The first article in this series (see Resources) introduced and described the new approach to constructing a UDDI model of a WSDL description. This article describes the types of UDDI query that are enabled by this new approach, with examples of several queries given in the form of UDDI V2 API requests.
The third article will present a more complex example than the one in the Technical Note, including screen shots showing how to publish the UDDI entities and how to construct the types of query described in the Technical Note.
The final article will describe how to write Java applications that can publish these models to UDDI and issue the queries, using UDDI4J.
The queries described here can be issued at design/build time or at run time, depending on the type of application being developed, but the main scenario considered during the production of the new Technical Note was that at design/build time, a portType is chosen and, if necessary a particular binding, from which a stub or similar programming artifact is generated. At run time, implementations of this portType and, optionally, binding are searched for.
It is important to note that although the Technical Note describes only the WSDL-related information, it is valid to add other information to the UDDI model such as industry classifications, or owning business etc. and this information can also be used when querying.
Unless specifically querying for tModels corresponding to both portTypes and bindings, a keyedReference with the appropriate value from the WSDL Entity Type Category System should always be included so that only tModels of the correct type are returned.
Listing 1 shows a simple query for a portType tModel with a name of StockQuotePortType
Listing 1. Simple query by name of portType tModel
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<name>StockQuotePortType</name>
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyValue="portType"/>
</categoryBag>
</find_tModel>
|
Listing 2 shows a query for a portType tModel with a name of StockQuotePortType, a namespace of http://example.com/stockquote/ and an industry classification of 52312 (Securities Brokerage) in the NAICS Category System.
Listing 2. Query for portType tModel using WSDL and other criteria
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<name>StockQuotePortType</name>
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyValue="portType"/>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyValue="http://example.com/stockquote/"/>
<keyedReference
tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"
keyValue="52312"/>
</categoryBag>
</find_tModel>
|
If the name and/or the namespace name of the binding is known then the same types of query as described for portType tModels can be used to find bindings, but the most common type of query for bindings is likely to be finding bindings of a particular portType, once the tModel corresponding to the portType is known.
Listing 3 shows a query for binding tModel(s) that represent binding(s) for a portType that has a corresponding portType tModel with a key of uuid:11111111-1111-1111-1111-111111111111.
Listing 3. Query for all binding tModels for a portType tModel
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyValue="binding"/>
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyValue="uuid:11111111-1111-1111-1111-111111111111"/>
</categoryBag>
</find_tModel>
|
The first keyedReference in the categoryBag is not required. However, it is recommended that it is used when finding binding tModels using the portType Reference Category System as it is likely that a future Technical Note or Best Practice will extend the use of the portType Reference Category System to also model relationships between portTypes, so including a keyedReference from the WSDL Entity Type Category System will ensure that only binding tModels are returned.
The query in Listing 3 will return all bindings for a portType, regardless of the protocol and/or transport specified in the binding. If a particular protocol and/or transport is required, then extra keyedReferences from the Protocol Category System and/or the Transport Category System can be added as necessary. Listing 4 shows a query that is specific about the protocol (SOAP) and transport (HTTP) that is required.
Listing 4. Query for a specific type of binding tModel for a portType tModel
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyValue="binding"/>
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyValue="uuid:11111111-1111-1111-1111-111111111111"/>
<keyedReference
tModelKey="uuid:4dc74177-7806-34d9-aecd-33c57dc3a865"
keyName="SOAP protocol"
keyValue="uuid:aa254698-93de-3870-8df3-a5c075d64a0e"/>
<keyedReference
tModelKey="uuid:e5c43936-86e4-37bf-8196-1d04b35c0099"
keyName="HTTP transport"
keyValue="uuid:68DE9E80-AD09-469D-8A37-088422BFBC36"/>
</categoryBag>
</find_tModel>
|
If you wish to query businessServices in their own right, as opposed to querying them as part of querying bindingTemplates, then you can use any combination of the WSDL-related information (the service name, its namespace, and the fact that the businessService corresponds to a WSDL service) and generic UDDI information, primarily categorizations of the service.
Listing 5 shows a query for a businessService with a local name of "StockQuoteService" and a namespace of http://example.com/stockquote/. Note that the local name is queried for using a keyedReference in the categoryBag and not as the name of the businessService. As is mentioned in the Technical Note, it is valid to map a WSDL service to an existing UDDI businessService, in which case it cannot be assumed that the businessService name matches the WSDL service name, so the WSDL service name is always stored in the businessService categoryBag and it should always be this keyedReference that is used when querying based on the WSDL service name.
Listing 5. Query for a businessService corresponding to a WSDL service
<find_service generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyValue="service"/>
<keyedReference
tModelKey="uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6"
keyValue="StockQuoteService"/>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyValue="http://example.com/stockquote/"/>
</categoryBag>
</find_tModel>
|
When querying bindingTemplates using the UDDI V2 API, it is necessary to first query services as the V2 find_binding API requires a serviceKey.
If the query for bindingTemplates is being made without reference to any of the service-related information then only the tModelBag will be used, but it is possible to do a query that combines some of the information relating to the service, as described in the previous section, with the port/bindingTemplate information in the tModelBag.
The query for bindingTemplates can be made based on either a portType tModel or a binding tModel.
If implementations of all bindings for a portType are required, then the query should use the key of the tModel corresponding to the portType.
If implementations of only a single binding of a portType are required, then the correct binding tModel must be found and the key of that binding tModel used in the find_binding query.
If implementations of a subset of all bindings of a portType are required, then multiple tModel keys must be supplied in the tModelBag and the orAllKeys findQualifier must be supplied otherwise no bindingTemplates will be returned as each bindingTemplate will only refer to a single binding tModel so if multiple binding tModel keys are supplied with the default andAllKeys behaviour then no bindingTemplates will match.
If multiple services are returned then a find_binding call must be made for each one unless all but one of the returned services are discarded.
Listing 6 shows a find_service query followed by a find_binding query to find the bindingTemplate corresponding to a port that represents an implementation of the portType that is modeled by a tModel with a key of uuid:11111111-1111-1111-1111-111111111111.
Listing 6. Query for an implementation of a portType
<find_service generic="2.0" xmlns="urn:uddi-org:api_v2">
<tModelBag>
<tModelKey>uuid:11111111-1111-1111-1111-111111111111<tModelKey>
</tModelBag>
</find_service>
<find_binding serviceKey="key returned by previous query"
generic="2.0" xmlns="urn:uddi-org:api_v2">
<tModelBag>
<tModelKey>uuid:11111111-1111-1111-1111-111111111111<tModelKey>
</tModelBag>
</find_binding>
|
Note that the tModelBag is the same in both queries.
Listing 7 shows a similar query but this time some of the service-related information is also used, namely the desired namespace name.
Listing 7. Query for a an implementation of a portType in a particular namespace
<find_service generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyValue="service"/>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyValue="http://example.com/stockquote/"/>
</categoryBag>
<tModelBag>
<tModelKey>uuid:11111111-1111-1111-1111-111111111111<tModelKey>
</tModelBag>
</find_service>
<find_binding serviceKey="key returned by previous query"
generic="2.0" xmlns="urn:uddi-org:api_v2">
<tModelBag>
<tModelKey>uuid:11111111-1111-1111-1111-111111111111<tModelKey>
</tModelBag>
</find_binding>
|
This article has described what are likely to be the most common types of query issued against the new UDDI model for WSDL descriptions. The approach described in the Technical Note allows flexible and precise queries to be issued that can include both WSDL-related information and other information, such as industry classification.
The next article in this series will apply the approach described in the Technical Note to a sample WSDL description and show how to issue some of the types of queries described in this article.
- Read the other parts of this series:
- "A new approach to UDDI and WSDL, Part 1" (developerWorks, August 2003) describes the new Technical Note on using WSDL and UDDI together.
- "A new approach to UDDI and WSDL, Part 3" (developerWorks, October 2003) describes how to publish and query the UDDI model for the WS-I Sample Application, following the approach defined in the new Technical Note.
- "A new approach to UDDI and WSDL, Part 4" (developerWorks, October 2003) describes how to publish and query the UDDI model for the WS-I Sample Application, following the approach defined in the new Technical Note.
- "A new approach to UDDI and WSDL, Part 5" (developerWorks, October 2004) describes how to apply the approach defined in the new OASIS UDDI Technical Note to query from a Java application.
- The OASIS UDDI Specifications Technical Committee is now responsible for UDDI standards.
- This article is based on the Technical Note "Using WSDL in a UDDI Registry, Version 2.0" which has recently been published as an official Technical Note by the OASIS UDDI Specifications Technical Committee.
- The previous Best Practice "Using WSDL in a UDDI Registry, Version 1.08" has been updated by the OASIS UDDI Specifications Technical Committee since the previous developerWorks articles were written.
- Access Web services knowledge, tools, and skills with Speed-start Web services, which offers the latest Java-based software development tools and middleware from IBM (trial editions), plus online tutorials and articles, and an online technical forum.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Comments (Undergoing maintenance)





