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.