making web services dependable · 2007. 2. 24. · distributed systems. the participants in a...

Making Web Services Dependable

L. E. Moser

Electrical and Computer Engineering

University of California, Santa Barbara

Santa Barbara, CA 93106

[email protected]

P. M. Melliar-Smith


University of California, Santa Barbara

Santa Barbara, CA 93106

[email protected]

Wenbing Zhao


Cleveland State University

Cleveland, OH 44115

[email protected]

Abstract

Web Services offer great promise for integrating and au-tomating software applications within and between enter-prises over the Internet. However, ensuring that Web Ser-vices are dependable, and can satisfy their clients’ requestswhen the clients need them is a real challenge because, typi-cally, a business activity involves multiple Web Services anda Web Service involves multiple components, each of whichmust be dependable. In this paper, we describe fault toler-ance techniques, including replication, checkpointing, andmessage logging, in addition to reliable messaging and trans-action management for which Web Services specificationsexist. We discuss how those techniques can be applied tothe components of the Web Services involved in the businessactivities to render them dependable.

1 Introduction

Web Services [5] enable the software of one enterpriseto interact with that of another enterprise over the Internet,even if those enterprises use different hardware, different op-erating systems, and different programming languages, thusallowing disparate computing systems and applications tobe coupled together. Web Services enable direct computer-to-computer interaction by invoking operations of the en-terprises automatically that, otherwise, would be invokedmanually by a human through a browser and, thus, theystreamline business activities. Web Services can run not onlyon mainframe computers and server computers but also onclient desktop computers and mobile handsets.

The potential widespread use and benefits of Web Ser-vices are very compelling, because they facilitate:

� Automation of business processes distributed acrossmultiple enterprises

� Collaboration among multiple enterprises by couplingtogether the business processes running on their vari-ous computers.

Web Services create opportunities for efficient ecosystemsof consumers and suppliers, collaborating and competing forproducts and services over the Internet.

Web Services standards define the syntax of Web Ser-vices documents, the format of messages, and the meansto describe and find Web Services. They do not define im-plementation mechanisms or application program interfaces,which remain proprietary to individual vendors. Differentvendors can implement Web Services infrastructures in dif-ferent ways. Thus, Web Services standards provide interop-erability between Web Services that have been implementedon different infrastructures, but they do not provide portabil-ity of application programs from one vendor’s infrastructureto another. The basic Web Services standards comprise:

� The eXtensible Markup Language (XML), which de-fines the syntax of Web Services documents, so thatthe information in those documents is self-describing

� The Simple Object Access Protocol (SOAP) for XMLmessaging and mapping of data types, so that applica-tions can communicate with one another

� The Web Services Description Language (WSDL) fordescribing a Web Service, its name, the operations thatcan be called on it, the parameters of those operations,and the location to which to send requests

� The Universal Description Discovery and Integration(UDDI) standard, which is used by the service registrywhere service providers publish and advertise their ser-vices, and clients query and search for services to dis-cover what the services offer and how to access them.

Web Services introduce new problems into the operationof enterprise computing systems.

� A problem in one participant of a multi-enterprise busi-ness activity can affect another enterprise, and can dam-age relationships between that enterprise and its cus-tomers, suppliers and partners.

� Business activities that span multiple enterprises presentchallenges for reliability, availability, data consistency,concurrency, scalability and security.

These and other problems become more challenging asbusiness activities become more automated, as one Web Ser-

1

Company C(supplier)

Web Service

Web services middleware

Company D(credit card company)

Web Service


Company E(shipper)

Web Service


Company A(customer)

Company B(distributor)

operating systemand other tiers

Web Service Client


Web Service


2. Checkavailability

1. Requesta quote

3. Respondwith a quote

4.Orderthe product

5. Makepayment

6. Provideshippinginformation

5. Makepayment

6. Arrangeshipping





Figure 1. Use of Web Services in business-to-business activities that span multiple enterprises.

vice triggers other Web Services, and as business activitiesinvolve more enterprises and more steps. In this paper, weinvestigate some of these problems, and possible strategiesfor solving them, that result from automating business ac-tivities, as Web Services that span multiple enterprises. Wefocus, in particular, on reliability, high availability, and dataconsistency.

��

High availability must be provided for all of the WebServices of a business activity, and all of the componentsof those Web Services. If one of the components of a WebService is not available, all of the others will be affected. Theavailability of a business activity can be much less than theavailability of any of the components of the Web Servicesthat comprise that business activity, as the following simpleexample shows.

Let � be the number of tiers in a Web Services architec-ture within an enterprise and let � be the number of WebServices of different enterprises that are involved in a busi-ness activity. Assume that � is the same for all of the enter-prises and that � is the same for all of the business activities.Assume further that the processes within the different tiersand within the different enterprises are independent.

Let � be the probability that the processes in any one ofthe tiers within an enterprise fails. Then �� is the proba-bility that they do not fail. If all of the processes within thosetiers are operational at the start of the business activity, then

� � ��

is the probability that no fault occurs. For example, if � ��, � � � and � � �, then the probability that no faultoccurs is � � �� . The values of � for different valuesof �� are shown in Figure 2.

For � independent business activities (e.g., � business ac-tivities per day), the probability that no fault occurs in anyof them is

� � ��

With the same values of � and � as above, i.e., � � �and � � �, and with � � � � ��, the probability thatno fault occurs is � � ��. The values of � fordifferent values of � are shown in Figure 2.

� � �, � � �

1-p q

0.9 0.2820.99 0.8860.999 0.98810.9999 0.99880.99999 0.99988

��

l r

10 0.99880100 0.988071000 0.8869210000 0.30119100000 0.00001

Figure 2. The availability � of a single busi-ness activity based on the availability �� ofa single component, assuming � � � enter-prises and � � � tiers, and the availability � ofa number � of business activities.

0 1 10 102 103 104 105 106 107 108 109

Number of Business Activities

1.0

0.8

0.6

0.4

0.2

0.0

Pro

ba

bil

ity

tha

td

ata

ba

se

be

co

me

sp

ote

nti

all

yin

co

ns

iste

nt

10-3 10-4 10-5

10-6

Figure 3. The probability that a database isleft in a potentially inconsistent state after �

business activities, when using compensat-ing transactions.

Many business systems must process 100,000 businessactivities per day and, as Figure 2 shows, the probabilityof complete success can be astonishingly low. Because ofthe nature of Web Services and business activities, all of thecomponents of all of the Web Services involved in a busi-ness activity must be highly available in order to achieve ahigh probability that all of the business activities will com-plete successfuly. Even with careful programming and test-ing, it is unlikely that the probability of a fault in a step of abusiness activity will be reduced below 0.00001. Therefore,the required levels of availability cannot be achieved realis-tically without fault recovery and retry. Consequently, faultrecovery and retry must be regarded as essential for reliableoperation of business activities using Web Services.

��

Maintaining the consistency of business data is essen-tial to enterprise computing. Data consistency is crucial forWeb Services, where a business activity can span multipleenterprises and where detecting and correcting inconsisten-cies can be difficult, time consuming, and expensive.

The use of transactions to maintain data consistency with-in an enterprise is one of the great successes of enterprisecomputing, effective, efficient, and easy to use. Unfortu-nately, transactions have not been as successful in wide-areadistributed systems. The participants in a distributed trans-action incur a risk that their data will be locked, and willbe inaccessible, for an arbitrary period of time if the trans-action coordinator fails. In theory, this risk can be miti-gated by a three-phase commit protocol or by replicatingthe transaction coordinator [15, 27]. In practice, few trans-action processing systems use three-phase commit becauseof the high overheads in the fault-free case, and replicationpresents challenging problems as discussed below. More-over, transaction commit scales poorly as the number of par-ticipants in the transaction increases.

Currently, business activities are typically implementedusing multiple local transactions, with compensating trans-

actions to abort business activities that cannot be completed.Unfortunately, compensating transactions are difficult to de-sign and program, have a high error rate, and incur a highrisk of data inconsistencies.

Figure 3 shows the probability of potential inconsistencyfor a business activity, where compensating transactions areassumed to incur the same fault rate as regular transactionsthough, realistically, their fault rate is probably higher. Whilethe risk of data being locked for a substantial period of time(because the transaction coordinator failed) is unacceptable,the risk of data inconistency resulting from the use of com-pensating transactions is even more unacceptable. Conse-quently, mechanisms that prevent both locking of data byfailed transactions, and potential inconsistency of data re-sulting from incorrect compensation, are essential for reli-able operation of business activities.

2 WS Dependability Specifications

The Web Services (WS) community has published sev-eral specifications related to reliable messaging and trans-action management. The aim of those specifications is toprovide assurance not only that messages are delivered tothe destination applications but also that they are correctlyprocessed by the destination applications.

��

The Web Services Reliable Messaging specifications in-clude WS-ReliableMessaging [4] and WS-Reliability [23].Both of these specifications define an application-level reli-able messaging protocol that operates over SOAP. If a SOAPmessage is not successfully delivered (e.g., because it has anincomplete address), the sender application gets a responsecontaining a SOAP fault element that gives status or errorinformation.

SOAP typically operates over HTTP, which in turn oper-ates over TCP, which operates over IP, as shown in Figure 4.

RMP

SOAP

HTTP

TCP

IP

RMP

SOAP

HTTP

TCP

IP

Web ServiceApplication

ClientApplication

Figure 4. Reliable messaging protocol stack.

Even though TCP delivers messages reliably, and in order, tothe Transport Layer, there is no guarantee that SOAP mes-sages sent over HTTP are reliably delivered all the way upthe protocol stack to the destination application. Moreover,the reliable message delivery of TCP is not coordinated withfault handling and recovery for Web Services.

Both WS-Reliability and WS-ReliableMessaging providereliable messaging for SOAP using acknowledgments andretransmissions with different quality of service levels, in-cluding at least once, at most once, exactly once, and sourceordered delivery.

Pallickara, Fox and Pallickara [21] provide an analysisof the WS-Reliability and WS-ReliableMessaging specifica-tions. They identify the similarities and differences of thetwo specifications, and recommend extensions to the proto-cols to ensure ordered delivery across sets of messages andacross multiple destinations. They also discuss how the twospecifications might be used together.

Neither the WS-Reliability specification nor the WS-Reli-able Messaging specification addresses the topics of mes-sage persistence and recovery from faults. However, thesetopics are essential for reliable operation of business activ-ities composed of one or more Web Services, and they aretightly coupled to the reliable handling of messages.

If a Web Service fails after a message has been deliveredto it and after it has acknowledged receipt of the messagebut before it has fully processed the message (e.g., becauseit has invoked a nested request), the following actions arerequired.

� The recovering Web Service must be restored to a check-pointed state it had at some moment preceding thefault.

� The TCP connections must be restored.� Messages received subsequent to checkpointing the

state must be replayed from a log on distributed orpersistent storage.

� Messages, generated by the recovering Web Service,that have already been delivered to other Web Ser-vices, must be detected and suppressed.

� ��

The Web Services specifications [6, 7, 8] for both short-running transactions and long-running business activities thatspan multiple enterprises aim to provide data consistencyand protection against faults.

The Web Services Transaction (WS-Transaction) speci-fication [7] includes protocols for atomic distributed trans-action commitment, based on the Two-Phase Commit (2PC)protocol. Transaction processing based on the 2PC proto-col, as defined by the WS-Transaction specification, pro-vides data consistency for Web Services applications. How-ever, if the transaction coordinator fails and all of the par-ticipants in a transaction have voted to commit but have notreceived a commit from the coordinator, the 2PC protocol

blocks and requires the participants to wait for the coordina-tor to recover, which can take a relatively long time.

The Web Services Business Agreement (WS-BusinessAgreement) protocols [8] support long-running transactionsthat span multiple enterprises, are not two-phase, and allowthe business logic to determine whether the business activityshould roll forward or roll backward.

The Web Services Coordination (WS-Coordination) spec-ification [6] describes a framework for plugging in proto-cols that coordinate the actions of distributed applications,including those that require strict consistency and those thatrequire agreement of only a proper subset of the participants.A Web Service creates a context that is used to propagate anactivity to other Web Services and to register for a particu-lar coordination protocol. Participants make heuristic deci-sions regarding the outcome of transactions. However, con-tinued processing without waiting for coordinator recoverycan compromise the consistency of the data.

3 Fault Tolerance Technology

Fault tolerance technology can be used to increase thelevel of reliability, availability and data consistency of WebServices. This technology includes reliable messaging, repli-cation, checkpointing and restoration, message logging andreplay, and transactions, as discussed below.

��

WS-Reliability and WS-ReliableMessaging can be read-ily extended to make the re-establishment of the connectionsof a Web Service transparent to remote clients and servers sothat they do not need to reissue requests or replys. We referto this capability as transparent SOAP connection failover.

Transparent SOAP connection failover involves the re-liable message header and body for the group or sequenceof messages and, for WS-Reliability, the state that was ne-gotiated for the agreement, before transmitting the messagesin that set. The messages can be logged on disk for localrestart, or in the volatile memory of a backup computer forfailover to the backup computer.

Aghdaie and Tamir [1] have investigated failover of Webserver connections and replay of messages for Web serversup to the HTTP layer of the protocol stack, by modifyingthe Linux kernel and the Apache Web server. That workis similar to our transparent TCP connection failover [16],which is intended for general kinds of applications, includ-ing Web Services. Implementing failover support in the op-erating system kernel improves efficiency, but is not portableacross different operating systems.

��

Replication is used in fault-tolerant systems to protectan application against faults, so that if one replica becomes

faulty, another replica is available to provide the service tothe clients. The most commonly used replication strategiesare passive, active, and semi-active replication, summarizedbelow.

� In passive replication, there is a single primary replicathat executes operations invoked on the Web Service,and one or more backup replicas that do not executethose operations. The replication infrastructure trans-fers a checkpoint of the primary to the backups peri-odically or at the end of each remote invocation.

� In active replication, all of the replicas execute theoperations invoked on the Web Service independentlyand at approximately, but not necessarily exactly, thesame physical time. A checkpoint is used only to bringup a new active replica.

� In semi-active replication, both the primary and thebackup replicas execute each invoked operation. Theprimary provides directives (such as the order in whichto process messages) to the backups. The backups fol-low those directives, and thus lag slightly behind theprimary in executing the operations. Only the primarycommunicates results and makes further invocations.

The most challenging aspect of replication is maintain-ing replica consistency, as operations are invoked on the ser-vice, as the states of the replicas change, and as faults occur.Replica consistency is obviously critical for active and semi-active replication, which must maintain the consistency oftwo or more concurrently executing replicas. Less obvi-ously, replica consistency is also important for passive repli-cation because a recovering replica must repeat computa-tions and communications with other Web Services sincethe most recent chechpoint. Those computations and com-munications must be consistent with the prior computationsand communications to avoid disrupting other Web Services.Maintaining replica consistency requires the sanitization ofnon-deterministic operations and also the handling of sideeffects, as discussed below.

��

Checkpointing is used by all replication strategies but indifferent ways. Passive replication uses checkpointing dur-ing normal operation. Active replication and semi-activereplication do not use checkpointing during normal opera-tion, but use it to initialize a new or recovering replica.

The checkpoints of an application process can be storedon disk, or can be transmitted to and stored in another pro-cessor. If a fault occurs, the application process is then restartedon the same or a different processor, and the most recentcheckpoint is used to restore the process to the state it had atthe time of the checkpoint. There are basically two kinds ofcheckpointing, application-aware and application-transparent.

� In application-aware checkpointing, the application pro-grammer implements a getState() method and a set-

State() method. The getState() method captures par-ticular parts of the application state and encodes thatstate into a byte sequence, and the setState() methoddecodes the byte sequence and restores the applicationfrom the checkpoint.

� In application-transparent checkpointing, the check-pointing infrastructure uses operating system mecha-nisms [14] to capture the state of the application pro-cess (including file descriptors, thread stacks, etc), with-out the need for the application programmer to imple-ment the getState() and setState() methods.

For applications that involve multiple threads within aprocess or data structures that contain pointers, it is diffi-cult to implement the getState() and setState() methods ofapplication-aware checkpointing. On the other hand, applica-tion-transparent checkpointing does not produce checkpointsthat are portable across hardware architectures, because acheckpoint taken as a binary image contains values of vari-ables that differ for different architectures, such as memoryaddresses.

��

For simple restart without replication or checkpointing,and for all replication and checkpointing strategies, a faulttolerance infrastructure must provide message logging andreplay. Again, the messages can be logged either in thememory of another processor or on disk. However, loggingthe messages on disk and subsequently replaying them fromdisk can have adverse performance impacts.

For restart without either replication or checkpointing,the entire message history (from the first message in the setto the most recent message) must be retained and all of themessages must be replayed. For replication and checkpoint-ing, only the messages since the most recent checkpoint needto be replayed to the new or recovering replica.

��!"��#�� $��%��&�� '��

There has been extensive research undertaken on the topicof sanitizing non-deterministic operations (see, e.g., [18]).

Messaging is one source of replica non-determinism, be-cause messages can be received by the replicas in differentorders, due to loss of messages and retransmissions, delaysin the network, etc. To maintain replica consistency, mes-sages must be delivered to the replicas reliably and in thesame order. Such a message delivery service is sometimescalled atomic broadcast [10]. The Java Messaging Service(JMS) has been extended to provide atomic multicasts [17].For passive replication, the infrastructure must log messageson disk or in the memory of another processor so that, if theprimary replica fails, the messages after the checkpoint canbe replayed. For both active and passive replication, the in-frastructure must detect and suppress duplicate invocationsand duplicate responses.

Another source of replica non-determinism is multithread-ing. If two threads within a replica share data, they mustclaim and release mutexes that protect that shared data. How-ever, the threads in two different replicas will likely run atslightly different speeds and, thus, they might claim mutexesin different orders. To maintain replica consistency, the mu-texes must be granted to the threads within the replicas in thesame order.

Other sources of replica non-determinism include oper-ating system functions that return values local to the pro-cessor on which they are executed, such as rand() and get-timeofday(), or inputs for the replicas from different redun-dant sources, or system exceptions due to, say, exhaustionof memory on one of the processors. Such sources of replicanon-determinism must be sanitized, so that all of the replicassee the same values of the functions, the same inputs fromthe redundant sources, and the same system exceptions. Thissanitization must be done, whatever replication strategy isused.

��( �� "��%)*��

In addition to sanitizing non-deterministic operations, side-effects that occur as the result of a client invoking opera-tions on a Web Service must be handled properly to achievereplica consistency.

In particular, if a Web Service writes data to files or adatabase, those operations must be handled correctly. Theactions taken depend on whether each replica has its owncopy of the database or the files, or the replicas have a singleshared copy. Similarly, if a Web Service sends messages to,or invokes operations on, other Web Services, those opera-tions can have side-effects that must be handled properly.

��+ ��

Within a single enterprise, transactions have been suc-cessfully used to provide data consistency and to protect dataagainst faults by means of their ACID properties.

It is possible to achieve higher availability of Web Ser-vices that employ transactions by using transactions and repli-cation together. In particular, by replicating the transactioncoordinator, the 2PC protocol can be rendered non-blockingand exactly-once semantics can be provided for the clients’invocations. Moreover, by replicating the middle-tier com-ponents and using transparent transaction retry, roll-forwardrecovery can be achieved. We have implemented an infras-tructure for CORBA [27] that replicates the transaction coor-dinator and also the middle-tier application objects to protectthe business logic processing and to avoid potentially longservice disruptions caused by failure of the coordinator. Asimilar infrastructure for Web Services that unifies transac-tions and replication can provide both data consistency andhigh availability.

4 WS Architectures and Dependability

Web Services applications are typically programmed inJava or .Net. We refer here to a Java-based implementation.

A three-tier Web Services architecture involves clientsin the first tier, a Web server, a servlet engine and/or a J2EEapplication server in the middle tier, and a database systemin the third tier, as shown in Figure 5. The clients com-municate with the Web server and invoke operations on theWeb Service, which is deployed in a server-side container.The server-side container can be a servlet container such asTomcat, or a EJB container in a J2EE application server suchas JBoss or Geronimo. The Axis SOAP engine works withboth types of containers. Typically, there are multiple clientsand multiple Web servers that are used for load balancing theclients’ requests.

In a typical Web Services use case, the client accesses aWeb page, which consists of HTML and Java Servlets or JSPscripts. The client can make invocations by clicking on oneor more links provided in that page. Once a request reachesthe servlet engine, a servlet creates dynamic content for aresponse Web page, and might also perform simple businesslogic processing and communicate with the database system.Applications that involve complex business logic processingtypically use a J2EE application server. Multiple J2EE ap-plication servers might be used to load balance the clients’requests. The servlet creates dynamic content for the pre-sentation of the Web page and communicates with the EJBcontainer, containing session beans that perform the busi-ness logic processing and entity beans that correspond to thedatabase records.

Within an enterprise, the components of a Web Servicecan be made dependable using fault tolerance technology, asshown in Figures 6 and 7 and discussed below. See also [13].

�� ,� "��

A Web server is sometimes regarded as “stateless” in thatit does not retain any application state between its responseto a client’s request and the client’s next request. The ap-plication state is either stored in the database or returned to

RMP

SOAP

HTTP

TCP

IP

Client

RMP

SOAP

HTTP

TCP

IP

PrimaryWeb Server

RMP

SOAP

HTTP

TCP

IP

BackupWeb Server

FT FT

Figure 6. Fault-tolerant Web server.

BrowserApache

Web Server

Client Tier

Application Servlet

Tomcat Servlet Engine

Axis SOAP EngineDatabase

Database TierApplication Presentation Tier

JBoss Application Server

Application Logic Tier

Session Beans

Entity Beans

Application Logic

Middle Tier

Axis SOAP Engine

Figure 5. Three-tier Web Services architecture.

the client in a URL or a cookie. However, during the pro-cessing of a client’s request, the Web server does maintainapplication state and also hidden internal state, such as theprogress of nested invocations or disk I/Os or the state of theconnections with the Tomcat servlet engine or the database.The state that results from actions that are visible to otherprocesses must be captured, and restored if a fault occurs.

If the Web server fails while processing a client’s re-quest, either the unreplicated Web server must be restartedand the client must reissue the request, or the replicated Webserver must be failed over from the primary to a backup onanother processor, as shown in Figure 6. In the latter case,the fault tolerance infrastructure must replay the client’s re-quests to the restarted or backup Web server after the check-point has been restored. In either case, the Web server mustnot write the state to the database, or send a response to theclient, more than once.

In addition, the infrastructure at the servlet engine orthe J2EE application server must ensure that the restarted orbackup Web server receives its response messages reliablyand in the correct order, if the Web server fails.

�� "��

To achieve high availability, fault tolerance must be pro-vided for the Tomcat containers and the servlets containedwithin them using replication, checkpointing, and messagelogging.

Even if the state of the servlet application, such as thestate stored in a session object, is written to the database be-fore the servlet sends a response back to the Web server, acheckpoint must be taken that includes the state within theTomcat containers, such as the connections with the Webserver and the J2EE application server or database server.Subsequently, if the servlet engine fails while it is process-ing a client’s request and interacting with the J2EE applica-tion server or the database server, the servlet engine must bebrought back up or failed over to a backup servlet engine. Itsstate must be restored from the checkpoint, and the messagesafter the checkpoint must be replayed.

In [12] Hanik describes in-memory session replicationfor the Tomcat servlet engine that uses the Java Groups groupcommunication toolkit. That strategy exploits Java’s serial-

izability to checkpoint and restore the session state, but re-stricts what can be put into a session object to ensure serial-izability. Moreover, with that strategy, storing request datain decentralized sources, such as temporary files, can resultin data inconsistencies.

In [3] Bartoli, Prica and di Muro describe a frameworkfor program-to-programinteraction across unreliable networksand an implementation in a Tomcat servlet container. Theprototype is based on replication of HTTP client sessiondata and replication of a counter. The framework providesthe same consistency guarantees as a non-replicated servicewith respect to the order of execution requests. Moreover, itensures that, even if a client issues duplicate requests (e.g.,because of a service fault), the service executes the client’srequest at most once.

�� - )) �� "��

Some three-tier Web Services architectures use J2EE ap-plication servers. The J2EE standard derives from the CORBAstandard, and mandates the use of CORBA’s Internet Inter-ORB Protocol. The CORBA Object Transaction Service[20] provides data consistency through atomic commitmentof distributed transactions. The Fault Tolerant CORBA stan-dard [19] provides high availability by replicating the appli-cation objects. There exist several implementations of FaultTolerant CORBA (e.g., [18, 26]).

Fault tolerance must be provided for the EJB/J2EE con-tainers and the beans within them even if the application iscoded as one or more transactions with rollback and if thebeans are entity beans whose states are stored in a database.Again, the reason is that the EJB container contains consid-erable hidden internal state [22]. If application-transparentcheckpointing is used, there are interesting interactions andoverlap between the checkpoint of the EJB/J2EE containerprocess and the states of the entity beans stored in the databasethat must be reconciled.

In [2] Babaoglu, Bartoli, Maverick, Patarin and Wu de-scribe a framework for prototyping J2EE replication algo-rithms. They divide the replication code into two layers, theframework itself which is common to all replication algo-rithms and a specific replication algorithm that is pluggedinto the framework.

WebServer

W2

WebServer

W1

Servlet/JSPEngine

S1

Servlet/JSPEngine

S2

J2EEServer

E1

J2EEServer

E2Database

D2

DatabaseD1

ClientBrowser

A

ClientBrowser

B

ClientBrowser

C

UnreplicatedClients

ReplicatedServers

Tier1 Tier2 Tier3

Figure 7. Fault-tolerant three-tier Web Services architecture.

��

To achieve both data consistency and high availabilityfor transaction-based applications, the transaction coordina-tor must be replicated. Replication of the transaction coor-dinator renders the 2PC protocol non-blocking and achievesexactly-once semantics for the clients’ invocations [15]. Fur-thermore, if the middle-tier servers are also replicated andtransparent transaction retry is used, roll-forward recoverycan be achieved [27].

��! �� "��

Much work has been done on improving the reliabil-ity and availability of database systems. Vaysburd [25] hasprovided an excellent survey of commercial packages thatprovide fault tolerance for database systems, with respectto such requirements as persistence, data consistency, andavailability of service.

��( ,� "��

The UDDI registry for Web Services that contains theWSDL descriptions of the Web Services must be availablefor the clients that are looking for them. Availability of theUDDI registry can be achieved using the fault tolerance tech-niques of replication, checkpointing, and message logging,described previously.

The OASIS standards organization has published a spec-ification for lazy replication of the UDDI registry [9], wherethe updates are propagated point-to-point from one replicato another replica. Sun, Lin and Kemme [24] have imple-mented the OASIS lazy replication strategy for the UDDIregistry, as well as an eager replication strategy. The eagerreplication strategy is based on middleware that employs amulticast group communication protocol. They provide re-sponse time, propagation time, and execution results for bothreplication strategies in a LAN and in a WAN.

��+ ��

Distributed transactions based on the 2PC protocol areseldom used for business activities that span multiple en-terprises, because they unavoidably involve one enterprise’slocking the data records of another enterprise. Instead, ex-tended transactions, as defined by the WS-Coordination [6]and WS-BusinessActivity [8] specifications, are used. Ex-tended transactions typically involve local transactions andcompensating transactions [11] that offset committed localtransactions when a business activity is rolled back. How-ever, compensating transactions can have undesirable effects,such as one transaction’s seeing the results of another trans-action before the compensating transaction is applied.

In [28] we have presented a reservation-based extendedtransaction protocol for Web Services that coordinates busi-ness activities and that avoids the use of compensating trans-actions. Each task within a business activity is executed astwo steps. The first step involves an explicit reservation ofresources according to the business logic. The second stepinvolves the confirmation or cancellation of the reservation.Each step is executed as a separate traditional transaction.

5 Conclusion

If Web Services are to achieve their objective of automat-ing business activities across multiple enterprises, they mustbe made dependable. The existing Web Services reliablemessaging, transactions and business activity specificationsmust be augmented with additional mechanisms to providehigher levels of reliability, availability, and consistency.

In this paper, we have described various fault tolerancetechniques for increasing the reliability, availability, and con-sistency of Web Services, including transparent SOAP con-nection failover, replication, checkpointing, and message log-ging, and have shown how to apply these techniques to aWeb Services architecture. In the future, we plan to inves-tigate various security mechanisms that could be integratedwith these mechanisms.

6 Acknowledgments

This research has been supported in part by MURI/AFOSRGrant F49620-00-1-0330 for the authors at the University ofCalifornia, Santa Barbara, and by a faculty startup award forthe author at Cleveland State University.

References

[1] N. Aghdaie and Y. Tamir, “Implementation and evaluation oftransparent fault-tolerant Web Service with kernel-level sup-port,” Proceedings of the IEEE International Conference onComputer Communications and Networks, Miami, FL, Octo-ber 2002, 63-68.

[2] O. Babaoglu, A. Bartoli, V. Maverick, S. Patarin, and H. Wu,“A framework for prototyping J2EE replication algorithms,”Proceedings of the International Symposium on DistributedObjects and Applications, Agia Napa, Cyprus, October 2004,1413-1426.

[3] A. Bartoli, M. Prica, and E. Antoniutti, “A replication frame-work for program-to-program interaction across unreliablenetworks and its implementation in a servlet container,” Con-currency and Computation: Practice and Experience, JohnWiley & Sons.

[4] R. Bilorusets, et al., Web Services Reliable Messaging Pro-tocol (WS-ReliableMessaging), February 2005, http://www-128.ibm.com/developerworks/webservices/library/ws-rm/.

[5] D. Booth, H. Hass, F. McCabe, E. Newcomer, M. Champion,C. Ferris, and D. Orchard, Web Services Architecture, Febru-ary 2004, http://www.w3.org/TR/ws-arch.

[6] L.F. Cabrera, et al., Web Services Coordination, Septem-ber 2003, http://www.ibm.com/developerworks/library/ws-coor/.

[7] L.F. Cabrera, et al., Web Services Transaction, August 2002,http://www.ibm.com/developerworks/library/ws-transpec/.

[8] L.F. Cabrera, et al., Web Services Business Activity Frame-work, January 2004, http://www.ibm.com/developerworks/library/ws-busact/.

[9] L. Clement, et al., UDDI Version 2.03 Replication Spec-ification, http://uddi.org/pubs/Replication-V2.03-Published-20020719.pdf, July 2002.

[10] X. Defago, A. Schiper, and P. Urban, “Total order broadcastand multicast algorithms: Taxonomy and survey,” ComputingSurveys 36, 4, December 2004, 372-421.

[11] H. Garcia-Molina and K. Salem, “Sagas,” Proceedings of theACM SIGMOD Conference on the Management of Data, SanFrancisco, CA, May 1987, 249-259.

[12] F. Hanik, “In-memory session replication with Tomcat 4,”April 2002, http://www.TheServerSide.com.

[13] D. Ingham, S. Shrivastava, and F. Panzieri, “Constructing de-pendable Web Services,” IEEE Internet Computing, vol. 4,no. 1, January/February 2000, 25-33.

[14] G. Janakiraman, J, Santos, D. Subhraveti, and Y. Turner,“Cruz: Application-transparent distributed checkpoint-restart on standard operating systems,” Proceedings of theIEEE International Conference on Dependable Systems andNetworks, Yokohama, Japan, June 2005, 260-269.

[15] R. Jimenez-Peris, M. Patino-Martinez, G. Alonso, and S.Arevalo, “A low-latency non-blocking commit service,” Pro-ceedings of the International Conference on DistributedComputing, Lisbon, Portugal, October 2001, 93-107.

[16] R. Koch, S. Hortikar, L.E. Moser, and P.M. Melliar-Smith,“Transparent TCP connection failover,” Proceedings of theIEEE International Conference on Dependable Systems andNetworks, San Francisco, CA, June 2003, 383-392.

[17] A. Kupsys, S. Pleisch, A. Schiper, and M. Wiesmann, “To-wards JMS compliant group communication,” Proceedingsof the IEEE International Symposium on Network Computingand Applications, Cambridge, MA, August 2004, 131-140.

[18] P. Narasimhan, L.E. Moser, and P.M. Melliar-Smith,“Strongly consistent replication and recovery of fault-tolerant CORBA applications,” Computer Science and En-gineering Journal 17, 2, March 2002, 103-114.

[19] Object Management Group, Fault Tolerant CORBA, OMGTechnical Committee Document formal/02-06-59, Chapter23, CORBA/IIOP 3.0, 2000, http://www.omg.org.

[20] Object Management Group, Transaction Service Specifica-tion v1.2 (final draft), OMG Technical Committee Documentptc/2000-11-07, 2000, http://www.omg.org.

[21] S. Pallickara, G. Fox, and S.L. Pallickara, “An analysis of re-liable delivery specifications for Web SAervices,” Proceed-ings of the IEEE Conference on Information Technology, LasVegas, NV, April 2005, 360-365.

[22] M. Pasin, M. Riveill, and T. Weber, “High-available enter-prise Java Beans using group communication system sup-port,” Proceedings of the European Research Seminar on Ad-vances in Distributed Systems, Bologna, Italy, May 2001.

[23] T. Rutt, M. Peel, D. Bunting, K. Iwasa, and J. Durand,Web Services Reliability (WS-Reliability), August 2004,http://oasis-open.org/committees/tc home.php?wg abbrev=wsrm.

[24] C. Sun, Y. Lin, and B. Kemme, “Comparison of UDDI reg-istry replication strategies,” Proceedings of the IEEE Inter-national Conference on Web Services, San Diego, CA, July2004, 218-225.

[25] A. Vaysburd, “Fault tolerance in three-tier applications: Fo-cusing on the database tier,” Proceedings of the IEEE Sym-posium on Reliable Distributed Systems, Lausanne, Switzer-land, October 1999, 322-327.

[26] W. Zhao, L.E. Moser, and P.M. Melliar-Smith, “Design andimplementation of a pluggable fault tolerant CORBA infras-tructure,” Cluster Computing: The Journal of Networks, Soft-ware Tools and Applications, Special Issue on DependableDistributed Systems 7, 4, October 2004, 317-330.

[27] W. Zhao, L.E. Moser, and P.M. Melliar-Smith, “Unifica-tion of transactions and replication in three-tier architecturesbased on CORBA,” IEEE Transactions on Dependable andSecure Computing 2, 1, January-March 2005, 20-33.

[28] W. Zhao, L.E. Moser, and P.M. Melliar-Smith, “Areservation-based coordination protocol for business activi-ties” Proceedings of the IEEE International Conference onWeb Services, Orlando, FL, July 2005, 49-56.

making web services dependable · 2007. 2. 24. · distributed systems. the participants in a...

Documents