Proceedings of the Int. Conf.

on Information Science and Applications ICISA 2010

6 February 2010, Chennai, India.

An Algorithm for Selection of Service in Asynchronous Web Services with

Byzantine Fault Tolerance
S. Murugan1, V. Ramachandran2
1
Research Scholar, Sathyabama University, Tamilnadu, India.
2
Professor, Dept. of Computer Science and Engineering, Anna University, Tamilnadu, India.
1
snmurugan@live.com

Abstract—Asynchronous transactions are becoming
important in the implementation of B2B Web
applications, and Web services providing a well
established platform for communication between
applications. This paper addresses the effective
transaction between service provider and service
requestor under different scenarios. We had
developed a model to handle the exceptions which
usually occurs in any communication pattern. This
paper proposes an algorithm for selecting the
service (asynchronously invoked) after identifying
Byzantine attacks and client resumes from the point
of failure.
Keywords—Asynchronous, Byzantine, callback,
exception handling, polling, WSDL, UDDI
Byzantine faults [17]) must be tolerated to ensure
maximum service dependability. Middleware that
provides such type of fault tolerance is often termed as
Byzantine fault tolerance (BFT) middleware.
The paper is organized as: 1) introduces the various
asynchronous patterns, 2) known exceptions, 3)
replication mechanisms, 4) Byzantine fault tolerant
mechanism, 5) algorithm to select the service with
Byzantine attack and client to resume from the point of
failure, 6) conclusions and future scope.
ASYNCHRONOUS PATTERNS
The various asynchronous patterns are: Polling
pattern, Callback pattern, Publish subscribe pattern,
Callback with acknowledgement.

INTRODUCTION In polling service requestor only as consumer of

the services the service provider will produce the results
Web services have been the de facto means to
for the request made [4] (Figure 1). This pattern
enable business-to-business (B2B) applications in and
encompasses two WSDL operations: (i) a request-
between enterprises. Web services are outgrowing the
response to send the request; (ii) another request-
synchronous request-response model and emerging as a
response to ask for the answer. The client submits the
flexible distributed computing platform in which the
request and receives immediately a synchronous
asynchronous service model takes a more important
acknowledgement, together with a request context
role [2]. Invocations of Web services are asynchronous
identifier (CID). Later, the client invokes the service to
in nature in that the service provider must be capable of
obtain the answer; it will therefore send a message
accepting requests from clients without notice.
including the CID received before, in order to allow
However, sometimes the response to the Web service
correlation at server side. If in the meanwhile the server
request is available on the same thread of execution as
prepared the answer, the response is ready and the
the invocation; such operations are often labeled as
server provides it, otherwise the server returns a
synchronous. The Asynchronous operations will not
message stating the response is not ready yet, and
focus on the initiation of request messages by clients or
asking the client to retry later.
the consumption of request messages by service
providers; rather, it focuses on how to handle responses
Client Machine Server
to Web service requests that are not provided
1 Invoke 2 Send
immediately but at a time after the initial request Client Client
Service
transactions complete. Such asynchronous behavior is Proxy
common for services that require complex processing
3 Return
that may take minutes or even days to complete when, Set the
a Poll Object
for example, the Web service implementation is Polling and Poll
getting back the
dependent on batch processing or manual steps Object
requiring human intervention [3]. Considering the un-
trusted communication environment in which these
services operate, arbitrary faults (crash faults as well as Figure 1. Polling Pattern

Panimalar Engineering College ISBN 978-81-907677-9-8

 In the Callback pattern, the service provider of service message to the client. After acknowledge, to
publishes a one-way service, whose purpose is to accept get the actual service response the client should now
the incoming client calls [4] (Figure 2). Each request publish, a request-response operation to receive the
must include an identifier, the required input parameters response message from the dual solicit-response
and the Reply-to address. The Reply-to address is the operation in the Service provider side, and send back an
address of the service which has to be invoked to ack message.
provide the client with the response. When the response
Publish Subscribe with Acknowledgement is an
for the client is ready, the service provider sends a
orthogonal mechanism; it can be used in single-request,
message at the Reply-to address, bearing the response
multiple-responses configuration, thus generating
data. The Notification service at server side is therefore
publish-subscribe with acknowledgement pattern.
“advertised”, because the client must publish a service
that fulfills the format of expected response from the
service provider Client Service
(Peer) Provider
Publish-subscribe pattern generalizes callback at
App Pub
the purpose of modeling subscription to repetitive StockInfoSubscribe
One way
information delivery and event notification services [4]
(Figure 3). Pub Ad
StockUpdates
Client Machine 3 One Notification
Server
Send way
2 Invoke Client
Client Servic
Proxy
Figure 4. Publish Subscribe Pattern
EXCEPTIONS
Callbac It is known that in any mode of communication,
1 Creates there exist errors. In case of asynchronous
a Callback 4 Response is communication the following types of exceptions exist
Object dispatched in the above said patterns: They are: Exception
to the callback by the
handling, complex asynchronous conversations is not
Figure 2. Callback Pattern possible, unexpected delivery of messages, forwarding
service (hold/retry). The exception that will be
Client Service discussed in this paper is the exception handling.
(Peer) Provider
REPLICATION
App Request, Reply-to Pub The replication performs the following: the
Address replication node requests the hosts to deploy their
Ack with CID members based on the registered fault tolerant
properties, activates the fault detectors to monitor the
different hosts (services), subscribes fault notification
Response with CID to from fault notifier for the service group and chooses the
Pub Adv
reply-to address
Request Request primary and backup members, this information will be
Responser Ack Responser saved in the groups WSDL, lastly, the replication
publishes the WSDL of the service group to UDDI for a
client that intends to access the service [18].

Figure 3. Callback with acknowledgement

Application
Callback with acknowledgement pattern is a
generalization of callback pattern, in the sense that now Replication UDDI
each involved operation is bidirectional [4] (Figure 4).
This pattern is a generalization of callback pattern, in
the sense that now each involved operation is Fault Notifier
bidirectional. In callback with acknowledgement, the
client contacts the service provider by invoking a
S1 S2
request-response service. This call can either succeed,
and the client will thus receive the correlation ID as Service Group
acknowledgement, or fail, and the server sends a denial

231 Panimalar Engineering College

 BYZANTINE FAULT TOLERANT Table 1. Java execution time (in ms) for different
Byzantine fault tolerance (BFT) refers to the number of processes, number of rounds and
capability of a system to tolerate Byzantine faults. For a processing messages
client-server system, BFT can be achieved by replicating RESUMABLE ASYNCHRONOUS WEB SERVICE CLIENT
the server and by ensuring all server replicas to execute WITH BYZANTINE FAULT TOLERANT
the same request in the same order. The latter means
One common exception that happens is handling
that the server replicas must reach an agreement on the
the server crash. That is during the processing if the
set of requests and their relative ordering despite
server crashed then the question is, what happened to
Byzantine faulty replicas and clients. Such an agreement
the data that is currently processed? In polling there
is often referred to as Byzantine agreement [17].
will be a continuous checking from the requestor end
Byzantine fault tolerance algorithm is implemented whether the server is processed its request. If the
in java and the time taken for different sets of rounds operation is completed (either success / failure) the
and processing instructions is given below. provider will return the processed result to the requestor.
Processes Rounds Messages Time(ms)
During polling if the server is not available then the
5 10 260 22 requestor will return an error without even knowing
6 10 1630 13 about to what level the provider had completed its task.
7 10 11742 89
8 10 95900 773 The proposed solution for the above said problem,
9 10 876808 4977 during polling when the requestor approaches the
5 110 260 22
completion of the job at the provider, the server returns
6 110 1630 13
7 110 11742 59 the status to the client about the processed details.
8 110 95900 501 Suppose if the server crashed, then the client will be
9 110 876808 4162 holding the last completion status. The requestor will
5 210 260 13
6 210 1630 13
then keep on polling whether the server is ready for
7 210 11742 49 processing or not. If yes, then the requestor will send
5 310 260 22 the last processed result to the provider, and it continues
8 210 95900 473 in the place where it left. (Figure 6).
6 310 1630 13
9 210 876808 4067 The replication strategy will be used by the server
5 410 260 6
for handling the fault. Replication is implemented on
7 310 11742 91
6 410 1630 13 more than one secondary host. Due to distributed
8 310 95900 417 environment, it is not necessary that all the server
5 510 260 13 replicas to execute the same request. This leads to
9 310 876808 4169
7 410 11742 63
Byzantine fault tolerance. Even after Byzantine
5 610 260 13 agreement the final computed values that are
6 510 1630 23 manipulated by the different hosts need not be unique.
8 410 95900 431
5 710 260 22 The issues to be addressed in this model are: i)
7 510 11742 89 when the provider should response back to the client
6 610 1630 53
and with result, ii) on receiving the intermediate
9 410 876808 4531
5 810 260 22 processed result where the client should store it and
8 510 95900 432 how long the result should be preserved, iii) how to
6 710 1630 22 handle the issue of Byzantine Fault Tolerant.
7 610 11742 69
5 910 260 13 The first problem is resolved by the polling policy.
9 510 876808 4569 The polling is done by the client at regular intervals.
6 810 1630 22
8 610 95900 443 Polling time can be fixed depends on the type of
7 710 11742 96 application it is processing. It is the responsible of the
6 910 1630 22 client to pull the intermediate results from the server.
9 610 876808 4479
7 810 11742 79 The second issue deals once again with the
8 710 95900 443 requestor end. It is the responsible of the client to store
7 910 11742 113
9 710 876808 4413 the intermediate results. One possible solution to this
8 810 95900 437 problem depends on the type of the application it can
8 910 95900 563 store in a temporary memory or in a database and the
9 810 876808 4501 decision is left to the client’s requirement.
9 910 876808 4339

Panimalar Engineering College 232

 The third issue is the major task. Once the The client (service requestor) sends an initial
replicated hosts send the processed data to the client, request to the host H1 for a service. The host H1 sends
the client has to cross check with the intermediate value an initial response to the client. Once after confirming
that is stored (which the primary server sent lastly), if from the host the client invokes the polling request back
the values are matched with the replicated host (not to the host. The host starts processing the client request
necessary that all the replicated hosts should have the and creates the replication hosts H2 and H3 in parallel.
same value), then once the client acknowledges, the In between the intermediate results will be received by
replicated host will start with the completion of the the client. At some point of time the host H1 crashes.
remaining task. This leads to the client transparent The replication manager makes the secondary host as
elimination of Byzantine Fault. the processor. In this model, all the replicated hosts will
send the intermediate results to the client. The
intermediate result with the client and from the other
H3 H2 H1 Client hosts, using the Byzantine algorithm, the values are
scanned and the appropriate host will be selected for
IReq further processing. The selected host sends the final
result back to the client.
IRes ALGORITHM FOR SELECTION OF SERVICE:
1. Client establishes an asynchronous connection
PReq with the primary server H1
Rep InRes 2. Primary Server H1 controls the secondary servers
Rep H2 and H3
F 3. Client receives Intermediate values from the
primary server H1
InRes H2
4. If the Primary server fails (crashes) then

InRes H3
a. Client Å H2 (Client receives the Intermediate
Value from the secondary server H2)

P
b. Client Å H3 (Client receives the Intermediate
Value from the secondary server H3)
Sel H2
c. Apply Byzantine algorithm to identify the traitor.
i. Choose the service:
FRES Case 1: if H2 is traitor then choose H3.
Case 2: if H3 is traitor then choose H2.
Case 3: if H2 and H3 are traitors then
Figure 6. Asynchronous Pattern with wait for H1 to resume.
Client Transparent Byzantine Fault Case 4: if H2 and H3 are loyal, then
choose the service whichever is having fewer
Legends: loads than the other. The other factors to
IReq – Initial Request choose the service are: Cost, distance, server
IRes – Initial Response performance.
PReq – Polling Request
InRes – Intermediate Response d. Resume the service.
InRes Hi – Intermediate Response from replicated (The above algorithm can be extended to perform
hosts with any number of secondary servers).
Sel H2 – After computing Byzantine Fault Tolerant
Algorithm Host H2 is selected CONCLUSIONS AND FUTURE WORK
F – Host H1 Server Error The solution discussed, reduces the overhead of the
P – Processing by client with the intermediate result server by not redoing the same process which it had
obtained from replicated hosts already done. The time spent in processing the
FRES – Final computed result from secondary host information before server crash is not wasted. The
Rep – Replication with other hosts problem in this model is that the client has to
F – Server Failure continuously monitor for the server whether it is

233 Panimalar Engineering College

recovered or not. The client also requires additional
storage area for storing the intermediate results. The
concept of replication and handling Byzantine fault
tolerant will lead to additional overhead in the
processing and execution time.
The model also handles errors only on the server
side, if the client crashed then the status of the
processed intermediate results are not known.
REFERENCES
[1] Marco Brambilla, Giuseppe Guglielmetti, and Christina
Tziviskou, “Asynchronous Web Services Communication
Patterns in Business Protocols”, in the proceedings of WISE
2005.
[2] J-Y Chung, K-J Lin, R.G. Mathieu, “Service-oriented
computing”, Web Services Computing, IEEE Computer Vol.
36, Issue 10, pp 38-44, Oct. 2003.
[3] H.Adams, “Asynchronous operations and Web services”, an
IBM article, http:// www.ibm.Com/ developerworks/library/ws-
asynch1.html
[4] Marco Brambilla, Stefano Ceri, Mario Passamani, Alberto
Riccio, “Managing Asynchronous Web Services Interactions”,
in the Proceedings of the IEEE International Conference on
Web Services (ICWS'04)
[5] Michael Ruth, Feng Lin, Shengru Tu, “A Client-Side
Framework Enabling Callbacks from Web Services”, in the
Proceedings of the Third European Conference on Web
Services (ECOWS’05).
[6] Michael Ruth, Feng Lin, Shengru Tu, “A Framework for Web
Service with Callbacks for Resumable Clients”, in the
Proceedings of the International Conference on Next Generation
Web Services Practices (NWeSP’05)
[7] Sam Chung, Jennifer R. Pan, Sergio Davalos, “A Special Web
Service Mechanism: Asynchronous .NET Web Services”, in the
Proceedings of the Advanced International Conference on
Telecommunications and International Conference on Internet
and Web Applications and Services (AICT/ICIW 2006)
Panimalar Engineering College
[8] Venugopalan Ramasubramanian and Douglas B. Terry,
“Caching of XML Web Services for Disconnected Operation”,
Microsoft Research
[9] Jingtao Yang, Corina Cîrstea, and Peter Henderson, “Document
Flow Model: A Formal Notation for Modelling Asynchronous
Web Services Composition”, R. Meersman et al. (Eds.): OTM
Workshops 2005, LNCS 3762, pp. 39 – 48, 2005. © Springer-
Verlag Berlin Heidelberg 2005
[10] Markus Voelter, Michael Kircher, Uwe Zdun, Michael
Englbrecht, “Patterns for Asynchronous Invocations in
Distributed Object Frameworks”, in the proceedings of IEEE
International Conference on ICWS 2007, pp 208-215.
[11] Michael Ruth, Feng Lin, and Shengru Tu, “A Client-Side
Framework for Resumable Applications to Utilize Web Services
With SRMR Callbacks”, in the International Journal of Web
Services Practices, Vol.1, No.1-2 (2005), pp. 73-88
[12] Soheil Toodeh Fallah, Ehsan Zaeri Moghaddam, and Saeed
Parsa, “An Event-Driven Pattern for Asynchronous Invocation
in Distributed Systems”, in the proceedings of IJCSNS
International Journal of Computer Science and Network
Security, VOL.7 No.4, April 2007
[13] Yendluri P., Web Services Reliable Messaging,
http://webservices.org/
[14] Oasis web services reliable messaging (wsrm).
http://www.oasis-open.org/.
[15] W3C proposed recommendation. soap version 1.2 part 1:
Messaging framework, May 2003. http://www. w3c.org/
[16] IBM, Reliable, http://www.ibm.com/developerworks
/webservices/library/ws-httprspec/
[17] L. Lamport, R. Shostak, and M. Pease. “The Byzantine generals
problem”. In the proceedings of ACM Transactions on
Programming Languages and Systems, 4(3):382–401, July
1982.
[18] Deron Liang, Chen-Liang Fang, Chyouhwa Chen, Fengyi Lin,
“Fault tolerant web service”, in the proceedings of the Tenth
Asia-Pacific Software Engineering Conference (APSEC’03)
(2003 IEEE).
234