Pro-Spective

Digg This!

Page 2 of 2   « previous page

Here we'll refer to the process that does the invoking as the calling process and the one that it invokes as the invoked process. Rules regarding the interruptible and non-interruptible properties of the processes apply in this case. If the calling process is interruptible, then the invoked process can be either interruptible or non-interruptible. If the calling process is non-interruptible, then the invoked process must also be non-interruptible for obvious reasons. An invoked process, if it's interruptible, has an extended attribute available to it called Autonomy that can take the values Peer and Child. Peer implies that the invoked process runs on its own without access to the calling process's context and that it is also outside of the calling process's compensation sphere. It's completely autonomous in this case. When the Autonomy attribute is set to Child, then the calling process is considered to be the parent and the invoked process a child. In this case the invoked (child) process shares the context of the calling process (parent) and belongs to the same compensation sphere. When the Autonomy attribute is set to Child, the invoked process is effectively a sub-process nested inside the calling process. Sub-processes are sometimes referred to as micro flows.

The Autonomy attribute has an impact on what compensation support can be selected for a sub-process. If a sub-process's autonomy attribute is set to Peer, the valid compensation sphere settings are Not Supported or Requires New. If autonomy is set to Child, then only Supports or Required are valid.

ATTRIBUTES OF INVOKE ACTIVITY
Now that we've looked at an extended attribute closely tied to the Invoke Activity, let's examine some more attributes that belong directly to it: transactionalBehavior, undo, continueOnError, and expiration.

• An important aspect of the Invoke Activity is the transactional behavior associated with the invocation. This can be easily configured through the Transaction Behavior attribute (see Figure 4).
• Undo is the action taken to compensate on rollback. You won't actually see "undo" in the user interface of the WebSphere Process Choreographer, but it'll be created in the generated BPEL source if compensation is configured.
• The continueOnError extension is a useful flag that determines whether, on encountering an error, the invoke activity will go to the stopped state and cease executing the process, or merely transition to a failed state while the process continues. As its name implies, process execution continues if it's set to true.
• Finally, the expiration attribute is intended to prevent an Invoke Activity from blocking a process indefinitely while waiting for a response. Expiration can be set to a duration, date, or timeout (see Figure 5).

ONALARM ATTRIBUTE OF PICK ACTIVITY
The BPEL specification provides a useful entity called a Pick Activity that's a hybrid between the Receive and Switch Activities. It waits for one out of a set of messages and continues the process with an activity chosen based on the first message received that matches one of the options in the Pick. Besides waiting for a specific message, the Pick activity can also continue execution based on the setting of an extended attribute named OnAlarm. OnAlarm can be configured to trigger based on a duration of time or a specific date. An example of where this may be useful is a situation in which you're waiting for a response from a Staff Activity and if the response isn't received by a certain date, the process needs to timeout. You can configure OnAlarm to trigger in a certain number of days and then send the process to a no-op, effectively timing the process out or making it start over (see Figures 6 and 7).

A JAVA EXPRESSION AS PART OF A WAIT ACTIVITY AND OTHER ENTITIES
The base BPEL specification provides for enabling a Wait Activity either through duration of time or a specific date. The Wait Activity has been extended to allow for a Java Expression to calculate the amount of time to wait thus allowing for a more precise and flexible control in a Wait (see Figure 8). An example of where this could be useful would be in a retail order management system where you want to make the process wait to bill the customer for a certain number of days calculated by a formula based on the types and quantity of items ordered.

This same idea of flexible and granular control and decision making inside BPEL entities using a Java Expression also applies to the While and Switch Activities as well as Control links and Joins.

There are more extended attributes for Activity such as id, displayName, description, documentation, and layout. These are simple extensions without any profound impact, but they do make process choreography more convenient by adding meaningful information for human consumption and understanding.

THE BUSINESS RELEVANT ATTRIBUTE
So far we've examined extensions that provide for easier development and execution. A final attribute that we'll examine enables detailed and effective runtime monitoring of processes. The attribute that makes all of this possible is the Business Relevant attribute of variables, processes, links, and activities (see Figure 9). This powerful attribute can be used by tools such as the Business Process Engine in the WebSphere Business Integration Server Foundation to create a durable and persistent audit trail. This is done by logging certain events to an audit log table that can be examined to paint a vivid picture of the life of a running process including what events may have led to its failure. Events that can be logged, assuming the business relevant switch has been set for the entity, are numerous. The process instance events that can be logged are installation and starting a process, completion, failing, failed, terminating, terminated, compensating, compensation in doubt, successful compensation, initialization of correlation sets, and process deletion. You can see how much information can be gathered from the audit log table just from the audit events of a process instance. Adding even more power to the set of data that can be gathered are the audit events for activities, variables, and links.

Conclusion
The goal of this article was to illustrate the powerful benefits of IBM's BPEL extensions. While some are specific to IBM tooling and are unlikely to be adopted in the specification, others are non-proprietary and offer so much value such that they may be embraced. As the primary BPEL contributors create similar extensions and the user community uses these features, adoption becomes more likely.

More and more companies today are moving toward a Service Oriented Architecture that will enable their business to become more agile and adaptable. BPEL is the execution aspect required to implement such architecture. Together BPEL and IBM's BPEL extensions offer a powerful integration model to automate process integration in the enterprise and with partners.

Page 2 of 2   « previous page