Web service discovery in WCF : Ws-Discovery or UDDI?

Question

I know the distinction between UDDI and Ws-Discovery (well know location to search a service vs broadcast). But my question is : what is the simplest way to discover a webservice in WCF ? By simplest I mean what is already implemented in WCF and can be used now ? I've not seen any built-in implementation in WCF for UDDI or Ws-Discovery.

Do you have any link, or experience to share about these two protocols in WCF ?

UPDATE

Now I'm thinking about three solutions, waiting for WS-discovery on .NET 4.0, or maybe creating my own discovery binding with the Peer to Peer binding provided by WCF. This way I can broadcast a request. Or using the implementation provided by the link of eed3si9n.

I think that I'll do a gateway interface to easily change implementation latter.

Answer 1

.NET 4.0 will have WS-Discovery. See Messaging enhancements in .NET 4.0: (Discovery Part I) Using WS-Discovery in WCF 4.0. In the meantime, Claudio Masieri has provided an implementation. See WS-Discovery for WCF.

There's also a custom discovery implementation done in similar way as UDDI. See Windows Communication Service Discovery.

Imagine you have 200 clients using your funky Wcf service. They would all have in their conf file a section like this one:

<client>
   <endpoint configurationName="default"
               address="http://localhost/servicemodelsamples/service.svc"
               binding="wsHttpBinding"
               bindingConfiguration="Binding1"
              contract="IDataContractCalculator" />
 </client>
 <bindings>
   <wsHttpBinding>
      <binding configurationName="Binding1" />
   </wsHttpBinding>
</bindings>

Now, you decide to change the existing endpoint (server side) with a new one that uses SSL for security reason. How do you update your clients? You can quickly see that it can become tedious. So the idea I want to detail here is to implement a discovery service similar to what UDDI does and to use a metadata resolver to get the configuration out of the service in order to create dynamically a proxy allowing the client to discuss with the service.

This person has similar concern as you do, and seems to have a working solution.

Answer 2

jUDDI has a .NET client that you can use. It greatly simplifies a number of things for working with UDDI.

From experience, there's there only two or three functioning implementations of WS-Discovery.

• Apache CXF, but only when ran outside of a container
• This one: https://code.google.com/p/java-ws-discovery/ which doesn't work in Jboss and is unmaintained
• Microsoft .NET 4.0ish

UDDI you can access from anything. There are many client and server implementations. (Just the version 3 stuff is listed here)

• IBM WS-Registry
• Apache jUDDI
• Microsoft UDDI v3 with Biztalk (its free with 2008 server)
• HP SOA/Systinet or whatever it's called now
• WSO2 has something
• ebXML has some kind of bridge or adapter

There's even a REST endpoint for UDDI3 (jUDDI 3.2 has it, XML or JSON responses) which opens this up to many more possibilities.

In addition, the data that's sharable with WS-Discovery is somewhat limited compared to the virtually unlimited data you can attach to UDDI.

That's just my 2 cents.

Answer 3

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.

Citation from: http://travisspencer.com/blog/2007/09/post.html

Here is a good list of properties: http://laflour.spaces.live.com/Blog/cns!7575E2FFC19135B4!728.entry