Making the Paradigm Shift Part 5 of N

Welcome back! Last time around, I talked about what a Service is, reviewed SO and I talked about the Four Tenets of SOA. This article moves from the general into specific Architectural Design Patterns that are important in SO and creating an SOA.

Last time I did talk about the Three-Layered Services Application Pattern [PnP02]. The question we are now faced with is what goes in each “layer?”

Service Interface Pattern [PnP02]

• Two main responsibilities
  • Define & implement service contracts
  • Implement service adapters
• Service Contract
  • Describe operations
  • Describe message formats
  • Describe MEPs that service implements (i.e. One-Way, Request/Response)

Service Adapter [WSSF]

• 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

The Entity Translator pattern is similar to the Message Translator pattern described in Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe and Bobby Woolf. [Hohpe04]

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

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

[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.

[Gamma95] Gamma, Helm, Johnson, and Vlissides. Design Patterns: Elements Reusable Object-Oriented Software. Addison-Wesley, 1995.

[Hohpe04] Hohpe, Gregor, and Bobby Woolf. Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2004.

[PnP02] patterns & practices, Microsoft Corporation. "Application Architecture for .NET: Designing Applications and Services." MSDN Library. Available at:msdn.microsoft.com/.../ms978348.aspx

[WSSF] Patterns & Practices, Microsoft Corporation. Web Services Software Factory