W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Stop the Choreography Definition insanity!

From: Stephen White <swhite@SeeBeyond.com>
Date: Mon, 21 Oct 2002 16:06:08 -0700
Message-ID: <C513FB68F8200244B570543EF3FC65370AD9F649@MAIL1.stc.com>
To: www-ws-arch@w3.org

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 19:06:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT