wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Issue 82 - Proposal to resolve 82 and other abstract process issues
- From: "Furniss, Peter" <Peter.Furniss@choreology.com>
- To: <wsbpel@lists.oasis-open.org>
- Date: Wed, 1 Dec 2004 17:15:38 -0000
Title: Message
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]