When and why to use ESB/OSB technology?
I had this question in my mind from very first day, what is the real use of ESB architecture. I was able to get some tit-bit knowledge with help of some blogs. But the real quest for usage of ESB, when to use ESB and what are real significance of ESB was pondering in my mind from very long time.
Thanks to Ross Mason's blog , i was able to get some well defined answers for above questions. Thought of sharing with you in my blog.
ESB/OSB selection checklist:
-------------------------------
OSB or other ESBs offer real value scenarios where there are at least 2 or 3 applications are there to integrate.
They are also well suited for scenarios like loose coupling, scalability, and robustness are required.
Please consider below points before choosing ESB in your architecture.
1. Are you integrating 3 or more applications/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.
2. Do you really need to plug in more applications in the future? It’s better to keep things simple re-architect later if needed.
3. Are you in need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross-protocol messaging and transformation that ESB/OSB provides.
4. Do you need message routing capabilities such as routing and aggregating message flows, or content-based routing? Many applications do not need these capabilities.
5. Do you need to publish services for consumption by other applications? This is a good fit for ESB/OSB as it provides a robust and scalable service container.
6. Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down into smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.
7. Do you understand exactly what you want to achieve with your architecture? Vendors often draw an ESB as a box in the middle with lots of applications hanging off it. In reality, it does not work like that. There is a lot of details that need to be understood first around the integration points, protocols, data formats, IT infrastructure, security, etc. Starting small helps to keep the scope of the problem manageable and keep the complexity to a minimum. Until you understand your architecture and scope it properly, you can’t really make a decision as to whether an ESB is right for you.
If your architecture looks similar to image shown below, then using ESB in this case is waste of time.
on other hand, if your architecture resembles to image shown below, then an ESB would be probably good choice.
Note : I have borrowed above points from Ross's blog as it was much clear and plain explanations, din't thought of tampering the same.
For detailed explanation you can check below link.
https://blogs.mulesoft.com/dev/mule-dev/to-esb-or-not-to-esb/
Thanks,
Tapan
Thanks to Ross Mason's blog , i was able to get some well defined answers for above questions. Thought of sharing with you in my blog.
ESB/OSB selection checklist:
-------------------------------
OSB or other ESBs offer real value scenarios where there are at least 2 or 3 applications are there to integrate.
They are also well suited for scenarios like loose coupling, scalability, and robustness are required.
Please consider below points before choosing ESB in your architecture.
1. Are you integrating 3 or more applications/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.
2. Do you really need to plug in more applications in the future? It’s better to keep things simple re-architect later if needed.
3. Are you in need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross-protocol messaging and transformation that ESB/OSB provides.
4. Do you need message routing capabilities such as routing and aggregating message flows, or content-based routing? Many applications do not need these capabilities.
5. Do you need to publish services for consumption by other applications? This is a good fit for ESB/OSB as it provides a robust and scalable service container.
6. Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down into smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.
7. Do you understand exactly what you want to achieve with your architecture? Vendors often draw an ESB as a box in the middle with lots of applications hanging off it. In reality, it does not work like that. There is a lot of details that need to be understood first around the integration points, protocols, data formats, IT infrastructure, security, etc. Starting small helps to keep the scope of the problem manageable and keep the complexity to a minimum. Until you understand your architecture and scope it properly, you can’t really make a decision as to whether an ESB is right for you.
If your architecture looks similar to image shown below, then using ESB in this case is waste of time.
on other hand, if your architecture resembles to image shown below, then an ESB would be probably good choice.
Note : I have borrowed above points from Ross's blog as it was much clear and plain explanations, din't thought of tampering the same.
For detailed explanation you can check below link.
https://blogs.mulesoft.com/dev/mule-dev/to-esb-or-not-to-esb/
Thanks,
Tapan
Comments
Post a Comment