Generating compatible partner processes in BPEL

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 USC 119 to European Patent Application Number EP06100873.6, filed Jan. 26, 2006.

FIELD OF THE INVENTION

The present invention relates to a Workflow Management System (WFMS) or a computer system with comparable functionality. More particularly, the invention relates to a method or means for generating a runtime compliant partner process for a given original process, wherein both processes are dedicated to interact with each other.

BACKGROUND OF THE INVENTION

Workflow Management Systems (WFMS) support the development, execution and monitoring of business processes. A business process specifies a set of work items and their dependencies along with required resources and assigned roles. Within a WFMS environment, the execution of work items is triggered and monitored by the workflow engine, and even performed automatically for some work items—whereas the individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.

IBM® WebSphere® Business Process Choreographer represents such a typical modern, sophisticated, and powerful workflow management system. It supports the definition of business processes as a process graph via a graphical editor, while using an underlying flow definition language, such as Business Process Execution Language for Web Services (BPEL4WS). In this language, the actual work items are externalized as Web Services, accessible via standardized interfaces that are specified by help of the Web Services Definition Language (WSDL).

Since 2002, the Business Process Execution Language for Web Services (BPEL4WS) is in the very act of becoming the industrial standard for describing distributed business processes. On the one hand, a BPEL business process is a Web service. On the other hand, a BPEL business process interacts with one or more other Web services, which again can be business processes. Such a Web service is called partner of the BPEL process. Each Web service plays a role in a distributed business transaction, i.e. Buyer and Seller, or Producer and Supplier. Given a BPEL business process, in many cases it is useful to generate a ‘blueprint’ process for the other side, which has assured properties like i.e. behavioral compatibility.

The general challenge is to guarantee behavioral compatibility [c.f. Axel Martens: Analyzing Web Service based Business Processes. In: Proc. of Intl. Conf. on Fundamental Approaches to Software Engineering (FASE'05), LNCS 3442, Springer-Verlag] between two interacting processes in an early design period, particularly in situations in which the original process exists already, and the partner process is in a development phase. To illustrate the underlying problem of behavioral compatibility, <figref idrefs="DRAWINGS">FIG. 1</figref> depicts a situation wherein two BPEL processes do not work together well although the interfaces between both processes are perfectly compatible.

In more detail, in <figref idrefs="DRAWINGS">FIG. 1</figref>, the original BPEL process <b>200</b> at the right side interacts with a partner process <b>100</b> on the left side. The original BPEL process defines a sequence <b>205</b> of three activities: receiving the login data <b>210</b>, making an internal decision <b>215</b>, and returning the delivery data. The decision distinguishes two cases <b>220</b>, <b>225</b>. Each case implements the parallel execution (i.e. <b>230</b>) of two sequences (i.e. <b>240</b>, <b>255</b>), in which also interaction happens. The interaction to the partner is realized via two interfaces <b>90</b>, <b>95</b>, which together form a partner link.

The partner process <b>100</b> shown on the left side just mirrors the structure of the original BPEL process. After sending the login data <b>110</b>, the partner makes a decision <b>115</b> on its own to act like a premium customer <b>120</b> or like a regular customer <b>125</b>. While his decision is not synchronized with the decision of the original BPEL process, it is crucial to the interaction. Let's assume the partner <b>100</b> acts like a premium customer: He sends terms of payment and order, and awaits discount information <b>150</b> and confirmation <b>165</b>. The original BPEL process, however, might treat him like a regular customer <b>225</b> because he might have lost his status because it was too long since he last ordered. In that case <b>235</b>, it acknowledges the order <b>290</b> with the standard business conditions (SBC) <b>295</b> and awaits the payment <b>275</b>. Now, both of the processes are waiting and none can continue on its own—a classical deadlock situation. In the result, the behavior of both BPEL processes is not compatible.

Generating a behaviorally compatible partner process is a non-trivial task. A straight-forward approach could possibly be seen in a structural, pure BPEL-based method. The main idea is to analyze the original process' structure and to reflect it. In the end, this yields a so-called “mirrored” partner process, like the one shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. While this approach would be based on static mapping rules of all BPEL activities, it does not always generate a compatible partner process as the initial example of <figref idrefs="DRAWINGS">FIG. 1</figref> has proven.

A second approach is referred to as “communicational” method and is based on a formal, mathematical analysis of the process model. Some details are given in <figref idrefs="DRAWINGS">FIG. 2</figref> which shows a block diagram representation of the basic steps of the latter-mentioned prior art partner process generation method. Such prior art method is published at [Axel Martens: Analysis and re-engineering of Web Services. In: Proc. of 6th Intl. Conf. on Enterprise Information Systems (ICEIS'04), Porto, Portugal].

In step A the original process <b>200</b> is transformed into a formal input representation <b>320</b> as for example Petri Nets, or π-Calculus. This representation is intermediary in nature. It describes formally the internal logic of the original process, and its externally visible communication behavior.

In step B<b>2</b> the communication behavior of the formal input representation <b>320</b> is analyzed. This yields the communication graph that contains all possible sequences of input and output messages that may occur in the given process—the communication model <b>330</b> of the given BPEL process. Because some of those possible communication sequences might yield unwanted situations (like deadlocks, c.f. <figref idrefs="DRAWINGS">FIG. 1</figref>), the partner to generate should avoid those unsound sequences.

In step C the communication graph is restricted and projected to usable behavior. This yields to a sub-graph that represents a controller model <b>340</b> for the given BPEL process. Finally, in step D, the controller model, which is a graph, has to be transformed into a process model. The prior art method does perform a generation of a formal process model representation <b>345</b>, but it does not bridge the gap to the target language BPEL.

On the level of formal process model representations, the communicational method can be proven to produce behaviorally compatible processes—in contrast to the previously mentioned structural method. However, it will consider actually all possible sequences of communication activities. To illustrate that drawback: For a number of 12 communication activities in the original process, there are 12!=47,900,1600 possibilities to order them. The complexity to order the activities of two parallel sequences of the length 8 has an order of 48=65,536. Hence, the method often will yield a partner process that is often too complex to be easily understood by the partner, making it rather hard to refine it, since the process logic might be “distributed” in the generated partner process. This can be assumed to be caused by the mathematical algorithm used within the method. Thus, this prior art method has significant disadvantages for the developer and is not widely accepted, when developing a partner process.

It is thus an objective of the present invention to provide a method for generating a runtime compliant partner process for a given original process, which is easier understandable for a process developer.

SUMMARY OF THE INVENTION

The objectives of the invention are achieved by the features stated in enclosed independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective sub-claims. Reference should now be made to the appended claims.

According to the most basic aspect of the present invention a method is disclosed for generating a runtime compliant partner process for a given original process, wherein both processes are dedicated to interact with each other, including the steps of:

1. Identifying all activities of the original process, interacting with the partner process, and characterized by the steps of:

2. Determining if an activity is able to be mirrored by a mechanism supported by the business process language, e.g. BPEL, <ul><li id="ul0002-0001" num="0000"><ul><li id="ul0003-0001" num="0020">2.1 If yes, generating the mirrored activity and creating a respective activity name,</li><li id="ul0003-0002" num="0021">2.2 If not, using a predetermined mathematical method for dissecting such an activity into a set of sub-activities that can be mirrored, followed by <ul><li id="ul0004-0001" num="0022">2.2.1 Generating a respective mirrored sub-activity and creating a respective activity name for each sub-activity, and followed by</li><li id="ul0004-0002" num="0023">2.2.2 Arranging the mirrored sub-activities according to the outcome of the predetermined mathematical method.</li></ul></li></ul></li></ul>

Thus, a hybrid approach made from two distinct solutions is disclosed which takes profit of the advantages of both methods, and which avoids the disadvantages thereof. The basic advantage is that a behaviorally compatible partner process is found automatically. Further, the probability is high that the partner process has the same or nearly the same degree of complexity as the underlying original process. Of course, this will often depend of the actual case in question.

The key idea of this invention is thus to generate a partner process with the help of the two different approaches mentioned above applying them in a specific, combined way: The structural, BPEL-based operation mode mentioned above and the communicational (or analytical) operation mode.

The resulting partner process contains the necessary process logic for a compatible behavior respect to the original process, while it has a significantly reduced number of activities. In contrast to a pure communicational approach, the disclosed hybrid approach mirrors most of the structure of the original process and therefore makes it understandable, readable and able to be manipulated. But, compared with a pure BPEL approach, the generated partner process is guaranteed to be behaviorally compatible to the original process. By that any workflow can be mirrored with a reasonable extent of computational work.

Further, advantageously, BPEL is used as business process language. When further the determination step for the BPEL-specific activities Invoke, Pick, Flow and Sequence is run through directly by mirroring said activities into respective mirrored activities without using said mathematical method, then the disclosed method can be run with further reduced elapsed time.

Further advantageously, the process workflow is expressed by a hierarchical, tree-like structure, and the capability of a markup language, as for example XML, is used to map this tree-like structures into a specific format of the markup language. This helps to find an easy-to-do implementation for the basic disclosed method structure including the decision if or if not the mathematical method should be used. Thus, the mirroring procedure is further simplified.

When further reducing the number of potential combinations of sub-activities comprised of said set by applying some knowledge of the structure of the original process, then the additional advantage is achieved that the resulting partner process is as simple as possible.

When using a mapping vocabulary for mapping the names of an activity of the original process to names of a respective mirrored activity of the partner process, then an easy-to-do implementation is found for implementing an automatic name selection for the activities and sub-activities of the partner process.

As a person skilled in the art may appreciate, the original process and the generated partner process are never deadlocking. This is achieved through switching back and forth between those two operation modes, based on certain heuristics.

The method disclosed herein solves the above-mentioned problem by generating a guaranteed behaviorally compatible and therefore runtime compliant partner process that is simple enough to be understood.

A business partner implementing the partner process can advantageously use this ‘blueprint’ process generated according to the present invention and may refine it, based on certain rules, towards his special needs.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic process diagram representation of a sample business process interaction—expressly held simple—between the original process (right) and a “mirrored” partner process (left), showing behavioral incompatibilities, when implemented according to prior art;

<figref idrefs="DRAWINGS">FIG. 2</figref> is a schematic block diagram representation of the basic steps of a prior art partner process generation method;

<figref idrefs="DRAWINGS">FIG. 3</figref> is a schematic block diagram representation of the basic steps of the disclosed hybrid partner process generation method, according to a preferred embodiment;

<figref idrefs="DRAWINGS">FIG. 4</figref> is a schematic block diagram representation of the basic functional elements of the disclosed hybrid partner process generation system, and its integration into existing development environments;

<figref idrefs="DRAWINGS">FIG. 5</figref> is a schematic flow diagram representation of the algorithmic steps of the disclosed hybrid partner generation method, and their dependencies/correlations; and

<figref idrefs="DRAWINGS">FIG. 6</figref> is a schematic process diagram representation of the business process interaction between the original process and a partner process that was generated by the disclosed method.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

With general reference to <figref idrefs="DRAWINGS">FIGS. 3 to 6</figref>, a rough overview is given how a preferred embodiment of the disclosed method is preferably performed. As shown in <figref idrefs="DRAWINGS">FIG. 3</figref>, the following steps are performed at development time of the partner process:

Steps <b>1</b> to <b>3</b> coincide with steps <b>1</b> to <b>3</b> as described for prior art above (c.f. <figref idrefs="DRAWINGS">FIG. 2</figref>). In step <b>4</b>, the structure of the original input process is parsed into a process structure tree, where complex structured activities (like sequence, flow, etc.) form intermediate nodes, and basic activities (like receive, reply, etc.) form the leaf nodes of that tree.

Concurrently, in step <b>5</b> the available information about sound communication sequences contained in the controller model <b>340</b> is fed into the disclosed hybrid algorithm <b>360</b>. By mirroring the parsed structure of the original process <b>200</b> as far as possible and by treating structures that can't be mirrored with regard to the controller model <b>340</b>, the hybrid algorithm <b>360</b> generates in step <b>6</b> the desired partner process model <b>600</b>, which is behaviorally compatible to the original process and as small in size and complexity as possible.

<figref idrefs="DRAWINGS">FIG. 4</figref> depicts the integration of the disclosed hybrid partner generation method <b>450</b> into a given modeling tool development environment <b>430</b>. As shown in <figref idrefs="DRAWINGS">FIG. 4</figref>, the development environment <b>430</b> includes a process editor <b>435</b>, interface editor <b>440</b> and data structure editor <b>445</b>. The development environment <b>430</b> further includes the hybrid partner generation method <b>450</b>, which includes functional components <b>455</b>, <b>460</b>, <b>465</b> and <b>470</b>. Further shown in <figref idrefs="DRAWINGS">FIG. 4</figref> is a file repository <b>410</b>, including process models <b>415</b>, interface definitions <b>420</b>, and data structures <b>425</b>. Steps <b>1</b> and <b>4</b> are performed by the functional component <b>455</b>, which walks through the original process model <b>415</b> and collects and/or transforms the relevant information. The formal, mathematical analysis is realized by the functional component <b>465</b>, which applies model-checking-like technologies to distinguish sound and unsound communication sequences. This component <b>465</b> is widely independent from the actual chosen process modeling language (e.g. BPEL). The structural mirroring of individual activities with regard to the means of the chosen process modeling language is performed by the functional component <b>460</b>. Finally, functional component <b>470</b> represents the core of the disclosed hybrid approach by combining the results of structural transformation <b>460</b> and behavioral analysis <b>465</b>. It generates automatically the partner process model for the given original process. The behavioral compatibility between the original process and the resulting partner process is guaranteed per construction, which can even be proved mathematically.

Next, the disclosed hybrid algorithm <b>360</b> will be explained in greater detail. To do so, the individual algorithmic steps that are shown in <figref idrefs="DRAWINGS">FIG. 5</figref> will be described in general as well as applied to the introducing example of the order service (c.f. <figref idrefs="DRAWINGS">FIG. 1</figref>). The result of the hybrid partner generation—i.e. the generated partner of the order service—is shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, on the left side. The original order process is replicated on the right side of <figref idrefs="DRAWINGS">FIG. 6</figref>.

The invention exploits the fact that most of processes workflows are expressible also by a hierarchical tree-like structure. Thus, the invention uses the capability of XML and comparable languages to map such tree structures into a language-specific format. As shown in <figref idrefs="DRAWINGS">FIG. 5</figref>, the disclosed method parses the process model into a structure tree <b>510</b> where complex structured activities (like sequence, flow, etc.) form intermediate nodes, and basic activities (like receive, reply, etc.) form the leaf nodes of that tree. For each node in that structure tree—which is enforced by the initial decision <b>520</b>—the classification is made in a decision <b>530</b> whether it can either be mirrored with simple modeling language means, or it has to be decomposed into sub-structures.

In the first case, which is preferably entered, the current node is treated in structural (BPEL) mode <b>570</b>. That means, by looking at the mapping rule catalogue, which will be explained later, a corresponding mirrored BPEL activity with a respective activity name is generated, and it is inserted into the result structure tree. Then, the next node is treated by looping back to the initial decision <b>520</b>. This cycle is called “Structural Cycle”.

In case no mirrored activity can be found (NO branch of <b>530</b>), the behavior of the current activity is analyzed (<b>540</b>), which yields a behavioral sub-graph comprising a sub-tree of activities. In other words, an activity which can't be mirrored by structural (BPEL) means is processed by zooming into it and dissecting the activity into a plurality of connected sub-activities.

Similar to the structural cycle, for each node of that sub-graph <b>550</b> the classification is made in a decision <b>560</b> whether it can either be mirrored with simple modeling language means, or it has to be decomposed into sub-structures. In the first case, the current activity is handed over to the structural treatment <b>570</b>. Otherwise, the activity is treated in the behavioral mode <b>580</b> according to the mathematical model (like the before-mentioned Petri net model). Then, the control flow loops back to the next activity of the sub-graph <b>550</b>. This cycle is called “Behavioral Cycle”. When the sub-graph has been processed completely (decision <b>550</b> yields NO), the control flow loops back to the initial decision <b>520</b> in order to continue with the next “ordinary” node.

Next, the mapping rule catalogue is described in more detail:

A BPEL activity is mirrored by mapping it to its counterpart elements in the partner. This is done according to a pre-defined catalogue of mapping rules, of which some are disclosed as follows:

Asynchronous “Invoke” is mapped to “Receive” (without Reply).

Synchronous “Invoke” is mapped to “Receive” and “Reply”.

“Pick” is mapped to “Switch” while for each “onMessage” branch in the pick activity there will be one “Case” branch in the switch activity that invokes the corresponding message. As the initial example (<figref idrefs="DRAWINGS">FIG. 1</figref>) has shown, the mapping of “Switch”, i.e. an internal decision within the original partner, needs treatment in the behavioral mode.

“Sequence” and “Flow” are mapped to “Flow” to allow maximal freedom of connecting the embedded activities. In case of sequential behavior within the generated partner process, some flow activities might be replaced by sequences to simplify the structure. This does not have any impact on the correctness of the generation. It is rather a question of optimizing the generation's output.

Whenever a pattern occurs that can't be transformed by simply mirroring it (e.g. switch, while), the disclosed method switches from its structural operation mode into the behavioral mode. In the behavioral mode, the disclosed method extracts the information about the behavior of the current pattern from the communication graph. Then, it generates receive, reply, or invoke activities for all messages that occur in the relevant sub-graph. Finally, the disclosed method connects those generated activities by control flow links and/or embeds them into structured activities in order to realize the desired behavior. In general, “Switch” is transformed to “Pick” or a cascade of pick activities, and “While” is transformed again to “While”.

In the behavioral mode, the approach reacts to the appearance of patterns that permit to switch back to the structural mode. As patterns requiring the two different modes may be contained alternating in the structure tree, it is possible that the disclosed hybrid approach switches the operation mode forward and backward several times during the generation of a runtime compliant partner process.

EXAMPLE

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates the disclosed method. The left side shows the partner process <b>600</b> generated by aid of the disclosed method. It should be noted that the right side shows the original process <b>200</b>, which remains unchanged in relation to <figref idrefs="DRAWINGS">FIG. 1</figref>, nor is changed by the disclosed method.

Because each BPEL process needs to be initialized by an incoming message, the disclosed approach distinguishes three cases: Either the given process initiates the partner to generate, or both processes are initiated independently by an external component, or the original process is initiated by the partner to generate. <figref idrefs="DRAWINGS">FIG. 6</figref> depicts the last case. Consequently, the partner process itself has to be generated from outside. Hence, two activities <b>610</b>, <b>695</b> realize the communication with that third, not shown party.

The first activity of the original process <b>200</b> is a sequence <b>205</b> of three activities <b>210</b>, <b>215</b>, and <b>300</b>. As mentioned before, a sequence is mapped into a flow <b>615</b> in the structural operation mode. Moreover, its first (<b>210</b>) and last (<b>300</b>) activity can be treated in the structural operation mode as well. This yields corresponding, mirrored activities (<b>210</b>=&gt;<b>620</b>, <b>300</b>=&gt;<b>690</b>).

In contrast, the internal decision of the original process <b>215</b> cannot be mirrored directly. Hence, the disclosed hybrid method switches to behavioral mode and extracts the information about that decision from the communication graph (c.f. Step <b>5</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>). It turns out by analyzing the activities of the original process that to utilize the original process correctly, the order is required in both cases <b>260</b>, <b>290</b>. If the original process has chosen the premium customer branch <b>220</b>, it will return a confirmation <b>265</b>. Otherwise, it will send the standard business conditions (SBC), <b>295</b>. This information is mapped into the partner <b>600</b> as follows:

A flow activity <b>625</b> is generated in correspondence to the switch <b>215</b>. First the order is sent (<b>630</b>) and then the pick activity (<b>635</b>) distinguishes those two “onMessage” branches <b>640</b>, <b>645</b>. Finally, the body of each “onMessage” branch is generated in structural mode again. Branch <b>640</b> is shown including invoke ToP activity <b>655</b> and Receive Discount activity <b>660</b>, and branch <b>645</b> is shown including Invoke Payment activity <b>675</b> and Receive Confirm activity <b>680</b>.

As mentioned before, mapping a sequence into a flow activity allows maximal freedom of connecting the embedded activities. Nevertheless, additional steps of simplification, which are also part of this disclosure, might re-transform flow activities into sequences. If such additional steps of simplification were applied to the example shown in <figref idrefs="DRAWINGS">FIG. 6</figref>, two flow activities would be changed to sequences <b>650</b>, <b>670</b>, and two flow activities <b>615</b>, <b>625</b> would be unnecessary, because their child activities are moved into the surrounding sequence activity <b>605</b>.

The present invention can be realized in hardware, software, or a combination of hardware and software. A partner process generating tool according to the present invention can be realized in a centralized fashion (i.e. in one computer system) or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.

The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods.

The figures include block diagram and flowchart illustrations of methods, apparatus(s) and computer program products according to an embodiment of the invention. It will be understood that each block in such figures, and combinations of these blocks, can be implemented by computer program instructions. These computer program instructions may be loaded onto a computer or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the block or blocks. These computer program instructions may also be stored in a computer-readable medium or memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium or memory produce an article of manufacture including instruction means which implement the function specified in the block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks.

Those skilled in the art should readily appreciate that programs defining the functions of the present invention can be delivered to a computer in many forms; including, but not limited to: (a) information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM or CD-ROM disks readable by a computer I/O attachment); (b) information alterably stored on writable storage media (e.g. floppy disks and hard drives); or (c) information conveyed to a computer through communication media for example using wireless, baseband signaling or broadband signaling techniques, including carrier wave signaling techniques, such as over computer or telephone networks via a modem.

While the invention is described through the above exemplary embodiments, it will be understood by those of ordinary skill in the art that modification to and variation of the illustrated embodiments may be made without departing from the inventive concepts herein disclosed.