Browse Prior Art Database

Enhanced Expiration

IP.com Disclosure Number: IPCOM000130026D
Original Publication Date: 2005-Oct-11
Included in the Prior Art Database: 2005-Oct-11
Document File: 1 page(s) / 4K

Publishing Venue

IBM

Abstract

Flow languages, such as Business Process Execution Language for Web Services (BPEL4WS), provide for the definition of business processes. They typically support the notion of expiration: An activity or scope is assigned a time interval that when exceeded causes the activity to be treated as completed. It is proposed that the current, rather inflexible, mechanism is extended through the notion of expiration handlers, and expiration faults.

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

Page 1 of 1

Enhanced Expiration Enhanced ExpirationEnhanced Expiration Enhanced Expiration

Flow languages, such as Business Process Execution Language for Web Services (BPEL4WS), provide for the definition of business processes . They typically support the notion of expiration: An activity or scope is assigned a time interval that when exceeded causes the activity to be treated as completed. For example, if an activity has not been processed within 12 days, processing of the activity is no longer needed. This could, for example, be expressed as follows:

<invoke name="approve" expire="12D"...>

</invoke>

    The activity "approve" would be treated completed 12 days after it has been made available for execution; that means the approval would be given, if none has processed the approval within 12 days.

    The disadvantage of the current state-of-the-art expiration support is its inflexibility; the activity or set of activities are just treated as completed. In many cases however, it would be desirable to perform some additional processing .

    It is suggested to introduce the notion of expiration handlers similar to event handlers and fault handlers.

This would allow coding the previous example as follows:

<invoke name="approve">

<expire time="12D">

... some activity ...

</expire

</invoke>

    If the activity expires the expiration handler gets control and can do whatever is needed to cope with the situation.

    The same behavior can be achieved through the notion of notification faults which a...