Monitoring Web Services with the J-OCM System Lechoslaw Trebacz1, Włodzimierz Funika2, Piotr Handzlik3, Marcin Smętek2 1 Dept. Computer Methods in Metallurgy, AGH, al. Mickiewicza 30, 30-059 Krakow, Poland 2 Institute of Computer Science, AGH, al. Mickiewicza 30, 30-059 Krakow, Poland 3 Dept. Phys. Chemistry and Electrochemistry, AGH, al. Mickiewicza 30, 30-059 Krakow, Poland [email protected], [email protected], {funika,smetek}@uci.agh.edu.pl phone: (+48 12) 617 44 66, fax:(+48 12) 633 80 54

Abstract The monitoring of an application is aimed at observing, analyzing and manipulating the execution of an application, which provides information about different aspects of its life: threads, CPU usage, memory usage, about methods and classes. A particular case is the monitoring of distributed applications where an additional issue is the performance analysis of the infrastructure where the application is running. The paper presents an approach to monitoring Web Services based on an extension to the on-line monitoring interface specification that defines relationships between a monitoring system and on-line tools. The extension aims at defining a standard for an open interface that supports on-line software development tools. The paper also presents implementation ideas on building a monitoring infrastructure for application based on web services.

1 Introduction Tools supporting parallel and distributed programming play an important role in the development of applications. Our approach to build a universal monitoring system is based on OMIS [1], its extension J-OMIS [2] and the OCM [4]. The OMIS project defines a standardized interface between tools and the monitoring system. OMIS is not restricted to a single kind of tool, especially it supports tools oriented towards debugging as well as performance analysis and resource management. Originally, OMIS has been designed to support parallel systems, and its reference implementation, the monitoring system OCM has been targeted towards PVM and MPI applications. J-OCM [6] is an extension to the OCM, which is used to monitor distributed Java applications. The paper presents a monitoring platform for distributed applications which are oriented towards the use of Web Services (WS). We describe the building of a monitoring platform based on J-OMIS between a monitoring system organized as middleware and the tools that use the facilities provided by the monitoring middleware. Our idea to monitor WS-based applications focuses on observation and analysis of SOAP messages (data) exchanged with a WS (requests and responses). The main goal of this paper is to present an approach how to extend the J-OMIS

specification for WS-based applications and the implementation concepts for building a monitoring infrastructure based on this specification. Our extension is intended to: 1. provide information about running WS and their number, 2. provide information about main stages during WS life-cycle, for example: a moment of receiving request from client, the moments of starting, particular services, time of SOAP message parsing etc. 3. make accessible all information about any WS, 4. make it possible to check, which stages of WS life-cycle consume most CPU time, to analyze performance of this application, 5. provide information about errors during running WS. The paper is organized as follows: Section 2 gives a short overview of WS features, while Section 3 presents a software platform underlying the building of WS. Section 4 introduces the idea of WS monitoring, followed by its architectural aspects in Section 5. In Section 6 we are summing up the research carried out so far and show our plans for further research.

2 Web Services WS represent information resources or business processes that can be accessed over the Web by another application through standard Internet protocols. A WS is a service that is identified by a URI and can be accessed by applications via Web protocols in accordance with the contract that describes its programmatic interface. A WS is programmable application logic accessible using standard Internet protocols. Like components, WS represent functionality that can be easily reused without knowing how the service is implemented. Unlike current component technologies which are accessed via proprietary protocols, WS are accessed via ubiquitous Web protocols (e.g. HTTP) using universally-accepted data formats (ex: XML). The Web Services architecture takes all the best features of SOA and combines it with the Web. The Web supports universal communication using loosely coupled connections. Web protocols are completely vendor-, platform-, and language-independent. The resulting effect is an architecture that eliminates the usual constraints of DCOM, CORBA, or RMI. Web Services support web-based access, easy integration, and service reusability. WS are implemented using a core set of Internet middleware technologies including: • XML, which provides a platform-neutral mechanism to represent data, • SOAP, which defines the data communication protocol for Web services, • WSDL, which describes a Web Service, • UDDI, which provides a means to advertise and discover Web services. In Fig. 1 we show how these technologies relate to one another. When a service provider wants to make the service available to service consumers, the provider describes the service using WSDL and registers the service in a UDDI registry. The UDDI registry will then maintain pointers to the WSDL description and to the service. When a service consumer wants to use a service, he/she queries the UDDI registry to find a service that matches his needs and obtains the WSDL description of

the service, as well as the access point of the service. The service consumer uses the WSDL description to construct a SOAP message with which it is possible to communicate with the service.

Points to Description

UDDI Registry

WSDL

Points to Service Describes Service Finds Service

Service Client

SOAP

Web Service

Fig 1: Web services technologies

3 Software platform To build WS, we use Jakarta Tomcat and Axis (the Apache eXtensible Interaction System). Axis is an open-source product from the Apache Software Foundation, which contains tools for writing client Java programs that use WS and tools for deploying Java programs as WS. Axis provides transparent access to web services for Java programmers. This allows Java programmers to focus on the business logic of their applications rather than worry about low-level network protocols (like SOAP) in order to use a WS [3]. Axis is essentially a SOAP engine - a framework for constructing SOAP processors such as clients, servers, gateways, etc. It includes: • a simple stand-alone server • a server which plugs into servlet engines such as Tomcat • extensive support for the Web Service Description Language (WSDL) • emitter tooling that generates Java classes from WSDL • some sample programs • a tool for monitoring TCP/IP packets. Axis [5] comprises: 1 Axis engines which:

2

3

4

5

– coordinate message processing by invoking a series of handlers – run on server and optionally on client Handlers which: – operate on request and response messages – can examine a message and modify it before passing it on – can invoke software outside Axis – are used for authentication, compression, encryption, logging, message transformation, etc. Chains which are: – collections of handlers that are executed in a specified order, while – a chain is itself handler, allowing chains to contain other chains Provider which – points in the chain where handlers switch from processing the request to processing the response – invokes web service operation Transports which handle: – message protocol conversions – requests from client to Axis Engine (for example, HTTPTransport) – responses from Axis Engine to client

Client

Transport listener

transport request chain

global request chain

web service specific chain request handlers

Axis engine (AxisServer)

provider response handlers

transport response chain

global response chain web services

Fig 2: Architecture of AXIS

4 Monitoring Web Services Monitoring tools can be classified into two categories: on-line and off-line tools. The on-line tools run concurrently with the application, thus a user can interactively observe and influence the state of the application. In the case of off-line tools, information on the application’s execution is being stored on disk, usually as a trace

file. After the application is finished, a tool uses the data gathered in the trace file for analysis activities. In our system which is an on-line tool, for monitoring web services we used dynamic instrumentation of Axis class and JVM Tool Interface, to obtain information about JVM and running applications. The idea of software instrumentation is to insert additional code carrying out monitoring tasks at appropriate positions. Software monitoring requires instrumentation of the program's source code, the system libraries etc. Application instrumentation covers all mechanisms that instrument the application itself. Sourcecode instrumentation inserts a piece of monitoring code at appropriate positions within the application sources. This instrumentation is quite simple, but the source code has to be available and recompiled. Another instrumentation technique defers inserting a monitoring code until the target application is in execution. In this instrumentation model, the users associate simple operations with insertion points, and provide additional predicates to control the execution of the primitives. The advantage of this instrumentation approach includes its ability to dynamically control the insertion points and its efficiency in instrumentation execution because of operating at the binary code level. However, dynamicity is not easily supported because instrumentation takes place at the binary code level. Runtime environment instrumentation is the second approach which modifies components of runtime environment instead of the application. It is mostly implemented by instrumented libraries linked with the application or the operating system. Owing to the dynamic instrumentation of Axis classes it is possible to observe the following operations of WS: • Receive a request via SOAP • Parse XML contained within the SOAP request • Execute the functionality specified by the XML • Format the results in XML • Transmit the reply via SOAP. Our system will obtain the duration of particular operations, e.g. the time spent in the parsing of SOAP message, CPU and wall-clock time, the whole activity time of particular WS etc. The important element which will be monitored is the SOAP message and its content. It will be done by an event-driven system. At the start and the end of each earlier described stages of working WS, there are placed sensors which generate events and convey them to the application monitor (part of our monitoring system). The sensors are dynamically placed into class images of Axis classes (dynamic instrumentation).

5 Architecture our system To ensure that an extension to J-OCM correctly works, there must be a well defined interface for extensions. The specification of this interface is covering: • the interface of the functions implementing manipulation, information and event services, • the interface of token conversion functions,

• the interface used to register new services and token types. Services in an extension can call an OMIS request to invoke other services, just in the same way as a tool does. The monitoring system (Fig. 3) is intended to comprise three kinds of components: • application monitor (AM) - agent, • node's local monitor (LM), • service monitor (SM). Application Monitor is embedded into Axis which manages SOAP messages. It is used to perform monitoring activities in the context of the application, with JVM Tool Interface for monitoring JVM. A node's LM is created on each node, where are Web Services to be monitored. LM receives requests from Service Monitor and transfers this request to agent. Local Monitor sends a reply from AM to SM. SM resides permanently and exposes the monitoring services to tools. Low-level interactions with the JVM are a critical part of the monitoring system. The component responsible for this activity has to provide the functionality that allows to realize the services defined in the interface specification. One of the possible approaches is using the interfaces which enable a tool to access the JVM. They are used to obtain requests from a tool, handle them and forward to a relevant mechanism within the JVM. The results of the request are sent back to the tool. The requests may concern obtaining information on the application, performing actions on the application, or events whose occurrence triggers relevant actions.

Tool

service monitor

node's local monitor

node's local monitor

JVM AM

JVM AM

JVM AM

JVM AM

web services AXIS

web services AXIS

web services AXIS

web services AXIS

JVM

JVM

Fig 3: Architecture of our monitoring system

Our system provides two types of metrics: a) static - oriented towards WS, intended for the observation and analysis of SOAP messages sent to/received from a WS (requests and responses): • number of Web Services on a node, • request time, response time, SOAP create/parsing time, computing time • information about WS, • information about operations of WS. b) dynamic - oriented towards the applications which use WS: • function call, service invocation • number of errors (missing operations, incorrect code of WS). The main emphasis is put on the analysis of SOAP communication, e.g. SOAP create/parsing time. It can be done by dynamic instrumentation into Axis classes and by using JVMTI. Identification of request/reply between elements of system. Each service of our system is addressed by a unique service name, i.e. a unique identifier string passed to the tool/monitor-interface, which is mapped to the implementing function(s) using a mapping data structure built during initialization of the monitoring system. Likewise, the type of a token is indicated by a string prefix that can be mapped to the functions implementing token conversion using a similar data structure.

6 Conclusions Although there are a number of tools to monitor distributed application, only few of them can monitor WS based applications. Our idea and its implementation is intended to extend the functionality of J-OCM by WS monitoring. Commands of this extension comply to the same syntax as commands of J-OCM, our system is easy to use for the users of systems compliant with OMIS. For monitoring WS, we exploited dynamic instrumentation of Axis classes. As a result, we keep to a minimum an overhead to the monitored application performance. By monitoring the stages of WS, we can measure the efficiency of applications based on WS. This extension will be used by an SCIRun/TAU-based tool to visualize the performance of web services. Acknowledgements. This research was partially supported by the KBN grant 4T11C 032 23.

References 1. Ludwig T., Wismueller R., Sunderam V., Bode A.: OMIS – Online Monitoring Interface Specification (Version 2.0). Shaker Verlag, Aachen, vol. 9, LRRTUM Research Report Series, 1997 2. M. Bubak, W. Funika, M.Smetek, Z. Kilianski, and R. Wismüller: Architecture of Monitoring System for Distributed Java Applications. In: Dongarra, J., Laforenza, D., Orlando, S. (Eds.), Proc. Euro PVM/MPI 2003, Venice, Italy, Sept. 29 - Oct. 2 2003, LNCS 2840, pp. 447-454, Springer, 2003 3. http://ws.apache.org/axis/java/architecture-guide.html

4. R. Wismüller, J. Trinitis, T. Ludwig, A universal infrastructure for the run-time monitoring of parallel and distributed applications, in: Proceedings of the Conference on Parallel Processing (Euro-Par’98), Southampton, UK, September 1998, Lecture Notes in Computer Science, vol. 1470, Springer, Berlin, pp. 173–180. 5. Mark Volkmann, Axis – an open source web service toolkit for Java http://www.ociweb.com/javasig/knowledgebase/2002Sep/Axis.pdf 6. Funika, W., Bubak, M., Smętek, M., Monitoring System for Distributed Java Applications, in: Bubak, M., van Albada, G. D., Sloot, P. M. A., Dongarra, J. J. (Eds.), Computational Science - ICCS 2004. 4th International Conference, Kraków, Poland, June 2004, LNCS, no. 3038, vol. III, Springer, 2004, pp. 472-479.