6) Document-oriented
To interact with services, data is passed as documents. A document is an explicitly modeled, hierarchical container for data. The self-descriptiveness, as outlined in the previous section, is one important aspect of document-orientation. Ideally, a document will be modeled after real-world documents, such as purchase orders, invoices, or account statements. Documents should be designed so that they are useful in the context of a problem domain, which may suggest their use with one or more services.

Similar to a real-world paper document, a document exchanged with a service will include redundant information. For example, 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. While not absolutely required, it can usually be assumed that XML will be used as the document format/syntax.

Messages flowing between participants in an SOA connect disparate systems that evolve independently of each other. The loose coupling principle mandates as little dependence on common knowledge as possible. 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 same interface description document. If this is not the case, communication ceases on the assumption that the contract doesn't support interaction between those two parties. For this reason, RPC-style infrastructures require the synchronized evolution of client and server program code.

This is illustrated by the following comparison. Consider the message:

2006-03-1347113

and compare it to:

<order>
      <date>2006-03-13</date>
      <product-id>4711</product-id>
      <quantity>3</quantity>
</order>

While it's obvious that the second alternative is human-readable and the first is not, it's also notable that in the second case a participant that accesses the information via a technology such as XPath will be much better isolated against smaller non-breaking changes than one that relies on the fixed syntax. Conversely, using a self-descriptive message format such as XML while still using RPC patterns, such as stub and skeleton generation, serves only to increase XML's reputation as the most effective way to waste bandwidth. If one uses XML, the benefits should be exploited too. (See this paper for an excellent discussion of why many current Web Services stacks fail this test.)

7) Loosely Coupled
Most SOA proponents will agree that loose coupling is an important concept. Unfortunately, there are many different opinions about the characteristics that make a system "loosely coupled." There are multiple dimensions in which a system can be loosely or tightly coupled, and depending on the requirements and context, it may be loosely coupled in some of them and tightly coupled in others. 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, although the approach taken for this is irrelevant. When one participant sends a message to the other one, it doesn't rely on an immediate answer to continue processing (neither logically nor physically).
• 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: In an analogy to the concept of static versus dynamic and weak versus strong typing in programming languages, a participant can either rely on all or parts of a document structure to do its work.
• Version: Participants can depend on a specific version of a service interface or be resilient to change (to a certain degree). The more exact the version match has to be the less loosely coupled the participants (in this dimension). A good principle to follow is Postel's Law: Service providers should be implemented to accept as many different versions as possible, and thus be liberal in what they accept (and possibly even tolerant of errors), while service consumers should do their best to conform to exact grammars and document types. This increases the overall system's stability and flexibility.
• 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. In other cases, a service consumer (which in this case is more reasonably called a "message sender" or "event source") may neither know nor care about the number of recipients of a message.
• Lookup: A participant that intends to invoke a service can either rely on a (physical or logical) 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 (either directly or indirectly).
• Interface: Participants may require adherence to a service-specific interface or they may support a generic interface. If a generic interface is used, all participants consuming this generic interface can interact with all participants providing it. While this may seem awkward at first, the principle of a single generic (uniform) interface is at the core of the World Wide Web's architecture.

It's not always feasible or even desirable to create a system that's loosely coupled in all of the dimensions mentioned above. For different types of services, different tradeoffs have to be made.

8) Standards-compliant
A key principle to follow in an SOA approach is reliance on standards instead of proprietary APIs. 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 (e.g., in UBL).

9) Vendor-independent
No architectural principle should rely on any particular vendor's product. To transform an abstract concept into a concrete running system, 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. This means relying on both interoperability and portability standards as much as is reasonably possible. As a result, a participant can be built using any technology that supports the appropriate standards and not be restricted by any vendor roadmap.

10) 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. Artifacts include descriptions of service interfaces, participants, endpoint and binding information, organizational units and responsibility, document types/schemas, consumer/provider relationships, etc. As much as possible, using these artifacts should be automated by either code generation or interpretation and become part of the service and participant lifecycle.