Herveyw provides detailed insight into the WSE 2.0, in particular discussing changes to the underlying messaging channel model.
In the article, he discusses how transport semantics are not leaked up to the channel level. It begs the question of whether or not the parallel tranport/channel heirarchy in the Microsoft.Web.Services.Messaging namespace has been tamed. It seemed like the majority of the necessary concepts were there in the tech preview modulo a bit of massaging (i.e. SoapChannel, ITransport, IFormatter). When I first saw the class reference doc, I wondered why there were transport specific channel implementations given an ITransport abstraction. Performance maybe.
I have been interested in this thread, because I want to implement mq and msmq as transports for the services in the systems that I am working with. I want the consumers and providers to have to do as little as possible to leverage MOM to provide "guaranteed," idempotent delivery. In researching the options, I ran across the following articles that were of interest.
- The first article demonstrates extending the ASP.NET framework (System.Web and friends) to provide MQ and MSMQ transports.
- The second article demonstrates extending the WSE 2.0 technology preview to provide an MQ transport. It should be trivial to extend it to support MSMQ given the working MQ example.
- Additionally, Kevin Hammond has been working with the WSE team to implement MQ and MSMQ transports, and according to Herveyw that has had a signficant impact on the channel redesign.
For my project, I am prescribing that in the context of a service-oriented architecture, message-oriented middleware should be a transport that is bound to. Service providers and consumers should not know the difference (Within Reason-caveat lector).
There is a good wiki on Parallel Inheritance Heirarchies on the c2 site. Speaking of c2, I have a Thought Leaders entry I need to add.
Comments