- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 18 Oct 2002 16:58:17 -0700
- To: "'Champion, Mike'" <Mike.Champion@softwareag-usa.com>, www-ws-arch@w3.org
Mike Some observations on WSCI, BPEL4WS and choreographies. Having reviewed WSCI and BPEL4WS, they both tend to focus on how to sequence processes to carry out a particular activity. As such they tend to focus on "private" processes within the enterprise. What I don't think they do so well, is describe the public processes, often described as choreograhpies, that **constrain** what a private process can do when interacting with services outside of its direct control. I think this is an important distinction as: 1. Public processes need to be standardized, private ones do not. 2. Anything that needs to be standardized should have a formal way of being defined as an aid to understanding and therefore interoperability You also need to distinguish between the generic implementation of a standardized process/choreography and an individual actual implementation. A generic choreography definition just needs to say, for example, ... "if you send me an "order" then you must send me an "order response" back - and really nothing more". I could have said, but didn't ... "if you send me a RosettaNet Order contained as an PKCS7 encrypted attachment on a "SOAP with attachments" message to this URL using HTTP, then I will send you a RosettaNet Order Response in the same format to the URL you specify in return". It's all to do with layering. The generic choreography is a universal business pattern that is independent of how it is implemented, and specifically the service that implements it. If the only way you can define a choreography is as part of defining an actual instance then you will get unnecessary **massive** duplication of choreography definitions. David -----Original Message----- From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com] Sent: Friday, October 18, 2002 3:12 PM To: www-ws-arch@w3.org Subject: RE: Definition of Choreography > -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Friday, October 18, 2002 3:45 PM > To: Cutler, Roger (RogerCutler) > Cc: 'Dave Hollander'; Burdett, David; 'Mark Baker'; Champion, Mike; > www-ws-arch@w3.org > Subject: Re: Definition of Choreography > > > Another +1 from me. Let's see some use cases that > demonstrate why it's important to expose choreographies. > Because as we've seen from these > specs, they're not exactly simple, and if you can accomplish something > without needing to agreeing to new stuff, that reduces coordination > costs (read; reduces cost of doing business). I really, really hope we can stay focussed on identifying the components, connectors, and data that are identified by the BPEL4WS and WSCI specs, determine which of these are important to cover in a Choregraphy spec, and write this up in a way that makes a good case to the W3C AC for chartering a WG to define such a spec. That's what we've agreed to do at the F2F and in response to the request for a tighter scope by the WS CG. Use cases would definitely help in that effort, and I think the "Definition of Choreography" thread has gotten some ideas going. A "devil's advocate" position that this isn't needed is very useful in sharpening our arguments, and Mark does SUCH a good job at it :-) Still, let's not get too distracted by arguing for or against the idea that a Choreography spec is needed -- we already decided that it is! -- and focus on defining what exactly the scope of a Choreography WG would be. When we have a better handle on that, getting pushback helps us make the case, and gets the counter-arguments on the record for the AC's use. To put it another way, I'll feel that we've done our job if we analyze WSCI and BPEL from the WSA framework, make the best case for a new WG, but the AC disagrees. I will NOT feel that we've done our job if we spend the next month arguing about whether to do the analysis or not and then offer nothing to help the AC make their decision.
Received on Friday, 18 October 2002 19:58:18 UTC