UDDI Publishing with C#
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Listing your web service in the UDDI registry is an easy but detailed procedure. Naresh Apte and Toral Mehta discuss the steps for getting it right.
Naresh Apte and Toral Mehta are co-authors of UDDI: Building Registry-Based Web Services Solutions (Prentice-Hall PTR, 2002, ISBN 0130464570).
Web services technologies—arguably the next frontier of enterprise software—are getting immense attention in the information technology (IT) industry today. Initiatives by companies such as Microsoft, IBM, SAP, and Salesforce.com attest to the fact that technology vendors are looking seriously at web services.
One technology in the web service technology stack is Universal Description, Discovery, and Integration (UDDI). In a nutshell, 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 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 application programming interfaces (APIs) involved in the process of registration (called publishing) with a UDDI registry.
UDDI APIs
The UDDI specification, released by the UDDI.org council and later by the Organization for the Advancement of Structured Information Standards (OASIS), describes how to interact with a UDDI registry using XML documents. While this provides the language independence necessary for widespread adoption, it does pose one limitation: Structured documents (such as XML documents) are easy for computers to understand, but human beings cannot process them well. Constructing or editing an XML document is a tedious and error-prone job for a person. Thus, it would be difficult to author an XML document that represents a find_business query and then decipher the XML response from the registry. For that purpose, you need a user interface such as a web page or form.
The need for a suitable user interface automatically implies the need for a programming language. To facilitate interaction between user interface and registry, you need a set of APIs. And for easy interoperability, these APIs should be written in the same programming language used for the user interface or business logic. These needs have given rise to several language-specific UDDI APIs. Figure 1 shows the relationship between language-specific APIs and the UDDI APIs. The language-specific APIs manage the XML communications for the application layer.
)
Figure
1 Relationship between language-specific APIs and UDDI APIs.
This article provides examples using the UDDI .NET SDK in C#.