- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Wed, 3 Dec 2003 09:02:38 -0800
- To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>, "Burdett, David" <david.burdett@commerceone.com>, "Burdett, David" <david.burdett@commerceone.com>, "Steve Ross-Talbot" <steve@enigmatec.net>
- Cc: "Monica J. Martin" <Monica.Martin@Sun.COM>, <public-ws-chor@w3.org>, "Haugen Robert" <Robert.Haugen@choreology.com>, "Yunker, John" <yunker@amazon.com>, "Jon Pyke" <jpyke@dial.pipex.com>
- Message-ID: <EDDE2977F3D216428E903370E3EBDDC9032B89BB@MAIL01.stc.com>
The logic of my argument is that I, and a few others in this group, believe in the importance of WS-Chor complementing BPEL and at least supporting the coordination of BPEL nodes. If it is a choice between making WS-Chor much more complicated in order to support all choreography concepts know to man, or instead just supporting the minimum required to support BPEL, I would choose the latter any time. By the way, as a member of the BPEL team I resent the statement that the BPEL team believes that ws-cdl is useless. It is simply false, as proven by the fact that the BPEL TC has a liaison group continuously tracking WS-Chor. Ugo -----Original Message----- From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Sent: Wednesday, December 03, 2003 2:38 AM To: Ugo Corda; Jean-Jacques Dubray; Burdett, David; Burdett, David; Steve Ross-Talbot Cc: Monica J. Martin; public-ws-chor@w3.org; Haugen Robert; Yunker, John; Jon Pyke Subject: RE: choreography & orchestration must be defined in a context / s ematics and choreography Hum, we are reaching an interesting point of the discussion. ws-cdl is designed to work in coordination with BPEL only? and the BPEL team beleives that ws-cdl is useless, they actually proceed to build something that somehow competes with ws-CDL called BPELa. I really don't understand the logic of your argument. Jean-Jacques tel: 425-649-6584 Cell: 508-333-7634 _____ From: Ugo Corda [mailto:UCorda@SeeBeyond.com] Sent: Tuesday, December 02, 2003 6:23 PM To: Jean-Jacques Dubray; Burdett, David; Burdett, David; Steve Ross-Talbot Cc: Monica J. Martin; public-ws-chor@w3.org; Haugen Robert; Yunker, John; Jon Pyke Subject: RE: choreography & orchestration must be defined in a context / s ematics and choreography JJ, It seems to me that the "one-way" and the "request-response" MEPs would be able at least to choreograph sets of BPEL nodes, since that's all they use. Ugo -----Original Message----- From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Sent: Tuesday, December 02, 2003 5:47 PM To: Burdett, David; 'Jean-Jacques Dubray'; Burdett, David; Ugo Corda; Steve Ross-Talbot Cc: Monica J. Martin; public-ws-chor@w3.org; 'Haugen Robert'; 'Yunker, John'; 'Jon Pyke' Subject: RE: choreography & orchestration must be defined in a context / s ematics and choreography >>>If your goal is to allow for semantically rich specification to adopt ws-cdl as their choreography language. ws-cdl must include concepts such as "what is a protocol" and "what is a MEP".<<< The model is based on two basic MEPs: a "one-way" message and a "request-reponse". <JJ> This is what I was affraid of. Of course you could say that a protocol is subchoreography, but this is not exactly true. An MEP should be parameterizable exchange of message (i.e. choreography). In an MEP definition, I can specify fixed messages (e.g. signals), and I can also specify parameterizable messages, which in a choreography definition become more concrete (can still be an abstract message, but not a parameter anymore). I cannot imagine using ws-cdl to specify message exchanges along with protocols without a robust MEP capability</JJ> I also like the idea of sorting out the relationship between choreography/orchestration, etc different initiatives ... although making it happen could be hard. <JJ>we'll see</JJ> JJ- -----Original Message----- From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Sent: Monday, December 01, 2003 8:20 AM To: 'Burdett, David'; 'Ugo Corda'; Steve Ross-Talbot Cc: Monica J. Martin; public-ws-chor@w3.org; 'Haugen Robert'; 'Yunker, John'; 'Jon Pyke' Subject: RE: choreography & orchestration must be defined in a context / s ematics and choreography Dear all: I am responding to these emails on behalf of my involvement at ebBP since I do not belong to the ws-chor working group. I also apologize for not responding earlier to this very interesting debate which I think is at the heart of SOA. As a preamble to this email, I would like to re-iterate that this discussion underlines the need for a global SOA meeting with delegates from each relevant standards to discuss the layering of the concepts (composition, orchestration, choreography, collaboration, coordination, protocols, business process...) at the SOA level. This question is not only ours, but need to be discussed by all parties (e.g. BPEL, WS-CDL, WS-CAF, BTP and the like, ASAP, ebBP and BPML to name a few). Imagine the situation where we all create specifications that cannot work together because of gaps, overlap and lack of alignment? This email also reflects a discussion that I had with Nick at the last ws-chor f2f, which I would have hoped could have continued and lead to some conclusion about the role of ws-cdl with respect to semantically rich specifications like ebBP. IMHO, ws-cdl is an infrastructure specification which should provide a foundation for other specifications to use it. I could see how to transform a lot of existing specifications such as protocol related specs (BTP and the like), ebBP or BPML for that matter to be able to make use of ws-cdl. I don't see a big issue for ws-cdl to pursue semantically rich concepts provided it is itself separable into an abstract foundation and semantic specifications. If you fail to create these two levels, you would be missing a big opportuniy to federate a lot of specification of the SOA level since they they cannot seat on the other SOA infrastructure standard: orchestration. Such foundation would be greatly simplifying the modeling and implementation space as you can imagine. As far as I can tell, I count only 3 people really involved in making this happen or fail, so it will be easy to give credit either way. I don't think that ws-cdl can efficiently develop a lot of semantics (nick et al would have to write the equivalent of 10 more specs to cover a small portion of what could be possible). However, the spec must be designed in a way that these semantics can be easily added to a choreography definition. As I said to nick and repeatedly on this list or at the ws-chor f2f, I don't see why ws-chor should be in charge of defining a transaction protocol or a business transaction protocol. However, the choreography definition must have the necessary constructs (e.g. try/catch) such that other groups can define their protocols in terms of a choreography definition. If I take the example of ebBP (and only speaking for myself), I would be happy to propose a motion for a vote in order to adopt ws-chor as our foundation for specifying the choreography of messsages for: a) ebBP business transaction protocol b) ebBP state alignment protocol c) ebBP collaboration I would also be happy to write a proposal on how to use ws-cdl for ebBP to illustrate this. What would be an alternative for ebBP? re-inventing a choreography definition language? we already have one, loosely based on UML activity diagram. It is far from perfect. Why would we spend the time on a ebBP-cdl? why would modeling tools and infrastructure vendors be forced to support incompatible choreography definition language? I don't think this would make sense to any reasonable person. I am pretty sure that WfMC/BPMI folks could say the same thing. Now to respond specifically to David: I see two holes in your layering. Choreography should not really be concerned at all but what goes over the wire (though a binding to WSDL as a separate part of the spec sounds great). If your goal is to allow for semantically rich specification to adopt ws-cdl as their choreography language. ws-cdl must include concepts such as "what is a protocol" and "what is a MEP". Please take a look at the work of people like Bob Haugen and John Yunker. At the time I had suggested to Nick to create within ws-cdl the notion of "abstract protocols" (built on certain kinds of MEPs). I also mentioned several times that choreography must deal with a concept of service domain, but I think we agree on that one. Cheers, Jean-Jacques tel: 425-649-6584 Cell: 508-333-7634 _____ From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Tuesday, November 25, 2003 11:37 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, 3 December 2003 12:07:43 UTC