- From: Stephen White <swhite@SeeBeyond.com>
- Date: Mon, 21 Oct 2002 16:06:08 -0700
- 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 UTC