Web Services Business Process Execution Language Version 0 Public Review Draft 02, 20 November, 2006

This is especially relevant to the addition of links. New links cannot be added as targets to existing activities with at least one link if such an addition changes an existing, non-opaque join condition (including the default join condition). The default join condition is included in this consideration because adding a new link to an activity using the default join condition effectively changes the condition to include the new link’s status. Examples where new links can be added include adding them to: 1) an activity with no existing incoming links, 2) an activity with incoming link(s) and an opaque join condition, or 3) an activity with incoming link(s) and an explicitly specified, non-opaque join condition (whose value cannot be changed in any executable completion).

Definition (Basic Executable Completion). A Basic Executable Completion of an Abstract Process is defined as an Executable Completion whose allowed syntactic transformations MUST be  limited to:

• 
  Opaque Token Replacement (1. (b) i. above),
  
• 
  the addition of a start activity if none are present in the Abstract Process (per clause [5] of section 13.1.3. Hiding Syntactic Elements), and
  
• 
  the addition of ,
  ,
  , , elements at the
  level, as long as the declarations of any such newly added elements are not referenced by existing constructs in the AP (before opaque token replacement).
  

• 
  It conforms to the WS-BPEL XML Schema for the common base, as defined in Appendix E. XML Schemas. This is purely an XML Schema check and does not enforce any non-Schema validation rules, such as requiring that every link that has a source must also have a target.
  
• 
  Any extension construct, including the extension attribute, elements, extension activity and extension assign operations, is declared properly with the "namespace" and "mustUnderstand" not being opaque (including omission-shortcuts). See more details in sections 5.3. Language Extensibility and 14. Extension Declarations.
  
• 
  There exists at least one Basic Executable Completion of the Abstract Process.
  

There is no fundamental expressive power distinction between Abstract and Executable Processes. To accommodate the syntactic flexibility introduced by allowing opacity and omission in the syntax of Abstract Processes, the XML Schema for the Common Base of Abstract Processes does not reuse any definitions from XML Schema for the Executable Processes. The two have distinct namespaces: one for Abstract WS-BPEL Processes and one for Executable WS-BPEL Processes.

At the same time, an Abstract Process Profile may be required to extend the level of syntactic validation from that of the common base to support the inclusion of additional information necessary to it. Therefore an Abstract Profile MAY provide:

• 
  extension constructs in its own namespace to be added to the Abstract Process,
  
• 
  additional XML grammar to support its own specific syntax validation.
  

13.1.5. Interpretation of the Common Base

In addition to semantics, the consistency constraints of Executable WS-BPEL are clearly defined. The semantics of each language construct in an Abstract Process MUST be derived from that of the same construct in Executable WS-BPEL. For example, an in an Abstract Process always represents invoking a Web service operation as used in Executable Processes. The difference is strictly a consequence of the opacity used in that construct (missing information) and other parts of the process affected by it (for example, opacity in a link source element may affect the link target element). Any required clarifications depending on allowed opacity will be specified in the relevant usage profile.

In the common base definition, there are no requirements how Executable realizations of a given Abstract Process should be implemented (i.e. language, platform, etc.); nor are specific relationships with such realizations implied. Again, a concrete usage profile might provide such information based on its use case.

13.2. Abstract Process Profiles and the Semantics of Abstract Processes

It is a profile that defines a class of Abstract Processes with a shared semantic interpretation. Abstract Processes are incomplete and by definition not Executable, whether or not they contain opaque entities. The semantics of the non-opaque constructs they contain cannot be understood in isolation. Their semantics are bound by the Executable Completions that are permitted by the profile referenced by the Abstract Process. The semantics of those constructs can be realized only in the possible Executable Completions. As an edge case, a permitted completion may sometimes be virtually identical to the Abstract Process syntactically, but this is the exception rather than the rule.

A WS-BPEL Abstract Process and a WS-BPEL Executable Process are said to be compatible if the Executable Process is one of the Executable Completions in the set of permitted completions specified by the Abstract Process’ Profile. Compatibility for Executable Processes that are not WS-BPEL processes is outside the scope of this specification. Clearly, an Executable Process can exist independently from an Abstract Process.

A profile MUST NOT violate the common base. A profile MUST define

1. 
   A URI that identifies the profile and is used as the value of the abstractProcessProfile attribute by all Abstract Processes belonging to this profile.
   
2. 
   The set of syntactically valid Abstract Processes that belong to this profile, as a subset of the common base. Note that the subset does not have to be proper, i.e., it may include the entire common base. Example profiles include those that disallow control links or certain types of opaque tokens. Note further that the subset must be consistent with respect to the use of the omission-shortcut. Specifically, if a profile limits the use of opaque tokens in the set of Abstract Processes it covers, then it can only permit those omissions that correspond to permitted usage of opaque tokens. For instance, if a profile does not allow attributes to be opaque, then Abstract Processes belonging to that profile cannot omit attributes using the omission-shortcut.
   
3. 
   The set of permitted Executable Completions for Abstract Processes that belong to the set in (ii). The set of permitted Executable Completions MUST be non-empty for each Abstract Process in the set in (ii).
   

If the allowed level of opacity in a profile leads to the inability to relate constructs in the abstract process, the profile MUST provide additional syntactic constraints to ensure that a user can match the constructs. Examples include a receive/reply pair with opaque operation attributes, or a link source/target pair with an opaque name attribute.

Another example is a profile that allows “Opaque Token Replacement” and the addition of only WS-BPEL constructs that create leaf-nodes or sub-trees. By disallowing arbitrary additions, such a profile would not allow Executable Completions to do such things as wrap an existing activity with a , or add a around activities in a . On the other hand, it would allow the creation of new leaf activities inside an existing .

13.3. Abstract Process Profile for Observable Behavior

There are several key differences between processes intended to represent business process contracts and Executable Processes. Foremost among them is the different way in which data are handled in each case; the rich data manipulation that occurs in Executable Processes need not be described in public process contracts. Instead, public process contracts use non-deterministic data values to hide the private aspects of executable behavior. For example, using opaque assignment supports modeling the non-deterministic effects that private computation has on external behavior.

In this profile, the use of opacity is 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 to remain private.

13.3.1. Profile URI

http://docs.oasis-open.org/wsbpel/2.0/process/abstract/ap11/2006/08

13.3.2. Subset of the Processes Allowed in the Common Base

This profile applies opacity in WS-BPEL constructs that handle data. In addition, the omission-shortcut described in 13.1.3. Hiding Syntactic Elements can be used as an alternative to explicitly specifying opaque tokens. The profile described here allows the use of opaque activities specifically for supporting the two cases where an activity is syntactically required. The first is hiding internal processing that needs to be the source or target of links in the Abstract Process, while maintaining the same flow of control in the abstract representation. The second is the use of opacity (and consequently the omission shortcut) in places where an activity is required by the WS-BPEL semantics and Schema. For example, Executable Processes are required to have an activity in a fault handler. Using an opaque activity avoids the need to use an activity. The use of opaque activities where an activity is not syntactically required is superfluous, because this profile’s completion rules are flexible about where one can add an activity in an Executable Completion. The full completion rules are presented in the next section.

This profile restricts the use of the Abstract Process Common Base in the following manner:

• 
  Expressions: is not allowed to be opaque. The has a default value, and is based only on of the status of the incoming links, and not on data handled by the process.  Therefore, it is not appropriate to hide it. All other expressions may be opaque, as defined in section 13.1.3. Hiding Syntactic Elements.
  
• 
  Activities: The use of is not allowed.
  
• 
  Attributes:  Only the attributes used for identification of variables and message parts of message related constructs representing partner interactions are allowed to be opaque. The full list of the attributes allowed to be opaque is shown below. The following is the complete list of attributes, belonging to the , , , , or constructs, that are allowed to be opaque in this profile:
  
  • 
    variable, inputVariable, outputVariable attributes.
    
  • 
    part and toVariable attributes of  the element.
    
  • 
    part and fromVariable attributes of element.
    
• 
  From-specs: Opaque from-specs are allowed.
  

13.3.3. The Use of Opaque Variable References

Executable Processes are expected to follow constraints such as initializing variables before they are used. Clearly, Executable Completions of Abstract Processes that hide variable references and data manipulation are expected to abide by the constraints and requirements of executable processes.

13.3.4. Subset of the Executable Completions Allowed in the Base

In order to achieve the intent of the profile, 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. The completion rules provided below aim to enforce this restriction.

Data writing may cause changes in interaction order. Changes caused by data writing are not enforced by the completion rules, but are highlighted here as an advisory note. One example is 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 loop with a “true” condition as a child of an existing would hang the process.

When creating an executable completion of an abstract process belonging to this profile, the possible locations for adding new activities are not explicitly defined: Activities may be added anywhere that the Executable Completions definition in section [see 13.1.4. Syntactic Validity Constraints] allows with the restrictions below.

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 declared 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 (whether using an 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.
  
• 
  The lexical parent of an existing BPEL construct (including activities in particular) present in the abstract process MUST NOT be changed in an executable completion. Hence, the nesting structure of composite activities around any activity in an abstract process remains 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:
  
  • 
    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, except as disallowed above.
      
    • 
      Adding a new link definition to an existing flow, except as disallowed above.
      
  • 
    Examples of illegal additions:
    
    • 
      Adding a activity around an existing activity.
      
    • 
      Adding a new scope around an existing variable definition.
      
• 
  A valid executable completion MUST NOT add:
  
  • 
    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.
    
  • 
    New branches to an existing pick activity.
    
  • 
    New fault, compensation, or termination handlers to an existing scope. However, they may be added at the process level.
    
  • 
    activities.
    
  • 
    New links whose targets are existing activities. The Executable Completions definition in the Base already disallows adding new links to existing activities that have existing links and use the default join condition. This profile restricts this further by disallowing the addition of new links to any existing activity. However, one may freely add links targeting new activities as long as those activities are not a replacement of one of the abstract process’s opaque activities.
    
  • 
    Declarations of variables, partner links, and correlation sets in existing scopes if they hide existing declarations that are used by existing constructs in the scope.
    
• 
  Activities that throw non-standard faults (e.g. web service activities whose operations define faults, ) MAY be added only if the exception will not be propagated to any activity existing in the Abstract Process. For example, consider adding an activity A as a child of an existing sequence S. Then, one may only add a 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.