4

I'm not too familiar with ESB or Biztalk and am trying to get my head around what makes the most sense from an EAI perspective if you already own Biztalk. As I understand Biztalk is a message broker(hub and spoke) and the ESB pattern is an anti-broker where the conceptual "bus" is made of individual distributed components that talk to each other somehow. Message brokers inherently represent a single point of failure as opposed to an ESB where one component failing does not bring down the "bus" as a whole. Also my understanding is that Biztalk is monolithic in the sense that messaging, orchestrations are tightly coupled and scaling is problematic.

If the scenario at hand is:

  • Biztalk is already being used primarily for running different orchestrations based on different files received from outside parties.
  • A bunch of inhouse custom appications which are currently tightly coupled to system such as CRM and payroll need to be refactored to abstract out these dependencies.

Would it make sense to use Biztalk directly or Biztalk ESB toolkit for achieving ESB functionality or would it make sense to use a proper ESB implementation such as NServiceBus or Service Bus for Windows which is based on Azure Service Bus. What are the pros and cons of using Biztalk directly to achieve EAI vs. using a proper ESB. Would each application take a hard dependency on Biztalk and whether this is desirable?

I will leave this as an open ended discussion since there is no right or wrong answer.

@StuartLC: Thanks for your response. I've read several of the links you posted but still did not get a clear sense of whether Biztalk would make sense as an ESB solution vs. using something like NServiceBus. Both seem to implement the "ESB" pattern in one way or another. Question being which one has a cleaner implementation, better development experience and low ramp up time. My assessment so far(from pure research only) is that yes Biztalk can be used but it is painful and requires very specialized dev. skill sets. Latency and scaling being problematic and the fact that Biztalk will eventually be assimilated into the (Azure?) Service Bus and the Biztalk SKU will cease to exist. On the other hand, a framework like NService bus has relatively low ramp up time, can be easily picked up by a dev. having good .NET programming skills in general and can interface easily with Biztalk. Given the above, would it still make sense to go the Biztalk route even though you currently have Biztalk in house or to future proof yourself go with a proper ESB such as NService Bus ?

Abhijeet Patel
  • 5,904
  • 7
  • 46
  • 90
  • My two cents : I feel that going with a ESB solution like NServiceBus or MassTransit or Windows Service Bus would be a better option. Getting the devs upto speed with the nuances of BizTalk can be time consuming, at least from my experience. – HashName Jan 21 '13 at 19:51

1 Answers1

6

I believe many components of your open-ended question have already been covered on SO:

However, IMO it is just a flawed / short-sighted implementation which which would result in tight coupling between apps and endpoints. Loose coupling is easily achieved : (even without the ESB toolkit):

Single point-of-failure is also avoidable:

  • Configuring Retries and Alternative / backup transports on communication adapters
  • Redundancy achieved e.g. via Server Groups and Clustering
  • And fall back using compensation for failed delivery

IMO the Achilles heel when using BizTalk as an ESB is the lack of guaranteed latency e.g. here which is exarcebated if BTS gets into a throttling state.

Update

IMO the choice boils down to a matter of whether you have control over all systems in your environment.

If you are integrating an internal enterprise consisting only of homogeneous, contemporary (and mostly SOA and EDA) applications over which you have direct control, MassTransit or NServiceBus would likely more than do the job give and you better productivity and ramp up time.

Community
  • 1
  • 1
StuartLC
  • 96,413
  • 17
  • 181
  • 256
  • Thanks @Stuart. I've added comments to the original post. Was over by several characters for adding a comment :-) – Abhijeet Patel Dec 23 '12 at 19:31
  • I was actually going to give a positive feedback on your answer, but after reading this: "IMO the Achilles heel when using BizTalk as an ESB is the lack of guaranteed latency e.g. here which is exarcebated if BTS gets into a throttling state." and this NServiceBus in the same sentence, I actually had to do the opposite. – MeTitus Apr 16 '13 at 00:32