Is BizTalk an ESB?

Question

I am looking into architectural patterns, Enterprise Services Bus (ESB) precisely. Upon reading this article Enterprise Integration, and with little to no experience I am wondering if BizTalk has is a ESB or is it just a EAI (Hub/Spokes or Bus)?

I found this NServiceBus and Biztalk, describing BizTalk as a central message broker.

Taking other ESB frameworks into account (NServiceBus and Rhino Service Bus). These frameworks have no central point to process messages.

Is Biztalk a EAI rather than an ESB?

Many thanks

Solution 1

BizTalk is punted by Microsoft as having ESB capabilities - see the BTS ESB toolkit

However, the term 'ESB' covers a very broad field, and there is a lot of subjectivity about an exact definition of an ESB. IMHO there are weak points in BizTalk's claim to be comprehensive as an ESB (in a > 2010 definition of the term).

• BTS originated in the Hub-and-Spoke EAI era, before ESB became widespread.
• BTS is more suited toward asynchronous processes than synchronous processes - latencies will vary depending on load on the system, throttling state, etc.
• BTS is cumbersome when it comes to ease of versioning of services and schemas (new deployment is needed)
• BTS is cumbersome when it comes to management of MANY services (e.g. Using BizTalk as a facade for all 5000 of your corporate SOA / Web Services will be painful)

FWIW we have found BTS a good fit for:

• all of our synchronous and asynchronous EAI (i.e. formalized integration contracts between major LOB systems, and with trading partners), and the large number of adapters assists with integrating a wide number of protocols.
• For Business Process and Business Monitoring capabilities
• Addressing transactional and delivery reliablity - Biztalk has capability to retry, tracking and resumption of Suspended messages, which is useful over unreliable networks or when it comes to integration with unreliable systems.

Update, with some further comparative experiences

• BTS is very centralised - ultimately, even a multi-server BizTalk cluster / group is dependent on Sql-Server. Queue based ESB products tend to be more decentralised (logically and physically), so loss of a few endpoint or queue servers should not pull the whole enterprise down.
• Many queue based ESB's are built on open source technologies, with an eye on avoiding single vendor lock-in
• Many contemporary ESB's seem to take a commodity-computing approach to scale out. Scaling out with products like BizTalk can become expensive.
• On the plus side, the monitoring and administration capabilities of commercial offerings like BTS should not be underestimated - make sure any ESB you are considering has adequate auditing, instrumenting, retry, and diagnostic (WMI / SNMP / SCOM etc) capabilities - you'll need a dashboard to monitor the health of your bus, and there is nothing worse than not knowing where a message went. Here, centralisation administration and diagnosis is a plus.

Solution 2

BizTalk is a messaging and workflow orchestration platform, on which you can build ESB behaviours and capabilities. To make this easier, and standardise ESB implementation on BizTalk, Microsoft released the BizTalk ESB Toolkit - a set of guidelines, patterns and code.

The concepts of EAI and BPM have been around for a while, so there are many companies that have leveraged BizTalk to create solutions to these problems. Companies that host a full ESB on BizTalk server are far fewer, and adoption has certainly slowed in the advent of WCF/WF/NServiceBus and, of course, Azure Service Bus.

So in summary, BizTalk out of the box is nether EAI or ESB, but can do both with a number of developers applied to the problem.

Solution 3

By "EAI or ESB" I'm assuming you wanted to know if BizTalk follows the Hub&Spoke or the Bus architecture.

From an architecture patterns perspective, integration solutions roughly fall under one of the two patterns-

• The Hub and spoke: This involves a centralized message broker sending out messages to various receivers, while all the senders send their messages only to this broker. Thus neither the senders nor the receivers need to be aware of each other. This is typically what many people refer to as EAI (although it is absolutely possible to implement an EAI solution that follows the BUS pattern). Solutions following this pattern are easy to develop and administer. All the routing logic is centrally managed at one place - in the hub. But as you would have guessed, this has a glaring drawback - single point of failure. If the hub crashes everything comes to a halt. Also, this model doesn't scale very well.

• BUS: Enterprise Integration solutions developed around this pattern are generally referred to as ESB. There is no intelligent central authority here. All senders publish their messages on the bus. The receivers need to be intelligent enough to determine which messages are intended for them and take them off the bus. Thus the senders and the receivers need only be aware of the bus. But here the routing logic is spread across the receivers so there is no single point of failure. Also this model is highly scalable. However such solutions are quite complex and difficult to administer.

Coming to the question which pattern does BizTalk follow- it is a hybrid of both these patterns.

the Hub-like appearance is very obvious with its centralized Messaging Engine, and a central MessageBox database. This gives one the simplicity and ease of administration which is typical of the hub approach.

But if you look at the BizTalk architecture, one can have a Host with its Host Instances spread across multiple servers. It is also possible to have the different BizTalk databases like MessageBox, Tracking, Ent SSO etc. configured on different servers. This makes BizTalk solutions more scalable and tolerant to faults than the run-of-the-mill hub implementations - which is a behavior usually attributed to the bus approach.

Hope this answers your question.

Solution 4

BizTalk is more than an ESB but certainly fits the bill. This link is a little old, but answers your exact question.

EDIT: Here is a more-recent MS link that gets into specifics of implementation.

Solution 5

BizTalk is certainly an ESB. EAI is more of a loose concept - BizTalk can certainly be deployed to support EAI, and it can also do a lot more.

View more solutions

Comments

[amphibient]

what is your opinion about Mule ?

[Motivated]

I don't quite follow what you mean by The receivers need to be intelligent enough to determine which messages are intended for them and take them off the bus. Thus the senders and the receivers need only be aware of the bus. But here the routing logic is spread across the receivers so there is no single point of failure. Are you able to elaborate further?

[Parag Patil]

Imagine there are two subscribers- A subscribing to messages of type Foo and B subscribing to messages of type Bar. And a publisher publishes 3 messages of type Foo and 2 messages of type Bar on the Bus. Now A and B should have the logic to figure out which out of these 5 messages are meant for them, and they have to pick these messages off the Bus themselves. The Bus will not have that logic.

[Motivated]

So how does work with orchestration, business rules, etc?

[Parag Patil]

@Motivated Didn't quite understand your question. Can you elaborate? Also, by 'orchestration' did you mean the Orchestration - the concept or the orchestrations in BizTalk?

[Motivated]

If i understood you correctly, bus driven architectures work off the principle that there are no dumb pipes i.e. the subscribers in this instance have the capability to process the appropriate messages. If so, how does this work with orchestration i.e. workflows, secondary targets, as well as business rules? Do A and B have execute their own workflows and business rules as well as co-ordinate secondary targets i.e. once A has finished processing it hands over to B and vice versa until the transaction has completed. How does this also work with replaying transactions?