W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2003

RE: choreography & orchestration must be defined in a context

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 25 Nov 2003 18:16:53 -0800
Message-ID: <99F57F955F3EEF4DABA7C88CFA7EB45A0C0C8AB1@c1plenaexm04-b.commerceone.com>
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
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:41 GMT