ESB Guidance...part 3

Itinerary Processing

So what does ESB Guidance offer beyond the management and monitoring aspect?

The notion of itinerary processing was all new to me, and as I said in previous posts, I didn't really understand the concept at first. However, now that I do, I think of this as, by far, the coolest thing about the ESB Guidance.

Although BizTalk is flexible and configurable, when you've deployed your schemas, maps orchestrations etc, it all takes on a more static state. Furthermore, all those artifacts are compiled into assemblies, and you'll have binary references all over the place. These assembly references are of course internal, and doesn't necessary make your BizTalk solution less loosely coupled, but it will however have an effect on your overall productivity.

Normally, a system consuming a service hosted in BizTalk, would have no knowledge of how that call would be executed on the other side of that end-point. The mechanism behind the itinerary processing lets the consumer of the service describe the process, and pass that description to the service. A pipeline will then resolve the itinerary and proceed with the instructions.  

The itinerary describes a composition of services to be executed, such as transformation, routing and dynamic end-point resolution. Each of which works with a set of resolvers, that will provide the necessary input for that service.

A Uddi resolver, will return a preset property/value dictionary which only suits the adapter provider for dynamic end-point resolution. The BizTalk Rule Engine resolver howerver, is more dynamic and can be used with any adapter provider or service. This is since the user (developer) sets all the Resolver facts within the BRE, such as the name of a mapping file, which can then be used with the transformation service.

The help describes in great detail how’d you go about building your own Services, Resolvers and Adapter providers.

ESB Guidance part 4