WS-Discovery and its Relationship to UDDI

| | Comments (2) | TrackBacks (0)

A few weeks back, a customer pointed out a WCF-based implementation of WS-Discovery on netfx3.com.  They said that this implementation would be included in the next version of the .NET framework and that they were going to use the sample in the meantime to publish and discover services within their system.

As I thought about it more, I became confused.  I thought that service discovery was handled by UDDI.  Perhaps UDDI had been superseded by WS-Discovery I thought; however, in his new book SOA Using Java Web Services, Dr. Mark Hansen says that UDDI is very important.  (He didn't discuss WS-Discovery though.)  So, UDDI isn't outdated and replaced by WS-Discovery as I originally thought.  Then, how do the two related?

After a bit of research, I've learned that the two aren't competitors, but that they're compliments.  In general, both provide a way to find and consume available services on a network; however, the approaches they take to supply discovery is fundamentally different.  As with other aspects of computer systems, Web services use one of two methods to discover available network resources: by looking in a well-known location or broadcasting a request to everyone that's listening.  UDDI takes the former tact while WS-Discovery takes the latter.

UDDI provides a central registry to store information about available services.  It supplies a catalog where consumers can find services that meet their needs.  This phonebook-like directory of information allow consumers to find services by name, address, contract, category, or by other data.   UDDI can be thought of as the DNS of Web services.

On the other hand, WS-Discovery provides a protocol to discover services that are coming and going from a network.  As a service joins the network, it informs its peers of its arrival by broadcasting a Hello message; likewise, when services drop off the network they multicast a Bye message.  WS-Discovery doesn’t rely on a single node to host information about all available services as UDDI does.  Rather, each node forwards information about available services in an ad hoc fashion.  This reduces the amount of network infrastructure needed to discover services and facilitates bootstrapping. 

This last point is an important one.  With UDDI, the only services that can be discovered are those that have registered with the directory service.  Non-registered services may exist on the network, but, if they haven’t registered, clients can’t consume them.  Unless a service knows where the directory is, it can’t register itself.  This foreknowledge is usually gained by configuration, making the system less agile.  Because UDDI isn’t dynamic, the registry can contain stale, out-dated information about services that are no longer available.  Conversely, WS-Discover provides a decentralized system that insures that whichever service is found is available.

Another important distinction is that UDDI is a third version standard governed by OASIS while WS-Discovery hasn’t been ratified by any standards body.  Instead, it is simply an as-is publication provided by a group of industry leaders (including Microsoft, Intel, and BEA).  In my mind, this makes WS-Discovery more risky; however, this hazard is slightly mitigated by it purported use in Windows Vista.  While its adoption in Microsoft’s new operating system shows that the protocol is capable, its risk is exacerbated by reports that its use may require the future payment of royalties.  The quote sited in the article couldn’t be found in the current version of the specification, so it seems that the concern is moot.

For more information about the relationship between UDDI and WS-Discovery, see the following: