My fellow blogger James Snell
and I are having a friendly debate about the relative merits of UDDI
. In UDDI and DNS-EPD
, responding to my subtlety-titled UDDI Sucks
entry, James rightly points out that different tools work for different purposes. Indeed, as I said, "UDDI seems like a reasonable solution to the stated problem... [but] the problem is the wrong one to solve."
So, what's wrong with the approach UDDI solves? Here are some of the problems:
- Synchronous, point-to-point web services -- UDDI enables the client to lookup the URL for invoking a web service over HTTP. This requires invoking the service synchronously. Assuming the caller invoking the web service is another application, application-to-application integration is best accomplished asynchronously.
- Multiple matches -- With UDDI, the client specifies the WSDL for the web service it wants, and UDDI returns a list (URLs) of providers of that service. It is then the responsibility of the client to choose one of those service providers, yet it has very little information with which to make an informed decision.
- Repeated lookups -- After a caller looks up a service's address, things may change. The service may relocate to a new URL, other providers of the service may become available, the quality of the connection to the various providers can fluctuate. This makes the client defensive, repeatedly looking up the service to see if there's anything new. Likewise, the chosen provider may become unavailable, forcing the client to go look up an alternative (unless it has cached that information, but then it may become stale).
An Enterprise Service Bus
(ESB), on the other hand, encapsulates all of these details and handles them for the client so that it doesn't have to:
- Asynchronous -- One client thread fires and forgets the SOAP request, another thread listens for the SOAP response (or fault). This also enables multiple network paths to the same provider, and resiliency (via queuing) in cases where none of the providers are available at the moment.
- One channel per service -- To invoke a service, the caller puts the request (whose format is described by the WSDL) on the proper channel/queue/pipeline, then listens for the response on the appropriate reply channel (either specified in the WSDL or specified by the caller in the request message). If there are multiple service providers, the ESB figures out which one to dispatch the request to. This can be based on real-time metrics like load, latency, availability, etc. The way most messaging systems work, this balancing is done automatically--a provider which is overloaded or out-of-service simply won't consume the request.
- Single point of contact -- The caller need only know how to address the request channel (such as its URL). This can remain fixed even as service providers come and go and sometimes change their addresses. It's a level of isolation between the callers and the providers that adds stability.
One more point: An ESB can act as a directory service in the same spirit as UDDI. Basically, a caller would ping the ESB much the way it pings a UDDI server, saying "who implements this WSDL?" and the ESB responds with the request and reply channels to use. So maybe DNS-EPD
should provide a way to find ESB hosts as well as UDDI hosts. (And it probably does.)