SOA Pattern of the Week (#5): Service Decomposition

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.

In this series

• SOA Pattern of the Week (#1): Service Façade
• SOA Pattern of the Week (#2): Non-Agnostic Context
• SOA Pattern of the Week (#3): Domain Inventory
• SOA Pattern of the Week (#4): Service Normalization

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:

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine