- From: Ricky Ho <riho@cisco.com>
- Date: Sun, 16 Mar 2003 09:43:44 -0800
- To: "Assaf Arkin" <arkin@intalio.com>, "Hugo Haas" <hugo@w3.org>, <public-ws-chor@w3.org>
Agree ! But I think we care more about those Web Service interaction that are crossing the boundary of "domain of control" rather than within it. Best regards, Ricky At 05:53 PM 3/15/2003 -0800, Assaf Arkin wrote: > > Turing complete > > @@@ > >Can simulate a Universal Turing Machine. The definition of a Universal >Turing Machine is uniform and about one page long, I doubt if we want to >repeat it but can definitely reference it from a non-normative reference. > >As for everything below, I have one question. We live in the WS world, so in >my opinion we should define activities that a WS performs and proceses in >which the WS is involved. If the WSA decides that WS only perform 'business >activities' that this term would be adequate. Similarly if the WSA decides >that WS are business entities, the a choreography of Web services is in fact >a choreography of business entities. But unless such a definition is >proposed by the WSA, should we make this restriction in our glossary? > >arkin > > > 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: > > interface business processes and collaboration business > > processes. > > > > 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. > > > > 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. > > > > Note that there wasn't consensus on these definitions. > > > > Regards, > > > > Hugo > > > > -- > > Hugo Haas - W3C > > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Sunday, 16 March 2003 12:58:23 UTC