To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
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
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  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
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
embodying domain-specific best practices, encoded in a
platform-neutral and portable way
by both enterprises and vertical standards organizations. The process
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:
 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
 Abstract processes permit
the use of all of the constructs of executable processes.
Thus there is no fundamental expressive power distinction between
 An abstract process may
omit operational details that are mandatory for BPEL executable
processes either through the omission of specific BPEL elements or
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.
 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.
 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:
 Opaque expressions- Needed
in particular for opaque assignment, opaque transition
conditions, opaque query expression. Opaque assignment is used for
creation/modification in a yet-to-be-concretized mechanism/fashion.
 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
 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
Choreology Anti virus scan completed