Re: [wsbpel] Issue 82 - Closer to spec wording.

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

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.