RE: [wsbpel] Issue - 82 - Proposal for Vote

["Martin Chapman" <martin.chapman@oracle.com>]

Since most of these defintions are not really normative,
isnt this is mostly material for a primer?

Martin.

>-----Original Message-----
>From: rkhalaf [mailto:rkhalaf@watson.ibm.com] 
>Sent: 08 October 2004 15:38
>To: wsbpel@lists.oasis-open.org
>Subject: [wsbpel] Issue - 82 - Proposal for Vote
>
>
>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.
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/lea
ve_workgroup.php.