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 Statements about SOA

Stefan Tilkov,

Jeff Schneider linked to and commented on Judith Hurwitz’s ten principles of SOA, which somehow made me write down the first 10 SOA statements that came to my mind. Thanks to Hartmut and Marcel for early feedback … let me know what you think.

1. An SOA is primarily aimed at being an architecture for enterprise-wide usage. It is usable within a single application that is being decomposed using a services approach, but doing this makes the most sense when the ultimate goal is to arrive at a service landscape. For structuring applications internally, other technologies may be more appropriate.

2. A key concept within an SOA is loose coupling. Loose coupling has multiple dimensions, such as location, time, binding and address lookup, versioning, protocols and capabilities. It will not always be achievable, nor even desirable, to have loose coupling in all dimensions.

3. A service, as the primary concept within an SOA, encapsulates a business function that is accessed by means of messages, or documents, that are sent to it to request some function, which may possibly return a result message/document. With regards to their functionality, services are defined solely based on the type of documents they accept and emit. The number and type of documents a service can process define its “interface”, which some people prefer to call its “contract”.

4. The non-functional characteristics of a service are defined by means of a policy. Examples of aspects defined by policy are which security mechanism to apply, what transport or transfer protocol to use, and whether to perform reliable message delivery or not.

5. If you use Web services, you’re not necessarily doing SOA. Especially when you follow the examples and use the tools of the first generation, you can use Web services to build some of the worst RPC-style distributed computing systems ever.

6. You can do SOA without using Web services, but in general, that’s a bad idea. There are many benefits you can gain from Web services over distributed object technologies such as CORBA or DCOM, or messaging systems such as MQ or JMS, most notably with regards to loose coupling, interoperability, standards support and vendor independence.

7. A service, by definition, has a contract with its consumers, not with a runtime environment. This is one of the main aspects distiniguishing a service from a component (document-based interfaces being a close second).

8. In an advanced SOA, metadata plays a critical role in managing, administering, evaluating, optimizing, and evolving the services and their relationships. Whether metadata is created and maintained centrally and pushed towards the service endpoints, collected and cached in a central location, or maintained in a decentralized fashion, is a matter of choice.

9. Services can be combined and composed to build new services, or orchestrated to fully support a complete business process. Whether this is done using some programming language, or some engine with an associated declarative process specification language, is largely irrelevant.

10. Within an SOA, the focus is on the services, their contracts and policies, the standards being used, communication patterns and conventions, etc., not on any particular product. If an SOA effort relies on some vendor’s specific product instead of generally available standards, it misses one of the key points. You can’t buy an SOA.

On November 5, 2005 1:52 PM, Steve Ross-Talbot said:

Wrt to point 9:

The notion of defining a Business Process over a set of services in an SOA is an attractive way of utilising the services to achieve a measurable objective. But the way it is realised is of importance. One could realise a BP in an application server that is controlling the services (orchestration) or one could realise it as a script in which each service performs exactly what is required of it relative to the description of the BP. The former is server centric and so has an impact on the robustness of the system and the coupling of the BP to the services. The latter is higher up the stack and can be used to derive the former but can also be used to inform the services of their expected behavior and so yield a more distributed solution - more robust and looser coupling.

On November 5, 2005 3:00 PM, Stefan Tilkov said:

Interesting aspect, definitely. I agree that any centralized component has a bad smell, and this is IMO true for a centralized orchestration engine as well. Given the definition from /blog/st/2005/02/16/choreographyvsorchestration.html, it seems that you prefer choreography over orchestration. Although I don’t have practical experience with either, I tend to agree with this.

On November 5, 2005 11:45 PM, Jim Webber said:

Hey Stefan,

Point 5 contradicts point 3 I think - “request some function” and “return a result message” are precisely what most WS people think WS is all about. You capture this eloquently in point 5 I think.

I don’t think you went far enough with point 9. Yes it doesn’t matter what I use to compose services together functionally, but if I’m going to have an easier life I need some standard pattern (hint: extended transactions) to ensure end-to-end integrity of the composed process.

Jim

On November 6, 2005 12:32 AM, Stefan Tilkov said:

Hi Jim, thanks for the comments. I see your point with regard to 3 and 5, but I wonder: would you equate RPC with request/response? I’d argue that the RPC is something to be avoided because it tries to abstract away the net, while the second is still one of the most common patterns (if not the only one) in communication. I agree that a simpler, processMessage()-style communication plus some correlation mechanism is the basic building block for many more interesting patterns, but even then, request/response is still going to be the most common one.

As to point 9, I still have my doubts whether a transaction mechanism is a good idea and one will not have to design for failure explicitly, anyway - 2PC transactions violate loose coupling principles and other concepts, such as compensating transactions, seem to me to be an attempt at a solution that are never going to meet a 100% goal.

On November 6, 2005 6:16 AM, grumpY! said:

also, having a service does not mean using a service.

where i work (look at my name, guess), we have many webservices we offer to the public, many employing lower level schemes behind the scenes (shared memory, mem-mapped files, etc). internally we almost always use these lower level schemes to access the data. webservices help you cross domain, system, implementation boundaries. but crossing these boundaries has a cost. if you don’t need to incure that cost, don’t.

On November 6, 2005 6:19 PM, Jim Thomas said:

“You can do SOA without using Web services, but in general, that’s a bad idea” I really don’t agree with this statement. I think one could say that W.S. is the initial driver of SOA but I wouldn’t limit SOA to W.S. Primarily, consider the “oriented” portion of SOA. What if we had said “You can do Object Oriented programming without C++ but in general that’s a bad idea”.

On November 6, 2005 6:56 PM, Stefan Tilkov said:

This was the point I expected the most disagreement with :-)

I think the analogy should rather be “You can do Object Oriented Programming without using an object-oriented language but in general that’s a bad idea.” This definitely reflects what I think — you can do OOP in plain C or COBOL, and you can build service-oriented systems using CORBA or DCOM.

In my opinion, the message-orientation required for an architecture to qualify as an SOA implies XML or some equivalent. Since the latter is not exactly wide-spread (or are you passing around some hashtable/key-value variant?), the former is practically a requirement.

On November 6, 2005 8:16 PM, Jim Thomas said:

I don’t necessarily see SOA as requiring message-orientation, that sounds more like MOM to me. I see SOA as having the flexibility to facilitate and orchestrate all of these strategies.

On November 6, 2005 8:58 PM, Stefan Tilkov said:

Maybe I need to rephrase my point 3 to make this clearer. I argue that the data exchanged on the wire is what’s in focus in an SOA; whether you call that a message or a document is not that important. If you invoke a remote method with some parameters and a return value that just happen to be mapped to some protocol message you don’t care about, your service relies on much more commonality than I’d tolerate in what I consider to be SOA.

On November 7, 2005 6:14 PM, Anne Thomas Manes said:

Regarding your final sentence in Statement #3:

The number and type of documents a service can process define its “interface”, which some people prefer to call its “contract”.

IMO a contract defines much more than just the service’s interface. A contract comprises all aspects of agreement between a service consumer and a service provider, and it includes, for example, the definition of the interface, the agreed-to intersection of the constraints and capabilities of both the consumer and the provider, any service level agreements in place between the consumer and the provider, etc.

On November 7, 2005 8:55 PM, Stefan Tilkov said:

Anne, point taken; it makes sense to distinguish between interface and contract and include interface, policy and other information as part of the contract. I wonder, though: once consumer/provider relationships enter into the contract, how many contracts does a provider have? One per consumer? Or one generic one with multiple specializations?