[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 82 - Proposal for Vote
Hi, I replied to this earlier, but I think I only sent it to Martin since it's not showing up - so I'm recreating the gist of it here: Going back to your comment on 107 from 10/08: "Opaque have no place in executable bpel, but we have not yet clarified what abstract bpel is.Therefore I cannot see how we can vote on 107 until we have resolved the generic abstract bpel issue." -Martin This proposal aims to provide this clarification. Are there points in it that you think are confusing? tks Rania Martin Chapman wrote: > 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]