- From: Burdett, David <david.burdett@commerceone.com>
- Date: Tue, 25 Nov 2003 18:16:53 -0800
- To: "'Monica J. Martin'" <Monica.Martin@Sun.COM>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: 'Ugo Corda' <UCorda@SeeBeyond.com>, Jean-Jacques Dubray <jeanjadu@Attachmate.com>, Steve Ross-Talbot <steve@enigmatec.net>, public-ws-chor@w3.org
- Message-ID: <99F57F955F3EEF4DABA7C88CFA7EB45A0C0C8AB1@c1plenaexm04-b.commerceone.com>
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 21:17:16 UTC