- From: Monica J. Martin <Monica.Martin@Sun.COM>
- Date: Tue, 25 Nov 2003 20:04:54 -0700
- To: Ugo Corda <UCorda@SeeBeyond.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
Ugo Corda wrote: > David, > > I was not thinking about your cases 1 and 2 below when talking about > transformations. What you mention sounds more like what happens when > you have Web service intermediaries. In other words, you seem to be > referring to transformations at the binding level, while the same > abstract message (modulo some possible change in headers and security > encoding) travels across different intermediaries. > > The transformations I was referring to in this discussion are the ones > at the WSDL abstract level. mm1: Yugo, I think we may be saying the same thing, albeit differently. I believe this is more in line with what I was thinking re: transformations. > > Ugo > > -----Original Message----- > *From:* Burdett, David [mailto:david.burdett@commerceone.com] > *Sent:* Tuesday, November 25, 2003 6:17 PM > *To:* 'Monica J. Martin'; Burdett, David > *Cc:* Ugo Corda; Jean-Jacques Dubray; Steve Ross-Talbot; > public-ws-chor@w3.org > *Subject:* RE: choreography & orchestration must be defined in a > context > > Monica > > You said ... "Could it be that transformation is not limited to the > business document, but of the choreography itself given a specific > context or external event? This seems to touch the ideas evidenced > thus > far." > > I agree that transformation need not be limited to the business > document - I was using that as an example. Other types of > transformation that you might need include: > > 1. The Message envelope, e.g. different versions of SOAP, WS-I > Basic Profile, with/without attachments or using SMTOM, etc > > 2. Security transformations - if you the receiver doesn't trust a > sender and some trusted intermediary is required. > > However, I'm not sure I understand your point about transforming > the choreography itself as I always think that transforming one > sequence of messages into another in a sensible way that works is > almost always impossible to do. > > David > > -----Original Message----- > From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] > Sent: Tuesday, November 25, 2003 5:52 PM > To: Burdett, David > Cc: 'Ugo Corda'; Jean-Jacques Dubray; Steve Ross-Talbot; > public-ws-chor@w3.org > Subject: Re: choreography & orchestration must be defined in a > context > > > Burdett, David wrote: > > > 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. > > > > mm1: David, could it be that transformation is not limited to the > business document, but of the choreography itself given a specific > context or external event? This seems to touch the ideas evidenced > thus > far. > > > 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 Tuesday, 25 November 2003 22:02:35 UTC