11.3 Web Service Execution Environment Management

Web services naturally execute in a runtime. This runtime is also known as a service container or service execution environment. The Web service runtime, as shown in Figure 11.4, generally takes care of the details of decoding the SOAP messages, creating the correct Java objects, and invoking the service implementation.

Figure 11.4. Web Service Runtime

Both Sun's JAX-RPC and Apache's AXIS define and provide service provider runtimes that perform these functions. Many of the application server vendors have also shipped Web service runtime support, including IBM, BEA, Oracle, and HP. Web services are not required to execute in such environments. Certainly a single program could listen on the port and perform all the necessary parsing, business function, and response management. However, this is an unnecessary programming burden , considering the number of execution environments available free, in open source, and in products. Programming to the service port and protocol directly in the service also ties a service implementation to a particular binding and decreases your ability to make the service available from various protocols and bindings. Web services are more easily made available if multiple bindings are used when they are implemented in a Web service execution environment because the Web service's execution environment can also function as a multiprotocol access layer.

AXIS provides the ability to add new transports, although the protocol is fixed in SOAP. SOAP over JMS transport plug-ins is available. Web Services Invocation Framework and Web Services Gateway (available from Apache) are Web service execution environments that support multiple protocols and transports. Because of the pervasiveness of the use of Web service execution environments, it is possible to use these environments for management purposes. Let's look at how we will manage the execution environment, as both an owner and a user . In the next section we will look at how to take advantage of the execution environment to manage the Web services themselves .

11.3.1 Execution Environment Owner

Web service execution environments, or runtimes, are in an optimal position to keep track of some interesting management statistics and provide some important management operations and events ^[23] for both themselves and the Web services running in them. If you own the execution environment code, you can instrument it to be manageable. How to manage an execution environment that you do not control, but are only using, is covered in the next section. Let's look at the data that should be available from the execution environment about itself. In Section 11.4 we will look at what data the execution environment should track for its Web services.

The execution environment should keep the following information about itself:

• Descriptive information about the implementation running, including

  - Identifier

  - Product name

  - Version

  - Installation date

• Configuration information, including

  - Services deployed

  - Log name

  - URL

• Metrics that indicate the rate of work and responsiveness of the execution environment to them, including

  - Number of requests

  - Number of responses

  - Number of failure responses

  - Average response time of responses

  - Average response time of failure responses

  - Average response time of successful responses

• Notifications that the execution environment can send, including

  - "Service invocation failed"

  - "Security access denied "

• Operations that control the lifecycle of the execution environment, including

  - Start environment

  - Stop environment

  And the services running in it:

  - Deploy a service

  - Remove a service

  - Enable a service

  - Disable a service

Let's look at this lifecycle and how these operations are used. In enterprises , remote software distribution, installation, and deployment software will need to deploy the Web service into the runtime. It must also be possible to write succinct installation scripts for Web services that don't require the installer to be involved in multiple steps. Later, in order to move, update, or discontinue the Web service, it will be necessary to remove a Web service from a runtime. Thus we need deploy and remove operations for adding and removing Web services from the runtime. The disable operation would temporarily block the requests to the Web service without having to remove the service entirely. A disable might be done to allow maintenance on the Web service implementation, network, or backup systems. It might also be done to enforce scheduled availability of a service. For example, the "Technical Support Request" service might be available only from 7:00 A.M. to 7:00 P.M. Monday through Friday. Once the maintenance was finished or the time was 7:00 A.M. again, the enable operation would cause the runtime to allow the requests to invoke the Web service again.

As we indicated before, the execution environment should provide management data, metrics, operations, and events for each service. We will discuss service-specific responsibilities in Section 11.4.1.1.

A JMX MBean for the Web service execution environment would publish all of these attributes and operations that applied to the execution environment and send the notifications. Ideally there would also be an MBean for each service deployed in the execution environment. In order to give you functional examples, the samples developed for this section are implemented on the IBM Web Services Tool Kit (WSTK), which includes management support using TMX4J and handlers. Therefore, this MBean for the Web service execution environment is a subset of what is supported by the WSTK. Here is an MBean interface example:

  public   interface  WebServiceRuntimeManagerMBean {         String getName();        String getType();        String getVersion();                    // getServerVersion        Date getStartTime();                    // getStartDate        Integer getNumberOfServicesDeployed();  // getServicesCount        Integer getNumberofRequests();         // getTotalCalls        String checkAvailability();        String getServerHostname();          // getServerHostName        String getServerPort();              // getServerPort        Boolean getDebug();  void  setDebug(Boolean flip); } 

A simple implementation of this MBean is provided at the end of this chapter and on the book's Web site (http://www.awprofessional.com/titles/0672324083). This example works only on the Web Services Tool Kit with TMX4J.

Now that this information is available to you, how do you use it to manage the service? Because the metrics are exposed as MBean attributes, you can create a JMX monitor MBean to watch the attributes that represent the failure rates and response times. The monitor MBean will send a JMX notification. The management systems should get these notifications and react to them with recovery or operator notification. For instance, the management system may deploy a new instance of the service if the failure rate is 100 percent. If the management system is a quality-of-service (QOS) manager, it can react when average response time for methods drops below a defined threshold or failure rate exceeds a threshold. QOS managers typically track and report adherence to QOS agreements and don't adjust the system to improve the QOS. But a QOS manager may interact with a performance, configuration, or operations management system to tune it to improve performance and throughput.

The Web service runtime is also in a position to detect failures and react to or even recover some of them. If certain types of failures are returned ”that is, security failures or invalid target service failures ”notifications should be sent to management systems. Web service runtimes should send some failures to management systems for recovery rather than do the recovery for themselves because the execution environment may not know about the entire enterprise context in which it executes, and sometimes its own isolated recovery may be inappropriate. In smaller enterprises or single-host environments, however, a sophisticated Web service execution environment that does its own recovery may be appreciated. Recovery may include starting new instances of the Web service implementation if the Web service is not locatable or responding.

11.3.2 Execution Environment User

If your service is running in a Web service execution environment that is not JMX enabled ”that is, does not provide you a JMX MBean to manage it ”then you can develop an MBean to interact with the execution environment. How much information you can represent is subject to how much data is made available to you from the execution environment's APIs and log files. The logs may contain audit trails for service lifecycle changes, service invocations, status changes, and failures. You will have to write a program to read the log file, look for the messages, and update the counters or send notifications. Perl, grep, sed, and awk ^[24] are especially convenient scripting languages for this sort of processing.

Another way you can gather data into an MBean is to take advantage of interceptor or handler support of the execution environment. Handlers are invoked by the execution environment during request processing before the request is dispatched to the service, and during response processing before the response is returned to the requester. Both AXIS and JAX-RPC support these models. You can develop a request and response handler that is also an MBean that supports the runtime and service-specific metrics already discussed. Because it is a handler, this MBean may not be able to detect and publish the configuration information or WSDL URLs for the execution environment. IBM's Web Services Tool Kit contains a JMX management handler for AXIS.