Monica, Ron, Peter, and I took a stab at incorporating Monica and Ron's
requested clarifications with my response and Peter's text on 82. We
tried very hard to ensure that changes clarify/make consistent the
text below *without changing the content and intent*.
This text is provided for consideration, as input towards addressing
the TC's request that requested clarifications be handled before 82 can
I will also send a version without the change log that should be easier
to read from start to finish.
Rania (w/ Monica, Ron, and Peter).
red = changes. (Additions, unless otherwise specified.)
**addressing (x)** precedes each, where (x) is the item number from
Monica and Ron's email of concerns.
IMPORTANT NOTE ON 82:
Ambiguities should be limited/focus on non-substantive changes to the
accepted concept, i.e. editorial comment, further clarification that
do not change the substance of the accepted proposal from Peter dated
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
lack some of the required concrete
operational details expressed by
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
Replace: A BPEL abstract process can
Wiith: One such purpose for an abstract process could be
to 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.
Replace: Alternatively, a BPEL abstract process
With: Another purpose could be to
define a process "template"
embodying domain-specific best practices, encoded in a platform-neutral
and portable way by both enterprises and vertical standards
Replace: 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.
With: For example, a process "template" could capture some
essential process logic while leaving out operational details that will
be concretized 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.
Replace: 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.
With: The abstract process
base definition lacks well-defined semantics. Conversely, executable
processes have well-defined semantics and prescribed behavior. From the
abstract process base definition, "usage profiles" can be defined.
semantics of an abstract process are therefore derived from those of
Replace: process it could be mapped to.
With: processes to which it would be
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 MUST identify
the usage profile that
defines its meaning.
Replace: with a URI.
The profile is identified using a URI.
Replace: Profiles may be defined by anyone - in
separate standardization efforts, internally in organizations or for proprietary usage, etc.
With: Where profiles are defined is left
The base is simply a set of minimum
requirements for all abstract processes. Profiles are created from the
base. One or two profile(s) will be
given in the specification. They/it will show how one can create a
by building on the base.
[The TC will rework
the 1.1 AP definition into a profile with a defined URI.
is left open, at the moment, whether the base definition itself is to
be considered as a profile. If it is, it will be assigned a URI to
identify it] )
It is left open whether another profile will be
defined in the
specification that is identical to the base. If so, it will be given a
URI to identify it and added. It is suggested that a separate, new
issue XX be opened for this. The dependency (by allowed closing order)
of these three issues is: 82, XX, 158.
**addressing (e, 3)**
The placement of these profiles and other questions concerning the structure
of the ultimate specification and how many documents there will be will
be left open and dealt with as part of 158]
Issue 158 cannot be closed until 82 is closed.
**addressing (g) **
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 to the
usage profile a particular abstract
process definition belongs to.
 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.
 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
The semantics and consistency
constraints of executable BPEL are clearly defined. The semantics of
**addressing (g) **
construct in an abstract process
**addressing (g) **
derived from that of the same
construct in executable BPEL.
(i.e. an invoke is always an invoke).
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).
Replace: Addionally, an abstract
process is required to be
syntactically valid using the executable schema extended with the
Additionally, an abstract process is required to be syntactically valid
using the BPEL schema, that accommodates extension with opacity and
omissions as detailed in bullet 3 above. One schema exists for abstract
and executable BPEL. (Check that this is consistent with resolution of
 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
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.
This is used for checking the syntactic validity of an abstract process
not for process semantics.
 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
 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*
Replace: it permits
With: that are
permitted by the profile the abstract process references.
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.
Choreology Anti virus scan completed
Choreology Anti virus scan completed