[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82 - Closer to spec wording.
Hi everyone,
Here is where spec wording on 82 is at the moment. This was created by
taking the text from the final revision of 82, grouping sections and
tweaking others to get a coherent continuous description. I tried to
comment the sources of some of the sections.
In the interest of time, I am sending this to the main list for review
and comments.
regards,
Rania
-----
Abstract Processes. Major Diffs in Spec.
1. Introduction
----------------
•Move from Intro and use as input to AP1.1 refactoring section:
-last four sentences of second paragraph. The third paragraph.
•Reword:
- Fourth paragraph to : “What are the concepts required to
describe business processes? To answer these questions, consider the
following”.
- Substitute “Business Protocols” with “Business processes” in the
bullets of this paragraph.
•Move from Intro, and use as input to AP1.1 refactoring section:
-“if we wish to provide …. to capture the essence of public
behavior while hiding private aspects.”
•Delete:
-“A WS-BPEL process can define a business protocol role, using the
notion of abstract process…. In addition abstract processes use
nondeterministic data values to hide private aspects of behavior”.
•Add (right before “The basic concepts of WS-BPEL can be applied in one
of two ways …”):
(From first section of Peter’s text, with minor changes).
It is also possible to use ‘abstract’ WS-BPEL processes. A BPEL abstract
process is a partially specified process that is not intended to be
executed and that must be explicitly declared as ‘abstract’. Whereas
executable processes are fully concretized and thus can be executed, an
abstract process may abstract away some of the required concrete
operational details expressed by a fully executable artifact. All the
constructs of executables processes are made available to abstract
processes; consequently, executable and abstract BPEL processes share
the same expressive power. In addition to the features available in
executable processes, abstract processes provide two mechanisms for
abstracting away operational details: (1)omission and (2)the use of
explicit opaque tokens. Although a particular abstract process
definition might contain complete information that would render it
executable if interpreted as an executable process, its abstract status
states that any concrete realizations of it are permitted to perform
additional processing steps that are not relevant to the audience to
which it has been given.
Abstract processes serve a descriptive role, with more than one possible
use case. One such use case for an abstract process might be to describe
the publicly visible behavior of some or all of the services an
executable process offers (represented by "myRole" in the relevant
partnerLinks). Another use case might be to define a process "template"
embodying domain-specific best practices. For example, such 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.
Regardless of the purpose, all abstract processes share a common
syntactic base. However, they actually have different, possibly
conflicting, requirements for the levels of opacity and restrictions or
relaxations on which parts of a process definition may be omitted or
hidden, i.e. the overall level of incompleteness. Hence, different uses
of abstract processes have different effects on the consistency
constraints required in executable processes, and on the semantics of
that process. In order to address this flexibility, a
‘base-and-profiles’ approach is provided in section 15 for defining
abstract processes.
A common base specifies the features that define the syntactic universe
of abstract processes. However, the base lacks well-defined semantics.
Given this common base, a usage profile provides the necessary
specializations and the semantics based on executable BPEL for a
particular usage area of an abstract process. For example, one profile
might focus on publicly visible behavior; another profile might focus on
process templates of particular granularity.
• Substitute “business protocols” with “abstract processes” in the
paragraph starting with “Even when …”
• Reword:
-Sentence starting with “In summary, …”
-to “In summary, we believe that abstract business processes and
executable business process descriptions require a common core of
process description concepts.”
6.2. The Structure of a Business Process
-----------------------------------------
•Add to structure (xml) at top level: abstractProcessProfile=”anyURI”?
•Add to bullets “the top-level attributes are as follows”:
-abstractProcessProfile: This attribute provides the URI that
identifies the profile of an abstract process. It MUST be used if
abstractProcess=”yes”.
8.1.1 Motivation for Message Properties
----------------------------------------
Message properties are defined here in a sufficiently general way to
cover message context consisting of implicit parts, but the use in this
specification focuses on properties embedded in application-visible data
that is used in abstract business processes.
9. Data Handling
------------------
• Replace second paragraph with:
Executable processes are permitted to use the full power of data
selection and assignment but are not permitted to use opaque values.
Abstract processes, on the other hand, are permitted to hide behavior.
Detailed differences are specified in the following sections.
14. Extensions for Executable Processes
----------------------------------------
• Refactoring of this section waits on 158. Either way, 14.1, 14.3 and
14.6 move to relevant sections in main part of spec so that constructs
in abstract are superset of those in executable BPEL.
•Replace old section 15 with:
------------------------------
15. BPEL Abstract Processes
---------------------------
Abstract processes have multiple usage areas. Consequently, a base and
profiles approach is provided for defining abstract processes. The
common base, defined in section 15.1, specifies the features that define
the syntactic universe of abstract processes. However, the base lacks
well-defined semantics. Given this common base, a usage profile provides
the necessary specializations and the semantics based on executable BPEL
for a particular usage area of an abstract process. Nevertheless, every
abstract process MUST identify the usage profile that defines its
meaning. A profile is identified using a URI. This approach is
extensible: new profiles can be defined as different areas are
identified. Where these profiles can be defined is unspecified.
Profiles are created from the base and their characteristics are defined
in section 15.2. [One/two ] profile[s] will be provided in the
specification. [They/it] will show how one can create a profile by
building on the base.
15.1 The Common Base:
The common base is simply the *syntactic form* that all BPEL abstract
processes must conform to. The level of completeness, among other
things, is specified in the usage profile for a particular abstract
process definition. [from Peter’s 1]
The syntactic characteristics of the base are:
•The abstractProcess attribute MUST explicitly be set to “yes”.
•(Peter [2]) All the constructs of executable process are permitted.
Thus, there is no fundamental expressive power distinction between
abstract and executable processes.
•(Peter [3]) Operational details that are mandatory for BPEL executable
processes may be omitted through the use of "opaque" entities of various
types (i.e. elements, attributes, etc.) or through the omission of
specific BPEL constructs.
-Therefore, the following extensions are made to the syntax of
executable BPEL, to allow the following opaque entities:
[***Expected from 107 ***]
-Omission of all syntactically *required* attributes and
expressions is allowed, as long as the omitted artifact has no default
value. This omission is equivalent to representing the omitted artifact
with an opaque value. Note that this implies that the profile being used
permits that artifact to be opaque.
•A process must be ‘valid’:
-(Peter’s 3) After injecting opaque tokens any where they have
been omitted, it complies with the BPEL schema that accommodates
extension with opacity as defined in bullet 3 above. Hence, there is
only one schema, for abstract and for executable BPEL. (Check that this
is consistent with resolution of 24).
-(Peter’s 4) There exists at least one syntactic completion that
yields a *valid executable process* using the following manipulations):
-Defining all opaque tokens.
-Adding new elements.
The purpose of the latter check is for *syntactic* validity, in that it
limits the creation of absurd BPEL constructs that the XML Schema would
otherwise allow.
15.1.2 Semantics and consistency of the common base:
-----------------------------------------------------
(from Peter’s main) The common base, being extremely flexible, lacks
well-defined semantics. On the other hand, executable BPEL processes
have well-defined semantics and prescribed behavior. The semantics of an
abstract process are provided by the range of executable BPEL processes
that the particular abstract process represents. This range is provided
in usage profiles, and varies from one profile to another. In other
words, the semantics of an abstract process depend on its associated
profile.
[From Peter’s 3]In addition to semantics, the 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). Any required clarifications depending on allowed
opacity will be specified in the relevant usage profile.
(Peter’s 5) In the common base definition, there are no requirements on
how executable realizations of a given abstract process should be
implemented (i.e. language, platform, etc) (c.f. analogy to WSDL); nor
are specific relationships with such realizations implied. Again, a
concrete usage profile might provide such information based on its use
case. Note that the requirement in the common base for the existence of
at least one possible syntactic completion in section 15.1 is used for
validation.
15.2 Abstract Process Profiles:
---------------------------------
Having defined the level of opacity and omission abstract processes, we
now look closer at what this opacity means in practice. The semantics
and consistency of executable BPEL processes are well -understood and
laid out in this specification. The minimum requirements that a BPEL
abstract process must conform to for it to be valid are defined in the
common base definition. The combination of these two enables one to
clearly define usage profiles that characterize classes of abstract
processes based on the associated use case. In other words, a usage
profile provides and the information necessary to understand a
particular abstract process.
[From Peter’s 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 exist 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.
The characteristics of a profile are:
-A profile MUST NOT violate the common base; i.e., the set of abstract
processes conformant to a specific profile must be a subset of the
universe of abstract processes permitted by the common (syntactic) base.
-A profile MUST specify:
-An identifying URI that processes written in it must refer to.
-The level of opacity it allows (for example: only such and such
attributes can be opaque, or X can only be opaque if Y is also opaque,
or activities as well as all attributes and expressions can be opaque,
etc). Note that omission in the base is a special case of opacity.
Therefore, limiting the opacity also limits what can be omitted: if a
profile disallows the opacity of a particular attribute or expression,
then that attribute or expression cannot be omitted in abstract
processes belonging to that profile.
-The effects of the allowed opacity on the consistency and restrictions
of affected constructs and the overall process, as a delta from
executable BPEL. For example, if a profile allows opaque ”operation”
attributes on receive and reply activities then that profile should
specify how a receive and a reply are matched.
-the rules and restrictions for creating the executable completions that
its usage permits.
A profile may specify additional information specific to its usage - for
example additional restrictions and guidelines, such as “don’t use any
links” or “don’t require a createInstance receive” - as long as they do
not violate the common base.
15.3. Abstract Process Profile for … (refactoring of AP1.1)
-------------------------------------------------------------
• To include refactoring of AP1.1, including old 15.1 and 15.2.
15.4 [optional, left open as part of 82] Abstract Process Profile for …
------------------------------------------------
• Reworking of the other profile that has been asked for, but is still
awaiting vote.
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Related Items agreed on as part of Issue 82:
------------------------------------------------
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]