Backing away from MSMQ - this time
Earlier, I blogged that I was looking at MSMQ to perform message delivery within our application. Given our application is shrink-wrap and runs in a variety of computing environments (few of which have ActiveDirectory, much less MSMQ installed), I decided to shy away from that product. MSMQ is a good product in the right situations, but I believe this is a situation that merits a different approach.
The problem is this: when one plant is a part supplier to an item made in another plant, guaranteed messaging must take place. Timing is not critical, but ASAP. All plants must be capable of talking to one another - so symmetry in implementation and interface is desirable (we are talking supply-chain here). MSMQ throws out symmetry at each plant to some degree especially when dealing with workgroup mode. Simplicity is always a good thing, and in this case it's a really, really good thing (cost, time, potential errors make MSMQ fairly complex).
The solution I've settled on involves calling a webservice from a DTS. All required transactions get dumped into a transaction table and a regularly schedule DTS hits that table. From there, it calls a C#/COM Interop object that makes a webservice call given the payload and http address. If it fails, it tries again on a subsequent run. If it succeeds, it marks the tx successful and life is good.
I was considering MSMQ for its guaranteed deliver alone - no need for special routing setups. The nice bit with the webservice approach is that the C# object carries an abstraction point with it, so I could interchange other delivery mechanisms on an “as-needed“ basis. The other nice piece to this solution is that I maintain full visibility of transmission progress from the application. On the other hand, MSMQ becomes a black-hole with a significant coding effort to deal with the queue structure at each plant - which becomes worse when you consider multiple plants can run on the same box.
I initially discarded webservices because they do not offer guaranteed deliver. We have an entire supply-chain management offering built entirely on webservices, but I try not to get in the mode of applying one technology to every problem. But I think the DTS-based implementation guides us well in the guaranteed delivery approach and implementation costs ($, time, support, etc.) are just too compelling to dabble in message queueing.