ESB Guidance

Visualizing SOA’s Return on Investment

EltonStoneman — Thu, 26 Mar 2009 18:36:18 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

This is the rather grand title of a WebCast I've recorded recently which tries to illustrate where the return on investment comes after moving to a SOA strategy. The video is on Digital Forum: Visualizing SOA ROI , and the Open Source proof of concept it references is on CodePlex: ESBSimpleSamples.

In the WebCast I start with a blank Visual Studio solution and create a new Web app which consumes an existing service. All in it takes 3 lines of code and around 3 minutes of development (most of it spent correcting typos), and it doesn't require me to have any understanding of the underlying SOA infrastructure – in this case, Microsoft's ESB Guidance package sitting on BizTalk Server 2006 R2. Equally important, assuming the service we consume is in production, the testing and deployment effort needed for the new project is minimal.

This is a rework of a presentation I did with a client where I wanted to show how quick and easy it is to use their SOA implementation. I had reservations of showing a code demonstration to an audience which included IT heads (IT Director and Solution Architects) and project management, but it was surprisingly well received, so I've reproduced it using services and components which are publicly available.

Direct links to the references in the WebCast are here:

ESB Guidance: http://www.codeplex.com/esb
UK SOA/BPM User Group presentation: http://sbug.org.uk/media/p/129.aspx
Blog posts on ESB Guidance: http://geekswithblogs.net/EltonStoneman/category/7947.aspx

Receiving large WCF response messages in ESB Guidance

EltonStoneman — Wed, 25 Feb 2009 23:51:53 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

WCF bindings provide the MaxReceivedMessageSize property, which lets you block any incoming messages on the client side over a given size (defaulting to 64Kb). If you're using message-based itinerary processing with ESB Guidance, when a WCF service returns a message larger than this default, you'll get a System.ServiceModel.QuotaExceededException and the response message will be suspended:

System.ServiceModel.CommunicationException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. ---> System.ServiceModel.QuotaExceededException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

Setting the MaxReceivedMessageSize property is straightforward in a configured WCF port, but in ESB Guidance the port is configured dynamically and there's no straightforward way to interrupt it and add your own WCF bindings. To give us access to the message and the port, we replaced the "DynamicSendResponse" port used in the GlobalBank.ESB sample with a simple orchestration.

The orchestration has a direct-bound receive port filtering on the usual properties:

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "DynamicResolutionSolicitResp") &&

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending") &&

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Messaging")

- it then builds the outgoing message for the service, and configures the dynamic send/receive port. At this point the message has all the properties you need configured by ESB (via the resolver pipeline component in the previous itinerary steps), so you can extract them to configure the port, and add any WCF binding configuration you need.

We store the configuration in the Enterprise Single Sign-On application config store using SSO Config Tool, so the expression to build the outgoing message and increase the received message size looks like this –

//setup port from context properties:

sptServiceProvider(Microsoft.XLANGs.BaseTypes.Address) = ServiceProviderRequest(BTS.OutboundTransportLocation);

sptServiceProvider(Microsoft.XLANGs.BaseTypes.TransportType) = ServiceProviderRequest(BTS.OutboundTransportType);

//set message size from config:

maxReceivedMessageSize = x.y.z.Configuration.X_Y_Z_Config.WCFMaxReceivedMessageSize;

ServiceProviderRequest(WCF.MaxReceivedMessageSize) = maxReceivedMessageSize;

Microsoft.Practices.ESB.Adapter.AdapterMgr.SetMsgProperty(ServiceProviderRequest, typeof(WCF.MaxReceivedMessageSize), maxReceivedMessageSize);

//set timeout from config:

sendTimeout = x.y.z.Configuration.X_Y_Z_Config.WCFSendTimeout;

ServiceProviderRequest(WCF.SendTimeout) = sendTimeout;

Note that the WCF config is set on the message, not on the port. We're also setting timeout values here. When you're dealing with large messages, you may get operation timeouts as the default binding config from BizTalk is set to a pessimistic 1 minute. Value WCF.SendTimeout specifies how long the BizTalk client waits for a response, and WCF.ReceiveTimeout how long the BizTalk client allows for the reception of a request. If your WCF service is hosted in IIS and is long-running, you may also have an issue with IIS controlling execution times. See: Why changing SendTimeout does not help for hosted WCF services.

An Infrastructure Design for ESB Guidance

EltonStoneman — Mon, 02 Feb 2009 14:08:46 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Our ESB Guidance project is nearing code-completion and we're running System Test on an infrastructure which is suitable for production use. Designed for performance, reliability and scalability, we use servers in a combination of NLB farms, Windows clusters and SQL clusters. Shown below is a modified version of the layout, focusing on the BizTalk landscape:

A few of the design decisions are worth looking at:

Coordination Services run a host for Scheduled Task and FTP adapters, building itinerary requests from received messages. Both adapters are unable to flag an incoming message as being in-process, so are not safe on multiple instances – we have two servers in an active/passive Windows cluster to provide redundancy;
Itinerary Services run a host for incoming itinerary requests from the SOAP adapter. This is instance-safe, so we have two servers configured in a farm for redundancy and performance;
Itinerary Processing runs a host for the custom orchestration we have for handling calls to WCF service providers (not shown in this diagram, but running on a separate Web farm and SQL instance). All BizTalk servers run instances of this host, so any with capacity can service calls;
Enterprise Single Sign-On is located it on the Windows cluster with the Coordination Services, as it cannot run under an NLB farm. The Coordination Service is expected to have spare capacity, so hosting SSO shouldn't impact performance;
UDDI Services run on the BizTalk NLB farm with the Itinerary Services. A small compromise here from the ideal of having a separate UDDI host, but resolver calls will all be made during Itinerary Processing and we use a custom UDDI resolver which holds the cache indefinitely (until manually invalidated when a change is promoted to the UDDI Service), so after the initial warm-up, UDDI Services will have negligible usage;
UDDI Database runs on the same SQL instance as the BizTalk databases. The second small compromise – breaking the cardinal rule that BizTalk should have a dedicated SQL instance with dedicated hardware… As UDDI calls will be minimal, this is a worthwhile performance trade to get the redundancy of having UDDI on the SQL cluster.

The design is intended to cope with a relatively low initial throughput – 250,000 messages in the first year, 98% of which will be a few kilobytes, 2% running into megabytes. BizTalk servers all running Enterprise Edition in a Group, with just Microsoft.Practices.ESB and our custom application installed. Currently the BizTalk servers are running single quad-core CPUs with 4Gb RAM.

Our next task is to run some simulated load through the setup and modify the host layout or physical capacity if necessary. I'll cover the load testing results in a future post.

Generic WCF Error Handler for ESB Guidance

EltonStoneman — Tue, 20 Jan 2009 14:43:29 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The management portal for ESB Guidance is an excellent tool which displays information on faults generated during the processing of messages through the ESB. It also exposes Web and WCF services for logging your own faults to the exception database, so you can record exceptions that occur in your own service providers and use the portal as a single view over the health of your SOA stack.

The SubmitFault method of the ExceptionManagement service takes a FaultMessage object which must be correctly configured with Header and FaultException properties. It takes some trial-and-error to work out what needs populating – if any properties are missing or invalid, your fault won't be logged. I've put together a sample error handler on MSDN Code Gallery which populates a call correctly: ESB Guidance Error Handler, which you can use as-is in your WCF services, or as a basis for your own handler.

In the sample, the error handler is available to your service so you can manually log a fault for any exceptions that you catch, and you can also configure it as a service behaviour so it will log any uncaught exceptions in your WCF service. A sample service and client are provided for demonstration – set up the SampleService as a virtual directory and run SampleClient (you'll need the ESB Guidance Exception Management installed).

To use the ServiceProviderErrorHandler add a config section in your web.config to specify how faults are logged:

<section

name="serviceProviderErrorHandlerConfiguration"

type="ESBGuidanceErrorHandler.Configuration.ServiceProviderErrorHandlerConfiguration, ESBGuidanceErrorHandler"/>

</configSections>

<serviceProviderErrorHandlerConfiguration

exceptionHandlingUrl="http://localhost/ESB.ExceptionHandlingServices/ExceptionHandling.asmx"

bizTalkApplication="BizTalk Application 1"

faultCode="50054"

errorType="Service Provider exception"

failureCategory="0"

faultGeneratorName="ESBGuidanceErrorHandler">

</serviceProviderErrorHandlerConfiguration>

This identifies the location of the ExceptionHandling service (the sample uses the SOAP entry point, but it's a simple change to use the WCF version as they have the same signature) and the descriptive text to categorise errors being logged, which will be shown in the portal. Note that the specified BizTalk Application must exist and the fault generator name is limited to 50 characters. Other values can contain any identifiers you like.

With the config specified, it's a simple call to log a fault – passing the name of the service provider and the service, description and severity of the fault, and an exception:

ServiceProviderErrorHandler.SubmitFault("ErroringService", "LogHandledException", "Caught exception", FaultSeverity.Error, ex);

To register the ServiceProviderErrorHandler to catch any unhandled exceptions that occur just requires a behaviour extension in the WCF service configuration:

<system.serviceModel>

</service>

</services>

<serviceProviderBehavior/>

</behavior>

</serviceBehaviors>

</behaviors>

<extensions>

<behaviorExtensions>

</behaviorExtensions>

</extensions>

</system.serviceModel>

Add this to all your WCF service providers and any exceptions will be logged and can be shown, filtered and subscribed to in the normal way.

ESB Guidance Demonstration: “TriathlonResults”

EltonStoneman — Sat, 25 Oct 2008 12:10:16 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

At the SBUG meeting last week, my session on "ESB Guidance: A Real-World Implementation" was meant to end with a demonstration, but we ran out of time - and in any case what I'd intended to show was probably a bit ambitious, with plenty of this-is-bound-to-go-wrong points.

But I've spent some time making it more solid and the code is available now on MSDN Code Gallery: ESB Guidance 1.0 Demonstration: TriathlonResults, if you want to have a look. You'll need an environment with BizTalk 2006 R2 and ESB Guidance 1.0 set up to run it, but I'm looking at putting together a Webcast to give a walkthrough.

Overview

The demonstration involves a set of systems which each have custom integrations to a central system, and shows two SOA approaches for integrating them with BizTalk and ESB Guidance. The first approach is a partial migration, where the client systems are unchanged, but the central system picks up messages directed through ESBG. The second is a "full" SOA migration, where the clients are changed to integrate directly with ESBG.

For the sake of an interesting demo, the systems are contrived to be unusual. They represent different systems for recording an athlete's time in a sector of a triathlon – each having a different UI and a different integration approach. The first sector - the swim - is recorded from a console app:

The second – the bike – from a WinForms app:

And the third – the run – from an Excel 2003 workbook with some VBA script:

The integrations add results to a central database, which has a particularly poor web front-end:

Pre-requisites

Windows Server 2003 with IIS & UDDI Services installed; SQL Server 2005; BizTalk Server 2006 R2; ESB Guidance 1.0.

The sample expects everything to live on localhost, and uses a SQL Server login so you need to have mixed authentication and named pipes enabled in your SQL Server instance.

Installation

Two steps after downloading the code – build and deploy the TriathlonResults.Phase1 solution (you'll need to modify the BizTalk projects to point to your own management database), then run the Deploy.cmd script (it'll ask for the name of your SQL Server – just use "." for a local un-named instance).

This will create:

two SQL databases – TriathlonResults and TriathlonStaging;
a SQL login – TriathlonResults;
a BizTalk application - TriathlonResults;
two IIS virtual directories – TriathlonResults.Web and TriathlonResults.Central.

In the Shortcuts folder under the solution root you'll have links to the various client apps, and to the website which shows the full results from the central system.

Phase 0

This is the starting point, with each system integrating to the central results service in a custom way:

Console app: receives user input and outputs as a delimited flat file; a central console app runs a FileSystemWatcher over the expected location, parses the flat file and inserts the record to the central database;
WinForms app: receives user input and sends the sector result as a Web service call to the central service, which inserts the record to the central database;
Excel workbook: receives user input and inserts the result as a record in a staging database; a trigger on the staging table retrieves the new record and inserts it to the central database.

To see this, run SetupPhase0.cmd and input some results. Usage of the client apps should be fairly straightforward – choose Athlete id=1 and Race id=1 to use known reference data, and refresh the web page for the first race after each input. You should see the sector times displayed after you enter them.

Phase 1

This is the first SOA approach, showing an option for partial migration. Here the central result-recording Web service has been exposed as a service through ESBG, and the clients all use the central service. The WinForms client has been changed to invoke the ESBG call directly, but the other systems are unchanged and a BizTalk app picks up their output and submits it to the ESB:

Console app: flat file output is now monitored by a BizTalk FILE Receive Location. The pipeline for the location parses the flat file into a known schema, and adds the itinerary details as context properties;
WinForms app: uses a typed Service Request class to submit messages to ESBG directly. This is a proxy class which deals with wrapping the message in an ESBG itinerary, and submitting it to the on-ramp;
Excel workbook: the trigger on the staging database is disabled and replaced with a SQL Receive Location which polls the staging table for unprocessed records. The pipeline adds itinerary details to the context;
TriathlonResults BizTalk app: for the FILE and SQL Receive Locations, the BizTalk app has custom orchestrations which map incoming messages to the contract for the Web service, and submit the request. The send port DynamicRequestResponse subscribes to any pre-formed itinerary message, so this picks up the message from the WinForms app, which doesn't require any specific workflow.

To use, close down any client apps you have running, run SetupPhase1.cmd, open the clients and input some results. The command clears down the results DB, so you should start with an empty results page on the website. As you use the clients you can confirm they're using ESBG by checking HAT. You'll probably also notice that the WinForms app responds more slowly when you submit a result.

Phase 2

This is a full SOA migration, where the consumers are aware of the mechanism for requesting services, unlike the Phase 1 approach where this was abstracted away from the legacy apps. All client apps are changed here to invoke the ESBG service request directly:

Console app: now uses the typed Service Request used by the WinForms app to build the ESBG message and submit it. Flat file no longer generated;
WinForms app: unchanged from Phase 1;
Excel Workbook: the typed Service Request is registered as a COM-callable Type Library and referenced from the Workbook. The VBA instantiates, populates and submits the ESBG message. Staging database no longer used;
TriathlonResults BizTalk app: the SQL and FILE receive locations are no longer used, all incoming messages are of the expected itinerary type and are all dealt with by the DynamicRequestResponse port.

To use, close down any client apps you have running, run SetupPhase2.cmd, open the clients and input some results. Again, you should start with an empty results page on the website and can use HAT to confirm messages are going through BizTalk. You'll notice now that all the apps are responding more slowly when you submit a result.

Notes

The Phase 1 approach is a pragmatic one, realising some of the benefits expected in SOA at the cost of others. We have reuse of loosely-coupled services, a centralised discoverable service repository, and centralised message flow. We don't have a common communication mechanism and we haven't got away from bespoke formats and protocols. In some environments this may be as far as the migration goes, if service consumers can't be modified. It has the benefit of being transparent to consumers, but with bespoke mapping and configuration for each consumer it will have the largest custom codebase – taking more effort to develop and maintain.

Phase 2 gives us the benefits of Phase 1, plus we are now using a single entry point to the ESB and consumers are submitting messages of known types which can be verified against the service contract schemas held in BizTalk. This particular implementation sees all the apps using a .NET component to abstract the work of creating the itinerary. This means consumers need no knowledge of BizTalk or ESB Guidance, but has the complication of distributing and maintaining that assembly. Consumers could use any approach to build their requests, provided they can understand XML and SOAP.

Contract-First CodeGen

EltonStoneman — Fri, 06 Jun 2008 02:45:00 GMT

I've added some codegen scripts to the ESBSimpleSamples project, and a simple UI which runs the scripts against metadata it retrieves from a WSDL endpoint. The codegen templates were built for a custom tool which we use (not public I'm afraid), and then stripped down for the "ServiceClient.Generator" tool, so the structure might look a bit odd, but they do the following jobs:

Extract the schema from the WSDL location to XSD (ready for loading into BizTalk)
Build a (very) clean request DTO for the selected method
Build a (similarly) clean response DTO for the selected method
Build a typed ServiceRequest object for use with the ESBSimplseSamples.ServiceClient library, giving access to the service via ESB

The classes are just displayed in the form at the moment (using ScintillaNET for readability):

(if anyone has a burning desire to increase the functionality of the UI, let me know and I'll add you to the CodePlex project).

I'm intending to add further codegen scripts to generate:

a unit test stub for calling the ServiceRequest
a sample XML message containing the necessary itinerary steps in the header, and some dummy values in the body
settings for adding the service to a UDDI repository.

This all works splendidly for the straightforward services I've tried so far, though I'm expecting some rework to deal with services that use types across a variety of schemas.

Rummaging around in the System.Web.Services.Description namespace to get the WSDL metadata really isn't much fun. I'll write a post moaning about it in more detail later, but for now I'll point to a couple of helpful resources: Web Service Studio Express (the basis for the DynamicProxy code) and C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\DefaultWsdlHelpGenerator.aspx (the page that ASP.Net runs when you enter a WSDL location in IE).

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.

The identity of application pool, 'ESBAppPool' is invalid

EltonStoneman — Mon, 26 May 2008 21:16:07 GMT

While I was finishing up the "ESBSimpleSamples" project, I came across this strange error. On submitting a message to the ProcessItinerary Web service I got a 503 Service Unavailable error, and the event log showed the app pool had been shut down, with The identity of application pool, 'ESBAppPool' is invalid and error code 80070532.

A quick Google suggested it was an issue with the BizTalk isolated account. I hadn't changed it at all and the service was fine a couple of days ago, but I checked the BTSISOSVC account. It was flagged as "User must change password at next logon" which seemed odd. Removed that and set it to never expire, restarted IIS and it all started working again. Odd.

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