[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]