A couple of points worth noting when using UDDI Services in Windows 2003 as a repository, and the ESB Guidance UDDI Resolver:
- The UDDI Resolver checks Service Providers and Services in a culture-specific manner. In the UDDI Services Web interface, the culture defaults to en-US, whereas the Resolver picks up the current system culture. So if you're running under en-GB it won't find entries set with en-US, or with the root "en", it must be an exact match.
-
When it finds a match, the Resolver caches it using a timeout policy. The timeout is configured in Microsoft.Practices.ESB.PipelineComponents.config and defaults to 600 seconds:
<ESBProcessor>
…
<Cache>
<add key="UDDI" value="600" />
- UDDI allows you to have multiple names for one service so you can have aliases, and also multiple services with the same name. There's no versioning of services out of the box with ESB Guidance, but you could have multiple UDDI entries with the same service name and a custom binding to indicate the version. An extended resolver would check the version and consumers could then request a specific version, or default to the latest version.
-
The W2k3 Resource Kit has a tool for exporting UDDI config settings, but this also exports the unique service key. Manually entering UDDI config is brittle and time consuming; there's an SDK which makes life easier, so we're looking at an MSBuild task which creates the UDDI entry as part of the deployment.
When you add itineraries and service resolution as abstractions, you lose the single endpoint for consumer discovery. In the ESB model, a new consumer will need to know the format of the itinerary header and the contract for the service provider which will form the body of the request. It would be good to centralise client developer access to the repository, so users can navigate the repository, read the descriptions and get generated usage – WSDL for the header and the body, sample XML itinerary message, generated entities for request/response etc. This is a tool in our growing TODO list…