Re: [wsbpel] Issue 107 - Proposal to Vote (pending 82)

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

Here it is again, without changelog. This is a proposal to vote, pending 
82 passing with same concepts.

Expanding on Peter's existing 107 proposal (details, syntax, examples), 
assuming
concepts in 82 (base+profiles) :
----------------------------------------------------------------

15.1 Language extensions for Abstract Processes

The language extensions consist of opaque tokens which are used as 
explicit 'placeholders' for
missing details. Note that "opaque" is not a new semantically meaningful 
construct but a
syntactic device for indicating incompleteness. As such, "opaque" 
entities have no semantics
of their own.

There are three kinds of opaque placeholders: expressions, activities,
and attributes. A usage profile may restrict the kinds of opaque tokens 
allowed at its discretion.
For example, a profile could specify that it allows only opaque 
activities, but not opaque
expressions and attributes, or a profile could specify that it allows 
all attributes to be opaque
except the “partnerLink” attribute. However, a usage profile may not 
expand it above what is
allowed by the "common base". For example, a profile cannot specify that 
it allows <faultHandler>
elements to be opaque.


-Under the 'common base' section
---------------------------------

Three types of opaque tokens are allowed in abstract processes:
activities, expressions, and attributes. The functions of these opaque
placeholders are described below, with examples:

Part A - Opaque activities:

An opaque activity explicitly is a placeholder for exactly one 
executable BPEL activity (not counting
any activities that could be nested within that single executable 
activity) whose behavior is not relevant
to the recipient/user of the abstract process. An opaque activity is a 
BPEL activity and therefore has
the same standard elements and attributes that all BPEL activities have 
(see spec section 11.1 and
11.2). It has the following form:

<opaqueActivity standard-attributes>
standard-elements
</opaqueActivity>


One examples of using opaque activities includes creating process
templates (marking the points of normative extension in a
process). Another is when creating an abstract process from a known
executable process and wanting to hide an activity that is a join
point for several links. If that activity, on the other hand, had just
been an unlinked activity in a 'sequence' it could have just been omitted
from the resulting abstract process.

At first glance, it seems that this could instead be done using
<empty>. The difference is that <empty> explicitly says "nothing happens 
here,"
whereas <opaqueActivity> is really saying "something happens here, but 
it's hidden
on purpose".

A.1 Opacity of activities allowed in the base:
Opaque activities are allowed.

PART B - Opaque expressions:

Opaque BPEL expressions shall be allowed exclusively for the use of 
abstract processes. An opaque
expression explicitly hides a corresponding executable BPEL expression.

An example usage of an opaque expression is that of copying a hidden 
value into a known variable.
Opaque assignment can be used to express non-determinism: the obvious 
case being a process
that needs to show a decision point with alternative outcomes without 
specifying how the decision
is reached. In this case the expressions that constrain each branch may 
need to be left unspecified,
but it may also be convenient to make a specific value or quantity such 
as a price threshold
unspecified, so that explicitly specified conditions relative to the 
threshold become
non-deterministic as a result of the threshold value being unknown.

All expressions in BPEL, and their corresponding opaque representations are
listed below:

1-Boolean valued expressions:

-Transition Condition:
<transitionCondition expressionLanguage="anyURI"? opaque="yes"/>
-Join Condition:
<joinCondition expressionLanguage="anyURI"? opaque="yes"/>
-While Condition:
<condition expressionLanguage="anyURI"? opaque="yes"/>
-Switch Case Condition (editors’ note: reflect new if-then-else syntax) :
<case>
<condition expressionLanguage="anyURI"? opaque="yes"/>
activity
</case>

2- Deadline valued expressions:

-Until element of onAlarm and wait:
<until expressionLanguage="anyURI"? opaque="yes"/>


3- Duration valued expressions:

-For element of onAlarm and wait:
<for expressionLanguage="anyURI"? opaque="yes"/>

-repeatEvery element of onAlarm:
<repeatEvery expressionLanguage="anyURI"? opaque="yes"/>

4- Opaque From-Spec in Assignment:

(Issue 103)

<from expressionLanguage="anyURI"? opaque="yes"/> is allowed, and 
represents
hiding any of the forms of the 'from-spec'.

-Opaque assignment (<from opaque="yes"/>) is used for capturing variable 
creation/modification
in a yet-to-be-concretized mechanism/fashion. See section 9.3.

(editor’s note: update with any new expressions from any new activities)

B.1 Opacity of expressions in the common base:

All BPEL expressions are allowed to be opaque. The generic form of
opaque assignment is also allowed.


PART C - Opaque attributes:

An opaque attribute hides the value of an executable BPEL attribute.

For example, an opaque variable attribute in a receive activity hides
where the data is stored once the corresponding message is received.

The reserved value “##BPELopaque” shall be made available for use as the 
value of any BPEL
attributes in a BPEL abstract process that can be opaque. (editor’s 
note: this may change to make
sure have a value for attribute types based on XSD.

C.1: Opacity of attributes in the common base:
All BPEL attributes are allowed to be opaque in the common base.


---------

Rania's note on spec editing :
if 82 passes, then A.1, B.1, and C.1 could go in the bullets of the
common base where it says that it depends on 107.