Summary
As enterprises build a critical mass of Web services, they need some way of keeping track of those services. UDDI is an ideal store for such information. Using UDDI's built-in abstractions of business services, binding templates, and tModels referring to interface specifications, UDDI can be used to manage all of the addresses and protocols and formats of those services.
As enterprises build a critical mass of Web services, they need some way of keeping track of those services. UDDI is an ideal store for such information. Using UDDI's built-in abstractions of business services, binding templates, and tModels referring to interface specifications, UDDI can be used to manage all of the addresses and protocols and formats of those services. This information can be used for several purposes, including providing location independence and identification of common supported interfaces among those services. But the amount of information tracked on each Web service is a small subset of the information that companies truly need to manage for each of these services. Developers want to access the actual formats used by those Web services within the registry. This includes objects from the WSDL descriptions of Web services, such as portTypes, and also includes other artifacts associated with Web services such as XML Schemas to represent types used by those WSDLs. They also want to be able to keep track of the versions of those Web services and their associated objects. IT administrators typically want to know a variety of information on each Web services' quality of service. They also want to know who has access to those services, and what applications and Web services may be dependent on those services. This article discusses how UDDI can be used as this more robust registry of extensive information on each Web service. It describes UDDI tModels for categorization and shows how they are used in the "Using WSDL in a UDDI Registry, Version 2.0" Technical Note [WSDL-UDDI] to represent all of the information present in WSDL in UDDI. It then describes how the techniques used by the WSDL mapping technical note can be used to represent new classes and attributes of information generally. We then show how to use these techniques to represent versioning information of Web service objects and quality of service information for a Web service. My company is working with the UDDI Technical Committee as well as customers and partner companies to create Technical Notes in each of these areas: versioning and quality of service metrics. Our hope is that the techniques developed in these areas will be useful models to extending UDDI to cover other areas of describing Web services mentioned above as well. UDDI tModelstModels, short for technical models, can register two types of things: specifications and categorizations. Specifications describe the Web service and can be expressed in Web Service Description Language (WSDL) files, XML Schema definitions, policy expressions, or just a reference to a Web page for a spec. Categorization tModels provide an extensible mechanism for adding property information to a UDDI entity. The uddi-org:types category indicates which type of tModel is at hand. The following example below demonstrates how to define a categorization tModel, and how to use a categorization tModel to categorize a UDDI entity. This tModel entity represents the WSDL Transport Categorization tModel as defined in the WSDL mapping technical note. It's used to specify what type of transport is supported by a Web service. This tModel includes a categoryBag that defines the tModel as a checked categorization tModel (see Listing 1).Entities are categorized with the keyedReference structure on a categoryBag. A keyedReference element has a tModelKey attribute that refers to the unique ID of the categorization tModel. In this example, the tModelKeys in the two keyedReference structures refer to the uddi-org:types tModel. The keyName attribute is purely for human readability. The keyValue attribute contains the value for the category. The first keyedReference specifies that the tModel represents a taxonomy. The second keyedReference specifies that the values specified for the taxonomy are checked against a defined value set. Taxonomies used for categorization may have validated value sets or may support arbitrary values. WSDL MappingWSDL files describe a Web service's interfaces (portTypes), their encoding formats and transport protocols (bindings), specific endpoint locations (ports) that implement a binding, and services that contain a collection of named ports. Some of this information already exists in UDDI in some form. Specifically, WSDL ports are mapped to UDDI bindingTemplates. The bindingTemplate's tModelInstanceDetails collection points to the tModels generated for the WSDL portType and binding (described below). WSDL services are represented as UDDI businessService entities. More interesting than these mappings is how to represent WSDL artifacts that are not already present in UDDI.WSDL PortTypes Each portType tModel contains a categoryBag with at least two keyedReference structures. The first keyedReference indicates the type of WSDL artifact, and the second keyedReference indicates the namespace of the portType. The first keyedReference specifies the tModelKey referring to the WSDL Entity Type tModel (uddi-org:wsdl:types), which is a checked taxonomy of WSDL entity types. The taxonomy defines four allowed values: portType, binding, port, and service. The keyValue in this keyedReference will be "portType". The second keyedReference specifies the tModelKey referring to the XML Namespace tModel (uddi-org:xml:namespace), which is an unchecked taxonomy. The keyValue in this keyedReference will contain the target namespace of the WSDL document that defines the portType. These taxonomies are defined in the WSDL mapping technical note. WSDL Bindings
Techniques for Information ExtensionLooking at how WSDL bindings and portTypes were represented in UDDI, we can see some generally useful approaches to putting new types of information associated with Web services into the registry.tModels as Classes A QoS Information tModel could also be referenced directly from the businessService entity or from a UDDI version 3 bindingTemplate entity using a keyedReference structure in the entity's categoryBag. Categories as Attributes Versioning InformationLet's try to put these techniques to work to represent some of the other information about Web services discussed above. One particular area of interest we have heard from many customers is a standard way of representing the versions of various Web service objects: business services, binding templates, portType tModels, and binding tModels. It would be helpful to categorize each of these objects with:
Listing 2 shows you how to use all of these taxonomies to categorize a portType tModel as version 2.1, build 1241, and the latest revision. It also uses the "versioning-component" tModel with a value of "StockQuoteSampleComponent" to tie together the portType with other UDDI objects (business services, binding templates, binding tModels, other portType tModels, and other versions of the portType tModel). The versioning-component taxonomy is used to establish an association between two versions of the same object. That is, it can be used to establish that two portType tModels are versions 1 and 2 of the same interface (relying on the name is not a reliable way of doing that). It can also be used to associate various UDDI objects as part of the same component. As portType tModels get replaced, there may not be a bindingTemplate that points to the old versioned portType tModels. So using this "versioning-component" is a reliable way to be able to ask "give me all of the UDDI objects associated with version n of this component" (rather than relying on business services containing binding templates which point to all supported tModels. Quality of Service InformationFor another example of extending UDDI with more information, let's also provide a method of representing quality of service metrics. Systinet is working with AmberPoint, a leading Web services management vendor, to author a Technical Note in this area. The example below represents an approximation of the currently envisioned approach, but this may change by the time the TN is released.In this example, we represent quality of service information for each Web service deployment by generating a tModel for quality of service information for the binding template that represents the deployment. We then assign properties for each QoS metric on the generated tModel using keyedReferences. This QoS information allows companies to track the actual delivered quality of service of a particular physical implementation of a Web service according to many criteria. Examples of this might be classifications of average response time (fast, medium, slow), categories of average throughput (>10 Mbps, 1-10Mbps, <1Mbps), and overall reliability (99.99%, 99.9%, 99%). Listing 3 is an example of the bindingTemplate reference to the tModel that will have the QoS attribute categories attached. It starts with the Stock Quote Service example used in the WSDL mapping technical note, but for simplicity does not include the WSDL artifacts that the example uses. In order to retrieve more detailed management information, we store the location of a WSDL in a keyed reference with tModelKey "uddi:uddi.org:QoS-Detail". This tModel has the reference to a binding template of a "management Web service" endpoint which provides operations for more detailed analysis of the given Web service's performance. Listing 4 is an example of the QoS Information tModel, which contains a categoryBag specifying QoS metrics. Additional Standards for Enhanced Web Services InformationWe've just described how a given company can use the extensibility methods in UDDI to track more extensive information about Web services than just their locations, access protocols, and supported formats. Specifically, we have shown how we can use categories on UDDI objects to represent both versioning information and quality of service information. As mentioned, we expect to finalize Technical Notes working with the OASIS UDDI TC, in these areas as well.In addition, we are helping to create ways of representing other classes of Web services information, as additional technical notes under the aegis of OASIS' UDDI Technical Committee. Some of the areas that we think are of most immediate value to track for each Web service include:
SummaryUDDI is an excellent basis for an enterprise Web services registry. Incremental standards such as the "Using WSDL in a UDDI Registry" technical note demonstrate methods of storing additional information in UDDI. Companies can start leveraging these approaches to add more information on additional attributes of Web services, such as quality of service and versioning information, to their enterprise UDDI registries. Incremental standards in the form of UDDI Technical Notes are emerging for these attributes of Web services and others to allow tracking of this information.AcknowledgementsThanks to Anne Thomas Manes, Zdenek Svoboda, Mirek Novotny, Fred Carter, and Luc Clement for helpful feedback on topics related to this article.References |
|
About the author
Related Sites
|
