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

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Proposed suggestions or clarifications sought for Issue 82:

==============================================================================================================

1. Emphasis that a profile created from the abstract process assumptions 
in v1.1 is an example of how to constrain or build from the base. It is 
not the base.

2. For statement: "Every AP instance will always refer to a profile URI 
to define its meaning." I would suggest we concentrate on the core AP 
definition as a guiding principle. I would separate the concepts 
explicitly between a) the core AP definition [1], b) profiles, and c) 
Any profile we give as an example such as AP v1.1.

[1] Concentrate on lightweight, template-like semantics recognizing 
abstract processes are incomplete, could include opaque entities and may 
serve as the basis
of creation of an executable process through various means.

3. Link Issue 82 to 158 to resolve the construction of the specification 
and leave it that except to say that the document construction will be 
handled before Issue 82 can be fully closed (dependency). [2]

[2] The abstract process definition should keep Issue 158 on track.

4. Ambiguities should be limited/focus on non-substantive changes to the 
accepted concept,  i.e. editorial comment, further clarification that do 
not change the substance of the accepted proposal, which I believe was 
the agreement.

5. Other specific changes:

Change From [letter such as 'a'] / Change To [letter such as 'a1']:

Note: Clarifications identified as such.

a. 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'.

a1. Whereas executable processes are fully concretized and thus can be 
executed, an abstract process MAY lack some of the required concrete 
operational details expressed by a fully executable artifact. An 
abstract BPEL process must be explicitly declared as 'abstract'.

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

b1. Abstract processes serve a descriptive role, with more than one 
possible purpose. A BPEL abstract process can define the publicly 
visible behavior of all of the services it offers....

Reasoning: The use of 'some" because it confuses an example of 
description of an example of use. From a reference from Peter Furniss, 
an abstract process could refer to only one service of something that 
has executables that offer multiple services - one could have a 
customer-facing link, defined by the abstract process, and a management 
link that wasn't in that abstract process (but might be in another one 
that also mapped to the same executable).

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

c1. The process "template" captures some essential process logic while 
leaving out operational details. These details MAY be concretized in 
resulting fully executable artifact(s) by enterprises and vertical 
standards organizations.

d. 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 behavior of the executable process as a whole, and 
is thus not directly available outside an executable process.

d1.  From this base, "usage profiles" can be defined. Executable 
processes have well-defined semantics that may not be relevant, visible 
or exposed in a base or profiled abstract process definition.

Reasoning: The semantics could be indicative (even if implicit) of the 
profiled domain.  Assumptions may be made because of the use of BPEL 
constructs or what can replace opaque or missing entities (such as 
suggested by Peter).

e. The semantics of an abstract process are therefore derived from those 
of the executable process it could be mapped to.....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.

e1. The semantics of an abstract process are therefore derived from 
those of the executable process....An abstract process  MUST identify 
the usage profile  that defines its meaning with a URI. Profiles may be 
defined outside of this specification.

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

f1. The base definition is considered as a profile. When used, it will 
utilize the URI assigned to it.

Semantics of Abstract Processes:

g. The semantics and consistency constraints of executable BPEL are 
clearly defined. The semantics of each construct in an abstract process 
are always derived from that of the same construct in executable BPEL.

g1. The semantics and consistency constraints of executable BPEL are 
clearly defined. The semantics of each construct in an abstract process 
MAY BE derived from that of the same construct in executable BPEL.

Reasoning: Given the fact we can add constructs, is it actually true 
that the semantics of the abstract ARE ALWAYS derived from the 
executable? Some of the executable process constraints will not apply to 
specific abstract process instances, depending on what is abstracted 
out. Therefore, MAY is an appropriate qualifier.

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

h1. Additionally, an abstract process is required to be syntactically valid.

Reasoning: What happens when we have an opaque entity and it is not 
replaced in an executable process? Even if the abstract and executable 
are syntactically valid individually, can we also always say the 
abstract is syntactically valid to the executable? Abstract process 
syntax alters executable process syntax in at least two ways:

    * Addition of opaque activities and attributes
    * Relaxation of cardinality constraints 

 From this strictly syntactic point of view, Ron and I can't see how an 
AP can be required to be EP schema valid, with or without the addition 
of opaque entities.

j. [4] In this base definition, to avoid absurd constructs and to 
clarify opacity, the minimal 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.

j1. Clarify: This is used for schema validation on an abstract process 
not for process semantics.

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

k1. Clarify: How can we deny the existence of AP semantics, but only 
acknowledge the semantics of resulting EPs?
==========================================================================================================

> FURNISS, 13 DECEMBER 2004: Following some discussion, this is a 
> revised version of the issue 82 proposal (proposals on the other 
> abstract issues have been separated, as asked).
>
> This version has more detail on the concept of profiles, but does not 
> make them mandatory. It's a merge of different ideas (messed up by me 
> probably).
>
> 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 may 
> identify the usage profile it belongs to with a URI. Profiles may be 
> defined by anyone - in separate standardization efforts, internally in 
> organizations or for proprietary usage, etc.
>
> The section [x.x] is such a usage profile for abstract processes, with 
> the same purpose as the abstract process definition from BPEL1.0/1.1, 
> with minor modifications.
>
>  
>
> 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.