OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Over all I like this language. I do have one question - why is the 
opaque activity only allowed to represent a single BPEL activity? I know 
that the restriction is a minor one since that activity could always be 
a sequence or flow but what would break if we said that an opaque 
activity represents one or more activities?

What I'm trying to avoid is a situation where people think they need to 
do things like put two opaque activities right next to each other in a 
sequence. I can imagine people thinking that was necessary in the 
current text because of its requirement that an opaque activity be 
replaced by a single BPEL activity.

		Yaron

Rania Khalaf wrote:
> 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.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
>  From - Wed



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]