QoS-Enabled Web Services


In this section, we look at how to build QoS-enabled Web services. A developer of a QoS-enabled Web service must not only build the actual Web service, but also communicate the QoS measures to potential consumers of the Web service.

We begin by looking at how to communicate Web service QoS to potential consumers of the Web service.

Communicating QoS to Client Applications

When developing an application that consumes Web services, one of the most difficult tasks is to identify the right services to use. Web services are software modules that implement a particular function or capability. Since Web services will typically not be enormous monolithic applications, there will usually be multiple competing implementations for a particular type or class of service functionality. Although the capabilities will be the same or similar, the different Web services will compete based on implementation details such as access latency and interface specification. In addition to technical details, the selection of Web services will also be based on business, strategic, and political issues.

In selecting a Web service to use, there may exist business relationships and legal agreements that have to be honored. This may sometimes involve selecting a technically inferior service in order to meet such obligations. There may be pending customer deals that can be closed by using a particular vendor's Web services. A company may attempt to pressure another company by withholding patronage of the latter company's Web services. Because of the wide mix of issues that are often involved, technologists alone will also be insufficient. Accordingly, business analysts, consultants, and other such people (possibly in conjunction with technologists) will usually be responsible for the Web service selection process. In the remainder of our discussion, we focus on the technical QoS issues in selecting Web services.

An application developer or architect must understand the QoS and other non-functional attributes of Web services before he can determine those Web services that are appropriate. Unfortunately, Web Services Description Language (WSDL) files that are usually used to determine whether to use a particular Web service only specify the service's interface and location. Today answers to the following (and many other) questions are beyond the scope of WSDL files:

  • What is the expected latency of this service?

  • What specification version does the service support?

  • Does the service support transactions?

  • What is the average power consumed by interacting with this service?

The answers to these questions lie not only in the actual service implementation but also with the particular Web services platform (the service access point) used. For instance, a Web services platform that supports caching will provide improved average latency for those operations that do not change much with time. Weather information is a good example. Moreover, Web services platforms that support prioritized service requestors will offer better performance for some users and slower response times for others. This means that the same Web service implementation may have different QoS values depending on its access endpoint.

One means of supporting QoS by Web services is to augment service specifications to include QoS information. QoS can be assigned to three levels of granularity:

  • Access endpoints

  • Individual Web services

  • Individual operations or methods of individual Web services

WSDL files can be extended to include this type of information. As we have noted, the same Web service at different endpoints may have different WSDL files to reflect the difference in their QoS or other non-functional attributes.

Figure 9-6 shows a segment of a WSDL file that has been augmented to include QoS information. It is important to note that no industry standard exists to augment WSDL files (or other Web service-specific object) with QoS information as yet. What we discuss in this subsection is simply one way of supporting and communicating Web service QoS to potential consumers of Web services using WSDL files.

Figure 9-6. QoS-annotated WSDL segment showing differentiated service endpoints.
 <wsdl:service name="WeatherService">   <wsdl:port name="WeatherPort"              binding="weather:WeatherBinding">     <soap:address location="http://example.org/weather1"/>     <QoS group="1"/>   </wsdl:port>   <wsdl:port name="WeatherPort"              binding="weather:WeatherBinding">     <soap:address location="http://example.org/weather2"/>     <QoS group="2"/>   </wsdl:port> </wsdl:service> 

The <QoS group=n> tag is used to annotate the WSDL file to specify different service endpoints with different QoS. The semantics of the QoS tag must be predefined so that applications programmatically inspecting WSDL files for various Web services can make a determination of the appropriate group for its needs.

The QoS information can be used at application design time or even at runtime to select the appropriate service endpoint. The QoS information available to a client application can be further enhanced with more specific information. This information may include the expected response times at different time periods throughout the day. Other information, such as the cost of accessing that Web service endpoint, can also be supported.

A QoS-annotated WSDL segment that specifies not only the different QoS groups but also the expected response times is shown in QoS-annotated WSDL segment showing differentiated service endpoints as well as specific information about expected response times during different time periods throughout the day.

The Timing tag specifies various time-related information about the Web service. The attribute response specifies in milliseconds the expected response time of accessing the Web service. The attribute period specifies the time period within a twenty-four hour day for which the expected response time is valid. For example, from Figure 9-7, we can conclude that if a client application were to access the weather Web service at http://example.org/weather2 (QoS group 2) at 8:30 A.M., the expected response time would be 930 milliseconds.

In some cases, different operations within a Web service may have different expected QoS attributes. Depending on the operation, it may also have other different characteristics, such as the fee required to access the operation. Figure 9-8 shows a segment of a WSDL file that has been augmented to include specific information at the service operation level.

Figure 9-7. QoS-annotated WSDL segment showing differentiated service endpoints as well as specific information about expected response times during different time periods throughout the day.
 <wsdl:service name="WeatherService">   <wsdl:port name="WeatherPort"              binding="weather:WeatherBinding">     <soap:address location="http://example.org/weather1"/>     <QoS group="1">       <Timing response="310" period="1900-0659"/>       <Timing response="740" period="0700-1859"/>     </QoS>   </wsdl:port>   <wsdl:port name="WeatherPort"              binding="weather:WeatherBinding">     <soap:address location="http://example.org/weather2"/>     <QoS group="2">       <Timing response="590" period="1900-0659"/>       <Timing response="930" period="0700-1859"/>     </QoS>   </wsdl:port> </wsdl:service> 

The operation attribute of the Timing tag specifies the Web service operation name for which the other attribute values are valid. By parsing the WSDL segment in Figure 9-8, a client application can determine that if it were to access the getTemp operation of the weather Web service at http://example.org/weather2 (QoS group 2) at 8:30 A.M., the expected response time would be 870 milliseconds.

In this section, we illustrated a means of communicating QoS information of Web services to potential client applications by annotating WSDL files. Not only can information about expected response times be communicated, but also any QoS measure as well as other information such as access fees. Information such as access fees are fixed by the Web service owner, while QoS information such as response time, reliability, and availability must be monitored and then reported. Web services monitoring and management utilities are available to track this information or, as we will see in a later section, simple applications can be written to track the measure of various metrics.

Figure 9-8. QoS-annotated WSDL segment showing differentiated service endpoints as well as specific information about the expected response times during different time periods throughout the day of individual operations.
 <wsdl:service name="WeatherService">   <wsdl:port name="WeatherPort"              binding="weather:WeatherBinding">     <soap:address location="http://example.org/weather1"/>     <QoS group="1">       <Timing operation="getTemp" response="310"               period="1900-0659"/>       <Timing operation="getTemp" response="740"               period="0700-1859"/>       <Timing operation="getHighTemp" response="110"               period="1900-0659"/>       <Timing operation="getHighTemp" response="280"               period="0700-1859"/>     </QoS>   </wsdl:port>   <wsdl:port name="WeatherPort"              binding="weather:WeatherBinding">     <soap:address location="http://example.org/weather2"/>     <QoS group="2">       <Timing operation="getTemp" response="420"               period="1900-0659"/>       <Timing operation="getTemp" response="870"               period="0700-1859"/>       <Timing operation="getHighTemp" response="230"               period="1900-0659"/>       <Timing operation="getHighTemp" response="410"               period="0700-1859"/>     </QoS>   </wsdl:port> </wsdl:service> 

Lifecycle Management

Once a Web service has been developed and deployed, it not only has an interface specification but also a network location (usually a URL) as well as other information (such as QoS compliance and specifications) associated with it. Over time, the deployment that had sufficed when the service was new and relatively underused may require changes. This could include migration of the service to a new server. Multiple geographical mirror servers may also be deployed as the need to scale the service increases, or a new server location may be launched while the original one is taken offline for maintenance. The organization or division maintaining the Web service may be relocated or sold, thereby necessitating an update to its access endpoint information. How can these changes be propagated to applications that have already been designed to consume the original Web service? Without appropriate dissemination of such changes, applications consuming the original service can malfunction or produce erroneous transactions.

Applications based on Web services need a mechanism to stay updated with the latest information, including changes to access endpoints, additional endpoints, and updated QoS specifications for a particular Web service. It is precisely in this need for lifecycle management of 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 role of runtime broker or middleman in handling and propagating these changes.



Developing Enterprise Web Services. An Architect's Guide
Developing Enterprise Web Services: An Architects Guide: An Architects Guide
ISBN: 0131401602
EAN: 2147483647
Year: 2003
Pages: 141

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net