The first sample I put together for creating a message service was fairly simplistic and was missing a few key features necessary to put together a truly valuable message service for the ESB Toolkit. Here are the pieces that were necessary and have been included in this new sample.
Resolver Support
The message service built in the original sample had a status property that should not be hardcoded, but configurable based on where the itinerary step is located. This seems like a pretty common need of message services or even orchestration services to have resolver values outside of those provided by the included resolvers. The included resolvers are based on routing or transforming which makes sense, but what if you need other properties? The resolver framework exists to provide information to itinerary services which do the actual work, but it is just a dictionary. What information and how the resolver gets it in there is not limited.
In this case I just wanted something like the STATIC resolver, but based on the values I need for the message service to run. In this case the only property I cared about was a Status of the Order to track to my BAM tables. To do this I put together two potential resolvers. The first is called the ProperyCollectionResolver and the other is the PropertyResolver. I will go into details in the next section on why there are two.
The final piece was to add support in the message service for the resolver. This entails a few steps of invoking the resolver framework to execute and receive the resolver dictionary. This was added to the base BAMMessageService to avoid repeating this in extension classes. Below is the snippet that parses the resolver string and then invokes the resolver framework.
Designer Support
The designer really is the best new feature of the Toolkit from my point of view. I worked on a lot of the core features in the ESB Toolkit around itineraries and thought the changes we made were good, but the designer really adds a significant productivity boost. Key to that productivity is validation, direct support for the ESB engine framework artifacts (resolvers, itinerary services, adapters) and integration with BizTalk. The message service from the original sample achieved some designer support just by registration in the configuration file, but now there are two new resolvers.
The next step was to give the resolvers designer support as well. Using the Designer Extensibility sample as a guide, I included full support for the resolvers. So the question is why two resolvers that basically do the same thing? Both resolvers add whatever key-value pairs are in the resolver string to the resolver dictionary. The reason is pretty simple. The PropertyCollectionResolver just exposes a simple dialogue to add key-value pairs. This could be used with any message service or orchestration created to provide values to the itinerary service. The problem is that there is no design time validation other than correctly formatting the resolver string (which by the way could be a pain in the past when manually creating the itinerary). The advantage is that this can be used right away with any itinerary service. Below is the UI presented for the property collection which takes anything added.
The PropertyResolver does not have a built-in designer support. To correctly utilize it, resolver extenders based on the values the itinerary services are expecting must be added. The advantage is that you can potentially add properties as enums or include other validation with the built-in Enterprise Library Validation block support. The problem is that potentially each itinerary service would require a resolver extender based on the properties it will need. Below is a sample of the properties presented for the resolver extender built specifically for the OrderTrackingMessageService.
Itinerary Extension
Another extension point not well known in the ESB Toolkit is to implement your own itinerary manager responsible for making the right things happen when advancing the itinerary, serializing/de-serializing the itinerary, etc. Implementing your own itinerary manager is not something easily accomplished and probably not a recommended decision. This does enable some interesting possibilities though. The original message service sample was driven by posts on the ESB Toolkit forums about logging to BAM. In the ESBExtensions solution is the ItineraryV2 which extends the base ItineraryV1 from the Toolkit. The purpose of ItineraryV2 is to potentially provide your own BAM logging on itinerary advance. I did not implement this specifically but provide instructions on how to use this itinerary manager and also a snippet on where/how to log BAM data.
Wrapping Up
I have included installation instructions in the base directory of the sample in a text file called InstallInstructions.txt. Also make sure to unzip the sample to the same directory as your other ESB Toolkit samples. The strong name key file path is the same as other samples which is required to build the project. If you do want to run the tests make sure the resolvers and message service are registered in the esb.config file.
This sample gives a good practical example of the various extensions points in the ESB Toolkit. Please see the zip file with the sample below. I hope to have something on extending adapter providers soon as well!