Byzantine Fault Tolerance for Coordination of Web Services in Cloud

Byzantine Fault Tolerance for Coordination of Web Services in Cloud

V. Lingajothi

S.A Engineering College, Computer Science and Engineering,

Chennai, India.

S. Subhaponmani

S.A Engineering College, Computer Science and Engineering,

Chennai, India.

Abstract Cloud computing is a developing computing paradigm. It aims to share data, controls and service clearly over an available network of nodes. Since cloud computing repository the data and spread resources in open environment. In our project, the composite of web services should be stored in the cloud by using the coordination of web services. The coordination of web service business activities should be reliable by using the Lightweight Byzantine Fault Tolerance (BFT) algorithm. This algorithm is the outcome of a complete analysis of the threats to the WS-BA coordination services and also it carefully study about the state model of WS-BA. The lightweight BFT is need not to perform total ordering of request rather than it customs source ordering to achieve reliable coordination of WS-BA, state- machine replication of the WS-BA coordination service.

Keywords Byzantine Fault Tolerance (BFT); Cloud Computing; Distributed Computing; Web Services.

1. INTRODUCTION

   Web services defines a consistent way of consolidating Web-based applications with the XML, SOAP, WSDL and UDDI open standards terminated an Internet protocol. The data should be tag by using XML, Using SOAP, the data should be transfer, the services available should be describe by using WSDL and Using UDDI ,to list the available services. Web services alternatively divide business logic, data and processes over a programmatic interface through a network. The web services application should have the two types parts. One is client that initiating a allocating the business activity and the second one is server should carry out the activity.

   The OASIS (Organization for the Advancement of Structured information Standards) is a worldwide relationship that enterprises the development, convergence and acceptance of e-business and web service standards [14]. The OASIS should develop the web services Business Activity (WS-BA) specification and also standardizes the activation of web services, registration of web services and coordination of the WS-BA. A business activity contains one or more participants, a coordinator and an initiator. The initiator should start and terminate the business activity. The business activity should be distributed to the participants from the initiator using coordination context in a request. According to the business

   logic, the initiator is determining the result of the business activity.

   In this paper, the travel reservation application is used. The travel reservation is one of composite web service (aggregation of web services is called as composite web services). This application should be directly interact with the client. In this project, we take two types of web services from the travel reservation application. This two composite web services are airline reservation and hotel reservation application and this two web service contain only one initiator. These types of application are independent to the owner and also provided by the service provider (agent) that is third- party.

   The initiator should create the web service business activity when the participants or user invokes the composite of web service. This web service business activity is used for communicated with the travel reservation application (airline application and hotel reservation). The coordinator components make sure that the business activity is correctly distributed to the travel reservation web services and also is well end according to the predefined policy.

   From that travel reservation application, the reliable of the coordination service is important to the business activity.it is necessary to have the coordinator replicated for byzantine fault tolerance (BFT). Inappropriately, WS-Specification does not decide a standard way for communication between an initiator of business activity and coordination of business activity.

   This design choice is easy for merchants to integrate WS- BA coordination functionalities into their business process engines but it difficult to ensure the interoperability between the different vendors of initiator and coordination [12]. This interoperability must need because of necessary of separating the initiator and the coordinator. In specific that,

   • A composite web service (such as a travel reservation service) should be created in a small company for their customers. It is difficult for the customers to implement and host robust coordination service.

   • On the other side, Amazon, Google that is large company should offer the coordination service for their part of the cloud service.

     WS-BA-I protocol referred as the extension of WS-BA specification proposed by Erven at al. [12]. This extension of WS-BA specification used to separate the functionality of coordination and the business logic and the way of standard that can be interaction between the initiator and the coordinator. With the help of WS-BA-I extension WS-BA becomes available for the third party to provide coordination services to originalities that need to conduct WS-BA with minimum modifications to their workflow engines.

     This is type of coordination service widely adopted so must be reliable for their participants. In this paper, we mainly concerned the high availability and high integrity of the web service. To increase the reliable of web services, we develop the number of specifications. These specifications are,

     1. WebService-ReliableMessaging and Web Service- Reliability specification

        These two types of specification concerned on reliable message exchange. This exchange is taken place between the two web services. The WS-Reliability is based on SOAP and OASIS specification and the WS-Reliable Messaging use the extension model of SOAP and WSDL. The current web services standards are defined by the WS-Reliability specification. WS-Reliability was out of date by WS-Reliable Messaging.

     2. WebService-Security

        This type of specification describes the basic mechanism for providing the secure messaging between the different web services. This specification is extension to the SOAP to apply the security of web services.

     3. WebService-Trust

     This type of specification is extension of WS-Security token exchange and also it defines primitives of web service web services of different reliable domain.

     The main objective of this project is fully focuses on the high availability of web service and high integrity of the web service. Why we need this above two types of features defined as follows

   • The participants cannot able to register the web service (that is airline reservation, hotel reservation) when the coordination service are not highly availability.

   • The WS-BA should be inconsistent when the integrity of coordination service is compromised.

   The uses of WS-Specification for WS-Messaging are trustworthy for the solution. The coordination of web service should be replicated because to achieve the high availability and high integrity of the web services. The Byzantine fault model is necessary when the untrusted environment of the internet.

   The Byzantine fault is an arbitrary fault that caused by both omission failures and commission failures during the execution of the program or algorithm by a distributed system. The omission failure means break down failures,failing to receive a request or failing to send a response [5]. The commission failure occurs when processing a request inaccurately, mortifying local state and/or sending an inconsistent response to request. The system may respond in an unpredictable way when a Byzantine failure has occurred, unless it is designed to have Byzantine Fault Tolerance (BFT).

   Byzantine Fault Tolerance is a sub field of failures tolerance. The main objective of BFT is that protect against Byzantine failures in which components of a system fails does not dependence on any procedure or algorithm. BFT requires 3f+1 based on replication. f refers to faulty. All server replicas reach agreement on the Byzantine faulty replicas and clients such as achieved by ensuring BFT. This agreement referred as Byzantine agreement.

2. THE WEB SERVICE BUSINESS ACTIVITY

   A Web Service is a way that communicates between client and server application over the Internet via open protocol. The web services are creating more and more business activities and then transforming into distributed computing environment. The Web Service Business Activity (WS-BA) specification was used to create and to enable the web service to participate site in long running application. This WS-BA specification is loosely coupled transaction to the web service. This type of transaction is mostly used for modeling business application. For example, work flow system, the execution engine is responsible only for the coordinating the participants in the business logic as per rule defined in business process.

   The business activity is a set of initiator, coordinator and one or more participants. The initiator is used to start the business activities and also terminate the business activities. The coordinator components consist of registration service, activation service, coordinator service, completion service [4]. When participants invoke to the web service, initiator create a web service business activity for the particular request from the participants. Then the coordinator component check whether the created business activity is propagated to the web service and also check whether its terminated predefined policy or not.

   The coordination service of the business activities should be replicated because to achieve high availability of services and high integrity of the service. The coordination services are tightly coupled to the web services. So the lack of well- defined interface between the application and coordinator requires coordination service that is built into the application. The participant have trust the coordination services. The coordination service contains all the state notifications and records all the state changes.

   Using coordination context, the initiator increases the business activity to the participants according their request. In business application the workflow engine provide the WS-BA coordination services. This coordination services will enable the web service environment without workflow engines to create a web service, to coordinate between initiator and

   participate in long running application. An initiator of a web service business activity is to communicate with the coordinator of the web service business activity by using the WS-BA specification. This specification does not specific any standard way for communication.

3. PROPOSED SYSTEM

   Consider the travel reservation application example, this application using both WS-BA-I extension and the WS-BA specification. This travel application uses the atomic-outcome transaction and the BAwCC protocol. The travel reservation consists of airline reservation, hotel reservation. The airline reservation consists of airline services and participants services and also the hotel reservation consists of hotel service and participants services.

   In this proposed system consists of a participants side, an initiator and the coordination side. Initiator service is the main part of the business activity because the business activity is started and terminated by initiator. If any faulty can be appeared in the initiator means that time the BFT algorithm should be used.

   The coordination service consists of registration service, activation service, coordination service and completion service. The registrations services are used to register the participants inform. Then this inform is stored into the database. After finishing the registration services, the user id and password should be generated to the participants. Using this user id and password, the participants can access the web service anytime at anywhere.

   Fig.1. System Architecture

   Next, the activation services are used for activate the user requested service. This activation service generates a business activity coordination context that is creating the activation id. This activation id is send to the participants. If the participants send the complete message to the coordination or the coordination sends the complete message to the participants means that time this activation id get expired.

   Next the completion service is used for indicate the completion message. This message may be indicated by coordination service or by the participants. Once the participants send the complete message to the coordination

   services means the user cannot able to modify or cancel the transactions.

   Next the cloud storage, the composite web services should be stored in the cloud. It is represented in fig.1.

   A. Analysis of state model

   First , we examine the different business activities, in this process the business activity should be handle independently in WS-BA requests that is the state transitions model does not affected by their relative ordering. This independent business activity is observable for the registration requests and the coordinator requests because this are handled by different coordinator objects. All though all the requests are managed by the same process, their business activities relative ordering does not influence how the coordination objects are created. Anyway, the creation of coordination objects or coordination identifiers are very important for the replica consistency. We manage this specific replicas non determinism problem without resorting to inter-replica coordination, which needed for the byzantine agreement algorithm between the coordination replicas.

   Next, we examine within the same business activity, in WS-BA requests, the activation and registration requests are causally related, i.e., the activation request must lunch the registration request. This relative ordering of requests is planned directly into the BFT framework without resorting to inter-replica coordination. It is direct to make sure that the source ordering of requests from a participant in the BAwCC or BAwPC protocol (e.g., by using a sequence number).

   One part of the coordinator state associated with one participant. If any changes in that states means it does not affect another part of coordinator state associated with another participants. According to the BAwCC or BAwPC protocol, the coordinator object uses each part of the participants to keep track the state. The modify coordinator object requests should be sent by all the participants according to their respective parts of the state. So it is not necessary to order requests from the different participants. Dependent on the requests from the initiator the requests are classified into three parts to the WS-BA-I Specification.

   The first type of request is to generate the invitation tickets to the participants, only one at a time. Within the business activity, this type of request can include with the requests from the participants, because the business activity are managed by different objects.

   The second type of request is read-only mode that is queries the state of the business activity. Although these requests does not changed to the coordinator state. The initiator gets report of different states from the different replicas. This query requests are not ordered with respective tothe participants requests. This states is not important because the initiator can repeatedly send the query require to the coordinator so it becomes guaranteed by using BFT algorithm.

   The third type of requests are direct to the coordinator terminate the business activity. If the requests are not in order requests with respect to their participants then it takes the last queries states from the initiator. This request is also not

   important because the WS-BA-I specification take care of these replicas requests. The initiator requests a cancel message to the coordinator for the participants. That time participants also have seen the complete message from initiator. In this situation, the coordinator send the compensate message to the participant instead of the cancel message.

4. CONCULSION

Several companies, for example Amazon, Google, Microsoft, and Apple, are now proposing cloud services. Some of them might offer coordination services used for web services in the cloud. Such coordination services could permit smaller companies to propose combined web services to offer value-added services to their customers without having to invest heavily in computing infrastructures.

The Coordinator object is replicated in our BFT framework. The cloud coordination service should be replicated the service in order to achieve high availability and data integrity of the service and also provide the cloud storage this cloud storage provides as a service to storage consumers.

REFERENCES

1. www.gictf.jp/doc/GICTF_Whitepaper_20100809.pdf

2. Apache WSS4J, http://ws.apache.org/wss4j/, 2013.

3. Zhong Xu, Rong Huang,(2009)Performance Study of Load Balanacing Algorithms in Distributed Web Server Systems, CS213 Parallel and Distributed Processing Project Report.

4. C. Attiya, D. Dolev, and J. Gil, Asynchronous Byzantine Consensus, Proc. ACM Symp. Principles of distributed Computing, pp. 119- 133, 1984.

5. M. Castro and B. Liskov, Practical Byzantine Fault Tolerance and Proactive Recovery, ACM Trans. Computer Systems, vol. 20, no. 4, pp. 398-461, Nov. 2002

6. D. Davis, A. Karmarkar, G. Pilz, S. Winkler, and U. Yalcinalp, Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1,

   OASIS Standard, Jan. 2008

7. D. Dolev, An Efficient Algorithm for Byzantine Agreement without Authentication, Information and Control, vol. 52, no. 3, pp. 257-274,

   Mar. 1982

8. ] D. Dolev and H.R. Strong, Authenticated Algorithms for Byzantine Agreement, SIAM J. Computing, vol. 12, pp. 656-666, 1983

9. H. Erven, H. Hicker, C. Huemer, and M. Zapletal, The Web Services- BusinessActivity-Initiator (WS-BA-I) Protocol: An Extension to the Web Services-BusinessActivity Specification, Proc. IEEE Intl Conf.

   Web Services, pp. 216-224, July 2007

10. T. Freund and M. Little, Web Services Business Activity, Version 1.1, OASIS Standard, Apr. 2007.