Technical Note - OASIS€¦  · Web view24/02/2004  · Technical Note This Version: Latest Version: Introduction Requirements Relationship to OASIS WSDM Standard Use Cases Developers

UDDI Spec TC

Technical NoteRepresenting Web Services Quality of Service Information in UDDIDocument identifier:

document.doc24

This Version:http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-QoS-metrics-20040224.htm

Latest Version:http://oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-qos-metrics.htm

Authors:

Fred Carter, AmberPoint, [email protected] Blum, Systinet, [email protected]

Abstract:This document describe how quality of services information associated with individual implementations of web services can be stored in UDDI.

Status:This document is a working draft. Committee members should send comments on this technical note to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 1 of 15

Table of Contents

1 Introduction............................................................................................................................ 31.1 Requirements................................................................................................................31.2 Relationship to OASIS WSDM Standard.......................................................................31.3 Use Cases..................................................................................................................... 3

1.3.1 Developers and Users...............................................................................................31.3.2 Administrators...........................................................................................................41.3.3 Web Services Management Software.......................................................................4

1.4 Terminology................................................................................................................... 42 Design Alternatives................................................................................................................5

2.1 tModel Pointing to External Web Service for QoS Information Only..............................52.2 Place Categories for QoS Attributes Directly on Binding Templates..............................52.3 Extend the UDDI Data Structures..................................................................................52.4 tModel for with Multiple Categories of QoS Information Referred to from Binding Template.................................................................................................................................... 6

3 Recommended Solution.........................................................................................................74 References............................................................................................................................. 8

4.1 Normative...................................................................................................................... 8Appendix A. Acknowledgments......................................................................................................9Appendix B. Revision History........................................................................................................10Appendix C. Notices..................................................................................................................... 11

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 2 of 15

1 IntroductionUsers and organizations are increasingly concerned with being able to access and understand aspects of the performance, reliability, throughput and availability of the web services they are considering using in their applications and that they are managing. Web services management software is addressing this problem and storing a set of very similar metrics for these aspects of web services. The OASIS WSDM group is addressing standardizing the set of these metrics and their names. This Technical Note puts forth a standard for where and how to store such information, since there are many possible methods to do this using UDDI’s abstractions.

1.1 RequirementsThe goals for the solution outlined in this technical note include:

- Allow important summary aspects of the quality of service a specific web service physical implementation, deemed pertinent by the WSDM group, to be stored in UDDI

- Should be searchable and browsable using UDDI V2’s existing web services-based browse and search capabilities

- Both aggregate metrics (such as average performance, reliability, throughput and availability) and individual count metrics (request, response and fault counts) that can be used by client software to compute additional aggregates should be represented. The initial set of metrics should ideally be derived from input by the WSDM group.

- Provide for easy extensibility of metrics tracked based on forthcoming recommendations and standards from the WSDM group

- Additional quality of service attributes, different time periods, varying levels of aggregation and realtime quality of service information should be available through invocation of a “management web service” that is referenced from web service’s binding template and associated tModels in a standard way. Standardized WSDLs for management web service are expected to be provided by WSDM.

- Allow ease of segregated permissions to manage or own just the quality of service information as distinct from the binding template information itself

Although this Technical Note concentrates on representation quality of service and performance metrics, it would be valuable if the modeling techniques used to store these attributes could also be used for other, more general, web services management information such as service level agreements, cost and chargeback information, lifecycle information, etc. However, this other information is beyond the scope of this proposal.

1.2 Relationship to OASIS WSDM Standard The OASIS Web Services Distributed Management Technical Committee (WSDM) is operating concurrently, working toward standard mechanism definitions for both management using web services and management of web services. That group is the proper place for ongoing definition of management information, naming, etc. This note, on the other hand, is focused on how this information is to be incorporated into a UDDI registry. Combining the standard definitions from WSDM with a standard means of access via a UDDI registry provides the web service community with a powerful addition in capabilities for choice of web services.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 3 of 15

The first revision of the WSDM specification is focusing on the definitions for management providers [WSDM-Arch]. As outlined in section below, this is primarily the raw data obtained by the manager. This data, while useful, is not typically that in which a UDDI user is interested. This specification outlines the means by which QoS information can be provided to a UDDI user, as we expect that to be the primary management information of interest to someone choosing between web services. Consequently, we have suggested a number of QoS metrics we feel will be of value to such a user.Ultimately, these definitions will come from the WSDM group. We expect to work closely with the WSDM technical committee to refine this specification.

1.3 Use Cases

1.3.1 Developers and UsersDevelopers that are considering incorporating a web service into their application would use their general purpose UDDI client to search for web services. They would also be able to use web services “search clients” from within their development tool of choice or potentially clients provided by web services management vendors. A programmer may choose between two implementations of a given web service based on the performance or reliability of that web service. Or they may choose between two entirely different web services (that can nevertheless yield the desired information, potentially in combination with other web services or programming components). Even the decision of whether or not to use a web service at all (versus a component already available to be integrated in process) is influenced by such information.

A class of emerging “general purpose web service client tools” and “composite web service application tools” let users invoke web services directly. The information available on web services performance and reliability can be used by them to determine which web services they wish to use.

1.3.2 AdministratorsAdministrators of the UDDI registry or specific web services will choose the implementations of web services for which they wish to store quality of service metrics using their web services management software of choice. This will cause the management software to create and maintain the quality of service information in the registry. Since this is a standard they may also create the quality of service metrics themselves. Quality of service information is stored on a separate UDDI object (specifically a generated tModel as discussed below).

In scenarios where developers and users are concerned about who has published the quality of service information, UDDI V3’s ability to digitally sign content can be used to determine with assurance whether the management software, the UDDI administrator or the publisher of the given web service has asserted the quality of service metrics which are advertised.

The administrator will choose, as a matter of policy, the appropriate identities to update the QoS information contained in a UDDI registry. UDDI registries provide the mechanism for these policies.

Administrators of the UDDI registry will also determine the frequency of update of the aggregated information, by setting the appropriate intervals on their web services management software, or by controlling the frequency of their own homegrown quality of service aggregation publication mechanism.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 4 of 15

1.3.3 Web Services Management SoftwareIn the model of Web Service Management defined by the WSDM committee [WSDM-Arch], management providers are the source of the raw management data about the behavior of a web service. This data is consumed [typically] by management applications, which can provide aggregations, contextual information, historical analysis, etc., to be used by that application’s users.These applications may be display oriented, providing graphical information to their users, data acquisition and storage applications, storing data for later analysis, or both. These management applications are likely to be the source of the QoS information available to the UDDI registry.As noted above, these applications may take on the role of updating the associated UDDI registry, under the control of that registry’s administrator. UDDI V3’s signed content capabilities will allow appropriately configured management applications to verify the validity and integrity of the information placed in the registry, again under the control and direction of the administrator.

1.4 TerminologyThe key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in Error: Reference source not found.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 5 of 15

2 Design Alternatives

[Note: Per Tom Bellwood’s suggestion, this section will be removed as the proposed solution is finalized. Hence we do not provide examples or XML fragments when presenting them.]There are four possible methods of reflecting this additional information in UDDI:

2.1 tModel Pointing to External Web Service for QoS Information Only

Define a tModel (say, QoSInformation) that references an external quality of service web service. Such a web service should be defined with a standard WSDL by some web services management focused standards body such as WSDM. A resource at the tModel’s overviewURL (such as 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’s query and browse capabilities and object management APIs. This is the lowest common denominator of integration. .

2.2 Place Categories for QoS Attributes Directly on Binding Templates

Create multiple additional tModels to represent this information, one for each type of represented information. Add these categories to UDDI bindingTemplates. In effect, each categoryBag will have multiple keyedReferences, each of which represents a different WSM metric. The values of the metrics would be stored right in the category values. Thus WSM attributes of implementations of web services can be searched and browsed via general UDDI clients.

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. This would violate the second requirement above of supporting V2 only. It would also violate the desire to have QoS information separately manageable and accessible from the basic binding template information (the last requirement above)

2.3 Extend the UDDI Data Structures

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

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 6 of 15

This method has the disadvantage of requiring UDDI V3 registries. In the future however this option warrants further evaluation, possibly to supplement the approach we recommend, and perhaps eventually become the preferred method.

2.4 tModel for with Multiple Categories of QoS Information Referred to from Binding Template

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. This tModel will have multiple categories on it, each reflecting a different WSM 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. The latter range capability will require that range query be implemented in a future UDDI specification

But one of the categories on the tModel will be a reference to a tModel of a taxonomy of new web services management related objects (the list of which is to be determined). The keyValue of that category will be “QoSInformation”. This approach of creating new tModels 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. However in this case, the created tModels apply to specific physical implementation of web services. In the purist UDDI sense, such use of tModels may be undesirable. Nevertheless, this would seem to provide significant utility as a way of organizing additional information about each web service. Also, it does not assume any use of UDDI V3.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 7 of 15

3 Recommended Solution

A QoSInformation tModel would be added to UDDI bindingTemplate’s tModelInstanceDetails collection. The QoSInformation 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 determined by the recommendations of the appropriate standards (such as WSDM). 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.

[Note: the friendly names of the tModelKeys shown below in the first column have not been decided. The values there are just for example We need guidance on those names from UDDI TC and WSDM.]

tModelKey keyName keyValue Comments

urn:wsdm.org:metric:RequestCount RequestCount (number of requests)

urn:wsdm.org:metric:ReplyCount ReplyCount (number of replies)

urn:wsdm.org:metric:FaultCount FaultCount (number of faults)

urn:wsdm.org:identity:resourceId resourceId (resource identification in URI format)

This is the unique identity by which the resource (service) is known to the management system. It is useful for further queries.

urn:wsdm.org:metric:lastUpdateTime lastUpdateTime (time value) Time these values were updated.

The examples shown below demonstrate how this base set of values might be extended to include other QoS values. The values shown below are meant as examples only.

urn:wsdm.org:QoS:Responsetime_Average ResponseTime Average (numeric value or symbolic rating)

WSM vendor should consider using symbolic rating to ease exact match searching.

urn:wsdm.org:QoS:Throughput_Count Throughput_Count (numeric value or symbolic rating)

Urn: wsdm.org:QoS:Throughput_Bytes Throughput_Butes (numeric value or symbolic rating)

urn: wsdm.org:QoS:Reliability Reliability (numeric value or symbolic rating)

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 8 of 15

urn: wsdm.org:QoS:ReportingPeriodStart ReportingPeriodStart (datetime) The beginning on the reporting time period used for the information above.

urn: wsdm.org:QoS:ReportingPeriodEnd ReportingPeriodEnd (datetime) The end of the reporting time period used for the information above.

urn: wsdm.org:QoS:UpdateInterval UpdateInterval (duration) How often is this information updated in UDDI (it is not assumed to be realtime).

Below is an example of the bindingTemplate reference to the tModel that will have the QoS attribute categories attached. It starts with the sample sample Stock Quote Service example used in “Using WSDL in a UDDI Registry” [WSDL-UDDI] but for simplicity does not include the WSDL artifacts that example uses.

<businessService      serviceKey="102b114a-52e0-4af4-a292-02700da543d4"          businessKey="1e65ea29-4e0f-4807-8098-d352d7b10368">    <name>Stock Quote Service</name>    <bindingTemplates>         <bindingTemplate                  bindingKey="f793c521-0daf-434c-8700-0e32da232e74”                  serviceKey="102b114a-52e0-4af4-a292-02700da543d4">             <accessPoint URLType="http">                 http://location/sample             </accessPoint>             <tModelInstanceDetails>                 <tModelInstanceInfo                       tModelKey="urn:wsdm.org:QoS-attributes">                      <description xml:lang="en"> This is the reference to the tModel that will have all of the QOS related categories attached.                      </description>                 </tModelInstanceInfo>                 <tModelInstanceInfo                       tModelKey="urn:wsdm.org:QoS-detail">                      <description xml:lang="en">                          This points to the tModel that has the reference to the web service endpoint that allows detailed retrieval of information                      </description>                 </tModelInstanceInfo>             </tModelInstanceDetails>         </bindingTemplate>    </bindingTemplates></businessService

Below is an example of the tModel that categories for QoS attributes will be embedded in.

<tModel tModelKey="urn:wsdm.org:QoS-detail" >    <name>         QoS Information for Stock Quote Service     </name>    <overviewDoc>         <overviewURL>             http://<URL describing schema of QoS attributes>         <overviewURL>

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 9 of 15

    <overviewDoc>    <categoryBag>         <keyedReference              tModelKey="urn:wsdm.org:metric:RequestCount"         keyName=”Request Count”              keyValue="574"/>         <keyedReference              tModelKey="urn:wsdm.org:metric:ReplyCount"         keyName=”Reply Count”              keyValue="572"/>         <keyedReference              tModelKey="urn:wsdm.org:metric:ReplyCount"         keyName=”Fault Count”              keyValue="2"/>         <keyedReference              tModelKey="urn:wsdm.org:QoS:ResponseTime_Average"         keyName=”ResponseTime Average”             keyValue=”0.1” />    </categoryBag></tModel>

3.1 More Detailed QoS Information

In addition to having summary management information available, we want to allow WSDL-defined web services that return additional WSM metric details to be returned. These services will typically provide more (and more current) information than is reflected in the UDDI registry. We expect that such a service will use the standard WSDM interface, though other non-standard interfaces would be supported as well. (This may add a capability to categorize an interface as a management interface.) WSDM is currently developing the specification for query of metric information from a manageability provider. The first release of the specification is expected to model that providers information as a resource property document, following the model defined for WS-ResourceProperties (part of the WS-ResourceFramework set of specifications). An example of such a query follows:

 <wsrp:GetResourcePropertyRequest xmlns:wsdmQos=”urn:wsdm.org:Qos”>    wsdmQos:ResponseTime_Average </wsrp:GetResourcePropertyRequest>

Note: This is preliminary and non-normative. The actual specification of the request format will be defined by the WSDM technical committee.

Management services should be stored in UDDI using the “Using WSDL in a UDDI Registry, Version 2.0” Technical Note. That is, their WSDL information will be decomposed and placed into the appropriate UDDI objects. Specifically the port information from the WSDL for the management service will be placed into a UDDI bindingTemplate contained inside a businessService for the management service. The managed service (the web service being described) will then refer to bindingTemplate of its management service by referring to a tModel, which itself points to the management service’s bindingTemplate.Specifically, the tModel that points to the bindingTemplate for the management service is added to the bindingTemplate’s tModelInstanceDetails . The tModelKey will be something like “urn:wsdm.org:QoS-detail” (for UDDI V2 it would be a standard numeric UUID equivalent of this

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 10 of 15

friendly UUID). The keyValue will contain the unique serviceKey for the binding template of the management service.

For URL-accessible reports (retrievable via an 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:wsdm.org:QoS-report”. The keyValue will 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.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 11 of 15

4 References4.1 Normative [WSDL-UDDI] “Using WSDL in a UDDI Registry, Version 2.0” - http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm[UDDI-Data] “UDDI Data Structure Reference”, http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm[WSDM-Arch] “WSDM Architecture” [preliminary], http://www.oasis-open.org/committees/download.php/5210/WSDM-MUWS-Architecture-Draft%5B1%5D20031208.doc[WSDM-MOWS] “WSDM Management Of Web Services Specification” [preliminary], http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/5530/wd-wsdm-mows-05.doc[WSDM-MUWS] “WSDM Management Using Web Services Specification” [preliminary], http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/5569/wd-wsdm-muws-0%5B1%5D.5-20040219.doc

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 12 of 15

Appendix A. Acknowledgments

The authors would like to thank Rick O’Herron of AmberPoint, Zdenek Svoboda and Mirek Novotny of Systinet, Anne Thomas Manes of the Burton Group, Tom Bellwood and Andrew Hately of IBM, Tony Rogers of CA, Maud Cahuzac and Shishir Garg of France Telecom, Daniel Feygin of UnitSpace and Luc Clement for their help and feedback on this document.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 13 of 15

Appendix B. Revision History

Rev Date By Whom What

1 2/13 Adam Blum, Fred Carter

Initial TN proposal coming out of February 2004 F2F in San Francisco.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 14 of 15

Appendix C. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.Copyright © OASIS Open 2004. All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

document.doc 13 February 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 15 of 15