QoS-Enabled Applications

The first step in QoS-enabling an application that consumes Web services is to determine and set the QoS requirements. And the first step in setting the requirements is to be realistic. We would all love to have Web services that respond within a microsecond, but it's just not going to happen for most of them. The response time for many Web services will be measured in hundreds to thousands of milliseconds. As we saw earlier in the chapter, even the simplest of services must incur overhead from server-side middleware and infrastructure, as well as from the technologies such as XML and HTTP which underlie SOAP.

Monitoring QoS Performance

Monitoring various QoS metrics of the Web services consumed by an application is one of the most important means to maintain the quality and reliability of an application. Luckily, it is simple to monitor and measure the performance of the individual consumed Web services.

Web services monitoring and management products usually monitor the response time, availability, as well as other metrics that can be used by client applications in determining whether to consume a particular Web service. If such a monitoring product is not available, the client application, the Web service client proxy stub, or the Web services infrastructure can be augmented to monitor and log various QoS metrics.

Figure 9-9 shows segments of a Web services client proxy stub that has been enhanced to monitor and log the roundtrip time for the Web service invocation.

The FlightInfoServiceBindingStub is a client proxy stub used by a client application as a local interface to the remote FlightInfoService Web service. Two java.util.Date objects are used as a timer. Immediately before the client proxy stub invokes the remote Web service, the current time is recorded in the startTime object. Once the remote Web service call returns, another java.util.Date object is instantiated, and its time is recorded in the stopTime object. The difference between the stopTime and startTime is used to gauge the roundtrip response time of the Web service invocation.

Figure 9-9. Monitoring the roundtrip response time of a Web service invocation by using a timer within the Web service client proxy stub.

 public class FlightInfoServiceBindingStub extends    javax.xml.rpc.Stub implements FlightInfoServicePortType {   .   .   .   // additional methods not shown public int getDepartureTime ( java.lang.String arg1 ,                               int arg2 ,                               java.lang.String arg3 )     throws java.rmi.RemoteException {   if ( call.getProperty         (org.apache.axis.transport.http.HTTPTransport.URL )           == null )   {     throw new org.apache.axis.NoEndPointException ();   }   call.removeAllParameters ();   call.addParameter ( "arg1" ,     new org.apache.axis.encoding.XMLType (       new javax.xml.rpc.namespace.QName (         "http://www.w3.org/2001/XMLSchema" , "string" ) ) ,       org.apache.axis.client.Call.PARAM_MODE_IN );   call.addParameter ( "arg2" ,     new org.apache.axis.encoding.XMLType (       new javax.xml.rpc.namespace.QName (         "http://www.w3.org/2001/XMLSchema" , "int" ) ) ,     org.apache.axis.client.Call.PARAM_MODE_IN );   call.addParameter ( "arg3" ,     new org.apache.axis.encoding.XMLType (       new javax.xml.rpc.namespace.QName (         "http://www.w3.org/2001/XMLSchema" , "string" ) ) ,       org.apache.axis.client.Call.PARAM_MODE_IN );   call.setReturnType (     new org.apache.axis.encoding.XMLType (       new javax.xml.rpc.namespace.QName (         "http://www.w3.org/2001/XMLSchema" , "int" ) ) );   call.setProperty (     org.apache.axis.transport.http.HTTPTransport.ACTION ,     "http://tempuri.org/" );   call.setProperty ( call.NAMESPACE ,                      "http://tempuri.org/" );   call.setOperationName ( "getDepartureTime" );   // Start a Timer   Date startTimer = new Date ();   long startTime = startTimer.getTime ();   // Invoke the service   Object resp = call.invoke (     new Object[]{arg1, new Integer ( arg2 ), arg3} );   // Stop the timer   Date stopTimer = new Date ();   long stopTime = stopTimer.getTime ();   long elapsedTime = stopTime - startTime;   System.out.println ( "Roundtrip time is: " +     elapsedTime + " ms." );   if ( resp instanceof java.rmi.RemoteException )   {     throw ( java.rmi.RemoteException ) resp;   }   else   {     return ( ( Integer ) resp ).intValue ();   }  } } 

By simply augmenting the application code directly or each of the invoked Web service stubs, the amount of time for the Web service request-response roundtrip time can be calculated and recorded. These values can then be compared against the specified QoS measures to verify that the monitored performance is within the bounds of the specification.

Figure 9-10 lists the roundtrip response times of the FlightInfoService Web service as monitored by the FlightInfoServiceBindingStub client proxy stub enhanced with the timer logic. As is clearly seen in the monitored data, each invocation response time varies. The longer initial response time is due to the Web service being dynamically loaded by the SOAP Server in response to receiving the invocation. The other, smaller variations are a result of changing environments of both the application and the Web service, including network congestion and server load.

Although enhancing each client proxy stub with a timer is simple, it is a laborious process. A more architecturally elegant solution would be to place such logic within the Web services (SOAP) Server message handler. The monitored information could be recorded by a central location, returned to the application itself, or fed to an application management utility.

Figure 9-10. Roundtrip latencies for four invocations of a Web service.

 Roundtrip time is: 1645 ms. Roundtrip time is: 792 ms. Roundtrip time is: 431 ms. Roundtrip time is: 697 ms. 

Discovering the Right Service

Now that we have seen how QoS information that is annotated within other Web service specification information can be used to answer some critical questions in selecting the appropriate Web service, we next turn to the actual process of locating the right Web service.

Brokers will usually handle the establishment of bindings between applications (service requestors) and Web services (service providers). Brokers are "middleman" programs that facilitate locating the appropriate Web service based on given specifications, parameters, and hints. Since the functionality of these brokers are the same for all service providers and service requestors (only the specifications, parameters, and hints change), infrastructure software such as middleware will most likely provide these capabilities. Brokers (either the entire broker system or parts thereof) may also be remotely located as a Web service, in and of itself.

The steps in the interaction between an application and a QoS broker as the application tries to locate the right Web service to bind to are as follows:

• The application sends a request to the QoS broker with information about the type of service required (or even a UDDI tModel reference to a Web service interface) together with the application's QoS requirements.

• The broker searches a Web services registry, such as UDDI, for potential Web services.

• The broker negotiates with Web services to determine the actual QoS the services offer, and tries to establish an agreed QoS that matches the application's QoS needs and the QoS offered by the Web service.

• If a suitable Web service is found, the broker establishes binding between the application and the Web service.

• The broker informs the application that a suitable service has been located and the binding has been made.

It is important to remember that QoS brokers (or any broker) will not be able to act alone. Instead, all of the needs of the application will have to be taken into account in an effort to determine the best available Web service (or even if a suitable service exists). For instance, most businesses will require the use of a business and strategic broker in addition to a QoS broker. The business and strategic broker will create a subset of those Web service vendors that are appropriate to use based on business issues, while the QoS broker will create a subset based on QoS issues. Today, much of this brokering is done manually through human intervention. In the near future, it is unlikely that all of the required brokering can be automated to a sufficient level, or that automated results will be suitable for use without human intervention.

Recovering from Service Failures

Perhaps the simplest yet one of the most important QoS issues for applications that consume distributed and remote Web services is fault-tolerance and recovering from service failures. Services can fail for a variety of reasons, such as:

• An error in the service caused it to fail.

• The service itself consumed another service that failed.

• Network problems caused the service call to fail.

• Critical infrastructure, such as power, failed and caused the entire server to go down.

Developers often make the assumption that if they consume a Web service provided by a large corporation, the Web service will be 100% reliable. It's certainly true that larger corporations have resources as well as contingencies in place that may minimize potential problems with their Web services, but these services are far from fully reliable. Services may have to be taken offline for maintenance, they may be migrated to different machines, or they may be replicated for scaling purposes. These harmless actions may cause potential issues for applications that are consuming them. Also, problems with resources that are outside of the corporation's control, such as the network, may cause the service to be unavailable (and appear to have failed) to the consuming application.

It is precisely in this need for lifecycle management of applications and Web services where UDDI can play a critical role. Web services need to disseminate changes to applications that call them. Applications need to be made aware of these changes. UDDI can play the runtime broker or middleman in handling and propagating these changes.

The steps in this lifecycle management scenario are:

• Develop the application to consume the Web service using the information from the saved bindingTemplate information;

• If the Web service call fails or exceeds an application-specified timeout, query the UDDI registry for the latest information on that Web service;

• In the case the original Web service call failed, compare the latest binding information for that Web service with the saved information. If the latest binding information is different from the saved information, then save the new binding information and retry the Web service call.

• In the case that the original Web service call exceeded a timeout, compare the latest binding information for that Web service with the saved information. If the information is different or newer access endpoints are available, select another endpoint. The selection procedure may be manual in which the application allows the user to manually choose, or it may be automatic.

In this scenario, UDDI plays a critical role in maintaining the reliability and quality of service of both applications and the Web services they consume throughout their lifecycle.