Biztalk vs Azure Service Bus

Question

I am looking for a solution for real-time data integration between few on-premise databases. There is no much transformation of data involved. I am evaluating various ESBs available. I am thinking that data integration using Azure Service Bus as quick to develop a solution. Is it advisable to use Azure service bus for integration of all on-premise databases?

Answer 1

If you have all your applications 'on prem', you introduce an extra risk by moving your integration layer to the cloud (suddenly your internet connection could bring down your integration layer) but the good news is that you can use Service Bus for Windows Server, that you run locally (even with Windows Azure pack!) The same programming model, similar messaging features, so that might be a good option.

Comparing with BizTalk... Service Bus is light weight, messaging only. BizTalk provides much more rich features (transformations, pipelines, BAM, Business Rules, adapters).

Good luck

Answer 2

Unless there is extraordinary complexity in the integration, BizTalk is probably not the right tool for the job here. On the other hand, sending data out to the cloud just to transform it back to another database (on the same LAN?) is also not the right approach - this will introduce latency and traffic cost.

(Near) Real Time integration of databases sounds like a job for something like:

• SQL Server Integration Services (SSIS)
• If DB's are Sql-Server and the schemas are similar, Sql Server Replication
• And similar technologies exist for other RDMBS technologies , e.g. Oracle Streams

If you really want to build a service bus, either build a local AMQP based bus as Sam suggests (e.g. Windows Service Bus or Rabbit), or buy an existing product (NServiceBus etc).

Answer 3

If you are only looking to integrate between a few on premise databases then you might consider using Sql Server's Service Broker (http://msdn.microsoft.com/en-gb/library/bb522893.aspx).

It provides a reliable asynchronous way of passing data between databases in a real time way. It can manage the message order and can have numerous conversations running at the same time on the same queue, each being processed by its own instance of the receiver.

There's a good overview here... http://technet.microsoft.com/en-us/library/ms166104(v=sql.105).aspx