[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82 - Proposed resolution for vote (revised)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]