Browse Prior Art Database

Deactivating Event Handlers

IP.com Disclosure Number: IPCOM000126462D
Original Publication Date: 2005-Jul-19
Included in the Prior Art Database: 2005-Jul-19
Document File: 2 page(s) / 6K

Publishing Venue

IBM

Abstract

Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) provides for the specification of business processes which invoke Web services and for providing business processes as Web services.. Event handlers provide for the processing of sets of activities parallel to the main part of a business process managed by a workflow management system. Event handlers are associated with scopes or the whole process. They are activated when the process navigates into the scope with which the event handler is associated and are de-activated when the process is ready to navigate out of the scope. An activated event handler is started when an appropriate message is sent to the process or a timer goes. It is suggested to introduce two activities and that provide for the activation and deactivation of event handlers. When specified within the scope, the named event handler is activated or deactivated. The activity can also be specified within an event handler causing when carried out the event handler to be deactivated.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 69% of the total text.

Page 1 of 2

Deactivating Event Handlers Deactivating Event HandlersDeactivating Event Handlers Deactivating Event Handlers

Summary of Invention:

Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) provides for the specification of business processes which invoke Web services and for providing business processes as Web services .

    Event handlers are either associated with a set of activities, called a scope, or with the whole process. An event handler is activated when navigation through the process enters the scope or in the case of an event handler attached to the process, when the process is started. Event handlers are instantiated as the result of an external message or the triggering of a timer. The body of an event handler consists of a set of activities that are carried out when the event handler is instantiated .

    Event handlers are specified in BPEL4WS via the eventHandlers element as follows:

<scope>

<eventHandlers>

<onMessage>

<onAlarm>

</eventHandlers>

</scope>

    Event handlers that are activated via an external message are defined via the <onMessage> element; event handlers that are activated via a timer are defined via the <onAlarm> element. The individual event handler consists of an activity; this may be a simple activity or a complex activity which consists of a set of activities.

    In many cases, however, it is desirable to deactivate an event handler as the event handler is no longer needed; either permanently or for some time . This situation can be handled by adding a <deactivate> activity which deactivates the specified event handler and by a <activate> activity that causes activation of the event handler.

    The following code snippet illustrates how an event handler is deactivated and activated again in the scope to which the event handler is attached to . <scope>

<eventHandlers>

<onMessage name="cancel">

<activity>

</onMessage>

</eventHandlers>

<sequence>

<activity1/>

<deactivate eventHandler="cancel"/>

<activity2/>

<reactivate eventHandler="cancel"/>

<activity3/>

</sequence>

</scope>

The code snippet shows the three necessary changes that need to be made

1

Page 2 of 2

to the current specification of the language. First, a name attribute is added to the event handler; this name is used in the appropriate <activate> and <deactivate> activities to identify which event handler should be deactivated or activated. Second, the <deactivate> activity is added that when executed deactivates the named event handler. Third, the <activate> activity is added that when executed reactivates the named event handler.

    The processing within the code snippet is obvious; the event handler cancel is deactivated as long as <activity2> is being carried out; that means the message associated with the event handler cancel is not processed.

    The following code snippet illustrates how an event handler is...