W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2004

Typical SOA ... SOA Patterns

From: Paul Denning <pauld@mitre.org>
Date: Fri, 30 Jan 2004 09:54:53 -0500
Message-Id: <>
To: www-ws-arch@w3.org

The WSA [1] is essentially frozen, but there is one point that I would like 
to discuss, and perhaps add it to section 4.3 (if WSAWG deems it significant).

Section 3.1.1 says "A Service Oriented Architecture (SOA) is a form of 
distributed systems architecture that is typically characterized by the 
following properties: ..."

Keyword is "typically".

We do not define the minimum essential pieces of SOA.  We often see people 
explain SOA using the familiar triangle diagram with requester, provider, 
and broker/registry/xxx.  This third bubble has been 
controversial.  Vendors often brief you that UDDI is the third bubble, but 
then do not really stress UDDI as an essential piece of SOA.  Vendors are 
often presenting SOA with an eye toward selling you a BPEL workflow engine, 
suggesting that choreography or orchestration is an essential piece of SOA.

There is a lot of hype about SOA.

Management has gotten the message that SOA is good.
Vendors tell them if you want SOA, buy BPEL, or a WS management product.

With the familiar triangle diagram, the third bubble gets out of the way 
and lets the requester and provider exchange messages directly.
Seems like the essential pieces of SOA are a service with an interface 
description (which may include semantics; i.e., may be more than just WSDL, 
but WSDL at a minimum), and messages exchanged between a requester and 
provider.  (Intuitively, its a little hard to conceive of a requester as 
sink for a provider that does an out-only MEP [2], but thats ok).

Everything else is a pattern for using SOA.  Some patterns may position a 
BPEL engine between requesters and providers (a third bubble that does not 
get out of the way), but some realizations of SOA may not use a BPEL 
engine.  Other SOA patterns may include a WS management product that helps 
start up services, monitor them and assists in failover, but otherwise 
allows the requester and provider to interact directly.

So, I am starting to like the idea of "SOA Patterns".  But to talk about 
SOA Patterns, we must be clear what is meant by the minumum essential SOA.

We want management to understand SOA is good.
We also want them to understand that there are different ways to do SOA, 
and start to understand a few "SOA Patterns" well enough to make investment 
decisions about them.


Received on Friday, 30 January 2004 09:56:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:10 UTC