April 07, 2009, 1:38 PM — A service inventory is a living body of services that individually will need the freedom to evolve independently over time. What we learned when documenting the SOA design pattern catalog is that there are patterns that emerged not only at design-time but also during this post-implementation evolutionary stage in a service's lifecycle.
There is one common scenario that repeatedly surfaced in many projects:
1. When we model and design services during early stages of SOA adoption we are constrained by current infrastructure and technology. These constraints require that we limit the size of service compositions and the extent of cross-service message exchanges. As a result, each service encompasses more logic and is coarser grained.
2. Our infrastructure improves over time (because of new platform upgrades or new funding for better hardware, etc.). Our existing service compositions are comprised of coarse-grained services that were delivered within the parameters of the older environment. However, we now realize that services could be more fine grained (and could perform and be composed more effectively) because the infrastructure can support larger service compositions.
It is in response to this situation that the Service Decomposition pattern provides a technique for splitting up a service after its initial deployment into two or more fine-grained services.
Of course, such an approach will raise a few eyebrows from those involved in version control and change management. How can we break apart a service with an established contract without impacting all of the consumer programs that have been using the service and have formed very real runtime dependencies on how it currently exists?
To address these issues, the Service Decomposition pattern needs the help of several other SOA design patterns:
- Proxy Capability – When logic is moved from one service to another, this pattern can be used to preserve the original capability that is expressed as part of the original service’s contract.
- Service Façade – In support of enabling Proxy Capability, this multi-purpose pattern can be used to establish (within the original service logic) a façade layer of processing that acts as a liaison between the original service and the new service. The façade component may actually invoke the corresponding capability on the newly created service, thereby acting as its service consumer on behalf of the consumer of the original service.
When applying these two patterns together with Service Decomposition, the façade logic can also be designed to compensate for a change in behavior that is likely to occur as a result of physically moving a segment of the original service logic into a new location.
An important requirement for the decomposition of a service to be successful is that the resulting, more fine-grained services have distinct functional contexts. When modeling and designing these new services, all applicable service-orientation principles and patterns must be considered as with any other new service. Other fundamental patterns, such as Service Normalization, also need to be applied to ensure that the new services properly line up with the others in the existing service inventory.
