Alexis,
 
there are many different use case for abstract processes in BPEL: (1) process skelletons, (2) usage contraints, (3) viewing, ... many more. 
 
(1) allows you to document best practices in an abstract process model. This abstract process model must be refined at a customer's side into an executable process reflecting the customer's specifics.
 
(2) allows you to describe the order in which the operations of a (set of) services have to be used. Or it allows you to describe the message orders emitted/expected by a service.
 
(3) allows to describe the externally observable behavior of a process and to hide its internal implementation.
 
...etc...
 
Each of the use cases for abstract processes may come with a different language subset of BPEL and associated syntactic constraints.  Because BPEL cannot define all of them, we introduced the notion of an "abstract BPEL profile".  Such profile defines the syntax supported and the constraints that come with it. BPEL itself comes with profile definitions for the use cases (1) and (2).  A profile also MAY define the relation between an abstract process and (the set of) valid corresponding executable processes - if it does make sense for the profile.
 
BPEL itself is NOT playing in the choreography space. It is a language for (various aspects of) individual processes, only allowing to specify dependencies on other services (via so-called partner links).  The services a process depends on are "opaque", i.e. for BPEL it is irrelevant if those services are again processes or implemented in any other technology. If the other end is in fact a process, you are running into a situation where you choreography because the problems we discuss in parallel become aparent (e.g. matching message orders etc.).

----- Ursprüngliche Mail ----
Von: Alexis Richardson <[EMAIL PROTECTED]>
An: [email protected]
Gesendet: Montag, den 24. Juli 2006, 13:30:02 Uhr
Betreff: Re: [service-orientated-architecture] Re: Orchestration, Choreography , and Composition

Frank

I don't quite follow.  Are you saying that abstract BPEL is intended to play the same role as WS-CDL?

My understanding is that abstract BPEL represents a set of constraints on executable BPEL, such that for example there can be two executable BPEL process artefacts P and Q which share an abstract description.  Is that correct?   If so then is the abstract BPEL only describing externally observable behaviour of P and Q?  And, if so, then what composition guarantees are provided (or intended, or hoped for)?

Yours confusedly.

alexis




On 7/22/06, Frank Leymann <[EMAIL PROTECTED]> wrote:

Alexis,
 
you are absolutely right:  The different how's (i.e. orchestrations) cannot always be woven together! They have to fit... Although there is quite some research going on these days on checking whether two orchestrations fit together, there will likely always be situation where that won't help.
 
Thus, you need to specify how different orchestrations fit together - and this is where choreography comes in. By "wiring" orchestrations together explicitly, the human brain is solving otherwise intractable problems.
 
But there is a different twist in it:  In a choreography you typically only care about the externally visible behavior of each partner.  Thus, a choreography in practice may only weave together "projections" of the "internal choreography". To allow this distinction, we introduced executable vs abstract BPEL.
 
I am interested in Steve's view on that...

----- Ursprüngliche Mail ----
Von: Alexis Richardson < [EMAIL PROTECTED]>
An: [email protected]
Gesendet: Samstag, den 22. Juli 2006, 14:58:01 Uhr
Betreff: Re: [service-orientated-architecture] Re: Orchestration, Choreography , and Composition


Absolutely - then the question becomes: what is the compositionality in both cases.

Intuitively, you cannot always weave together two 'hows'.  Does choreography help by delimiting each 'how' with a composable 'what'?   (like a type system for behaviour). 

Steve, Frank, any comments?




On 7/21/06, Phil Ayres < [EMAIL PROTECTED] > wrote:

Alexis,

I think I need to refine this a little, as my brain did a loop trying
to get so abstract!


>
> - the choreography is the 'what'
> - the orchestration is the 'how'
>
Maybe I'll add a few words for my simple brain...

- choreography is the 'what to do - decide yourself how and when to do it'
- orchestration is the 'what to do - I'll tell you what and when to do it'

Cheers
Phil
http://improving-nao.blogspot.com/





__._,_.___


SPONSORED LINKS
Computer software Computer security software Computer software program
Computer fax software Computer virus software


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to