With the release of the .NET RC, the number of independent folks playing with the bits and putting together projects has grown tremendously. This is fantastic to see, because the more eyes we get on the product and the more demo code written the better the feedback. I love customer feedback 🙂
Here’s another Routing Service project, this time from Rochard Seroter, who put together a “multi-type” Routing Service hosted in WAS (the easy way this time). Here’s the link.
Richard also had an interesting question: “Do the contracts of all the services behind the routing service need to implement the same contract? Otherwise, where do you do the format transformation? In a custom behavior? Or would you recommend that the service accept an untyped object and cast it to the known type later?”
This is a great question as it points to one of the strengths of the Routing Service, which is its typelessness. The question now is what happens when the “types” presented at the front of the Routing Service don’t map to the ones that the backend services are expecting?
To answer Richard’s question: No, they don’t have to have the same contract. By default the Router doesn’t touch the message body: we take whatever was presented by the client or returned from the service (there’s one notable exception to this related to processing Faults). If your client is presenting messages that your remote services can’t understand (are incompatible) then yeah, you’ll need a transformation of some sort. I’ve seen this done a few ways:
1) A generic XSLT behavior, attached at either the inbound service endpoint (applied to all messages) or the outbound endpoint (transformation specific to this destination).
2) The use of something like automapper in a behavior. The downside of Automapper is that is presumes you’re working with strongly typed objects, which you aren’t by default at the Routing Service (though you could write some code that translated the XML message into your strongly typed objects and then converted it with AutoMapper. (I’d probably just write the XSLT, but that’s a less robust solution).
Going untyped is a third option, but is only necessary if you’re going to do the mapping/transformation/casting later.
Let’s keep those Router sample projects coming!