Back in 2004, when I heard this work for the first time, I was just nodding my head as if I was understanding the context. It was a design discussion going on where we were deciding on a SOA based framework to be architected, developed and deployed for one of my clients whom I was working with then.
Post the meeting, I gave a quick read of what is an ESB. Having exposure to EAI, I was quickly able to grasp the crux of what an ESB is. From then on, it has been a constant journey to explore and get exposed to ESB.
In IT layman term if you want me to define ESB? Let me try it out.
"From architecting a system / solution, scalability is one major factory that comes into play. The second one is what do I do to the legacy systems?
Answering short, messaging and asynchronous programming is the proven and practised way for Q1. And for Q2, the EI layer helped us to make heterogeneous systems talk. We were actually using a messaging layer constructed out of message queues to communicate.
Now putting both together, a specification was designed on how build a platform to integrate systems in an enterprise and make them talk with each other. This is ESB in crux".
This is in initial definition that I gave to myself when I read about ESB. But now I still believe it is the same. Over a period of time, when you start yourself to work with much complex and integrated systems, with different patterns, the above definition would help you to dissect and read between the lines and make your understanding much better.
Overall ESB is definitely not rocket science, it is just a platform to make heterogeneous systems talk together and a scalable platform for larger enterprises.
For taking a quick sneak of ESB, try MULE which is an open source ESB.
Jai Hind
No comments:
Post a Comment