Dynamic Transactional Workﬂows in Service-oriented Environments

David Paul, Frans Henskens and Michael Hannaford

School of Electrical Engineering and Computer Science, University of Newcastle, Callaghan, NSW, Australia

Keywords:

Web Service, Transaction.

Abstract:

Transactions in service-oriented environments, such as those provided by Web Services, traditionally support

a reduced set of the ACID properties. This has typically required providers to constantly offer a ﬁxed level

of transaction support for each client request to a service. Further, clients have been limited in their ability

to combine services with different transactional guarantees into a single workﬂow. We present a mechanism

that allows the dynamic speciﬁcation of transaction support for a given service call, and a cost-based model

that allows clients to automatically reason about workﬂows consisting of service requests with various levels

of transaction support. A Web Services transactions simulator is used to verify the viability of this dynamic

transaction scheme, with results indicating potential beneﬁts for both service providers and clients.

1 INTRODUCTION

In Web Services and similar service-oriented environ-

ments, providers offer services that are available to be

consumed by clients. Clients use messages to send

service requests to providers, and respective providers

respond either that the request was successful, or

that the service was not performed. This provides a

loosely-coupled environment in which the client need

not be aware of the intricate details of how a provider

performs its service.

Clients use services to perform particular tasks.

However, it is often the case that no single provider

offers a service that completely satisﬁes a client’s

needs. Thus clients have a need to combine multi-

ple services, typically from different providers, into a

single workﬂow. The client views all of the providers

participating in its workﬂow as participants working

on achieving the client’s task. Each individual ser-

vice call is part of an overall workﬂow, and the task

will only be complete when the required service calls

have all succeeded. The various providers used by

the client do not know that their services are being

combined with those of other providers, and need not

even know that the other providers exist; all a provider

knows is that it is being asked to perform a service.

If all service requests are guaranteed to be suc-

cessfully handled, a client can simply call all services

required to complete the workﬂow, and the result will

be successful. However, a client cannot be certain that

a particular service call will succeed. Thus, it may

be possible for part of a client’s workﬂow to succeed

while other parts fail. Since the client views the entire

workﬂow as a single task, such a partially completed

workﬂow may not be appropriate. For example, when

booking a holiday, there is no point in booking a hotel

in the destination city if the client is unable to book a

ﬂight to take them there.

Thus there is a need for clients to combine multi-

ple service calls into a single workﬂow in which any

errors are handled gracefully, with the deﬁnition of

the term ‘graceful’ being based on the client’s needs.

One possible technique that can be used for this pur-

pose is transactions. Transactions combine services

provided by multiple, possibly completely unrelated,

parties into a single action, with well-deﬁned be-

haviour whenever a part of the transaction fails.

In traditional systems, transactions offer various

guarantees, such as an assurance that all actions in

the transaction will complete successfully, or none

of them will occur. The restraints that these guar-

antees require are often considered unacceptable in

service-oriented environments, because they place an

unfair burden (that can reduce the efﬁciency of the

entire system) on service providers. Instead, the guar-

antees are typically weakened to provide acceptable

behaviour to the client with fewer restrictions on the

provider. Since each provider may be completely in-

dependent, a client workﬂow may need to combine

service calls with different transactional guarantees to

achieve an acceptable result.

Further, different clients may have different views

Paul D., Henskens F. and Hannaford M..

Dynamic Transactional Workﬂows in Service-oriented Environments.

DOI: 10.5220/0004368000260036

In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST-2013), pages 26-36

ISBN: 978-989-8565-54-9

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

as to which guarantees are acceptable for a given ser-

vice call. For example, if part of a client’s work-

ﬂow is optional, the client may be willing to accept

lesser guarantees than if that part was necessary for

success. In this paper we describe a technique that

allows providers to dynamically change the level of

transaction support they offer for a particular service,

and a means for clients to reason about such dynamic

workﬂows. A simulator is used to show the viability

of this approach.

The main contribution of this paper is to formalise

the dynamic Web Services transactions system intro-

duced in (Paul et al., 2010; Paul et al., 2011). This is

achieved by ﬁrstly, in Section 2 describing the needs

of a service composition platform, and how transac-

tions ﬁt in with such a system. Section 3 then de-

scribes a motivating scenario that highlights some of

the limitations of transactions as they are currently

supported in the Web Services environment. This is

followed, in Section 4, by presentation of a formal

approach that overcomes these limitations. Section 5

introduces a simulator that is used to verify the new

approach, and Section 6 uses the simulator to model

the motivating scenario. Finally, Section 7 concludes

the work and offers future directions for research.

2 BACKGROUND

This section provides an overview of the current state

of Web Services as a service composition platform.

Section 2.1 examines the requirements of such a plat-

form, how the requirements are currently handled in

the Web Services environment, and where limitations

exist. Section 2.2 then describes the role transactions

play in service composition, and how transactions in

the Web Services environment differ from more tradi-

tional transactional systems.

2.1 Service Composition Platforms

Chakraborty and Joshi (Chakraborty and Joshi, 2001)

identify ﬁve different issues that must be provided by

a comprehensive service composition platform so that

dynamic service compositions can be formed. This

section examines those requirements.

2.1.1 Service Discovery

Before multiple services can be combined into a ser-

vice composition, it is necessary to ﬁnd a service or

services that can perform the required tasks. Service

discovery requires semantic information so the sys-

tem can automatically determine which services (or

combination of services) offer the functionality that

is required by the client. This issue is beyond the

scope of this paper, but efforts in the Semantic Web

are making such discovery possible.

2.1.2 Uniform Information Exchange

Infrastructure

Different services may operate in different ways (e.g.

taking different parameters, or returning informa-

tion differently), but a service composition platform

should abstract over these differences. With Web

Services, it is possible to deﬁne an abstract ser-

vice (Sch

afer et al., 2007) that knows how to interact

with each of the different services that offer similar

functionality. This abstract service, when requested

by a client, contacts actual providers, converting the

client’s request into the form that is understood by

each particular provider, receiving any response(s),

and returning them to the client in a uniform format.

2.1.3 Adaptiveness

To allow true adaptiveness, it must also be possi-

ble to dynamically compose services when necessary

to provide required functionality (Milanovic et al.,

2003). One approach to implementing dynamic com-

positions is to have semantic contracts with each

provider (Milanovic, 2006). Then, by utilising a

good service discovery mechanism, an abstract ser-

vice that performs its own service composition could

be created to provide the functionality required by the

client.

2.1.4 Other Requirements

The remaining issues required of a good ser-

vice composition platform are: service coordination

and management; and fault tolerance and scalabil-

ity (Chakraborty and Joshi, 2001). Service coordina-

tion and management requires a way to communicate

with each of the services involved in the composition

to ensure correct behaviour of the composition. Fault

tolerance and scalability requires the system to cor-

rectly handle faults, and efﬁciently use the resources

available to the system.

Transactions allow multiple actions to be com-

bined into a seemingly single action, can be arbitrarily

nested, and each nested transaction can specify how it

handles errors. Thus, it is possible to solve the re-

maining issues required for a good service composi-

tion platform by supporting transactions in the Web

Services environment.

DynamicTransactionalWorkflowsinService-orientedEnvironments

2.2 Web Services Transactions

Transactions typically provide the ACID properties of

Atomicity, Consistency, Isolation, and Durability. By

ensuring these properties, transactions are guaranteed

to complete in a predictable way, making it impos-

sible for the transactions to perform operations that

would compromise the integrity of the system.

However, in service-oriented environments, com-

plete support for ACID properties is often unde-

sirable. In these environments, transactions typi-

cally have a much longer running time than is ex-

perienced when transactions execute in traditional

transaction systems. The different services involved

in a transaction may be offered by completely au-

tonomous providers, and communication between

these providers already increases the duration of any

transaction. The independence of each provider

means they will often be unwilling to reduce their au-

tonomy to such an extent that complete ACID sup-

port is possible. Thus, certain reductions to the ACID

properties are typically supported in service-oriented

environments, such as replacing atomicity with se-

mantic atomicity (Garcia-Molina, 1983), or offering

tentative holds (Fauvet et al., 2005).

Most Web Services transactions standards are lim-

ited in their ability to allow clients to combine ser-

vices with different transactional guarantees into a

single workﬂow (Mikalsen et al., 2002). Mikalsen

et al. introduce a new way to ensure transactional

reliability in the Web Services environment. Their

technique allows providers to indicate the “transac-

tional attitude” of the provider for each service it pro-

vides; that is, the kind of transactional support that

the provider offers for the service. Clients also in-

dicate their transactional attitude by utilising a Web

Service to create and manage a pre-deﬁned transac-

tional pattern. Once providers and clients have spec-

iﬁed their transactional attitudes, middleware is used

to automatically manage the context and transactional

interaction between a client and a set of providers.

With transactional attitudes, a provider must spec-

ify the level of transaction support it offers along with

its service deﬁnition. This makes it impossible for

the provider to alter the level of transaction support

it offers for a particular service. In some cases, dif-

ferent clients may require different levels of transac-

tional support for a particular service. Paul et al. (Paul

et al., 2010) suggest a method that allows providers to

dynamically alter the level of transaction support on

offer for a particular service. In this paper, we fur-

ther argue this point, and provide a formal model that

allows arbitrarily complex client workﬂows to utilise

such enhanced transactional properties.

3 MOTIVATING SCENARIO

Consider a public screen shared by multiple compa-

nies to display various pieces of information content.

The screen provides a Web Service that allows clients

to book time on the display. Further, consider a client

that wishes to use the screen to inform the public

of sporadically-changing data. The client is notiﬁed

whenever new data are available, and can then use

a Web Service to access the data. That data can be

passed to a Web Service offered by a render farm to

convert it into a visualisation suitable for the public

screen. Each Web Service has a cost associated with

its use.

On notiﬁcation that new data is available, the

client can retrieve the data, pass the data to the ren-

der farm, and display the visualisation at the time the

client has the public screen booked. Since the data is

updated sporadically, the client cannot book the dis-

play in advance, but can only attempt to do so when

new data is released. However, since there is a fee

associated with each Web Service, the client would

prefer to only retrieve and render the data if it is guar-

anteed time on the display. Similarly, the client would

not wish to retrieve the new data if ever the render

farm was too busy to process the client’s request.

The client can achieve its aim of only retrieving

data if the render farm is available, and only attempt-

ing either action if the screen can be booked, if each

of the providers offers suitable levels of transaction

support. However, different clients using the shared

screen may not all have identical transactional re-

quirements. The following section describes a mech-

anism that allows providers to dynamically alter the

level of transaction support they offer for each ser-

vice call, and a method that allows clients to combine

services with different transactional guarantees into a

single workﬂow.

4 DYNAMIC TRANSACTIONS

When providers offer a service, there is a level of

transactional support they offer along with that ser-

vice. In the simplest case, there is no explicit trans-

actional support offered; the service either completes

successfully or fails. More advanced cases allow

the provider to deliver information or guarantees to

a client before the client utilises the service, or allow

the client to perform the operation but later cancel it

if required. This section discusses the levels of trans-

actional support that a provider can offer.

On examining the possible reductions, it becomes

apparent most can be described using a combination

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

of ﬁve basic operations that can be requested by a

client (Paul et al., 2011):

Enquire. Allows the client to query whether a re-

quest would currently be successful, without any

guarantee that a later request will succeed.

Prepare. Allows the client to query whether a re-

quest would currently be successful and, if so,

guarantees that any such request sent by the client

within a timeout period will succeed. On receipt

of a successful reply, the client has the option to

cancel the request, which relieves the provider of

its responsibility to guarantee the resources to the

client.

Commit. Performs the client’s request. This is the

only required operation for a service.

Compensate. Performs actions to undo a previously

committed request, provided that the call to com-

pensate is received within a timeout period.

Callback. Allows a provider to notify a client that

has previously received a response from the

provider, in the circumstance that the provider’s

situation has changed, resulting in a revision of

the provider’s previous response.

Using these ﬁve operations, a traditional ACID

transaction can be described as a Prepare/Commit pat-

tern with an inﬁnite timeout for the Prepare stage.

Similarly, semantic atomicity is provided by having

the provider offer a Commit/Compensate pattern, and

support for tentative holds is achieved through an En-

quire/Callback/Commit pattern.

The concept of resilience (Younas et al., 2000)

cannot be described using these operations. How-

ever, replacing concrete services with abstract ser-

vices (Sch

afer et al., 2007) can allow resilience in

a way that is transparent to both clients and service

providers. Clients use the abstract services rather than

the services offered by the concrete providers, and

the abstract service acts as a broker between all the

providers offering alternative services. These abstract

services can thus be used in transactions described by

the operations deﬁned above.

On becoming aware of the transactional pattern

supported by a provider for a particular interaction,

a client utilises the service by following through the

states depicted in Figure 1. The interaction begins in

the Initial state, and a change in state occurs when the

client sends a message to the provider, or the provider

sends a message to the client. Before entering this

state, the client receives a contract from the provider

indicating the level of transaction support that will be

supplied for the requested service (see Section 4.1).

From the Initial state, the client can choose to ac-

cept or reject the contract. If the client rejects the

contract, then the interaction transitions to the Failed

state. Otherwise the interaction moves into the Active

state. From the Active state, either party can cancel

the interaction, moving it to the Failed state. Other

options from the Active state allow the client to re-

quest either enquire, prepare, or commit operations.

In the case that an enquire request is sent, the

provider may reply that the request was successful

(indicating that the provider can currently success-

fully complete the activity), which moves the inter-

action to the EnquirySuccessful state. If, on the other

hand, the provider replies that the enquiry is unsuc-

cessful (indicating that the provider cannot currently

complete the required activity successfully), the inter-

action moves to the EnquiryFailed state. From either

of these states, the client can initiate a new enquiry,

though any enquiry callbacks remove the need as they

transition the client between the EnquiryFailed and

EnquirySuccessful states without requiring a new re-

quest. Similarly to behaviour in the Active state, either

party can cancel the interaction from the Enquiry-

Failed and EnquirySuccessful states, or the client can

request the prepare and commit operations.

When a prepare request is sent, the provider can

either send a cannotComplete reply to indicate that

the prepare has not occurred, or a prepared message

to indicate that the prepare has been performed suc-

cessfully. On receipt of a cannotComplete message,

the client can either acknowledge the failure, moving

to the Failed state, or, if applicable, wait for a call

back from the provider and then send another prepare

request. If the prepare is completed successfully, the

client can choose to either cancel the activity, or re-

quest to commit.

After a request to commit, the provider can either

perform the requested service successfully, or indicate

that it cannot be completed at the current time. If the

commit request was sent from the Prepared state then

the second option should not be possible, as the pre-

pare operation guarantees that a later call to commit

will succeed. On receipt of a committed message, the

interaction moves to the Committed state. With com-

pensation support, the client can choose to either close

the interaction, moving it to the Successful state, or

compensate the activity, moving to the Failed state. If

the provider indicated that it could not complete the

commit operation, the interaction moves to the Failed

state unless the provider sends a callback to the client

to indicate that the commit operation would now suc-

ceed.

Finally, from the Successful state, the client may

choose, without the provider’s knowledge, to take

some action to undo the operation performed by the

provider. In this case, the provider would believe

DynamicTransactionalWorkflowsinService-orientedEnvironments

Failed

Successful

undo (undo)

Active

cancel cannotComplete

Committing

commit

Enquired

enquire

Preparing

prepare

Committed

committed (com)

NotCommitted

cannotComplete

EnquiryFailed

enquiryFailed (enq)

EnquirySuccessful

enquirySuccessful (enq)

NotPrepared

cannotComplete

Prepared

prepared (pre)

CommitCallback

cancel

commit

Compensating

compensate

compensating (cmp)

notCompleted

callback

cancel cannotComplete

commit

enquire

prepare

enquirySuccessful

cancel cannotComplete

commit

enquire

prepare

enquiryFailed

Initial

reject

notCompleted

PrepareCallback

callback

cancel

commit

prepare

cancel

commit (-pre)

Figure 1: State transition diagram for a client’s processing of an activity. Solid lines represent messages sent by the client.

Dashed lines represent messages sent by the service provider. Dotted lines indicate client-side only transitions. Values in

parentheses represent the associated cost to the client.

that the interaction completed successfully, while the

client would see it as a failure. This allows the client

to compensate the action performed by the provider

even when the provider does not support compen-

sation. For example, if the client is requesting an

item from the provider that has already shipped to

the client, the client could immediately dispose of the

item to effectively have it appear as though the oper-

ation failed.

4.1 Provider Contracts

When a provider receives a request from a client, it

must decide on the level of transactional support it

wishes to provide to the client. The provider may

be willing to support more than one possible level of

transaction support, but at this stage will not know

which level would be preferable for any particular

client.

Once the provider has decided on the level of

transaction support it is willing to provide, it must no-

tify the client of the decision. This can be achieved

by having the client ﬁrst request the level of transac-

tional support that the provider is willing to offer for a

given service request. The provider must then inform

the client of any transactional interaction patterns it is

willing to provide for that service request, by send-

ing contract offers describing the level(s) of support

the provider is willing to support. The client must

then agree to one of these contracts before the service

request can be handled in the required transactional

manner. If the client does not agree with the initial

patterns offered by the provider, it may wish to rene-

gotiate with the provider until both sides have found

a level of transactional support they are willing to ac-

cept. Once the client has accepted one of the offers

from the provider, the interaction continues following

the interaction speciﬁed in the agreed-upon contract.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

Table 1: Costs required for a client to guarantee the completion of an interaction. success deﬁnes the minimal cost required

to transition to the Successful state, and fail deﬁnes the maximum cost necessary to transition to the Failed state.

State success fail

Initial com 0

Active com 0

Enquired enq + com enq

EnquiryFailed com 0

EnquirySuccessful com 0

Preparing com max{0, pre}

NotPrepared com 0

PrepareCallback com 0

Prepared −pre + com 0

Committing com max{com + min{undo, cmp}, 0}

NotCommitted com 0

CommitCallback com 0

Committed 0 min{undo, cmp}

Compensating ∞ cmp

Successful 0 undo

Failed ∞ 0

4.2 Combining Contracts

Once the client begins accepting agreements from

various service providers, it must choose how to pro-

ceed. The client can achieve this by prioritising those

activities in its workﬂow that are yet to be completed,

and determining whether the risk of performing the

next stage of the ﬁrst activity in the prioritised list is

acceptable. If the risk is acceptable, then the client

performs the next stage of the ﬁrst activity.

When the client deems the risk of performing the

next stage of the ﬁrst activity to be too great, be-

haviour depends on the activity being performed. If

the client thinks it likely that waiting will reduce the

risk, the client may choose to wait. Otherwise, if there

is an alternate activity that can replace the current ac-

tivity, the client may choose to cancel the current ac-

tivity and replace it with the alternative. If the risky

activity is optional for the success of the workﬂow,

then the client may choose to cancel the activity. If,

however, the activity is necessary and none of the pre-

vious options are available, the client must cancel its

workﬂow.

In order to allow a client to calculate risk, it is

assumed that the client has knowledge of a price for

each action it performs. This could be prescribed by a

provider, for example as part of the contract, by spec-

ifying a particular price for each of the ﬁve supported

basic transaction operations (enquire, prepare, com-

mit, compensate, callback).

To allow the client to make decisions based on

these costs, it is assumed the client has a maximum

budget it is willing to spend to have its workﬂow com-

plete successfully, and a maximum budget it does not

want to exceed should the workﬂow fail. It is possi-

ble that a cost to the client could be multidimensional.

For example, if a client orders a physical item from a

provider, it will have to pay the provider as well as

have storage space for the item. The model presented

here assumes a single-dimensional cost, though this

could be extended to multidimensional by specifying

a cost for each action in each dimension.

A contract identifying the level of transac-

tion support that a provider will offer to a

client for a particular service call, and the cost

for this support, can be deﬁned as a tuple

(enq, ecb, eth, pre, pcb, com, ccb, cmp), where:

enq ∈ R is the cost of an enquiry operation.

ecb ∈ {0, 1} speciﬁes whether the provider may call

back after an unsuccessful enquire operation if the

enquiry would now be successful.

eth ∈ {0, 1} speciﬁes whether the provider may call

back if a tentative hold on an item is revoked.

pre ∈ R is the cost of a successful prepare operation.

pcb ∈ {0, 1} speciﬁes whether the provider may call

back after an unsuccessful prepare request if the

prepare would now be successful.

com ∈ R is the cost of a successful commit operation.

ccb ∈ {0, 1} speciﬁes whether the provider may call

back after an unsuccessful commit request if the

commit would now be successful.

cmp ∈ R is the cost of a successful compensate oper-

ation.

DynamicTransactionalWorkflowsinService-orientedEnvironments

V |W ≡ W|V

V |(W |X) ≡ (V |W )|X

V ; (W ; X) ≡ (V ;W ); X

done|W ≡ W

abort|abort ≡ abort

done;W ≡ W

abort; abort ≡ abort

V, (W, X) ≡ (V, W), X

abort, W ≡ W

V, abort ≡ V

Figure 2: Structural congruences that equate all processes

that never need be distinguished.

To support the client’s undoing of a successfully com-

pleted interaction without the provider’s knowledge,

it is also necessary for the client to specify a cost

undo ∈ R to indicate the cost to compensate a com-

pleted interaction on the client’s side. For each cost,

a value of ∞ indicates that the associated operation is

not supported by the interaction. It is also possible to

use a contract to specify time out behaviour for an in-

teraction. However such details are beyond the scope

of this paper, in which it is assumed that time outs

never occur.

Figure 1 indicates which transitions trigger a cost

to the client. Using this information, a client can de-

termine the minimal cost required for an interaction

to complete in the Successful state, and the maximum

cost required to move the interaction into the Failed

state. Table 1 displays the success and fail costs for

each state.

Client workﬂows typically combine multiple in-

teractions with multiple providers. Using a system

inspired by πt-calculus (Bocchi et al., 2003), we de-

scribe a workﬂow W as:

W , done (success)

| abort (failure)

| W |W (parallel)

| W ;W (sequence)

| W, W (alternative)

| (p)(s, c, u) (client interaction)

done and abort are activities that respectively in-

dicate the successful or unsuccessful completion of a

workﬂow. The parallel operation W |W executes two

workﬂows in parallel, with no guarantee as to which

will complete ﬁrst. In contrast, the sequence operator

W ;W guarantees that the workﬂow on the right will

only succeed if the workﬂow on the left succeeds ﬁrst.

The alternative operator W, W means that the work-

ﬂow succeeds if either the ﬁrst workﬂow succeeds and

the second fails, or, given the ﬁrst workﬂow’s failure,

the second workﬂow succeeds (i.e. only one of the

success(done) = 0

success(abort) = ∞

success(V |W ) = success(V ) + success(W )

success(V ;W ) = success(V ) + success(W )

success(V, W ) = min{success(V ) + fail(W ),

fail(V ) + success(W )}

fail(done) = ∞

fail(abort) = 0

fail(V |W ) = fail(V ) + fail(W )

fail(V ;W ) = fail(V ) + fail(W )

fail(V, W ) = fail(V ) + fail(W )

success((p)(s, c, u)) = success(s)

fail((p)(s, c, u)) = fail(s)

Figure 3: The minimal success and maximal failure cost of

a workﬂow.

two ever succeeds).

The ﬁnal operation is a client interaction,

(p)(s, c, u). p is a unique identiﬁer for a client’s in-

teraction with a provider; s is the current state of the

interaction, which can be any of the states in Figure 1;

c is a contract as deﬁned above; and u is the undo cost

to the client to move the interaction from the Success-

ful state to the Failed state.

Given the above deﬁnition, and workﬂows

V, W, X, the structural congruences in Figure 2 hold.

The ﬁrst seven congruences are directly analogous to

those in πt−calculus (Bocchi et al., 2003). The ﬁnal

three specify that , is associative and that abort is

an identity to the operation.

Using this deﬁnition of workﬂows, it is possible to

calculate the minimal success cost, success, and max-

imal failure cost, fail of a workﬂow as speciﬁed in

Figure 3.

done represents the successful completion of a

workﬂow interaction, and thus has a success cost of

0 and a failure cost of ∞ (as it is not undoable). Sim-

ilarly, abort represents a failure of the workﬂow, so

its failure cost is 0 and its success cost is ∞. Both

the success and failure costs of workﬂows performed

in parallel (V |W ) or in sequence (V ;W) are simply

the sums of associated costs of each component in-

cluded in the workﬂow. Alternatives such as (V, W )

are successful whenever exactly one of the alterna-

tives succeeds, making the minimum success cost the

minimum cost required to have one of the alternatives

fail and the other succeed. The failure cost of alterna-

tives is the sum of the failure cost of each component,

as both must fail for the alternatives to fail. Finally,

the success or failure cost of an interaction with a par-

ticular provider is the success or failure cost of the

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

interaction as deﬁned in Table 1.

By combining the client’s success and fail budgets

with the costs calculated by the above success and

fail functions, a client is able to determine whether its

workﬂow can succeed. Each workﬂow begins with

the client having not accepted any of the provider-

offered contracts and, since the fail cost of an inter-

action from the Initial state is always 0, it is guaran-

teed that the client can initially cancel the workﬂow

without exceeding its failure budget. The client then

chooses the next action to perform by ensuring that

the action will not cause the cost of the workﬂow to

exceed the client’s success or failure budgets.

For a single client interaction, the set of possi-

ble next steps is speciﬁed by the transitions in Fig-

ure 1 (with some transitions being removed if the con-

tract does not support them. For example, if pcb = 0

then the transition from NotPrepared to PrepareCall-

back is removed). The next step progresses the work-

ﬂow by changing the state of the interaction, while

keeping the contract and undo cost constant. If the

next step requires a provider-generated message, the

client’s action is to wait for that message to arrive.

When a number of client interactions are combined

in a workﬂow, the possible next steps are the union

of the possible next steps for each interaction in the

workﬂow.

The client begins by considering all of the pos-

sible actions that can be performed from its current

state. Each of these actions have a possible cost (as

displayed in Figure 1) and move one of the client in-

teractions in the workﬂow to a new state. If the cost

of a potential action, plus the success or fail cost of

the resultant workﬂow, exceeds the success or failure

budget (respectively), that action is removed from the

set of possible actions. In this way, the client creates

a set of possible actions it can perform, given the cur-

rent state of its workﬂow, which will not exceed the

client’s budgets.

The aim of the client is ﬁrstly to complete the

workﬂow successfully, by reducing it to done. If that

becomes impossible then the aim shifts to completing

the transaction by reducing it to abort. The client thus

chooses an action, from its set of possible actions, to

bring it closer to one of these outcomes. Once an ac-

tion has been performed, the client uses the structural

congruences from Figure 2 to simplify the workﬂow

as much as possible. The client also uses the follow-

ing reduction rules:

• Any client interaction that is in the Failed state is

replaced with abort.

• Any workﬂow that has no alternatives, and all

client interactions in the Successful state, is re-

placed with done.

The ﬁrst rule indicates that a failed interaction is

equivalent to abort, since they are both failures. The

second rule ensures that any sequence or set of work-

ﬂows running in parallel succeeds if each client inter-

action in the workﬂow succeeds. Further, since the

structural congruence rules only remove an alterna-

tive if it is abort, the restriction on alternatives ensures

that, for each set of alternatives, exactly one alterna-

tive succeeds.

By following this strategy, the client is assured

that it will only ever perform an action that will not

exceed its budgets. However, the client can still opti-

mise the strategy for its own purposes. Once the client

has determined the set of possible actions for its cur-

rent state, the client can choose which action to per-

form based on other criteria. For example, the client

may choose the next action that minimises either the

success or fail cost of the workﬂow. Regardless of

how the action is chosen, the client performs the ac-

tion, which moves the workﬂow to a new state. The

client then repeats the process for the new workﬂow

state, until the workﬂow is complete.

Note that, while this work borrows from the al-

gebraic laws of πt−calculus (Bocchi et al., 2003),

this system augments these laws with client reason-

ing about the individual interactions included in its

combined workﬂow. Thus the system presented is not

a process calculus, but instead a tool to allow client

reasoning. In particular, a client only requires a model

of its own workﬂow and a knowledge of the required

transactional behaviour of the providers it is using to

allow its reasoning, whereas most process calculi re-

quire a complete description of not only all service

providers that may be used by the client, but also of

any other clients that may utilise those provider’s ser-

vices while the ﬁrst client’s workﬂow is still process-

ing (Laneve and Zavattaro, 2005). By thus reducing

the complexity of the model, it is possible for a client

to guarantee its correct behaviour, rather than having

the system grow to such a size that such analysis be-

come intractable (as in (Fantechi et al., 2009)).

5 SIMULATION

Web Services transactions have been shown to be very

different from traditional transactions. Multiple par-

ties work together to achieve a client’s aims, but still

wish to remain autonomous. Further, the different ser-

vice providers may have different levels of transac-

tional support, making veriﬁcation and testing of dif-

ferent transaction schemes very complex. While the-

oretical analysis is essential to ensure that transaction

schemes work correctly, these models (e.g. (Casado

DynamicTransactionalWorkflowsinService-orientedEnvironments

et al., 2011; Fantechi et al., 2009)) do not easily allow

comparison between different transaction techniques.

In particular, these models make it difﬁcult to deter-

mine which transaction schemes are best suited for

certain conditions, applications, or environments.

Instead, simulation can be used to provide an indi-

cation of practical results. In simulation, some or all

of a system is abstracted so that only the features im-

portant to the current investigation are tested. When

simulating Web Services transactions, details such as

the networking topology, the timing of events, and

the actual services being used can be abstracted. This

can allow intricate comparison of various transaction

strategies, by allowing the parameters of interest to be

studied while ensuring that all other factors are kept

constant.

Most available Web Services simulation environ-

ments replace a Web Service with a simple, usually

local, program that sends and responds to messages

in a way that is appropriate to the service being sim-

ulated (Paul et al., 2011). However, when examining

Web Services transactions, further abstraction can oc-

cur (Paul et al., 2011). Messages are not required to

be sent in the exact same format as with real services;

it is only the transaction interaction patterns that need

to be simulated. A simulator, based on the model

introduced in Section 4 that models transaction ﬂow

rather than message ﬂow, is described in (Paul et al.,

2011).

The simulator accepts a description of the scenario

to process, which includes details of the providers and

clients to simulate. Provider information describes

the number of resources available from each provider,

cost information for accessing those resources, and

the availability of abstract providers that provide re-

silience for the simulation. Client deﬁnitions contain

a description of a workﬂow, which consists of a se-

quence of activities to be performed, and speciﬁes

whether successful completion of each activity is re-

quired, or if the workﬂow is successful when at least

one of the included activities succeeds. An activity

can either be a workﬂow or a service call. Finally,

the scenario description contains timing information

to specify the length of time that messages take to be

sent between the different participants in the system

being modelled.

The simulator also accepts various parameters to

specify the level of transaction support offered by

the various service providers, and the risk-taking be-

haviour of the clients. These parameters can be

changed independently of the scenario description,

and any changes to results can be directly attributed to

these changed values. The level of transaction support

offered by providers is speciﬁed based on the ﬁve op-

erations described in Section 4 and, when combined

with abstract services, this allows providers to utilise

all of the reductions to the standard ACID properties.

Client risk-taking behaviour is speciﬁed using bud-

gets, as described in Section 4.2.

The simulator models the passing of messages be-

tween the various participants in the simulated sce-

nario. Each provider tracks the state of its resources

to ensure the provider can support any transactional

contract it offers to a client. Clients similarly monitor

their interactions with providers to track the progress

through their workﬂows, and to determine the next

action the client should take. By tracking all mes-

sages sent through the simulator it is possible to ex-

tract details such as whether a particular client’s work-

ﬂow succeeded or failed, and the cost for that out-

come, or the number of a provider’s resources that

were utilised, and the amount it was paid.

Thus, by deﬁning appropriate scenarios, it is pos-

sible to use the simulator to measure the way different

transactional support from providers, or different risk-

taking behaviour of clients, affects the outcome of the

simulation. The following section will describe a sce-

nario, based on the preceding motivating example, to

demonstrate the effects of using a dynamic transac-

tion scheme rather than a scheme in which the trans-

action support offered by each provider remains ﬁxed.

6 RESULTS

The Web Services transactions simulator described in

Section 5 was used to validate the dynamic transac-

tion model introduced in Section 4. The validation

experiment was based on the motivating example de-

scribed in Section 3.

According to the scenario, the display system of-

fered either 100 or 1000 time units for clients to book.

A total of 500 clients, each requiring between 1 and

5 time units, were included in the simulation. Each

client had a success budget that allowed for successful

completion of both the display booking and the other

required services. 100 of the clients were given a fail

budget of 0, meaning that they would only perform an

action that required payment if success was guaran-

teed. The remaining clients had a budget that allowed

either the booking of the display to fail while the other

actions succeeded, or for the other actions to succeed

and the booking of the display to fail. The other ser-

vices were modelled as a service that was successful

80% of the time, with no special transaction support.

Three different levels of transactional support of-

fered by the display booking service were simulated.

The ﬁrst level provided semantic atomicity, allowing

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

Table 2: Results of simulation based on motivating example.

Transactionality Offered Booked Succeeded Failed Penalised Reserved Time

Semantic Atomicity 100 100 42 458 0 119

Tentative Hold 100 100 48 420 32 0

Variable 100 100 44 444 12 76

Semantic Atomicity 1000 963 393 107 0 1350

Tentative Hold 1000 805 330 130 40 0

Variable 1000 914 367 112 21 588

clients to book a time unit and then later cancel that

booking without charge. The second level offered ten-

tative holds. When granted a tentative hold, 50% of

the clients converted that tentative hold into a booking

immediately, and then attempted the other services.

The remaining 50% retained the hold and attempted

the other services, only conﬁrming the booking if the

other services completed successfully. The ﬁnal level

of transaction support was a variable scheme which

offered semantic atomicity until 50% of the time units

had been booked, and then offered tentative holds in-

stead. This ﬁnal level was only possible with dynamic

transaction support.

Assuming the data service is data, the rendering

service render, and the visualisation service display,

the system can be modelled as follows. Each client

has a success budget of 4, a fail budget of 0 or 2 (as

speciﬁed above), and the following workﬂow:

(data)(Initial, c

, ∞);

((render)(Initial, c

, ∞)|(display)(Initial, c

, ∞))

where c

, the contract for the data service,

is (∞, 0, 0, ∞, 0, 1, 0, ∞), c

, the contract for the

render service is similarly (∞, 0, 0, ∞, 0, 1, 0, ∞),

and c

, the contract for the display service, is

(∞, 0, 0, 0, 0, 2, 0, ∞) if semantic atomicity is offered,

or (0, 0, 0, ∞, 0, 2, 0, ∞) if tentative hold is offered.

The results for these simulations can be seen in Ta-

ble 2. The ﬁrst column indicates the level of transac-

tion support that was offered by the display-booking

service. The “Offered” and “Booked” columns

give, respectively, the number of time units that the

provider offered to clients, and the number of time

units that were actually booked. The “Succeeded”,

“Failed”, and “Penalised” columns indicate, respec-

tively, the number of client workﬂows that completed

successfully, the number of client workﬂows that

failed with neither the display booking nor the other

services requiring payment, and the number of client

workﬂows that failed with either the display booking

service or the other services completing successfully

(and thus requiring payment). The “Reserved Time”

column indicates the total length of time during which

the provider held resources for a client that later can-

celled its request (i.e. the time resources were with-

held from other clients, ultimately unnecessarily).

When only 100 time units were offered, each time

unit was booked by a client. This is unsurprising, as

the large number of clients compared to the available

resources means that each time unit was highly con-

tended. In contrast, when 1000 time units were of-

fered, more time units were booked when semantic

atomicity was offered. This is because the clients with

a 0 fail budget would only attempt their workﬂow

if such a level of transactional support was offered.

However, as can be seen from the “Reserved Time”

column, semantic atomicity places a higher burden on

the service provider, as the provider must ensure that

a completed action can be undone until the client de-

termines whether or not it will compensate the book-

ing, whereas tentative holds have no such restrictions.

Using the variable scheme, the provider obtained re-

sults that were a compromise between only offering

tentative holds and only offering semantic atomicity.

From the point of view of clients, the beneﬁts of

better transactional support can be seen in the “Pe-

nalised” column of Table 2. Tentative holds give no

future guarantee about the state of resources, mean-

ing that a client may commit one part of its work-

ﬂow, but have the tentative hold expire before com-

pleting the booking. In contrast, when semantic atom-

icity is offered, the client can perform the action be-

fore attempting the rest of its workﬂow. If any part

of the workﬂow later fails, the performed action can

be compensated to allow completion without penalty.

Thus, no clients failed with a penalty when the display

provider offered semantic atomicity, and the use of the

variable scheme greatly reduced the number of clients

that were forced to pay for an incomplete workﬂow

compared to when only tentative holds were used.

7 CONCLUSIONS

Clients often require services from multiple providers

to be combined into a single workﬂow to achieve the

clients’ aims. Problems can occur, however, when

part of a workﬂow fails while other parts succeed. A

possible solution to these problems is the use of trans-

DynamicTransactionalWorkflowsinService-orientedEnvironments

actions.

Service-oriented environments have different

transactional requirements to traditional transaction

systems. Reductions to the ACID properties, such as

tentative holds or semantic atomicity, are often used

to retain as much autonomy as possible for service

providers while still offering an acceptable level of

service for clients.

The reductions to be used for a particular service

call are typically speciﬁed along with the deﬁnition

of the service. In some cases, however, it is desirable

to allow the provider to dynamically alter the level of

transaction support offered for a particular service as

the provider’s environment changes. This paper de-

scribes a technique whereby providers offer transac-

tional contracts to clients on a per-service-call basis.

According to this technique, the provider and client

ﬁrst agree upon a level of transaction support before

the service is actually performed.

Client workﬂows can be arbitrarily complex, and

consist of many such interactions. A formal model,

inspired by πt-calculus, was presented to allow auto-

mated reasoning about a client workﬂow. This model

ensures that a client workﬂow has an acceptable out-

come. A Web Services transactions simulator based

on the model has been developed to allow investiga-

tion of the effect of different transactional strategies.

The simulator was used to examine a scenario in

which a provider alters the level of transactional sup-

port it offers for its service. By varying the offered

level of transaction support, the provider was able to

better balance the strength of the transactional guar-

antees it supported, and the number of clients that

completed successfully. Thus there can be beneﬁts for

both clients and providers when dynamic transaction

levels are used.

The model presented in this paper ignored the pos-

sibility of time outs for messages sent between partic-

ipants in the system. Further, only simple negotiation

strategies, used by both providers and clients to de-

termine which levels of transaction support should be

offered or accepted, have been tested. Additionally,

quality of service and other similar issues are not con-

sidered in the described transactional contracts. These

limitations offer future directions for research.

REFERENCES

Bocchi, L., Laneve, C., and Zavattaro, G. (2003). A cal-

culus for long-running transactions. Lecture Notes in

Computer Science, pages 124–138.

Casado, R., Tuya, J., and Younas, M. (2011). A frame-

work to test advanced Web Services transactions. In

IEEE 4th International Conference on Software Test-

ing, Veriﬁcation and Validation (ICST’11), Berlin,

Germany.

Chakraborty, D. and Joshi, A. (2001). Dynamic service

composition: State-of-the-art and research directions.

Technical report, University of Maryland.

Fantechi, A., Gnesi, S., Lapadula, A., Mazzanti, F.,

Pugliese, R., and Tiezzi, F. (2009). A logical veri-

ﬁcation methodology for service-oriented computing.

Technical report, Universita’ degli Studi di Firenze.

Fauvet, M.-C., Duarte, H., Duman, M., and Benatal-

lah, B. (2005). Handling transactional properties in

Web Service composition. In The 6th International

Conference on Web Information Systems Engineer-

ing (WISE’05), pages 273–289, New York City, New

York, USA.

Garcia-Molina, H. (1983). Using semantic knowledge for

transaction processing in a distributed database. ACM

Transactions Database Systems, 8(2):186–213.

Laneve, C. and Zavattaro, G. (2005). Foundations of web

transactions. In The 8th International Conference

on Foundations of Software Science and Computation

Structures (FoSSaCS’05), pages 282–298, Edinburgh,

UK. Springer.

Mikalsen, T., Tai, S., and Rouvellou, I. (2002). Trans-

actional Attitudes: Reliable Composition of Au-

tonomous Web Services. In Workshop on Dependable

Middleware-based Systems (WDMS’02) at the De-

pendable Systems and Network Conference (DSN’02),

Bethesda, MD, USA.

Milanovic, N. (2006). Contract-based Web Service Compo-

sition. PhD thesis, Humboldt-Universit

at zu Berlin.

Milanovic, N., Stantchev, V., Richling, J., and Malek, M.

(2003). Towards adaptive and composable services.

Proceedings of the IPSI2003.

Paul, D., Henskens, F. A., and Hannaford, M. (2010). Per-

request contracts for Web Services transactions. In 6th

International Conference on Web Information Systems

and Technologies (WEBIST-2010), Valencia, Spain.

INSTICC.

Paul, D., Henskens, F. A., and Hannaford, M. (2011). Sim-

ulating Web Services Transactions. In Special Session

on Web Services Principles and Applications (WSPA

2011) at the 7th International Conference on Web In-

formation Systems and Technologies (WEBIST-2011),

Noordwijkerhout, The Netherlands.

Sch

afer, M., Dolog, P., and Nejdl, W. (2007). Engineer-

ing compensations in Web Service environment. In

The International Conference on Web Engineering

(ICWE’07), Como, Italy. Springer Berlin/Heidelberg.

Younas, M., Eaglestone, B., and Holton, R. (2000). A

formal treatment of the SACReD protocol for multi-

database Web transactions. In The 11th International

Conference on Database and Expert Systems Appli-

cations (DEXA’00), pages 899–908, London, UK.

Springer-Verlag.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies