UDDI Inquiry with C#
My previous article in this series on Universal Description, Discovery, and Integration (UDDI) described how application programming interfaces (APIs) are used for publishing to a UDDI registry. Publishing APIs are used by service providers to advertise and offer their services to potential users. Service users, on the other hand, must explore a UDDI registry for potential service providers who can satisfy their needs. UDDI provides inquiry APIs for this purpose.
Here's a quick refresher on UDDI.
UDDI is a registry in which business entities, the services they offer, and the interfaces (tModels) for those services can be registered by potential service providers. The registration includes a vocabulary for describing these resources; service consumers can then discover the registered resources and use them as needed. If the description vocabulary is standardized, it makes the task of description and discovery easier, and could even be automated. Functionally, a UDDI registry can be thought of as a directory in which "white pages" contain the business contact information and "yellow pages" contain the categorized information about services offered by various businesses. UDDI also contains "green pages" that describe the service interaction interfaces.
Other InformIT articles provide a high-level overview of the UDDI technology; this article focuses on the APIs involved in the process of finding services (called inquiry) with a UDDI registry.
As noted in the previous article, the UDDI specification has undergone several revisions. Version 3 is the most recent specification, but most of the current implementations of UDDI in production still implement Version 2 (most notably, those of Microsoft and IBM). This article therefore focuses on the APIs related to Version 2 of the specification.
Inquiry APIs
Like the publish APIs, the inquiry APIs use a dedicated uniform resource locator (URL) at a registry. This inquiry URL can be used to retrieve information about registered entities such as businesses, services, and tModels. The inquiry URL accepts XML messages that perform tasks, such as the following (all but the last of which also include getting registration details):
Business entity discovery
Service discovery
Service binding discovery
Taxonomy discovery
Interaction specification discovery
Business relationships discovery
For a complete list, refer to the latest UDDI API specification document.
Figure 1 depicts the role of the inquiry URL in a UDDI registry. The inquiry URLs for the Universal Business Registry (UBR), a global pool of UDDI registries, would normally take the following form:
http://uddi.tasmanAve.com/inquiry
Figure 1 UDDI interactions supported on inquiry URL.
Unlike the publish URL, the inquiry URL doesn't use a secure mode of communication, because inquiry APIs don't need sensitive data such as usernames and passwords. The information being retrieved is also considered public domain; therefore, the publisher should be careful about the kind of data that's published at a UDDI registry. Any user with access to the registrywhether or not the user is registered with the registrycan access the information published by the publisher. (However, a private UDDI registry with greater access control can implement more restrictive policies. An invitation-only or more elaborate registration process can control access to the registry.)