BPEL-TIME:WS-BPEL Time Management Extension

Amirreza Tahamtan, Christian oesterle, A Min TjoaInstitute of Software Technology & Interactive Systems, Information & Software Engineering Group,

Vienna University of Technology, Favoritenstrasse 9-11/188, A-1040 Vienna, Austriatahamtan@ifs.tuwien.ac.at, christian.oesterle@gmx.at, amin@ifs.tuwien.ac.at

Abdelkader HameurlainInstitut de Recherche en Informatique de Toulouse, University Paul Sabatier,

Route de Narbonne, 31062 Toulouse Cedex, Francehameur@irit.fr

Keywords: WS-BPEL, Extension, Time, Temporal Management, Business Process, Design, Execution, Monitoring

Abstract: Temporal management and assurance of temporal compatibility is an important quality criteria for processeswithin and across organizations. Temporal conformance increases QoS and reduces process execution costs.WS-BPEL as the accpetd industry standard lacks sufficient temporal management capabilities. In this paperwe introduce BPEL-TIME, a WS-BPEL extension for time management purposes. It allows the definition,execution and monitoring of business processes with time management capabilities. This extension makesa fixed, variable and probabilistic representation of temporal constraints possible and checks if the model istemporally compliant. Our approach avoids temporal failures by the prediction of the future temporal behaviorof business processes.

1 INTRODUCTION

Temporal conformance and compliance are im-portant quality criteria for business processes andinterorganizational workflows. Processes may havedeadlines. The assigned deadlines may be part of theservice level agreement between partners or enforcedby law or organizational policies. It must be ensuredthat the right information is delivered to the right ac-tivity at the right time and the process executes in atimely manner in order to be able to hold the dead-lines. Temporal conformance on the one hand in-creases the QoS and on the other hand reduces thecost of process execution as costly exception handlingmechanisms can be avoided. Temporal managementcan be used for three different purposes (Tahamtan,2009):

• Predictive time management: to predict the pos-sible temporal behavior of the system and pre-calculate future possible violations of temporalconstraints.

• Pro-active time management: to detect potentialfuture violations and raise alarm in these casessuch that counter-measure mechanisms can betriggered early enough.

• Reactive time management: to react and triggerexception handling mechanisms if a temporal fail-ure has already occurred.

Web Services and SOA offer several advantagesfor implementation of business processes such asinteroperability, loosely coupling and composition.WS-BPEL has become the accepted standard for de-scription end execution of business processes basedon Web Services. In the realm of web services wemainly talk about two concepts: choreographies andorchestrations or in the WS-BPEL notation, abstractand executable processes.

A WS-BPEL executable process or orchestrationis controlled and run by one partner. A partner’s inter-nal logic and business know-how are contained in hisexecutable process. Other tasks such as data transfor-mations, data handling, arithmetic operations and theactual performed work are as well contained in thisprocess. An executable process is solely visible to itsowner and other external partners have no view on andknowledge about it. An executable process is a pro-cess viewed only from the perspective of its owner.

On the other hand, a choreography, which is calledabstract process in WS-BPEL, describes business pro-tocols. An Abstract Process may be used to describeobservable message exchange behavior of each of the

parties involved, without revealing their internal im-plementation (Alves et al., 2007). An abstract pro-cess can use all the construct of an executable processand have the same expressive power but it is not in-tended to be executed. It has merely a descriptive role.An abstract process defines a collaboration among in-volved partners to reach an overall business goal. Itcontains only visible exchanged messages betweenpartners in course of a business process. An abstractprocess has no owner or a super user in charge of con-trol and all involved partners are treated equally. It isa process definition from a global perspective sharedamong all involved partners (Peltz, 2003).

In order to ensure that cooperating business pro-cesses are temporally compliant, it must be guaran-teed that both the tasks performed in executable pro-cesses and the protocols described in abstract pro-cesses have a compliant temporal behavior. The Con-tribution of this paper is an extension of WS-BPELcalled BPEL-TIME (WS-BPEL Time ManagementExtension) to ensure temporal compatibility of busi-ness processes. BPEL-TIME consists of two compo-nents, a design time component and a run time com-ponent. The design time component allows the def-inition of temporal constraints. At design time it ischecked if the model is temporally feasible, i.e. ifthere is a solution that satisfies all the temporal con-straints. If the system is temporally not feasible, itcan be detected at design time and necessary mod-ifications performed. We calculate a valid temporalwindow for each activity in this phase. If an activityexecutes within its valid temporal window it is guar-anteed that the whole process terminates successfully.The run time component monitors the execution ofthe process and informs the process manager if anydeviation from valid temporal windows is detected.Based on the calculations at design time, the run timecomponent predicts the future temporal behavior ofthe flow and informs the process manager about itsstatus. Our approach is based on prevention of er-rors rather than repairing them after their occurrence.By predicting the behavior of a flow appropriate mea-sures can be triggered in order to guarantee its suc-cessful execution. BPEL-TIME offers two differentpossibilities: an interval-based and a probabilistic ap-proach The interval-based approach allows the def-inition of fixed and/or variable temporal constraintssuch as deadlines and durations. The probabilistic ap-proach enables a probabilistic representation of tem-poral constraints and takes also branching probabili-ties into account.

2 MODEL DESCRIPTION

For modeling and calculation of temporal plans ofWS-BPEL executable and abstract processes threetypes of constraints have to be considered:

• Implicit constraints are derived implicitly fromthe structure of a process, e.g. an activity can startexecution if and only if all of its predecessors havefinished execution. This kind of constraints alsocan be referred to as structural constraints.

• Explicit constraints, e.g. assigned deadlines, canbe set explicitly by the process designer or en-forced by law, regulations or business rules.

• Dependencies with other processes may imposea temporal restriction on a process. It is notenough to perform a temporal analysis in isola-tion. The dependencies with other abstract andexecutable processes must also be taken into ac-count.

The first two constraints are needed to calcu-late the temporal plan of one single process. Thethird constraint must be considered in order to checkthe temporal conformance and calculate the temporalplans of a set cooperating processes. We model thefirst two constraints using two different modeling ap-proaches: the interval-based and the probabilistic ap-proach. Both models are described in subsections 2.1and 2.2 respectively.

2.1 Interval-Based Approach

The interval-based approach allows modeling of fixedand variable durations of activities. The durationof an activity can take any value within an intervalbounded by minimum and maximum durations, e.g.a.d = [a.dmin,a.dmax], where a.d refers to duration ofan activity a. We use upper-bound and lower-boundconstraints (Eder and Panagos, 2001) to model the in-terval within which the duration of an activity lies.

Lower-bound constraint identifies the minimumtemporal distance between two events. Let abe the source event and b the destination event.lbc(a,b,δ) denotes that between the event a andthe event b at least δ time points must pass.

Upper-bound constraint identifies the maximumtemporal distance between two events. Let abe the source event and b the destination event.ubc(a,b,δ) denotes that between the event a andthe event b at most δ time points can pass.

a.dmin and a.dmax can be modeled by defining theminimum and maximum allowed time points betweenstart event and end event of an activity respectively.

This scenario as depicted in fig. 1, where a.d = [2,7],as and ae refer to the start event and end event of theactivity a. Obviously an activity can also be assigneda fixed value, if a.dmin = a.dmax. Note that in the restof this paper, for the sake of brevity, we do not illus-trate lbc and ubc as well as start and end events inthe graphs. lbc and ubc are not only used for mod-eling dmin and dmax of activities. They can also beused for modeling temporal constraints between dif-ferent activities. For example ubc and lbc can be usedfor modeling requirements such as approval or rejec-tion of an application may take at most one week afterits receipt and sending a notification to the applicanttakes at least three days.

Figure 1: Modeling dmin and dmax by lbc and ubc.

As the basic modeling language, we adapt themodel presented in (Tahamtan, 2009). It is a timed ac-tivity graph or timed graph (Panagos and Rabinovich,1997) augmented with start and end events for ac-tivities. Timed graphs are familiar workflow graphswhere nodes correspond to activities and edges to thedependencies between activities, enriched with tem-poral information. Fig. 2 shows an example of themodel. All activities have a unique name and two cor-responding events (start and end events). The othernotions used in the fig. 2 are described in subsec-tion 2.1.1. Because BPEL-processes are full-blocked(WfM, 2002), in this work we restrict the graphs tofull-blocked ones, i.e. each split node has a counter-part join node and vice versa.

2.1.1 Calculation of Temporal Values

For calculation of temporal values, we extend the al-gorithms developed in our previous works (Eder andTahamtan, 2008; Eder et al., 2008). All activities havedurations. a.d denotes the duration of an activity a.The duration is an interval bounded by minimum andmaximum durations. At the first use of a model anestimation of the activity durations, e.g. expert opin-ion, may be used. Later, workflow logs can be minedfor actual activity durations. An interval in which an

activity may execute is calculated. This interval is de-limited by earliest possible start (eps-value) and lat-est allowed end (lae-value). a.eps denotes the eps-value of an activity a and is the earliest point in timein which the activity a can start execution. eps-valuesreflect the implicit constraints of a flow. a.lae rep-resents the latest point in time in which an activitya can finish execution in order to hold the assigneddeadline. lae-values reflect the explicit constraints ofa flow. Both eps and lae values are calculated for bestcase and worst case. Best case and worst case identi-fies the execution of the shortest and longest path of aflow respectively. a.bc.eps refers to best case eps anda.wc.eps refers to worst case eps of an activity a. Thesame applies to lae-values. eps-values are calculatedin a forward pass by adding the eps-value of the pre-decessor to its duration. Minimum duration for bestcase and maximum duration for worst case are consid-ered. For example b.bc.eps = a.bc.eps + a.dmin andb.wc.eps = a.wc.eps+a.dmax if an activity a is a pre-decessor of an activity b. If an activity a has multiplepredecessors, e.g. if activity a is an immediate suc-cessor of an AND-join or the target node of an lbc,the maximum of eps-values of predecessors of a andthe lbc is taken into account. The eps-value of thefirst activity or the set of first activities are set to 0.

In contrast to the eps-values, lae-values are calcu-lated in a backward pass by subtracting the lae-valueof the successor from its duration, e.g. a.bc.lae =b.bc.lae− b.dmin and a.wc.lae = b.wc.lae− b.dmax ifan activity b is a successor of an activity a. If an ac-tivity a has multiple successors, e.g. if activity a issource of an lbc, the minimum of lae-values of prede-cessors of a and the lbc is taken into account.

Temporal values of a simple graph are depicted infig. 2. Given known activity durations, in addition wecan calculate earliest possible end (epe-values) andlatest allowed start (las-values) for an activity, us-ing the following formulas: a.epe = a.eps + a.d anda.las = a.lae− a.d. We refer to eps-values and epe-values as e-values and to lae-values and las-values asl-values. In this approach we handle loops as com-plex activities. For calculation of the temporal planat design time we consider only one iteration. Be-cause the actual iterations of a loop is not known atdesign time, its execution is monitored at run timeand process manager receives notifications about thetemporal status of the process. For a more detaileddiscussion on calculation of interval-based values andtheir algorithms, refer to (Tahamtan, 2009; Eder andTahamtan, 2008).

Figure 2: An example of a timed graph with deadline= 50.

2.2 Probabilistic Approach

Fixed or variable duration of activities can be mod-eled using the interval-based approach. However, insome use cases one may need to consider branchingprobabilities. The probabilistic approach described inthe following subsections caters for probabilistic rep-resentation of temporal constraints.

2.2.1 Probabilistic Model Description

In order to express variable duration of activities, thenotion of time histograms (Pichler, 2006; Eder andPichler, 2002) is used. A duration histogram is adata structure for representation of the (probabilisticand variable) duration of basic activities, complex ac-tivities, subworkflows and workflow itself. A dura-tion histogram is a tuple (p,d), where p is a prob-ability and d a duration. For example the proba-bilistic duration of an activity can be represented as{(0.1,10),(0.25,12),(0.32,15),(0.33,20)}. This dura-tion can be interpreted as follows: the duration of thisactivity is with the probability 10%, 10 time points,with the probability 25%, 12 time points, with theprobability 32%, 15 time points and with the proba-bility 33%, 20 time points. If a duration histogramcontains any tuples whose time values are the same,these tuples must be merged by adding the probabil-ities of tuples with the same duration. A workflowgraph augmented with probabilistic temporal infor-mation for activities and nodes is referred to as proba-bilistic timed graph (PTG). Fig. 3 illustrates an exam-ple of such a probabilistic timed graph. The durationof activities are given in the table above the graph.

All control nodes have the duration 0. The dead-line of the workflow is also given in form of a (proba-bility, duration) tuple. Further, it is assumed that thereis no delay between end of an activity and start of itssuccessor or the set of its successors. Analogous toduration histograms (d-histograms), (Pichler, 2006)

defines e-histograms for presentation of e-values andl-histograms for presentation of l-values. Note thatfor probabilistic calculations we do not consider bestand worst case or lbc and ubc.

2.2.2 Histogram Operations

In order to calculate the temporal values, operationson histograms are necessary. Theses histograms oper-ations are briefly introduced in this subsection.

The histogram addition generates the carte-sian product of the tuples of two histograms,where probabilities are multiplied and time valuesare added: {(0.25,3),(0.75,5)}+ {(0.5,3),(0.5,5)} ={(0.125,6),(0.125,8),(0.375,8),(0.375,10)}. Resultingtuples with equal time values are aggregated, whichmeans they are merged by summing up their proba-bilities: {(0.125,6),(0.5,8),(0.375,10)}.

The histogram subtraction h1−h2 is a variation ofthe addition, with the only difference that time valuesfor the resulting tuples are subtracted.

The histogram conjunction also generatesa cartesian product. Again probabilities aremultiplied, but this time the maximum timevalue of each tuple-combination determinesthe time value of the resulting tuple. There-fore it is also called the max-conjunction:{(0.25,3),(0.75,5)}∧

max{(0.5,3),(0.5,5)}= {(0.125,3),(0.125,5),(0.375,5),(0.375,5)}. Again the finalresulting histogram has to be aggregated, whichresults in {(0.125,3),(0.875,5)}. A variation of thisoperation is the min-conjunction which determinesthe time value of the resulting tuple by applying aminimum-operation.

The weight-operation multiplies all proba-bilities of a histogram with a given probability:{(0.25,3),(0.75,5)} ∗ 0.25 = {(0.0625,3),(0.1875,5)}.Please note that the weight operation producesan invalid histogram, as the sum of probabilitiesis less than 1.0. Therefore it always appears

Figure 3: A sample probabilistic timed graph (PTG).

in combination with the histogram disjunc-tion, which merges two weighted histograms:{(0.0625,3),(0.1875,5)}∨{(0.375,3),(0.375,5)} ={(0.0.625,3),(0.1875,5),(0.375,3),(0.375,5)}; and theaggregation which yields to {(0.4375,3),(0.5625,5)}.

Both, conjunction and disjunction, are commuta-tive and associative, therefore they can be extendedto k histograms, e.g.: h = h1 ∨ . . .∨ hk =

∨hi, where

1≤ i≤ k.The histogram comparison is applied for compar-

ing two histograms with each other. Unlike discretevalues, two histograms h1 and h2 may partially over-lap. Thus an expression like h1 < h2 can be true andfalse at the same time, each at least up to a certaindegree. The comparison of two histograms h1 andh2 with the comparison-operator ./∈ {≤,<,=,>,≥}for a given degree 0≤ deg≤ 1 is defined as follows:

h1 ./deg h2 =

true : Σp1 ∗ p2 ≥ deg∧ t1 ./ t2,∀(p1, t1) ∈ h1,∀(p2, t2) ∈ h2

f alse : otherwise

Based on the histograms h1 and h2, depicted in fig. 4,we can make the following statements: up to a degreeof 0.545, h1 is greater than h2 and up to a degree of0.35, h1 is equal to h2. For instance, the following ex-pressions are true: h1 <0.05 h2, h1 >0.25 h2, h1 >0.545h2, and the following are false: h1 >0.7 h2, h1 ≥0.9 h2.In order to check the total histogram equality the cer-tainty degree must be set to 1.0: h1 =1.0 h2. To ensurethat two histograms have no overlapping regions atall, they must be compared with the certainty degreeof 1.0: h1 <1.0 h2 or h1 >1.0 h2.

A relaxed certainty allows for overlapping re-gions, which might prove useful especially if thereare (extreme) outliers in histograms. For exampleimagine that the mean of a histogram h3 is 5 and itcontains one extreme outlier, the tuple (0.005,1000).Even with a histograms h4 that contains much higher

time values, a <-comparison with 100%-certainty al-ways yields false. Relaxing the certainty-value just by0.01% will avoid most conformance-conflicts (still,one day this highly improbable case might occur).

2.2.3 Calculation of Probabilistic Timed Graphs

e-histograms (eps-histograms, epe-histograms) ofnodes of a workflow can be calculated by apply-ing the forward calculation rules in a topological or-der. These rules are specified in table 1 accordingto the node types. In table 1, node.eps denotes theeps-histogram of the current node, node.epe its epe-histogram, node.d the duration histogram of the cur-rent node, pred.epe identifies the epe-histogram ofthe predecessor node, node.Pred the set of predeces-sor nodes of the current node and ppred⇒node identi-fies the execution probability of the edge connectingthe predecessor node to the current node.

Except for nodes with multiple incoming paths,i.e. AND-join and XOR-join, the duration-histogramsare summed up to calculate the according e-histograms. For AND-joins the max-conjunction isapplied because the longest path (or histogram-tuple)determines the resulting tuple. For XOR-joins, thehistograms of predecessors are weighted with the ac-cording branching probability and subsequently theyare merged applying the conjunction.

Analogously, for calculation of l-histograms (las-histograms and lae-histograms) the backward calcu-lation rules, as specified in table 2, have to be ap-plied in a backward topological order. In table 2node.lae refers to the lae-histogram of the currentnode, node.las the las-histogram of the current node,{(1.0,δ)} denotes the assigned deadline, node.d theduration histogram of the current node, succ.lasidentifies the las-histogram of the successor node,node.Succ the set of successor nodes of the currentnode and pnode⇐succ the execution probability of the

0.15

0.50

0.35

10

15

20

0.30

0.70

9

15

0.045 10

15

20

10

15

20

9

9

9

15

15

15

>

>

>

<

=

>

0.350

0.105

0.105

0.150

0.245

t1 > t2 : 54.5 %

t1 t2p1 p2 p1 * p2 t1 t2

Histogram h1 Histogram h2

t1 = t2 : 35.0 %

t1 < t2 : 10.5 %

t1 <= t2 : 45.5 %

t1 => t2 : 89.5 %

Figure 4: Calculating the values for histogram comparison.

type of node node.eps = node.epe =Start {(1.0,0)} node.eps+node.dEnd pred.epe node.eps+node.d

Activity pred.epe node.eps+node.dAND-split pred.epe node.eps+node.dXOR-split pred.epe node.eps+node.dAND-join ∀pred ∈ node.Pred :

∧max(pred.epe) node.eps+node.d

XOR-join ∀pred ∈ node.Pred :∨

(pred.epe∗ ppred⇒node) node.eps+node.d

Table 1: Calculation of e-histograms.

edge connecting the current node with the successornode.

When reversing the direction of calculation, be-ginning from the end-node to the start-node, his-togram subtraction is applied instead of histogram ad-dition. lae-histogram of the end node is initializedwith the assigned deadline. Special rules must be ap-plied when calculating the l-histograms of the nodeswith multiple outgoing paths: AND-split and XOR-split. lae-histogram of an AND-split is calculated by amin-conjunction over its outgoing paths. XOR-splitsare calculated by a weighted disjunction of the outgo-ing paths. The probabilistic approach provides bettermeans for handling loops. Again here, loops are han-dled as complex activities. The number of iterationscan be reflected in durations of the complex activitywith different probabilities. At run time the execu-tion is monitored. For a more detailed discussion ofthe probabilistic approach and some examples, referto (Eder et al., 2008).

3 Temporal Management ofWS-BPEL Executable andAbstract processes

The interval-based and the probabilistic approachpresented above can be used to calculate the tempo-ral plan of one single executable or abstract processin isolation. However, in order to calculate the tem-

poral plans of a set of cooperating executable andabstract processes and check their temporal confor-mance, it is necessary to consider the dependenciesbetween them. Executable and abstract processesmay be linked in several ways. A typical scenario(Barros et al., 2005; Decker et al., 2006; Dijkman andDumas, 2004) of web service composition assumesone abstract process shared among several partnerswhere each partner realizes its parts of the abstractprocess in its executable process. The shared abstractprocess defines the communication among executableprocesses. This scenario is depicted in fig. 5. An exe-cutable process does not solely contain (a subset of) ofactivities of an abstract process rather it may containother internal tasks of its owner. (Eder et al., 2007)provides a technique for checking if the ordering ofthe activities in executable and abstract processes isstructurally compliant.

(Eder et al., 2006; Tahamtan and Eder, ) intro-duce other architectures for web service composition.This architecture is a two layered model where an ab-stract or executable process can be an extended sub-set of another abstract process. The most importantissue to consider regarding the dependency betweentwo nodes (abstract and/or executable processes) isthe greatest common divisor (GCD) of their activities.GCD identifies the set of common activities in twonodes. A dependency between two nodes implies thatGCD of activities of two nodes is not empty, i.e. thesetwo nodes have at least one activity in common. De-pendencies between activities are depicted using links

type of node node.lae = node.las =End {(1.0,δ)} node.lae−node.dStart succ.las node.lae−node.d

Activity succ.las node.lae−node.dAND-join succ.las node.lae−node.dXOR-join succ.las node.lae−node.dAND-split ∀succ ∈ node.Succ :

∧min(succ.las) node.lae−node.d

XOR-split ∀succ ∈ node.Succ :∨

(succ.las∗ pnode⇐succ) node.lae−node.d

Table 2: Calculation of l-histograms.

Figure 5: A typical scenario of Web Service composition.

between them as in fig. 5. Fig. 6 depicts the abstractprocess C and the executable process O1 in fig. 5. TheGCD of two graphs include the activities Receive re-quest and Reply request. For the sake of brevity thethe executable process O2 is omitted.

If two nodes have no common activities, these twonodes are temporally independent from each otherand their temporal plans can be calculated in isola-tion. If GCD of two nodes is not empty these twonodes affect each other through the common activi-ties. In this case a cycle of calculation-assignment-recalculation beginning with the abstract process andalong the all links in the model must be repeated. Inthe assignment phase, temporal values of the activi-ties of GCD are assigned from the source node to thetarget node. The assignment is only performed if e-values of the source node are greater than e-values ofthe target node. l-values are assigned if l-values ofthe source node are smaller than those of the targetnode. In other words an assignment is only allowedif the current valid execution interval of an activity inthe target node becomes tighter. The concept of as-signment is depicted in fig. 6. If any temporal valuechanges after the assignment, the temporal plan of thegraph must be recalculated as described above. Againhere, current values can be overwritten if newly cal-

culated e-values are greater than current values andnewly calculated l-values are smaller than current l-values. This cycle is repeated until a stable state isreached or the conformance condition is violated. Astable state is reached if no changes is made after as-signment of values from one node to another. Confor-mance condition is violated if e-value of an activitybecomes greater than its corresponding l-value. Thetop part of the Fig. 6 illustrates the graphs after calcu-lation of C and O1 and assignment of values from Cto O1. The bottom part of the figure illustrates the val-ues after recalculation at O1, assignment of the valuesfrom O1 to C. A recalculation at C does not changethe values at C and hence these values are final values.As you can see the same activities in different graphshave the same final temporal values. The arrows onlyshows the assigned values. For example in the top partof the figure the e-values of the activity Receive re-quest in the abstract process C are equal to those in theexecutable process O1 and hence not assigned. Theprobabilistic approach, as well, uses the same con-cept for assignment and calculation of temporal plans.The histogram comparison as described above can beused for comparing histograms and assignment of val-ues from one graph to another. The same technique(calculation-assignment-recalculation) also applies ifthere are more than one abstract process present inthe model. In fig. 6 please also note the differencebetween deadline and maximum duration (dmax). Adeadline is a point in time whereas maximum dura-tion is a time period. For example deadline of a pro-cess may be 15th of July, 12:00 but maximum dura-tion says that a process can execute for 10 hours afterstarting execution.

4 Prototypical Implementation

Our prototype has been implemented based onthe open source softwares Eclipse BPEL designerand Apache ODE (Orchestration Director Engine).The prototype consists of two components: A design

Figure 6: Propagation of values for the same activity in different graphs.

time component that allows the definition of cooper-ating processes, their dependencies and temporal con-straints (deadline, activity durations, lower and up-per bound constraints between activities). The de-sign time component also checks the temporal sat-isfiability of the model. It checks if there exists asolution that satisfies temporal constraints of all pro-cesses. If such a solution does not exist the user willbe informed which part of the process has temporalconflicts. In this case process structure or temporalconstraints should be redefined such that the tempo-ral constraints can be satisfied. Design time compo-nent calculates a valid temporal window for each ac-tivity. If activities execute within their valid temporalwindow it can be guaranteed that all cooperating pro-cesses execute and terminate in a temporally compli-ant way. The run time component monitors the exe-cution of each activity and checks if it executes withinits valid temporal window. If any deviation is foundthe user receives an alarm about the process status.We use the traffic light model presented in (Eder andPanagos, 2001). If all activities executes within theirvalid temporal window the traffic light is green andeverything is ok. If some activities deviate from theirprecalculated valid temporal window but it is still pos-sible to hold the deadline and satisfy the temporal

constraints (e.g. by executing the shortest path of aconditional structure) the traffic light turns to yellow.If some activities took longer than expected and in anycase, even in best case scenario, temporal constraintswill be violated, the traffic light turns to red. In thiscase the process manager can decide to cancel the ex-ecution prematurely or skip some activities. The pro-totype, an installation and troubleshooting guide andan introduction how to perform basic tasks such asdefining BPEL-process, preparing wsdl-files and set-ting up variables can be found on our homepage (ifs,).

4.1 Design Time Component

The design time component is prototyped underEclipse Helios. The required functionalities are im-plemented under properties as depicted in fig. 7. Af-ter definition of the structure of the processes, the de-pendencies between processes can be defined usingthe property choreography. A supported process canbe chosen using Select Process. A supported processidentifies processes that have a link to this process,i.e. their GCD is not empty. This can be an executableprocess or another abstract process. The combo boxbeneath allows for choosing processes that support

this process. Dependencies can be added or removed.The result is written in an XML-file called dependen-cies.xml.

Temporal constraints can be set under Constraints(see fig. 8). It is possible to set minimum and max-imum duration of activities and the deadline for theprocess. Further it is possible to add and remove op-tional lower and upper bound constraints between ac-tivities. The right part of the fig. 8 shows the temporalvalues of each activity after calculation.

Certainty allows the definition of probabilisticvalues: durations of activities and their probabilitiesas well as the deadline of the whole process. Theprobabilistic temporal values can be calculated by theCalculate button.

4.2 Run Time Component

The run time component is implemented in ApacheODE 1.3.4. It monitors the process execution andchecks if activities are executed within their validtemporal interval. At process instantiation time, anactual calendar is used in order to transform all timeinformation which was computed relative to the startof the flow to absolute time points (Eder et al., 1999).For every instantiated activity, the calendar e-value iscompared with the start date of the instantiated activ-ity. In the same way, the mapped calendar l-value isalso compared with the end date of the instantiatedactivity. The traffic light model (Eder and Panagos,2001) provides an overview for process manager. Ifactivities execute within their calculated interval atdesign time it is guaranteed that all processes remaintemporally compliant. If some activities are delayedand deviate from their valid temporal window, it ispossible that a deadline be violated. In this case thetraffic light turns to yellow indicating that some ac-tivities are delayed but it is still possible to finish theexecution in time. The process manager may decideto force the process to execute the shortest path in or-der to guarantee the temporal compliance. If activitiesare delayed to the extent that future execution in anycase leads to temporal violation, the traffic light turnsto red. In this case, the process manager may wantto cancel execution prematurely in order to reduce theprocess execution costs. Fig. 10 shows a screen shotof the run time component.

5 Related Works

One of the earliest works on time properties is(Allen, 1983). Allen describes a temporal represen-tation using the concept of temporal intervals and

introduces a hierarchical representation of relation-ships between temporal intervals applying constraintspropagation techniques. This work describes thir-teen ways in which an ordered pair of intervals canbe related. Authors in (Eder et al., 1999) present amodel for calculation of temporal plans and proposesome algorithms for calculation and incorporationof time constraints. (Eder and Panagos, 2001) pro-vides a methodology for calculating temporal plans ofworkflows at design time, instantiation time and runtime. It considers several temporal constraints such aslower-bound, upper-bound and fixed-date constraintsand explains how these constraints can be incorpo-rated. Moreover, a model for monitoring the satisfac-tion of temporal constraints at run time is provided.(Eder et al., 2000) provides a technique for model-ing and checking time constraints whilst conditionaland parallel branches are discriminated. In addition,an unfolding-method for detection of scheduling con-flicts is provided. Marjanovic in (Marjanovic, 2000)represents the notions of duration space and instan-tiation space and describes a technique for verifica-tion of temporal constraints in production workflows.The approach presented in this paper is complemen-tary to that introduced in (Marjanovic, 2000) in theway that a temporal plan for execution of all activitiesis calculated. (Benatallah et al., 2005) uses tempo-ral abstractions of business protocols for their com-patibility and replaceability analysis based on a finitestate machine formalism. Kazhamiakin, Pandya andPistore in (Kazhamiakin et al., 2006b), as well as in(Kazhamiakin et al., 2006a), exploit an extension oftimed automata formalism called web service timetransition system (WSTTS) for modeling time prop-erties of web services. The approach presented inthis work can cover cases which can be modeled inthese works and additionally allows the definition ofexplicit deadlines. This work extends previous worksby addressing the conformance and verification prob-lem and provides an a priori execution plan at designtime consisting of valid execution intervals for all ac-tivities of participating abstract and executable pro-cesses with consideration of the overall structure andtemporal restrictions. The calculated execution planscan be monitored at run time. (Bettini et al., 2002)proposes a formalism for representation of quantita-tive temporal constraints. A consistency service en-sures the satisfiability of temporal constraints. Au-thors in (Kallel et al., 2009) propose an approach forspecification and monitoring of relative and absolutetemporal constraints based on XTUS-automata andAo4BPEL. In this approach temporal constraints canbe translated into modular aspect code that listens toactivities during the execution of a process. An activ-

Figure 7: Definition of dependencies between processes.

ity will be only executed if the temporal constraintsare satisfied. Guermouche et al. in (Guermoucheet al., 2008) study temporal aspects of Web Services.They differentiate between internal and external tem-poral constraints. Internal constraints specify a rel-ative and absolute time period and can be used forexpression of activation and dependency conditions.External constraints are exposed by the client and theprovider service. They have to be checked before in-teraction initialization. They infer from internal con-straints and allow for detection of incompatibilitiesof services. Song et al. in (Song et al., 2009) use

petri nets for description and modeling of behaviorand temporal aspects of BPEL processes. The short-coming of this approach is that only analysis is con-sidered. Our approach is complementary in the sensethat it allows for analysis and temporal reasoning andfurther a BPEL-extension for execution is provided.

6 Conclusions

Temporal management and consistency are impor-tant quality criteria for business processes. They im-

Figure 8: Definition and calculation of interval-based temporal values.

Figure 9: Definition and calculation of probabilistic temporal values.

prove QoS and reduce costs. WS-BPEL lacks suf-ficient time management capabilities. In this workwe introduced an extension of WS-BPEL that makesbusiness processes time aware and overcomes thisshortcoming. The user can define different tempo-ral constraints, check temporal feasibility and mon-itor the execution. The two considered techniques,interval-based and probabilistic, caters for differentneeds of the users in different scenarios.

REFERENCES

Vienna university of technology, institute of software tech-nology and interactive systems, information & soft-ware engineering group. http://www.ifs.tuwien.ac.at/.

(2002). Workflow process definition interface - xml pro-cess definition language. Technical Report WFMC-TC-1025, The Workflow Management Coalition.

Allen, J. (1983). Maintaining knowledge about temporalintervals. Communications of the ACM, 26(11):832–843.

Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B.,Curbera, F., Ford, M., Goland, Y., Guzar, A., Kartha,N., Liu, C., Khalaf, R., Koenig, D., Marin, M., Mehta,V., Thatte, S., Rijn, D., Yendluri, P., and Yiu., A.(2007). Web services business process execution lan-guage version 2.0. Technical report, OASIS.

Barros, A., Dumas, M., and Oaks, P. (2005). A criti-cal overview of the web services choreography de-scription language(ws-cdl). Technical report, Busi-ness Process Trends.

Benatallah, B., Casati, F., Ponge, J., and Toumani, F.(2005). On temporal abstractions of web service pro-tocols. In Proc. of CAiSE Forum.

Bettini, C., Wang, X. S., and Jajodia, S. (2002). Tempo-ral reasoning in workflow systems. Distrib. ParallelDatabases, 11:269–306.

Decker, G., Overdick, H., and Zaha, J. (2006). On the suit-ability of ws-cdl for choreography modeling. In Proc.of EMISA’06.

Dijkman, R. and Dumas, M. (2004). Service-oriented de-sign: A multi-viewpoint approach. Int. J. CooperativeInf. Syst., 13(4):337–368.

Eder, J., Gruber, W., and Panagos, E. (2000). Tempo-ral modeling of workflows with conditional executionpaths. In Proc. of the 11th International Conferenceon Database and Expert Systems Applications.

Eder, J., Lehmann, M., and Tahamtan, A. (2006). Chore-ographies as federations of choreographies and or-chestrations. In Proc. of CoSS’06.

Eder, J., Lehmann, M., and Tahamtan, A. (2007). Confor-mance test of federated choreographies. In Proc. ofI-ESA’07.

Eder, J. and Panagos, E. (2001). WfMC WorkFlow Hand-book 2001, chapter Managing Time in Workflow Sys-tems. J. Wiley & Sons.

Eder, J., Panagos, E., and Rabinovich, M. (1999). Time con-straints in workflow systems. In Proc. of the 11th In-ternational Conference on Advanced Information Sys-tems Engineering (CAiSE).

Eder, J. and Pichler, H. (2002). Duration histograms forworkflow systems. In Proc. of the IFIP TC8 / WG8.1Working Conference on Engineering Information Sys-tems in the Internet Context.

Figure 10: The run time component monitors the execution.

Eder, J., Pichler, H., and Tahamtan, A. (2008). Probabilis-tic time management of choreographies. In Proc. ofQSWS-08.

Eder, J. and Tahamtan, A. (2008). Temporal conformanceof federated choreographies. In Proc. of DEXA’08.

Guermouche, N., Perrin, O., and Ringeissen, C. (2008).Timed specification for web services compatibilityanalysis. Electron. Notes Theor. Comput. Sci., 3:155–170.

Kallel, S., Charfi, A., Dinkelaker, T., Mezini, M., andJmaiel, M. (2009). Specifying and monitoring tempo-ral properties in web services compositions. In Proc.of the Seventh IEEE European Conference on WebServices.

Kazhamiakin, R., Pandya, P., and Pistore, M. (2006a). Rep-resentation, verification, and computation of timedproperties in web service compositions. In Proc. ofICWS 06.

Kazhamiakin, R., Pandya, P., and Pistore, M. (2006b).Timed modelling and analysis in web service compo-sitions. In Proc. of ARES06.

Marjanovic, O. (2000). Dynamic verification of temporalconstraints in production workflows. In Proc. of theAustralasian Database Conference.

Panagos, E. and Rabinovich, M. (1997). Predictive work-flow management. In Proc. of the 3rd Int. Work-shop on Next Generation Information Technologiesand Systems.

Peltz, C. (2003). Web services orchestration and choreog-raphy. IEEE Computer, 36(10):4653.

Pichler, H. (2006). Time Management for WorkflowSystems. A probabilistic Approach for Basic andAdvanced Control Flow Structures. PhD thesis,Alpen-Adria-Universitaet Klagenfurt. Fakultaet fuerWirtschaftswissenschaften und Informatik.

Song, W., Ma, X., Ye, C., Dou, W., and Lu, J. (2009). Timedmodeling and verification of bpel processes using timepetri nets. In Proc. of the International Conference onQuality Software.

Tahamtan, A. (2009). Modeling and Verification of WebService Composition Based Interorganizational Work-flows. PhD thesis, University of Vienna.

Tahamtan, A. and Eder, J. View driven interorganiza-tional workflows. Int. J. Intelligent Information andDatabase Systems, To Appear.