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:
Hi Travis,
This is a great post. Thanks.
However, I have a question with the last important point you mentioned differenciating UDDI and WS-Discovery.
You said, With UDDI, the only services that can be discovered are those that have registered with directory service.
The same is kind of true for WS-Discovery. I am using java-ws-discovery and there is a requirement from the service to register itself to the network, to be identified by the clients.
My point is, If there is an existing web service in EnterpriseX, that service needs to be registered to the network to start sending multicast udp packets to announce its presence in the network.
The same as UDDI, where the owner of the service has some work to register his service in the UDDI registry.
Do you agree? or Am I missing something here.
Thanks,
Ganesh.
Though the API of the Java library you're using may make it seem like registration is required when using WS-Discovery, no central registry exists. This is the value of WS-Discovery. Unlike UDDI, any service that broadcasts its arrival on the network (i.e., "registers with the network") will be found by the other services that are currently listening. Does that help? If not, reread through the docs that come w/ your Java lib, read the resources I listed at the bottom of this post, and surf around online for additional info. If you're still stuck after that, shoot me an email or give me a call.