RE: Typical SOA ... SOA Patterns

It sounds like most of what you identify as "SOA Patterns" is currently
addressed by WS-Chor. Unlike BPEL, WS-Chor does not introduce any new
"bubble", and it's all focused on message exchange patterns among a set
of peer services.

Ugo

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Paul Denning
> Sent: Friday, January 30, 2004 6:55 AM
> To: www-ws-arch@w3.org
> Subject: Typical SOA ... SOA Patterns
> 
> 
> 
> 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.
> 
> [1] 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-ar
ch-review2.html#service_oriented_architecture
[2] 
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-patterns.
html#out-only

Paul

Received on Friday, 30 January 2004 11:26:43 UTC