Browse Prior Art Database

Dynamic Expiration of Activities

IP.com Disclosure Number: IPCOM000127665D
Original Publication Date: 2005-Sep-08
Included in the Prior Art Database: 2005-Sep-08
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. The disadvantage of the current state-of-the-art expiration support is its inflexibility; expiration is always the same whether it is a high value process or a low value process, whether it is an urgent process or a non-urgent process; that means expiration is context independent. Furthermore the appropriate expiration condition can not be changed. Two new mechanisms are needed to provide these capabilities.

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

Page 1 of 1

Dynamic Expiration of Activities Dynamic Expiration of ActivitiesDynamic Expiration of Activities Dynamic Expiration of Activities

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 5 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 nobody has processed the approval within 12 days.

    First, it is suggested to address the context issue by supporting conditions in notifications. This would allow the previous example to be written as follows:

<invoke name="approve"...>

<expire "12D" when "amount < 1000"/>

</invoke>

    In this case, the "approve" activity would only expire if the amount (of the loan for example) is less than 1000 &euro.

    It is further suggested that multiple expiration specifications can be specified for one activity. The syntax could be along the line of a case statement in regular programming languages.

    Second, it is suggested to address the static nature of the expiration condition through introd...