Bill takes a particular layered service model, a plausible combination of layers such as you might find in any number of popular SOA books, and shows how he can use this model to produce an inefficient and inflexible design.
Of course, all this shows is that there are problems with a particular layered service model, as interpreted by Bill. (The authors of the books from which Bill has taken this model might claim that Bill had misunderstood their thinking, but whose fault is that?) It doesn't show that all layered service models are bad.
As Bill points out, one reason commonly cited in support of the layered service model approach is the hope that services will be highly reusable. But there is a much more important reason for layering - based on the expectation that each layer has a different characteristic rate of change. (This principle is known as pace layering.)
When done properly, layering should make things more flexible. When done badly (as in Bill's example) then layering can have the opposite effect.
One of the problems is that the people inventing these layered service models often confuse classification with layering. We can identify lots of different types of service, therefore each type must go into a separate layer. A deeper problem with these models is that their creation is based purely on clever thinking rather than systematic and empirical comparison of alternatives. Too much architectural opinion is based on "here's a structural pattern that seems to make sense" rather than "here's a structural pattern that has been demonstrated to produce these effects".
See my post on Layering Principles. You can't just take an SOA principle ("loose coupling is good", "layering is good"), apply it indiscriminately and expect SOA magic to occur.
Great point on the confusion between classification and layering. Classification is needed to choose appropriate implementation platforms (e.g orchestration engine vs. Java app server), but that doesn't imply any particular direction of communication between the service types.
ReplyDeleteOne of our key reasons for layering has been the separation of concerns. For example, the separation of process-centric from information/data-centric capabilities. Whilst reuse is not the only driver for SOA, reuse (we prefer to say 'sharing') is hard to achieve when concerns are mixed. That is, it is hard to share data-centric capabilities in new processes, when they are bound up in another process.
ReplyDeletecould you elaborate more on classification vs Layering with few example to understand the differences.
ReplyDeleteWe are using Thomas Erl service model. I was wondering what would be a typical anti service pattern