Why Messaging #6: Why not …

Posted by Dru Sellers on September 8, 2009

As I have been writing this series I have been asked a couple of times why I didn’t use technology X. I have tried to respond in the comments, but for those of you that may not be following the comments I have tried to summarize my thoughts here.

Why not BizTalk?

Actually I did consider BizTalk and ruled it out for a couple of reasons. 1. I have heard more horror stories than success stories 2. The price tag, I just couldn’t make the case for that much money on a concept that was still in the initial testing stages. 3. I am no BizTalk expert, but I was concerned about the testability of such a program. 4. I didn’t want to have to install BizTalk onto my dev machines.

Why not Tibco, SonicESB, etc?

See BizTalk

Why not Sql Server Service Broker?

1. Overall longevity of system, its a child product of Sql Server not its own product like BizTalk. 2. Like BizTalk I was worried about the testability of the system. 3. My SQL Servers do enough work as it is, and I would prefer not to put more stuff on them, especially business logic.

Why not NServiceBus?

Probably the best question for me really. At the time it seemed complex (it is a complex problem). Used a lot of verbage I wasn’t familiar with (unicast / multicast, I just want a message). Was tied to Spring.Net (not anymore). I wanted a simple NSB for use in my shop (as I said its not a simple problem though), in the beginning MT was very small and easy. Although as Chris and I have been working MT it is getting more complex, to handle the complexity in the problem. I am starting to appreciate the complexity that adding this architecture brings to a project (because it is explicit complexity which is helping to clarify the overall problem) but I also see the tremendous value it brings as well.

Lastly: In the end it was a means for me to learn, I enjoy coding and thinking about problems. It has made asking questions about the problems easier as I can phrase them now in the NSB world and the MT world. Its not a path I recommend for just anyone but it worked for me.

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Steve Py

    It’s an interesting discussion point that I’ve run into the past, also coincidentally around messaging vs. something else. (at the time, web services/WCF)

    On the one hand there’s the argument that “if you do it that way, you’re re-inventing a wheel, or using a train when you could be using a plane.” Technology X+1 is designed to solve your problem, and more!

    My argument is often that I understand the problem domain, and I understand particular solution paths to solve that problem, and Technology X I know will fit that problem domain well. X+1 might be better, but I don’t fuly understand X+1 yet, it’s also immature. Adopting X+1 often means stumbling around a bit, and the risk is that I won’t fully understand, or be happy with the solution.

  • Jason Meckley

    another option for messaging is rhino service bus. You can find the lastest bits on github.

  • http://www.chrisholmesonline.com Chris

    You’re making a good decision, I think. I always believe it’s a good idea to learn through coding. Especially when it comes to a complex technology. You will be much better positioned in the future to know whether a tool like NServiceBus is the right tool for the job, because you’ve built your own and understand the problem domain and the complexity so much better.