Development of a Reliable SOA Framework

Transcription

1 Chapter 4 Development of a Reliable SOA Framework Service-Oriented Architecture (SOA) supersedes the traditional software architecture because of its dynamic nature of service composition. Service is an encapsulated function that is different from other services in the environment. Services in SOA accept requests and return one or more responses by using any defined standard interfaces. A service can berequested by a user or by another service by which service composition happens. Service composition is an aggregate of services collectively composed to automate a particular task or business process [8]. This immensely helps the business world to improve their agility. Business agility is one important characteristic that is supported by SOA very strongly. In order to support the business agility, service composition plays an important role. There are certain issues related to service composition that needs special attention. There might be a situation where SOA services may not be available for task based or business process based service compositions. There may be various reasons for formation of service compositions such as lack of business process understanding or tasks, network failures, services not registered in the registry server, intricate composition and distributed network complexity etc. Hence the non available services can be composed to make the business systems more efficient. In this chapter, first we propose an architecture for a self analyzing and reliable SOA followed by a framework for exception handling and a model for dynamic fault handling. All these approaches will enhance our proposed self analyzing SOA. Self analyzing SOA architecture has the following capabilities: i) To analyze the developed services by considering the user s requirements. ii) To evaluate the perfectness of developed service, before its delivery, and to find out its accuracy. iii) To find the missing services as per users requirement.

2 58 Development of a Reliable SOA Framework iv) To take corrective measures to develop missing services. v) To compose missing services along with other services as per user requirements meeting the service composition criteria. The proposed architecture for a self analyzing and reliable SOA is based on the above mentioned self analyzing SOA capability. It is discussed in Section The Proposed Architecture of Self Analyzing and Reliable SOA In this section, we propose an architecture of self analyzing and reliable SOA as shown in Fig. 4.1 [26]. It consists of six horizontal layers and four vertical layers dealing with all six horizontal layers. The six horizontal layers are data & components, specification & analysis, service, process, business process execution & analysis and presentation. The four vertical layers are composition, fault handling, integration and quality of service. The vertical layers handle different types of mechanisms associated with six horizontal layers. The brief description of all six horizontal layers is presented below: Figure 4.1: Proposed Architecture for a Self Analyzing and Reliable SOA Data and Components Layer: It consists of legacy systems such as objectoriented systems, artificial intelligence applications, data repositories, old reusable

3 4.1 The Proposed Architecture of Self Analyzing and Reliable SOA 59 data, components which are responsible for realizing functionality and maintaining the Quality of Service (QoS), enterprise assets, and various servers like application servers, file server, server etc. It deals with the various legacy as well as stateof-art database systems, where the data is retrieved in a heterogeneous environment. Specific SOA services are designed and implemented to handle these data retrieval in heterogeneous environment. Specification and Analysis Layer: This layer deals with the user specification and analysis of the requirements leading to service specification. Based on application specification and considering user s perspective the user condition action database, service specification and work flow specification are built. So, this layer consists of two specifications, they are service specification and work flow specification. For example, check balance is a service and withdraw cash is a work flow in an online banking system. Service Layer: The services that are exposed to the consumer, reside in this layer. The services can be discovered first and then invoked or choreographed into a composite service. This layer consists of mechanism to publish interfaces of components, service descriptions and exposes them through service registry for using Universal Description, Discovery and Integration (UDDI) protocol. If a service is not found, building of atomic services at same layer takes place by defining Web Service Description Language (WSDL). Process Layer: This layer consists of business process logic that are mapped to the services. This layer deals with composition of business services based on the mechanisms like choreography or orchestration. This layer integrates services together which are exposed in the service layer according to the work-flow specification to build a single composite application. Business Process Execution and Analysis Layer: This layer deals with deployment of services and its execution analysis. The functionality of this layer is to analyze the developed service to find out the errors. This layer analyses the perfectness of the composed services. It also finds out the differences between the newly built service and the service as required by the user. When the self analysis process is satisfied, the service is delivered else the fault is found out for further processing. Presentation Layer: The presentation layer exposes the composed services to be invoked by the users through various interfaces. It is not a mandatory layer in SOA. Now-a-days, this layer is needed, because there is an increasing convergence of standards, such as web services for Remote Portlets Version 2.0 and other technologies that seek to leverage web services at the application interface or presentation level. Moreover, this layer deals with invocation of services through software to software communications. The four vertical layers that handle the mechanisms are as follows:

4 60 Development of a Reliable SOA Framework Composition: Composition is a part of service layer and process layer. When the unavailability of a service is notified after searching service registries, the service layer initiates for atomic composition. The composition at process layer deals with mechanism for composition of the required services to develop the required composite service. This mechanism is based on a knowledge-base. The knowledgebase contains the service profiles and the condition action database for services, which are already available. After composition, each service must have this condition action database. Each condition action database of a service has the number of conditions that a service must meet to perform correctly. For each condition, there may or may not be one respective action to satisfy that condition. For calculation of perfectness, a value column is also included in the database. A value of 2 is considered for primary condition and a value of 1 is considered for secondary condition. When a new service is composed by taking a number of services, a new condition action database is created for the composed service by adding all the condition action database of the services taking part in composition for developing the new service. Condition action database includes primary condition, secondary condition, primary value, secondary value and services. Fault Handling: While development and execution analysis continue, fault tolerance is achieved by handling composition faults. The composition faults for services are found by analysing their executions at business process execution and analysis layer. These faults are corrected by the process recycle, where the recomposition takes place to handle the composition error. Error for any wrong data input at the time of execution can also be handled with roll-back to the previous session by storing the previous session variables. Integration: This layer enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the Enterprise Service Bus (ESB). Web Services Description Language (WSDL) specifies a binding, which implies a location where the service is provided. On the other hand, an ESB provides a location independent mechanism for integration. Quality of Service (QoS): This layer provides the capabilities required to monitor, manage, and maintain QoS such as, performance, and availability. This is a background process done through sense-and-respond mechanisms, tools that monitor the health of SOA applications, other relevant protocols and standards that implement quality of service for SOA Working of the Architecture This section deals with the working of our proposed architecture. The work flow of the proposed architecture is shown in Fig The process of the proposed archi-

5 4.1 The Proposed Architecture of Self Analyzing and Reliable SOA 61 tecture gets started, when a request from a service consumer arrives. An application specification is built containing the service consumer s requirements as conditions. Conditions can be divided as primary conditions and secondary conditions. Primary conditions are those composed services without which the service consumers requirement cannot be satisfied. Secondary conditions are optional requirements of the service consumer without which the composed services will be able to meet the goal. Based on the requirements, a user condition action database is created having those conditions that should be satisfied to meet the user requirements. The process controller is the controller of the work flow of the whole process. User provides the service/application specification having primary and secondary conditions. Based on the application specification and service specification the work flow specification is built. A user condition action database is created which stores the primary and secondary conditions specified in the service/application specification and the required actions, wherever needed. The service provider is made aware about the service specification. Accordingly, the services are looked upon in the service registry for composition. Then, the identified services are passed on to the process controller. The process controller then initiates the work flow specification of the service. The process controller forwards these identified services to the service specification repository. This information along with the work flow specification is forwarded to the dynamic composer. The application monitoring is done to keep track of the service interactions and data is stored if any error or exception occurs. This monitoring process continues till all service interactions are completed. Finally, all the errors or exceptions occurred are captured and handled through this mechanism. Dynamic composition of the services now takes place, based on the work flow specification. If any atomic service is not found, it is developed and tested by analyzing the execution of business processes. Considering the business process execution in analysis layer, the developed services are tested to analyze the execution of proper work flow of the process. Self analysis is done at this layer to find out the perfectness of the developed service in comparison with the user s requirement. Dynamic reconfiguration and composition takes place in this case, where a new requirement arises or any service replacement has to take place due to some composition error which gives rise to recycling of the process Self Analysis of Developed Services Self analysis of the developed services is carried out for finding out the perfectness or correctness of the services. The requirement and service specification are mapped based on the user s requirements. It provides a measure for better accuracy. It also detects composition faults while analyzing the services and handles them in order to provide more reliability. The new condition action database is analyzed by

6 62 Development of a Reliable SOA Framework Figure 4.2: Work flow of the Proposed SOA Architecture comparing with the user condition action database which was previously created. It is based on user s requirement that arises at various points of time of the process execution. The user condition action database has columns such as primary condition, secondary condition, action, primary value and secondary value. The new condition action database also has primary conditions and secondary conditions. The primary conditions are the collection of all primary conditions of the condition action database of those services that had taken part in composition of the new service. Similarly, the secondary conditions are the collection of all secondary conditions of the condition action database of all those services, that had taken part in composition of the new service. The service column indicates to which service a particular condition belongs. The primary conditions must satisfy to meet the user s requirement, with comparison to the secondary conditions. We have taken the value for primary condition as 2. Then, the value of the secondary conditions should be less than the primary condition value. So, we have taken the value for the secondary condition as 1. Let us consider an example from banking domain. If a user requires the account details (accountnumber, accounttype, amount), customer details (name, socialse-

7 4.1 The Proposed Architecture of Self Analyzing and Reliable SOA 63 curityno, telephone) along with the address details (streetno, streetname, postbox, city, state, zipcode, country) of a customer as a service, then zipcode and telephone may be considered as secondary conditions. Hence, by excluding zipcode and accessingthe particulars of a customer in theform of aservice called addresshavingname, streetno, streetname, postbox, city, state and country, is another need. So, here zipcode can be taken as a secondary condition in the user condition action database. Similarly, we can exclude telephone number making telephone as a secondary condition. Let, the service specification to build the services consists of three services namely account, customer and address. Their condition action database for service account, service customer and service address are shown in Table 4.1, Table 4.2 and Table 4.3 respectively. The service profile contains the accuracy of that service, where accuracy is found out by calculating the perfectness. In this case, the perfectness is found with respect to the customer s address. Table 4.1: Condition Action Database for Service Account Primary Condition Secondary Condition Primary Value Secondary Value Name Service accountnumber null 2 null account accounttype null 2 null account amount null 2 null account of Table 4.2: Condition Action Database for Service Customer Primary Condition Secondary Primary Secondary Name of Condition Value Value Service name alphabetic 2 1 customer socialsecurityno numeric 2 1 customer telephone numeric 2 1 customer Table 4.3: Condition Action Database for Service Address Primary Condition Secondary Condition Primary Value Secondary Value Name Service streetno null 2 null address streetname null 2 null address postbox null 2 null address city null 2 null address state null 2 null address zipcode numeric 2 1 address country alphabetic 2 1 address of If any of the primary conditions of the composed service is not found in the database of developed service then, the developed service is not acceptable. Such

8 64 Development of a Reliable SOA Framework type of service will not satisfy the primary requirement of the user. So, fault is detected and this fault can be corrected by recycling the process by using the application monitoring mechanism. For the purpose of error handling, the conditions responsible for errors should be kept for further processing while execution of service analysis continues. Algorithm 4.1 shows the analysis process of the developed service. Algorithm 4.1 Analysis Process of the Developed Services 1: Initialize i=0, j=0, counter=0, primary value=2, secondary value=1, i = no of records in user condition action database, j=no of records in condition action database 2: for m = 0 to i do 3: pc=primary condition of user condition action database 4: end for 5: for n = 0 to j do 6: if pc=primary condition of new condition action database then 7: Exit 8: else 9: Display message fault in service. So service is not acceptable because of error in condition PC. 10: Add 1 to counter. 11: Store the respective related row of user condition action database in the database called error detection. 12: end if 13: end for 14: Find out the number of primary conditions and number of secondary conditions from user condition action database and number of primary condition and number of secondary conditions of new condition action database and store them in variables no of primary, no of secondary, no of primary1, no of secondary1, respectively. 15: Minperfectvalue = no of primary primary value 16: Maxperfectvalue = (no of primary primary value)+ (no of secondary secondary value) 17: Newperfectvalue = (no of primary1 primary value)+ (no of secondary1 secondary value) 18: if (newperf ectvalue = perf ectvalue) then 19: perfectness = best. The developed service is a best service to accept. 20: end if 21: if (newperf ectvalue > minperf ectvalue) then 22: perfectness = better. It is a better service and is acceptable. 23: end if

9 4.1 The Proposed Architecture of Self Analyzing and Reliable SOA 65 24: if (newperf ectvalue = minperf ectvalue) then 25: perfectness = good. The developed service is good and is acceptable. 26: end if 27: if (counter > 0) then 28: Go to Step 2 29: end if Considering any value within the Maxperfectvalue and Minperfectvalue, indicates that all primary conditions along with some secondary conditions have been satisfied, which makes the service a better one Case Study: Banking Service The main purpose of the bank is to handle customers accounts to provide good services to its customers. Following are the three cases to achieve this purpose of the bank. Case 1 To have all the details of the customer account. Case 2 To have all the details of the customers, for their unique identification. Case 3 To have all the details of the customers by which a contact through letter can be possible whenever needed. To accomplish the required task, three atomic services account, customer and address are needed for Case 1, Case 2 and Case 3 respectively. So, the requirements of the bank will be fulfilled by a service which needs to be composed by taking these three services. With reference to the layers of the proposed architecture following functions are performed- Data and components layer:- Based on the requirement, the user condition action database for the required service is searched in the service registry, which contains the list of existing services and their details. In this case, Table 4.4 shows the user condition action database with the related existing service name filled against the respective row of the conditions. Here, the atomic services account, customer and address are already present in the service registry. If any of the atomic services is not present in the registry then in this case the conditions in the rows without having the service column are taken for atomic composition. Here the conditions are account no, account type and amount. This composition takes place in service layer and the atomic service account is created by taking all these 3 primary conditions. Table 4.4 shows user condition action database when service account is not present in the service registry. Specification and analysis layer:- When the requirement comes first it is analyzed in the specification and analysis layer. The requirement specifications are in the form of primary and secondary requirements and are called primary condition

10 66 Development of a Reliable SOA Framework Table 4.4: Unavailability of Service Account in user condition action database Primary Condition Secondary Condition Primary Value Secondary Value Name Service account no. numeric 2 null customer account null 2 null customer type amount null 2 null customer name null 2 null address social security null 2 null address number telephone 2 1 address of and secondary condition respectively. Primary conditions are those requirements of the customer without fulfilling which the goal will never be achieved. Secondary conditions are those conditions of the requirements of the customer without which also we can achieve the goal of service composition, if primary composition is captured well from user requirement. Service layer:- The atomic composition is performed in service layer by taking conditions of the vacant service column of user condition action database. Whenever a service is composed a condition action database is created. Services account, customer and address are physically present in the service layer. All the existing services are exposed in this layer for the composition. The existing services at the time of composition have their condition action databases. Process layer:- In the process layer the composite composition takes place by considering the services condition action databases and the services that are found against the service column of user condition action database. To compose the final service needed in order to fulfill the requirement of the bank, the following service database are taken into account such as condition action databases of services account, customer and address. A new condition action database is created by adding all the primary conditions and secondary conditions of these condition action databases. Business Process Execution and Analysis Layer:- After composition of the new condition action database, it is compared with the user condition action database. The perfectness of the service is found out by using the algorithm for self analysis given in Algorithm 4.1. The composition faults are also detected whenever a primary condition of user condition action database is not found in the new condition action database and is stored in error database. Fig. 4.3 shows that the new composed service is a better service having all the primary conditions and secondary conditions. In Fig. 4.4 the new composed service have the fault in composition service having all the primary conditions that are not equal in both new condition action database and user condition action database as

11 4.2 Framework for Exception Handling in Web Services 67 Figure 4.3: The contents of new condition action database streetno is not present in new condition action database. Presentation Layer:- Finally, the new composed service interface is exposed to the user. Hence the service address with zipcode and telephone number can be served. So, a self analysis of the missing services could be composed by the application monitoring in the specification and analysis layer of proposed SOA architecture. Once the new service is composed it goes as per the work flow of all the layers of Fig Framework for Exception Handling in Web Services InordertomaketheproposedSOAshowninFig. 4.1morereliablewehaveproposed an exception handling technique in the vertical layer called fault handling [83]. Exception handling is the most essential designing element of any type of web service. But, mostly while designing the web services, applications lack enough attention towards exception handling. Web services, communicating with other web service servers that use Service-Oriented Access Protocol (SOAP) cause compatibility problem and miss the interoperability as well as lack in effective fault tolerance mechanism. Considering, interoperability and Fault Tolerance (FT) as primary issues, a framework to provide automatic resolution for web services from an ab-

12 68 Development of a Reliable SOA Framework Figure 4.4: Self analysis of new condition action database in comparison to user condition action database normal breakdown is proposed and is shown in Fig These breakdowns happen whenever web services are developed based on basic profile (BP) version 1.0 specification to communicate with those web services that are developed using BP version 1.1 specification. In this section, problems related to providing support for some business and system exceptions to support Fault Tolerance (FT) are also considered. It also takes care of designing issues such as functional design and technical design. Proposed framework for exception handling in Fig. 4.5 deals with three major components: Reconfiguration Manager (RM), Fault Notifier (FN) and Recovery Manager (REM) to provide fault tolerance in web services. With the help of these three major components, recovery mechanisms such as retry and replace to recover from the failures exhibit web services as FT is part of the proposal. We propose a Fault Prevention (FP) algorithm to ensure high availability and QoS to consumers. In the proposed exception handling framework as shown in Fig. 4.5, SOAP is used as the binding protocol Proposed Fault Prevention (FP) Algorithm The proposed fault prevention (FP) algorithm is presented in Algorithm 4.2. In the Fault Prevention (FP) algorithm, S represents services, T represents time intervals and F represents faults. Here, S i and S j represent root and sub service directories

13 4.2 Framework for Exception Handling in Web Services 69 respectively. Root service directory S i communicates with its sub service directory S j which takes time T k. During service communication when faults occur, it rolls back the service to its previous state otherwise the service will continue execution normally. Suppose, the root directory service S 1 communicates with sub service directory S 2 at time interval t 3. When fault occurs the service will be rolled back to its previous state that is in time interval t 2. Algorithm 4.2 Fault Prevention (FP) Algorithm FP(S,T,F) //S-Service, T-Time, F-Fault if (S i = = S j ) (where i= 0 to n-1 and j = 0 to n) then T = T k (where k = 1 to n) if (F = = F l ) (where l= 1 to n) then rollback; T= T k 1; FP(S,T,F); end if else execute normally; end if Figure 4.5: Framework for Exception Handling in Web Services

14 70 Development of a Reliable SOA Framework In web services, whenever a fault is encountered, the responses of the web services can be categorized into various types of stages [69, 88] such as fault detection, diagnosis, reconfiguration, recovery, repair etc. In the proposed framework of exception handling (Fig. 4.5), usually first the application server is activated. In the case of failure, remaining servers can be used for backup purpose. Here, the web services are also hosted on all the servers, therefore whenever the primary web service fails, then the other web services can provide the desired result. A SOAP based web service communicating with the WebSphere web service application, leads to an interoperability problem. This problem occurs when a web service application uses apache SOAP2.3 stack standards of BP1.1 to communicate with WebSphere web service of another version. The root cause of an interoperability problem is in the WSDL [37,84], in which consumer has SOAP for the endpoint Universal Resource Locator (URL), that means WSDL indicates to the service provider that the consumer was developed to access Apache SOAP Steps for resolving interoperability issue 1. In order to consume services, consumer will send a request to the service provider. For instance, Consumer request (SOAP over HTTP protocol) will be transmitted to primary AppServer. 2. Service Provider (AppServer) reports the error to Reconfiguration Manager. 3. Reconfiguration Manager reconfigures and selects an appropriate web service to continue serving the consumers without breakdown. 4. Service Provider again reports exceptions to Reconfiguration Manager such aswebservicesfault exception which ensures the interoperability problem. 5. Reconfiguration Manager modifies the WSDL document [37, 84] and changes the schema from elementf romdef ault = qualif ied to elementf romdef ault = unqualif ied and maps to UDDI registry [50,118]. Example: Old Schema: <schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace= > Modified Schema: <schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=...

15 4.2 Framework for Exception Handling in Web Services > 6. Now, resume the service. Reconfiguration Manager that runs on AppServer, keeps checking the web service faults reported by the application. Then, it will take an appropriate action based on the type of exception. In this case, when Reconfiguration Manager doesn t get a reply from the active primary web service, then it will choose another web service and map the new address to WSDL document and register it with UDDI registry [50,118]. Thus the consumer can still access the web service with the same URL. As shown in Fig. 4.5, Reconfiguration Manager (RM) is the key component of the proposed architecture. It is responsible for performing following fundamental operations in order to provide fault tolerance in service communication such as: 1. Developing and marking a primary web service. 2. Registering WSDL with the UDDI registry [50, 118]. 3. Continuously checking faults reported by the application. 4. Whenever Reconfiguration Manager gets an exception reported by web service application, then it transmits a request to another web service application to ensure FT (Fault Tolerance) else reconfigures the WSDL document [37, 84] and maps it to a UDDI registry [50,118]. 5. It also replaces services, those are faulty to ensure high FT (Fault Tolerance) Pseudo code for replacing faulty services In order to replace faulty web services, Reconfiguration Manager shown in Fig. 4.5 is used as the key component. The process required to replace faulty services is presented in Algorithm 4.3. Algorithm 4.3 Replacing Faulty Services while (Service == ServiceRegistry) do Customer = WSDL Document; if (d f == 1) then display message( Service is error free ); else display message( Service is error prone ); rollback(); reconfigure();

16 72 Development of a Reliable SOA Framework reinvoke(); end if end while Steps for replacing faulty services 1. Lookup a service from the service registry (UDDI), which returns WSDL documents. Let s assume, it is not returning null, when the while loop in Algorithm 4.3 becomes true. 2. For each service registered with UDDI, calculate the degree of fault using ReconfigurationManager and StateManager. Let s take a range of degree of fault between 0 to 1. If the value of degree of fault is equal to 1, this means web services are free from error. 3. If the value of degree of fault is less than 1 then the service is likely to be error prone. So, roll back it to the previous state of the web service by taking the help of Fault Notifier. It can be made possible by managing state of the web service. 4. Reconfigure and again invoke the web service which is exactly same as the the primary web service. Explanation of the proposed framework using Railway ticket reservation through a travel agency Let us consider the example of a travel agency dealing with railway ticket reservation and other services as shown in Fig The travel agency allows the passenger to book tickets using the online travel agency services. The online services of the travel agency are implemented using web services. Passengers can book trips that includes railway ticket reservation to their desired destination, rent a cab for pick up and drop and hotel reservation. This service is invoked through other services. For instance a passenger wants to travel from Bhubaneswar to Mumbai. The passenger need to find an appropriate train, berth, date of journey and will have to pay for it through online debit card/credit card credential etc. For booking the ticket, passengers need to enter the details such as name, age, gender, berth, etc. using a web browser. Railway reservation system will try to find different combinations of the need of the passenger. The payment service can be invoked to make the payment in order to confirm the ticket. Taking into account the scenario that the passenger has requested for the appropriate train, the railway reservation service discovers the train through the discovery service and responds the request.

17 4.2 Framework for Exception Handling in Web Services 73 Figure 4.6: Travel Agency Services Let s assume discovery service returns four railway reservation services i.e Train- Book1, TrainBook2, TrainBook3, TrainBook4. Similarly, the returned railway reservation service is checked for valid composition with a payment service. Here, while booking a ticket, reservation service calls the payment service to pay in order to confirm the ticket. During this communication, faults may get propagated. Generally these faults are referred to as WebserviceFaults because it might be possible that the payment service may be developed using BP1.0 specification and reservation service may be developed using BP2.0 specification. Hence, version conflict faults may get propagated while communicating with payment service and it misses interoperability feature. The application may fail to invoke payment service in order to confirm a seat for reservation. Considering this fact, the reconfiguration manager re-configures the service and re-invokes the service as shown in Fig Then, the payment service can accept the credential of passenger for booking the ticket and payment can be made in order to confirm successful reservation Implementation Series of request-response experiments were designed and carried out for evaluating the reliability of the web service, like single service without replication, single service with retry or reboot, and a service with spatial replication. We also took into consideration the scenario of retry or failure when the web service is down. The web services were replicated on different machines and the primary web service was chosen by the reconfiguration manager. To implement the proposed work, we have adopted Currency converter example, a free web service available [13]. In order to consume services provided by currency converter web service, we have used Java as the programming language and Glassfish as the application server to deploy the application. Here, currency converter has an operation named conversionrate(-,-), which converts one country s currency

18 74 Development of a Reliable SOA Framework to another country s currency. Sample of XML coding of the communication of currency conversion is as follows: <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:tm=" xmlns:soapenc=" xmlns:mime=" xmlns:tns=" xmlns:soap=" xmlns:s=" xmlns:soap12=" xmlns:http=" targetnamespace=" xmlns:wsdl=" <wsdl:types> <s:schema elementformdefault="qualified" targetnamespace=" <s:element name="conversionrate"> <s:complextype> <s:sequence> <s:element minoccurs="1" maxoccurs="1" name="fromcurrency" type="tns:currency" /> <s:element minoccurs="1" maxoccurs="1" name="tocurrency" type="tns:currency" /> </s:sequence> </s:complextype> </s:element> <s:simpletype name="currency"> <s:restriction base="s:string"> <s:enumeration value="inr" /> <s:enumeration value="all" /> <s:enumeration value="dzd" /> <s:enumeration value="ars" /> <s:enumeration value="awg" /> <s:enumeration value="aud" /> <s:enumeration value="bsd" /> <s:enumeration value="usd" /> </s:restriction> </s:simpletype> <s:element name="conversionrateresponse"> <s:complextype> <s:sequence> <s:element minoccurs="1" maxoccurs="1" name="conversionrateresult" type="s:double" /> </s:sequence> </s:complextype>

19 4.2 Framework for Exception Handling in Web Services 75 </s:element> <s:element name="double" type="s:double" /> </s:schema> </wsdl:types> <wsdl:message name="conversionratesoapin"> <wsdl:part name="parameters" element="tns:conversionrate" /> </wsdl:message> <wsdl:message name="conversionratesoapout"> <wsdl:part name="parameters" element="tns:conversionrateresponse" /> </wsdl:message> <wsdl:message name="conversionratehttpgetin"> <wsdl:part name="fromcurrency" type="s:string" /> <wsdl:part name="tocurrency" type="s:string" /> </wsdl:message> <wsdl:message name="conversionratehttpgetout"> <wsdl:part name="body" element="tns:double" /> </wsdl:message> <wsdl:message name="conversionratehttppostin"> <wsdl:part name="fromcurrency" type="s:string" /> <wsdl:part name="tocurrency" type="s:string" /> </wsdl:message> <wsdl:message name="conversionratehttppostout"> <wsdl:part name="body" element="tns:double" /> </wsdl:message> <wsdl:porttype name="currencyconvertersoap"> <wsdl:operation name="conversionrate"> <wsdl:documentation xmlns:wsdl=" </wsdl:documentation> <wsdl:input message="tns:conversionratesoapin" /> <wsdl:output message="tns:conversionratesoapout" /> </wsdl:operation> </wsdl:porttype> <wsdl:porttype name="currencyconverterhttpget"> <wsdl:operation name="conversionrate"> <wsdl:documentation xmlns:wsdl=" $ </wsdl:documentation> <wsdl:input message="tns:conversionratehttpgetin" /> <wsdl:output message="tns:conversionratehttpgetout" /> </wsdl:operation> </wsdl:porttype> <wsdl:porttype name="currencyconverterhttppost"> <wsdl:operation name="conversionrate"> <wsdl:documentation xmlns:wsdl=" </wsdl:documentation> <wsdl:input message="tns:conversionratehttppostin" /> <wsdl:output message="tns:conversionratehttppostout" />

20 76 Development of a Reliable SOA Framework </wsdl:operation> </wsdl:porttype> <wsdl:binding name="currencyconvertersoap" type="tns:currencyconvertersoap"> <soap:binding transport=" /> <wsdl:operation name="conversionrate"> <soap:operation soapaction=" style="document" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="currencyconvertersoap12" type="tns:currencyconvertersoap"> <soap12:binding transport=" /> <wsdl:operation name="conversionrate"> <soap12:operation soapaction=" style="document" /> <wsdl:input> <soap12:body use="literal" /> </wsdl:input> <wsdl:output> <soap12:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="currencyconverterhttpget" type="tns:currencyconverterhttpget"> < verb="get" /> <wsdl:operation name="conversionrate"> < location="/conversionrate" /> <wsdl:input> < /> </wsdl:input> <wsdl:output> <mime:mimexml part="body" /> </wsdl:output>$ </wsdl:operation> </wsdl:binding> <wsdl:binding name="currencyconverterhttppost" type="tns:currencyconverterhttppost"> < verb="post" />

21 4.2 Framework for Exception Handling in Web Services 77 <wsdl:operation name="conversionrate"> < location="/conversionrate" /> <wsdl:input> <mime:content type="application/x-www-form-urlencoded" /> </wsdl:input> <wsdl:output> <mime:mimexml part="body" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="currencyconverter"> <wsdl:port name="currencyconvertersoap" binding="tns:currencyconvertersoap"> <soap:address location=" /> </wsdl:port> <wsdl:port name="currencyconvertersoap12" binding="tns:currencyconvertersoap12"> <soap12:address location=" /> </wsdl:port> <wsdl:port name="currencyconverterhttpget" binding="tns:currencyconverterhttpget"> < location=" /> </wsdl:port> <wsdl:port name="currencyconverterhttppost" binding="tns:currencyconverterhttppost"> < location=" </wsdl:port> </wsdl:service> </wsdl:definitions> Fig. 4.7 to 4.12 represents the complete Currency converter web-service consumption and development using Java as the programming language, NetBeans as IDE and GlassFish as an application sever to deploy the application. Fig. 4.7 represents the Currency converter WSDL document that describes the services(operations) provided by currency converter service, in order to facilitate consumer to use currency converter service. Fig. 4.8 represents the generated binding classes using currency converter WSDL document that helps to call the web service (currency converter). Fig. 4.9 represents the calling of web service operations conversionrate(-,-). Fig shows the selection of conversion rate from available web service references. Fig represents the Java code for calling conversionrate(-,-) method and code for converting currency from United States

22 78 Development of a Reliable SOA Framework Dollar (USD) to Indian Rupees (INR) and vice versa. Fig represents the process of building and deploying the CurrencyClient on GlassFish application server. Fig represent the responses of converting currency from USD to INR and from INR to USD. Figure 4.7: Currency Converter WSDL document

23 4.2 Framework for Exception Handling in Web Services 79 Figure 4.8: JAX-WS generated classes through WSDL document In the experiments, a number of faults may occur in the web service environment [114, 115], including network, resource and component failures. These faults are injected in the experimental system to evaluate the fault tolerance and reliability of our proposed framework. Our experimental environment is defined by a set of parameters. Table 4.5 shows the parameters of the web service considered in our experiments. We compare five approaches for providing the web services. The details of the experiments are described as follows: Expt1: Single service without retry and restart: The web service is provided by a single server without any replication. No redundancy technique is applied to this Web service. Expt2: Single service with retry: The web service provides the service and the client retries another web service when there is no response from the original web service after time out. This exhibits fault-tolerant check.

24 80 Development of a Reliable SOA Framework Figure 4.9: Calling of Web service operation(conversionrate(-,-)) Expt3: Single service with restart: The web service provides the service and the web service server will reboot when there is no response from the web service.

25 4.2 Framework for Exception Handling in Web Services 81 Figure 4.10: Selecting conversionrate from available web service references Clients will not retry after timeout whenthereis noresponsefrom theservice. Expt4: Spatial replication with fail over: We use a generic spatial replication.

26 82 Development of a Reliable SOA Framework Figure 4.11: CurrencyClient to invoke conversionrate( ) The web service is replicated on different machines and the request is transferred to another machine when the primary web service fails. The replication manager coordinates among the replicas and carries out a fail over in case of a failure. Clients will only submit the request once and will not retry. Expt5: Spatial replication with fail over and retry: This is a hybrid approach. It is similar to Experiment 4 where the web service is replicated on different machines and the request is transferred to another one (fail over) when the primary web service fails. But, the client will retry if there is no response from the web service after time out. The reliability and fault tolerance of proposed framework are tested under various circumstances such as resource problem, network problem and during normal operation as well. Resource problem is created in the framework by increasing loads on the application server (Weblogic) and entry point failure is created in the framework by restarting the application server. The applicability and fault tolerance of web services are tested under different scenarios as follows: Normal operation Resource problem by increasing the load of the server.

27 4.2 Framework for Exception Handling in Web Services 83 Figure 4.12: Building consumer (CurrencyClient) application Entry point failure by rebooting the application server again and again and inserting a number of faults by different fault injection techniques. Resource Problem/ resource unavailability: It could arise due to various reasons such as application severs slowdown and service has reached it maximum capacity of its execution at a time, increasing loads on the application server (Weblogic) and entry point failure created in the framework by restarting the application server. Network Problem: In the fault injection, web service fault injection technique is applied. Web service fault injection technique is a modification of Network Level Fault Injection. Web service fault injection technique differs from standard Network Level Fault Injection techniques in that the fault injector decodes the SOAP message and injects faults into individual RPC call parameters rather than randomly corrupting a message. This enables API-level parameter value modification to be performed in a non-invasive way as well as using the standard Network Level Fault injection. The web services were executed for 720 hours generating a total of 720x60 requests/hr = requests from the client. A single failure is counted as one when the system cannot reply to the client. This situation appears in our Expt1 single service without retry and restart, Expt3

28 84 Development of a Reliable SOA Framework Figure 4.13: Web service conversion Response from USD to INR and INR to USD single service with restart and Expt4 spatial replication with fail over. In Expt1 we got 4928 normal operation failures, 6130 failures due to resource problems and 5324 network level failures. Similarly, we have also got failures for Expt3 and Expt4 which is described in Table 4.5. For Expt2 single service with retry and Expt5 spatial replication with fail over and retry, a single failure is counted when the client retries five times and still cannot get a result. In Expt2 we got 2210 normal operation failures, 2327 failures due to resource problems and 2289 network level failures. Similarly, we have also got failures for Expt5 which is described in Table 4.5. A summary of the results is shown in Table 4.5. Fig to Fig depict the number of failures as the time increases. Currently, our proposed algorithm works for moderate size of SOA based applications. We have not tested our algorithms for large/very large SOA based applications. But, we hope all our proposed algorithms will work for large / very large SOA based applications. However, the space and time requirements will be very high.

29 4.2 Framework for Exception Handling in Web Services 85 Table 4.5: Experimental Results Experiments over 720 hours (43200 reqs) Single Service without retry and restart Single Service with retry Single Service with restart Spatial replication with failover Spatial replication with failover and retry No. of Failures Observed Due to Normal Due to Due to Network Opera- Resource Level Faults tion Problems Figure 4.14: Number of failures when the server Operates Normally Analysis The experiments barely indicate linearly increase of the number of failures in all categories. Therefore, the ratio of the number of failures to the amount of time is almost constant for each type of experiment and each type of failure. The ratio a(number of failures divided by time t) is given for each type of experiments and each type of failures. So the communicative number of failures f at time t can be

30 86 Development of a Reliable SOA Framework Figure 4.15: Number of failures under Resource Problem Figure 4.16: Number of failures under Network Level Faults approximated by f = at. When there is no redundancy techniques applied on the web service system, the failure rate of the system is the highest. Consequently, we try to improve the reliability of the web service in two different ways, including spatial redundancy with replication and temporal redundancy with retry or reboot. When the server operates normally the obtained failure rate is shown in Fig Resource Problem: Under different situations, our approach improves the availability of the system differently. When the system is under resource problem or

31 4.2 Framework for Exception Handling in Web Services 87 constraints, the experiment shows that the temporal redundancy helps to improve the availability of the system. For the web service with retry, the percentage of failures of the system (number of failed requests/total number of requests) is reduced from 11.97% to 4.93%. This shows that the temporal redundancy with retry can significantly improve the availability of the Web service. When there is a failure occurrence in the Web service, on the average, the clients need to retry twice to get the response from the Web service. Another temporal redundancy is web service with reboot. From the experimental result, it is found that the failure rate of the system is also reduced: from 11.97% to 6.44%. The improvement is good, but not as substantial as the temporal redundancy with retry. It is due to the fact that when the Web service cannot be provided, the server will take time to reboot. Spatial redundancy is applied in the system, in our proposed approach. The availability of the system is improved even more significantly. The failure rate of the system is reduced from 11.97% to 3.56%. The Web service performs fail over when the web service cannot respond. The replication manager keeps checking the availability of the Web services. If the primary service fails, the replication manager selects another Web service to provide the service. The replication manager sends a message to the web server to check the availability in every 5 ms. It shortens the potential downtime of the Web service, thus the failure rate is reduced. In the experiment, on the average, the reconfiguration manager detects that there are around 600 failures in the Web services and performs the fail overs accordingly. To further improve the reliability of the web service, both spatial and temporal redundancy are applied in system in Experiment 5 i.e. Spatial replication with fail over andretry. Thefailurerateisreducedfrom11.97% to 2.59%. Intheexperiment, the web service is replicated on five different machines and the clients retry if they cannot get response correctly from the service. It is demonstrated that this setting results in the lowest failure rate as shown in Fig When the system is under network level faults, the temporal redundancy reduces the failure rate of the system from 12.32% to 5.12% as shown in Fig When there are faults injected into the SOAP message, the system cannot process the request correctly, which causes error in the system. However, with temporal redundancy, the clients can resubmit the result to the system when there is a fault injected into the previous message, thus the failure rate of the system is reduced.