Issue 82 - resolution

As discussed on the TC call yesterday,
when we adopted the proposal below for 82 we agreed that we would put together
a list of questions identifying the areas of the resolution that are underspecified
or ambiguous.   There were no objections on the call to setting Jan
19 as the target date to have all of them identified.  If you have
such questions, please send them to the list.  We will include a review
of them on the agenda for that meeting.  

If you have a problem with this timing,
please let us know.  

Regards, Diane

IBM  Emerging Internet Software Standards



(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709

----- Forwarded by Diane
Jordan/Raleigh/IBM on 12/16/2004 03:19 PM -----

"Furniss, Peter"
<> 

12/15/2004 04:52 PM

To

<>

cc

Subject

RE: [wsbpel] Issue 82 - Proposed
resolution for vote (revised)

This is the revised text as agreed
on Tuesday, incorporating the amendments. 

 

1  Every AP iinstance will always refer
to a profile URI to define its meaning but we leave it open at this time
whether the core AP definition is a profile. 

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

3. The structure of the ultimate specification and how many documents there
will be will be left open and dealt with as part of 158.  

 

Further work is needed on areas that are unspecified or ambiguous in the
proposal.  Questions to be provided by the TC (date to be determined)
and then volunteers to address them will be solicited.

 

 

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 _
either through omission or explicit opacity.  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,
with more than one possible purpose. 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.

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. 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.
The semantics of an abstract process are therefore derived from those of
the executable process it could be mapped to. 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 with a URI. Profiles
may be defined by anyone - in separate standardization efforts, internally
in organizations or for proprietary usage, etc.  

 

[It 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] 

 

[The TC will rework
the 1.1 AP definition into a profile with a defined URI.
 The placement of this profile
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]

 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 construct
in an abstract process is derived from that of the same construct in executable
BPEL. 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).

Addionally, an abstract process is required
to be syntactically valid using the executable schema extended with the
opaque entities.

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

[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* it permits. 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. 

__ 

 

Peter

 

------------------------------------------

Peter Furniss

Chief Scientist, Choreology Ltd

web: http://www.choreology.com

email: 

phone: +44 870 739 0066

mobile: +44 7951 536168

 

Choreology Anti virus scan completed

Choreology Anti virus scan completed