A Web Service Based-Architecture for Detecting Faults in Web Services. A.Benharref, R. Glitho, R. Dssouli Concordia University 1455 De Maisonneuve Bld. W. Montreal, Quebec H3G 1M8 Canada
[email protected], {glitho, dssouli}@ciise.concordia.ca Abstract Web services are emerging as the standard paradigm for program-to-program interactions on Internet. They are gaining more and more momentum and their management is becoming critical. Fault management is one of the most challenging areas of network and service management. It includes fault detection, isolation and repair. This paper proposes a Web service based – architecture for detecting faults in Web services. The architecture is rooted in passive testing and its potential is demonstrated by a case study where we use it to detect faults in a Web service for conferencing. Passive testing consists of observing and analyzing the messages the component under test exchanges with its environment. The passive testers of our architecture are designed as Web services. Related work is discussed. The architecture is presented, and its potential is demonstrated. Keywords Web services, passive testing, fault management
1.
Introduction
Web services offer a set of mechanisms for program-to-program interactions over the Internet. Managing them is critical because they are being used in a wide range of applications. Some examples of applications are telecommunications, geographical information systems and digital imagery. Fault, configuration, accounting, performance and security are the main functional areas of network and service management. Fault management includes fault detection, localization and repair. Detecting faults in networks and systems is no easy task. A widely used mechanism is testing. Testing can be passive or active. Active testing is based on the generation and the application of specific test cases while passive testers just observe the interaction between a tested (observed) system and its clients. The observation is done by entities known as observers.
0-7803-9088-1/05/$20.00 (C) 2005 IEEE
Today, the management of Web services is highly platform dependent. Each platform comes with its own testing tools and these are mainly active testers. This makes testing a vendor-dependent activity. It also makes testing of already deployed web services an activity where third parties are not allowed. An open and multi-player testing environment is of paramount importance for the successful deployment of Web services. This will enable third parties including Web service requestors and third party certification entities to verify the correctness of the features claimed by Web service providers. This paper proposes a novel architecture for detecting faults in Web services. The architecture is rooted in passive testing. The observers are designed as Web services. This makes them platform independent and opens the door to testing of deployed Web services by third parties. The potential is demonstrated by a case study where we test a deployed conferencing Web service. In section 2, we discuss related work. The third section introduces the architecture. Then a case study is briefly discussed. A conclusion is given in the last section.
2. Background Due to the young age of the concept, most works on web services focus on their development and deployment. Management of web services, and in particular fault management, is not yet a well-defined area. Researchers are still trying to enumerate the requirements and define the approaches. The approaches can be divided into two main groups: those based on active testing[1], and those requiring the web service (architecture) to support a management interface ([2], [3], [4], [5]). These solutions assume that a web service will participate in its management by providing specific interfaces or are based on active testers. The architecture becomes more complex if it has to support management aspects in addition to its functionalities. The performance is also degraded due to these additional features. Moreover, the web service provider has to implement also the needed interfaces and APIs to support management. When the tester is an active tester, appropriate test cases have to be carefully generated, executed, and the results analyzed. Our proposition for fault management is based on model-based passive testing ([6], [7], [8], [9]). The observer can be either on-line or off-line: an on-line observer checks in real time the exchanged input/output while an off-line observer uses the log files generated by the component itself. In this paper, we focus on on-line observers due to their capability of detecting errors somehow quickly.
3. Components and Interfaces The main components of our fault detection architecture are the observers. Since we are dealing with web services, we propose to design each observer itself as a web service. Two main reasons justify this decision. First of all, the observer must be available for service providers, their clients and third parties depending on who is interested in observation. A service provider can
0-7803-9088-1/05/$20.00 (C) 2005 IEEE
use the observer to make sure that the web service she/he is offering is operating correctly. The client can make use of the observer in order to verify that the service she/he is using is operating as agreed on with the service provider. Furthermore, a third party mandated by the client and/or the server, can invoke the observer to provide an independent certification stating if the web service is correct or not. In addition, no additional skills are required since invoking the observer follows almost the same steps as when invoking another web service. In addition to the on-line detection capability, the passive property of the tester is the major design key in our architecture. In fact, a couple of points have been considered while designing our tester. These points include: online detection (detect a fault as quick as possible), minimization of the induced load (less load for testing), and transparency to components (observation should not affect system components). The testing procedure within our architecture can be performed following the steps listed hereafter and illustrated in Figure 1. The 1. Publish and 2. Find operations are the same as within basic web services. In Figure 1, a dynamic publication using a UDDI registry is considered. 3. Invoke: The observer is invoked by a manager. The manager can be the client, the manager of the web service or even an authorized third party. In all cases, the manager should provide specific information when invoking the observer. This information includes the location of the service to be observed, its specification (model), when to start observation, when to end observation, etc. 4. Observe: This is the main action in the monitoring of web services. The observation can start for new service invocations or for service invocations already in progress. The fault detection procedure is the same but the homing procedure is longer for the latter case. 5. Report: When the observer stops observation (fault found or observation period expired), it returns the result to the manager. Based on these results, fault location, isolation and correction processes are initiated if a fault occurred. 5.Report 3.Invoke
Observer
4.Observe
1.Publish
Service
Manager 2.Find
Registry
Figure 1 Observer Invocation. One of the design keys to be inspected is how to provide the observer with all the exchanged input/output sequences without affecting the performance of the service. The mechanism to be used depends basically on who is interested in the observation: the client, the service manager or a third party; and also on the location of the client, the service and the observer. Possible solutions include multicast, sniffer-like dispatchers, SNMP agents/managers, participation of the service and/or the client, and the use of mobile agent
0-7803-9088-1/05/$20.00 (C) 2005 IEEE
4. Implementation: Call Control To illustrate the applicability of our architecture, a web service [10] exposing some of the functionalities of Parlay/Call Control [11], has been tested (i.e. observed) using FSM models. This web service provides mainly the conferencing parts of the parlay specification. The observer was able to detect all INPUT/OUTPUT faults. But due to the limitations of the FSM model, the observer was unable to detect deadlocks.
5. Conclusion As web services technology emerges, its management becomes an important issue. Management includes many aspects from fault management to security management. In this paper, we presented an architecture for fault detection of web services through web services based on passive testing and illustrated its applicability with a case study. The main contribution concerns the design of an observer that can be invoked by interested requesters when developed and published as a web service.
References [1] http://www.parasoft.com [2] Web Services Endpoint Management Architecture Requirements Draft, http://www.w3.org [3] J. A. Farrel and H. Kreger, “Web Services Management Approaches”. IBM Systems Journal, 41(2), 2002, pp 212-227. [4] F. Casati, E. Shan, U. Dayal, M. Shan, “Business-Oriented Management of Web Services”, Communication of the ACM, Vol.46, No.10, October 2003, pp55-60. [5] HP Openview Web Services Management, Business White Paper, Hewlett Packard, November 2002 [6] D. Lee, A. N. Netravali, K. K. Sabani, B. Sugla, A. John, “Passive Testing and Applications to Network Management” Proceedings of IEEE International Conference on Network Protocols, October 1997, pp 113-122 [7] R.E. Miller, “Passive Testing of Networks using a CFSM Specification”, IEEE International Performance Computing and Communications Conference, February 1998, pp 111-116. [8] R.E. Miller, “A Formal Approach for Passive Testing of Protocol Data Portions”, 10th IEEE International Conference on Network Protocols, November 2002, pp 122-131,. [9] A.R. Cavalli, C. Gervy, S. Prokopenko, “New Approaches for Passive Testing using an Extended Finite State Machine Specification”, Information and Software Technology. Vol. 45, No. 15. September 2003. [10] K. Hassan, R. Glitho, F. Khendek. “Web Services for Call Control in 3G Networks : A Parlay Based Implementation”, 9th IEEE International Conference on Network Protocols. November 2002, pp 122-131. [11] Parlay 4.1 Specification, http://www.parlay.org
0-7803-9088-1/05/$20.00 (C) 2005 IEEE
