[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] 82.3 updated to reflect amendments (w minor clarification)
Hi guys, here is the updated version. Alex, I fiddled a bit more with the text on assign and endpoint references to make it clearer because 'an assign activity or otherwise MUST NOT' puts the focus on 'otherwise' and 'assign' so I think the new text is clearer yet still uses MUST NOT as you suggested. the text there now reads: • The endpoint reference of any partnerLink defined in the abstract process MUST NOT be modified (whether using an <assign> activity or otherwise). Additionally, an endpoint reference of any partnerLink defined in the abstract process MUST NOT be copied into the reference of a newly created partnerLink. The reason is that the former would effectively prevent subsequent interactions with that partner and the latter would add new ones. Remember that 'opaque token replacement' also replaces opaque tokens omitted through the omission-shortcut. This and the rest of the changes are in the attached document. Diane Jordan wrote: > > > Change busines sprotocol to behavior contracts > > Change must not back to caps > This section clarifies the meaning of using opacity of variables in > interaction activities. If _a _no variable_ reference_ is _opaque > _specified i_i_n a_n_n _inbound _interaction _message _activity which > receives an incoming message, then the abstract process _must not – and > has no way to - _MUST NOT subsequently_subsequently_ refer to the > received message or its properties, if any. If _a_the variable reference > is omitted _opaque _for an _outbound message _activity that sends an > outgoing message, then_ each executable completion must have already > initialized the _ any properties of the message_ that gets used by that > activity._ are considered to have been initialized through opaque > assignment, > > Delete these paragraphs: > > When variable references are _opaque_omitted in interaction _message > _activities, correlation set references may be interpreted as follows: > _[ryk1]_ > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00102.html#_msocom_1> > > > > > 1. When an incoming message initializes a correlation set > (initiator case), the correlation set is considered to be initialized. > > 2. When an outgoing message initializes a correlation set > (initiator case), the correlation tokens (message _(_properties) _must > be_are initialized _in any executable completion. _through an implicit > opaque assignment. > > 3. For an outgoing message which references but does not initialize > a correlation set (follower case), the proper initialization of the_ > _ message properties _ must be done in the executable completions. _is > implicit. In this case, the already initialized correlation set itself > provides the token values for the outgoing message. > > It is not possible to arbitrarily mix interaction _message _activities > that use variable references with those that don’t. If a correlation set > is initialized by rules 1 or 2 above, then outgoing messages using the > same correlation set MUST also refrain from referencing a message > variable. This restriction applies because it is not possible to > initialize the properties of the outgoing messages from the correlation > set alone. > > o Change from: "It is not allowed to modify (in an > <assign> activity or otherwise) the endpoint reference > of a partnerLinks..." > o Change to: "An <assign> activity or otherwise MUST NOT > modify the endpoint reference of a partnerLinks..." > > > > Regards, Diane > IBM Emerging Internet Software Standards > drj@us.ibm.com > (919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709 >Title: Web Services Business Process Execution Language
15. WS-BPEL Abstract Processes… 15.3 Abstract Process Profile for Observable BehaviorMotivationThe
objective of the Abstract Process Profile for Observable Behavior is to provide
precise and predictable descriptions of observable service behavior. The main
application of this profile is the definition of business process There
several a key differences between processes intended to represent business process
In this profile, the use of opacity is consequently concentrated in those features associated with data handling. Non-deterministic data values are not allowed in executable processes; abstract processes, on the other hand, use non-deterministic values to reflect the consequences of actual behavior while maintaining the details of that behavior private. Profile URIThe URI identifying this abstract process profile is: urn:oasis:names:tc:wsbpel:2.0:abstract:ap11<year><month> Subset of the Processes Allowed in the BaseThis profile is concerned mainly with hiding internal processing of a business partner while capturing all the information required to describe how the process interacts with its partners. The set of usage restrictions associated with the use of abstract processes in general was in fact derived from this original requirement, which was captured by the Abstract Process definition incorporated in the previous version of this specification (BPEL4WS V1.1, May 2003). It
has been mentioned already that this profile applies opacity in BPEL constructs
that handle data. In addition, the omission-shortcut
described in section 15 can be used as an
alternative to explicitly specifying opaque tokens. The
profile described here allows the use of opaque activities for supporting the
specific case where an activity is syntactically required. This profile restricts the use of the Abstract Process Base in the following manner: · Expressions: joinCondition is not allowed to be opaque. The joinCondition is based on the transition conditions of the incoming links, with a default value being the disjunction of the status of those links, and not on data handled by the process. Therefore, it is not appropriate to hide it. Other expressions may be opaque, as defined in section 15. · Activities: The use of <exit > is not allowed. · Attributes: Only the attributes used for identification of data containers of activities representing partner interactions are allowed to be opaque. Note that assigning to opaque containers is already available using the opaque assignment capability discussed in section 15, where one assigns from an opaque expression. The full list of the attributes allowed to be opaque is shown below. The following is the complete list of attributes, belonging to the receive, invoke, reply, onMessage, or onEvent constructs, that are allowed to be opaque in this profile: o "variable", "inputVariable", "outputVariable", o "part" and "toVariable" attributes of the "fromPart" element, o "part" and "fromVariable" attribute of "toPart" The level of abstraction appropriate in
the description of business process contract Subset of the Executable Completions Allowed in the BaseWith respect to executable BPEL completions of an abstract process that uses this profile, the intent of the profile requires a valid completion to follow the same interactions as the abstract process, with the partners that are specified by the abstract process. The executable process may, however, perform additional interaction steps relating to other partners. Therefore:
a completion MUST NOT change the presence or order of interactions already in
the abstract process, and it MUST NOT perform additional interactions with the
partner links defined in the abstract process. It is important to observe that
one way in which the order of interactions can be modified is by changing the
value of a variable used in a condition that affects branching in such a way
that the new effective branching behavior is in direct conflict with what is
specified by the abstract process. Conditions that affect the flow of control
such as transition conditions, “if-then” or “while”
expressions, among others, can have such an effect on the order of
interactions. For example, adding a new <while> loop with
a “true” condition as a child of an existing <sequence>
would hang the process. The possible locations of new activities are not explicitly defined in this profile. Activities may be added anywhere where completions to the base are allowed, as long as the restrictions enumerated below are followed. In this profile, the valid executable completions of an abstract process are obtained through both 'opaque token replacement' and 'addition of BPEL constructs', with the following restrictions: · New activities (including those created to replace opaque activities) MUST NOT interact with partnerLinks already defined in the abstract process. This rule does not affect adding interactions with new partnerLinks present in the executable completion but not in the abstract process. ·
The endpoint reference
of any partnerLink defined in the abstract process MUST
NOT be modified · The lexical parent an existing BPEL construct (including activities in particular) present in the abstract process MUST NOT be changed in a valid executable completion. Hence, the nesting structure of composite activities around any activity in an abstract process MUST remain unchanged in any legal completion. Some examples to illustrate this restriction are provided below. The word ‘existing’ is used in the examples to refer to constructs defined in the abstract process from which the executable completions are being created: o Examples of legal additions: § Adding a variable or a partner link to an existing scope S, even though that scope is the parent of existing activity A. § Adding a new link def to an existing flow. o Examples of illegal additions: § Adding a <while> activity around the existing activity A whose parent is another existing activity B. § Adding a new scope around an existing variable definition whose parent is an existing scope S. · A valid executable completion MUST NOT add: o New branches to an existing “if-then-else” activity, unless it has no “else” branch, and the new branch is added after all existing branches. o New branches to an existing pick activity. o New fault, compensation, or termination handlers to an existing scope. However, they may be added at the process level. o <exit> activities. · Activities that throw non-standard faults MAY be added only if the exception will not be propagated outside of the highest newly added ancestor of the fault-throwing activity. For example, consider adding an activity A as a child of an existing sequence S. Then, one may only add a <throw> within A if the fault it throws does not reach the scope of the existing sequence S. In other words, the fault must be caught and fully handled by A or its descendants, and not be re-thrown by them. Observe that executable completions MUST NOT add new links targeting an activity that exists in the abstract process. Adding such a new link would have the effect of changing the corresponding join condition, which is in violation of the completion rules of the base (since it modifies a non-opaque existing value). This restriction does not affect the addition of links to new activities that are not replacing opaque activities.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]