Re: [wsbpel] Issue 82 - Proposed resolution for vote (revised)

[Charlton Barreto <charlton_b@mac.com>]

I'll second this proposal. I'm not keen on profiles :-), but I think 
Peter well captures bridging the gap between the two positions on 
absBPEL.

On 14/12/2004, at 11:20, Furniss, Peter wrote:

> On the quetstion of profiles not changing the existing semantics, I 
> suggest we add in the third paragraph, as the ante-penultimate 
> sentence (between ".. or omitted." and "An abstract process may 
> identify...")
>  
> "A profile must not change the existing semantics of BPEL constructs, 
> other than by allowing or requiring opacity or omission."
>  
> Peter
> -----Original Message-----
> From: Furniss, Peter
>  Sent: 14 December 2004 00:16
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue 82 - Proposed resolution for vote (revised)
>
>
> Following some discussion, this is a revised version of the issue 82 
> proposal (proposals on the other abstract issues have been separated, 
> as asked).
>
> This version has more detail on the concept of profiles, but does not 
> make them mandatory. It's a merge of different ideas (messed up by me 
> probably).
>
> Proposal for Issue 82:
>
> Abstract BPEL definition:
>
> A BPEL abstract process is a partially specified process that is not 
> intended to be executed. Executable and abstract BPEL processes share 
> the same expressive power, while the latter allows process definitions 
> that are capable of abstracting away operational details _ either 
> through omission or explicit opacity.  Whereas executable processes 
> are fully concretized and thus can be executed, an abstract process 
> lacks some of the required concrete operational details expressed by 
> or when mapping it to a fully executable artifact. An abstract BPEL 
> process must be explicitly declared as 'abstract'.
>
> Abstract processes serve a descriptive role, with more than one 
> possible purpose. A BPEL abstract process can define the publicly 
> visible behavior of some or all of the services it offers ("myRole" in 
> its partnerLinks), which may include its interactions along its 
> partnerLinks with other services. Alternatively, a BPEL abstract 
> process can define a process "template" embodying domain-specific best 
> practices, encoded in a platform-neutral and portable way by both 
> enterprises and vertical standards organizations. The process 
> "template" captures some essential process logic while leaving out 
> operational details that will be concretized by the enterprises and 
> vertical standards organizations when mapping the partial process 
> specification to a fully executable artifact.
>
> The different uses of abstract BPEL require different levels of 
> opacity and restrictions or relaxations on which elements of a 
> corresponding executable artifact are omitted or hidden.  To cleanly 
> enable different usages of abstract processes, an extensible approach 
> is taken using a set of basic, minimal requirements (base) for all 
> abstract processes. From this base, "usage profiles" can be defined. 
> On its own, the base lacks well-defined semantics - the only 
> constructs that have defined meaning are the constructs of executable 
> processes, and that meaning is defined by prescribed behaviour of the 
> executable process as a whole, and is thus not directly available 
> outside an executable process. The semantics of an abstract process 
> are therefore derived from those of the executable process it could be 
> mapped to. To define these semantics, the range of corresponding 
> executable processes can be constrained by a usage profile, placing 
> constraints on what is opaque or omitted. An abstract process may 
> identify the usage profile it belongs to with a URI. Profiles may be 
> defined by anyone - in separate standardization efforts, internally in 
> organizations or for proprietary usage, etc.
>
> The section [x.x] is such a usage profile for abstract processes, with 
> the same purpose as the abstract process definition from BPEL1.0/1.1, 
> with minor modifications.
>
>  
>
> Semantics of Abstract Processes:
>
> [1] Although it might contain complete information that would render 
> it executable as specified 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. The minimum criteria for an abstract process is defined in 
> this specification while completeness is left to the usage profile a 
> particular abstract process definition belongs to.
>
> [2] Abstract processes permit the use of all of the constructs of 
> executable processes. Thus there is no fundamental expressive power 
> distinction between abstract and executable processes.
>
> [3] An abstract process may omit operational details that are 
> mandatory for BPEL executable processes through the use of "opaque" 
> entities of various types (i.e. elements, attributes, etc.) or through 
> the omission of specific BPEL elements or attributes that are allowed 
> to be implicitly opaque. This omission is treated as a syntactic 
> shortcut equivalent to the attribute or expression being in the 
> omitted location with an opaque value.
>
> The semantics and consistency constraints of executable BPEL are 
> clearly defined. The semantics of each construct in an abstract 
> process is derived from that of the same construct in executable BPEL. 
> The difference is strictly a consequence of the opacity used in that 
> construct (missing information) and other parts of the process 
> affected by it ( For example, opacity in a link source element may 
> affect the link target element).
>
> Addionally, an abstract process is required to be syntactically valid 
> using the executable schema extended with the opaque entities.
>
> [4] In this base definition, to avoid absurd constructs and to clarify 
> opacity, the minimial requirement is that for any abstract process, 
> there exists at least one syntactic completion that yields a *valid 
> executable process* by
>
>     a) replacing each opaque token by a concrete entity or removing 
> the opaque token completely, and
>
>
>     b) adding new BPEL XML elements anywhere in the process.
>
>
> [5] For this base definition, there are no requirements on how 
> concretized, executable realizations of abstract process should be 
> implemented (ie: language, platform, etc) (c.f. analogy to WSDL); 
> nor are specific relationships with such realizations specified.
>
> [6] Abstract processes are *incomplete* and non-executable by 
> definition, whether or not they contain opaque entities. Therefore the 
> semantics of the non-opaque constructs they contain cannot be 
> understood in isolation from the relationship of the abstract process 
> with the executable *completions* it permits. The reason being that 
> the semantics of those constructs actually exists only in the possible 
> executable completions. As an edge case, a permitted completion may 
> sometimes be identical to the abstract process syntactically, but this 
> is the exception rather than the rule.
>
> __
>   
> Peter
>  
> ------------------------------------------
> Peter Furniss
> Chief Scientist, Choreology Ltd
> web: http://www.choreology.com
> email: peter.furniss@choreology.com
> phone: +44 870 739 0066
> mobile: +44 7951 536168
>  
> Choreology Anti virus scan completed
> Choreology Anti virus scan completed