SOA: Making the Paradigm Shift Part 4 of N ROUGH DRAFT

Note: This is a Rough Draft open to comments and editing…

Last time in Part 3, I talked about the definitions of SOA, from the Architectural and Business standpoints. Left over, was a discussion of the Four Tenets of SOA. However, we really do need to try to define a Service itself and see if there are any Design Patterns to help guide us in shaping what constitutes or becomes a service. These Design Patterns help to put the “A” in SOA and we will be spending a lot of time in Part 5 with the Architectural Patterns that make up SOA.

There’s More than the 4
Tenets!
• XML Document Based (not RPC!!)
• Loosely-Coupled
• Coarse-Grained Agnostic Services
• Asynchronous
• WSDL described
• Conversational
• Reliable
• Secure/Identity
• Policy Driven
• BPEL Orchestrated

What is a Service?

There are, of course, more than one definition of a service. We can start out with one of my favorites:

“a software component of distinctive functional meaning that typically encapsulates a high-level business concept.” [3]

But let’s bring it down out of the abstract. Think about travel agency, utility company, ISP, etc. They offer:

• Publicized package of functionality that is
• Composable (Travel agency makes use of
  transportation)
• Discoverable on descriptions, terms & conditions
• Use based on agreed-upon contract
• Some Quality of service

Likewise, this analogy can be applied to Software services. Software services, however, are not just described by contract but by business terms.
Software Service characteristics:

• Available at particular endpoint
• Receives/sends messages & behavior
• Contract governs behavior
• Quality requirements via policy

Let’s say you buy all this stuff I have been writing and you want to get concrete about it. In other words, you want to expose a chunk of stuff as a “Service.” How do you go about? Well, luckily there are various Pattern sources like Fowler [Fowler03], POSA [Buschmann96] , and Enterprise Solution Patterns Using .NET [PnP02] to help guide us.

Service Interface Pattern [PnP02]

Problem

How  do you expose your application?s functionality over a network so it can be consumed by disparate applications?

Forces

• Separation of concerns – business logic and service contract issues
• Consuming applications may require different channels for
  optimization
• Consumers application may want to communicate with application using different technologies

Solution

• Design your application as collection of software services, each w/ a service interface through which consumers of the app may
  interact w/ service
• Use the Service Interface pattern to describe behavior of a service and the messages required to interact with that service.
• The service interface does the following:
  • Describes operations that your service provides that a client can use
  • Describes the format for information being passed to and from operations
  • Describes the message exchange patterns that the service implements, such as: request/reply, one-way, and duplex

Three-Layered Services Application [PnP02]

Context

You are designing a Layered Application. You want to expose some of the core functionality of your application as services that other applications can consume, and you want your application to consume services exposed by other applications.

Problem

How do you layer a service-oriented application and then determine the components in each layer?

Forces

In addition to the forces discussed in Layered Application, the following forces apply:

Service Adapter
• Implements service contract defined in Service Interface
layer
• Connects Service Layer to Business Layer
– Lives in Service Layer
• Translates from message types to Business Entities &
back
– Keep each other separate for evolution!
• Calls methods on Business/Domain Logic components
• Employ an Entity Translator b/w Service Adapter &
Business Entity

Entity Translator
static class PayeeTranslator
{
public static Business.Payee TranslateFromServicePayeeToBusinessPayee(Service.Payee servicePayee)
{
Business.Payee businessPayee = new Business.Payee();
businessPayee.PayeeId = servicePayee.PayeeId;
businessPayee.CustomerId = servicePayee.CustomerId;
businessPayee.Name = servicePayee.Name;
businessPayee.AccountNumber = servicePayee.AccountNumber;
businessPayee.Address1 = servicePayee.Address1;
businessPayee.Address2 = servicePayee.Address2;
businessPayee.City = servicePayee.City;
businessPayee.State = servicePayee.State;
businessPayee.Zip = servicePayee.Zip;
businessPayee.EMail = servicePayee.EMail;
businessPayee.Phone = servicePayee.Phone;
businessPayee.PrimaryContact = servicePayee.PrimaryContact;
businessPayee.SecondaryContact = servicePayee.SecondaryContact;
businessPayee.TransitNumber = servicePayee.TransitNumber;
businessPayee.RoutingNumber = servicePayee.RoutingNumber;
businessPayee.Country = servicePayee.Country;
return businessPayee;
}

Domain/Business Layer
• This is your business core value
• Can use Row Table Gateway [Fowler] or Transaction Script  [Fowler]
1-1
– Mapping b/w object and database Table
– Add logic to create Active Record [Fowler]
• I now prefer to create rich Domain Model [Fowler] and use  Domain-
Driven Design [Evans]
– Layer models actual business domain w/ Ubiquitous Language
– Converted from Data-Driven Architect to modeling business
• Then use Domain Mapper [Fowler] a.k.a OR/M to persist
to  Resource Layer
– Evans Patterns help here  Repository, Factory, Entity, Value Type

Repository Pattern
• Context 
– Business entities interact w/ data access components to  retrieve
& save business entities 
– One interface to Find & save entity whether In-Memory or in
database 
– Complex business rules require large # of unique queries 
– Different data sources/databases
• Forces 
– Client should not be aware of SQL code (no coupling) 
– Business rules require lots of complex queries 
– Must support many data stores (In-Memory, Service Agent, DB)

Repository Pattern
• Implement repository layer b/w business components &
data access components 
• Repository responsible for using information found in 
business components to build a query that will be used
with the data access layer 
• Simple 
– Queries hard-coded in Repository & pass-in data parameters
• Sophisticated
– True power of Repository 
– Create Criteria object [Fowler] for what trying to find 
– Criteria object used by Repository to build query 
– Use Criteria object to handle complex business rules vs. separate
functions

• [3] Enterprise SOA: Service-Oriented Architecture Best Practices

• [Buschmann96] Buschmann, Frank, et al. Pattern-Oriented Software Architecture. John Wiley & Sons Ltd, 1996.