Geeks With Blogs

News This is the *old* blog. The new one is at blog.sixeyed.com
Elton Stoneman
This is the *old* blog. The new one is at blog.sixeyed.com

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

Posted on Saturday, October 25, 2008 7:10 AM ESB Guidance , BizTalk 2006 R2 , Code Gallery | Back to top


Comments on this post: ESB Guidance Demonstration: “TriathlonResults”

# Web Design Company India,
Requesting Gravatar...
Thanks it is really cool info about

ESB Guidance Demonstration: “TriathlonResults”
Left by Rg ifnotech on Oct 25, 2008 7:57 AM

# re: ESB Guidance Demonstration: “TriathlonResults”
Requesting Gravatar...
The post is very nicely written and it contains many useful facts. I am happy to find your distinguished way of writing the post. Now you make it easy for me to understand .
Left by bridesmaid dresses on Jun 11, 2010 4:18 AM

# re: ESB Guidance Demonstration: “TriathlonResults”
Requesting Gravatar...
This is a great blog with excellent posts and links.Thanks for sharing
Left by Sanovnik on Jan 27, 2012 12:42 PM

Your comment:
 (will show your gravatar)


Copyright © Elton Stoneman | Powered by: GeeksWithBlogs.net