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

RE: choreography & orchestration must be defined in a context

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Wed, 26 Nov 2003 07:58:22 -0800
Message-ID: <EDDE2977F3D216428E903370E3EBDDC903958755@MAIL01.stc.com>
To: "Monica J. Martin" <Monica.Martin@Sun.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>

Monica,

Thank you for your Requirements quotation, but I am still not sure what to conclude from that.

Ugo

> -----Original Message-----
> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Wednesday, November 26, 2003 8:00 AM
> To: Ugo Corda
> Cc: Burdett, David; Jean-Jacques Dubray; Steve Ross-Talbot;
> public-ws-chor@w3.org
> Subject: Re: choreography & orchestration must be defined in a context
> 
> 
> Ugo Corda wrote:
> 
> > David,
> >  
> > I agree with you about the existence of all those levels. What I am 
> > not sure about is whether level 0 is in scope for this group, given 
> > the fact that the WG is supposed to deal only with Web services.
> >  
> > For instance, let's take the example of a choreography designed to 
> > describe the interactions of multiple BPEL nodes (which is the case 
> > that in my view provides the most value right now in a Web services 
> > context). In that case, all the BPEL endpoints present WSDL 
> abstract 
> > interfaces and that is all that is required to describe their 
> > interactions from the choreography point of view.
> >  
> > Of course, we could go to a higher level (your level 0) and 
> abstract a 
> > whole set of choreographies that not only can describe that 
> particular 
> > set of BPEL endpoints but can also capture the interactions 
> among any 
> > other groups of BPEL nodes that differ from the first group only by 
> > syntactic definitions of message vocabularies (same semantics).
> >  
> > I understand there is value in this, I just am not sure we 
> should go 
> > that extra mile. I would be interested in hearing what 
> other people think.
> >  
> 
> mm1: Is Level 0 within our scope as defined in our mission 
> statement and 
> evolving requirements document?
> 
> Reference:
> Introduction in Requirements Document (previous version from 
> SRT): "The 
> description of interactions among Web Services especially 
> with regard to 
> the exchange of messages, their composition, and the sequences"......
> ......A choreography description is a multi-party contract that 
> describes the external observable behavior across multiple clients 
> (which are generally Web Services but not exclusively so) in which 
> external observable behavior is defined as the presence or absence of 
> messages that are exchanged between a Web Service and it's 
> clients.....
> 
> The only other comment is that originally we had quite a 
> discussion of 
> 'human' clients, and I believe this was deemed or questioned 
> to be out 
> of scope. Perhaps we should clarify this in the introduction of the 
> requirements document, in order to put this item to bed.
> 
> Thanks.
> 
> > Ugo
> >
> >     -----Original Message-----
> >     *From:* Burdett, David [mailto:david.burdett@commerceone.com]
> >     *Sent:* Tuesday, November 25, 2003 11:36 PM
> >     *To:* Ugo Corda; Burdett, David; Jean-Jacques Dubray; Steve
> >     Ross-Talbot
> >     *Cc:* Monica J. Martin; public-ws-chor@w3.org
> >     *Subject:* RE: choreography & orchestration must be defined in a
> >     context
> >
> >     mmm ... interesting ...
> >      
> >     Firstly I think there is a real need for the "higher level" of
> >     abstraction that I described otherwise, it will result in
> >     unnecessary duplication of choreography definitions. For example
> >     using the WSDL definition of an abstract interface then 
> you could
> >     have:
> >
> >         * Choreography 1 which consisted of sending an order and
> >           receiving an order response where the schemas were from
> >           RosettaNet, and
> >         * Choreography 2, which was absolutelyu identical 
> except that
> >           the order and order response were from RosettaNet.
> >
> >     Given that you could have hundreds of different order 
> document XML
> >     schemas this approach would seem silly.
> >      
> >     So here's my attempt at the different levels of abstraction that
> >     might be useful
> >
> >         * Level 0 - completely abstract, i.e. the messages are
> >           identified by a URI and described by a semantic definition
> >         * Level 1 - concrete schema but abstract wire 
> format, e.g. the
> >           order could be a RosettaNet order but how it is wrapped is
> >           undefined - this is the WSDL abstract level
> >         * Level 2 - concrete schema and concrete wire 
> format, e.g. the
> >           order is a RosettaNet order and the envelope is SOAP 1.2
> >           plus maybe extensions for security and RM
> >         * Level 3 - as level 2 but also extended to identify the
> >           specific instance of a WSDL interface to which 
> the messages
> >           are sent as well as other endpoint information such as the
> >           certificates used for digitally signing the message.
> >
> >     If you agree with these different levels, then I think that we
> >     need to work out names that describe each level that 
> avoid confusion.
> >      
> >     David
> >
> >         -----Original Message-----
> >         *From:* Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >         *Sent:* Tuesday, November 25, 2003 6:34 PM
> >         *To:* Burdett, David; Jean-Jacques Dubray; Steve Ross-Talbot
> >         *Cc:* Monica J. Martin; public-ws-chor@w3.org
> >         *Subject:* RE: choreography & orchestration must be 
> defined in
> >         a context
> >
> >         David,
> >          
> >> there are really two different types of choreography:
> >> An "Abstract" choreography where neither the format (e.g.
> >         XSD) for the message
> >> nor the interfaces are specified, so transformations are not
> >         relevant, and 
> >> A "Concrete" Choreography, for want of a better word, where
> >         they are specified, in detail.
> >         At a certain point (hopefully soon) we'll have to reconcile
> >         the WSDL abstract and concrete concepts with the 
> ones you are
> >         using. Right now they simply do not match.
> >          
> >         In WSDL, an abstract interface include the definition of a
> >         specific schema. The concrete interface simply maps that
> >         schema to specific on-the-wire bit sequences (that's the so
> >         called binding of the abstract interface - so in 
> one binding I
> >         might have a mapping of the XML infoset to plain XML
> >         serialization, in another binding I might have part of the
> >         infoset in XML serialized form and part of it in 
> the form of a
> >         MIME multipart attachment, etc.).
> >          
> >         As you can see, your definitions of abstract and 
> concrete are
> >         shifted one level above the WSDL definitions (i.e., if we
> >         combine the two definitions we get three levels).
> >          
> >         My initial understanding of WS-Chor goals was that it would
> >         start from the WSDL abstract interface, not from 
> the "abstract
> >         choreography" that you define. Whichever way we 
> decide to go,
> >         I hope we can get a final decision on this, 
> otherwise it will
> >         be hard to communicate because we associate 
> different meaning
> >         to the same words.
> >          
> >         Ugo
> >
> >             -----Original Message-----
> >             *From:* Burdett, David 
> [mailto:david.burdett@commerceone.com]
> >             *Sent:* Tuesday, November 25, 2003 6:13 PM
> >             *To:* Ugo Corda; Jean-Jacques Dubray; Steve Ross-Talbot
> >             *Cc:* Monica J. Martin; public-ws-chor@w3.org
> >             *Subject:* RE: choreography & orchestration must be
> >             defined in a context
> >
> >             Ugo
> >              
> >             You said ... "So I could add a new Web service 
> to indicate
> >             the transformation (so that all the interfaces at that
> >             point would match)."
> >              
> >             True, and if you did, then effectively then 
> there would be
> >             agreement and whoever was doing the transformation would
> >             not only need to expose the transformation 
> service and not
> >             the service that would receive the message.
> >              
> >             You also said ... "But I might think that it is too much
> >             detail, and I just want to indicate in the choreography
> >             that it is ok to connect the two mismatching interfaces,
> >             because some mechanism (to be determined at 
> binding time)
> >             will perform the transformation."
> >              
> >             I agree, and as a result there are really two different
> >             types of choreography:
> >
> >                 * An "Abstract" choreography where neither 
> the format
> >                   (e.g. XSD) for the message nor the interfaces are
> >                   specified, so transformations are not 
> relevant, and
> >                 * A "Concrete" Choreography, for want of a better
> >                   word, where they are specified, in detail.
> >
> >             In the latter case, the sender and the receiver of the
> >             message still have to agree the format that is 
> going to go
> >             over the wire as this decision is unavoidable. In this
> >             case, there is still no need to specify what
> >             transformations will occur, or who is going to do them
> >             since presumably sender and receiver would not agree to
> >             use a particular format unless they could each 
> handle them.
> >              
> >             Thoughts?
> >              
> >             David
> >
> >                 -----Original Message-----
> >                 *From:* Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >                 *Sent:* Tuesday, November 25, 2003 5:45 PM
> >                 *To:* Burdett, David; Jean-Jacques Dubray; Steve
> >                 Ross-Talbot
> >                 *Cc:* Monica J. Martin; public-ws-chor@w3.org
> >                 *Subject:* RE: choreography & orchestration must be
> >                 defined in a context
> >
> >                 David,
> >                  
> >                 The way I see it, a choreography is defined in terms
> >                 of various WSDL abstract interfaces that are the
> >                 senders/recipients of the messages 
> exchanged. Each one
> >                 of those WSDL abstract interfaces has a specific
> >                 schema that describes the format of the documents
> >                 exchanged.
> >                  
> >                 If two end points have to communicate and their
> >                 respective WSDL abstract interfaces have a schema
> >                 mismatch, then I cannot just indicate in the
> >                 choreography that one interface talks to the other,
> >                 because they actually cannot.
> >                  
> >                 So I could add a new Web service to indicate the
> >                 transformation (so that all the interfaces at that
> >                 point would match). But I might think that it is too
> >                 much detail, and I just want to indicate in the
> >                 choreography that it is ok to connect the two
> >                 mismatching interfaces, because some 
> mechanism (to be
> >                 determined at binding time) will perform the
> >                 transformation.
> >                  
> >                 Ugo
> >
> >                     -----Original Message-----
> >                     *From:* Burdett, David
> >                     [mailto:david.burdett@commerceone.com]
> >                     *Sent:* Tuesday, November 25, 2003 5:15 PM
> >                     *To:* Ugo Corda; Jean-Jacques Dubray; Steve
> >                     Ross-Talbot
> >                     *Cc:* Monica J. Martin; public-ws-chor@w3.org
> >                     *Subject:* RE: choreography & orchestration must
> >                     be defined in a context
> >
> >                     JJ & Ugo
> >                      
> >                     I still don't see why you need transformation at
> >                     the choreography level. For example, 
> suppose that:
> >                     1. Company A can generate SAP orders 
> from its ERP
> >                     system
> >                     2. Company B can accept Oracle Financial orders
> >                     into its ERP system.
> >                      
> >                     In this case, the interoperability is 
> not possible
> >                     without some transformation. This can 
> be solved in
> >                     three basic ways:
> >                     1. Company A transforms their SAP orders into
> >                     Oracle Financial format before sending to B
> >                     2. Company A sends SAP orders to B. Then, when B
> >                     receives the order it transfomrs it into the
> >                     Oracle financials format
> >                     3. Company A transforms the SAP orders into some
> >                     neutral format, e.g. UBL before sending 
> to B. Then
> >                     B transforms the UBL order to Oracle Financial
> >                     format when received.
> >                      
> >                     Firstly, in all these cases there has to be
> >                     agreement between A and B over what 
> format will be
> >                     sent over the wire. Secondly, the 
> transformations
> >                     are always done by one, the other or both of the
> >                     participants. Thirdly, the format of 
> the documents
> >                     being sent does not alter the sequence in which
> >                     they are sent and therefore does not alter the
> >                     choreography.
> >                      
> >                     Given the variety of different formats 
> that exist,
> >                     and the multiple different ways and places in
> >                     which transformation can be done, would it be
> >                     better to have a single choreography definition
> >                     that is independent of transformation 
> requirements
> >                     and then:
> >                     1. The participants in the choreography could
> >                     search for a choreography that 
> specifies a format
> >                     for the documents that they can both, either
> >                     directly or indirectly, generate/accept.
> >                     2. They could then agree to use that 
> choreography, and
> >                     3. They could each, independently of each other,
> >                     work out the private choreographies that they
> >                     would follow.
> >                      
> >                     What am I not understanding?
> >                      
> >                     David
> >                      
> >                      
> >
> >                         -----Original Message-----
> >                         *From:* Ugo Corda 
> [mailto:UCorda@SeeBeyond.com]
> >                         *Sent:* Monday, November 24, 2003 12:55 PM
> >                         *To:* Jean-Jacques Dubray; Steve Ross-Talbot
> >                         *Cc:* Burdett, David; Monica J. Martin;
> >                         public-ws-chor@w3.org
> >                         *Subject:* RE: choreography & orchestration
> >                         must be defined in a context
> >
> >                         JJ,
> >                          
> >                         I agree with your position on 
> transformations.
> >                         I think they play a very important role in
> >                         many choreographies, and should be expressed
> >                         at the choreography language level.
> >                          
> >                         A transformation specified at the 
> choreography
> >                         level can, of course, be implemented in many
> >                         different ways, going from hard-coded XSLT
> >                         transforms to a full ontology-based system
> >                         that automatically transforms from 
> one format
> >                         to another based on some semantics 
> reasoning.
> >                         The actual implementation would 
> correspond to
> >                         a specific binding of the choreography.
> >                          
> >                         Ugo
> >
> >                             -----Original Message-----
> >                             *From:* Jean-Jacques Dubray
> >                             [mailto:jeanjadu@Attachmate.com]
> >                             *Sent:* Monday, November 24, 
> 2003 11:41 AM
> >                             *To:* 'Steve Ross-Talbot'
> >                             *Cc:* Burdett, David; Ugo 
> Corda; Monica J.
> >                             Martin; public-ws-chor@w3.org
> >                             *Subject:* RE: choreography &
> >                             orchestration must be defined 
> in a context
> >
> >
> >                             Steve:
> >
> >                             >>I agree with your layering and the
> >                             relationships between a 
> BPEL-like language
> >                             and a WS-CDL-like language. This
> >                             >>is indeed how WS-CHOR sees things too.
> >                             I was also under this impression but I
> >                             felt that it was not clear in 
> the mind of
> >                             many people outside the ws-chor 
> working group.
> >
> >                             >>I shall give more thought to 
> a BPDL. One
> >                             thing that I am interested to understand
> >                             is the role of business rules
> >                             >>and business contraints and that whole
> >                             genre of AI-like technology to this BPDL
> >                             space. I am interested in two
> >                             >>main aspects:
> >
> >                             >>      Business processes encoded as
> >                             rules and constraints
> >                             >>      Business policies (i.e. SLA's)
> >                             encoded as rules and constraints
> >                             >>      The relationship to current BPM
> >                             standards and standards-to-be.
> >
> >                             As you state the problem that way, we
> >                             might realize that there must not be one
> >                             BPDL in the future but a few different
> >                             types based on what it being modeled.
> >
> >                             I think we would collectively 
> be making a
> >                             lot of progress if enough people would
> >                             stand up and explain clearly the current
> >                             layering orchestration, choreography and
> >                             business process. (note that I believe
> >                             that coordination and transaction fit
> >                             somewhere in the picture but 
> did not have
> >                             time to articulate it).
> >
> >                             The business process space is extremely
> >                             complex. The work done around 
> XRL by Prof.
> >                             van der Aalst, Papazoglou and Kumar, the
> >                             notion of meta-workflow, ... are a
> >                             brilliant example of the variety of
> >                             business rules and constraints that are
> >                             needed to express even the most trivial
> >                             (but real) use cases. IMHO, the current
> >                             BPM standards (i.e. BPEL and BPML) are
> >                             simply (excellent) 
> orchestration standards
> >                             (again if I take van der Aalst, 
> Papazoglou
> >                             and Kumar's work as a point of 
> reference).
> >
> >                             IMHO, (if we all believe in 
> this layering)
> >                             the ws-chor working group 
> should make sure
> >                             that the choreography language 
> is capable
> >                             of supporting higher level business
> >                             process definitions including 
> XRL and next
> >                             generation of BPML. The idea is not to
> >                             bring the kind of rules or flexibility a
> >                             BPDL would need, but have 
> enough in terms
> >                             of expressing message exchanges for BP
> >                             definitions.
> >
> >                             As I said earlier, having the notion of
> >                             domain of control somewhere can 
> be helpful.
> >
> >                             Let me try on more time to talk about
> >                             transformation. I think I did 
> not express
> >                             myself correctly. We talked with David
> >                             about transformation being something you
> >                             specify at binding time (role ->
> >                             participant). Actually, as you traverse
> >                             the boundary of a domain of control, you
> >                             need transformation, outside the context
> >                             of a binding. The 
> transformation is needed
> >                             because what you send to be 
> consumed by a
> >                             domain, may not be what one of 
> its service
> >                             might be able to consumer. I hope this
> >                             clarifies a bit more the need for
> >                             transformation.
> >
> >                             Cheers,
> >
> >                             JJ-
> >
> >                             On Wednesday, November 19, 
> 2003, at 11:06 
> >                             pm, Jean-Jacques Dubray
> >                             wrote:
> >
> >                             > Steve:
> >                             >
> >                             > I was talking of WS-CDL as 
> the output of
> >                             the WS-CHOR working group,
> >                             > when it becomes available. I have no
> >                             idea if it has been named that
> >                             > way. I thought that I had saw you
> >                             recently using this term.
> >                             >
> >                             > I am convinced that WS-CDL (as an
> >                             output) is the right level upon
> >                             > which Business Process Definition
> >                             Language(s) can be built. Again, I
> >                             > wrote a paper in the summer 2002
> >                             substantiating this claim.
> >                             >
> >                             > The whole debate started around pi for
> >                             workflow, business process,
> >                             > then moved to business process versus
> >                             orchestration, choreography, ...
> >                             > Then we heard that pi makes 
> choreography
> >                             as a concept irrelevant...
> >                             >
> >                             > Again my points are:
> >                             > 1) orchestration and choreography are
> >                             complementary as the "what" is
> >                             > being composed and "how" they 
> are composed
> >                             > 2) orchestration and choreography
> >                             languages (that I can refer
> >                             > occasionaly as BPEL and WS-CDL) are
> >                             different from business process
> >                             > definition languages
> >                             > (BPDLs)
> >                             > 3) BPDL(s) should be layers on top of
> >                             WS-CDL(s)
> >                             > 4) Protocols such as transaction or
> >                             business transaction protocols
> >                             > should also be layered on top 
> of WS-CDL(s)
> >                             > 5) In order to do 3) and maybe 4) the
> >                             current set of requirements,
> >                             > scope and objectives of 
> WS-CHOR working
> >                             group are lacking IMHO 3
> >                             > things (maybe more),
> >                             >       a) the ability to express
> >                             transformations along with the
> >                             >       message definition (ideally
> >                             transformation are expressed from the
> >                             >       consumer point of view to reach
> >                             the maximum level of decoupling)
> >                             >       b) the ability to express simple
> >                             routing rules between
> >                             >       nodes, again to acheive a good
> >                             level of decoupling
> >                             >       c) the ability to express the
> >                             ability to define domains
> >                             >       of control to which a 
> message can
> >                             be sent. The domain may then
> >                             >       implement special rules 
> to route a
> >                             message sent to the domain, to a
> >                             >       particular node.
> >                             >
> >                             > I view a), b) c) not as execution per
> >                             say but as an "active"
> >                             > choreography.
> >                             >
> >                             > I hope that helps clarify, I am sorry
> >                             for the confusion.
> >                             >
> >                             > Jean-Jacques
> >                             > tel: 425-649-6584
> >                             > Cell: 508-333-7634
> >                             >
> >                             > -----Original Message-----
> >                             > From: Steve Ross-Talbot
> >                             [mailto:steve@enigmatec.net]
> >                             > Sent: Wednesday, November 19, 
> 2003 12:14 AM
> >                             > To: Burdett, David
> >                             > Cc: Jean-Jacques Dubray; 'Ugo Corda';
> >                             Monica J. Martin;
> >                             > public-ws-chor@w3.org
> >                             > Subject: Re: choreography &
> >                             orchestration must be defined 
> in a context
> >                             >
> >                             > JJ,
> >                             >
> >                             > Hmmmm it's getting tricky to 
> figure out
> >                             who said what to whom.
> >                             > The piece I wish to comment on is the
> >                             last piece from (I think) JJ
> >                             > that talks about what a 
> WS-CDL lacks (or
> >                             is missing) and also
> >                             > references the pi-calculus. I have put
> >                             my comments in-line.
> >                             >
> >                             > Cheers
> >                             >
> >                             > Steve T
> >                             >
> >                             >
> >                             > On Tuesday, November 18, 
> 2003, at 10:50 
> >                             pm, Burdett, David wrote:
> >                             >
> >                             >> JJ
> >                             >>
> >                             >> I don't think we are as far apart in
> >                             our thinking as you suggest -
> >                             >> comments inline.
> >                             >>
> >                             >> David
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Jean-Jacques Dubray
> >                             [mailto:jeanjadu@Attachmate.com]
> >                             >> Sent: Tuesday, November 18, 
> 2003 1:49 PM
> >                             >> To: 'Burdett, David'; 'Ugo Corda';
> >                             Monica J. Martin; Steve
> >                             >> Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> David:
> >                             >>
> >                             >> thanks for forwarding this 
> definition,
> >                             however, I cannot disagree
> >                             >> more with the association of
> >                             "orchestration" and "business process".
> >                             >> If a business process 
> language were to
> >                             be defined one day, it will be
> >                             >> layered on top of a choreography
> >                             language as (as you put it yourself)
> >                             >> a co-operation of "orchestration
> >                             nodes". The fact that you talk about
> >                             >> orchestration nodes
> >                             >> (plural) participating in a business
> >                             process and you say that the
> >                             >> business process is an 
> orchestration is
> >                             antinomic.
> >                             >> </DavidBurdett> What I think I am
> >                             really saying is that Orchestration
> >                             >> occurs when a single entity 
> can define
> >                             what happens without there
> >                             >> being any need for cooperation with
> >                             others. Sometimes, these
> >                             >> orchestrations could define 
> a complete
> >                             business process, but they
> >                             >> will not always. Sometimes, 
> as you say,
> >                             the implementation of a
> >                             >> business process will require
> >                             cooperation with others businesses.
> >                             >> However this cooperation is 
> limited to
> >                             how those business processes
> >                             >> interact. The owner of the business
> >                             process will still have a lot of
> >                             >> control over how they carry out major
> >                             parts of their business process.
> >                             >> For example if a business defines a
> >                             process that allows placement of
> >                             >> orders, then you could imagine it
> >                             consisting of a number of steps:
> >                             >> 1. Determine demand for a product -
> >                             this is strictly internal and
> >                             >> private to the busines 2. If more
> >                             product is required then - this is
> >                             >> also strictly a private decision 3.
> >                             Place an order with the supplier
> >                             >> - how this is done is NOT 
> private as it
> >                             depends on the buyer and
> >                             >> supplier agreeing how the 
> order will be
> >                             placed.
> >                             >> So I would say that steps 1 through 3
> >                             are all part of a private
> >                             >> process and would be defined using an
> >                             Orchestration Language as there
> >                             >> is clearly one entity in contorl.
> >                             However, one part of the process
> >                             >> (step 3) must conform to a previously
> >                             agreed definition which is
> >                             >> where the choreography 
> definition comes
> >                             in.</DavidBurdett>
> >                             >>
> >                             >>
> >                             >> Yes I totally agree that there are
> >                             ochestration nodes, of course,
> >                             >> these nodes represent the "things"
> >                             where the activities of "the
> >                             >> business process"
> >                             >> are performed.
> >                             >>
> >                             >> Business processes that map 
> to a single
> >                             orchestration node are the
> >                             >> exception rather than the rule. These
> >                             type of orchestration
> >                             >> definitions require that all units of
> >                             work/activites be modeled as a
> >                             >> web service (with request/response
> >                             operations). They also create de
> >                             >> facto a "center" of business 
> processes
> >                             which does not exist in
> >                             >> reality, we all know that.
> >                             >> <DavidBurdett> I would disagree that
> >                             single orchestration nodes are
> >                             >> the exception. They are as common as
> >                             business processes that involve
> >                             >> multiple nodes where a single
> >                             orchestration node is at the end of the
> >                             >> branches of a business 
> process as in ...
> >                             >> BP1 consists of
> >                             >>   - BP2 which consists of
> >                             >>     - BP3 which consists of
> >                             >>       - Orchestration 4, and
> >                             >>       - Orchestration 5, with
> >                             >>    -Orchestration 6
> >                             >> </DavidBurdett>
> >                             >>   These are 2001 concepts, 
> in 2003, we
> >                             are thinking of service
> >                             >> oriented architectures. We finally
> >                             realized that units of
> >                             >> work/activities cannot be modeled as
> >                             request/responses but rather as
> >                             >> orchestrated nodes that co-operate
> >                             within a business
> >                             >> process.<DavidBurdett> I 
> totally agree.
> >                             >> However, at the lowest 
> level, you will
> >                             have either request-responses
> >                             >> or one-way messages.</DavidBurdett>
> >                             There is no center to a business
> >                             >> process, therefore a single
> >                             orchestration engine cannot be used for
> >                             >> that. <DavidBurdett> This is 
> sometimes
> >                             true, but not
> >                             >> always.</DavidBurdett>
> >                             >>
> >                             >> Please take a look at this 
> presentation
> >                             I am giving next week:
> >                             >>
> >                             
> <http://www.ebpml.org/technoforum_2003_b_eng.ppt>
> >
> >                             >>
> >                             
> http://www.ebpml.org/technoforum_2003_b_eng.ppt
> >                             it gives a detailed
> >                             >> definition of orchestration and
> >                             choreography as well as collaboration
> >                             >> (sorry I did not have time to put
> >                             coordination in the mix but it is
> >                             >> coming).
> >                             >> <DavidBurdett>I've looked at your
> >                             presentation and I really like it
> >                             >> and agree with it totally in terms of
> >                             what you are saying. I think
> >                             >> that, in the article, I used the term
> >                             Business Process Language as a
> >                             >> shorthand for BPEL which I think is
> >                             what you would call an
> >                             >> orchestration language - is that
> >                             right?</DavidBurdett>
> >                             >>
> >                             >> I also published this paper in the
> >                             summer of 2002 that expresses a
> >                             >> business process as a multiparty
> >                             collaboration of orchestrated nodes
> >                             >> ( http://www.ebpml.org/ebpml2.2.doc
> >                             >> <http://www.ebpml.org/ebpml2.2.doc>
> >                             >> ).
> >                             >> This approach enables the 
> definition of
> >                             end-to-end processes either
> >                             >> within or even beyond corporation
> >                             boundaries if needed. It also
> >                             >> provide a seemless model to go from
> >                             public business processes to
> >                             >> private business processes since both
> >                             are a co-operation of nodes.
> >                             >>
> >                             >> Neither BPEL or WS-CDL have any
> >                             business semantics to reach the level
> >                             >> of business process 
> definitions we all
> >                             know that. However, they
> >                             >> provide the substrate or the 
> foundation
> >                             upon which a business process
> >                             >> definition can be specified.
> >                             >>
> >                             >> WS-CDL also lacks three 
> concepts (that
> >                             I know of) to be able create a
> >                             >> business process definition language
> >                             (BPDL is not yet taken by any
> >                             >> spec):
> >                             >> a) WS-CDL lacks the ability 
> to express
> >                             transformations along with the
> >                             >> message definition (ideally
> >                             transformation are expressed from the
> >                             >> consumer point of view to reach the
> >                             maximum level of decoupling)
> >                             >> b) WS-CDL lacks the ability 
> to express
> >                             simple routing rules between
> >                             >> nodes, again to acheive a 
> good level of
> >                             decoupling
> >                             >> c) WS-CDL lacks the ability 
> to express
> >                             the ability to define domains
> >                             >> of control to which a message can be
> >                             sent. The domain may then
> >                             >> implement special rules to route a
> >                             message sent to the domain, to a
> >                             >> particular node.
> >                             >> If we had c) we may not need 
> b). There
> >                             is a very obvious domain of
> >                             >> control, it is called a company
> >                             boundary, but I think the concept
> >                             >> would be useful even within 
> a company.
> >                             >>
> >                             >
> >                             > SRT> Firstly no such thing as a WS-CDL
> >                             exists today. An editing team
> >                             > has been appointed and two 
> contributions
> >                             > SRT> received. A requirements document
> >                             is nearing it's second
> >                             > publication (more of this 
> later). So to
> >                             use the term
> >                             > SRT> WS-CDL as if it has been created
> >                             and so comment on it having this
> >                             > feature and not having that feature is
> >                             > SRT> speculative at best.
> >                             > SRT>
> >                             > SRT> Secondly it is very easy to say
> >                             that some specific language lacks
> >                             > things when you take that language out
> >                             of context.
> >                             > SRT> According to the mission 
> statement
> >                             of WS-CHOR and according to
> >                             > SRT> the
> >                             > unpublished draft of the requirements
> >                             document
> >                             > SRT> which I am fortunate to 
> have seen,
> >                             it is clear that a WS-CDL is
> >                             > *not* seeking to be an executable
> >                             language and so (a) and (b)
> >                             > SRT> will be out of scope.
> >                             > SRT>
> >                             > SRT> A WS-CDL, as far as I am 
> concerned
> >                             as a member, is a
> >                             > SRT> specification
> >                             > language. It's aim is to describe
> >                             > SRT> the external observable behaviour
> >                             and not actively police it.
> >                             > SRT> What
> >                             > a WS-CDL does is describe the
> >                             > SRT> external observable behaviour of
> >                             multi-party interaction where no
> >                             > one party has overall control -
> >                             > SRT> hence the use of the term
> >                             peer-to-peer. WS-CDL is likely to have
> >                             > some concept of participant and
> >                             > SRT> that notion may be akin 
> to a domain
> >                             of control but it is not a
> >                             > statically bound concept (others may
> >                             > SRT> wish to comment here).
> >                             > SRT>
> >                             >
> >                             >>
> >                             >> All these concepts are not in pi so I
> >                             am not surprised they don't
> >                             >> show up in WS-CDL or BPEL. However,
> >                             they are essential to achieve the
> >                             >> level of SOA, without them, we cannot
> >                             start building a BPDL.
> >                             >
> >                             > SRT>
> >                             > SRT> Yes you are correct that no
> >                             construct in the pi-calculus can be
> >                             > said to match directly to the (a) (b)
> >                             and (c) above.
> >                             > SRT> I don't see why it is helpful or
> >                             insightful to mention this. It's
> >                             > a bit like saying that because a
> >                             language only has
> >                             > SRT> loops it cannot express 
> recursion.
> >                             The pi-calculus can be used to
> >                             > encode (a), (b) and (c) just as any
> >                             programming
> >                             > SRT> language can and just as lamba
> >                             calculus can. Of course we would
> >                             > not wish to do so expect to show some
> >                             formal
> >                             > SRT> semantics about these constructs
> >                             and reason over them in
> >                             > particular ways. So I don't really
> >                             understand the pervious
> >                             > SRT> comment and what you are 
> trying to
> >                             say.
> >                             > SRT>
> >                             > SRT> As regards WS-CDL I have made it
> >                             clear that it doesn't exist yet
> >                             > so it is premature to suggest what is
> >                             and is not a feature
> >                             > SRT> of a WS-CDL. As far as BPEL is
> >                             concerned BPEL is not based on
> >                             > pi-calculus. Indeed several member of
> >                             the TC have
> >                             > SRT> asked for some pointers on
> >                             formalisms that underpin BPEL and have
> >                             > yet to see anything.
> >                             > SRT>
> >                             >
> >                             >> <DavidBurdett>All these 
> ideas are very
> >                             necessary and useful before we
> >                             >> can get to the 
> interoperability Nirvana
> >                             we want to reach. However we
> >                             >> are now getting into scope issues.
> >                             Should the WS Choreography group
> >                             >> describe how you do transformations,
> >                             how you do routing, how you do
> >                             >> security, how you do reliable
> >                             messaging, how identify a message, etc
> >                             >> - all of these are necessary. I don't
> >                             think so. What we really need
> >                             >> to do is allow these 
> specifications to
> >                             be separately specified then
> >                             >> work out how they are going 
> to be used
> >                             together.</DavidBurdett>
> >                             >>
> >                             >> If you use an orchestration engine
> >                             between "nodes" you are doing EAI
> >                             >> or integration scenarios, a very
> >                             particular form of SOA. (see this
> >                             >> article that explains why ESB is
> >                             different from SOA:
> >                             >> <http://www.ebpml.org/indigo.htm>
> >                             >> http://www.ebpml.org/indigo.htm)
> >                             >> <DavidBurdett>I wasn't 
> suggesting this.
> >                             I was suggesting that between
> >                             >> the nodes, you do need to define how
> >                             they will cooperate - this is
> >                             >> the choreography. I think the
> >                             misunderstanding is that I tended to
> >                             >> use the definition of a business
> >                             process as being specific to an
> >                             >> individual role, e.g. a Buyer, OR a
> >                             Seller, whereas I think that you
> >                             >> also consider the process 
> that involves
> >                             the Buyer AND the Seller as a
> >                             >> business process where no one is in
> >                             control. This is technically
> >                             >> correct, however, largely because of
> >                             BPEL, I think that people think
> >                             >> that business processes are 
> within the
> >                             enterprise.</DavidBurdett>
> >                             >>
> >                             >> Cheers,
> >                             >>
> >                             >> Jean-Jacques
> >                             >> tel: 425-649-6584
> >                             >> Cell: 508-333-7634
> >                             >>
> >                             >>
> >                             >>
> >                             >>   _____
> >                             >>
> >                             >> From: Burdett, David
> >                             [mailto:david.burdett@commerceone.com]
> >                             >> Sent: Tuesday, November 18, 
> 2003 12:43 PM
> >                             >> To: 'Ugo Corda'; Burdett, David;
> >                             Jean-Jacques Dubray; Monica J.
> >                             >> Martin;
> >                             >> Steve Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> Ugo
> >                             >>
> >                             >> I think we might be getting confused
> >                             over the definition of terms. I
> >                             >> would saythat an "orchestration
> >                             language" defines what an
> >                             >> "orchestration node"
> >                             >> does. I would use the term
> >                             "choreography language" to 
> define the ways
> >                             >> in which independently controlled and
> >                             managed "orchestration nodes"
> >                             >> should
> >                             >> co-operate. I agree though that this
> >                             co-oepration can be determined
> >                             >> by other means.
> >                             >>
> >                             >> I also think that we are basically
> >                             agreeing ;)
> >                             >>
> >                             >> David
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Ugo Corda
> >                             [mailto:UCorda@SeeBeyond.com]
> >                             >> Sent: Tuesday, November 18, 
> 2003 12:19 PM
> >                             >> To: Burdett, David; Jean-Jacques
> >                             Dubray; Monica J. Martin; Steve
> >                             >> Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> David, you say:
> >                             >>
> >                             >>> With an orchestration, someone (or
> >                             something) is definitely in
> >                             >>> control, so
> >                             >> cooperation is not needed - 
> which makes
> >                             life much easier.
> >                             >>
> >                             >> I think this would only apply to the
> >                             case where the orchestration Web
> >                             >> service only interacts with other Web
> >                             services that do not themselves
> >                             >> contain an orchestration. But in many
> >                             situations the system includes
> >                             >> more than one single orchestration
> >                             node, so that some type of
> >                             >> cooperation among all those
> >                             orchestration nodes is indeed required
> >                             >> (otherwise nothing would work). As I
> >                             said before, such cooperation
> >                             >> can be expressed via an orchestration
> >                             language, but it could be
> >                             >> achieved by other means.
> >                             >>
> >                             >> Ugo
> >                             >>
> >                             >>
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Burdett, David
> >                             [mailto:david.burdett@commerceone.com]
> >                             >> Sent: Tuesday, November 18, 
> 2003 11:31 AM
> >                             >> To: 'Jean-Jacques Dubray'; Ugo Corda;
> >                             Monica J. Martin; Steve
> >                             >> Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> Just to contribute my $0.02c to this
> >                             discussion ... here's an extact
> >                             >> from an article of mine that will be
> >                             published in December's Web
> >                             >> Services
> >                             >> Journal:
> >                             >>
> >                             >> A business process 
> definition (i.e. an
> >                             Orchesteration) describes how
> >                             >> internal, private business processes
> >                             work - for example the Sales
> >                             >> Order Management process where a
> >                             business uses its sales management
> >                             >> system, stock management 
> system and its
> >                             fulfillment system to satisfy
> >                             >> orders that the business receives. In
> >                             this case, the business
> >                             >> handling those orders is in complete
> >                             control of how those internal
> >                             >> and external systems are 
> integrated and
> >                             combined with existing manual
> >                             >> processes.
> >                             >>
> >                             >>
> >                             >>
> >                             >> Choreography definitions, on 
> the other
> >                             hand, define how one
> >                             >> "independent"
> >                             >> business or process interacts with
> >                             another, by defining the sequence
> >                             >> and conditions in which messages are
> >                             exchanged between them. In this
> >                             >> latter case no single business or
> >                             process is in control so each has
> >                             >> to agree with the other how to
> >                             cooperate. For example if a buyer
> >                             >> sends a supplier an order, 
> the supplier
> >                             needs to know how to respond.
> >                             >> Should they: a) return an order
> >                             response indicating the extent to
> >                             >> which they can meet the 
> order, b) just
> >                             ship the goods and send an
> >                             >> invoice or c) do something different.
> >                             No single business can
> >                             >> unilaterally decide what do without
> >                             informing, and getting the
> >                             >> agreement of, the other businesses
> >                             involved.
> >                             >>
> >                             >>
> >                             >>
> >                             >> As I think Ugo said, the key 
> difference
> >                             to my mind is that a
> >                             >> choreography defines how two or more
> >                             processes COOPERATE as no one is
> >                             >> in control.
> >                             >> With an
> >                             >> orchestration, someone (or something)
> >                             is definitely in control, so
> >                             >> cooperation is not needed - 
> which makes
> >                             life much easier.
> >                             >>
> >                             >>
> >                             >>
> >                             >> David
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Jean-Jacques Dubray
> >                             [mailto:jeanjadu@Attachmate.com]
> >                             >> Sent: Saturday, November 15, 
> 2003 1:39 PM
> >                             >> To: 'Ugo Corda'; Monica J. Martin;
> >                             Steve Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> well, I am not sure your 
> assessment is
> >                             correct with respect to the
> >                             >> direction the ws-stack is growing but
> >                             I'll refrain from any further
> >                             >> comments ;-)
> >                             >>
> >                             >>
> >                             >> Jean-Jacques
> >                             >> tel: 425-649-6584
> >                             >> Cell: 508-333-7634
> >                             >>
> >                             >>
> >                             >>   _____
> >                             >>
> >                             >> From: Ugo Corda
> >                             [mailto:UCorda@SeeBeyond.com]
> >                             >> Sent: Saturday, November 15, 
> 2003 10:52 AM
> >                             >> To: Jean-Jacques Dubray; Monica J.
> >                             Martin; Steve Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> I think the problem you describe is a
> >                             direct derivation from the fact
> >                             >> that the WS stack is being built
> >                             bottom-up. We all know there are
> >                             >> pros and cons for both bottom-up and
> >                             top-down. The risk of isolation
> >                             >> and lack of higher context 
> is usually a
> >                             shortcoming of the bottom-up
> >                             >> approach, and extra effort 
> needs to be
> >                             spent to overcome it.
> >                             >>
> >                             >> Ugo
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Jean-Jacques Dubray
> >                             [mailto:jeanjadu@Attachmate.com]
> >                             >> Sent: Saturday, November 15, 
> 2003 10:37 AM
> >                             >> To: Ugo Corda; Monica J. 
> Martin; Steve
> >                             Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> Yes, I guess, this is why it is
> >                             important to clearly define the
> >                             >> context(s)
> >                             >> in which choreography applies, its
> >                             relationship to other concepts
> >                             >> such as orchestration, composition,
> >                             coordination, protocols and
> >                             >> collaboration, and define its purpose
> >                             in life, e.g :
> >                             >> 1) choreography can support the
> >                             specification of n-party
> >                             >>     a) protocols
> >                             >>     b) collaborations
> >                             >> 2) choreography can validate complex
> >                             orchestration implementation
> >                             >> (#peers >
> >                             >> 3)
> >                             >> ...
> >                             >>
> >                             >> I personally donc think that any of
> >                             these concepts can be used in
> >                             >> isolation of each other 
> except for very
> >                             trivial cases. There is a
> >                             >> need to objectively align all these
> >                             specifications which are today
> >                             >> still mostly work in progress.
> >                             >>
> >                             >> Jean-Jacques
> >                             >> tel: 425-649-6584
> >                             >> Cell: 508-333-7634
> >                             >>
> >                             >>
> >                             >>
> >                             >>   _____
> >                             >>
> >                             >> From: Ugo Corda
> >                             [mailto:UCorda@SeeBeyond.com]
> >                             >> Sent: Saturday, November 15, 
> 2003 10:26 AM
> >                             >> To: Jean-Jacques Dubray; Monica J.
> >                             Martin; Steve Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: RE: choreography &
> >                             orchestration must be defined in a
> >                             >> context
> >                             >>
> >                             >>
> >                             >> JJ,
> >                             >>
> >                             >>> In a SOA, Orchestration 
> cannot be used
> >                             to describe the global, peer
> >                             >>> to
> >                             >> peer message exchange.
> >                             >>> The reason is simple: orchestration
> >                             assumes that there is a
> >                             >>> "center", i.e.
> >                             >> where the orchestration engine is.
> >                             >>> In a SOA, there is no center, peers
> >                             talk to each other arbitrarily
> >                             >>> (see
> >                             >> the links below).
> >                             >>> Forcing all the messages to 
> go through
> >                             a center would IMHO be an
> >                             >> architectural mistake,
> >                             >>> and I don't think anyone is 
> suggesting
> >                             that. The "center" of an SOA
> >                             >>> looks
> >                             >> more like a "fabric" or a "grid".
> >                             >>
> >                             >> As you say, I don't think anyone is
> >                             suggesting that in the
> >                             >> orchestration view of things there is
> >                             only one center. There are many
> >                             >> "centers", one for each "orchestrated
> >                             service" in the SOA,
> >                             >> corresponding to many orchestration
> >                             engines.
> >                             >>
> >                             >> The real issue is how these various
> >                             orchestrations and corresponding
> >                             >> engines harmonize and 
> cooperate. In the
> >                             orchestration approach, that
> >                             >> is left to be defined "out of band"
> >                             (i.e. is not part of what
> >                             >> orchestration itself describes). The
> >                             way this "out of band" work is
> >                             >> done can vary. Using a choreography
> >                             language is evidently a way, but
> >                             >> other less formal ways are also
> >                             conceivable (e.g. the same designer
> >                             >> develops all the orchestrations;
> >                             different designers work closely
> >                             >> together - a la extreme programming -
> >                             when developing each individual
> >                             >> orchestration; etc.) and potentially
> >                             appropriate depending on the
> >                             >> environment in which the SOA 
> is developed.
> >                             >>
> >                             >> Ugo
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Jean-Jacques Dubray
> >                             [mailto:jeanjadu@Attachmate.com]
> >                             >> Sent: Saturday, November 15, 
> 2003 9:34 AM
> >                             >> To: 'Monica J. Martin'; Ugo Corda;
> >                             Steve Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: choreography & orchestration
> >                             must be defined in a context
> >                             >>
> >                             >>
> >                             >>
> >                             >> Even though I no longer belong to the
> >                             ws-chor working group :-( I
> >                             >> felt that I needed to add my 
> 2c to this
> >                             question.
> >                             >>
> >                             >> IMHO, these concepts must be 
> defined in
> >                             the context in which you use
> >                             >> them.
> >                             >>
> >                             >> Today, the "web services stack" has
> >                             divided itself in three parts:
> >                             >> - messaging
> >                             >> - web services
> >                             >> - service oriented architecture
> >                             >>
> >                             >> Within the SOA layer, one must also
> >                             distinguish specification that
> >                             >> are relevant to the behavior of a
> >                             service in an SOA, and
> >                             >> specifications that are 
> relevant to the
> >                             web service fabric.
> >                             >>
> >                             >> What I mean by that is that I can use
> >                             some "web services"
> >                             >> specifications to
> >                             >> simply exchange messages, I don't
> >                             really care if these messages are
> >                             >> composed in "web services". 
> They could
> >                             but I don't use WSDL, UDDI or
> >                             >> any "web service" specification. SOAP
> >                             with a bit of ws-addressing is
> >                             >> enough.
> >                             >>
> >                             >> Then, I can also define "web 
> services"
> >                             as a composition of messages.
> >                             >> These
> >                             >> web services can be formally 
> described
> >                             and sometimes "discovered".
> >                             >> The UDDI piece is optional.
> >                             >>
> >                             >> Finally, I can build a "service
> >                             oriented architecture" which may,
> >                             >> IMHO leverage both messages and web
> >                             services, one not excluding the other.
> >                             >>
> >                             >> The confusion comes from the 
> fact that
> >                             we try to define concepts such
> >                             >> as orchestration, choreography,
> >                             coordination, protocols,
> >                             >> collaborations and many more 
> outside a
> >                             given context.
> >                             >>
> >                             >> For instance, orchestration 
> could be a
> >                             model of "composition" of web
> >                             >> services in the context of the "web
> >                             service layer, i.e. I want to
> >                             >> build a web service by
> >                             assembling/composing other 
> services. However,
> >                             >> in the context of a Service Oriented
> >                             Architecture, Orchestration
> >                             >> clearly describes the behavior of one
> >                             "Service" with respect to all
> >                             >> the other (peer) services it 
> interacts
> >                             with.
> >                             >>
> >                             >> Interestingly enough, when you deal
> >                             with composition(orchestration)
> >                             >> at the web service layer, it somehow
> >                             overlaps heavily with
> >                             >> choreography. What I mean by that, it
> >                             that I could almost use a
> >                             >> choreography description to describe
> >                             composition as well.
> >                             >>
> >                             >> However, when I go to the SOA level,
> >                             choreography describes the
> >                             >> overall message interchange between
> >                             "orchestrated services" and
> >                             >> simple services (i.e. 
> request/response
> >                             type). In a SOA, Orchestration
> >                             >> cannot be used to describe 
> the global,
> >                             peer to peer message exchange.
> >                             >> The reason is
> >                             >> simple:
> >                             >> orchestration assumes that there is a
> >                             "center", i.e. where the
> >                             >> orchestration engine is. In a SOA,
> >                             there is no center, peers talk to
> >                             >> each other arbitrarily (see the links
> >                             below). Forcing all the
> >                             >> messages to go through a center would
> >                             IMHO be an architectural
> >                             >> mistake, and I don't think anyone is
> >                             suggesting that. The "center" of
> >                             >> an SOA looks more like a 
> "fabric" or a
> >                             "grid". There is an instance
> >                             >> of an SOA where there is a center, it
> >                             is called EAI (or ESB), but it
> >                             >> is not general enough, there 
> are other
> >                             models supported by SOA that
> >                             >> would not work if a center existed.
> >                             Orchestration works well for a
> >                             >> service in an SOA, because we can
> >                             define a center within a service.
> >                             >> Even
> >                             >> at the composition level, a center
> >                             exist, it is the composed web
> >                             >> service.
> >                             >>
> >                             >> I found this definition of
> >                             Orchestration on the web, I like it very
> >                             >> much (the author was talking 
> about BPEL
> >                             not orchestration)
> >                             >>
> >                             >> Orchestration
> >                             >> < ... is an emerging [concept] that
> >                             would give programmers a way to
> >                             >> formally describe processes 
> underlying
> >                             business applications so that
> >                             >> they can be exposed and linked to
> >                             processes in other applications >
> >                             >>
> >                             >> I added this, but I am sure you guys
> >                             can do better.
> >                             >> Choreography
> >                             >> Is a concept that specifies how these
> >                             processes are linked together
> >                             >> across the enterprise 
> Choreography can
> >                             be < active > when mapping and
> >                             >> routing are necessary
> >                             >>
> >                             >> I would like to add one thing about
> >                             WSCI. If you agree with these
> >                             >> different layers of the 
> ws-stack, then
> >                             you can see that WSCI fits
> >                             >> very well at the web service 
> layer and
> >                             amounts to an abstract BPEL,
> >                             >> it merely describes the behavior (in
> >                             time) of a web service. This is
> >                             >> a useful thing in itself to 
> communicate
> >                             to a web service consumer, it
> >                             >> will convey more information 
> than WSDL.
> >                             IMHO, it was a mistake to add
> >                             >> a "global model" to WSCI because the
> >                             global model is useful in the
> >                             >> context of the SOA layer, but in this
> >                             context it does not scale well,
> >                             >> this is what will happen to abstract
> >                             BPEL as well if one tries to use
> >                             >> it at the SOA layer.
> >                             >>
> >                             >> Here is a few things I wrote 
> that might
> >                             be of interest to continue
> >                             >> this
> >                             >> discussion:
> >                             >> http://www.ebpml.org/indigo.htm
> >                             <http://www.ebpml.org/indigo.htm>
> >                             >> (ESB vs
> >                             >> SOA)
> >                             >> http://www.ebxmlforum.org/
> >                             <http://www.ebxmlforum.org/>  "Standards
> >                             >> for a Service Oriented Architecture"
> >                             >>
> >                             
> http://www.ebpml.org/technoforum_2003_b_eng.ppt
> >
> >                             >>
> >                             
> <http://www.ebpml.org/technoforum_2003_b_eng.ppt>
> >
> >                             >>
> >                             >>
> >                             >> JJ-
> >                             >> tel: 425-649-6584
> >                             >> Cell: 508-333-7634
> >                             >>
> >                             >> -----Original Message-----
> >                             >> From: Monica J. Martin [
> >                             mailto:Monica.Martin@Sun.COM
> >                             >> <mailto:Monica.Martin@Sun.COM> ]
> >                             >> Sent: Friday, November 14, 
> 2003 7:11 PM
> >                             >> To: Ugo Corda; Steve Ross-Talbot
> >                             >> Cc: public-ws-chor@w3.org
> >                             >> Subject: Re: A trial balloon
> >                             distinction between choreography &
> >                             >> orchestration
> >                             >>
> >                             >>
> >                             >>
> >                             >>> Corda: Steve,
> >                             >>>
> >                             >>> I think your orchestration 
> definition
> >                             below is too vague and could
> >                             >>> refer to
> >                             >> meanings that are not related to
> >                             orchestration at all (for example,
> >                             >> "the way a single Web 
> service should be
> >                             used is by sending messages
> >                             >> as specified in the 
> corresponding WSDL
> >                             file, at the address specified
> >                             >> in the same file").
> >                             >>
> >                             >>>
> >                             >>> A more appropriate definition would
> >                             be, in my mind, something like:
> >                             >>>
> >                             >>> A written business protocol (i.e.
> >                             abstract WS-BPEL) description
> >                             >>> documents
> >                             >> how a set of Web Services should be
> >                             "used", as expressed from the
> >                             >> point of view of one of the
> >                             participating Web services......
> >                             >>
> >                             >>>
> >                             >> mm1: I would be inclined to 
> agree with
> >                             Ugo. On Steve's point (and
> >                             >> thanks Steve for the 
> impetus), I would
> >                             add that the choreography
> >                             >> definition describes how a set of web
> >                             services conforms to the
> >                             >> definition when the services 
> are used.
> >                             >>
> >                             >>> Ross-Talbot: As an aside from all of
> >                             the stuff going on in
> >                             >>> requirements I
> >                             >> would be interested on 
> peoples take on
> >                             what Frank postulated as a
> >                             >> distinction between the O 
> word and the
> >                             C word. As a guiding principle
> >                             >> in how we may view a CDL is 
> this helpful?
> >                             >>
> >                             >>>
> >                             >>> Suppose we changed it 
> slightly to read:
> >                             >>>
> >                             >>>       A written choreography
> >                             description documents how a set of Web
> >                             >> Services should be "used".
> >                             >>>
> >                             >>> This minor change could then
> >                             incorporate design-time use as well as
> >                             >> run-time use (for conformance and
> >                             compliance to a choreography).
> >                             >>
> >                             >>>
> >                             >>>
> >                             >>>>> McCabe:
> >                             >>>>> I am aware that the O 
> word is taboo.
> >                             However, the following
> >                             >>>>> occurred to
> >                             >> me during the last F2F: A written
> >                             choreography description documents
> >                             >> how to
> >                             >> *use* a set of Web services: 
> A written
> >                             orchestration description
> >                             >> documents how to *control* a 
> set of Web
> >                             services.
> >                             >>
> >                             >>>>>
> >                             >>>>>
> >                             >>
> >                             >
> >                             > This email is confidential and may be
> >                             protected by legal privilege. If
> >                             > you are not the intended recipient, 
> >                             please do not copy or disclose
> >                             > its content but  delete the email and
> >                             contact the sender immediately.
> >                             > Whilst we run antivirus 
> software on all
> >                             internet emails we are not
> >                             > liable for any loss or damage. The
> >                             recipient is advised to run their
> >                             > own antivirus software.
> >
> >                             This email is confidential and may be
> >                             protected by legal privilege. If you are
> >                             not the intended recipient,  
> please do not
> >                             copy or disclose its content but  delete
> >                             the email and contact the sender
> >                             immediately. Whilst we run antivirus
> >                             software on all internet emails 
> we are not
> >                             liable for any loss or damage. The
> >                             recipient is advised to run their own
> >                             antivirus software.
> >
> 
> 
> 
Received on Wednesday, 26 November 2003 10:58:23 GMT

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