Issue - 82 - Proposal for Vote

[rkhalaf <rkhalaf@watson.ibm.com>]

In this proposal, we clarify abstract processes as requested by Issue 
82. The spec should reflect these clarifications to abstract processes 
throughout its text.

--------

A BPEL abstract process defines the publicly visible behavior of the 
services it offers (all "myRole" in its partnerLinks), of course 
including its interactions along its partnerLinks with other services. 
Abstract processes serve a descriptive role. They can be viewed as 
partially specified processes that are typically not intended to be 
executed. They are partially specified in that they are capable of 
abstracting away operational details. An abstract BPEL process must be 
declared abstract by setting the abstractProcess attribute to “yes”. 
Operational details may be abstracted away either through the omission 
of specific BPEL elements or attributes listed in the specification, or 
through the use of opaque tokens. Aside from these factors, they are 
well-formed process following the structure and restrictions in the 
specification regarding the process definition and the constructs used.

Semantics of Abstract Processes:

A.	 Although it might contain complete information that would render it 
executable if the abstractProcess=”yes” attribute were changed to “no” 
for executable BPEL, its abstract status states that any concrete 
realizations of it may perform additional processing steps that are not 
relevant to the audience to which it has been given.

B.	Abstract processes permit the use of nearly all of the constructs of 
executable processes.  Thus there is no fundamental expressive power 
distinction between abstract and executable processes.

C.	An abstract process may omit certain details that are mandatory for 
BPEL executable processes. However, the semantics of the constructs used 
in such a process is exactly the same as their semantics in the 
executable context. An abstract process must comply with the syntax and 
semantics of the specification.  The syntactic elements that can be 
omitted in abstract processes where this would not be permitted in 
executable processes are currently:
-	Those listed in the “extensions for executable processes” section of 
the specification.
-	inputVariable/outputVariable/variable on invoke, receive, onMessage, 
and reply.
-	An initiating receive activity (pending resolution of issue 99).

D.	Abstract processes may include special syntactic extensions (“opaque” 
entities of various kinds) that should be replaced with concrete 
entities  in any executable artifact that complies with an abstract 
process using such opaque entities. Which opaque entities are permitted 
is the scope of issue 107.

E. Abstract processes say nothing about *how* concrete, executable 
realizations of them should be implemented (ie: language, platform, etc) 
. (analogy to WSDL).

F. Multiple abstract processes together may be created to define a 
global view of a multi-party business protocol. However, the way in 
which they may be wired together (connecting partnerLinks a la WSFL 
global models) is out of scope of BPEL itself.