What is the reality of UDDI and runtime discovery of services? It seems unlikely the enterprises will rely on dynamic discovery of services (even internally) at business process run time for anything critical. It seems more likely that this would happen at design time and that the binding to the service would occur as part of the build of the business process, rather than happening dynamically and risking not finding the service required for a critical business process.
QUESTION POSED ON: 27 OCT 2004
QUESTION ANSWERED BY: Ron Schmelzer, Jason Bloomberg
The reality is that registry products that support UDDI are very useful both at design time and at run time, for different purposes. At design time, a registry can help developers find the service they require and obtain metadata about it that will help them access the service. At runtime, registries are a critical element of maintaining the loose coupling between service consumers and providers that is so important to SOA.
At its simplest level, a registry can provide location independence -- instead of hard-coding the URL of a service into a consumer, have the consumer query the registry for it instead, similar to how DNS translates domain names into IP addresses. Such location independence provides a measure of loose coupling, just as DNS does.
When incorporated into an SOA management platform, however, the UDDI registry can be an important piece of how the management platform handles scalability, failover and the support of varying service levels for different consumers. It's important to keep in mind, however, that in this last scenario, the UDDI registry doesn't stand alone or it would have the problems you suggest.
|
|
|
