.NET cognoscenti Rockford Lhotka and Ted Neward have been having some interesting discussions on the what exactly is the nature of SOA. (Service Oriented Architecture for those of you that have been in a cave) About the only thing that anybody seems to agree on is that nobody know exactly what is the definition of a service.
Another thing that seems to be inarguable is that a lot of people are going to make a lot of money off of SOA - whether they know what it is or not. The good folks at Jacada, seem to have figured out the whole SOA thing which is interesting given that just about everybody who is anybody from the J2EE world as well as the .NET haven't been able to do it.
Don Box of Microsoft's Indigo team, offers up these four tenets of service orientation:
Tenet 1: Boundaries Are Explicit. Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.
Tenet 2: Services Are Autonomous. Services behave reasonably as independent entities. We make no assumptions on the space between the service boundaries. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes can and will evolve. The service should expect that peer services can and will fail, and that it can and will received malformed or malicious messages. Services should be built not to fail, using (for example) redundancy and failover techniques.
Tenet 3: Services Share Schema and Contract, Not Class. Services interact solely on their expression of structures using schema, and behaviors using contract. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows machine the verification of incoming messages, which allows us to protect the service's integrity. Contracts and schema must remain stable over time, so building them flexibly (for example, through use of xsd:any in schema) is important.
Tenet 4: Service Compatibility Is Based on Policy. Both service-providers and service-consumers will have policies—operational requirements—for interactions across boundaries. A simple example of provider-side policy is that a service may require that the invoker have a valid account with the service provider. From the consumer-side, an organization may require that service invocations across the Internet be encrypted, so it will only use services that offer the capability of bi-directional security-enhanced data exchanges. Services express their capabilities and requirements in terms of a machine-readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system at large; services must simply be able to satisfy each other's policy requirements.
For now I am content to let others worry about these issues and futher define just exactly what is a “service“. If you are interested, here is a white paper that presents Microsoft Corporation's vision for service orientation and service-oriented architecture in enterprise computing. In the meantime, I'm still working on getting my Navision ERP system to talk to our manufacturers through EDI using BizTalk 2002. Ick.
Just because I can...