- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Wed, 26 Nov 2003 07:58:22 -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, Thank you for your Requirements quotation, but I am still not sure what to conclude from that. 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 10:58:23 UTC