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
definition.
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
proposal.)
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
Choreology Anti virus scan completed
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/leave_workgroup.php.