none
What does BizTalk ESB really differentiate from BizTalk?

    Question

  • I am trying to get the idea how ESB is different from BizTalk itself.

    Seems ESB is more focusing on pipeline kind of stuff. Still use BizTalk orchestration, BRE to provide workflow/decision making kind of logic.

    Any case using ESB is more reasonable or convenient than BizTalk basic features?

    Thank you.


    Friday, June 22, 2018 3:30 PM

All replies

  • An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure.

    ESB products enable users to build this type of architecture, but vary in the way that they do it and the capabilities that they offer. The core concept of the ESB Architechure is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which becomes brittle and hard to manage over time. Point-to-point integration results in custom integration code being spread among applications with no central way to monitor or troubleshoot. This is often referred to as "spaghetti code" and does not scale because it creates tight dependencies between applications.

    BizTalk is a much more than just one integration pattern i.e. ESB it is a holistic framework to support many integration patterns and scenarios and it also supports ESB pattern natively through its ESB toolkit. We can use all the BizTalk artifacts and using ESB we can tie them together in the process.

    ESB Toolkit is most useful when you need itinerary based solutions i.e. where you need to perform many steps before doing the final one and you want flexibility to manage these steps. In an orchestration you need to define a pattern and redeploy the code but in ESB you can just manage the flow in a configuration.

    For e.g. If you are getting data from multiple sources we can divide our solution in few steps

    1. Receive and Load the messages
    2. Convert the messages to a common canonical format
    3. Canonical to third party format or database load
    4. Routing to various subscribers

    All these are separate processes and behaving independently and during each step we are using native BizTalk artifacts like Maps; orchestration. Having one big orchestration will be a fixed pattern and will be difficult to update however if a new source or a target is added; we only need to add new steps in the ESB itinerary.

    A good high level documentation on ESB toolkit is available here : https://docs.microsoft.com/en-us/biztalk/esb-toolkit/microsoft-biztalk-esb-toolkit

    Example : https://www.codeproject.com/Articles/288285/Hello-World-in-BizTalk-ESB-Itinerary-using-a-Purch

    https://www.biztalk-server-tutorial.com/2014/10/15/esb-toolkit-itineraries/


    Friday, June 22, 2018 4:53 PM
  • You are right..

    BizTalk has ootb routing capabillities. ESB is just a framework that uses that principle.I can do everything the ESB framewok does just ootb.....

    In my opinion the ESB framework adds just a lot of complexity that is not needed.


    Well0549, Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread

    Monday, October 1, 2018 10:41 AM
  • ESBT is built on top of BizTalk so anything ESBT can do, you can do in regular BizTalk, often easier and faster.

    Unless you have confirmed a specific case where ESBT can make your app easier to develop and maintain, you should not use it.  For clarity, I have never had such a situation.


    Wednesday, October 3, 2018 2:12 PM
  • Another point to consider is that you have another moving part to maintain, the itinerary definition itself. I have seen way too complex itinerary definitions that were a maintenance nightmare.

    Thanks Arindam

    Thursday, October 4, 2018 12:00 AM
    Moderator