Usage of BPEL Abstract Processes

Usage of BPEL Abstract Processes

Satish Thatte, May 21, 2004

Summary

One of the essential prerequisites for clarifying the form and intent of abstract BPEL processes and their relationship to the executable variant is to be clear on the intended usage for the abstract form. In this note we discuss the usage context for abstract processes as currently stated in the specification: this usage focuses on abstract processes as descriptions of externally visible or public behavior. We then discuss the pros and cons of the omission and commission approaches to missing details in abstract process definitions.

Abstract Processes for Externally Visible Behavior

The abstract of the current specification has this to say (emphasis removed):

Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes.

A business protocol in the full sense has two aspects. It involves specifying the behavior of multiple cooperating parties and it involves only externally observable or public aspects of process behavior. BPEL does not provide any formal “global model” notation to codify multi-party relationships. Therefore the intent expressed in the sentences quoted above applies primarily to the second aspect, i.e., to the specification of externally observable or public aspects of process behavior. More specifically, based on the current language in the specification, it would be more accurate to state the intent of abstract processes in the following way

An abstract process is a precise and independent description of the externally observable behavior of an executable process. Such a description may stand alone as the behavioral description of a single web service or a set of web services, or it may describe the behavior of one of the participants in a multi-party business protocol in which the interaction points defined by the abstract process must be coupled with corresponding interaction points of partner processes in a separate global protocol structure description.

Note that this description does not assert that all externally observable behavior of an executable process must be captured in a single abstract process. It is entirely possible that an executable process that interacts via multiple partner links will “project” its externally observable behavior relative to each partner as a separate abstract process. This is especially likely if the executable process acts as the hub with which each partner interacts without being aware of the other partners of the hub. Each abstract process is meant to be a complete description of external behavior relevant to the partner(s) it interacts with. The relationship between abstract and executable processes is thus in general many-to-one rather than one-to-one, rather like the relationship between interfaces and classes in OOP. In the world of Web services, WSDL is used to define the static aspects of service (and process) interfaces, and abstract processes are meant to be used to augment that with dynamic aspects.

Who Will Define Externally Visible Behavior and Who Will Use It?

There are two scenarios for the creation of abstract processes and two orthogonal scenarios for their use.

Definition Scenario 1: A web service provider wishes to augment the service interface structural contract with a behavioral contract, since the service is Stateful and represents an interface on an underlying business process. The behavior of the service is defined as an abstract process. In this scenario it is possible that more than one portType will be involved on the service provider’s side. However the partnerLinks will be onesided, i.e., there will only be “myRole” elements and no “partnerRole” elements. In other words, the process does not prescribe any requirements on the partner except to respect its behavior.

Definition Scenario 2: There is an entity defining a business protocol among multiple parties and it wishes to precisely describe the externally visible behavior of each party. This may be accomplished using an abstract process description for each party but in this case it is likely that symmetric partnerLinks will be used and the multiple parties will play different roles in these links. Examples of entities defining such protocols include large enterprises defining protocols for their partners and vertical standards organizations defining business protocols for their domains (e.g., RosettaNet for supply chain).

Usage Scenario 1: An abstract process can serve as very precise formal documentation of behavior for human understanding. It may replace voluminous and often ambiguous sets of rules expressed in natural language and reduce the scope for misunderstanding and error. In such cases the usage has no automated component. This usage scenario applies to both the definition scenarios.

Usage Scenario 2: An abstract process for a specific party in a business protocol in Definition Scenario 2 can be used in tools as a template for implementation. The abstract process definition may be imported and then filled out and refined to create an appropriate executable process. It is also conceivable that a tool may be able to export an abstract process describing the externally visible behavior ofthe web service in Definition Scenario 1 based on an underlying executable process. In this usage scenario there is a natural question of conformance between the abstract process and the corresponding executable process.

The Expressive Power of Abstract Processes

Given that abstract processes are meant to represent public behavior, which necessarily omits many details found in executable process models, one natural question to ask is whether public behavior description needs the same degree of expressive power as executable models. One conceivable approach is to actually use a simpler and less expressive notation for public description which would in some sense force the omission of details by not providing the power to express them. BPEL has taken a different approach. Quoting from the introduction section of the specification

What are the concepts required to describe business protocols? And what is the relationship of these concepts to those required to describe executable processes? To answer these questions, consider the following:

• Business protocols invariably include data-dependent behavior. For example, a supply-chain protocol depends on data such as the number of line items in an order, the total value of an order, or a deliver-by deadline. Defining business intent in these cases requires the use of conditional and time-out constructs.
• The ability to specify exceptional conditions and their consequences, including recovery sequences, is at least as important for business protocols as the ability to define the behavior in the "all goes well" case.
• Long-running interactions include multiple, often nested units of work, each with its own data requirements. Business protocols frequently require cross-partner coordination of the outcome (success or failure) of units of work at various levels of granularity.

If we wish to provide precise predictable descriptions of service behavior for cross-enterprise business protocols, we need a rich process description notation with many features reminiscent of an executable language. The key distinction between public message exchange protocols and executable internal processes is that internal processes handle data in rich private ways that need not be described in public protocols.

Thus the specification of abstract processes in BPEL is based on the premise that omission of detail cannot and should not be forced by constraint on expressive power since it is difficult if not impossible to make a hard distinction between the expressive power required for abstract processes and what is required for executable ones. Omission of detail should be facilitated by allowing the omission of certain syntactic elements in abstract processes even though executable processes do not allow such omission because these elements are required for complete specification of executable behavior. But we must recognize that omission of details can occur without the use of this syntactic license, i.e., it is possible to construct an abstract process that omits semantically essential details without violating the schema requirements for executable processes.

Conformance Verification

If an abstract process claims to be the externally observable behavioral description of (some aspect of) a previously existing executable process, or vice versa, an executable process claims to faithfully implement external behavior as previously specified in an abstract process, we must be able to define the meaning of the validity of such claims. At the same time we recognize that given the expressive power of BPEL, the mechanical verification of such conformance claims is not decidable in general.

Syntactic Options for Abstract Processes

Option 1: The specification currently permits omission of certain syntactic elements in abstract processes since they may not be relevant to externally observable behavior. To take a very simple example, an external view may simply state that an inbound message receive activity is followed by two outbound message send activities, in turn followed by another message receive activity. All occurring via a single partnerLink. There is thus no reason to mention the variables used for sending and receiving the messages since the externally visible behavior does not show what the process does with the messages it receives nor how it constructs the messages it sends. The current specification allows the variable declarations and the variable attributes to be omitted.

Option 2: Issue 107 points out that there is a different option for permitting missing details in abstract processes. This option uses explicit opaque activities and attributes to mark the missing details. The aim is to practically eliminate the syntactic distinction between abstract and executable processes and use a single syntactic validation schema for both with the simple proviso that opaque activities and attributes can only occur in abstract processes. Moreover, YaronG, who originated this proposal, has acknowledged that the intent is not to mark all missing details with opaque markers. In other words, in the context of the first part usage scenario 2 above, the implementer would be free to extend the abstract process in arbitrary places not just by replacing opaque activities with ordinary ones. Recalling the observation that not all of the missing detail in the description of externally visible behavior will be syntactically significant, this implies that the primary aim is to require abstract processes to conform to the same standard of syntactic correctness as executable processes.

Pros and Cons of Syntactic Options

The pros and cons of the two options are inverses of each other. The primary pro for option 1 is simplicity and brevity. One is required to say only what is needed and is allowed to omit internal details such as variable names in the example above which one would be forced to provide in option 2. The con is that there may be unintended omissions. However, as the usage scenarios and conformance verification discussion point out, abstract process usage and correctness assessments can be expected to have human scrutinyas an integral requirement. Human scrutiny is the ultimate guarantee for completeness of the abstract description, and a syntactic schema check would be a far weaker guarantee. And the need in option 2 to clutter the abstract description with extra syntactic elements such as opaque activities, opaque attributes and unneeded internal variable descriptions would make it harder to discern the intended abstract structure and make human scrutiny harder to apply. As we noted above, it is possible to construct an abstract process that omits semantically essential details without violating the schema requirements for executable processes. In such cases, the use of opaque activities and attributes becomes even harder to justify and enforce.