[Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications (withOUTchange log)]

[Rania Khalaf <rkhalaf@watson.ibm.com>]

Hi,

here is the text with proposed updates incorporated and no
highlighting of changes.
-----------

Proposal for Issue 82:

NOTE: 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 12/15/2004.


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 abstract process
may lack some of the required concrete operational details expressed
by a fully executable artifact. An abstract BPEL process must be
explicitly declared as 'abstract'.

Abstract processes serve a descriptive role, with more than one
possible purpose. 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.  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 organizations.
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.

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. The semantics of an
abstract process are therefore derived from those of the executable
processes to which it would be mapped.

To 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.  The profile is identified
using a URI. Where profiles are defined is left unspecified.

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 profile by building on the base.

[The TC will rework the 1.1 AP definition into a profile with a
defined URI.

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.

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.

       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 to the
usage profile a particular abstract process definition belongs to.

      [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 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 opaque value.

      The semantics and consistency constraints of executable BPEL are
clearly defined. The semantics of each language construct in an
abstract process are always 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).


      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 24).

      [4] 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 process* by

          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.

      [5] 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 realizations specified.

      [6] 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* 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.

      __