Wednesday, April 15, 2009

Sometimes It's Easier to Stick With What You Already Use

For the upcoming London Open Space Coding Day, we're thinking about working with messaging in enterprise applications.

That reminds me of the lesson I learned the last time I tried using MSMQ: Sometimes, it's easier to stick with what you already use.

The scenario was that we were going to import some record updates from an external system. Once we grabbed them from the external web service, we wanted to queue them up and bring them into our system.

"Aha!" I thought. "We need a queue. This is what MSMQ is for. We'll use that."

Unfortunately, this import is a very, very small piece of an application that otherwise is very, very largely database-driven. Ever since implementing the import, every time someone needs to test it, there's baloney about the MSMQ queues not getting set up right or not having permissions or some other junk. And that's ignoring that when we first coded it, we found out that lots of our developers didn't even have MSMQ installed, and they all had to install it.

On the other hand, if we'd set up the queues to be stored in the database, there would have been no problem. In our application, if you can't access the database, you're not going anywhere. In fact, in the next release, another developer needed a queue. He stored it in the database and never had any of the problems I did.

Now, this isn't a story about how you shouldn't use MSMQ. Instead, it's a story about how if your application is largely based on one technology, and to implement a single feature, you have a choice between using that technology and another one—where both will work pretty much equally well—you might want to seriously think about sticking with the one the rest of the application is based on.

On a related note, a few months ago, when I was at the February meeting of the London .NET User Group, Gojko Adzic and David de Floriner gave a talk on NServiceBus. It looked like an interesting way I might have been able to interface the message queuing so that I could have swapped out MSMQ with our SQL Server database without needing to change code.

No comments:

Post a Comment