Anatomy of a UDDI Registry

Previously I presented UDDI in a very high level abstraction.  Now we’ll look a little more closely at the structure of UDDI in the real world.  In my earlier entry I mentioned UDDI servers from IBM, Microsoft, SAP, and open source vendors. For the rest of this series I will primarily focus on the Microsoft UDDI Server.  Originally, this was part of the Windows Server platform and is now part of the BizTalk Server product.  To demonstrate the registry and related concepts we’ll look at a few screen shots from the UDDI Services management portal.  Recall that we mentioned three types of directory listings in UDDI:

• Organizations (Providers)

• Services

• Bindings

Below we can see each of these graphically represented. 

The Hierarchy becomes reasonably clear in the image above and you can also see some features we’ll cover later in this series (specifically Search, Subscribe, and Coordinate). 

Providers 

The folder ‘Providers’ is exactly that – the place in the tree where all the service providers are listed in your UDDI server (meaning Organizations, or more likely departments).  Below this we see services, and below those are bindings for the services (endpoints or physical locations / implementations).   

In the image above, Nova Enterprise Systems is the Organization (White Page entry).  Below is a screen shot of the details for this Organization.   

The image shows that there can be multiple names in different languages and descriptions as well.  There are also tabs for Services and Contacts.  The Contacts include details such as Name, Email, Phone, and Address.  This metadata helps provide visibility and responsibility at the organizational level.   

There is also a Relationships tab that allows us to specify organizational structures (Parent-Child) and partnerships (Peer).  Through this we can describe the operational structure of a company, convey business relationships or simply identify that two organizations are really the same entity (Identity).  The choices for Relationships are Parent-Child, Peer, and Identity (in the order they were introduced above).   

Categories are also listed in this and at every level in the hierarchy.  They are part of what make UDDI so powerful.  We’ll cover more on Categories shortly.   

Services 

Services also have a similar properties page for names and descriptions in multiple languages.  Importantly they have a collection of Bindings (covered below) and again a collection of Categories. 

The important part here is that a single service is a child of an Organization (Provider) and has one or more Bindings associated with it as that Service’s own children.  The service is the logical container; the bindings are the endpoints where the services or their detailed technical descriptions actually exist.  If you click the More Details link you can see the service key for this service: 

• uddi:42f392a5-0fc3-4d25-b4c9-1003bba4ac63   

Bindings 

Bindings are the lowest level in the hierarchy and are really meant to represent locations of implementations or service details, like WSDLs.   Bindings correspond to the Green Pages in our phone book analogy.  Here is an example of a binding for a service from the UDDI Services portal.

We can see that the Access Point for this service is a URL to where the service exists; in this case it is a service endpoint.  A WSDL Deployment which points to a complete WSDL including the SOAP binding information is another option.  You may be wondering how SOAP binding differs from the bindings we’re looking at here.  Although we could put all the details of our service in the UDDI registry (such as parameters and other technical information) it is usually more useful to expose the service and / or its WSDL for simplicity.  We don’t want to tightly couple our registry with service implementations.  You will mostly use these two types of Access Points, but there are others.    

Recap 

As you can see the registry is quite simple so far and to a large degree already provides the core features required for Service Orientation Initiatives. 

• Visibility (service existence)
• Accountability (ownership)
• Decoupling of consumers from provider endpoints (we’ll cover this more later, but it should be more clear now how this will work).   

Decoupling Consumers from Providers 

So what does all this give us and what is our primary goal with all this decoupling?  A simple service deployment generally looks something like this: 

The consumer has a reference (normally through some proxy class and configuration file) to a provider endpoint (meaning the URL where the service is located).  In a simple world this works fine.  Most of us don’t live in simple worlds.  As the number of consumers and services grow we begin to see a pretty typical pattern emerge (shown below). 

We can actually already see that this is forming a point to point graph and already making changes will become more cumbersome.  What we really want is something more like what is pictured below:

In this diagram each consumer simply asks UDDI where each service it wants is located.  This diagram is a bit of an over simplification.  The consumers will still communicate with the services directly, but they will resolve their location and capabilities dynamically at runtime.  This is where part of the DNS comparison comes in.  The service consumers (and again these are programs) only know what service they want (its identity in UDDI), they have no idea where the service is deployed, and the UDDI administrators are free to change this information as needed.   

If a disaster causes an entire web server or farm to go down the only change is a change to UDDI to redirect the service locations.  There are no changes to the client applications.   

Categories 

Categories are where we start to see the real expressive power of UDDI.  You may have noticed that each level of the hierarchy (corresponding to our colored “books”) had a Categories tab on it.  A Category is used to classify the different levels of the hierarchy through metadata; this would be the Yellow Pages in our phone book metaphor.  You can use standard categories or create custom ones.  One Category set that generally ships with UDDI servers is the North American Industry Classification System (NAICS); this can be used to classify organizations based on type of business they are engaged in.   

Under the surface the Category is really a tModel (or Technical Model), which is an abstract representation of a concept or categorization.   

When you add a Category to any of the levels of the UDDI structure (providers, services, bindings) you can either choose to add a standard prepackaged category or use a custom category.  Personally I don’t find most of the standard categories to be that useful.  When UDDI was originally imagined to be an open directory on the Internet it made a lot more sense, but I don’t see that as the case anymore.  Some of the newer categories are made for things like transports, which can definitely help.  The screen shot below shows the options as well as two custom categories already added for this binding template. 

We can see that one of these custom categories is novaenterprisesystems:runtime:environment.  I created this tModel to convey the concept of different environments (often Test, Production, UAT, etc).  The Category itself is just a concept, a place to store a name-value pair.  These are managed globally at the root of the UDDI Portal.  By adding this category to my binding (and the name and value for it) I am creating an instance of this tModel able to convey to consumers that this service is targeted towards the Environment dubbed Test.  This helps us move away from UDDI just being like a file system and into it being an expressive environment from which to convey more details about our specific services.  Also unlike a file system, where a file exists in one place in a tree, categories are merely metadata, so they can be applied at many levels; even inappropriately.   

I like this example because the concept of environment (Test, Production, etc) is really more of a human concept, not a technical one.  In another article we’ll see how this Category of environment can help my consumers discover and resolve which services to use.  Ultimately Categories (and the tModels behind them) represent extensible metadata used to annotate any part of the registry we choose.  This is both a great strength and a potential weakness in UDDI as creating a poor categorization scheme will result in a poor experience.   

Conclusion 

We have now gotten a pretty good look at how UDDI actually looks and feels and the functions performed by the different parts of the repository.  We can see how the registry represents a central repository for our three primary nodes: Providers, Services, and Bindings (end points).  We can also see how annotating artifacts in the repository allows us not only to establish ownership and visibility, but also to express intent and convey a more rich model of our organization and services.   

Finally all of the features presented above are standard in nearly all UDDI servers regardless of vendor.