Dependencies between services
During a architect panel at TechEd Europe one of the questions centered on dependencies between services: Isn't there a contradiction between promoting loose-coupling and minimal dependencies between services on one hand and collaboration between services on the other hand?
In this respect it is important to separate the business and technical aspects of service orientation. Services should make minimal assumptions in the technical realm, for example about location (may vary from same machine to outsourced on other side of the world over time), communication protocol (HTTP, DCOM, MSMQ/MQSeries, RMI, IIOP), message format (XML, binary XML), and many other aspects that are policy to be determined and optimised by administrators/operators rather than developers.
If IT services (provided by machines) are to mirror business services (provided by people), the dependencies between services will mirror dependencies between people. People must collaborate because they are not able (lack of capability) or allowed (lack of authorisation) to do everything that they are expected to do by themselves. For the same reason services must collaborate to perform the task they are expected to do. If a service would try to do everything, you end up with the monoliths and application silos that we are slowly trying to get rid of!
In this respect it is important to separate the business and technical aspects of service orientation. Services should make minimal assumptions in the technical realm, for example about location (may vary from same machine to outsourced on other side of the world over time), communication protocol (HTTP, DCOM, MSMQ/MQSeries, RMI, IIOP), message format (XML, binary XML), and many other aspects that are policy to be determined and optimised by administrators/operators rather than developers.
If IT services (provided by machines) are to mirror business services (provided by people), the dependencies between services will mirror dependencies between people. People must collaborate because they are not able (lack of capability) or allowed (lack of authorisation) to do everything that they are expected to do by themselves. For the same reason services must collaborate to perform the task they are expected to do. If a service would try to do everything, you end up with the monoliths and application silos that we are slowly trying to get rid of!
1 Comments:
I had exactly the same thoughts ( I was at most of the SOA sessions at Teched Europe too). I particularly think that the Proseware architecture is fundamentally flawed in this respect - especially as its being touted as the best practices implementation of an SOA. Clemens hardcoded complex dependencies between services such that in a particular business process, each service had awareness of the next one it had to call. This takes away all the benefits of loose coupling from an architectural point of view as changes to business processes will then have massive impact on the system designed like this. Clearly Biztalk 2004 is an ideal place to put the awareness of the business process and the collaboration between services. However even if you don't have the inclination or budget for Biztalk, in my view a beter implemtation would be to create a business process co-ordination service where all knoweledge of the dependencies between services lives.
Post a Comment
<< Home