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 08:33:28 -0800
Message-ID: <EDDE2977F3D216428E903370E3EBDDC903958759@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,
So are you are saying that level 0 should be out of scope? I bet David might be able to derive the opposite conclusion ;-). 

I suspect we should be much more explicit than that.

Ugo

> -----Original Message-----
> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
> Sent: Wednesday, November 26, 2003 8:36 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:
> 
> >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:33:36 GMT

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