A Fault Propagation Approach for Highly Distributed Service Compositions

Meiko JensenDepartment for Computer Science

Christian-Albrechts-University of Kiel, Germanymje@informatik.uni-kiel.de

Abstract

Today, the techniques for realizing service compositions(e.g. WS-BPEL) have become mature. Nevertheless, when itcomes to execution faults within service compositions, manyproblems are still unsolved. Especially the propagation andglobal handling of errors in service compositions yet re-mains an open issue.

In this paper, we describe some preliminary results ofour ongoing work in the field of fault propagation and ex-ception handling in service compositions. We provide someservice classification criteria and show how they relate toservice composition fault handling. Further, we present afault propagation approach for service compositions.

1. Introduction

The widespread paradigm of service-oriented architec-ture (SOA) relies on the idea of single, network-based ser-vices, providing special, encapsulated tasks, and servicecompositions which aggregate invocations of such singleservices into more complex ones. As service composi-tions are provided as single services itself, they may beused within other service compositions as well, spanningtrees of composed services. A widespread realization ofthis paradigm is the Web Services Architecture [5].

In the context of single service invocations, a fault thatraised within a service execution is propagated to the ser-vice requester by sending a special type of reply message,e.g. an appropriate SOAP fault message for Web Services.Thus, the responsibility for fault handling in single serviceinvocations is up to the requester.

In service compositions, this approach does not alwayshold. Depending on the services involved in the composi-tion, the task of dealing with faults in single service exe-cutions may require rollback and recovery measures withinother parts of the service composition, and the reply-with-a-fault-message concept of single service invocations is nolonger sufficient to handle execution errors reliably.

In this paper, we present our ongoing work on faultpropagation approaches for service compositions. We givea classification of different participation types of serviceswithin service compositions, and illustrate their problemsin fault handling and compensation from the perspective ofthe service composition. After presenting our general ap-proach, we will give some concretions and prerequisites forfault handling approaches within service compositions.

2. Foundations

2.1. Message Passing Patterns

Service invocations start with a request that triggers theservice execution. Optionally, a request can be answered bya reply message, containing results of the execution. Thesecommunication patterns are known as request-response andone-way in terms of WSDL.

As the widespread SOAP-over-HTTP binding has somelimitations on the time an HTTP session stays establishedfor a direct reply message, service invocations can be clas-sified as being either synchronous—where a direct replymessage within the same HTTP session is sent—or asyn-chronous, where the service replies by invoking anotherWeb Service at the requester’s side. Though the latter oneallows a service execution to take an arbitrary amount oftime, it requires the request message to contain a Web Ser-vice endpoint address the reply message should be deliveredto. For Web Services, this is done via WS-Addressing [2].

As it is a typical case to have a one-way service invoca-tion without any necessity for a reply—e.g. triggering somelogging activities or a database write operation—the notionof a reply-to endpoint often is omitted. Thus, there are threebasic communication patterns of interest in the context ofservice invocation:

1. a one-way request without any reply opportunity,

2. a synchronous request-response invocation and

3. an asynchronous request-response invocation.

2008 IEEE International Conference on Services Computing

978-0-7695-3283-7/08 $25.00 © 2008 IEEE

DOI 10.1109/SCC.2008.38

507

2008 IEEE International Conference on Services Computing

978-0-7695-3283-7/08 $25.00 © 2008 IEEE

DOI 10.1109/SCC.2008.38

507

Figure 1. A service composition example

2.2. Fault Handling for Web Services

For common Web Services, a fault within a service ex-ecution causes the Web Service framework to send an ap-propriate SOAP fault message to the requester. For syn-chronous service invocations, this fault message can be sentdirectly using the existing TCP connection. In the asyn-chronous case, the fault message can be delivered using theendpoint reference given in the request message.

For the one-way request invocation, the delivery of afault message poses a problem. As the requester does notexpect any answer apart from binding-specific headers (e.g.HTTP 202 Accepted, which is sent on complete messagereception), there is no intent to keep the TCP connectionopen. If the fault happens to occurr within the service ex-ecution, but after the requester closed its connection, thedelivery of the appropriate fault message can only be donein an application-specific manner.

2.3. Service Compositions

Based on the idea that a service may invoke other ser-vices during its execution, the term of service compositionrefers to the approach of aggregating basic services thatprovide single, elementar functionalities into compositionalservices that perform more complex tasks.

An example of a typical service composition is given infigure 1. Imagine a Book Order Service providing the func-tionality of buying a book.

First, the credit card information used within the requestmust be validated. As this task cannot be done by the BookOrder Service itself, it employs the Credit Card Check ser-vice, provided by the credit card company. This servicevalidates the correctness of a given credit card number anddeterminates the liquidity of the corresponding billing ac-count. Thus, both CC Number Check service and CC Liq-uidity Check service are basic services, while the aggregatedCredit Card Check service is a simple compositional ser-vice.

Assuming that the book happens to be not in stock, a sec-ond step consists in delegating the book order to an ExternalSupplier Order service. This service employs an appropriateShipping Service and does some Order Billing.

As a final part of the service composition, the ShippingService consists of a Shipping Address Check and someShipping Billing tasks.

2.4. States in Service Compositions

Looking at the example above, it is possible to classifythe participating services according to their execution be-haviour.

Some of the basic services like CC Number Check pro-vide a simple computational task that does not have anystateful context. Either the credit card number is valid ornot, but in both cases the service delivers the result withina reply message and forgets about the invocation. We callsuch types of services stateless basic services.

Other basic services are intended to perform a task thatdoes not have any direct reply, but merely triggers some ap-plication specific internals. An example is the Order Billingservice, which collects the necessary information for gen-erating a bill and then uses other, internal computations inorder to complete this task. These kinds of services havetheir internal state modified by every service request (e.g.a new bill is filed), thus they can be called stateful basicservices.

For compositional services, this classification does notobviously hold. Though the Credit Card Check servicemaintains an internal execution state, its intended behaviouris that of “reply-and-forget” for every invocation. Thus, onthe one hand it clearly performs a stateful execution (firstcall CC Number Check, then call CC Liquidity Check), onthe other hand its internal persistency did not change aftercompletion of a service request.

When it comes to fault handling and rollback issues,these different classes require different tasks to be per-formed. Stateless basic services do not need to recover

Figure 2. Common fault propagation

508508

Figure 3. Full forward recovery approach

anything, and a fault will be propagated directly to the re-quester1. Compositional services may delete their internalexecution instance, but a more important task for them isto propagate the fault to all services it already invoked andto its own requester. Recovery for stateful basic servicesis likely to become very complex and will always requireapplication-specific measures.

3. The Fault Propagation Approach

We propose an approach of treating fault handling notas an additional message type in a single service invoca-tion, but merely as a complete workflow of its own. Thus,a service that encounters an error during its execution doesnot “reply” with a fault message delivered to its requester,but it merely invokes a special Web Service that explicitlydeals with fault handling issues of the particular service in-vocation. This FaultHandler service—which may beprovided as a special operation at the same Web Serviceendpoint—explicitly takes all appropriate measures to per-form rollback and consistency check operations in order tosolve the problems caused by the particular error.

For the given example scenario, an error occurring at theShipping Address Check service would cause this serviceto invoke its own meta-service FaultHandler instead ofreplying to the compositional Shipping Service with a faultmessage. Then, the FaultHandler service can take ap-propriate measures as described below (see Section 3.1).

One big advantage of this fault handling model con-sists in the possibility to invoke the FaultHandler ser-vice not just for the service that raised the error, but forother services involved in the same service composition aswell. As the fault handling functionality itself is providedas a service, it may be invoked by other services, includingthe FaultHandler services of other composition partic-ipants. Further, the functionality of rollback and recovery

1Obviously, stateless basic services will always have some kind of replymessages.

Figure 4. Centralized backward recovery

can be used within regular service composition executions.Another advantage is that this approach enables a con-

sistent handling of faults that occurr within fault handlers.Especially for dynamic service compositions with asyn-chronous invocations, the delivery and handling of faultmessages may cause faults itself. So, while fault messagereplies for single service invocations cannot be re-answeredwith another fault message, the proposed approach ad-vances here by enabling a fault handling recursion of anydepth.

3.1. Fault Recovery Approaches

There are several different tasks a FaultHandlermaybe responsible to do, depending on the particular service’stype (stateless/stateful and basic/compositional). First ofall, it has to recover its own internal states, re-setting per-sitent data and the like (internal recovery). Then, it maytrigger the FaultHandler services of those services thatit already invoked within the same service composition exe-cution instance. This is what we call forward recovery. Fur-ther, it may notify the requester of the compositional serviceit is responsible for. We call this backward recovery in thefollowing.

The first approach for fault handling in service compo-sitions consists in determining the original initiator of theservice invocation as a whole (The Book Order Service inthe example). A discussion on how to determine this infor-mation will be given in Section 3.2. Once the original ini-tiator is determined, its FaultHandler is invoked, whichwill do a full forward recovery on the whole service com-position execution instance (see Fig. 3). Obviously, this is avery radical approach, as it would lead to an all-or-nothingresult, which in most scenarios is not appropriate.

A second approach would be to invokeFaultHandlers in reverse order along the serviceinvocation chain, each performing forward and internalrecovery only (see Fig. 4). Though this may lead to somerecovery actions performed twice or more times, it has

509509

Figure 5. Decentralized backward recovery

the advantage that each FaultHandler may decidewhether a further backward recovery is necessary. Thus,this approach better supports the opportunity to recoverthe necessary parts of a service composition only, and toresume normal operations sooner than with the first ap-proach. Nevertheless, it still requires the FaultHandlerof the service that raised the error to know the wholeservice invocation chain from the original initiator up to itsown service. Again, you will find a discussion on that topicbelow (Section 3.2).

In order to get rid of the necessity to know the fullservice invocation chain, the second approach may be re-fined by transferring the responsibility for the progress ofthe fault handling to all of the involved FaultHandlersrather than solely the FaultHandler of the erroneousservice. In this approach, each FaultHandler just hasto know its direct requester’s FaultHandler endpoint.As with the original approach, forward and internal recov-ery is done by each FaultHandler itself. But in con-trast to that approach, each FaultHandler service in-vokes its requester’s FaultHandler service itself (seeFig. 5) instead of leaving this task to the FaultHandlerof the service that initially raised the error. This way, thefault handling shows the same characteristics and commu-nication paths as the original service invocation, just in re-versed order. No “centralized” FaultHandler is neces-sary. Nevertheless, there also is no single executional unitthat solely is responsible for handling the fault, and if oneFaultHandler along the service invocation chain doesnot agree to this propagation approach, fault handling willmost likely never complete. Thus, this approach brings flex-ibility, but lowers robustness in fault handling.

3.2. Approach Prerequisites

In order to invoke the FaultHandlers of previouslyinvoked services within a service composition, it is neces-sary to spread some information on the service composi-tion participants. Both approaches described above require

knowledge on the service endpoint of a service’s requesteror the original initiator of a service composition’s execution.

An obvious way to provide this information (which maybecome of interest for other tasks as well, see e.g. [3]) is toembed the service invocation chain (or history) within eachrequest message of the composition. For SOAP-based WebServices, this may e.g. be done by embedding a continuouslist of WS-Addressing endpoint references within a desig-nated new SOAP header element.

4. Conclusion, Related and Future Work

We have shown a general approach for dealing withfaults in service invocations, which enables a service com-position to perform a reliable, consistent fault handlingmethod even within dynamic service compositions. Theapproach is able to deal with faults within fault handlers,and enables the use of rollback and recovery functionalitywithin regular service executions.

Related work by CHAFLE et al. [1] already stated the ne-cessity to explicitly deal with fault handling and error recov-ery in service compositions. Nevertheless, their proposedstatus monitor focusses on the centralized approach only,which is not suitable for real decentralized service compo-sitions. Additionally, they do not consider different servicetypes and fault-handling needs.

Other approaches (e.g. [4]) focus on bringing transac-tion properties to service interactions, which is not suitablein highly distributed service compositions as the examplepresented here.

In the future we will focus on different application sce-narios for our approach, creating an appropriate protocolextension for the Web Services architecture. Further, wecontinue implementation of a prototypical middleware forevaluating the usability and advantages of our approach.

References

[1] G. B. Chafle, S. Chandra, V. Mann, and M. G. Nanda. Decen-tralized orchestration of composite web services. In WWWAlt. ’04, pages 134–143, New York, NY, USA, 2004. ACM.

[2] M. Gudgin, M. Hadley, and T. Rogers. Web Services Ad-dressing 1.0 - SOAP Binding. W3C Recommendation, May2006.

[3] M. Srivatsa, A. Iyengar, T. Mikalsen, I. Rouvellou, and J. Yin.An Access Control System for Web Service Compositions.icws, 0:1–8, 2007.

[4] F. Tartanoglu, V. Issarny, A. Romanovsky, and N. Levy. Coor-dinated Forward Error Recovery for CompositeWeb Services.srds, 00:167, 2003.

[5] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, and D. F.Ferguson. Web Services Platform Architecture: SOAP, WSDL,WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messag-ing, and More. Prentice Hall PTR, 2005.

510510