This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

10 Principles of SOA

Stefan Tilkov,

In many customer engagements, I need to establish a basic set of principles of SOA. The following sections introduce fundamental principles that a Service-oriented Architecture (SOA) should expose.These are not introduced as an absolute truth, but rather as a frame of reference for SOA-related discussions. You’ll note that the first four are based on Don Box’s four tenets, although over time they may have acquired a slight personal spin. (I’m putting them up now because someone asked me for a version that can be referenced; I haven’t reviewed them again now and may actually have changed my mind with regards to some of them.)

1. Explicit Boundaries

Everything needed by the service to provide its functionality should be passed to it when it is invoked. All access to the service should be via its publicly exposed interface; no hidden assumptions must be necessary to invoke the service. “Services are inextricably tied to messaging in that the only way into and out of a service are 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 than those of a local method invocation or remote procedure call. A service invocation is not a remote procedure call.

While consuming and providing services certainly should be as easy as possible, it is therefore 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 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 not 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 these 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 functionality, syntax and semantics of the provider 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 (e.g. because it is implemented on the .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. Even in those cases where both partners do have the necessary capabilities, they might need 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 possible number of differently equipped and capable consumers, a policy mechanism has been introduced as part of the SOA tool set. 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 (, 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, e.g. from a lightweight prototype implementation to a full-blown, application server-based collection of collaborating components, without any effect on its consumers. Services can be changed and deployed, versioned and managed independently of each other. A service provider can not rely on the ability of its consumers to quickly adapt to a new version of the service; some of them might not even be able, or willing, to adapt to a new version of a service interface at all (especially if they are outside the service provider’s sphere of control).

5. Wire formats, not Programming Language APIs

Services are exposed using a specific wire format that needs to be supported. This principle is strongly related to the explicitness of boundaries principle, but introduces a new perspective: To ensure the utmost accessibility (and therefore, 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 is a useful test for conformance to this principle to consider whether it is 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 a human readable description
  • It is possible to create messages adhering to those schemas with reasonable effort without requiring 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 (or is accessible via a) standard network protocol

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 on the context of a problem domain, which may suggest their use with one or more services.

Similarly 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. Whena document-oriented pattern is applied, service invocations become meaningful exchanges of business messages instead of context-free RPC calls. While not an absolute 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 that the dependence on common knowledge ought to be as small 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 does not support interaction between those two parties. For this reason, RPC-style infrastructures require synchronized evolution of client and server program code.

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


and compare it to:


While it is obvious that the second alternative is human-readable while the first one is not, it is 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 does not rely on an immediate answer message to continue processing (neither logically, nor physically).
  • Location: If participants query for the address of participants they intend to communicate with, the location can change without having to re-program, 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 vs. dynamic and weak vs. strong typing in programming languages, a participant can either rely on all or only on parts of a document structure to perform 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 perform a lookup operation first, using a description of a set of capabilities instead. This implies a registry and/or repository that is able to match the consumer’s needs to a providers 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 sight, the principle of a single generic (uniform) interface is at the core of the WWW’s architecture.

It is not always feasible nor even desirable to create a system that is loosely coupled in all of the dimensions mentioned above. For different types of services, different trade-offs need to be made.

8. Standards-compliant

A key principle to be followed in an SOA approach is the reliance on standards instead of proprietary APIs. Standards exists 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 implies reliance on both interoperability and portability standards as much as reasonably possible. As a result, a participant can be built using any technology that supports the appropriate standards, not restricted by any vendor roadmap.

10. Metadata-driven

All of the metadata artifacts within the overall SOA need to be stored in a way that enables them to be discovered, retrieved and interpreted at both design and run time. 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, usage of these artifacts should be automated by either code generation or interpretation and become part of the service and participant life cycle.

On December 13, 2006 4:59 PM, David Ing said:

Hi Stefan. If you do come to review them then, if you haven’t already seen it already, take a look at this:

I’m still chewing on it, but thought I should pass on…

On December 14, 2006 5:44 AM, Spar Hawk said:

Hi Stefan,

Very interesting points; most of them ring true in my work with web services, as well. A question though, you mention in point #6: “…See [11] for an excellent discussion…” - but I can’t locate the reference. Can you provide it?

Thank you for the thoughtful discussion.

On December 14, 2006 6:19 AM, Rafael said:

Great article, as usual. I have just one question: what is the [11] referencing on item 6? Thanks.

On December 14, 2006 7:56 AM, Mark Baker said:

I like constraints better than principles, but as principles go, those are pretty good ones 8-)

On December 14, 2006 9:13 AM, Stefan Tilkov said:

Thanks for the feedback, I’ve fixed the link to “11”, which should be

On December 14, 2006 10:03 AM, Peter said:

If you use WebServices Frameworks with “standard” Stub/Skeleton generation for your SOA you will fail on #6 and #7 as you already mentioned. I don’t know why these Frameworks are implemented this way. Why don’t they just ignored unknown elements as default. Like all the Browsers did for years with HTML. It’s the “Must ignore” pattern. As you said these frameworks use the flexible XML in an inflexible manner. For Axis 1 and 2 I could solve this problem by using other bindings, e.g. XMLBeans. But then you have to do some things manually and you have to provide some code to your clients. It’s not enough to provide the WSDL URLs anymore, because then they’ll use the standard wsdl2xxx tools and fail.

So why is “Must ignore” not a basic rule in the WS/SOAP world?

On December 14, 2006 3:27 PM, Stefan Tilkov said:

So why is “Must ignore” not a basic rule in the WS/SOAP world?

IMO, the WS/SOAP world is traditionally very much rooted in the statically typed language world — the idea of “loose contracts” seems almost absurd from that perspective. I agree, though, frameworks could be implemented differently, which would change a lot.

On December 17, 2006 1:35 AM, James said:

You should further define policy in future blog entries. For example, encryption, routing, authorization, logging, etc can all be defined via policy. The key is to tell folks how not just what…

On December 21, 2006 4:29 PM, Carlos E. Perez said:

Good post and a lot of interesting links.

Question for the first principle. How does one ensure that there are no “shared context” between two parties in a conversation?

I mean, in any conversation, shared context is built up to make communication more efficient. That’s why the english language has pronouns. The act of communicating a reference to an object establishes a shared context. Furthermore, the absence of any reference passing implies a purely functional computation (i.e. stateless) and therefore implies that distribution is an unnecessary artifiact.

Let me know if you got any insight on this.

On December 21, 2006 4:54 PM, Stefan Tilkov said:

Carlos, very good question. We had very long (and heated) discussions about this in our last project — without arriving at a fully satisfactory answer.

On the one hand, stateless communication does (obviously) not imply that there is not supposed to be any side effect (in the programming language theory sense). Otherwise, there could never be something like “CreateCustomer()” (or a POST to /customers, if you prefer). What is bad, though, is if a sequence of invocations or exchanges don’t have merit on their own, but only as a whole; for example “createOrder()”, “addItem()”, “addItem()”, “saveOrder()” would be an example for what I would want to avoid.

You are obviously right that passing “complete” data instead of a reference wastes bandwith and performance. That’s the downside of less coupling, though — I guess one has to find a good compromise between efficiency and other goals.

Being able to rely on a common concept for identifying resources helps, of course, and is a good argument in favor of a RESTful approach.

On December 22, 2006 1:42 PM, Carlos E. Perez said:


So in your example your really talking about “shared session state”.

The question then is, where does one draw the line as to what state is shared or not?

What’s wrong with “createOrder()”, “addItem()”, “addItem()”, “saveOrder()” is the amount of network calls… the DTO pattern that fixes this. Is object oriented like messagging what we intend on banning?


On December 22, 2006 8:49 PM, Michael Stiefel said:

The SOA Reference Model mentioned by David Ing has been an approved OASIS specification since October 2006. Here is the link to the final version:

On December 22, 2006 8:50 PM, Stefan Tilkov said:

So in your example your really talking about “shared session state”.


Is object oriented like messagging what we intend on banning?

Well … I guess we don’t have a problem of understanding each other, more of finding the right way to phrase this. On the one hand, we could separate “objects” into “transient objects” and “persistent objects”, or maybe into “objects” and “resources”. Interacting with resources is fine (even when not using a REST approach) because they have business meaning and are not an implementation detail.

For example, createOrder(OrderDTO) would create an order in a single invocation and return an identifier “id” for that order. A later cancelOrder(id) would be fine IMO, because the object or resource we’re interacting with is not an implementation detail. That would be a non-technical, design-oriented reason for assuming as little shared state as possible.

The other, more technical reason is simply to arrive at a shared-nothing architecture (where, again, “sharing nothing” means “sharing nothing that isn’t persistent”) which means that each request can be handled by a different {thread|process|machine}.

On December 22, 2006 9:03 PM, Stefan Tilkov said:

I commented on an earlier draft of the OASIS RM a while ago: /blog/st/2006/03/20/comments_on_the_oasis_soa_reference_model.html

On January 8, 2007 1:38 PM, Håkon said:

Great principles! :-)

I am missing Service Identification in your loose coupling collection. Each Service should deal with a specific area of business and at a suitable loose coupled level. I think it relates to the discussion about object orientation contra service orientation. Zapthink has a great analogy to Lego (sorry, I am Danish and therefore brought up with Lego :-) ) which can be found at IMO this is the essential of Loose Coupling and has no relation to the technical issues of loose coupling, how important they are as well. I think this point of loose coupling is one of the most overseen points of Service Orientation, but at the same time it is one of the most essential points of Service Orientation :-)

I agree with your example of Order, i.e. a CustomerOrderService with operations like Create and Cancel could be one of the basic building blocks in an Enterprise dealing with shooping customers.