UDDI

ESB Simple Samples on CodePlex

EltonStoneman — Mon, 26 May 2008 23:55:16 GMT

I've finally uploaded my ESBSimpleSamples project to CodePlex here: ESB Simple Samples

It's intended as a quick-start for using the ESB Guidance package, and it has a client library for building strongly-typed service request objects. It has two very simple sample services which return the encoded value of a given character, either in ASCII or Unicode. The services are exposed as Web services and IIS-hosted WCF, and there's a WinForms client which lets you call them directly or via ESB.

Prerequisites

To use the samples you'll need the following up and running:

Visual Studio 2005
BizTalk 2006 R2
ESB Guidance package
ESB Guidance sample app ("GlobalBank" – this is only used to save me configuring a dynamic send/receive port)
UDDI services

Deployment

Nothing helpful in the project I'm afraid. I stripped out all the test and build artifacts before uploading, but you should only need to:

Build & deploy the ESBSimpleSamples solution
Create the Web services virtual directory in IIS (import settings from ESBSimpleSamples.Services.Web\Config\IISConfig.xml)
Add UDDI settings for the Web services (in ESBSimpleSamples.Services.Web\Config\UDDISettings.xml)
Create the WCF virtual directory in IIS (import settings from ESBSimpleSamples.Services.WCF\Config\IISConfig.xml)
Add UDDI settings for the WCF services (in ESBSimpleSamples.Services.WCF\Config\UDDISettings.xml)

You'll need to change the paths to the SNK file in the BizTalk project, and to the project outputs in the IISConfig files.

Running

Run the WinForms client and you'll get this form:

You can check all is well with your deployment by calling the various services – with InProcess the client app instantiates service objects locally; Web and WCF call the services directly; ESB calls the Web service via ESB and ESB.WCF calls the WCF service via ESB.

Any problems are likely to be config – if the services don't respond it'll be an IIS issue, and if the ESB calls don't respond it'll be UDDI (assuming your ESB Guidance is working for other calls).

Architecture

On the service side, there's not much to it – the ServiceComponents project has the business logic and the Services.Web and Services.WCF projects wrap access to the ServiceComponents. The BizTalk project holds the Request and Response schemas which are the same for the Web and WCF services – BizTalk owns the contracts.

The WinForms client uses generated code for the Web service and WCF calls (using VS 2005 Extensions for WCF). For the ESB call there are simple DTO entities for Request and Response objects, matching the schemas (note these are handwritten rather than use the clunky output from XSD.exe – they'd be codegened from very plain templates in a real project). The ServiceRequest classes wrap usage of ESB, and expose the typed DTOs so the client is abstracted from the message bus:

ServiceRequests.GetASCIICode esbASCII = new ServiceRequests.GetASCIICode();

esbASCII.Request.Character = "a";

byte[] code = esbASCII.Response.GetASCIICodeResult;

The interesting stuff is all in the ServiceClient project. There's a generated proxy for the ESB.ItineraryServices.Response Web service; the ResolverConnection and ItineraryBuilder classes make life much easier for building itineraries in code. ESBServiceRequest is the base class for clients to build their typed requests – child classes specify the Request and Response types and only need code to prepare the request, specifying the service steps they want:

public class GetASCIICode : ESBServiceRequest<GetASCIICodeRequest, GetASCIICodeResponse>

{

public override ItineraryRequest PrepareRequest()

{

ItineraryBuilder builder = new ItineraryBuilder();

builder.AddRoutingService("ESBSimpleSamples", "GetASCIICode");

builder.AddRequestResponseService();

ItineraryRequest request = new ItineraryRequest();

request.Header = builder.GetItinerary();

request.Body = this.GetRequestBody();

return request;

}

In the samples project, UDDI is the chosen resolver so AddRoutingService builds up a UDDI resolver connection for the specified service. When the Response property is accessed, the base class calls for the request to be prepared, sends it to the broker and caches the response.

The ESBSimpleSamples should make the learning curve for ESB Guidance a bit shallower, and the ServiceClient library is one approach you can take for consumers. With this library most of the code is abstracted and the specifics for services can easily be codegened. From a published service, the schema, Request and Response entities, ServiceRequest class, ServiceRequest unit tests and UDDI settings can all be generated. Even if there are no .Net consumers for a service, being able to generate all this and have unit tests verifying the service response should be useful.

UDDI Service Resolution

EltonStoneman — Sun, 25 May 2008 18:25:30 GMT

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…

ESB Guidance – UDDI Resolver

EltonStoneman — Wed, 30 Apr 2008 01:17:51 GMT

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:

<![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