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

Answer 1

BizTalk can do both ESB and EAI, depends how you design your biztalk applications.

Answer 2

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.

Answer 3

Absolutely! Biztalk comes from an EIS background, which makes perfect sense for ESB as an infrastructure backplane for service-oriented architectures that span hybrid technical platforms.

At a previous company we chose Biztalk in preference to the IBM ESB product for reasons of functionality and lower cost.

It is Microsoft, so you get what you pay for, but still well worth looking into.

Answer 4

Biztalk Server withot "ESB Toolkit" Is not an ESB. Because of the following:

1. Is a contract first, need to build you message types first.
2. Need to Plan the whole scenario first to minimize the impact of changes.
3. Changes requires Deployment which increases downtime.

Regarding to your qustion, Yes BizTalk Server is EAI Product

Answer 5

I agree with most of what's said here. It's a stretch to pitch BizTalk as an all inclusive EBS solution even with the EBS toolkit.

To address a couple points made here ...

•BTS is more suited toward asynchronous processes than synchronous processes - latencies will vary depending on load on the system, throttling state, etc.

BizTalk hosts with unchanged defaults are not ideal for a low latency. But those hosts are meant to be tuned. Out of the box configuration is not suitable for any situation where throughput is needed. In my experiences of walking into an organization where BizTalk has been shunned there is always an untuned single host setup sitting in the middle of it. It is somewhat analogous to making tables in a dbms with no indexes, getting performance issues and saying the dbms itself sucks.

•BTS is cumbersome when it comes to ease of versioning of services and schemas (new deployment is needed)

Like with any development platform you need to have a deployment strategy. If schemas have version in the namespace you do not need to redeploy anything. A new version maybe deployed without taking anything down.

As far as the service endpoints are concerned BizTalk can host web services without the use of IIS (BizTalk can use HTTP.SYS to host just as IIS does). To host an inprocess service in BizTalk is merely a matter of importing a binding which can be done without stopping anything in BizTalk. In those end points you can implement versioning as well (like http:.../thing/v1, http:.../thing/v2, etc.).

Anyway ~5 years have passed I'm sure you have hit a conclusion before now :)

Answer 6

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.