RE: Stop the Choreography Definition insanity!

Stephen,

Well done! This does a very good job of describing and differenciating
choreography from orchestration.

Edwin 


> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Stephen White
> Sent: Monday, October 21, 2002 4:06 PM
> To: www-ws-arch@w3.org
> Subject: RE: Stop the Choreography Definition insanity!
> 
> 
> 
> I too have not been able to follow all the e-mail on this 
> topic-due to a lack of bandwidth and mental capacity. But, 
> from what I could follow I seem to have lost track of the 
> actual definitions that are being formed. Thus, I would like 
> to enter a set of definitions from the perspective of someone 
> outside the WS arch group. These may not be complete, formal 
> definitions, but they help me understand what the potential 
> working group inputs do and how they relate to each other.
> 
> * Abstract (Choreography) Business Processes
> These are definitions that are designed to describe the 
> ordering of business activities that send and/or receive 
> messages. The definition of the flow between activities is 
> not computationally complete (i.e., it cannot be executed). 
> All of the messages are between independent business entities 
> (participants). The participants may be across companies or 
> within a company. 
> There are two types of these processes:
> 
> o Interface Business Processes
> This is an abstract business process that defines how outside 
> participants can expect to interact with a service of a 
> business entity. This service can be implemented as any type 
> of application, including an executable business process. If 
> the interface is for an executable business process, then all 
> activities within the interface business process will also 
> exist within the executable business process-that is, the 
> interface business process will be a sub-set of the 
> executable business process. Example of specifications to 
> define these types of processes: WSCI and the abstract part of BPEL4WS
> 
> o Collaboration Business Processes
> This is an abstract business process that defines how two or 
> more interface business processes interact with each other. 
> Even if these business processes were executable, there could 
> be no central control mechanism that could run one of these 
> processes. These processes are dependent on the 
> implementations of the interface business processes to act in 
> coordination. Example of specifications to define these types 
> of processes: WSCI global model and BPSS
> 
> * Executable (Orchestration) Business Processes
> These are definitions that are designed to describe the 
> ordering of business activities that send and/or receive 
> messages. The definition of the flow between activities is 
> computationally complete (i.e., it can be executed). The 
> messages may be sent to/from: a) an independent business 
> entity to itself and b) an independent business entity to 
> another (participant). These could be called internal or 
> workflow business processes. The business activities that 
> interact with another participant will also appear in a 
> derived abstract business process. In fact, the definition of 
> an executable business process is a superset of the 
> definition of an abstract business process. Example of 
> specifications to define these types of processes: executable 
> part of BPEL4WS and BPML
> 
> 
> 
> 
> 
>  -----Original Message-----
> From: 	Champion, Mike 
> [mailto:Mike.Champion@SoftwareAG-USA.com] 
> Sent:	Monday, October 21, 2002 2:10 PM
> To:	www-ws-arch@w3.org
> Subject:	RE: Stop the Choreography Definition insanity!
> 
> 
> 
> 
> > -----Original Message-----
> > From: David Orchard [mailto:dorchard@bea.com]
> > Sent: Monday, October 21, 2002 3:29 PM
> > To: www-ws-arch@w3.org
> > Subject: Stop the Choreography Definition insanity!
> > 
> 
> > 
> > 2.  We need actual discussion of REQUIREMENTS, with proposed
> > suggestions.
> 
> One thing that I *think* the discussion has pointed to is a 
> need to disentangle the public/declarative/interface 
> definition of a choreography from the language used to 
> implement it.  Would you disagree?  Does the W3C choreography 
> language need to cover both the declaration and execution aspects?
> 
> > 
> > 4. if this group decides that it
> > wants to re-invent choregraphy languages from ground up 
> with n inputs, it
> will 
> > be a total waste of time.  Simply put, a number of companies are not
> prepared 
> > to go through the reinvent the wheel exercise again.
> 
> Are you suggesting that one of the input choreography 
> languages is more or less done (well, at least as "done" as 
> WSDL 1.1 was when submitted to the
> W3C) and the new WG should be chartered to profile and polish 
> it?   Or in
> the context of the previous question, maybe we should take 
> either the intersection or union of the requirements covered 
> by WSCI and BPEL, and add some requirements that the new WG 
> more cleanly separate the interface declaration from the 
> execution language?
> 
> Personally, I thought the problem was that there were a bunch 
> of wobbly wheels that have been invented, and that the W3C WS 
> Choreography WG was needed to invent a simple but steady 
> wheel based on what we've learned from the previous efforts :-)
> 
>

Received on Monday, 21 October 2002 20:42:52 UTC