New SOA Capabilities in BizTalk Server 2009: UDDI Services

All truths are easy to understand once they are discovered; the point is to discover them.
-Galileo Galilei

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	Purpose	Name in Microsoft UDDI services
BusinessEntity	These are the service providers. May be an organization, business unit or functional area.	Provider
BusinessService	General reference to a business service offered by a provider. May be a logical grouping of actual services.	Service
BindingTemplate	Technical details of an individual service including endpoint	Binding
tModel (Technical Model)	Represents metadata for categorization or description such as transport or protocol	tModel

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.