The four tenets of SOA - part 2
I was not able to finish the thoughts on ”The four tenets of SOA” in one go, so this is part two. BTW, Ian Mariano reminded me of an official Microsoft whitepaper explaining Microsoft positioning on SOA, and how we see SOA as a way towards Connected Systems. The whitepaper is found at MSDN Architecture Center: Service Orientation and Its Role in Your Connected Systems Strategy.
I would also like to point out that the most important part of this, for me, is not actually the four tenets, but more of how services will be defined going forward. The tenets seem to be a good starting point for that discussion, but the crucial question for me is to understand whether we will define services as either:
- Technical aspects of distributed applications
- Providing business capabilities as coarse-grained services in the enterprise architecture
- A combination of the above
(And I do strongly believe it is #2 that is closest to were we are going.)
Tenet #4 – Compatibility is based upon policy.
When I am out presenting SOA to customers and partners, this is the tenet I feel is the hardest to explain. It seems to me that many feel the compability issue is somewhat “off-topic” of the general “What is a service”-discussion.
The concept that a service provider and a service consumer can use a policy to negotiate appropriate protocol, message format, security requirements etc is very tempting, and there is no doubt about WS-Policy is containing very nice capabilities. But on the other hand, is this really a requirement for being service oriented, isn’t this more of an implementation detail or maybe more correct; a web service infrastructure ability? In my opinion service-orientation is not tied into being web services only, although web services in most (many) cases would be the right technology for implementing SOA. As I mentioned earlier, I feel that service-orientation is more of providing coarse-grained services, corresponding to business capabilities in the enterprise, than a technical aspect of distributed computing. This means you could do fully “valid” service-orientation without the ability of providing a machine interpretable policy for the service, or actually completely without leveraging web service technology at all.