Java EE Web Service client Quality report (i)

Profile

This article implements a common structure that records the number of client responses to Java EE (JAVA2 Platform Enterprise) Web services. The number of responses recorded is the actual number of client responses, so they actually reflect the user's perception of the quality of service. The sample is built using sun one (open Web Environment) application server and IDE, but this method is very common and can be easily extended to other Java EE implementations.

Web services are rapidly becoming the preferred architecture for implementing client-server systems. The advantage is that an enterprise can formally define a set of services, and then generate a complete client and server code base for communication, simplifying new client access to legitimate Web resources.

However, while WEB services simplify the establishment of client-server systems, it becomes important to monitor service quality. Suppose there is a client application that submits the processing in the user's position. Enterprise transactions typically invoke several Web services: The initial invocation submits the work content, the next call checks the implementation, and the final call results. A call is a special Http/soap (Simple Object Access Protocol) Exchange. If you are a staff member of the IT department who specializes in monitoring server loading and forecasting future needs, you have to answer the basic question: "What do I do with my client now?" What else do I need to manage for the future? "

If you only have HTTP logs, it's very difficult to answer these questions. The client is concerned only with transaction processing, but because each transaction includes several HTTP requests, you can only develop custom data acquisition software for evaluating the quality of the service, which can be directed through the HTTP log and establish a model for user transactions. Even so, the information you have is still limited, because it does not reflect the network transmission or client-side application of the internal operation.

The central idea of this article is that the quality of transactional service is best evaluated by client. The approach here is to allow the client to record the actual number of transaction responses. The client application uploads the response time report to the server by adding a response time report to the next pop-up transaction request. The server takes out these attachments and queues them up for storage and online analysis.

Structure

The goal of the client-based frequency recording structure is that the lower construction of the record must be lightweight, which not only helps to realize the overhead of running the house but also reduces the burden of adding it to an existing implementation. We also want the structure to have no restrictions on the services provided, and we would like to add the service to an existing client-server system that can use the Web service as easily as possible.

Another goal of our structure is to not be too poor in the reliability of the enterprise application itself. We will introduce some new and easy steps into the processing workflow of the application. And we can guarantee that any failure in these new steps will be handled, and we will not fail to process the enterprise transaction because we cannot use the frequency for the program.

The following illustration shows a typical client-server application of the Java 2 Platform Enterprise Edition Web service. A typical component is marked with a thick line; The new component we add is used to collect frequencies, which are marked with red lines.

Java EE Web services:metrics-gathering architecture

The "Java Application Server" zone represents an existing server resource. They are the Enterprise JavaBeans (EJB) components that are used to process client requests. The tool can automatically generate Web service packages. EJB components and related WEB service modules are configured as Java EE applications on the Java server. When an application is configured, the client can judge a service by invoking the program WSDL (WEB Service Description Language) service. The WSDL service gives a formal definition of the service provided by the program.

The application Client area consists of program components and Web service packages. The program component implements the business logic and user interface. Web Services packages can be created automatically through WSDL compilers and WSDL services provided by the Java server program.

Theoretically, the entire client-server system has two tiers. The application layer has an EJB component on the server side that has an application at the client. The Web service layer has a server implementation and a client implementation, both of which can be generated automatically.

Typically, a user's business transaction includes many service-period calls. The first call initializes the transaction and returns a "handle" to the client. Subsequent calls to query the completion of the transaction-the client uses the handle to invoke the service to check whether the transaction is handled. Usually the last call to the state of a transaction that can be completed. Therefore, a business model, which can be implemented within a client program, always makes a transaction associated with a low-level server invocation.

We can add a collection of frequency components to our standard Java EE Web services architecture. The payload package in the figure above is configured on both the server and the client. I'll discuss this package in detail later, but in a structural sense, this package provides several services. For example, a client program can use BeginTransaction () and CommitTransaction () to set the bounds of transactions and record times. The Client Web Services package uses the payload package to serialize the number of reports to the SOAP information attachment. The server-side Web Services package uses the payload package to detach the soap attachment from the incoming request and queue it up for registration and reporting.

The system operation in this implementation is rarely because the client and the server do not exchange any new traffic-the frequency report of the completed transaction is shipped along with the next client request. The only new processing introduced is the serial and server-side queued attachments on the client. The entire implementation is lightweight because you just add one line of code to each program Web method, and the code is the same-if the markup for the Web method doesn't change.

The last component introduced is an information-driven EJB component that reads serial frequency attachments. Typically, these attachments will be recorded in a database so the enterprise can keep a record of the quality of the transaction service. An enterprise can use this database to link the actual number of transaction responses to the use of server resources, thus identifying which server component is the critical service bottleneck. Because the attachment is queued, the frequency Reader EJB component should run on a different Java-EE server, and we do not want to compete with the frequency attachment of the commercial EJB component record.