Note On UDDI
What is UDDI
Web service standards have made outstanding progress. However, let's take a quick step backwards to examine an older standard called Universal Description, Discovery and Integration of Web services (UDDI).
The UDDI specification defines a SOAP-based Web service for locating Web services and programmable resources on a network. It offers a foundation for sharing information about internal services across the enterprise and public services on the Internet.1
UDDI Programming Model
XML Web Services has been the toast of the .NET Framework, however Web Services are not a .NET invention – they were available before .NET. So why are they so popular under .NET? Because the set of tools available under Microsoft .NET Framework lets the developer build sophisticated Web Services with little difficulty. Developers are embracing Web Services at an exponential rate under the .NET framework. With this popularity increase, UDDI is emerging as the preferred mechanism to discover the Web Services. This article is aimed at advanced users familiar with UDDI so I will be skipping the introductory lessons and dive into UDDI details from the start. In the second half of this article we will put our knowledge into use by building an ASP.NET UDDI browser using web forms.
We will first explore the UDDI data structures, then we will investigate the UDDI API version 2.0, this is the most recent version of the UDDI API. The best place to find more technical details on UDDI is www.uddi.org.
UDDI API Data Structures
UDDI has 4 main data structures.
All the information is stored as predefined XML formats. First we will try to understand the responsibilities of each structure. Then we will learn how these structures work together to create UDDI.
Business information ( businessEntity XML Format)
Service Information ( businessService XML Format)
Binding Information ( bindingTemplate XML Format)
Specifications for the services offered ( tModels XML Format)
businessEntity Data Structure
You only need a businessEntity element to publish data within a UDDI repository. The other data elements are optional. During the discovery phase, the businessEntity element serves as a handle to retrieve pertinent information about a company.
businessService Data Structure
Service information deals with technical and business descriptions. Each Web Service has one or more technical web descriptions. These technical descriptions include information to communicate with clients. Those could be:
URLs, addresses to communicate to child Web Services.
Configuration options on the host web server.
Prerequisite Web Services that should run before this Web Service.
Load Balancing information on the host web server.
bindingTemplate Data Structure
The information about invoking a Web Service is documented in a XML structure called bindingTemplate.. The bindingTemplate"binds" technical and business data to a Web Service. So what information do we bind? We need to know all the technical information for seamless integration of the Web Service. Here are some of those questions if we implement a Web Service to handle purchase orders.
We need to know the format of our purchase orders?
Are they in a specific XML format geared towards online transactions? (eg. OBI – Open Buying on Internet)
What are the required security implications to access purchase orders?
In order to integrate the Web Service we need to answer all these questions, therefore we need XML structures to represent this information inside the Web Service bindings. These structures are commonly referred to as "tModel".
tModel Data Structure
This is probably the most interesting data structure. UDDI draws a distinction between abstraction and implementation with its concept of tModels. The tModel structure, short for "Technology Model", represents technical fingerprints, interfaces and abstract types of metadata. Binding templates are the concrete implementation of one or more tModels. Inside a binding template, one registers the access point for a particular implementation of a tModel. tModels can be published separately from the binding templates that reference them.
Each tModel also gets a unique identifier, this will enable other applications to refer to it, these tModels make up bindingTemplate structures. The tModels represent all the integration information to consume a Web Service. The different service providers can easily build a software product to consume the Web Service as long as the tModels are compatible.
check this link for more details
http://www.microsoft.com/windowsserver2003/technologies/idm/uddi/default.mspx
