Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Improved Dead-Path-Elimination for Business Processes

IP.com Disclosure Number: IPCOM000021127D
Original Publication Date: 2003-Dec-24
Included in the Prior Art Database: 2003-Dec-24
Document File: 4 page(s) / 35K

Publishing Venue

IBM

Abstract

Improved dead-path-elimination for business processes specified in languages like the business process execution language for web services.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 4

Improved Dead-Path-Elimination for Business Processes

The business process execution language for web services (BPEL4WS) has been designed to specify interactions between various web services. For an detailed description of the language, we refer the reader to [1]. In BPEL4WS, the basic activities include assignments, invoking web service operations, receiving requests, and replying to requests. These basic activities are combined into structured activities using ordinary sequential control flow constructs like sequencing, switch constructs, and while loops.

Concurrency is provided by the flow construct. For example, in

<flow>

buy

sell

</flow> the activities buy and sell, whose behaviour has been left unspecified to simplify the example, are concurrent. The pick construct allows for selective communication. Consider, for example, <pick>

<onMessage partner="consumer" operation="buy" container="request">

sell

</onMessage>

<onMessage partner="producer" operation="sell" container="offer">

buy

</onMessage>

</pick> On the one hand, if a message from consumer is received then the activity sell is executed. In that case, the buy activity will not be performed. On the other hand, the receipt of a message from producer triggers the execution of the buy activity and discards the sell activity. In the case that both messages are received almost simultaneously, the choice of activity to be executed depends on the implementation of BPEL4WS.

    Synchronization between concurrent activities is provided by means of links. Each link has a source activity and a target activity. Furthermore, a transition condition is associated with each link. The latter is a Boolean expression that is evaluated when the source activity terminates. Its value is associated to the link. As long as the transition condition of a link has not been evaluated, the value of the link is undefined. We will use, for example, Figure 1 to depict that link l has source aS and target aT and transition condition true.

1

Page 2 of 4

    Each activity has a join condition. This condition consists of incoming links of the activity combined by Boolean operators. Only when all the values of its incoming links are defined and its join condition evaluates to true, an activity can start. As a consequence, if its join condition evaluates to false then the activity never starts. We will use, for example, Figure 2 to depict that the join condition of activity aTis l1and l2. In 1Figure 2, activity aT can only start after activities aSand aS2have finished.

    In Figure 3, we use + to depict the pick construct. Note that the choice between 1the activities a1and a12determines which of the activities a3, a4and a5are performed. For 1example, if a1is chosen then a3is executed. In that case neither a4nor a5can ever occur. As a consequence, the activities a4and a5could be garbage collected.

2

[This page contains 2 pictures or other non-text objects]

Page 3 of 4

This problem has been addressed as follows.

  If a pi...