WSE Msmq Transport Update

Those of you more well-versed in the System.Messaging namespace may safely ignore this post.

The following statement

Do not use the asynchronous call BeginReceive with transactions. If you want to perform a transactional asynchronous operation, call BeginPeek, and put the transaction and the (synchronous) Receive method within the event handler you create for the peek operation. Your event handler might contain functionality as shown in the following C# code.

from the MessageQueue.BeginReceive msdn documentation can be very helpful if you intend to implement transactional, msmq'ed soap transports with WSE 2.0.

So far, my experience has been considerably more positive than the same in the Tech Preview release, which itself was that bad, primarily due to the changes per hervey's discussion of the new channel classes and interfaces. The Microsoft.Web.Services2.Messaging namespace is definitely cleaner than it was before. Unless I am missing something, there is still a violation of the Hollywood principle buried in the SoapTransport heirarchy that requires an invocation of DispatchMessage. The async callback stuff gets a bit hairy if you aren't careful, but other than that, it has been reasonably smooth sailing. I am worried about managing the scope of transactions, especially in conjunction with enterprise services. That could get ugly. It has been nice to dive down deep for a while, especially with so much of what I have been doing lately not being that.

Comments

[Jef Newsom]

The last paragraph says: ...considerably more positive than the same in the Tech Preview release, which itself was that bad, ... though it should have said: ...considerably more positive than the same in the Tech Preview release, which itself was *NOT* that bad, ...