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?
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.