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

["Yaron Y. Goland" <ygoland@bea.com>]

One of the outcomes of the discussion around issue 81 is that it 
actually makes sense to allow for empty to occur before start 
activities. But I recognize that this is not a normative statement of 
the spec.

But in any case the other issues mentioned in my letter still stand.

Assaf Arkin wrote:
> 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. 
>>
>>
> 
>