One of the fundamental goals when designing service-oriented solutions is to attain a reduced degree of coupling between services, thereby increasing the freedom and flexibility with which services can be individually evolved. Achieving the right level of coupling "looseness" is most often considered a design issue that revolves around the service contract and the consumer programs that form dependencies upon it.

However, for the service architect there are opportunities to establish intermediate layers of abstraction within the service implementation that further foster reduced levels of coupling between its internal moving parts so as to accommodate the evolution and governance of the service itself. These intermediate abstraction layers are created by the application of Service Façade, a design pattern focused on intra-service design.

When designing a service, there are several negative coupling types you need to look out for. Contract-to-logic coupling, for example, results in a service contract that is derived from (and therefore may have formed dependencies upon) the underlying service logic, which makes the contract subject to change whenever the logic changes. The result is, predictably, a cascading effect whereby all service consumers are impacted (usually negatively) by the changes.

Service Façade can help avoid these situations by establishing an intermediary processing layer in between the core service logic and the service contract. The façade logic allows the service contract to remain decoupled from the underlying logic and further shields it from changes to the core business logic. This applies to both functional and behavioral changes, the latter of which may (often inadvertently) come about as a result of applying the Service Refactoring pattern. The façade layer can compensate for internal changes so that the service contract does not need to be modified as a result of the changes and/or the behavior of the functionality expressed in the contract is also not affected. In both cases, the service can evolve internally while existing service consumers remain protected from any potential side-effects.

Another scenario that can be effectively managed through the application of this pattern is when a single body of core service logic requires multiple contracts (a situation that actually pertains to another pattern called Concurrent Contracts). In this case, a separate service façade component can be created for each service contract, thereby retaining a clean abstraction of core service logic from the contract layer. This avoids having to augment and bloat the core service logic over time in order to accommodate different contracts and can further leverage the aforementioned benefits of functional and behavioral compensation when that logic is subject to functional change or refactoring efforts.

The Service Façade pattern can result in an elegant service architecture with clean layers of abstraction, but it can also impose extra processing overhead that naturally comes with increasing the physical distribution of service logic. The fact that service logic ends up being more distributed can also be perceived as increasing the complexity of the service design as well. Carefully minding the type of logic placed in façade layers will help mitigate these issues.

Overall, though, the intelligent and regulated application of this pattern can result in an effective separation of intra-service processing responsibilities, which brings with it numerous governance benefits that can accommodate the long-term evolution of the service and further help to preserve on-going relationships formed with service consumer programs.

The SOA Pattern of the Week series is comprised of original content and insights provided courtesy of the authors and contributors of the SOAPatterns.org community site and the book "SOA Design Patterns" (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the "Prentice Hall Service-Oriented Computing Series from Thomas Erl" (www.soabooks.com). Copyright 2009 SOA Systems Inc.

• SOA Pattern of the Week (#4): Service Normalization
• SOA Pattern of the Week (#3): Domain Inventory
• SOA Pattern of the Week (#3): Domain Inventory