WS-BPEL allows you to achieve enterprise-agility by providing a mechanism to orchestrate and invoke disparate web services either synchronously or asynchronously. At runtime, these business processes will have to have the ability to handle disparate events. Business processes need to wait for incoming messages (or events) that trigger their execution. BPEL already provides the <receive> and <pick> activities that await incoming messages to kick off a new business process instance to execute as we saw in this blog entry. The <receive> activity allows the business process to wait for a specific type of message to arrive on a specified portType.

For asynchronous business process invocations, results are usually returned back to the invoking business process instance using callback mechanisms. In such cases, the business process has to handle multiple types of incoming messages and provide the ability to define alternate paths to handle execution of the appropriate business logic. Since in most cases we are orchestrating a loosely-coupled service, we have to keep in mind that the web service we are invoking may not be available all the time. In such situations, we may need to model enough intelligence in the process to execute alternate paths. Therefore, the business process may need to wait for the callback for a specified duration (or a specified interval of time) before it can proceed with execution of other correctional activities that have to be executed. We can think of two different types of events that business processes may have to handle. They are:

1. Messages: Incoming messages that are the result of operation invocations by a partner process.
   
2. Alarms: Messages that are triggered by the same process after a specified time duration, or those that happen in response to a pre-defined date/time deadline.

The <onMessage> element - Handling Incoming Messages:
The <onMessage> element is very similar to the <receive> activity and takes the same set of attributes as the <receive> activity. The following skeletal code illustrates the <onMessage> element inside of a <pick> activity from the Travel Reservation Composite Application scenario described in this blog entry.

... <onMessage partnerLink="Hotel"            portType="hres:HotelReservationCallbackPortType"            operation="hotelReserved"            variable="HotelReservedIn">   <correlations>     <correlation set="ItineraryCorrelator"/>   </correlations>   <sequence name="HotelReserved">     <assign name="CopyHotelReservation">       <copy>         <from variable="HotelReservedIn" part="itinerary"/>         <to variable="ItineraryOut" part="itinerary"/>       </copy>     </assign>   </sequence> </onMessage> ..

The <onAlarm> element - Handling triggered events
The <onAlarm> element is very similar to the <wait> element that we saw in this blog entry. It allows facilities to model for both a specific duration using the for attribute, or a deadline using the until attribute.

It is therefore possible to model a deadline type of scenario where we want the business process to wait for a callback until a deadline occurs and then either throw a fault or perform other correctional business activities. It is also possible to model a duration type of scenario where we want the business process to wait for a certain amount of time duration and if no callback is received within this time, either throw a fault or perform other correctional business activities.

The following skeletal code illustrates the <onAlarm> element inside of a <pick> activity from the Travel Reservation Composite Application scenario described in this blog entry.

... <onAlarm>   <for>'P3DT10H'</for>   <sequence name="Timer">      <assign name="CopyHotelCancellation">       <copy>         <from>$ReserveHotelIn.itinerary/ItineraryRef</from>         <to variable="CancelHotelIn" part="itinerary"/>       </copy>     </assign>                 <invoke name="CancelHotel"             partnerLink="Hotel"             portType="hres:HotelReservationPortType"             operation="cancelHotel"             inputVariable="CancelHotelIn"             outputVariable="CancelHotelOut"/>   </sequence> </onAlarm> ...

Look at this blog entry to understand what the value 'P3DT10H' means. The <onMessage> and the <onAlarm> elements can be used either inside a <pick> activity or in an <eventHandler> element.

The screenshot below shows the <pick> activity and the <onMessage> and the <onAlarm> elements as modeled using the BPEL Visual Designer from the Travel Reservation Composite Application scenario described in this blog entry.


Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you'd like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta, NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System Application Server Platform Edition 9. This bundle also contains Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints, and API docs (Javadoc).

The screenshots below illustrate the WSDL and business process related to the Travel Reservation Composite Application scenario described in this blog entry..

The screen-shot below shows the WSDL for the Travel Reservation Composite Application scenario in the Sun NetBeans 5.5 Enterprise Pack Beta WSDL Editor	The screen-shot below shows the BPEL for the Travel Reservation Composite Application scenario in the Sun NetBeans 5.5 Enterprise Pack Beta BPEL Visual Designer