We complete this series of entries dedicated to the SOA principles with this eighth and final principle: service composability.
As we have been commenting on in this series, most SOA principles are closely interrelated, and often need each other to be implemented. This is again the case with the principle of service composition.
What this service comes to underline is a design principle that is not always immediate to see, and that if not taken into account can lead to an important amount of effort to redesign what should have been stable.
Often the first services of an implementation of an SOA strategy will come from the bottom up approach, that is, starting from the existing integration solutions in the legacy systems.
After some work of abstraction and standardization, we will identify the SOA services that meet the existing needs at a higher level of service orientation.
Usually those needs are simple tasks, with hardly any business rules or complex events to orchestrate.
Other times, our services will come from the analysis of more or less complex business processes (top-down approach). First we will analyze simpler processes, with few actors, low complexity business rules, etc.
This path from top to bottom will generally gives us services with a high level of abstraction, and often we will find in our design desktop some services with vocation to solve complex problems. These problems can be exploited in simpler ones, which could lead to more granular services, more detailed rules, etc.
The challenge presented here is that in both approaches, services must be designed with the idea that in addition to solving the need or task we are analyzing, it must be able to combine with other services to solve more complex processes, compound services.
We might think this does not require an SOA principle. After all, by using standards for the design of the services we can always combine them.
But it’s not enough.
Consider, for example, the top-down scenario we have raised: we analyze a particular business process, and we identify a possible service to include in the catalog.
Well, we can try to solve that subprocess or set of threads through a single service, or we can break it down into increasingly simple tasks, and make it easier for them to have their own standard service.
What for? Why increase the number of services to design, build and maintain?
Easy: to have more lego pieces.
To count on next use cases with enough standard services, to be able to select some of these pieces, and compose other services of superior order simply assembling these services.
The simile of the lego game is very useful.
To have a set of standard services, oriented by business events, orchestrated by business rules, and able to be autonomous and at the same time to compose higher order services, provides tremendous power and flexibility in maximizing impact and benefit of the entire SOA strategy.
It’s like having a box of lego pieces of different shapes and colors, rather than having large pieces, assembled specifically for some specific need, that would reduce our ability to reuse that piece. And most likely it will include details that will be presented to us in other models, and therefore we will have to re-include.
If we decompose all the lego parts instead, we will have much more ease and flexibility when composing any form, without worrying about retouching or redesigning anything, or repeating anything that already exists.
Consider also the maintenance of the catalog.
If our services have the proper granularity that allows them to compose higher order services, maintenance is facilitated and clarified very quickly. Any errors that arise, or changes that we have to add to our services, will affect many less services of the catalog, since all their uses (autonomous or compound) will be immediately updated by the new version of the corrected or evolved service.
As you can see, keeping in mind the principle of service composition when it comes to identifying, analyzing and designing our SOA services, brings significant benefits to our future, and greatly enhances the impact and rationale of the entire SOA strategy for the organization.