Enterprise Service Bus Middleware
An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.
The concept of the enterprise service bus is analogous to the bus concept found in computer hardware architecture combined with the modular and concurrent design of high-performance computer operating systems. The motivation for the development of the architecture was to find a standard, structured, and general purpose concept for describing implementation of loosely coupled software components (called services) that are expected to be independently deployed, running, heterogeneous, and disparate within a network. ESB is also a common implementation pattern for service-oriented architecture, including the intrinsically adopted network design of the World Wide Web.
No global standards exist for enterprise service bus concepts or implementations. Most providers of message-oriented middleware have adopted the enterprise service bus concept as de facto standard for a service-oriented architecture. The implementations of ESB use event-driven and standards-based message-oriented middleware in combination with message queues as technology frameworks. However, some software manufacturers relabel existing middleware and communication solutions as ESB without adopting the crucial aspect of a bus concept.
The ESB is implemented in software that operates between the business applications, and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB. To achieve this objective, the ESB must encapsulate the functionality offered by its component applications in a meaningful way. This typically occurs through the use of an enterprise message model. The message model defines a standard set of messages that the ESB transmits and receives. When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message model, the ESB has to transform the message into a format that the application can interpret. A software adapter fulfills the task of effecting these transformations, analogously to a physical adapter.
ESBs rely on accurately constructing the enterprise message model and properly designing the functionality offered by applications. If the message model does not completely encapsulate the application functionality, then other applications that desire that functionality may have to bypass the bus, and invoke the mismatched applications directly. Doing so violates the principles of the ESB model, and negates many of the advantages of using this architecture.
The beauty of the ESB lies in its platform-agnostic nature and the ability to integrate with anything at any condition. It is important that Application Lifecycle Management vendors truly apply all the ESB capabilities in their integration products while adopting SOA. Therefore, the challenges and opportunities for EAI vendors are to provide an integration solution that is low-cost, easily configurable, intuitive, user-friendly, and open to any tools customers choose.
Suppliers Enterprise Service Bus Middleware
Vendors Enterprise Service Bus Middleware
F.A.Q. about Enterprise Service Bus Middleware
What is an Enterprise Service Bus (ESB)?
An Enterprise Service Bus (ESB) is a type of software platform known as middleware, which works behind the scenes to aid application-to-application communication. Think of an ESB as a “bus” that picks up information from one system and delivers it to another.
The term ESB first appeared in 2002, but the technology continues to evolve, driven by the need for ever-emerging internet applications to communicate and interact with one another.
Why would I want an ESB?
Imagine that there are two systems in an organization that needs to exchange data. The technical teams that represent each system plan and implement a solution that allows these systems to communicate. A year or two later, the organization deploys several more systems that need to interact with each other as well as the existing two systems. How can all teams develop and reach an agreement on the best solution?
It becomes very complicated to manage and maintain one solution as an organization’s IT systems expand. With just 10 systems, there could be 100 different interfaces and scores of disparate technical requirements.
An ESB provides a secure, scalable and cost-effective infrastructure that enables real-time data exchange among many systems. Data from one system, known as a service provider, can be put on the enterprise service bus as a message, which is sent immediately to a service consumer of the data. If a new system wants to consume this same data, all it has to do is plug into the bus in the same manner.