Web Services Management Information

Representing

Web Services Management Information

in UDDI

Adam Blum, CTO, Systinet Corporation

Fred Carter, Sr. Architect, AmberPoint, Inc.

January 2004

Introduction

We would like to propose a Technical Note (TN) to define a standard way to store web services management information in UDDI. The most immediately obvious type of information to store is quality of service information. This includes information aggregating a web service’s overall performance, reliability, availability and throughput. There are several alternatives methods to store such information in UDDI registries. Already customers are demanding that WSM vendors store this information in UDDI. Without any attempt to standardize the location of such information, each WSM product will likely store such information with different names using different methods.

There is an opportunity to allow customers to see all quality of service information in standard locations in UDDI with a common vocabulary for referring to it. This will allow developers and users to make better decisions about what web services to use given the QoS information. It also magnifies the value of WSM vendors’ solutions, as a wider set of people beyond their direct web services administrator customer now has access to the value of that data. In this document, we propose a standard mechanism for storing such data and standard names on the quality of service attributes.

Design Goals

The recommendation set forth should meet the following criteria:

• Make it as easy and direct as possible to get particularly important summary quality of service information on each web service and binding.
• This should include a default “overall aggregation” for performance, reliability, availability and throughput
• Other detailed QoS metrics aggregated over varying time periods should be requestable via additional WSDL-defined services
• Reports (of any format) whether HTML for human consumption or XML format for programmatic use should be returnable via direct http URLs
• Existing standards (such as the full set of abstractions available in UDDI, WSDL for conveying locations of web services, and the existing “Mapping UDDI to WSDL” technical note) should be leveraged wherever possible.

Requirements

We would like to represent the following information for each service represented in UDDI and each binding of that service. This is information summarized over time at some default level of aggregation determined by the administrator or WSM product. We assume that this data will only be updated to the UDDI registry infrequently, perhaps once per day for example.

To get realtime information, or detailed information not at the default level of aggregation, we propose external WSDL services that are referred to from the UDDI registry in a standard way. In effect, the reference to the WSDL for detailed or realtime information becomes another natively stored attribute.

The aggregated “UDDI native”-stored summary statistics maintained will include:

-average response time

-invocation throughput

-byte throughput

-reliability

-availability

-the reporting time period for this information

-the update interval

This list may become longer as this work is reviewed by a wider audience.

We assume that users will want to be able to browse for services based on these QoS attributes, and that they should be able to do so with either generic UDDI browsers and/or special purpose search client written only with the UDDI APIs.

Web service management vendors should be able to store information about each web service binding on the UDDI bindingTemplate by using only the UDDI management APIs.

Methods to Incorporate Into UDDI

There are four basic methods of reflecting this additional information in UDDI:

TModel for QoS Information Pointing to External Resource

Define a tModel called QoSInformation that references an external quality of service web service. A resource at the tModel’s overviewURL (such as an a generated XML file) would contain all of the performance and reliability data. Each UDDI bindingTemplate contain a tModel reference to the QoSInformation tModel, added to its tModelInstanceDetails collection.

This method has the disadvantage of requiring navigation to external resources to retrieve information. The quality of service metrics are not available right inside UDDI, accessible via UDDI query and object management APIs.

Multiple Categories for QoS Attributes

Create multiple additional tModels to represent this QoS information, one for each type of QoS information. Add these categories to UDDI bindingTemplates. In effect, each categoryBag will have multiple keyedReferences, each of which represents a different QoS metric. The values of the metrics would be stored right in the category values.

This method has the potential disadvantage of creating unmanageably large categoryBags (i.e. too many categories) on each bindingTemplate. It also requires UDDI V3 to allow usage of categories on bindingTemplates.

Extend the UDDI Data Structures

Extend the UDDI information explicitly to have the QoS information using UDDI v3 extensibility mechanism to extend the UDDI data structures (specifically businessService and bindingTemplate) via XML schema derivation.

This method has the disadvantage of requiring UDDI v3 support registries. In the future however this option warrants further evaluation, possibly to supplement the approach we recommend.

TModel for QoS Information Containing Multiple Categories of QoS Attributes

In effect this combines the first two approaches. As with the first approach, each UDDI bindingTemplate, would have a tModel reference in its tModelInstanceDetails collection QoSInformation. The QoSInformation tModel will have have multiple categories on it, each reflecting a different QoS attribute. Using UDDI V3’s “nested find” capability, users will be able to search for all bindingTemplates that point to a tModel that has categories on it with particular values or ranges of values.

But one of the categories on the tModel will be “Type” and the value of that category will be “QoSInformation”. This approach of creating new tModels, indicating the type as a category and storing multiple attributes as categories on those new tModels is the method pursued by the WSDL-UDDI mapping specification [WSDL-UDDI] to reflect new classes of objects. See “Extending UDDI with Robust Web Service Information” [ExtendingUDDI] for a general discussion of this technique.

Recommended Method

As you can see, we recommend the fourth alternative A QoSInformation tModel will be added to UDDI bindingTemplate’s tModelInstanceDetails collection. The QoS Information tModel will have multiple keyedReferences, each with the following structure. Note that we have used the UDDI V3 capability of “friendly named keys” for clarity of explanation. On UDDI V2 systems, conventional UUIDs would be used. Also on UDDI V3 systems the names shown would be subject to change and recommendations from the appropriate standards bodies that we might work with. As is the case for any keyedReference the keyName is completely optional. WSM vendors will mark managed bindingTemplates and services with the defined tModelKey and the keyName and keyValue.

tModelKey / keyName / keyValue / Comments
urn:UDDI-WSMInfo-QoS-Responsetime_Average / ResponseTime Average / (numeric value or symbolic rating) / WSM vendor should consider using symbolic rating to ease exact match searching
urn:UDDI-WSMInfo-QoS-Throughput_Count / Throughput_Count / (numeric value or symbolic rating)
urn:UDDI-WSMInfo-QoS-Throughput_Bytes / Throughput_Butes / (numeric value or symbolic rating)
urn:UDDI-WSMInfo-QoS-Reliability / Reliability / (numeric value or symbolic rating)
urn:UDDI-WSMInfo-QoS-CurrentAvailability / CurrentAvailability / (Boolean)
urn:UDDI-WSMInfo-QoS-ReportingPeriodStart / ReportingPeriodStart / (datetime) / The beginning on the reporting time period used for the information above.
urn:UDDI-WSMInfo-QoS-ReportingPeriodEnd / ReportingPeriodEnd / (datetime) / The end of the reporting time period used for the information above.
urn:UDDI-WSMInfo-QoS-UpdateInterval / UpdateInterval / (duration) / How often is this information updated in UDDI (it is not assumed to be realtime).

Detailed QoS Queries Reporting

In addition to having summary quality of service information we want to allow WSDL-defined web services that return additional QoS metric details to be returned. These services will typically allow varying levels of aggregation and different time periods to be queried. Eventually we would like to see that such WSDL definitions would be standardized as well. But we aren’t proposing such a standardization just yet. All that we currently propose to standardize is the method of referring to the external location.

The following is an example of such a method.

Boolean Get_ResponseTime_Average(

DateTime beginDate,

DateTime endDate,

int timeGranularity,

Array results)

The tModel that points to the WSDL for this service is added to the bindingTemplate’s tModelInstanceDetails . The tModelKey will be something like “uuid:UDDI-WSMInfo-QoS-DetailService” (for UDDI V2 it would be a standard numeric UUID equivalent of this friendly UUID). The keyValue will be a reference to the WSDL of the external web service.

For URL-accessible reports (retrievable via http get) a similar method is used. The difference is that the URL of the report will be reflected directly as the keyValue. Specifically the tModelKey would be something like “urn:UDDI-WSMInfo-QoS-Report”. The keyValuewill be the URL for the report. The report may everything from structured XML available at that URL to plain HTML with a text description of the service’s performance.

Summary

Providing standardized locations in UDDI registries for web services management information provides great value for both customers and WSM vendors. The “Using WSDL in a UDDI Registry” specification provides a precedent for how an additional class of information related to a web service can be stored. We have tried to follow that convention in proposing a mechanism for storing quality of service information for web services, both summary attributes and for more detailed information.

References

[WSDL-UDDI] “Using WSDL in a UDDI Registry, Version 2.0” -

[UDDI-Data] “UDDI Data Structure Reference”,

1