W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

WS-Arch comments re choreography

From: Jon Dart <jdart@tibco.com>
Date: Fri, 09 May 2003 10:22:50 -0700
Message-ID: <3EBBE3EA.4080501@tibco.com>
To: "'public-ws-chor@w3.org '" <public-ws-chor@w3.org>

I have tried here to collect some recent discussion from the www-ws-arch 
list that is relevant to choreography. I have omitted discussion already 
copied to the public-ws-chor list. I have done some editing to pick out 
interesting bits and exercised some editorial judgement re what is 
interesting. (N.b. I probably missed some stuff that should be 
included). As more than one thread is represented here, I'd suggest that 
if you respond, you identify which topic you're responding to.

I would suggest that a possible agenda item for the F2F would be an 
update on WSA from someone more directly involved than I am.


On the definition of choreography:

Francis McCabe:
> Since we are currently editing the WSA spec, we need a placeholder for  
> the notions of Choreography and probably orchestration.
> I propose the following:
> Choreography:
> The pattern of interactions, expressed as a pattern of types of  
> messages, between a set of service requestors and providers. A  
> description of a choreography may include a description of the  
> necessary states that give rise to the particular message patterns.
> In contract, Orchestration would be:
> A mechanism for ensuring that a set of service providers and requestors  
> exchange messages in accordance to a choreography.

(See also followup comments:

On MEPS and their relation to choreography:

> In WS choreography we don't want to describe these MEPs, rather we want 
> to refer to WSDL operations that already describe these MEPs, and we 
> want to let the messaging layer handle the protocol specific MEPs as it 
> sees applicable. So on the one hand we don't want to describe every 
> interaction down to the level of actual messages that have to be 
> sent/received including those that are of no interest to the 
> choreography (like ack/nack, commit/abort, challange/response, etc).

Also on this topic see e.g.
And another Assaf comment on the relation of RM to Choreography:

Geoff Arnold (Sun)
> In the area of web services, we start from a simple base with two 
> models:
> REST, and SOA SOAP+HTTP. Right now there are three developments that we 
> can
> anticipate:
> - multiple types of message transports
> - choreography (which I interpret as MEP composition)
> - multiparty interactions
> Each of these developments will affect the web services model(s) in 
> interesting
> ways; taken together, the consequences are hard to imagine at this 
> point.
> One thing is clear (to me, anyway): the semantics of synchronization and
> coordination will change significantly from what we are discussing 
> today.
> (Consider for example the use cases of an auction, checking 
> creditworthiness,
> and credit card purchase, as well as the various ways these may be way
> composed.)

Interesting comment by Ugo Corda (SeeBeyond) re intermediaries
> In fact, my impression is that so far the area of intermediaries has been investigated very little beyond what the SOAP processing model 
says. As far as I know, most of the new specs currently being worked on 
(security, reliability, choreography, transaction, etc.) say very little 
or nothing at all about intermediaries so far.

Mike Champion re "Interoperability and Fragmentation"

> Some things are beginning to seem a bit clearer to me as a result of recent
> discussion. 
> First, I think that there are some people, perhaps including myself, who had
> an expectation that if we defined a Web service architecture well enough
> that then one could guarantee, or at least hope, that any two Web services
> conformant to that architecture would interoperate. 
> With all respect, I don't think that's what WSA ever tried to do.  We hope
> (hoped?) to provide a framework for  spec writers to write specs that could
> dovetail with one another in an architectural sense.  For example, we could
> never hope to ensure that users of different reliable messaging or
> choreography specs would interoperate, and clearly we do not have the
> authority to ensure that there is One and Only One RM or choreography spec;
> but we can try to promote a situation where the choreography specs aren't
> tied to one and only one RM spec, because that is the road to COM vs CORBA
> all over again.  
> Moreover, I think it's pretty much time to wake up and smell the coffee on
> the fragmentation issue.  Yes, fragmentation is not good.  It is, however, a
> FACT and it doesn't do any good to ignore it.  
>  'Fraid so ... I don't know what to say other than we have to work harder to
> produce something that achieves credibility on its own merits, because
> clearly the industry is not delegating architectural guidance to the W3C.
> (Note the news today that BPEL4WS is going to OASIS for standardization).
> I'm sure the marketing departments are hard at work spinning this, but there
> is some hard work that we are probably in the best position to do to define
> what the properties, relationships, and constraints are in the "boxes"  for
> choroegraphy, business process execution, etc.  so that people can make
> technical analyses of the extent to which whatever OASIS comes up with and
> whatever WS-Choreography comes up with (not to mention the ebXML business
> process stuff!) compete or complement each other.   

Some discussion of how Choreography might fit into the WSA stack diagram
George Blanck
> I believe that you are correct in concluding the multiple purposes behind
> the WSA stack diagram but the statement about the use of a stack diagram as
> runtime relationships is not necessarily true.  The key message behind the
> WSA stack may not be "runtime" but "definitional" relationships.   There
> will be several/many runtime variations of how these components are employed
> but generally within these same structural relationships.  But I would start
> with four boxes and the two pillars very much like Hugo's diagram:
> Label for Box 1. "Processes" (rather than aggregation);  Content: "Examples:
> Discovery, Aggregation, Choreography..."
> Label for Box 2. "Services" (rather than description) Content: WSDL Service
> Descriptions
> Label for Box 3. "Messages"  include two boxes within Box 3a "SOAP
> Extensions" Box 3b: "SOAP"
> label for Box 4. "Transport" Content:  "HTTP, SMTP, JMS..."
> Pillar A: "Security"
> Pillar B: "Management"

Assaf comment re WS-Policy
> I read all the related specifications as one block. My initial impression,
> perhaps because WS-Policy refers specifically to security and privacy, is
> that it was designed primarily to address security. And I assume other
> readers would fall in the same trap.
> On the other hand, I also recieved the impression that WS-Policy is
> "proposing a model which other specifications should follow when addressing
> other problem spaces (e.g. transactions, choreography)".
> I guess that a second reading of the spec in isolation would reveal even
> more hidden treasures ;-)

Mike Champion, thread on Layering in ebXML and WSA.
includes some high-level discussion of how choreography fits in (and 
what it needs to fit in with).
Received on Friday, 9 May 2003 13:22:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC