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

Re: choreography & orchestration must be defined in a context

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
Message-id: <3FC41856.707@sun.com>

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 GMT

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