There are multiple ways of executing or invoking our itineraries, where the message sender provides explicitly more or less information about the itinerary to execute:
- Submitting the message through the ESB Itinerary Web Services: The client sends the message invoking those web services and attaching to the request a SOAP header that contains the actual itinerary to execute. In this scenario, the initiator has full control and responsibility over what steps compose the itinerary. We will know more about this on the chapter dedicated to the ESB Web Services.
- Using the Itinerary Selector pipeline component with dynamic resolution: The message is received through a port whose receive pipeline uses the Itinerary Selector, configured with a resolver connection string that will find out the itinerary to apply (for example, a BRI resolver connection string). In this scenario, the consumer has relative control over the selection of the itinerary, as some information provided by the consumer could be used as an input for the resolution, and so could influence on its result.
- Using the Itinerary Selector pipeline component with static resolution: The same component is used, but in this case we use a resolver that statically defines the itinerary that will be executed (for example; an ITINERARY connection string). Here, the name of the itinerary and its version is defined in the configuration of the pipeline component, so the consumer has no control at all to select the itinerary that will be executed.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.