Dynamic Transactional Workflows 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 fixed 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 workflow. We present a mechanism
that allows the dynamic specification of transaction support for a given service call, and a cost-based model
that allows clients to automatically reason about workflows 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 benefits 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 satisfies a client’s
needs. Thus clients have a need to combine multi-
ple services, typically from different providers, into a
single workflow. The client views all of the providers
participating in its workflow as participants working
on achieving the client’s task. Each individual ser-
vice call is part of an overall workflow, 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 workflow, 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 workflow to succeed
while other parts fail. Since the client views the entire
workflow as a single task, such a partially completed
workflow 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
flight to take them there.
Thus there is a need for clients to combine multi-
ple service calls into a single workflow in which any
errors are handled gracefully, with the definition 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-defined 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 efficiency 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 workflow may need to combine
service calls with different transactional guarantees to
achieve an acceptable result.
Further, different clients may have different views
26
Paul D., Henskens F. and Hannaford M..
Dynamic Transactional Workflows 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
Copyright
c
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-
flow 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
workflows. 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 firstly, in Section 2 describing the needs
of a service composition platform, and how transac-
tions fit 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 five 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 find 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 define 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 efficiently 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
27
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 workflow (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-defined transac-
tional pattern. Once providers and clients have spec-
ified 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 definition. 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 workflows 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 notified
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 notification 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 workflow.
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
28
of five 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 infinite 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 defined 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
29
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
close
Compensating
compensate
compensating (cmp)
notCompleted
callback
cancel cannotComplete
commit
enquire
prepare
enquirySuccessful
cancel cannotComplete
commit
enquire
prepare
enquiryFailed
Initial
reject
accept
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 first 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 specified in the agreed-upon contract.
WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies
30
Table 1: Costs required for a client to guarantee the completion of an interaction. success defines the minimal cost required
to transition to the Successful state, and fail defines 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 workflow that are yet to be completed,
and determining whether the risk of performing the
next stage of the first activity in the prioritised list is
acceptable. If the risk is acceptable, then the client
performs the next stage of the first activity.
When the client deems the risk of performing the
next stage of the first 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 workflow,
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
workflow.
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 five 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 workflow com-
plete successfully, and a maximum budget it does not
want to exceed should the workflow 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 defined as a tuple
(enq, ecb, eth, pre, pcb, com, ccb, cmp), where:
enq R is the cost of an enquiry operation.
ecb {0, 1} specifies whether the provider may call
back after an unsuccessful enquire operation if the
enquiry would now be successful.
eth {0, 1} specifies 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} specifies 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} specifies 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
31
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 workflows typically combine multiple in-
teractions with multiple providers. Using a system
inspired by πt-calculus (Bocchi et al., 2003), we de-
scribe a workflow 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
workflow. The parallel operation W |W executes two
workflows in parallel, with no guarantee as to which
will complete first. In contrast, the sequence operator
W ;W guarantees that the workflow on the right will
only succeed if the workflow on the left succeeds first.
The alternative operator W, W means that the work-
flow succeeds if either the first workflow succeeds and
the second fails, or, given the first workflow’s failure,
the second workflow 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 workflow.
two ever succeeds).
The final operation is a client interaction,
(p)(s, c, u). p is a unique identifier 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 defined 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 definition, and workflows
V, W, X, the structural congruences in Figure 2 hold.
The first seven congruences are directly analogous to
those in πtcalculus (Bocchi et al., 2003). The final
three specify that , is associative and that abort is
an identity to the operation.
Using this definition of workflows, it is possible to
calculate the minimal success cost, success, and max-
imal failure cost, fail of a workflow as specified in
Figure 3.
done represents the successful completion of a
workflow 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 workflow, so
its failure cost is 0 and its success cost is . Both
the success and failure costs of workflows performed
in parallel (V |W ) or in sequence (V ;W) are simply
the sums of associated costs of each component in-
cluded in the workflow. 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
32
interaction as defined 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
workflow can succeed. Each workflow 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 workflow
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 workflow to
exceed the client’s success or failure budgets.
For a single client interaction, the set of possi-
ble next steps is specified 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-
flow 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 workflow, the possible next steps are the union
of the possible next steps for each interaction in the
workflow.
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 workflow to a new state. If the cost
of a potential action, plus the success or fail cost of
the resultant workflow, 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 workflow, which will not exceed the
client’s budgets.
The aim of the client is firstly to complete the
workflow 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 workflow
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 workflow that has no alternatives, and all
client interactions in the Successful state, is re-
placed with done.
The first 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-
flows running in parallel succeeds if each client inter-
action in the workflow 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 workflow. Regardless of
how the action is chosen, the client performs the ac-
tion, which moves the workflow to a new state. The
client then repeats the process for the new workflow
state, until the workflow is complete.
Note that, while this work borrows from the al-
gebraic laws of πtcalculus (Bocchi et al., 2003),
this system augments these laws with client reason-
ing about the individual interactions included in its
combined workflow. 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 workflow 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 first client’s workflow 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 verification 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
33
et al., 2011; Fantechi et al., 2009)) do not easily allow
comparison between different transaction techniques.
In particular, these models make it difficult 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 flow
rather than message flow, 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 definitions contain
a description of a workflow, which consists of a se-
quence of activities to be performed, and specifies
whether successful completion of each activity is re-
quired, or if the workflow is successful when at least
one of the included activities succeeds. An activity
can either be a workflow 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 specified based on the five 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 specified 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 workflows, 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-
flow 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 defining 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 fixed.
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 first level provided semantic atomicity, allowing
WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies
34
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 confirming the booking if the
other services completed successfully. The final 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 final 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
specified above), and the following workflow:
(data)(Initial, c
1
, );
((render)(Initial, c
2
, )|(display)(Initial, c
3
, ))
where c
1
, the contract for the data service,
is (, 0, 0, , 0, 1, 0, ), c
2
, the contract for the
render service is similarly (, 0, 0, , 0, 1, 0, ),
and c
3
, 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 first 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 workflows that completed
successfully, the number of client workflows that
failed with neither the display booking nor the other
services requiring payment, and the number of client
workflows 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 workflow
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 benefits 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-
flow, 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 workflow. If any part
of the workflow 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 workflow
compared to when only tentative holds were used.
7 CONCLUSIONS
Clients often require services from multiple providers
to be combined into a single workflow to achieve the
clients’ aims. Problems can occur, however, when
part of a workflow fails while other parts succeed. A
possible solution to these problems is the use of trans-
DynamicTransactionalWorkflowsinService-orientedEnvironments
35
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 specified along with the definition
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
first agree upon a level of transaction support before
the service is actually performed.
Client workflows 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 workflow. This model
ensures that a client workflow 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 benefits 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, Verification 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-
fication 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
36