- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Wed, 26 Nov 2003 08:33:28 -0800
- To: "Monica J. Martin" <Monica.Martin@Sun.COM>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>, "Steve Ross-Talbot" <steve@enigmatec.net>, <public-ws-chor@w3.org>
Monica, So are you are saying that level 0 should be out of scope? I bet David might be able to derive the opposite conclusion ;-). I suspect we should be much more explicit than that. Ugo > -----Original Message----- > From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] > Sent: Wednesday, November 26, 2003 8:36 AM > To: Ugo Corda > Cc: Burdett, David; Jean-Jacques Dubray; Steve Ross-Talbot; > public-ws-chor@w3.org > Subject: Re: choreography & orchestration must be defined in a context > > > Ugo Corda wrote: > > >Monica, > > > >Thank you for your Requirements quotation, but I am still > not sure what to conclude from that. > > > > > mm1: > > * Choreography 'of web services' only > * Bounding of the abstract level > * Semantic definition outside of WS-Chor > > These all seem to provide some boundaries of our scope, do they not? > > >Ugo > > > > > > > >>-----Original Message----- > >>From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] > >>Sent: Wednesday, November 26, 2003 8:00 AM > >>To: Ugo Corda > >>Cc: Burdett, David; Jean-Jacques Dubray; Steve Ross-Talbot; > >>public-ws-chor@w3.org > >>Subject: Re: choreography & orchestration must be defined > in a context > >> > >> > >>Ugo Corda wrote: > >> > >> > >> > >>>David, > >>> > >>>I agree with you about the existence of all those levels. > What I am > >>>not sure about is whether level 0 is in scope for this > group, given > >>>the fact that the WG is supposed to deal only with Web services. > >>> > >>>For instance, let's take the example of a choreography designed to > >>>describe the interactions of multiple BPEL nodes (which is > the case > >>>that in my view provides the most value right now in a Web > services > >>>context). In that case, all the BPEL endpoints present WSDL > >>> > >>> > >>abstract > >> > >> > >>>interfaces and that is all that is required to describe their > >>>interactions from the choreography point of view. > >>> > >>>Of course, we could go to a higher level (your level 0) and > >>> > >>> > >>abstract a > >> > >> > >>>whole set of choreographies that not only can describe that > >>> > >>> > >>particular > >> > >> > >>>set of BPEL endpoints but can also capture the interactions > >>> > >>> > >>among any > >> > >> > >>>other groups of BPEL nodes that differ from the first > group only by > >>>syntactic definitions of message vocabularies (same semantics). > >>> > >>>I understand there is value in this, I just am not sure we > >>> > >>> > >>should go > >> > >> > >>>that extra mile. I would be interested in hearing what > >>> > >>> > >>other people think. > >> > >> > >>> > >>> > >>> > >>mm1: Is Level 0 within our scope as defined in our mission > >>statement and > >>evolving requirements document? > >> > >>Reference: > >>Introduction in Requirements Document (previous version from > >>SRT): "The > >>description of interactions among Web Services especially > >>with regard to > >>the exchange of messages, their composition, and the > sequences"...... > >>......A choreography description is a multi-party contract that > >>describes the external observable behavior across multiple clients > >>(which are generally Web Services but not exclusively so) in which > >>external observable behavior is defined as the presence or > absence of > >>messages that are exchanged between a Web Service and it's > >>clients..... > >> > >>The only other comment is that originally we had quite a > >>discussion of > >>'human' clients, and I believe this was deemed or questioned > >>to be out > >>of scope. Perhaps we should clarify this in the introduction of the > >>requirements document, in order to put this item to bed. > >> > >>Thanks. > >> > >> > >> > >>>Ugo > >>> > >>> -----Original Message----- > >>> *From:* Burdett, David [mailto:david.burdett@commerceone.com] > >>> *Sent:* Tuesday, November 25, 2003 11:36 PM > >>> *To:* Ugo Corda; Burdett, David; Jean-Jacques Dubray; Steve > >>> Ross-Talbot > >>> *Cc:* Monica J. Martin; public-ws-chor@w3.org > >>> *Subject:* RE: choreography & orchestration must be > defined in a > >>> context > >>> > >>> mmm ... interesting ... > >>> > >>> Firstly I think there is a real need for the "higher level" of > >>> abstraction that I described otherwise, it will result in > >>> unnecessary duplication of choreography definitions. > For example > >>> using the WSDL definition of an abstract interface then > >>> > >>> > >>you could > >> > >> > >>> have: > >>> > >>> * Choreography 1 which consisted of sending an order and > >>> receiving an order response where the schemas were from > >>> RosettaNet, and > >>> * Choreography 2, which was absolutelyu identical > >>> > >>> > >>except that > >> > >> > >>> the order and order response were from RosettaNet. > >>> > >>> Given that you could have hundreds of different order > >>> > >>> > >>document XML > >> > >> > >>> schemas this approach would seem silly. > >>> > >>> So here's my attempt at the different levels of > abstraction that > >>> might be useful > >>> > >>> * Level 0 - completely abstract, i.e. the messages are > >>> identified by a URI and described by a semantic > definition > >>> * Level 1 - concrete schema but abstract wire > >>> > >>> > >>format, e.g. the > >> > >> > >>> order could be a RosettaNet order but how it is > wrapped is > >>> undefined - this is the WSDL abstract level > >>> * Level 2 - concrete schema and concrete wire > >>> > >>> > >>format, e.g. the > >> > >> > >>> order is a RosettaNet order and the envelope is SOAP 1.2 > >>> plus maybe extensions for security and RM > >>> * Level 3 - as level 2 but also extended to identify the > >>> specific instance of a WSDL interface to which > >>> > >>> > >>the messages > >> > >> > >>> are sent as well as other endpoint information > such as the > >>> certificates used for digitally signing the message. > >>> > >>> If you agree with these different levels, then I think that we > >>> need to work out names that describe each level that > >>> > >>> > >>avoid confusion. > >> > >> > >>> > >>> David > >>> > >>> -----Original Message----- > >>> *From:* Ugo Corda [mailto:UCorda@SeeBeyond.com] > >>> *Sent:* Tuesday, November 25, 2003 6:34 PM > >>> *To:* Burdett, David; Jean-Jacques Dubray; Steve > Ross-Talbot > >>> *Cc:* Monica J. Martin; public-ws-chor@w3.org > >>> *Subject:* RE: choreography & orchestration must be > >>> > >>> > >>defined in > >> > >> > >>> a context > >>> > >>> David, > >>> > >>> > >>> > >>>>there are really two different types of choreography: > >>>>An "Abstract" choreography where neither the format (e.g. > >>>> > >>>> > >>> XSD) for the message > >>> > >>> > >>>>nor the interfaces are specified, so transformations are not > >>>> > >>>> > >>> relevant, and > >>> > >>> > >>>>A "Concrete" Choreography, for want of a better word, where > >>>> > >>>> > >>> they are specified, in detail. > >>> At a certain point (hopefully soon) we'll have to reconcile > >>> the WSDL abstract and concrete concepts with the > >>> > >>> > >>ones you are > >> > >> > >>> using. Right now they simply do not match. > >>> > >>> In WSDL, an abstract interface include the definition of a > >>> specific schema. The concrete interface simply maps that > >>> schema to specific on-the-wire bit sequences (that's the so > >>> called binding of the abstract interface - so in > >>> > >>> > >>one binding I > >> > >> > >>> might have a mapping of the XML infoset to plain XML > >>> serialization, in another binding I might have part of the > >>> infoset in XML serialized form and part of it in > >>> > >>> > >>the form of a > >> > >> > >>> MIME multipart attachment, etc.). > >>> > >>> As you can see, your definitions of abstract and > >>> > >>> > >>concrete are > >> > >> > >>> shifted one level above the WSDL definitions (i.e., if we > >>> combine the two definitions we get three levels). > >>> > >>> My initial understanding of WS-Chor goals was that it would > >>> start from the WSDL abstract interface, not from > >>> > >>> > >>the "abstract > >> > >> > >>> choreography" that you define. Whichever way we > >>> > >>> > >>decide to go, > >> > >> > >>> I hope we can get a final decision on this, > >>> > >>> > >>otherwise it will > >> > >> > >>> be hard to communicate because we associate > >>> > >>> > >>different meaning > >> > >> > >>> to the same words. > >>> > >>> Ugo > >>> > >>> -----Original Message----- > >>> *From:* Burdett, David > >>> > >>> > >>[mailto:david.burdett@commerceone.com] > >> > >> > >>> *Sent:* Tuesday, November 25, 2003 6:13 PM > >>> *To:* Ugo Corda; Jean-Jacques Dubray; Steve Ross-Talbot > >>> *Cc:* Monica J. Martin; public-ws-chor@w3.org > >>> *Subject:* RE: choreography & orchestration must be > >>> defined in a context > >>> > >>> Ugo > >>> > >>> You said ... "So I could add a new Web service > >>> > >>> > >>to indicate > >> > >> > >>> the transformation (so that all the interfaces at that > >>> point would match)." > >>> > >>> True, and if you did, then effectively then > >>> > >>> > >>there would be > >> > >> > >>> agreement and whoever was doing the > transformation would > >>> not only need to expose the transformation > >>> > >>> > >>service and not > >> > >> > >>> the service that would receive the message. > >>> > >>> You also said ... "But I might think that it > is too much > >>> detail, and I just want to indicate in the choreography > >>> that it is ok to connect the two mismatching > interfaces, > >>> because some mechanism (to be determined at > >>> > >>> > >>binding time) > >> > >> > >>> will perform the transformation." > >>> > >>> I agree, and as a result there are really two different > >>> types of choreography: > >>> > >>> * An "Abstract" choreography where neither > >>> > >>> > >>the format > >> > >> > >>> (e.g. XSD) for the message nor the interfaces are > >>> specified, so transformations are not > >>> > >>> > >>relevant, and > >> > >> > >>> * A "Concrete" Choreography, for want of a better > >>> word, where they are specified, in detail. > >>> > >>> In the latter case, the sender and the receiver of the > >>> message still have to agree the format that is > >>> > >>> > >>going to go > >> > >> > >>> over the wire as this decision is unavoidable. In this > >>> case, there is still no need to specify what > >>> transformations will occur, or who is going to do them > >>> since presumably sender and receiver would not agree to > >>> use a particular format unless they could each > >>> > >>> > >>handle them. > >> > >> > >>> > >>> Thoughts? > >>> > >>> David > >>> > >>> -----Original Message----- > >>> *From:* Ugo Corda [mailto:UCorda@SeeBeyond.com] > >>> *Sent:* Tuesday, November 25, 2003 5:45 PM > >>> *To:* Burdett, David; Jean-Jacques Dubray; Steve > >>> Ross-Talbot > >>> *Cc:* Monica J. Martin; public-ws-chor@w3.org > >>> *Subject:* RE: choreography & orchestration must be > >>> defined in a context > >>> > >>> David, > >>> > >>> The way I see it, a choreography is > defined in terms > >>> of various WSDL abstract interfaces that are the > >>> senders/recipients of the messages > >>> > >>> > >>exchanged. Each one > >> > >> > >>> of those WSDL abstract interfaces has a specific > >>> schema that describes the format of the documents > >>> exchanged. > >>> > >>> If two end points have to communicate and their > >>> respective WSDL abstract interfaces have a schema > >>> mismatch, then I cannot just indicate in the > >>> choreography that one interface talks to the other, > >>> because they actually cannot. > >>> > >>> So I could add a new Web service to indicate the > >>> transformation (so that all the interfaces at that > >>> point would match). But I might think that > it is too > >>> much detail, and I just want to indicate in the > >>> choreography that it is ok to connect the two > >>> mismatching interfaces, because some > >>> > >>> > >>mechanism (to be > >> > >> > >>> determined at binding time) will perform the > >>> transformation. > >>> > >>> Ugo > >>> > >>> -----Original Message----- > >>> *From:* Burdett, David > >>> [mailto:david.burdett@commerceone.com] > >>> *Sent:* Tuesday, November 25, 2003 5:15 PM > >>> *To:* Ugo Corda; Jean-Jacques Dubray; Steve > >>> Ross-Talbot > >>> *Cc:* Monica J. Martin; public-ws-chor@w3.org > >>> *Subject:* RE: choreography & > orchestration must > >>> be defined in a context > >>> > >>> JJ & Ugo > >>> > >>> I still don't see why you need > transformation at > >>> the choreography level. For example, > >>> > >>> > >>suppose that: > >> > >> > >>> 1. Company A can generate SAP orders > >>> > >>> > >>from its ERP > >> > >> > >>> system > >>> 2. Company B can accept Oracle Financial orders > >>> into its ERP system. > >>> > >>> In this case, the interoperability is > >>> > >>> > >>not possible > >> > >> > >>> without some transformation. This can > >>> > >>> > >>be solved in > >> > >> > >>> three basic ways: > >>> 1. Company A transforms their SAP orders into > >>> Oracle Financial format before sending to B > >>> 2. Company A sends SAP orders to B. > Then, when B > >>> receives the order it transfomrs it into the > >>> Oracle financials format > >>> 3. Company A transforms the SAP orders > into some > >>> neutral format, e.g. UBL before sending > >>> > >>> > >>to B. Then > >> > >> > >>> B transforms the UBL order to Oracle Financial > >>> format when received. > >>> > >>> Firstly, in all these cases there has to be > >>> agreement between A and B over what > >>> > >>> > >>format will be > >> > >> > >>> sent over the wire. Secondly, the > >>> > >>> > >>transformations > >> > >> > >>> are always done by one, the other or > both of the > >>> participants. Thirdly, the format of > >>> > >>> > >>the documents > >> > >> > >>> being sent does not alter the sequence in which > >>> they are sent and therefore does not alter the > >>> choreography. > >>> > >>> Given the variety of different formats > >>> > >>> > >>that exist, > >> > >> > >>> and the multiple different ways and places in > >>> which transformation can be done, would it be > >>> better to have a single choreography definition > >>> that is independent of transformation > >>> > >>> > >>requirements > >> > >> > >>> and then: > >>> 1. The participants in the choreography could > >>> search for a choreography that > >>> > >>> > >>specifies a format > >> > >> > >>> for the documents that they can both, either > >>> directly or indirectly, generate/accept. > >>> 2. They could then agree to use that > >>> > >>> > >>choreography, and > >> > >> > >>> 3. They could each, independently of > each other, > >>> work out the private choreographies that they > >>> would follow. > >>> > >>> What am I not understanding? > >>> > >>> David > >>> > >>> > >>> > >>> -----Original Message----- > >>> *From:* Ugo Corda > >>> > >>> > >>[mailto:UCorda@SeeBeyond.com] > >> > >> > >>> *Sent:* Monday, November 24, 2003 12:55 PM > >>> *To:* Jean-Jacques Dubray; Steve > Ross-Talbot > >>> *Cc:* Burdett, David; Monica J. Martin; > >>> public-ws-chor@w3.org > >>> *Subject:* RE: choreography & orchestration > >>> must be defined in a context > >>> > >>> JJ, > >>> > >>> I agree with your position on > >>> > >>> > >>transformations. > >> > >> > >>> I think they play a very important role in > >>> many choreographies, and should be > expressed > >>> at the choreography language level. > >>> > >>> A transformation specified at the > >>> > >>> > >>choreography > >> > >> > >>> level can, of course, be > implemented in many > >>> different ways, going from hard-coded XSLT > >>> transforms to a full ontology-based system > >>> that automatically transforms from > >>> > >>> > >>one format > >> > >> > >>> to another based on some semantics > >>> > >>> > >>reasoning. > >> > >> > >>> The actual implementation would > >>> > >>> > >>correspond to > >> > >> > >>> a specific binding of the choreography. > >>> > >>> Ugo > >>> > >>> -----Original Message----- > >>> *From:* Jean-Jacques Dubray > >>> [mailto:jeanjadu@Attachmate.com] > >>> *Sent:* Monday, November 24, > >>> > >>> > >>2003 11:41 AM > >> > >> > >>> *To:* 'Steve Ross-Talbot' > >>> *Cc:* Burdett, David; Ugo > >>> > >>> > >>Corda; Monica J. > >> > >> > >>> Martin; public-ws-chor@w3.org > >>> *Subject:* RE: choreography & > >>> orchestration must be defined > >>> > >>> > >>in a context > >> > >> > >>> Steve: > >>> > >>> >>I agree with your layering and the > >>> relationships between a > >>> > >>> > >>BPEL-like language > >> > >> > >>> and a WS-CDL-like language. This > >>> >>is indeed how WS-CHOR sees > things too. > >>> I was also under this impression but I > >>> felt that it was not clear in > >>> > >>> > >>the mind of > >> > >> > >>> many people outside the ws-chor > >>> > >>> > >>working group. > >> > >> > >>> >>I shall give more thought to > >>> > >>> > >>a BPDL. One > >> > >> > >>> thing that I am interested to > understand > >>> is the role of business rules > >>> >>and business contraints and > that whole > >>> genre of AI-like technology to > this BPDL > >>> space. I am interested in two > >>> >>main aspects: > >>> > >>> >> Business processes encoded as > >>> rules and constraints > >>> >> Business policies (i.e. SLA's) > >>> encoded as rules and constraints > >>> >> The relationship to current BPM > >>> standards and standards-to-be. > >>> > >>> As you state the problem that way, we > >>> might realize that there must > not be one > >>> BPDL in the future but a few different > >>> types based on what it being modeled. > >>> > >>> I think we would collectively > >>> > >>> > >>be making a > >> > >> > >>> lot of progress if enough people would > >>> stand up and explain clearly > the current > >>> layering orchestration, > choreography and > >>> business process. (note that I believe > >>> that coordination and transaction fit > >>> somewhere in the picture but > >>> > >>> > >>did not have > >> > >> > >>> time to articulate it). > >>> > >>> The business process space is extremely > >>> complex. The work done around > >>> > >>> > >>XRL by Prof. > >> > >> > >>> van der Aalst, Papazoglou and > Kumar, the > >>> notion of meta-workflow, ... are a > >>> brilliant example of the variety of > >>> business rules and constraints that are > >>> needed to express even the most trivial > >>> (but real) use cases. IMHO, the current > >>> BPM standards (i.e. BPEL and BPML) are > >>> simply (excellent) > >>> > >>> > >>orchestration standards > >> > >> > >>> (again if I take van der Aalst, > >>> > >>> > >>Papazoglou > >> > >> > >>> and Kumar's work as a point of > >>> > >>> > >>reference). > >> > >> > >>> IMHO, (if we all believe in > >>> > >>> > >>this layering) > >> > >> > >>> the ws-chor working group > >>> > >>> > >>should make sure > >> > >> > >>> that the choreography language > >>> > >>> > >>is capable > >> > >> > >>> of supporting higher level business > >>> process definitions including > >>> > >>> > >>XRL and next > >> > >> > >>> generation of BPML. The idea is not to > >>> bring the kind of rules or > flexibility a > >>> BPDL would need, but have > >>> > >>> > >>enough in terms > >> > >> > >>> of expressing message exchanges for BP > >>> definitions. > >>> > >>> As I said earlier, having the notion of > >>> domain of control somewhere can > >>> > >>> > >>be helpful. > >> > >> > >>> Let me try on more time to talk about > >>> transformation. I think I did > >>> > >>> > >>not express > >> > >> > >>> myself correctly. We talked with David > >>> about transformation being > something you > >>> specify at binding time (role -> > >>> participant). Actually, as you traverse > >>> the boundary of a domain of > control, you > >>> need transformation, outside > the context > >>> of a binding. The > >>> > >>> > >>transformation is needed > >> > >> > >>> because what you send to be > >>> > >>> > >>consumed by a > >> > >> > >>> domain, may not be what one of > >>> > >>> > >>its service > >> > >> > >>> might be able to consumer. I hope this > >>> clarifies a bit more the need for > >>> transformation. > >>> > >>> Cheers, > >>> > >>> JJ- > >>> > >>> On Wednesday, November 19, > >>> > >>> > >>2003, at 11:06 > >> > >> > >>> pm, Jean-Jacques Dubray > >>> wrote: > >>> > >>> > Steve: > >>> > > >>> > I was talking of WS-CDL as > >>> > >>> > >>the output of > >> > >> > >>> the WS-CHOR working group, > >>> > when it becomes available. I have no > >>> idea if it has been named that > >>> > way. I thought that I had saw you > >>> recently using this term. > >>> > > >>> > I am convinced that WS-CDL (as an > >>> output) is the right level upon > >>> > which Business Process Definition > >>> Language(s) can be built. Again, I > >>> > wrote a paper in the summer 2002 > >>> substantiating this claim. > >>> > > >>> > The whole debate started > around pi for > >>> workflow, business process, > >>> > then moved to business process versus > >>> orchestration, choreography, ... > >>> > Then we heard that pi makes > >>> > >>> > >>choreography > >> > >> > >>> as a concept irrelevant... > >>> > > >>> > Again my points are: > >>> > 1) orchestration and choreography are > >>> complementary as the "what" is > >>> > being composed and "how" they > >>> > >>> > >>are composed > >> > >> > >>> > 2) orchestration and choreography > >>> languages (that I can refer > >>> > occasionaly as BPEL and WS-CDL) are > >>> different from business process > >>> > definition languages > >>> > (BPDLs) > >>> > 3) BPDL(s) should be layers on top of > >>> WS-CDL(s) > >>> > 4) Protocols such as transaction or > >>> business transaction protocols > >>> > should also be layered on top > >>> > >>> > >>of WS-CDL(s) > >> > >> > >>> > 5) In order to do 3) and maybe 4) the > >>> current set of requirements, > >>> > scope and objectives of > >>> > >>> > >>WS-CHOR working > >> > >> > >>> group are lacking IMHO 3 > >>> > things (maybe more), > >>> > a) the ability to express > >>> transformations along with the > >>> > message definition (ideally > >>> transformation are expressed from the > >>> > consumer point of view to reach > >>> the maximum level of decoupling) > >>> > b) the ability to > express simple > >>> routing rules between > >>> > nodes, again to acheive a good > >>> level of decoupling > >>> > c) the ability to express the > >>> ability to define domains > >>> > of control to which a > >>> > >>> > >>message can > >> > >> > >>> be sent. The domain may then > >>> > implement special rules > >>> > >>> > >>to route a > >> > >> > >>> message sent to the domain, to a > >>> > particular node. > >>> > > >>> > I view a), b) c) not as execution per > >>> say but as an "active" > >>> > choreography. > >>> > > >>> > I hope that helps clarify, I am sorry > >>> for the confusion. > >>> > > >>> > Jean-Jacques > >>> > tel: 425-649-6584 > >>> > Cell: 508-333-7634 > >>> > > >>> > -----Original Message----- > >>> > From: Steve Ross-Talbot > >>> [mailto:steve@enigmatec.net] > >>> > Sent: Wednesday, November 19, > >>> > >>> > >>2003 12:14 AM > >> > >> > >>> > To: Burdett, David > >>> > Cc: Jean-Jacques Dubray; 'Ugo Corda'; > >>> Monica J. Martin; > >>> > public-ws-chor@w3.org > >>> > Subject: Re: choreography & > >>> orchestration must be defined > >>> > >>> > >>in a context > >> > >> > >>> > > >>> > JJ, > >>> > > >>> > Hmmmm it's getting tricky to > >>> > >>> > >>figure out > >> > >> > >>> who said what to whom. > >>> > The piece I wish to comment on is the > >>> last piece from (I think) JJ > >>> > that talks about what a > >>> > >>> > >>WS-CDL lacks (or > >> > >> > >>> is missing) and also > >>> > references the pi-calculus. > I have put > >>> my comments in-line. > >>> > > >>> > Cheers > >>> > > >>> > Steve T > >>> > > >>> > > >>> > On Tuesday, November 18, > >>> > >>> > >>2003, at 10:50 > >> > >> > >>> pm, Burdett, David wrote: > >>> > > >>> >> JJ > >>> >> > >>> >> I don't think we are as far apart in > >>> our thinking as you suggest - > >>> >> comments inline. > >>> >> > >>> >> David > >>> >> > >>> >> -----Original Message----- > >>> >> From: Jean-Jacques Dubray > >>> [mailto:jeanjadu@Attachmate.com] > >>> >> Sent: Tuesday, November 18, > >>> > >>> > >>2003 1:49 PM > >> > >> > >>> >> To: 'Burdett, David'; 'Ugo Corda'; > >>> Monica J. Martin; Steve > >>> >> Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> David: > >>> >> > >>> >> thanks for forwarding this > >>> > >>> > >>definition, > >> > >> > >>> however, I cannot disagree > >>> >> more with the association of > >>> "orchestration" and "business process". > >>> >> If a business process > >>> > >>> > >>language were to > >> > >> > >>> be defined one day, it will be > >>> >> layered on top of a choreography > >>> language as (as you put it yourself) > >>> >> a co-operation of "orchestration > >>> nodes". The fact that you talk about > >>> >> orchestration nodes > >>> >> (plural) participating in a business > >>> process and you say that the > >>> >> business process is an > >>> > >>> > >>orchestration is > >> > >> > >>> antinomic. > >>> >> </DavidBurdett> What I think I am > >>> really saying is that Orchestration > >>> >> occurs when a single entity > >>> > >>> > >>can define > >> > >> > >>> what happens without there > >>> >> being any need for cooperation with > >>> others. Sometimes, these > >>> >> orchestrations could define > >>> > >>> > >>a complete > >> > >> > >>> business process, but they > >>> >> will not always. Sometimes, > >>> > >>> > >>as you say, > >> > >> > >>> the implementation of a > >>> >> business process will require > >>> cooperation with others businesses. > >>> >> However this cooperation is > >>> > >>> > >>limited to > >> > >> > >>> how those business processes > >>> >> interact. The owner of the business > >>> process will still have a lot of > >>> >> control over how they carry > out major > >>> parts of their business process. > >>> >> For example if a business defines a > >>> process that allows placement of > >>> >> orders, then you could imagine it > >>> consisting of a number of steps: > >>> >> 1. Determine demand for a product - > >>> this is strictly internal and > >>> >> private to the busines 2. If more > >>> product is required then - this is > >>> >> also strictly a private decision 3. > >>> Place an order with the supplier > >>> >> - how this is done is NOT > >>> > >>> > >>private as it > >> > >> > >>> depends on the buyer and > >>> >> supplier agreeing how the > >>> > >>> > >>order will be > >> > >> > >>> placed. > >>> >> So I would say that steps 1 > through 3 > >>> are all part of a private > >>> >> process and would be > defined using an > >>> Orchestration Language as there > >>> >> is clearly one entity in contorl. > >>> However, one part of the process > >>> >> (step 3) must conform to a > previously > >>> agreed definition which is > >>> >> where the choreography > >>> > >>> > >>definition comes > >> > >> > >>> in.</DavidBurdett> > >>> >> > >>> >> > >>> >> Yes I totally agree that there are > >>> ochestration nodes, of course, > >>> >> these nodes represent the "things" > >>> where the activities of "the > >>> >> business process" > >>> >> are performed. > >>> >> > >>> >> Business processes that map > >>> > >>> > >>to a single > >> > >> > >>> orchestration node are the > >>> >> exception rather than the > rule. These > >>> type of orchestration > >>> >> definitions require that > all units of > >>> work/activites be modeled as a > >>> >> web service (with request/response > >>> operations). They also create de > >>> >> facto a "center" of business > >>> > >>> > >>processes > >> > >> > >>> which does not exist in > >>> >> reality, we all know that. > >>> >> <DavidBurdett> I would disagree that > >>> single orchestration nodes are > >>> >> the exception. They are as common as > >>> business processes that involve > >>> >> multiple nodes where a single > >>> orchestration node is at the end of the > >>> >> branches of a business > >>> > >>> > >>process as in ... > >> > >> > >>> >> BP1 consists of > >>> >> - BP2 which consists of > >>> >> - BP3 which consists of > >>> >> - Orchestration 4, and > >>> >> - Orchestration 5, with > >>> >> -Orchestration 6 > >>> >> </DavidBurdett> > >>> >> These are 2001 concepts, > >>> > >>> > >>in 2003, we > >> > >> > >>> are thinking of service > >>> >> oriented architectures. We finally > >>> realized that units of > >>> >> work/activities cannot be modeled as > >>> request/responses but rather as > >>> >> orchestrated nodes that co-operate > >>> within a business > >>> >> process.<DavidBurdett> I > >>> > >>> > >>totally agree. > >> > >> > >>> >> However, at the lowest > >>> > >>> > >>level, you will > >> > >> > >>> have either request-responses > >>> >> or one-way messages.</DavidBurdett> > >>> There is no center to a business > >>> >> process, therefore a single > >>> orchestration engine cannot be used for > >>> >> that. <DavidBurdett> This is > >>> > >>> > >>sometimes > >> > >> > >>> true, but not > >>> >> always.</DavidBurdett> > >>> >> > >>> >> Please take a look at this > >>> > >>> > >>presentation > >> > >> > >>> I am giving next week: > >>> >> > >>> > >>> > >>> > >><http://www.ebpml.org/technoforum_2003_b_eng.ppt> > >> > >> > >>> >> > >>> > >>> > >>> > >>http://www.ebpml.org/technoforum_2003_b_eng.ppt > >> > >> > >>> it gives a detailed > >>> >> definition of orchestration and > >>> choreography as well as collaboration > >>> >> (sorry I did not have time to put > >>> coordination in the mix but it is > >>> >> coming). > >>> >> <DavidBurdett>I've looked at your > >>> presentation and I really like it > >>> >> and agree with it totally > in terms of > >>> what you are saying. I think > >>> >> that, in the article, I > used the term > >>> Business Process Language as a > >>> >> shorthand for BPEL which I think is > >>> what you would call an > >>> >> orchestration language - is that > >>> right?</DavidBurdett> > >>> >> > >>> >> I also published this paper in the > >>> summer of 2002 that expresses a > >>> >> business process as a multiparty > >>> collaboration of orchestrated nodes > >>> >> ( http://www.ebpml.org/ebpml2.2.doc > >>> >> <http://www.ebpml.org/ebpml2.2.doc> > >>> >> ). > >>> >> This approach enables the > >>> > >>> > >>definition of > >> > >> > >>> end-to-end processes either > >>> >> within or even beyond corporation > >>> boundaries if needed. It also > >>> >> provide a seemless model to go from > >>> public business processes to > >>> >> private business processes > since both > >>> are a co-operation of nodes. > >>> >> > >>> >> Neither BPEL or WS-CDL have any > >>> business semantics to reach the level > >>> >> of business process > >>> > >>> > >>definitions we all > >> > >> > >>> know that. However, they > >>> >> provide the substrate or the > >>> > >>> > >>foundation > >> > >> > >>> upon which a business process > >>> >> definition can be specified. > >>> >> > >>> >> WS-CDL also lacks three > >>> > >>> > >>concepts (that > >> > >> > >>> I know of) to be able create a > >>> >> business process definition language > >>> (BPDL is not yet taken by any > >>> >> spec): > >>> >> a) WS-CDL lacks the ability > >>> > >>> > >>to express > >> > >> > >>> transformations along with the > >>> >> message definition (ideally > >>> transformation are expressed from the > >>> >> consumer point of view to reach the > >>> maximum level of decoupling) > >>> >> b) WS-CDL lacks the ability > >>> > >>> > >>to express > >> > >> > >>> simple routing rules between > >>> >> nodes, again to acheive a > >>> > >>> > >>good level of > >> > >> > >>> decoupling > >>> >> c) WS-CDL lacks the ability > >>> > >>> > >>to express > >> > >> > >>> the ability to define domains > >>> >> of control to which a message can be > >>> sent. The domain may then > >>> >> implement special rules to route a > >>> message sent to the domain, to a > >>> >> particular node. > >>> >> If we had c) we may not need > >>> > >>> > >>b). There > >> > >> > >>> is a very obvious domain of > >>> >> control, it is called a company > >>> boundary, but I think the concept > >>> >> would be useful even within > >>> > >>> > >>a company. > >> > >> > >>> >> > >>> > > >>> > SRT> Firstly no such thing > as a WS-CDL > >>> exists today. An editing team > >>> > has been appointed and two > >>> > >>> > >>contributions > >> > >> > >>> > SRT> received. A > requirements document > >>> is nearing it's second > >>> > publication (more of this > >>> > >>> > >>later). So to > >> > >> > >>> use the term > >>> > SRT> WS-CDL as if it has been created > >>> and so comment on it having this > >>> > feature and not having that > feature is > >>> > SRT> speculative at best. > >>> > SRT> > >>> > SRT> Secondly it is very easy to say > >>> that some specific language lacks > >>> > things when you take that > language out > >>> of context. > >>> > SRT> According to the mission > >>> > >>> > >>statement > >> > >> > >>> of WS-CHOR and according to > >>> > SRT> the > >>> > unpublished draft of the requirements > >>> document > >>> > SRT> which I am fortunate to > >>> > >>> > >>have seen, > >> > >> > >>> it is clear that a WS-CDL is > >>> > *not* seeking to be an executable > >>> language and so (a) and (b) > >>> > SRT> will be out of scope. > >>> > SRT> > >>> > SRT> A WS-CDL, as far as I am > >>> > >>> > >>concerned > >> > >> > >>> as a member, is a > >>> > SRT> specification > >>> > language. It's aim is to describe > >>> > SRT> the external observable > behaviour > >>> and not actively police it. > >>> > SRT> What > >>> > a WS-CDL does is describe the > >>> > SRT> external observable behaviour of > >>> multi-party interaction where no > >>> > one party has overall control - > >>> > SRT> hence the use of the term > >>> peer-to-peer. WS-CDL is likely to have > >>> > some concept of participant and > >>> > SRT> that notion may be akin > >>> > >>> > >>to a domain > >> > >> > >>> of control but it is not a > >>> > statically bound concept (others may > >>> > SRT> wish to comment here). > >>> > SRT> > >>> > > >>> >> > >>> >> All these concepts are not > in pi so I > >>> am not surprised they don't > >>> >> show up in WS-CDL or BPEL. However, > >>> they are essential to achieve the > >>> >> level of SOA, without them, > we cannot > >>> start building a BPDL. > >>> > > >>> > SRT> > >>> > SRT> Yes you are correct that no > >>> construct in the pi-calculus can be > >>> > said to match directly to the (a) (b) > >>> and (c) above. > >>> > SRT> I don't see why it is helpful or > >>> insightful to mention this. It's > >>> > a bit like saying that because a > >>> language only has > >>> > SRT> loops it cannot express > >>> > >>> > >>recursion. > >> > >> > >>> The pi-calculus can be used to > >>> > encode (a), (b) and (c) just as any > >>> programming > >>> > SRT> language can and just as lamba > >>> calculus can. Of course we would > >>> > not wish to do so expect to show some > >>> formal > >>> > SRT> semantics about these constructs > >>> and reason over them in > >>> > particular ways. So I don't really > >>> understand the pervious > >>> > SRT> comment and what you are > >>> > >>> > >>trying to > >> > >> > >>> say. > >>> > SRT> > >>> > SRT> As regards WS-CDL I have made it > >>> clear that it doesn't exist yet > >>> > so it is premature to suggest what is > >>> and is not a feature > >>> > SRT> of a WS-CDL. As far as BPEL is > >>> concerned BPEL is not based on > >>> > pi-calculus. Indeed several member of > >>> the TC have > >>> > SRT> asked for some pointers on > >>> formalisms that underpin BPEL and have > >>> > yet to see anything. > >>> > SRT> > >>> > > >>> >> <DavidBurdett>All these > >>> > >>> > >>ideas are very > >> > >> > >>> necessary and useful before we > >>> >> can get to the > >>> > >>> > >>interoperability Nirvana > >> > >> > >>> we want to reach. However we > >>> >> are now getting into scope issues. > >>> Should the WS Choreography group > >>> >> describe how you do transformations, > >>> how you do routing, how you do > >>> >> security, how you do reliable > >>> messaging, how identify a message, etc > >>> >> - all of these are > necessary. I don't > >>> think so. What we really need > >>> >> to do is allow these > >>> > >>> > >>specifications to > >> > >> > >>> be separately specified then > >>> >> work out how they are going > >>> > >>> > >>to be used > >> > >> > >>> together.</DavidBurdett> > >>> >> > >>> >> If you use an orchestration engine > >>> between "nodes" you are doing EAI > >>> >> or integration scenarios, a very > >>> particular form of SOA. (see this > >>> >> article that explains why ESB is > >>> different from SOA: > >>> >> <http://www.ebpml.org/indigo.htm> > >>> >> http://www.ebpml.org/indigo.htm) > >>> >> <DavidBurdett>I wasn't > >>> > >>> > >>suggesting this. > >> > >> > >>> I was suggesting that between > >>> >> the nodes, you do need to define how > >>> they will cooperate - this is > >>> >> the choreography. I think the > >>> misunderstanding is that I tended to > >>> >> use the definition of a business > >>> process as being specific to an > >>> >> individual role, e.g. a Buyer, OR a > >>> Seller, whereas I think that you > >>> >> also consider the process > >>> > >>> > >>that involves > >> > >> > >>> the Buyer AND the Seller as a > >>> >> business process where no one is in > >>> control. This is technically > >>> >> correct, however, largely because of > >>> BPEL, I think that people think > >>> >> that business processes are > >>> > >>> > >>within the > >> > >> > >>> enterprise.</DavidBurdett> > >>> >> > >>> >> Cheers, > >>> >> > >>> >> Jean-Jacques > >>> >> tel: 425-649-6584 > >>> >> Cell: 508-333-7634 > >>> >> > >>> >> > >>> >> > >>> >> _____ > >>> >> > >>> >> From: Burdett, David > >>> [mailto:david.burdett@commerceone.com] > >>> >> Sent: Tuesday, November 18, > >>> > >>> > >>2003 12:43 PM > >> > >> > >>> >> To: 'Ugo Corda'; Burdett, David; > >>> Jean-Jacques Dubray; Monica J. > >>> >> Martin; > >>> >> Steve Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> Ugo > >>> >> > >>> >> I think we might be getting confused > >>> over the definition of terms. I > >>> >> would saythat an "orchestration > >>> language" defines what an > >>> >> "orchestration node" > >>> >> does. I would use the term > >>> "choreography language" to > >>> > >>> > >>define the ways > >> > >> > >>> >> in which independently > controlled and > >>> managed "orchestration nodes" > >>> >> should > >>> >> co-operate. I agree though that this > >>> co-oepration can be determined > >>> >> by other means. > >>> >> > >>> >> I also think that we are basically > >>> agreeing ;) > >>> >> > >>> >> David > >>> >> > >>> >> -----Original Message----- > >>> >> From: Ugo Corda > >>> [mailto:UCorda@SeeBeyond.com] > >>> >> Sent: Tuesday, November 18, > >>> > >>> > >>2003 12:19 PM > >> > >> > >>> >> To: Burdett, David; Jean-Jacques > >>> Dubray; Monica J. Martin; Steve > >>> >> Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> David, you say: > >>> >> > >>> >>> With an orchestration, someone (or > >>> something) is definitely in > >>> >>> control, so > >>> >> cooperation is not needed - > >>> > >>> > >>which makes > >> > >> > >>> life much easier. > >>> >> > >>> >> I think this would only apply to the > >>> case where the orchestration Web > >>> >> service only interacts with > other Web > >>> services that do not themselves > >>> >> contain an orchestration. > But in many > >>> situations the system includes > >>> >> more than one single orchestration > >>> node, so that some type of > >>> >> cooperation among all those > >>> orchestration nodes is indeed required > >>> >> (otherwise nothing would work). As I > >>> said before, such cooperation > >>> >> can be expressed via an > orchestration > >>> language, but it could be > >>> >> achieved by other means. > >>> >> > >>> >> Ugo > >>> >> > >>> >> > >>> >> > >>> >> -----Original Message----- > >>> >> From: Burdett, David > >>> [mailto:david.burdett@commerceone.com] > >>> >> Sent: Tuesday, November 18, > >>> > >>> > >>2003 11:31 AM > >> > >> > >>> >> To: 'Jean-Jacques Dubray'; > Ugo Corda; > >>> Monica J. Martin; Steve > >>> >> Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> Just to contribute my $0.02c to this > >>> discussion ... here's an extact > >>> >> from an article of mine that will be > >>> published in December's Web > >>> >> Services > >>> >> Journal: > >>> >> > >>> >> A business process > >>> > >>> > >>definition (i.e. an > >> > >> > >>> Orchesteration) describes how > >>> >> internal, private business processes > >>> work - for example the Sales > >>> >> Order Management process where a > >>> business uses its sales management > >>> >> system, stock management > >>> > >>> > >>system and its > >> > >> > >>> fulfillment system to satisfy > >>> >> orders that the business > receives. In > >>> this case, the business > >>> >> handling those orders is in complete > >>> control of how those internal > >>> >> and external systems are > >>> > >>> > >>integrated and > >> > >> > >>> combined with existing manual > >>> >> processes. > >>> >> > >>> >> > >>> >> > >>> >> Choreography definitions, on > >>> > >>> > >>the other > >> > >> > >>> hand, define how one > >>> >> "independent" > >>> >> business or process interacts with > >>> another, by defining the sequence > >>> >> and conditions in which messages are > >>> exchanged between them. In this > >>> >> latter case no single business or > >>> process is in control so each has > >>> >> to agree with the other how to > >>> cooperate. For example if a buyer > >>> >> sends a supplier an order, > >>> > >>> > >>the supplier > >> > >> > >>> needs to know how to respond. > >>> >> Should they: a) return an order > >>> response indicating the extent to > >>> >> which they can meet the > >>> > >>> > >>order, b) just > >> > >> > >>> ship the goods and send an > >>> >> invoice or c) do something > different. > >>> No single business can > >>> >> unilaterally decide what do without > >>> informing, and getting the > >>> >> agreement of, the other businesses > >>> involved. > >>> >> > >>> >> > >>> >> > >>> >> As I think Ugo said, the key > >>> > >>> > >>difference > >> > >> > >>> to my mind is that a > >>> >> choreography defines how two or more > >>> processes COOPERATE as no one is > >>> >> in control. > >>> >> With an > >>> >> orchestration, someone (or > something) > >>> is definitely in control, so > >>> >> cooperation is not needed - > >>> > >>> > >>which makes > >> > >> > >>> life much easier. > >>> >> > >>> >> > >>> >> > >>> >> David > >>> >> > >>> >> -----Original Message----- > >>> >> From: Jean-Jacques Dubray > >>> [mailto:jeanjadu@Attachmate.com] > >>> >> Sent: Saturday, November 15, > >>> > >>> > >>2003 1:39 PM > >> > >> > >>> >> To: 'Ugo Corda'; Monica J. Martin; > >>> Steve Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> well, I am not sure your > >>> > >>> > >>assessment is > >> > >> > >>> correct with respect to the > >>> >> direction the ws-stack is > growing but > >>> I'll refrain from any further > >>> >> comments ;-) > >>> >> > >>> >> > >>> >> Jean-Jacques > >>> >> tel: 425-649-6584 > >>> >> Cell: 508-333-7634 > >>> >> > >>> >> > >>> >> _____ > >>> >> > >>> >> From: Ugo Corda > >>> [mailto:UCorda@SeeBeyond.com] > >>> >> Sent: Saturday, November 15, > >>> > >>> > >>2003 10:52 AM > >> > >> > >>> >> To: Jean-Jacques Dubray; Monica J. > >>> Martin; Steve Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> I think the problem you > describe is a > >>> direct derivation from the fact > >>> >> that the WS stack is being built > >>> bottom-up. We all know there are > >>> >> pros and cons for both bottom-up and > >>> top-down. The risk of isolation > >>> >> and lack of higher context > >>> > >>> > >>is usually a > >> > >> > >>> shortcoming of the bottom-up > >>> >> approach, and extra effort > >>> > >>> > >>needs to be > >> > >> > >>> spent to overcome it. > >>> >> > >>> >> Ugo > >>> >> > >>> >> -----Original Message----- > >>> >> From: Jean-Jacques Dubray > >>> [mailto:jeanjadu@Attachmate.com] > >>> >> Sent: Saturday, November 15, > >>> > >>> > >>2003 10:37 AM > >> > >> > >>> >> To: Ugo Corda; Monica J. > >>> > >>> > >>Martin; Steve > >> > >> > >>> Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> Yes, I guess, this is why it is > >>> important to clearly define the > >>> >> context(s) > >>> >> in which choreography applies, its > >>> relationship to other concepts > >>> >> such as orchestration, composition, > >>> coordination, protocols and > >>> >> collaboration, and define > its purpose > >>> in life, e.g : > >>> >> 1) choreography can support the > >>> specification of n-party > >>> >> a) protocols > >>> >> b) collaborations > >>> >> 2) choreography can validate complex > >>> orchestration implementation > >>> >> (#peers > > >>> >> 3) > >>> >> ... > >>> >> > >>> >> I personally donc think that any of > >>> these concepts can be used in > >>> >> isolation of each other > >>> > >>> > >>except for very > >> > >> > >>> trivial cases. There is a > >>> >> need to objectively align all these > >>> specifications which are today > >>> >> still mostly work in progress. > >>> >> > >>> >> Jean-Jacques > >>> >> tel: 425-649-6584 > >>> >> Cell: 508-333-7634 > >>> >> > >>> >> > >>> >> > >>> >> _____ > >>> >> > >>> >> From: Ugo Corda > >>> [mailto:UCorda@SeeBeyond.com] > >>> >> Sent: Saturday, November 15, > >>> > >>> > >>2003 10:26 AM > >> > >> > >>> >> To: Jean-Jacques Dubray; Monica J. > >>> Martin; Steve Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: RE: choreography & > >>> orchestration must be defined in a > >>> >> context > >>> >> > >>> >> > >>> >> JJ, > >>> >> > >>> >>> In a SOA, Orchestration > >>> > >>> > >>cannot be used > >> > >> > >>> to describe the global, peer > >>> >>> to > >>> >> peer message exchange. > >>> >>> The reason is simple: orchestration > >>> assumes that there is a > >>> >>> "center", i.e. > >>> >> where the orchestration engine is. > >>> >>> In a SOA, there is no center, peers > >>> talk to each other arbitrarily > >>> >>> (see > >>> >> the links below). > >>> >>> Forcing all the messages to > >>> > >>> > >>go through > >> > >> > >>> a center would IMHO be an > >>> >> architectural mistake, > >>> >>> and I don't think anyone is > >>> > >>> > >>suggesting > >> > >> > >>> that. The "center" of an SOA > >>> >>> looks > >>> >> more like a "fabric" or a "grid". > >>> >> > >>> >> As you say, I don't think anyone is > >>> suggesting that in the > >>> >> orchestration view of > things there is > >>> only one center. There are many > >>> >> "centers", one for each > "orchestrated > >>> service" in the SOA, > >>> >> corresponding to many orchestration > >>> engines. > >>> >> > >>> >> The real issue is how these various > >>> orchestrations and corresponding > >>> >> engines harmonize and > >>> > >>> > >>cooperate. In the > >> > >> > >>> orchestration approach, that > >>> >> is left to be defined "out of band" > >>> (i.e. is not part of what > >>> >> orchestration itself describes). The > >>> way this "out of band" work is > >>> >> done can vary. Using a choreography > >>> language is evidently a way, but > >>> >> other less formal ways are also > >>> conceivable (e.g. the same designer > >>> >> develops all the orchestrations; > >>> different designers work closely > >>> >> together - a la extreme > programming - > >>> when developing each individual > >>> >> orchestration; etc.) and potentially > >>> appropriate depending on the > >>> >> environment in which the SOA > >>> > >>> > >>is developed. > >> > >> > >>> >> > >>> >> Ugo > >>> >> > >>> >> -----Original Message----- > >>> >> From: Jean-Jacques Dubray > >>> [mailto:jeanjadu@Attachmate.com] > >>> >> Sent: Saturday, November 15, > >>> > >>> > >>2003 9:34 AM > >> > >> > >>> >> To: 'Monica J. Martin'; Ugo Corda; > >>> Steve Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: choreography & > orchestration > >>> must be defined in a context > >>> >> > >>> >> > >>> >> > >>> >> Even though I no longer > belong to the > >>> ws-chor working group :-( I > >>> >> felt that I needed to add my > >>> > >>> > >>2c to this > >> > >> > >>> question. > >>> >> > >>> >> IMHO, these concepts must be > >>> > >>> > >>defined in > >> > >> > >>> the context in which you use > >>> >> them. > >>> >> > >>> >> Today, the "web services stack" has > >>> divided itself in three parts: > >>> >> - messaging > >>> >> - web services > >>> >> - service oriented architecture > >>> >> > >>> >> Within the SOA layer, one must also > >>> distinguish specification that > >>> >> are relevant to the behavior of a > >>> service in an SOA, and > >>> >> specifications that are > >>> > >>> > >>relevant to the > >> > >> > >>> web service fabric. > >>> >> > >>> >> What I mean by that is that > I can use > >>> some "web services" > >>> >> specifications to > >>> >> simply exchange messages, I don't > >>> really care if these messages are > >>> >> composed in "web services". > >>> > >>> > >>They could > >> > >> > >>> but I don't use WSDL, UDDI or > >>> >> any "web service" > specification. SOAP > >>> with a bit of ws-addressing is > >>> >> enough. > >>> >> > >>> >> Then, I can also define "web > >>> > >>> > >>services" > >> > >> > >>> as a composition of messages. > >>> >> These > >>> >> web services can be formally > >>> > >>> > >>described > >> > >> > >>> and sometimes "discovered". > >>> >> The UDDI piece is optional. > >>> >> > >>> >> Finally, I can build a "service > >>> oriented architecture" which may, > >>> >> IMHO leverage both messages and web > >>> services, one not excluding the other. > >>> >> > >>> >> The confusion comes from the > >>> > >>> > >>fact that > >> > >> > >>> we try to define concepts such > >>> >> as orchestration, choreography, > >>> coordination, protocols, > >>> >> collaborations and many more > >>> > >>> > >>outside a > >> > >> > >>> given context. > >>> >> > >>> >> For instance, orchestration > >>> > >>> > >>could be a > >> > >> > >>> model of "composition" of web > >>> >> services in the context of the "web > >>> service layer, i.e. I want to > >>> >> build a web service by > >>> assembling/composing other > >>> > >>> > >>services. However, > >> > >> > >>> >> in the context of a Service Oriented > >>> Architecture, Orchestration > >>> >> clearly describes the > behavior of one > >>> "Service" with respect to all > >>> >> the other (peer) services it > >>> > >>> > >>interacts > >> > >> > >>> with. > >>> >> > >>> >> Interestingly enough, when you deal > >>> with composition(orchestration) > >>> >> at the web service layer, it somehow > >>> overlaps heavily with > >>> >> choreography. What I mean > by that, it > >>> that I could almost use a > >>> >> choreography description to describe > >>> composition as well. > >>> >> > >>> >> However, when I go to the SOA level, > >>> choreography describes the > >>> >> overall message interchange between > >>> "orchestrated services" and > >>> >> simple services (i.e. > >>> > >>> > >>request/response > >> > >> > >>> type). In a SOA, Orchestration > >>> >> cannot be used to describe > >>> > >>> > >>the global, > >> > >> > >>> peer to peer message exchange. > >>> >> The reason is > >>> >> simple: > >>> >> orchestration assumes that > there is a > >>> "center", i.e. where the > >>> >> orchestration engine is. In a SOA, > >>> there is no center, peers talk to > >>> >> each other arbitrarily (see > the links > >>> below). Forcing all the > >>> >> messages to go through a > center would > >>> IMHO be an architectural > >>> >> mistake, and I don't think anyone is > >>> suggesting that. The "center" of > >>> >> an SOA looks more like a > >>> > >>> > >>"fabric" or a > >> > >> > >>> "grid". There is an instance > >>> >> of an SOA where there is a > center, it > >>> is called EAI (or ESB), but it > >>> >> is not general enough, there > >>> > >>> > >>are other > >> > >> > >>> models supported by SOA that > >>> >> would not work if a center existed. > >>> Orchestration works well for a > >>> >> service in an SOA, because we can > >>> define a center within a service. > >>> >> Even > >>> >> at the composition level, a center > >>> exist, it is the composed web > >>> >> service. > >>> >> > >>> >> I found this definition of > >>> Orchestration on the web, I > like it very > >>> >> much (the author was talking > >>> > >>> > >>about BPEL > >> > >> > >>> not orchestration) > >>> >> > >>> >> Orchestration > >>> >> < ... is an emerging [concept] that > >>> would give programmers a way to > >>> >> formally describe processes > >>> > >>> > >>underlying > >> > >> > >>> business applications so that > >>> >> they can be exposed and linked to > >>> processes in other applications > > >>> >> > >>> >> I added this, but I am sure you guys > >>> can do better. > >>> >> Choreography > >>> >> Is a concept that specifies > how these > >>> processes are linked together > >>> >> across the enterprise > >>> > >>> > >>Choreography can > >> > >> > >>> be < active > when mapping and > >>> >> routing are necessary > >>> >> > >>> >> I would like to add one thing about > >>> WSCI. If you agree with these > >>> >> different layers of the > >>> > >>> > >>ws-stack, then > >> > >> > >>> you can see that WSCI fits > >>> >> very well at the web service > >>> > >>> > >>layer and > >> > >> > >>> amounts to an abstract BPEL, > >>> >> it merely describes the behavior (in > >>> time) of a web service. This is > >>> >> a useful thing in itself to > >>> > >>> > >>communicate > >> > >> > >>> to a web service consumer, it > >>> >> will convey more information > >>> > >>> > >>than WSDL. > >> > >> > >>> IMHO, it was a mistake to add > >>> >> a "global model" to WSCI because the > >>> global model is useful in the > >>> >> context of the SOA layer, > but in this > >>> context it does not scale well, > >>> >> this is what will happen to abstract > >>> BPEL as well if one tries to use > >>> >> it at the SOA layer. > >>> >> > >>> >> Here is a few things I wrote > >>> > >>> > >>that might > >> > >> > >>> be of interest to continue > >>> >> this > >>> >> discussion: > >>> >> http://www.ebpml.org/indigo.htm > >>> <http://www.ebpml.org/indigo.htm> > >>> >> (ESB vs > >>> >> SOA) > >>> >> http://www.ebxmlforum.org/ > >>> <http://www.ebxmlforum.org/> > "Standards > >>> >> for a Service Oriented Architecture" > >>> >> > >>> > >>> > >>> > >>http://www.ebpml.org/technoforum_2003_b_eng.ppt > >> > >> > >>> >> > >>> > >>> > >>> > >><http://www.ebpml.org/technoforum_2003_b_eng.ppt> > >> > >> > >>> >> > >>> >> > >>> >> JJ- > >>> >> tel: 425-649-6584 > >>> >> Cell: 508-333-7634 > >>> >> > >>> >> -----Original Message----- > >>> >> From: Monica J. Martin [ > >>> mailto:Monica.Martin@Sun.COM > >>> >> <mailto:Monica.Martin@Sun.COM> ] > >>> >> Sent: Friday, November 14, > >>> > >>> > >>2003 7:11 PM > >> > >> > >>> >> To: Ugo Corda; Steve Ross-Talbot > >>> >> Cc: public-ws-chor@w3.org > >>> >> Subject: Re: A trial balloon > >>> distinction between choreography & > >>> >> orchestration > >>> >> > >>> >> > >>> >> > >>> >>> Corda: Steve, > >>> >>> > >>> >>> I think your orchestration > >>> > >>> > >>definition > >> > >> > >>> below is too vague and could > >>> >>> refer to > >>> >> meanings that are not related to > >>> orchestration at all (for example, > >>> >> "the way a single Web > >>> > >>> > >>service should be > >> > >> > >>> used is by sending messages > >>> >> as specified in the > >>> > >>> > >>corresponding WSDL > >> > >> > >>> file, at the address specified > >>> >> in the same file"). > >>> >> > >>> >>> > >>> >>> A more appropriate definition would > >>> be, in my mind, something like: > >>> >>> > >>> >>> A written business protocol (i.e. > >>> abstract WS-BPEL) description > >>> >>> documents > >>> >> how a set of Web Services should be > >>> "used", as expressed from the > >>> >> point of view of one of the > >>> participating Web services...... > >>> >> > >>> >>> > >>> >> mm1: I would be inclined to > >>> > >>> > >>agree with > >> > >> > >>> Ugo. On Steve's point (and > >>> >> thanks Steve for the > >>> > >>> > >>impetus), I would > >> > >> > >>> add that the choreography > >>> >> definition describes how a > set of web > >>> services conforms to the > >>> >> definition when the services > >>> > >>> > >>are used. > >> > >> > >>> >> > >>> >>> Ross-Talbot: As an aside > from all of > >>> the stuff going on in > >>> >>> requirements I > >>> >> would be interested on > >>> > >>> > >>peoples take on > >> > >> > >>> what Frank postulated as a > >>> >> distinction between the O > >>> > >>> > >>word and the > >> > >> > >>> C word. As a guiding principle > >>> >> in how we may view a CDL is > >>> > >>> > >>this helpful? > >> > >> > >>> >> > >>> >>> > >>> >>> Suppose we changed it > >>> > >>> > >>slightly to read: > >> > >> > >>> >>> > >>> >>> A written choreography > >>> description documents how a set of Web > >>> >> Services should be "used". > >>> >>> > >>> >>> This minor change could then > >>> incorporate design-time use as well as > >>> >> run-time use (for conformance and > >>> compliance to a choreography). > >>> >> > >>> >>> > >>> >>> > >>> >>>>> McCabe: > >>> >>>>> I am aware that the O > >>> > >>> > >>word is taboo. > >> > >> > >>> However, the following > >>> >>>>> occurred to > >>> >> me during the last F2F: A written > >>> choreography description documents > >>> >> how to > >>> >> *use* a set of Web services: > >>> > >>> > >>A written > >> > >> > >>> orchestration description > >>> >> documents how to *control* a > >>> > >>> > >>set of Web > >> > >> > >>> services. > >>> >> > >>> >>>>> > >>> >>>>> > >>> >> > >>> > > >>> > This email is confidential and may be > >>> protected by legal privilege. If > >>> > you are not the intended recipient, > >>> please do not copy or disclose > >>> > its content but delete the email and > >>> contact the sender immediately. > >>> > Whilst we run antivirus > >>> > >>> > >>software on all > >> > >> > >>> internet emails we are not > >>> > liable for any loss or damage. The > >>> recipient is advised to run their > >>> > own antivirus software. > >>> > >>> This email is confidential and may be > >>> protected by legal privilege. > If you are > >>> not the intended recipient, > >>> > >>> > >>please do not > >> > >> > >>> copy or disclose its content > but delete > >>> the email and contact the sender > >>> immediately. Whilst we run antivirus > >>> software on all internet emails > >>> > >>> > >>we are not > >> > >> > >>> liable for any loss or damage. The > >>> recipient is advised to run their own > >>> antivirus software. > >>> > >>> > >>> > >> > >> > > > > > > > > >
Received on Wednesday, 26 November 2003 11:33:36 UTC