These two services allow clients to submit a payload to be processed by an itinerary that is explicitly defined by the client. They are respectively meant to execute one-way and request-response itineraries. The itinerary XML definition is attached to the web service request as a SOAP header.

Once we add the service reference to those web services in our code, the class that defines that SOAP header is represented by the Itinerary class, as shown in the following screenshot:

To populate the Itinerary class instance that will be attached as a SOAP header, we can either instantiate the Itinerary class and fill out by code all it properties (itinerary services that compose the itinerary, resolvers to be used by the itinerary, and so on) or just deserialize the itinerary specification from an XML file. This last approach is a much easier and maintainable one.

So given the XML definition as shown in the following XML file:

We just need to deserialize its contents into the corresponding Itinerary class instance, and use it right away in the web service proxy instance that we will use to call the service, as shown in the following example:

XmlDocument payload = new XmlDocument();
payload.Load("myPayload.xml");

asmxItineraryTwoWay.Process svc = new asmxItineraryTwoWay.Process();
svc.Credentials = System.Net.CredentialCache.DefaultCredentials;

XmlDocument itdoc = new XmlDocument();
itdoc.Load("myItineraryXML.XML");
string ItineraryStr = itdoc.DocumentElement.OuterXml;


StringReader reader = new StringReader(ItineraryStr);
XmlSerializer ser = new XmlSerializer(typeof(asmxItineraryTwoWay.Itinerary), 
  http://schemas.microsoft.biztalk.practices.esb.com/itinerary");
asmxItineraryTwoWay.Itinerary itnryTwoWay = (asmxItineraryTwoWay.Itinerary)ser.Deserialize(reader);

svc.ItineraryValue = itnryTwoWay;
XmlNode node = (XmlNode)payload;

svc.SubmitRequestResponse(ref node);

As the web service request reaches the On-Ramp receive location for the service, the ItineraryReceiveXml pipeline configured in that receive location processes the message received. Within that pipeline, the ESB Itinerary Pipeline component is the one in charge of extracting the itinerary definition received as a SOAP header, and promoting its information into the message context, so the message can follow the usual itinerary processing logic.

These services are similar to the previous ones, but these have a different pipeline configured on their receive location, the ItinerarySelectReceiveXml pipeline. This pipeline has the ESB Itinerary Select pipeline component, that allows the client just to specify the name (and optionally the version) of the itinerary, and the component automatically retrieves the itinerary definition from the Itineraries repository. The following example shows how we could consume these services in our client application:

using (ItineraryTwoWayService.ProcessRequestResponseClient client = new ItineraryTwoWayService.ProcessRequestResponseClient("WSHttpBinding_ITwoWayAsync"))
{
  XmlDocument payload = new XmlDocument();
  payload.Load("myPayload.xml");
  object response = payload.OuterXml;


  itinDesc = new ItineraryTwoWayService.ItineraryDescription();
  itinDesc.Name = genericItineraryName;
  itinDesc.Version = genericItineraryVersion;
  itinDesc.Guid = Guid.NewGuid().ToString();
  txtTrackingID.Text = itinDesc.Guid;

  client.SubmitRequestResponse(itinDesc, ref response);
}

The pipeline configured on these two uses the ESB Itinerary Selector pipeline components, but uses it in a slightly different way.

They don't receive an itinerary description as a header that defines the name of the itinerary, but they rely on the resolver connection string configured on the ESB Itinerary Selector pipeline component to dynamically resolve the itinerary.

We could use a BRI connection string in the ResolverConnectionString of the pipeline component. The connection string could look like the following:

BRI:\policy=policyName;version=1.0;useMsg=true

When the call arrives at the service, the pipeline component will execute the dynamic resolution by means of the BRE policy specified on it, using the contents of the message as an input for the policy. The policy will resolve the itinerary name and version according to our business rule, and retrieve the actual itinerary from the Itineraries repository. Finally, the itinerary information is promoted to the message context.