10 principles of SOA

• Explicit Boundaries - Everything needed by the service to provide its functionality should be passed to it when it's invoked. All access to service should be via its publicly exposed interface. Service invocations should be modeled as stateless. A service invocation isn't a remote procedure call.

• Shared Contract and Schema, not Class - Data is exchanged as XML documents validatable against one or more schemas.

• Policy-driven - The provider's functionality, syntax, and semantics must fit the consumer's requirements. The technical capabilities and needs must match.

• Autonomous - It must be possible to change a service's runtime environment, 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 the service interface all.

• Wire Formats, not Programming Language APIs - Services are exposed using a specific wire format that has to be supported. 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.

• Document-oriented - To interact with services, data is passed as documents. It should be self-descriptive. It should be explicitly modeled. e.g. a customer ID might be included along with the customer's address information (although the customer ID would be enough). This redundancy is explicitly accepted since it serves to isolate the service interface from the underlying data model of both service consumer and service provider. When a document-oriented pattern is applied, service invocations become meaningful exchanges of business messages instead of context-free RPC calls. When messages are sent in a Distributed Objects or RPC infrastructure, client and server can rely on a set of proxy classes (stubs and skeletons) generated from the interface description document.

• Loosely coupled - There are multiple dimensions in which a system can be loosely or tightly coupled. Dimensions include -

• Time - When participants are loosely coupled in time, they don't have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them. When one participant sends a message to the other one, it doesn't rely on an immediate answer to continue processing.

• Location - If participants query for the address of other participants they intend to communicate with, the location can change without having to reprogram, reconfigure, or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses.

• Type - A participant can either rely on all or parts of a document structure to do its work.

• Version - Service providers should be implemented to accept as many different versions as possible, and thus be liberal in what they accept, while service consumers should do their best to conform to exact grammars and document types.

• Cardinality - There may be a 1:1 relationship between service consumers and service providers especially in cases where a request/response interaction takes place or an explicit message queue is used.

• Lookup - A participant that intends to invoke a service can either rely on a name of a service provider to communicate with, or it can do a lookup operation first using a description of a set of capabilities instead. This implies a registry and/or repository that can match the consumer's needs to a provider's capabilities.

• Standards-compliant - Standards exist for technical aspects such as data formats, metadata, transport, and transfer protocols, as well as for business-level artifacts such as document types. Reliance should be on standards instead of proprietary APIs.

• Vendor-independent - It's unavoidable to decide on specific products, both commercial and free/open source software. None of these decisions must have implications on an architectural level. A participant can be built using any technology that supports the appropriate standards and not be restricted by any vendor roadmap.

• Metadata-driven - All of the metadata artifacts in the overall SOA need to be stored in a way that enables them to be discovered, retrieved, and interpreted at both design time and runtime.