Tenets of Service Orientation

Before I get into the service standards it's appropriate to lay the groundwork by defining what we mean by service-orientation or service oriented architecture. Much of this is probably familiar to many readers and is based the lead of some key Microsoft architects, but is provided as a stake in the ground.

Although definitions of this term vary in the industry the idea within Compassion an SOA or service-oriented architecture is an orchestrated sequence of messaging, transformation, routing and processing events in which XML technologies expose the message content and the components that operate on the messages.

Technically a service exposes an interface contract that encapsulates operations within a specific domain (business or technical for example). This contract defines the behavior (policy) of the service, the messages used to interact with the service, and the message exchange patterns the service employs. The service manages its own state information. Because the interface contract is platform and language independent, the technology used to define messages must also be agnostic with respect to any specific platform/language. Therefore, messages are constructed using XML documents that conform to XML schemas (XSD). Services then exchange messages with applications or other services.

In short service-orientation encompasses the following tenets:

• Explicit Boundaries – services are bounded by their contracts that define specific messages they accept and return
• Autonomous – services are self-contained and built to last. The applications that use them will change more frequently than the services themselves
• Negotiation via policy – services expose their requirements such as security and message exchange patterns via policies in the contract
• Exposed Schema and Contract – service consumers use the contract and the schema it contains in order to create messages that interact with the service
• Message Driven – all interaction with the service occurs through messages. Messages share schema and contract but not class or internal representation
• Reliable - services are by definition shared resources and so is not the purview of a single application. In other words services are built to last, applications and business processes are built to change. As a result there is an implicit requirement that services be reliable.
• Available – just as in the previous tenet services must be highly available since they will be shared by a wide variety of applications