So far the examples I've shown have been using STATIC resolvers. These are easy to set up and for quick samples have the benefit that all the connection settings are visible in the resolver config in the itinerary. They're brittle though and for real-world use it's obviously a limitation to hard-code the service settings on the consumer side.
ESB Guidance offers various resolvers, but UDDI seems the most attractive for dynamically resolving service implementations. UDDI (Universal Description, Discovery and Integration) is a standard for registering services in a central repository. It provides a structured way to store and discover Service Providers, Services and Bindings. Initially, UDDI registries were intended for public publishing of commercial services, but Windows Server 2003 includes UDDI Services, allowing registries to be used internally within organisations.
In UDDI terms, Services are registered under a Service Provider – this may be an organisation providing a set of services, or internally it can be used identify an internal system. This provides a grouping of like services and the provider's contact information can be used for the technical owner, or other point of contact.
Services in UDDI are method endpoints, typically a Web service action. Service names are not constrained to be unique within a provider, and there is no intermediate grouping, so a naming convention may be needed to group services within a provider. It may also be necessary to include versioning in the service name. While UDDI allows you two have two services with the same name but different target namespaces (so the namespace could be used for versioning), the ESB resolver only uses the service name.
Each service has a set of bindings, representing the necessary connection data to use the service. There are standard bindings (e.g. http to specify endpoint address), but they are configurable so can include any amount of information. In ESB each component of the resolver connection string (TransportLocation, TransformType etc.) is stored as a binding. The resolver finds the UDDI service from the registry and brings back all the connection settings you would manually specify in the STATIC connection string.
The UDDI resolver requires the location of the registry, and the name of the Service Provider and Service. The static resolver config from the previous post would look like this using UDDI:
<Resolvers serviceId="Microsoft.Practices.ESB.Services.Routing1">
<![CDATA[
UDDI:\\serverUrl=http://localhost/uddi;
serviceProvider="ESBSimpleSamples;
serviceName=EncodingService.GetASCIICode;
]]>
</Resolvers>
Note that the service name is arbitrary. The convention here identifies the action with the owning Web service which may be useful for Service Providers which have large numbers of services registered.
The UDDI resolver caches hits to the UDDI service for a configurable lifetime. The obvious trade off is between performance and flexibility, so an extension option may be to provide an external method for invalidating the ESB cache. A custom deployment step could update the UDDI registry with a new/updated service then fire a message to ESB Guidance to invalidate the cache.
There's not much cost involved in using UDDI, and the publishing step could be an automated part of deployment. It requires a UDDI repository to be available to dev and other environments, and naming standards need to be considered, but the advantage comes in decoupling consumers and the ESB from the actual service implementations. Swapping out a service in live is as straightforward as deploying the new service and updating the registry. In an SOA world, the registry also forms the central point of knowledge about the systems and services available for consumption