Itineraries are at the core of the ESB Guidance offering. They enable the client to define what services its message needs, rather than fixing them at the provider. So in a typical BizTalk service an orchestration will define the steps - e.g. receive, transform, enrich, send. With ESB the client specifies those steps in an itinerary.
This has three major benefits. Firstly you can decouple all your service components. Instead of exposing a composite service tailored for each client, the clients do their own tailoring by defining the itinerary steps they require. Secondly, leveraging ESB's resolution capabilities, the service used to process each step can be dynamically resolved. The fulfillment of the service is then decoupled so new service providers can be swapped in without the clients changing or even knowing. Thirdly, itinerary steps can specify services which exist outside of BizTalk configuration, so you can design an app with fewer BizTalk artifacts to develop and maintain.
Take an example where ProjectX and ProjectY both submit payments to PeopleSoft. In a BizTalk app this could be structured as an orchestration with a dynamic receive subscribing to SubmitPayment message types. The orchestration has steps to validate the message and pass on to PeopleSoft, along with various levels of error handling. Consumers ProjectX and ProjectY have different message content, so each has its own receive location with a dedicated map, transforming to the SubmitPayment schema for the orchestration. So far we have two maps, two receive locations, a receive port, orchestration, and various send ports for PeopleSoft and the exception handlers.
Say the PeopleSoft team are finding issues with some payments originating from ProjectX and want to extend the validation. The new validation is only relevant to ProjectX payments and should not be applied to any other requests. In the BizTalk implementation we need to change our orchestration. It may be that we can identify ProjectX payments from the message properties and perform the extra validation in the orchestration. Or it could be that we need a complete new orchestration dedicated to ProjectX, which does the validation then calls into the existing orchestration. The existing orchestration can no longer subscribe to all SubmitPayment messages so we'd need new dedicated receive ports for each client. There are various approaches, but all of them effectively mean the service knows about different clients and offers a tailored solution to each.
In ESB Guidance the solution would look very different. We still have the maps and the orchestration, but now it only has the validation steps and the send to PeopleSoft. ESB Guidance has a rich layer of error handling so we can dispense with the custom exception handling. There are no specific receive ports or locations for the service – we'll use the generic itinerary on-ramp.
The client builds an itinerary that says: map the enclosed message then call this service. Map and service details are specified statically or as dynamic lookups. The client then sends the itinerary and the message to the ESB Guidance on-ramp. The on-ramp is a receive port with a pipeline component which promotes the itinerary details (received in the message header) to context properties. Then a generic orchestration picks up the message and, for each step in the itinerary, resolves the service and submits to it a copy of the message.
Our requirement to change the validation is now straightforward – just expose the additional validation as a separate service, and include that service as a step in the ProjectX itinerary (other consumers' itineraries don't need to change).
The next couple of posts will look at what happens when the itinerary is processed by the on-ramp, and provide a walkthrough for constructing and submitting a simple itinerary.