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: Wed, 26 Nov 2003 09:35:42 -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: <3FC4D65E.1040402@sun.com>

Ugo Corda wrote:

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

    * Choreography 'of web services' only
    * Bounding of the abstract level
    * Semantic definition outside of WS-Chor

These all seem to provide some boundaries of our scope, do they not?

>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 11:28:55 GMT

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