* Full support for WCF and it’s protocols, extensibility, etc.

* Durable message delivery using MSMQ and/or SQL Server Service Broker (message persistence in a database is on the todo-list)

* Static subscription configuration via database or web/app configuration files.

* Dynamic (@run-time) subscription configuration via a WCF service interface.

* Transactional delivery to one or multiple subscribers.

* Support for itineraries (complex message flows)

The full list of goodies is documented on the codeplex page: rockbus.codeplex.com.

RockBus can be interesting if you’re looking for a way to decouple your wcf clients and services. For instance, by using publish/subscribe, you can have multiple subscribers (wcf services) receive the same message, while the publisher (wcf client) only has to send the message once, and doesn’t have to know which subscribers actually receive the message(s).

If you want to selectively send messages to subscribers, you can use XPath expressions to filter out the messages. The XPath expressions are part of the subscription information, sent to RockBus by the subscribers.

There are a couple of samples, provided with the RockBus solution:

* 0. No Dependencies: Shows how RockBus can be used to perform in-memory (non-store-and-forward) routing of messages to subscribers. This sample has no dependencies on for instance MSMQ or SSB.

* 1. Durable Cbr: Shows how RockBus can be used to perform content-based routing, while storing the messages in a durable backing store (MSMQ) before delivering them to the subscribers.

* 2. Transactional Delivery: Shows how RockBus can be configured to transactionally deliver one message to two subscribers (one message copy to each subscriber), within 1 transaction. If one subscriber’s transaction rolls back, the other subscriber’s transaction will, too. The transactions are propagated using wcf WsHttp and NetNamedPipe bindings.

* 3. Dynamic Publish/Subscribe: Shows how RockBus can be used to receive subscription information at run-time, store that subscription information into a subscription database, and perform content-based routing on any published messages using that subscription information.

* 4. File Transport: Shows how the RockBus framework can be extended with custom implementation of a transport by implementing the ITransport and IMessagePublisher interfaces. (The File transport is (to be) used for demonstration purposes only).

Short introduction. For my upcoming session at the Sela Developer Practice, I’m developing a demo that involves durable content based routing with MSMQ and WCF. I was using a generic message contract:

[ServiceContract(Namespace = ”SomeNamespace”, SessionMode = SessionMode.Allowed)]
public interface ITwoWay
{
    [TransactionFlow(TransactionFlowOption.Allowed)]
    [OperationContract(AsyncPattern = true, IsOneWay = false, Action = "*", ReplyAction = "*")]
    IAsyncResult BeginProcessRequest(Message message, AsyncCallback callback, object state);
    Message EndProcessRequest(IAsyncResult result);
}

N.B. Apart from the name and namespace, this is identical to the WCF 4.0 RoutingService IRequestReplyRouter interface.

Furthermore I was using:

• WsHttp binding with transactionFlow=”true”,
• [OperationBehavior(TransactionFlowOption.Allowed)] on both the client generic message contract and the typed service contract,
• [OperationBehavior(TransactionScopeRequired = true)] on the service method,
• and a TransactionScope in the client to make sure the WCF call was performed from within an ambient transaction.

I was experiencing a strange issue with flowing the transaction from the client to the service. The transaction SOAP header was not added, even though I was following all the rules to enable transaction flow described above.

It turns out there’s a known issue (described here) with flowing transactions when using a generic message contract. After a lot of research, I found that this is because of the fact that a generic message contract uses wildcard specifications for the Action and/or ReplyAction. Then I wondered how the .NET 4.0 RoutingService would deal with this issue, so I reviewed the code of the .NET 4.0 RoutingService and found this:

private static void ConfigureTransactionFlow(ServiceEndpoint endpoint)
{
    CustomBinding binding = endpoint.Binding as CustomBinding;
    if (binding == null)
    {
        binding = new CustomBinding(endpoint.Binding);
    }

    TransactionFlowBindingElement element = binding.Elements.Find<TransactionFlowBindingElement>();
    if (element != null)
    {
        element.AllowWildcardAction = true;
        endpoint.Binding = binding;
    }
}

Applying this change to the binding configuration fixes the transaction flow when using a generic message contract.

There’s one more gotcha though; if you apply this to the endpoint of the channel (or any class derived from ClientBase<T>), it still doesn’t work, because the channel has already been initialized internally before you get to change the binding configuration. You need to apply this to the endpoint of the ChannelFactory, BEFORE you create the channel. (I use a customized base class (other than ClientBase<T>) for WCF proxies where I arrange for a timely initialization of the binding configuration).

The sample contains two WCF services: StorageService and StorageServiceTransactional. As the names suggest, the first doesn’t use transactions, the latter does. The sample uses wsHttpBinding and netMsmqBinding. Below a picture of a call sequence that could be performed with the sample:

The sample allows to easily (by (un)commenting only a couple of lines) change the sequence of calls. For instance, you could make the non-transactional StorageService (instead of the transactional StorageServiceTransactional) pick up the message from the MSMQ queue, and see what happens to the transactions and the propagation. The number of possible combinations grows quickly; that’s exactly why this sample can come in handy.

The sample writes the TransactionInformation to the console at several steps during the execution of the call sequences. This allows you to inspect the transaction identifiers, and the transaction propagation. Below a screenshot of the console output, with highlights to the transaction identifiers:

In the picture above, you can see that the client and the host used different transactions (different local and distributed identifiers). However, the message exchange between the two services within the host was done within one and the same transaction (same identifiers). The fact that the message exchange was executed ‘within one executable’ doesn’t make too much difference; if you would run two instances of the host executable (and make the appropriate changes regarding the listen urls), the message exchange would still be performed in one transaction. The LocalIdentifier would be different (LocalIdentifier corresponds to AppDomain), but the DistributedIdentifier would be the same.

If you’re wondering about the contents of the SOAP header; below the fragment of the SOAP header (taken with Fiddler2), containing the WS-* header describing the transaction context. You can see that the LocalTransactionIds match the DistributedIdentifiers displayed above:

<CoordinationContext s:mustUnderstand="1" xmlns="http://schemas.xmlsoap.org/ws/2004/10/wscoor" xmlns:mstx="http://schemas.microsoft.com/ws/2006/02/transactions">
  <wscoor:Identifier xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">urn:uuid:e49c680d-ebd5-449a-b2a5-36e01b16ac0f</wscoor:Identifier>
  <Expires>59904</Expires>
  <CoordinationType>http://schemas.xmlsoap.org/ws/2004/10/wsat</CoordinationType>
  <RegistrationService>
    <Address xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing">https://bram08r2/WsatService/Registration/Coordinator/Disabled/</Address>
    <ReferenceParameters xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing">
      <mstx:RegisterInfo>
        <mstx:LocalTransactionId>e49c680d-ebd5-449a-b2a5-36e01b16ac0f</mstx:LocalTransactionId>
      </mstx:RegisterInfo>
    </ReferenceParameters>
  </RegistrationService>
  <mstx:IsolationLevel>0</mstx:IsolationLevel>
  <mstx:LocalTransactionId>e49c680d-ebd5-449a-b2a5-36e01b16ac0f</mstx:LocalTransactionId>
  <PropagationToken xmlns="http://schemas.microsoft.com/ws/2006/02/tx/oletx">AQAAAAM...snipped for brevity...AAAA==</PropagationToken>
</CoordinationContext>

Regarding the asynchronous implementation

The WCF services were implemented with the Task Parallel Library, but you could easily swap that out for ‘old-school’ APM style BeginXxx etc. What’s more important is the way the transaction completion is implemented. Asynchronously completing transactions is more complicated, because there are multiple threads involved in the completion process, and you just can’t rely on using (TransactionScope ts = new TransactionScope) { … }. The sample was implemented using the Transaction.Clone() method, which returns a DependentTransaction. This DependentTransaction is used to block the completion process, and it is passed as the asynchronous state, to be completed when the asynchronous call completes (the EndXxx method);

If you find anything wrong with this sample, pls. let me know! Other suggestions are welcome too. You can download it from here.

Hope this helps anyone!

• You need to receive a message into BizTalk Server, and send an acknowledgement back to the sender (probably using a Request-Response port).
• The response is trivial, it’s similar to a void response in WCF, or containing only information that can be obtained from the request message (such as an ID or something).

<cmc xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <cm xsi:type="add">
    <cpi>
      <name>RouteDirectToTP</name>
      <namespace>http://schemas.microsoft.com/BizTalk/2003/system-properties</namespace>
      <value>True</value>
      <type>Boolean</type>
      <promoted>true</promoted>
    </cpi>
  </cm>
</cmc>

The ContextManipulator pipeline component allows to add, remove, map, change, promote and demote context properties.

Below a screenshot of using the WCF Test Client to receive a response using the above sample:

You can download the sample from my skydrive. It includes the sources for the ContextManipulator pipeline component.

The first sample involves using BizTalk to publish messages on the .NET ServiceBus using the NetEventRelayBinding. The information, published by BizTalk, is retrieved from the yahoo finance website. This part of the demo was inspired by Kent Weare’s blog on consuming the Yahoo finance webservice from BizTalk. After transforming the csv file format, provided by the yahoo finance webservice, it’s published on the .NET ServiceBus and consumed by a console application client.

The second sample involves duplex communication using the NetTcpRelayBinding. It’s amazing to see that sessionful duplex can be performed accross the .NET ServiceBus. Hope you enjoy!

The ESB.Extensions builds on top of the ESB Toolkit 2.0, and thus requires BizTalk Server 2009. The ESB.Extensions contains a number of services, that are itinerary-aware: ReceivePipelineService, SendPipelineService, ResequencerService and ResequencerGoService. Let’s look at them more closely.

The ReceivePipelineService

When the ReceivePipelineService executes, the following steps are performed:

1. Receives a message.
2. Uses the resolution framework to resolve the receive pipeline type.
3. Executes the receive pipeline.
4. [Optional] If the pipeline didn’t set these properties, assigns BatchId and SequenceId promoted properties to the pipeline output message(s).
5. [Optional] If the resolution (resolutionDictionary) included a new itinerary for the pipeline output message, this new itinerary is applied to the pipeline output message(s), and the original itinerary is reserved for further processing of the original (inbound) message. If no itinerary was specified during the resolution, it is assumed that the pipeline output message(s) should continue the itinerary of the original message, and processing of the original message is discontinued.
6. Publishes the pipeline output messages.
7. [Optional] If a new itinerary was specified for the pipeline output message(s) during resolution, advances the itinerary of the original message and publishes the original inbound message (if it had outstanding itinerary steps).

The following drawing depicts an itinerary, which I have titled “OneWay-Debatch-MessageSendPort” (ODM) that uses the ReceivePipelineService:

OnRamp, Debatch, MessageSendPort

Fairly simple scenario, you send an order batch through an itinerary onramp to BizTalk, where the ReceivePipelineService orchestration will pick it up, debatch it using the receive pipeline, and forwards the order items to the Message SendPort. (i.e. bound to a FILE location).

Debatching is one obvious application for the ReceivePipelineService, but you can specify any receive pipeline type in the resolver, so it can also be a 1:1 scenario where the pipeline has only 1 output message. I’m fairly certain that it will not work with FFDisAsm pipelines, though!

The SendPipelineService

When the SendPipelineService executes, the following steps are performed:

1. Receives the 1^st message within the batch of messages to be executed by the send pipeline. After receipt of this 1st message, a convoy subscription is created based on the Itinerary (should point to SendPipelineService) and the BatchId.
2. Resolves the SendPipelineServiceResolution object, necessary to perform the execution of the send pipeline. This resolution object contains the following parameters:
   • Send pipeline type: the type of the send pipeline to execute.
   • XLANGMessageComparer type: The SendPipelineService uses a serializable list to collect the messages to be aggregated. You can specify the comparer type to control how the messages are sorted. This happens in memory, but does not add much overhead compared to the use of Microsoft.XLANGs.Pipeline.SendPipelineInputMessages. I used an XLANGMessage comparer that compares the messages’s SequenceId promoted property values.
   • Batch Timeout: The timeout to apply to the entire batch. When this timeout expires, all the collected messages up to that point in time will be aggregated and the service completes.
   • Message Timeout: The timeout to apply to each message. When this timeout expires, all the collected messages up to that point in time will be aggregated and the service completes.
3. [Optional] If a new itinerary was specified during resolution, the new itinerary will be applied to the pipeline output message, and the original inbound message will continue it’s own itinerary. If no new itinerary was specified, it is assumed that the original inbound message’s itinerary should be applied to the aggregated message. So, if a new itinerary was specified, the original message’s itinerary is advanced and applied to the original message, and the original message is republished for further processing.
4. The inbound message is added to a list of pipeline input messages.
5. The receive loop (batch convoy) starts.
6. The next message within the batch is received and added to the list of pipeline input messages.
7. [Optional] Like in step 3, if necessary, the original message’s itinerary is advanced and the message republished.
8. When all messages have been received (or when a Batch or Message Timeout has occurred), the receive loop (and the corresponding batch convoy) is ended.
9. The pipeline input messages are sorted using the XLANGMessageComparer type, specified in the resolver.
10. The itinerary (new or original advanced) is applied to the pipeline output message, and the message is published.

Below a scenario that uses both the ReceivePipelineService and the SendPipelineService:

OnRamp, Debatch, Aggregate, MessageSendPort

An orderbatch gets sent through an itinerary onramp, gets debatched by the ReceivePipelineService. The resolver does not specify a new itinerary, so the original message’s itinerary is used for the debatched messages. The debatched messages all have the same BatchId, and have a current itinerary step that points to the SendPipelineService, so they get picked up by the SendPipelineService. The SendPipelineService sorts and aggregates the messages, and publishes one output message, which is sent to the offramp.

The Resequencer and ResequencerGo services

The idea for these services actually came from a TechEd (2006?) session, where Lee Graber detailed the use of the (what he called) Go-pattern to implement a resequencer. The Resequencer and ResequencerGo services work together to resequence any given sequence of messages. The ResequencerService blocks processing of a certain message until it receives the corresponding Go message (by using a parallel convoy). The ResequencerGoService’s responsibility is to work out which message within the sequence is up next and publishes the corresponding Go message.

The ESB.Extension implementation let’s the resolver decide which message is up next, so the resolver (i.e. BRE) could access a database or any other (in-memory?) representation of the message sequence (or batch) to determine who’s next. In my BizUnit tests I have used the simplest possible scenario, where the maximum number of messages is always 5 and the next SequenceId is simple determined by incrementing by 1.

Below a scenario that uses the debatcher, aggregator and resequencer services:

OnRamp, Debatch, Resequence, Aggregate, MessageSendPort

In this scenario, the orderbatch gets debatched, every order item gets picked up by a seperate Sequencer instance. The 1st Go message, corresponding to the 1st message (SequenceId == 0) is sent to BizTalk, triggering the 1st Resequencer to release the 1st message. That message gets picked up by the SendPipelineService, and the SendPipelineService stores the pipeline input message, then itinerary-advances and republishes the original message, which triggers the ResequencerGoService to increment to the next SequenceId and publish the corresponding Go message. This process repeates until all messages have been processed (the ResequencerGo’s resolution works out when it is the last message and does not publish a new Go message when it is the last). The SendPipelineService aggregates the message, applies the itinerary and ships it off to the offramp.

Conclusion

A select number of scenarios has been described here, and these are also the scenarios that have been tested. But there can be many many other scenarios, ranging from likely to not-in-a-million-years, that could be implemented with these services:

• Receiving incoming messages for a certain interval (24 hours?), then sort and aggregate them and sending them off.
• Debatching, sending the seperate items to web services, aggregating the responses, sending them back to the caller. (Doesn’t work yet because Request-Response hasn’t been implemented yet; future version)
• Receiving incoming messages, block them with the ResequencerService, after a specified interval, start sending the messages to another system in a specified order.
• If I missed an obvious scenario, please drop a comment!

A short summary of how the ESB Toolkit resolution framework works. Resolvers are configured in the esb.config file using a specific name that can be coupled to a .NET type that needs to implement IResolveProvider. From the esb.config:  

<resolver name="BRE" type="Microsoft.Practices.ESB.Resolver.BRE.ResolveProvider, Microsoft.Practices.ESB.Resolver.BRE, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

The above type implements IResolveProvider, and the ESB Toolkit provides a ResolverMgr and ResolverConfigHelper to allow for retrieving and caching the appropriate resolver types when the resolvers are retrieved from the itinerary and to be used by the itinerary service.  

Let’s look at IResolveProvider:  

public interface IResolveProvider
{
    Dictionary<string, string> Resolve(ResolverInfo resolverInfo, XLANGMessage message);
    Dictionary<string, string> Resolve(string config, string resolver, XmlDocument message);
    Dictionary<string, string> Resolve(string config, string resolver, IBaseMessage message, IPipelineContext pipelineContext);
}

IResolveProvider provides three methods that all perform more or less the same task: resolve some information into a Dictionary<string, string>. My main problem with this approach it that everything that needs to be resolved needs to be in the form of string in order to be applicable for this way of resolution. I would expect a generic resolution framework to be more generic than that!  

To make matters worse, there are limitations to which keys you are allowed to use in the resolution dictionary, if you’re using the out of the box resolvers (i.e. the BRE resolver). Basically, you’re stuck with the keys that are provided on the Microsoft.Practices.ESB.Resolver.Resolution type:  

[Serializable]
public sealed class Resolution : IContextParameters, ITransformParameters, IEndpointParameters
{
    ... private members & constructor (left out for brevity) ...  

    public string Action { get; set; }
    public string ActionField { get; set; }
    public string CacheTimeout { get; set; }
    public string DocumentSpecNameField { get; set; }
    public string DocumentSpecStrongNameField { get; set; }
    public string EndpointConfig { get; set; }
    public string EpmRRCorrelationTokenField { get; set; }
    public bool FixJaxRpc { get; set; }
    public string InboundTransportLocationField { get; set; }
    public string InboundTransportTypeField { get; set; }
    public string InterchangeIdField { get; set; }
    public string IsRequestResponseField { get; set; }
    public string MessageExchangePattern { get; set; }
    public string MessageType { get; set; }
    public string MethodNameField { get; set; }
    public string OutboundTransportCLSID { get; set; }
    public string ReceiveLocationNameField { get; set; }
    public string ReceivePortNameField { get; set; }
    public bool Success { get; set; }
    public string TargetNamespace { get; set; }
    public string TransformType { get; set; }
    public string TransportLocation { get; set; }
    public string TransportNamespace { get; set; }
    public string TransportType { get; set; }
    public string WindowUserField { get; set; }
}

Where the three Interfaces (IContextParameters, ITransformParameters, IEndpointParameters) all define a seperate set of properties (which are implemented by the Resolution type, see above).  

The resolvers use this Resolution type to fill the (more generic) Dictionary<string, string> type using ResolverMgr.SetResolverDictionary:  

public static void SetResolverDictionary(Resolution resolution, Dictionary<string, string> ResolverDictionary)
{
    try
    {
        ResolverDictionary.Add("Resolver.Action", resolution.Action ?? string.Empty);
        ResolverDictionary.Add("Resolver.ActionField", resolution.ActionField ?? string.Empty);  

        ... more calls to ResolverDictionary.Add("Resolver.Xxx", resolution.Xxx ?? string.Empty); (removed for brevity) ...   

        ResolverDictionary.Add("Resolver.TransportType", resolution.TransportType ?? string.Empty);
        ResolverDictionary.Add("Resolver.WindowUserField", resolution.WindowUserField ?? string.Empty);
    }  

   ... some exception handling ...  

}

This basically means that you can only work with the properties that the Resolution type provides. I see that as another limitation, because it means that the current resolvers are limited to only be able to resolve those properties. If I want to resolve a string value, that does not correspond to one of the properties of the Resolution type, I have two options:  

• Abuse one of the properties of the Resolution type. I.e. put a pipeline type name in the property TransformType. I started with this workaround, but it became a problem because I needed to resolve more complex objects than just strings (more on that later).
• Write a custom Resolver. For instance, this means that I would need to implement a custom BRE resolver, that does resolution using the BRE in exactly the same way as the standard BRE resolver, just because of the different property.

The conclusion is that at the moment, the resolvers are coupled to what those resolvers are actually resolving. That should be decoupled if you ask me.  

I took a stab at improving this situation by implementing a resolution framework that uses the following interface:  

    public interface IResolutionProvider
    {
        ResolutionDictionary Resolve(ResolverInfo resolverInfo, XLANGMessage message);
        ResolutionDictionary Resolve(string config, string resolver, XmlDocument message);
        ResolutionDictionary Resolve(string config, string resolver, IBaseMessage message, IPipelineContext pipelineContext);
    }  

    [Serializable]
    public class ResolutionDictionary : Dictionary<string, object>, ISerializable
    {
        public ResolutionDictionary()
        {
        }  

        public void SetValue(string key, object value)
        {
            base.Add(key, value);
        }  

        public object GetValue(string key)
        {
            if (base.ContainsKey(key))
            {
                return base[key];
            }
            return null;
        }  

        public string GetString(string key)
        {
            return GetValue(key) as string;
        }
    }

This dictionary allows resolvers to resolve anything, for as long as the resolution objects are serializable. It also allows for using any key value (string). The code, that’s calling this kind of resolution, will be responsible for casting the object to the type that it expects.  

The ESB.Extensions resolution framework, that uses the above IResolutionProvider and ResolutionDictionary, is still compatible with the esb configuration and the itinerary designer.  

A full example can be found the in the ESB.Extensions solution on codeplex. I use the resolution framework there to resolve parameters needed in a couple of services: ReceivePipelineService, SendPipelineService and Resequencer services. I implemented some BRE vocabularies to enable for creating the resolution objects.  

Off course, any feedback is welcome!

• http://www.biztalkgurus.com/forums/p/12435/24295.aspx (Greg Forsythe nailed it)
• http://www.eggheadcafe.com/conversation.aspx?messageid=30040782&threadid=30040773
• http://www.tech-archive.net/Archive/BizTalk/microsoft.public.biztalk.server/2008-10/msg00018.html

I reproduced this behaviour both on a BizTalk Server 2009 deployment and in standalone mode with the ExecuteRecievePipelineStep, found in BizUnit 3.1. See the screenshots below.

Schema containing both promoted and distinguished property

Message Context missing the promoted property

For BizUnit ExecuteReceivePipelineStep intimi: I used test T_015, added both a distinguished and a promoted property to the Child1Attribute1 attribute (which is of type string) from schema0.xsd, and pointed it to promoted Property2 (which is of type string); then I ran the test. The screenshots above show that the promoted Property2 property isn’t there.

I have not tested this with the Flat File Disassembler pipeline components.

A workaround for this bug is to define the schema to only use the promoted property, and use the promoted property syntax from within your orchestrations.

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 &amp;lt;, &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.

Fixed Itinerary OnRamp Pipeline Configuration

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!