ESB(Enterprise service bus)

Enterprise service bus

From Wikipedia, the free encyclopedia

In computing, an enterprise service bus (ESB) refers to a software architecture construct typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards, which provide fundamental services for complex architectures via an event-driven and standards-based messaging engine (the bus).

An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

An ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. Although it is a common belief, an ESB is not necessarily web-services based^{[citation needed]}. An ESB should be standards-based and flexible, supporting many transport mediums. Based on EAI rather than SOA patterns, it tries to remove the coupling between the service called and the transport medium.

Most ESB providers now build ESBs to incorporate SOA principles and increase their sales.

[edit] What is an Enterprise Service Bus?

There is some disagreement on whether an enterprise service bus is an architectural style, a software product, or a group of software products. While use of an ESB certainly implies adherence to a particular architecture, the term "enterprise service bus" is almost always used to denote the software infrastructure that enables such an architecture.

An Enterprise Service Bus (ESB) brings flow-related concepts such as transformation and routing to a Service-Oriented Architecture. An ESB can also provide an abstraction for endpoints. This promotes flexibility in the transport layer and enables loose coupling and easy connection between services.

[edit] ESB Architecture

The word "bus" is a reference to the physical bus that carries bits between devices in a computer. The enterprise service bus serves an analogous function at a higher level of abstraction. In an enterprise architecture making use of an ESB, an application will communicate via the bus, which acts as a message broker between applications. The primary advantage of such an approach is that it reduces the number of point-to-point connections required to allow applications to communicate. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.

[edit] ESB as Software

In such a complex architecture, the ESB is the piece of software that lies 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 bus. In order to achieve this objective, the bus must encapsulate the functionality offered by its component applications in a meaningful way. This is typically accomplished through the use of an enterprise message model. The message model defines a standard set of messages that the ESB will both transmit and receive. When the ESB receives a message, it routes the message to the appropriate application. Often, because the application was not built with the message model in mind, the ESB will have to transform the message into a legacy format that is understandable by the application. The software responsible for effecting these transformations is referred to as an adapter (analogous to a physical adapter). It is not widely agreed whether these adapters should be considered part of the ESB or not.

The connection between the enterprise message model and the functionality offered by the applications is crucial. If the message model does not completely encapsulate the applications' functionality, then other applications that desire that functionality will be forced to bypass the bus and invoke the applications directly. Doing so violates all of the principles outlined above, and negates many of the advantages of using an ESB.