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