Re: [wsbpel] Issue - 107 - Proposal to Vote

[Assaf Arkin <arkin@intalio.com>]

Yaron Y. Goland wrote:

> Imagine I have the following abstract process:
>
> process abstract="true"
>    sequence
>       opaque
>       receive
>
> I want it to be undefined in the abstract process definition if the 
> receive is a start activity or not. After all, if opaque is replaced 
> by empty then it would be legal for receive to be a start activity.

A start activity cannot follow a base activity, and the empty activity 
is a base activity.

Assaf


>
> The default value for createInstance is no. Therefore it is impossible 
> for me to leave the receive activity's status as a potential start 
> activity as undefined. Only if there was a createInstance="opaque" 
> would the ambiguity be possible.
>
> Similarly if I want to define a messaging operation but be ambiguous 
> as to what exactly message I'm sending or receive, I just want to 
> specify who I am communicating with, there is no way to do that if I 
> can't say operation="opaque".
>
> By not providing for opaque attributes I am required to specify 
> aspects of an abstract process that in a templating scenario I 
> wouldn't want to have to specify.
>
>         Yaron
>
>
> rkhalaf wrote:
>
>>
>>
>> This proposal affects spec section 15 (Extensions for Business
>> Protocols). I'm not going to do spec wording. This is split into four
>> parts: base, activities, expressions, and attributes.
>>
>> ---
>>
>> Base (w/ background):
>>
>> In abstract processes, operational details may be abstracted away
>> either through the omission of specific BPEL elements or attributes
>> listed in the specification, and/or through the use of opaque tokens.
>> 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.
>>
>> It must be stressed that opaque entities (activities, etc) are not the
>> only points of extension allowable in creating a process derived from or
>> related to an abstract process that uses them. In particular, a related
>> executable process MAY contain additional processing steps (activities,
>> fault handlers, etc) and  parterLinks including the extras that may be
>> required to carry these out(correlation sets, variables).
>>
>> Opaque entities:
>>
>> Part  A - Opaque activities:
>>
>> An activity called 'opaque' shall be introduced for the exclusive use of
>> abstract processes. An opaque activity explicitly hides a concrete BPEL
>> 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).
>>
>> Examples of using opaque activities include, but are not restricted to,
>> creating process templates (marking the points of normative extension
>> in a process) and edge cases where simple omission of an activity
>> creates a syntactic problem, e.g., if the omitted activity is a join
>> point for several links.
>>
>> At first glance, it seems that this could instead be done using "empty"
>> , but the difference is that "empty" explicitly says "I do nothing
>> here," whereas "opaque" is really saying "some magic occurs here but
>> it's hidden on purpose".
>>
>>
>> PART B - Opaque expressions (incl assignment):
>>
>> Opaque assignment (<from opaque="yes") is used for capturing variable
>> creation/modification in a yet-to-be-concretized mechanism/fashion. An
>> example of usage is 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.
>>
>> In addition to <from opaque="yes"/>, this proposal asks for allowing
>> transitionConditions  to be opaque. This avoids the default "true"
>> value. If an expression is opaque, the expressionLanguage attribute on
>> it is meaningless since there is no expression syntax to refer to.
>>
>> -sample syntax:
>> <transitionCondition opaque="yes"/>
>>
>> PART C - Opaque attributes:
>>
>> No change to the spec.
>>
>> (background info on why not attributes: They were originally proposed to
>> make all hiding explicit but there was a lot of resistance to that.
>> Then, they were proposed  for attributes that have defaults in BPEL -
>> but all the examples that were put forward created more agony than the
>> uniformity  using opaque would have brought to the table. The reason was
>> that they are core to the semantics of the constructs they are attached
>> to. Examples include suppressJoinFailure, isolated (scopes),
>> createInstance, and initiate (correlation sets). Therefore, I propose no
>> change to the spec.)
>>
>>
>> --- Rania
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>>
>>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

S/MIME Cryptographic Signature