Web Service Diagnoser Model for managing faults in web services

K. Jayashree , Sheila Anand

Web services are self describing, self contained and loosely coupled mechanism for program to program interaction over the Internet [1]. Web service technology is being increasingly used in many commercial applications like online reservation, auction, stock trading and banking. Web services are based on eXtensible Markup Language (XML) standards and are supported by standard protocols like Simple Object Access Protocol (SOAP) for message exchange, Web Services Description Language (WSDL) for interface description and Universal Description Discovery and Integration (UDDI) for service discovery [2,3]. It facilitates the delivery of business applications as web services are accessible to anyone, anytime, at any location and using any platform.

Web Service Management System (WSMS) is a comprehensive framework for managing web service lifecycle which covers the development, deployment, publishing, discovery, composition, monitoring and optimizing access to web services [4]. As web services are being extensively deployed for business applications, the reliability of the services provided becomes an important criterion to enable the usage of such services. Continuous monitoring and fault management of web services are essential to ensure uninterrupted and continuous availability of web services. Traditional fault management tools cannot automatically monitor, analyze, and resolve faults in web services. As web services are distributed in nature, it is hard to trace the flow of transactions when a large number of services, supplier and technologies collaborate together to perform an activity [5]. Thus monitoring of web services becomes more difficult when compared to monitoring a centralized application. Tools, methodologies and techniques need to be specially developed to support and automate the fault management efforts [6].

This paper describes WISDOM (Web Service Diagnoser Model) a generic architecture for monitoring and detecting faults during run-time execution of web services. The rest of the paper is organized as follows. Section 2 discusses the related work and Section 3 presents WISDOM, the proposed architecture for web services run-time fault detection. In Section 4, the implementation and experimental results for a sample web service application are discussed. Section 5 presents the conclusion and future work.

Monitoring is used as a verification technique to detect run-time errors. Run-time monitoring has been extensively studied in different areas of computer science, such as distributed systems, requirement engineering, programming languages, and aspect oriented development [7,8]. Beth A. Schroeder et al. [9] have stated that monitoring can increase application dependability. They have described monitoring systems as external observers that gather information about the functioning of the applications. Such information can then be used for correctness checking, performance enhancement, security and dependability.

On-line monitoring systems not only gather information during execution of the application but also process the information to respond in a timely manner to application events to provide increased robustness, adaptability and fault tolerance. Delgado et al. [10] have presented a taxonomy of run-time software fault-monitoring approaches. Fault has been described as an incorrect state during the execution of the software that can lead to a software failure. It has been described as a deviation from the required or intended behavior of the system. The taxonomy presents the classification of elements in a monitoring system; a specification language to define the monitoring properties, an event handler to capture and communicate monitoring results and the monitoring mechanism to handle the faults and oversee the programming execution. The issues addressed have been taken into consideration while designing the proposed model for run-time monitoring of the behavior of web services during execution.

There has been considerable work related to development and deployment of web services. Management of web services and particularly fault management is not yet a well-defined area and require considerable research focus. Fault management includes fault detection, fault isolation and fault repair. Robinson [11] has proposed the integration of software requirements analysis with execution monitoring to address web service monitoring. He has proposed the use of individual monitor servers at each site to track web service traffic. A global integrative monitor is to be used to control the individual monitors and process the received information to provide real-time alerts. Requirements are expressed using Knowledge Acquisition in autOmated Specification (KAOS) which does not provide enough information on monitoring and the transformation from specification to monitoring code has not been clearly addressed.

It can be summarized from the above discussions that the earlier work has primarily been with respect to detecting errors in input and output of web services. In the proposed approach, fault detection pertaining to publishing, discovery, binding and execution of web services have been considered. Execution fault detection covers errors in the request given to web services and also errors in the reply from the web services. In addition, different types of SOAP processing errors have also been included in the fault detection process. The proposed model uses policies to express the intended behavior of web services. Policies provide a flexible approach to enforce and communicate various types of rules and requirements of the web services.

Service-Oriented Architecture (SOA) consists of the three key components, namely, Service Consumer (SC), Service Registry ( SR), and Service Provider (SP) which interact with each other to publish, discover and execute web services. Service providers create and deploy their web services. Service providers publish their web service in service registries which act as repository of web services. Service users look up these directories to obtain details of available web services. The users then bind and execute their selected web service deployed by the service provider.

Web services are loosely coupled and dynamic in nature. Web services need to connect different servers and clients systems that run on different hardware and software platforms. To ensure availability and reliability of these web services, it is necessary to ensure that these services behave correctly at run-time. Faults can occur during all or any of the interactions between the key players [16]. Monitoring the web service interactions at run-time would enable faults to be detected and handled appropriately to avoid system failures. WISDOM has been proposed as a generic architecture for run-time monitoring of web service interactions and handling fault detection. An extended version of WISDOM (Web Service Diagnoser Model) [6], the proposed monitoring architecture is given in Fig. 1.

A key aspect of web service monitoring is the interception of messages exchanged between the key players, namely, service providers, service registries and service users. Different methods are available to intercept such messages, namely, wrappers, network proxies and handlers [17].

Software wrappers are used to encapsulate the monitored service and such wrappers can be used for a variety of purposes. For on-line monitoring, the wrappers are primarily used to intercept the messages sent to the actual service. The wrapper is used to process the service request–replies and monitor for errors. To be transparent to the user, the wrapper interface has to match the interface of the service being monitored and a separate wrapper has to be designed for every service being monitored. In proxy based interception, network nodes are designated as proxies to handle the message exchanges. The transport protocol has to support the interception of the messages and the proxy server is used to process and monitor the request–replies.

In the proposed monitoring architecture, handlers have been used to intercept the message exchanges. SOAP protocol is widely used as the messaging framework for web service interchanges and SOAP provides support for the use of handlers to intercept the web service message exchanges. Handlers have been implemented to capture the request and replies between the user and web services. The handlers have been designed to delegate the validation of such messages to independent Monitoring Components (MCs) located in the service registries and service providers.

Faulty behavior can be defined as deviations or inconsistencies with respect to the specified behavior of web services [18]. Policies are proposed to describe the intended behavior of web services. Policies support standard assertions and provide a simple method to express the capabilities, requirements and characteristics of web services. Web services are frequently modified to suit the changing needs of the users. Policies make it easy to make necessary changes in the specifications of web services and facilitate its dynamic update. The interaction constraints would need to be specified by the service provider for the correct execution of their web services. Policies can also be used to define interaction constraints with respect to publishing and discovery of web services. WS-Policy [19], a web service standard, is proposed for expressing the specifications of the web services. WS-Policy is a W3C recommendation that provides a general purpose model to describe and communicate the policies of web services. The capabilities and constraints are expressed as a set of specifications using XML syntax.

MCs are the individual components that monitor the local web service interactions. An MC is implemented in each service registry that provides the directory for listing the web services of service providers. MCs are also located in each service provider where the web services are deployed. Fault Diagnoser (FD) is the common independent external entity that is used to coordinate the individual monitoring components. FD acts as the repository of web service policies and provides an interface for service providers to create and maintain their web service policies. Changes in web services would require modifications in their corresponding policies. FD provides a common interface for easy update of the policy changes. Service provider may choose to list their web service with multiple service registries. However, the policy needs to be defined only once for a web service and can be accessed by multiple MCs located in these service registries.

The MCs in service registry and service providers do not maintain these policies but access FD to obtain the policy of the web services being monitored. This would enable them to always access the latest updated or current policies. MCs would use the policy information to verify if the service run-time interactions are in conformance to the constraints specified in the policies. MCs located in the service registries analyze the web service publishing requests of service providers for faulty behavior. It also manages fault handling of web service search and discovery requests of users. MC located in each service provider would obtain the policy information from FD to detect errors that occur during binding and execution of the web services.

A local cache has been proposed to maintain details of web service policies recently accessed by the MCs. MC would first check the local cache for the policy information. If the information is available then it would proceed with verification and fault detection. Otherwise, it would send a request to the FD giving the web service details. FD would retrieve the policy details from the stored policy database and return the relevant policy information. The interaction between the monitoring components and the fault diagnoser is depicted as a sequence diagram is given in Fig. 2.

As seen from Fig. 2, MCs also communicate the usage and fault details of web services to FD, which maintains these statistics in separate databases. If a web service policy has changed, FD would alert the MCs which maintain the policy in their local cache, to request for the current policy information. As future work, it is proposed to develop an analyzer component which would use the fault and web service usage data to evaluate the performance and reliability of the web services.