Browse Prior Art Database

Coextending Workflow Management Execution Disclosure Number: IPCOM000097986D
Original Publication Date: 2005-Mar-07
Included in the Prior Art Database: 2005-Mar-07
Document File: 3 page(s) / 66K

Publishing Venue



The workflows defined by WebSphere Process Choreographer are based upon the open standard Business Process Execution Language for web services (BPEL4WS). Parallelism is supported in BPEL through the construct. However, the construct doesn?t support parallelism in terms of context of the business process. Specifically, it doesn?t allow to dynamically provision a new process during run time of the process based upon the context of the activity. Due to the lack of support for dynamic provisioning of business based upon the context of the business process there is a requirement to support Spin locks workflows. Spin Locks is type of problem that has to be solved in order to get parallelism in which the activity that invokes processes doesn't know the number of processes that it is going to invoke. This makes it particularly difficult because after invoking the last sub-processes it will be notified that it has completed all the sub-process invocation. Hence, the process of synchronization cannot be dealt with the sub-processes but has to be externalized.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Coextending Workflow Management Execution

2 Business Process Synchronizer

The Business Process Synchronizer is the software component that will have the capability to solve the Spin lock workflows. Before looking at the business process synchronizer in greater depth, we need to be aware about some key requirements during design.

Here are a list of key requirements that have to be satisfied through the component level design and the protocol usage:
* Business Process Synchronizer should be state independent thus allowing multiple installations to work without any scalability issues
* Business Process Synchronizer should be installed and successfully be running on a J2EE (WAS) cluster. That is it should classify WAS cluster requirements
* Sub-processes that are aborted or terminated should be designed in such a way that they send a message back to the Synchronizer regardless of the way they complete
* 'Multi-Threading' in J2EE should be accomplished through MDBs.
* Either the Synchronizer or the database design should be a the bottle neck

Now, we will look at the Business Process Synchronizer in greater detail:

Figure 2-1: Business Process Synchronizer

The Business Process Synchronizer basically consists of an MDB registered with a queue with a message selector defined for 4 different kinds of messages. After doing some processing the message selector calls the stateless session bean which does the work by creating a XA connection to the database using JDBC. There are 4 kinds of functions or transactions that are defined as the implementation of the bean. With this kind of implementation, the synchronizer can be replicated across a WAS cluster.


[This page contains 1 picture or other non-text object]

Page 2 of 3

3 Spin Lock Solution

In order to solve the Spin lock problem there is a need for:
* 5 different JMS message formats
* 2 tables to keep track of the number of outstanding sub-processes

Here is the overview of the protocol that will be followed:

Figure 3-1: Spin lock Solution with Business Process Synchronizer

Each of the steps in detail:
* Step 1: Before the master process, which is about to start a spin lock, it will send a message to the business process synchronizer with a message to start a spin lock transaction. The message will contain the process instance id to be used as a primary key for the identification of the spin lock transaction. The message will also contain the receive bindings that have to send out by the business process synchronizer for step 3 and the final step upon completion of the spin lock transaction.
* Step 2: Business Process Synchronizer...