All truths are easy to understand once they are discovered; the point is to discover them.
What is UDDI?
Universal Description and Discovery Information (UDDI) is a type of registry whose primary purpose is to represent information about web services. It describes the service providers, the services that provider offers, and in some cases, the specific technical specifications for interacting with those services. While UDDI was originally envisioned as a public, platform independent registry that companies could exploit for listing and consuming services, it seems that many have chosen instead to use UDDI as an internal resource for categorizing and describing their available enterprise services.
Besides simply listing available services for others to search and peruse, UDDI is arguably most beneficial for those who wish to perform runtime binding to service endpoints. Instead of hard-coding a service path in a client application, one may query UDDI for a particular service's endpoint and apply it to their active service call. While UDDI is typically used for web services, nothing prevents someone from storing information about any particular transport and allowing service consumers to discover and do runtime resolution to these endpoints. As an example, this is useful if you have an environment with primary, backup, and disaster access points and want your application be able to gracefully look up and failover to the next available service environment. In addition, UDDI can be of assistance if an application is deployed globally but you wish for regional consumers to look up and resolve against the closest geographical endpoint.
UDDI has a few core hierarchy concepts that you must grasp to fully comprehend how the registry is organized. The most important ones are included here.
Name in Microsoft UDDI services
These are the service providers. May be an organization, business unit or functional area.
General reference to a business service offered by a provider. May be a logical grouping of actual services.
Technical details of an individual service including endpoint
tModel (Technical Model)
Represents metadata for categorization or description such as transport or protocol
As far as relationships between these entities go, a Business Entity may contain many Business Services, which in turn can have multiple Binding Templates. A binding may reference multiple tModels and tModels may be reused across many Binding Templates.
What's new in UDDI version three? The latest UDDI specification calls out multiple-registry environments, support for digital signatures applied to UDDI entries, more complex categorization, wildcard searching, and a subscription API. We'll spend a bit of time on that last one in a few moments.
Let's take a brief lap around at the Microsoft UDDI Services offering. For practical purposes, consider the UDDI Services to be made up of two parts: an Administration Console and a web site. The website is actually broken up into both a public facing and administrative interface, but we'll talk about them as one unit.
The UDDI Configuration Console is the place to set service-wide settings ranging from the extent of logging to permissions and site security.
The site node (named UDDI) has settings for permission account groups, security settings (see below), and subscription notification thresholds among others.
The web node, which resides immediately beneath the parent, controls web site setting such as logging level and target database.
Finally, the notification node manages settings related to the new subscription notification feature and identically matches the categories of the web node.
The UDDI Services web site, found at http://localhost/uddi/, is the destination or physically listing, managing, and configuring services.
The Search page enables querying by a wide variety of criteria including category, services, service providers, bindings, and tModels.
The Publish page is where you go to add new services to the registry or edit the settings of existing ones.
Finally, the Subscription page is where the new UDDI version three capability of registry notification is configured. We will demonstrate this feature later in this article.
How to add services to the UDDI registry?
Now we're ready to add new services to our UDDI registry. First, let's go to the Publish page and define our Service Provider and a pair of categorical tModels. To add a new Provider, we right-click the Provider node in the tree and choose Add Provider.
Once a provider is created and named, we have the choice of adding all types of context characteristics such as a contact name(s), categories, relationships, and more.
I'd like to add two tModel categories to my environment : one to identify which type of environment the service references (development, test, staging, production) and another to flag which type of transport it uses (Basic HTTP, WS HTTP, and so on). To add atModel, simply right-click the tModels node and choose Add tModel.
This first one is named biztalksoa:runtimeresolution:environment.
After adding one more tModel for biztalksoa:runtimeresolution:transporttype, we're ready to add a service to the registry. Right-click the BizTalkSOA provider and choose Add Service. Set the name of this service toBatchMasterService.
Next, we want to add a binding (or access point) for this service, which describes where the service endpoint is physically located. Switch to the Bindings tab of the service definition and choose New Binding. We need a new access point, so I pointed to our proxy service created earlier and identified it as an endPoint.
Finally, let's associate the two new tModel categories with our service. Switch to the Categories tab, and choose to Add Custom Category. We're asked to search for atModel, which represents our category, so a wildcard entry such as %biztalksoa% is a valid search criterion.
After selecting the environment category, we're asked for the key name and value. The key "name" is purely a human-friendly representation of the data whereas the tModel identifier and the key value comprise the actual name-value pair. I've entered production as the value on the environment category, and WS-Http as the key value on thetransporttype category.
At this point, we have a service sufficiently configured in the UDDI directory so that others can discover and dynamically resolve against it.
Dynamic endpoint resolution via UDDI
Speaking of resolving, how do we actually call into a UDDI directory from code and discover information (including the endpoint) about a service? Let's take a look.
From within our command-line client application, we need to add a reference to the Microsoft.Uddi.dll. You should find this at C:Program FilesMicrosoftUDDI ServicesSDKMicrosoft.Uddi.dll. We'll first look at the scenario where you already know the service key for the service. What is the service key and how do you find that? On the Details page of your service in the directory, there is a More Details link which opens up a window containing both the UDDI V2 and V3-compatible keys.
Armed with this exciting piece of information, we're ready to look up our service. In the code below, you should see that I have a reference to the UDDI library, and have created a connection that points to the query service URI provided by the UDDI Services. Next, I ask for the details of the service based on the key and connection I've provided.
UddiConnection conn =
GetServiceDetail getDetails =
new GetServiceDetail("uddi:f1032d83-9469-4d3b-8a03-93fe606cd34f ");
ServiceDetail details = getDetails.Send(conn);
Once we have the service details in response, we are capable of discovering all sorts of things about our service.
//add pointer to target service
BusinessService service = details.BusinessServices;
Console.WriteLine("Service Name: " + service.Names.Text);
Console.WriteLine("Access Point: " +
KeyedReferenceCollection categories =
Console.WriteLine("** Categories **");
foreach (KeyedReference catKey in categories)
Console.WriteLine("Category Name: " + catKey.KeyName);
Console.WriteLine("Category Value: " + catKey.KeyValue);
The result of this block of code reveals all of the entries we added to our UDDI directory just a short time ago.
Now what if we don't know the service key? Fortunately for us, the UDDI service API also provides a query interface. If we want to search by service name, or by a set of categories we can.
Console.WriteLine("Calling UDDI query lookup service");
UddiConnection conn =
FindService serviceQuery =
ServiceList queryResult = serviceQuery.Send(conn);
string key = queryResult.ServiceInfos.ServiceKey;
Console.WriteLine("Service key: " + key);
When this code runs, we get back a key corresponding to our service in the registry.
The query scenario is useful if you want to do runtime resolution of a service within a given environment (say, production) and enable the UDDI administrators to re-point users to available services if the primary service is down. An administrator could perform this task by simply changing UDDI category values.
Building subscription alerts for service changes
One of the new features in UDDI V3 is the ability to subscribe to changes that occur within the UDDI directory. That is, we can build service listeners which act when UDDI objects (providers, services, and so on) undergo revision.
The Microsoft UDDI Service conforms to the official UDDI standard, and thus complies with WSDLs hosted at http://www.uddi.org. So, in order to build a listener service that UDDI Services will consume, create a service library with a service reference to the relevant WSDL on http://www.uddi.org. How do we do this? First, point the WCF svcutil.exe tool at the public WSDL:
svcutil http://uddi.org/wsdl/uddi_subr_v3_portType.wsdl /out:
Take the resulting class, and add it to a new class library project in Visual Studio.NET.
The interface generated by the WCF svcutil.exetool is not completely accurate according to the message sent by Microsoft UDDI Services. Specifically, the generated interface UDDI_SubscriptionListener_ PortTypehas an operation named notify_subscriptionListener whose Actionproperty should be changed to "*". There is no SOAP action defined in the core WSDL so WCF automatically adds one.However, this causes a mismatch when UDDI Services call the WCF service. Once the Actionproperty is modified, the service contract matches the message sent by the UDDI Services.
After adding the necessary project references to System.ServiceModel.dll and System.Runtime.Serialization.dll, create a new class which implements this contract identified in the public WSDL
public class UDDISubscriberService : UDDI_SubscriptionListener_
public notify_subscriptionListenerResponse notify_subscriptionListen
// Open file to write to log
System.IO.StreamWriter file =
new System.IO.StreamWriter("c: UDDILog.txt", true);
file.WriteLine("**" + System.DateTime.Now + "**");
//get UDDI key
requestValues = request.notify_subscriptionListener.
file.WriteLine("Subscription key: " + requestValues);
get_serviceDetail impactedService = (get_serviceDetail)request.
requestValues = impactedService.serviceKey.ToString();
file.WriteLine("Impacted service key: " + requestValues);
notify_subscriptionListenerResponse result = new notify_
result.dispositionReport = new dispositionReport();
Now we create a new WCF Service project and reference this existing service library. After making sure the .svc file points to our referenced library object, and adding a valid endpoint configuration file, view our service in the web browser to ensure that it's up and running.
Clearly, that service's metadata is NOT in good shape. But, I'm not too worried about the service's own ability to serve up metadata because I just pointed to the public WSDL and established that as the source of metadata. This is done by setting the externalMetadataBehavior attribute on our service behavior.
Now in order for us to use this service as a notification service, it actually needs to be registered in the UDDI directory itself. Within the same UDDI provider (BizTalkSOA), we add a new service and point it at this endpoint
We're almost done setting up this service minus one last change. This listener service must specifically be categorized as a UDDI listener within the registry. This is done by switching to the Instance Info tab on the service configuration and searching for the correct tModel named uddi-org:subscriptionListener_v3.
Select that particular tModel, and our configuration is complete. Now, we go to the Subscribe tab of the UDDI site where we define a new subscription. After clicking the Add Subscription button, choose the type of data entity we wish to write a subscription for.
I've chosen Services and am next presented with a screen used to find the service we're specifically interested in subscribing to. A search for %batch% yields a single result pointing to our recently added MasterBatchService. After adding that service to the Selected Element list, we designate our notification mechanism for this subscription.
We select the Enable Notification checkbox and then select the binding associated with our subscription listener endpoint. In our case, it's the second choice presented below.
After selecting the appropriate service and choosing a notification interval (which determines how frequently the UDDI Service publishes changes) our subscription is complete. We should now see a subscription listed on the left-side tree, and be able to peruse our subscription settings.
If we make a change to our service and execute the subscription (by either waiting the designated interval, or right-clicking the subscription and choosing Execute), we should see our listener service get executed.
Note that while I only showed changes being pushed out of UDDI via subscriptions, there is also a synchronous interface available for interrogating UDDI for changes on demand. Keep this in mind when deciding what changes you are interested in and if the information should be shared in an event-driven manner or simply on demand.
The UDDI V3 components included in BizTalk Server 2009 offer a set of services that are fully compliant with the UDDI standard. While there are dedicated vendors that offer very robust repositories alongside additional service governance solutions, if you are currently doing without an enterprise service repository, consider using UDDI Services. In the article above, we discussed what UDDI is, and how to use its capabilities in your environment. You learned to add services to UDDI registry and also build subscription alerts for service changes.To summarize, you learned about the new SOA capabilities in a BizTalk Server 2009, mainly the UDDI services.
If you have read this article you may be interested to view :
- The core principles of a service-oriented architecture with BizTalk Server 2009
- BizTalk Server: Standard Message Exchange Patterns and Types of Service
- New SOA Capabilities in BizTalk Server 2009: WCF SQL Server Adapter
- Consuming the Adapter from outside BizTalk Server