Issue 82 - proposal to vote

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

Here is the combined 82. There was a request for one more item that 
there is disagreement on, so that will be brought up in the discussion 
and i will send it in a following note. I suppose the way to handle that 
is as an amendment that we vote on.

Regards,
Rania


----------------------------------
Abstract Processes. Major Diffs in Spec.

1. Introduction
----------------
•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 (abstract or executable) …”):

It is also possible to use ‘abstract’ WS-BPEL processes. A WS-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 WS-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). In one particular usage scenario, another use case might 
be to define a process "template" that may embody 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. We use ‘consistency constraints’ to refer to constraints 
required for a valid executable WS-BPEL process that are not enforceable 
by the XML Schema, such as requiring at least one receive with 
‘createInstance’ set to true or that every link with a source activity 
must have a target activity. 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 WS-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
-----------------------------------------
• Remove: abstractProcess=”true|false”

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 is mandatory for abstract processes.
• Delete:
"Although <exit> is permitted as an interpretation of the token
activity, it is only available in executable processes and as such is
defined in the section on Extensions for Executable Processes."

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 WS-BPEL.

•Replace old section 15 with:
------------------------------

15. WS-BPEL Abstract Processes
---------------------------------------

(editor’s note: a couple of sentences of intro)

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 defines 
the necessary syntactic constraints and the semantics based on 
executable WS-BPEL for a particular use case for abstract processes. 
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 WS-BPEL abstract 
processes must conform to. The syntactic characteristics of the base are:

[1] The abstractProcessProfile attribute MUST exist and have a value 
referring to an existing profile definition.

[2] All the constructs of executable process are permitted. Thus, there 
is no fundamental expressive power distinction between abstract and 
executable processes.

[3] Certain syntactic constructs that are mandatory according to the XML 
Schema for WS-BPEL executable processes may be hidden as in 15.1.1.

[4] An abstract process MUST comply with the syntactic validity 
constraint defined in 15.1.2.

15.1.1: Hiding syntactic elements.

The rules for hiding syntactic elements as mentioned in clause [3] are:

- The following syntactic entities may use an opaque form, using an 
extension to the syntax of executable WS-BPEL:
[***Expected from 107 ***]
- Omission may be used as a shortcut to opacity, from hereon referred to 
as "omission-shortcut". The “omission shortcut” is exactly equivalent to 
representing the omitted artifact with an opaque value at the omitted 
location. It is only allowed to omit tokens whose omission and omitted 
location can deterministically be detected. To enforce this, we restrict 
the omittable tokens to all [things from 107] which are both (1) 
syntactically *required* by the Executable WS-BPEL XML Schema, and (2) 
have no default value. If the omitted token is an activity, the implied 
opaque activity has the exact form <opaqueActivity/> (ie: no 
standard-elements or standard-attributes). Notice that (1) deliberately 
excludes any non-Schema requirements of executable WS-BPEL.

Therefore, an abstract process P1 that uses the omission-shortcut is 
always equivalent to an abstract process P2 that is the same as P1 but 
injects opaque tokens anywhere they have been omitted and does not use 
the omission-shortcut. To illustrate, consider a process that omits the 
variable attribute in all invoke activities. This is equivalent to 
another process which is identical to P1 except that it includes the 
'variable' attribute on all its invokes but with the value "opaque", and 
vice versa.

15.1.2 Syntactic Validity Constraints

An abstract process is valid if it meets both of the following criteria, 
referred to in clause [4] :

- After injecting any opaque tokens omitted through the 
omission-shortcut (ie: P1 -> P2 above), the resulting process is valid 
with respect to the WS-BPEL XML schema extended to allow for opaque 
tokens. This is purely an XML Schema check and does not enforce any 
non-schema validation rules, such as requiring that every link that has 
a source must also have a target.
(Editor’s note: Editors will manage schema details to comply with this 
statement. Alex has a suggestion that can be circulated. Main idea: 
"wsbpel_main.xsd" + "wsbpel_opaque.xsd”).

-There exists at least one "basic executable completion" of the abstract 
process (see definition below).

The purpose of the latter is purely syntactic, limiting the creation of 
absurd abstract processes that the XML Schema would otherwise allow. On 
the other hand, the semantics of an abstract process comes from the 
range of executable processes that can be created from the executable 
completions (i.e.: not limited to ‘basic executable completions’) 
allowed by its profile.

Definition: A "basic executable completion" of an abstract process is an 
"executable completion" whose allowed syntactic transformations are 
limited to (a) below.

Definition: An "executable completion" of an abstract process is an 
executable process that
• is derived using some combination of the following syntactic 
transformations:
a) Replacing every opaque token (including those omitted using the 
omission-shortcut above) with a corresponding executable token. For 
example, replacing an opaque activity with an <empty>.
b) Adding new BPEL XML elements and/or attributes anywhere in the process.
• is a valid executable WS-BPEL process that satisfies all static 
validation rules mandated by this specification including both 
schema-based and non-schema-based rules.

**Note: Special case will be allowed for the base if the createInstance 
receive issue is resolved such that that activity is allowed to be 
omitted in an abstract process since that has an open issue].


15.1.2 Interpretation of the common base:
-----------------------------------------------------
The common base, being extremely flexible, lacks well-defined semantics. 
On the other hand, executable WS-BPEL processes have well-defined 
semantics and prescribed behavior. The semantics of an abstract process 
are provided by the range of executable WS-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.

In addition to semantics, the consistency constraints of executable 
WS-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 WS-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 completions sections of the relevant 
usage profile.

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 
syntactic validation.

15.2 Abstract Process Profiles and the Semantics of Abstract Processes:
---------------------------------

The common base for abstract processes is a specification of the 
syntactic universe within which abstract processes are defined. It is 
not meant to provide any semantics for abstract processes since the 
semantics must express a specific intent for the interpretation of an 
abstract process and the common base provides no mechanism to express 
such intent.

Profiles are provided to define classes of abstract processes with a 
common (shared) semantic interpretation of the members of the class. 
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 (see below). The reason being that the semantics of those 
constructs can be realized only in the possible executable completions. 
As an edge case, a permitted completion may sometimes be in essence 
identical to the abstract process syntactically, but this is the 
exception rather than the rule.

A profile MUST not violate the common base. Specifically, a profile defines

(i) A URI that identifies the profile and is used as the value of the 
abstractProcessProfile attribute by all abstract processes that belong 
to the class defined by the profile.
(ii) A class of abstract processes that is a subset of the common base, 
i.e., the set of syntactically valid abstract processes that belong to 
the profile. Note that the subset does not have to be proper, i.e., it 
may include the entire common base. Examples include profiles that 
disallow control links or certain types of opaque tokens. Note further 
that the subset must be consistent with respect to the use of the 
omission-shortcut. Specifically, if a profile limits the use of opaque 
tokens in the class of abstract processes it covers, then it can only 
permit those omissions that correspond to permitted usage of opaque 
tokens. For instance, if a profile disallows opaque attributes, then 
syntactic consistency requires that attributes cannot be omitted in 
abstract processes belonging to that profile regardless of whether they 
have default values.
(iii) The set of permitted executable completions for abstract processes 
that belong to the class. The set of permitted executable completions 
must be non-empty for each abstract process in the class.

For example, a profile may include all the syntax of the common base, 
and only permit executable completions that replace opaque tokens 
(including those covered by the omission-shortcut) but not allow 
addition of syntactic elements. The class of abstract processes covered 
by this profile can only include abstract processes which, when 
completed within the constraint, represent valid executable processes. 
The profile must therefore specify additional syntactic constraints 
beyond those of the common base to ensure this. For example, specifying 
that a <reply> is the reply to the same operation as a prior <receive> 
when their operation attributes are opaque. The profile would do this in 
the completions section, by specifying how one can determine the 
replacement of the “operation” attribute in a <reply>.


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.

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.

The submission of proposals for these profiles is not bounded by the 
April 1st deadline.