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