WS-Arch comments re choreography

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.

--Jon

On the definition of choreography:

Francis McCabe:
http://lists.w3.org/Archives/Public/www-ws-arch/2003May/thread.html
> 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:
http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0036.html,
http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0035.html)

On MEPS and their relation to choreography:

Arkin
http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0054.html
> 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.
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0285.html.
And another Assaf comment on the relation of RM to Choreography:
http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0449.html

Geoff Arnold (Sun)
http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0043.html
> 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
http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0009.html
> 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"
http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0115.html

> 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
http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0046.html
> 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
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0116.html
> 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).
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0087.html

Received on Friday, 9 May 2003 13:22:57 UTC