Pros/Cons of using BizTalk instead of NServiceBus

Question

I am curious if it even makes consider BizTalk for the implementation of a pub/sub messaging architecture (basically what you can do with NServiceBus or MassTransit is all I really need). My manager tends to want to stick with frameworks provided directly from Microsoft and so as part of my due diligence as to which one to use I need to give a good set of pro/cons for both sides. Any guidance would be greatly appreciated!

Answer 1

Biztalk is a broker and is more suited for EAI within the boundaries of different business services. A servicebus is fundamentally different. A comparison can be found here:

http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk

If you can share some of your requirements I might be able to give some more guidance.

Answer 2

It's important to note that BizTalk is a server product for Enterprise Application Integration (EAI -- as Andreas mentioned). It's more involved and complicated than a framework.

Microsoft does have the Enterprise Service Bus Toolkit available to use within BizTalk, so that you can call your BizTalk environment your ESB. What they consider "ESB" may not be what you consider ESB. You can take a look at their ESB Toolkit page (http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx), but it includes things like:

• Dynamic (i.e., at run-time) message transformation and translation.
• Message routing can be content-based, itinerary-based, or context-based, and determined at run-time.

Of course, the publish-subscribe pattern is not the same thing as using a service bus.

BizTalk does do pub-sub well, whether or not you use the ESB Toolkit. It's extremely simple to publish a single message to the BizTalk "Message Box", and have the message routed to any and all subscribers. The pub-sub solution means that BizTalk acts as a broker, but this helps guarantee that messages do not get missed, and all messages are tracked. A BizTalk pub-sub solution has built-in extensibility points that allow us to add, change, or remove endpoints without impacting the rest of the solution.

All that being said, your requirements may not dictate extensive message reliability, monitoring, and tracking, so it could be that BizTalk is not the best fit for you. It is a large investment, and since the product can do so many different things all at once, it can be daunting at a first glance.

A new book was just published call Applied Architecture Patterns on the Microsoft Platform, which covers much of this. One of that book's authors, Richard Seroter, also published SOA Patterns with BIzTalk Server 2009, which would be essential reading if you do decide to go with BizTalk for your company.

Answer 3

One of the major cons of a Broker is that it is very difficult to version and upgrade. You would have to stop the flow of messages to upgrade a particular endpoint(s). A Service Bus allows endpoints to be autonomous and be upgraded independently.

Then there is a difference in terms of scale. With a Broker the tendency is to scale those up(vertical) versus a Service Bus which is built for scaling out(horizontal). You would also have to make the Broker highly available through some sort of HA setup(clustering usually). This combined with the cost of software to do so can become pretty cost prohibitive.

NSB in particular will be offering a paid support model so if your manager is nervous about not having someone on the other end of the line when something goes wrong, you can buy into support.

Answer 4

I'm with Andreas on this - BizTalk is generally more suited to 'value add' integration and business process management, rather than ESB type activity. BizTalk is good at:

• BPEL
• Long Running / Compensated Transactions
• EAI
• Brokering / Mapping
• Protocol changes (MQ to WCF, Flat File to SAP etc)
• EDI, RFID

However, efforts have been made to use BizTalk as a service bus, notably the ESB Toolkit