Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Client quality reporting for J2EE Web services

Use SOAP attachments to report client response times for Web services

By Brian Connolly, JavaWorld.com, 09/19/03

Web services are fast becoming the preferred architecture for implementing client-server systems. The advantage of Web services is that a business can formally define a set of services, and then generate the entire client and server codebase for communications, thus simplifying new client access to legacy Web resources.

However, while Web services ease the building of client-server systems, monitoring service quality is a significant problem. Consider a client application that submits a transaction on a user's behalf. A business transaction usually involves several Web service calls: an initial call to submit a work item, subsequent calls to check for completion, and a final call to get the result. Each call is a distinct HTTP/SOAP (Simple Object Access Protocol) exchange. Put yourself in the position of an IT department responsible for monitoring server load and forecasting future needs. The fundamental question you must answer is, "How well am I serving my clients now, and what will I need to serve them in the future?"

Answering this question is difficult if you have only HTTP logs. Clients care about transactions, but since each transaction consists of several HTTP requests, the best you can do to estimate service quality is to develop custom data-mining software that cursors through HTTP logs and builds a model of user transactions. Even so, the information you have is still limited because it can't reflect network transport or client application overhead.

This article's key idea is that transaction service quality is best measured by the client. The approach adopted here allows the client to record actual transaction response times. A client application uploads response time reports to the server by appending them to the next up-bound transaction request. The server strips off these attachments and queues them for storage and offline analysis.

Architecture

One objective of the client-based metrics-recording architecture is that the recording infrastructure must be lightweight, both in terms of runtime overhead and the ease of adding it to an existing implementation. We also want an architecture that places no constraints on the services offered—we'd like to be able to add it to an existing client-server system that uses Web services as easily as possible.

Another objective of our architecture is that we don't want to make the business application itself less reliable. We'll be introducing some new, lightweight steps into the application process workflow. We must ensure any failures in these new steps are handled because we don't want a business transaction to fail just because we couldn't gather metrics on it.

The following diagram shows a typical J2EE (Java 2 Platform, Enterprise Edition) Web service client-server application. Typical components appear in black; the new components that we will add for metrics gathering appear in red.

J2EE Web services: Metrics-gathering architecture

The "J2EE Application Server" region represents existing server resources. These are the Enterprise JavaBeans (EJB) components that process client requests. A tool automatically generates the Web services package. The EJB components and the associated Web services module deploy to a J2EE server as a J2EE application. When the application deploys, a client can determine available services by invoking the application WSDL (Web Services Description Language) service, which provides a formal definition of the services offered by the application.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.