OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue 82 - Proposal to resolve 82 and other abstract process issues

Title: Message
Taking into account previous discussions and definitions,  including the Abstract BPEL
sub-group work, the  following definition of Abstract BPEL is proposed as the  resolution
of issue 82, to be included in WS-BPEL v2.0.  This definition would supercede the v1.1
 A resolution in principle of issue 107 is also proposed, in line with this defintion.
The other abstract issues can then be rapidly resolved in line with these proposals:
 91, 97, 99 - abstract processes ARE allowed to omit/hide the features mentioned. The
schema should make the  elements in question optional and, in line with 107, allow
explicit <opaque> as an alternative.
 109 - close with no change, mark as revisitable
 (The existing proposals for some of these issues are already in line with this
 A corollary of [2] below is that the content of the  "extensions for executable
processes" would become part of  the main body.
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. 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. 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.
 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 undefined.
 [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 either through the omission of specific BPEL elements or attributes listed
 in the specification, or through the use of "opaque" entities  of various types (i.e.
elements, attributes, etc.).
 However, the semantics of the constructs used in such a  process are exactly the same as
their semantics in the  executable context. Addionally, an abstract process is  required
to be syntactically valid using the executable  schema extended with the opaque entities.
 [4]  The omitted operational details may be added anywhere,
 by or when mapping an abstract process to a fully executable  artifact. In addition, if
the points of the omitted  operational details are specified through the use of opaque
entities, then these placeholders are replaced with other  concrete entities in any
executable artifact that corresponds  to the abstract process using such opaque entities.
 [5]  Abstract processes say nothing about *how* concretized,  executable realizations of
them should be implemented (ie:  language, platform, etc) (analogy to WSDL). Nor do they
imply  a relationship(s) with any such realizations.
Proposal for issue 107:
 Language extensions required for abstract processes
 The language extensions consist of opaque 'placeholders'
 whose functions are explained below:
 [1]  Opaque expressions- Needed in particular for opaque  assignment, opaque transition
conditions, opaque query  expression. Opaque assignment is used for capturing variable
creation/modification in a yet-to-be-concretized mechanism/fashion.
 [2]  Opaque activities- Hide a concrete BPEL activity, such
 as a structured activity, a lifecycle activity (ie.
 receive-start) or even just an "empty". They may also be used  as a source or a target of
control links.
 [3]  Opaque attributes- Hide a concrete BPEL attribute. For  example in invoke, receive
or reply activities opaque  attributes are specifying that variables need to be filled in
by or when mapping the partial process specification to a fully executable artifact.

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]