ESB Guidance

Cloud Services and Command-Query Separation: Part 3

EltonStoneman — Fri, 06 Aug 2010 21:43:15 GMT

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

In my previous post, Cloud Services and Command-Query Separation: Part 2, I walked through a sample Command-Query Separated service bus solution using readily available cloud services for communication. In this one, I'll look at some of the implications of shifting systems integration to the cloud, compared to an on-premise ESB. The focus here is mainly on Amazon Web Services, but I'll cover Azure with a dedicated sample project.

Cost & Non-Functional Requirements

If an ESB is core to your system landscape, it needs to be reliable and scalable. With a BizTalk-based solution you get this built-in with the architecture, but it doesn't come cheaply. For a minimally-resilient enterprise-grade solution you'll need at least two BizTalk servers in a group running against a SQL Server cluster on two nodes; for DR you'd need the same again in a separate data centre. Buying all the hardware and licenses could take you to £100K, not allowing for ongoing operating, maintenance and site costs.

In comparison the cloud solution is likely to be far more reliable at a far lower cost. Both AWS and Azure have multiple data centres around the globe, with redundancy levels you couldn't realistically achieve in a private data centre. Scalability is a given for the queuing and storage services - you just use them as much as you need, and the service scales to cope. If you're hosting the service provider nodes in the cloud too - either as a Windows Azure service, or within an Amazon EC2 instance - then they can be configured to automatically scale just as easily.

Cost-wise, there's no comparison. For the AWS services used in the sample, the "free tier" means if you're sending up to 100,000 messages a month on SQS with up to 1Gb total payload, and using less than 1Gb of storage on SimpleDB then there are no charges at all. The next level up incurs monthly costs (at time of writing) of around £0.20 for an additional 100,000 messages with 1Gb payload, and £0.30 per Gb of data in SimpleDB.

With the roughest calculation, you could push 10,000,000 messages through SQS, and use 100Gb storage on SimpleDB EVERY MONTH FOR 160 YEARS before approaching £100K in costs. Of course the BizTalk and cloud solutions are not comparable in terms of the functionality they offer, but for certain scenarios they can be compared as they may be used in similar ways.

Security and Interoperability

Cloud services are based on interoperable standards - typically SOAP and REST - and are published on publicly-available endpoints. Azure has clever tricks to navigate firewalls for WCF bindings, and AWS uses standard HTTPS endpoints. To make an internal service publicly available you need to configure DMZs, domain names and firewalls, and sign up for ongoing vigilance against attack.

In AWS, transport-level security on the endpoints is supported by message-level security, with every request containing a signature built using the sender's secret key to verify that the content has not been tampered with. AWS also lets you secure or deny services to a specific list of AWS user accounts, so you can limit use of your queues and data stores to business partners. It's fairly simple to interact with AWS services in an iPhone app.

On-premise gives you more options for tailoring your solution. For example, you may have a secure, interoperable entry point to the ESB, but between ESB and service providers the communication is private so you could standardise on efficient WCF over TCP/IP, using IPSec to prevent any machines other than the ESB nodes accessing the service providers. Calling services with an iPad is likely to be more of a challenge.

Time to Market

Or Time to Release, depending on your scenario. Starting from zero, you can be up and running with a simple cloud service bus with less than a day's effort. Assuming you're exposing existing functionality then you could conceivably have a pilot project deployed for testing in the cloud within a week. Adding new services is as simple as adding a façade over existing code, to act as a handler when a known type of message request is received. Business partners can use your test environment with no special effort, and when you go live, decommissioning the test environment is just a case of deleting the queues and data stores with a few API calls.

On-premise, all the delivery times go up. Development, deployment and testing of a basic ESB solution – even if you use BizTalk and the ESB Toolkit as a starting point – is likely to be closer to a month than a week. The contract-first nature of BizTalk means adding a new service or changing an existing one requires deployment of ESB artifacts as well as the new service provider – this not a negative, but it does add to the effort required.

Performance

In terms of latency, the cloud solution is never going to perform as well as on-premise. Pushing an ESB request and response through the BizTalk message box may add 0.5 seconds of latency, but calling out to the web is going to be double or quadruple that. That network latency in fetching a large query response could make the solution unworkable for end clients, compared to the LAN option.

The reverse may be true for globalised organisations which have their data centres in one region. While the on-premise solution needs to negotiate the WAN, the cloud solution has the option to push out to edge nodes, with independent queues and data stores residing in the nearest region to the consumer. In this scenario the cloud solution is likely to have the lower latency.

In terms of processor power and scaling up to meet demand, the cloud solution can provide that more-or-less instantly, with no service disruption and with a linear cost increase. Scaling an on-premise solution will always take longer to commission, for scaling up there will be downtime for the upgraded nodes and scaling out will mean cost spikes.

Limitations

In the cloud world, you currently have to live with limitations that will seriously affect your design. SQS allows maximum message sizes of 8Kb, which is entirely tiny, but should be a size you can cope with for service requests and responses. You may have to give more consideration to serialization than you normally would, using JSON or Protocol Buffers rather than bloated XML.

The BizTalk solution will happily deal with XML messages in the hundreds of megabytes, but to do so efficiently it needs to be tuned to favour large messages over throughput.

Governance

This is where the cloud option does really poorly. One of the key advantages of BizTalk and the ESB Toolkit is that I can navigate UDDI and get a list of all available services and their endpoints; then I can navigate the endpoint WSDL and see what the service contract is, or I can look up the XSD in BizTalk. The service and contract lookups can be wrapped into a custom tool, giving you a real-time ESB navigator which is fairly trivial to build.

In the sample cloud service bus there's no separate catalogue of services or contracts. Services exist as long as there is a subscriber for a particular type of message; request and response contracts may be explicit in .NET classes, but across the bus they're just strings of text with no option to validate them. For a robust cloud solution, governance needs to be in from the start, which is likely to mean some custom operations services which can be queried to get that service catalogue and contracts.

Visualizing SOA’s Return on Investment

EltonStoneman — Thu, 26 Mar 2009 13: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 17: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 08: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 08: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 06: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 — Thu, 05 Jun 2008 20: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 17: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 15: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 12: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…