RE: choreography & orchestration must be defined in a context

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 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 specification
language. It's aim is to describe
SRT> the external observable behaviour and not actively police it. 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.