In many customer engagements, I need to establish a basic set of SOA principles. The following sections introduce fundamental principles that a Service Oriented Architecture (SOA) should expose. They are not introduced as absolute truth, but rather as a frame of reference for SOA-related discussion. You'll note that the first four are based on Don Box's four tenets, although over time they may have acquired a personal spin.

1) Explicit Boundaries
Everything needed by the service to provide its functionality should be passed to it when it's invoked. All access to the service should be via its publicly exposed interface; no hidden assumptions should be necessary to invoke the service. "Services are inextricably tied to messaging in that the only way into and out of a service is through messages." A service invocation should - as a general pattern - not rely on a shared context; instead service invocations should be modeled as stateless. An interface exposed by a service is governed by a contract that describes its functional and non-functional capabilities and characteristics. The invocation of a service is an action that has a business effect, is possibly expensive in terms of resource consumption, and introduces a category of errors different from those of a local method invocation or remote procedure call. A service invocation isn't a remote procedure call.

While consuming and providing services certainly should be as easy as possible, so it's undesirable to hide too much of the fact that an interaction with a service takes place. The message sent to or received from the service, the service contract, and the service itself should all be first-class constructs within the SOA. This means, for example, that the programming models and tools that are used should at least provide an API that exposes these concepts to the service programmer. In summary, a service exposes its functionality through an explicit interface that encapsulates its internals; interaction with a service is an explicit act, relying on the passing of messages between consumer and provider.

2) Shared Contract and Schema, not Class
Starting from a service description (a contract), both a service consumer and a service provider should have everything they need to consume or provide the service. Following the principle of loose coupling, a service provider can't rely on the consumer's ability to reuse any code that it provides in its own environment; after all, it might be using a different development or runtime environment. This principle puts severe limits on the type of data that can be exchanged in an SOA. Ideally, the data is exchanged as XML documents validatable against one or more schemas, since they are supported in every programming environment one can imagine.

3) Policy-driven
To interact with a service, two orthogonal requirement sets have to be met:

1. The provider's functionality, syntax, and semantics must fit the consumer's requirements,
2. The technical capabilities and needs must match.

For example, a service provider may offer exactly the service a consumer needs, but offer it over JMS while the consumer can only use HTTP (because it's implemented on a .NET platform); a provider might require message-level encryption via the XML Encryption standard, while the consumer can only support transport-level security using SSL. So even in cases where both partners have the necessary capabilities, they might have to be "activated" - e.g., a provider might encrypt response messages to different consumers using different algorithms based on their needs.

To support access to a service from the largest number of differently equipped and capable consumers, a policy mechanism has been introduced as part of the SOA toolset. While the functional aspects are described in the service interface, the orthogonal, non-functional capabilities and needs are specified using policies.

4) Autonomous
Related to the explicit boundaries principle (5.4.1.1), a service is autonomous in that its only relation to the outside world - at least from the SOA perspective - is through its interface. In particular, it must be possible to change a service's runtime environment, say from a lightweight prototype implementation to a full-blown application server-based collection of collaborating components without affecting its consumers. Services can be changed and deployed, versioned, and managed independently of each other. A service provider can't rely on the ability of its consumers to adapt to a new version of the service quickly; some of them might not be able, or willing, to adapt to a new version of a service interface at all (especially if they're outside the service provider's sphere of control).

5) Wire Formats, not Programming Language APIs
Services are exposed using a specific wire format that has to be supported. This principle is strongly related to the explicitness of the boundaries principle, but introduces a new perspective: To ensure the utmost accessibility (and so, long-term usability), a service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service. For example, it's a useful test of conformance to this principle to consider whether it's possible to consume or provide a specific service from a mainstream dynamic programming language such as Perl, Python, or Ruby. Even though none of these may currently play any role in the current technology landscape, this consideration can serve as a litmus test to assess whether the following criteria are met:

• All message formats are described using an open standard or human-readable description
• It's possible to create messages adhering to those schemas with reasonable effort without a specific programmer's library
• The semantics and syntax for additional information necessary for successful communication, such as headers for purposes such as security or reliability, follow a public specification or standard
• At least one of the transport (or transfer) protocols used to interact with the service is a standard network protocol (or is accessible via one)