Archive

Archive for the ‘Enterprise Service Bus’ Category

Evolution of Open-Source Enterprise Service Bus (ESB)

December 31, 2009 2 comments

 

Evolution of open-source Enterprise Service Bus (ESB):

 

Developers involved in complex system integration will know how intriguing system integration can get to. Integration of disparate enterprise applications is always challenging because of the need to get them work together. It also has become an increasingly essential element of IT, where we oftenly come across terms such as BI (Business Integration), B2B (Business to Business) etc. A decade earlier, technology choices were limited. Integration of enterprise applications had to chose either an application server or a heavyweight enterprise application integration (EAI) solution that required a huge upfront investment in infrastructure, money, and human resources. There was a need for a lightweight solution which is easy to deploy and manage. Many enterprises at that time, built thier own abstractions on top of thier messaging servers. By doing so, it was an extreme undertaking and a huge burden on the developers.

Since IBM first released MQSeries, enterprises have been sold on the benefits of decoupling systems using point-to-point message queues. When TIBCO brought Rendezvous to the market, it expanded the horizons of messaging by introducing the publish-subscribe model. The Java Message Service (JMS)—born through Sun’s Java Community Process (JCP)—set out to unify the point-to-point and publish-subscribe messaging models. It wasn’t long before enterprises required more than just messaging, they also needed a way to orchestrate messages between systems and perform transformations.

To address this need, major vendors such as IBM, Oracle, and Microsoft built EAI brokers that added message brokering and centralized transformation engines on top of their existing messaging servers. The problem with the EAI approach was that it adopted a hub-and-spoke architecture where all data had to flow through the EAI broker. Although this worked for many applications, enterprises were soon pushing the boundaries of these systems and it became clear that something more flexible, scalable, and distributed was required. Enterprises needed connectivity, transaction management, security, and message routing, and they needed to host services that operated on data moving around their systems.

Working on integration projects used to mean working with enterprise application integration (EAI) products, each of which implemented its own stack of tools with proprietary technology. To switch from one EAI product to another meant learning the proprietary technology and toolset from that new product. With more focus on open standards that emerged in the integration market, the market changed from EAI to service oriented architecture (SOA) and enterprise service bus (ESB) products. Examples of these open standards are Java Message Service (JMS), SOAP, XML, and WS*. With open standards available, more and more open source projects began to implement these specifications.  There was a need for an open source solution built on open standards.

The next step of this evolution led to what is now known as an ESB: Data and exchanges are conveyed from system to system in a single logical bus, decoupling all the systems from each other. This leads to a much more maintainable system and can save a lot of time in the long term. Integration technologies are becoming commodity software, and the rise of open source integration frameworks is hence becoming increasingly important. Open source is now unavoidable, from JMS brokers to SOAP stacks to ESBs. Companies generally use ESBs to convey sensitive data, and they sometimes need advice when they’re developing the applications hosted in the ESBs or when they’re putting these applications in production. The industry needed the ESB. 

Read more…