In the previous four issues of .NET UPDATE, I've examined changes to the Universal Description, Discovery, and Integration (UDDI) 3.0 specification. In this issue, I explain how the UDDI specification improves the discovery model—that is, how users and applications can find the files they need in a UDDI registry. These changes include query nesting, new ways of tailoring the results of a search, extended support for wildcards, and a method of breaking large numbers of results into manageable pieces.
Complex Queries
Three of the "find" APIs that users and applications employ to search UDDI registries—find_binding, find_business, and find_service—support nested queries. In a nested query, one or more of the arguments that a user or application supplies to these APIs can be another query; the query results are filtered according to both queries instead of only the topmost one. Working with one nested query, an API can find information that otherwise would require at least two unnested queries. Such complex querying lets users and applications focus a search more easily and reduces the number of searches required to achieve targeted results.
New Find Qualifiers
Even if a search doesn't need complex queries, find qualifiers might be necessary to focus the results of that search. A find qualifier limits the results of a search. For example, you can use a find qualifier to make a search case sensitive or to search for matches that are similar to the search criteria but not identical to it. (You must specify this behavior when setting up a query because, by default, UDDI returns only exact matches.) UDDI 3.0 supports both tModel keys with find qualifiers and short names representing find qualifiers; UDDI 3.0-compliant registries must support both methods. Not all search APIs support all find qualifiers; a table in the UDDI 3.0 specification lists search APIs, the qualifiers each API supports, and the correct syntax. New to UDDI 3.0 is a standard for wildcard syntax that uses the SQL-99 format of substituting a percent sign (%) for any number of characters and an underscore (_) for a single character.
Paging Through Results
Complex queries and find qualifiers can focus a search of a UDDI registry, but the result set might still be too large to take in at one gulp. Therefore, just as Google placed the 612 results of my query "UDDI, discovery, limit results to microsoft.com" onto multiple pages at 10 results per page, a UDDI query can use the listdescription element to organize the results of a search into pages. The optional listdescription element has three values: includecount (the total number of matches for a particular query), actualcount (the number of all available matches at the time the query was made), and listhead (the index position of the first element of the returned result set within all available matches after any sorting has been applied). If a result set is too large to be returned within one group, it will contain the listdescription element with a listhead value that indicates the first match in that result set. For example, if the result set displays matches 10 through 20, then the listhead value for the first match displayed will be 10. The listhead value is not permanently associated with any particular match—it's only a placeholder that tells listdescription where to start displaying results if a display begins with a particular element.
For more details, and to examine the complete UDDI 3.0 specification, go to
http://uddi.org/pubs/uddi_v3.htm
End of Article
Register
