SOA Tenets

I spent some time over the last few days revisiting the tenets of SOA.

1. Boundaries are Explicit
2. Services are Autonomous
3. Services share schema and contract, not class
4. Service compatibility is determined based on policy

Richard Turner, in 2005 the Product Manager for Indigo described the SOA tenets as:

1. Services have explicit boundaries, The only way to interact with a service or to obtain information or modify the state of the service is via its exposed edge. It shouldn't take a string return a string or a opaque bucket of something where you "just have to know whats in there". The service boundary describes explicitly what messages it can receive and what responses it will return.
   
2. Services are autonomous. If I was to build an application that consumed a service outside of my boundary of control then I should not assume the service at the other end implements its functionality in any particular way. I wouldn't be able to influence it to implement one way or another. I won't be able to connect my SQL Server database to directly to their SQL Server database inside the remote service. I'm simply talking to that service through its boundary and it also automatically enforces an isolation layer between our two services. This allows us them to construct very flexible, very de-coupled applications.  (The service should not impose on the client any special components to be installed. Nor should it have unrealistic small operations that requires special knowledge to or an invocation sequence).
   
3. Services share schema and contract, not class. More accurately maybe, it does not share objects. Services are about passing information back and forth between two systems such that those entities can communicate in a common fashion. This is not about remoting an object that actually runs on a service remote from me and controlling it from my environment because the other service maybe running on a platform completely different to mine and I may not have knowledge as to how to affect that component and how it runs in that environment. So services are all about passing information back and forth passed "by value" if you will, rather than "by reference".
   
4. Services interoperate based on policy. And the policy can be information such as, for example, as a service if you want to speak to me you must support some kind of security mechanism. Or you must support TCP as a transport protocol. Or that you must support transactions, for example. (You must comply with security to use this service, or you must use TCP or have a client certificate). Policy describes "how" to send the data (with encryption, with authentication requirements, with duplex or one-way messages).

Resources:
http://pradeepgururani.blogspot.com/2005/08/tenets-of-soa.html
http://pradeepgururani.blogspot.com/2005/08/little-about-soa.html