First off, for a very good presentation about what an ESB could be, watch Mark Richards here.
Recently, I have taken a look at the new-and-improved ESB Guidance 2.0 for BizTalk Server 2009 Beta. The ESB Guidance contains some interesting and potentially powerful concepts. Where BizTalk provides ESB-functionality out of the box (routing, transformation, etc., etc.), the ESB Guidance allows for a much more dynamic approach to realize these functionalities. With ESB Guidance, the majorities of these functionalities (i.e. dynamic routing and/or dynamic transformation) can be used by the client applications of the ESB (the systems sending messages to BizTalk) in the form of an ESB Guidance specific soap header called an Itinerary header. These Itinerary headers describe the processing steps that the message should go through within the ESB, and this Itinerary header could be different per message if that were necessary.
This approach offers a great deal of flexibility, because per each separate message coming from one of the ESB clients, it's path through the ESB can be set individually. However, it also means that those clients will need to be aware of the ESB Guidance Itinerary concept and have some way to add the Itinerary headers in the soap header of the message. Next to that, if there are changes to or within the ESB (configuration changes, system replacements), there's a chance that the Itinerary header will have to be changed as well.
In order to circumvent introducing this dependency of the ESB clients to the Itinerary concept, wouldn't it be a good idea to have the ESB be responsible for assigning the Itinerary headers? The most obvious place I can think of doing just that would be in a custom pipeline component, which can be configured with the appropriate Itinerary information, and which will just add this Itinerary header to the message as it comes in into the ESB. Taking this approach, the ContextAdder pipeline component, written by Jon Flanders, comes to mind. Using the ContextAdder, together with Saravana Kumar's article on design-time properties for custom pipeline components, I came up with a sample that does as I described above. You can download it here. BTW, the pipeline component in this sample writes or promotes any set of properties you want it to, it's not specific to Itineraries.
The sample needs BizTalk 2009 and ESB Guidance 2.0. I worked with the ESB Guidance 2.0 October 2008 release, so there may be some discrepancies when using it with the January 2009 release. Configuring the pipeline component is somewhat tedious, as the xml syntax needs to be very specific (especially regarding &lt;, < and <). If using it for real, a way to programmatically generate the config would be a good enhancement.
The sample uses FILE receive locations only and uses a very simple Itinerary that uses the orchestration routing and transformation services, configured with the STATIC resolvers. A screenshot of the pipeline configuration is displayed below.
I'd be very interested in other's thoughts on this approach, so drop me a comment!
[27-02-2009] Nick Hauenstein pointed out that the January 2009 CTP2 release of ESB Guidance 2.0 contains a much better way to achieve the same result: static Itineraries, which can be set within a pipeline component. Check out his post!