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

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

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.

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