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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

This looks very good. I wonder if it would be worth explicitly including
near the end something 
on the lines of:

"A concrete realisation may correspond to more than one abstract process
definition. 
Such the abstract definitions might differ in which partnerLinks are
included and which
elements are omitted or represented as opaque."

I think that is generally agreed, but understanding that an abstract
definition my
just be a view of real process is important.

Peter

> -----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/le
> ave_workgroup.php.
> 
> 


Choreology Anti virus scan completed