Enterprise Service Bus

With Enterprise Service Bus (ESB ) is called support of information technology (IT) is a category of software products that enable the integration of distributed services (English service ) in the application landscape of a company (English enterprise) to be defined in more detail below way.

Sometimes you designated Enterprise Service Bus also

• The infrastructure that builds a particular company for the integration of services in its application landscape.
• An architectural style of integration, preferring to communicate through a shared communication bus a variety of point-to -point connections between providers and users of software services.

• 2.1 Integration in an application landscape
• 2.2 Bus and endpoints
• 2.3 adapter
• 2.4 Integration services and capabilities
• 2.5 Protocol and API -driven ESBs

Term

Literally translated, is an Enterprise Service Bus to " to provide services via a data bus in a corporate network available ". In the German -speaking world, however, no translation has prevailed. Enterprise Service Bus is widely accepted as a concept of the German jargon today. Although the name suggests otherwise, the principle also outside the application environment of a company (English enterprise) is valid.

The term Enterprise Service Bus was coined in 2002 by Gartner. The analyst Roy W. Schulte introduced him to describe a category of software products that were available on the market after his observation in 2002. Other sources point out that the term was coined in 2002 by the company Sonic for one of their software products and then taken over by analysts.

Through the book by David A. Chappell with the same title ( published in 2004 ), he became known to a wider audience.

Meanings

The Gartner report from 2002 uses the term in the sense of category of software products. Both producers of freely available software as well as commercial vendors refer to their products as an Enterprise Service Bus.

Monographs and comments on the topic of Enterprise Service Bus use the term in the sense of an architectural concept. Software manufacturers follow in some cases this interpretation, especially if they point to the possibility of being able to realize the concept of an Enterprise Service Bus with a range of their products.

Other sources use the term in the sense of physical infrastructure, building a company for application integration. So the financial institution Credit Suisse decreed 2005 on three instances of an Enterprise Service Bus: the CS integration bus for synchronous communication, the Event Bus Infrastructure for asynchronous communication and the integration of Bulk Infrastructure for the transfer of mass data. Also David A. Chappell points out in his book suggests that a given infrastructure may be referred to as an Enterprise Service Bus.

Design and Concepts

Integration in an application landscape

The application landscape of an organization supports their business processes with information technology. If it is designed in the style of service-oriented architecture, it can be divided into so-called services (English services). A service includes a professional and / or technically belong together subset of the functionality that IT supports the business processes.

Service providers offer their functionality through service interfaces (English service interfaces) so that they can be addressed by service users in the application landscape. Depending on the company and specific design of an application landscape come as a service user, among other services, other types of elements of an application landscape in question, for example, domains, applications or components.

If a service user the functionality of a service provider, the two elements are interdependent. This results in a logical connection, which is to be physically implemented. The totality of the physical couplings is the integration architecture of an application landscape.

Bus and endpoints

By bus is referred to in the data and electrical engineering, a subsystem that transfers data or power between parts of the system. The concept of the enterprise service bus transfers this approach to the field of enterprise-wide IT architecture. It replaces the complicated network of direct physical couplings in an application landscape through a communications infrastructure that is shared by all service providers and service users.

An Enterprise Service Bus is in the core of a communication over the news (English messages) can be exchanged. Services connect their service interfaces on endpoints (English endpoints ) by bus. Service users now communicate with a service provider, by exchanging with the service provider via the bus messages.

Adapter

The technical characteristics of service providers and service users differ significantly in heterogeneous application landscapes. Neither the software platforms used, nor the supported communication protocols, data formats and data structures are directly compatible in general. If the integration architecture of an application landscape dominated by point-to -point connections, the corresponding differences are bridged bilaterally. This results complicated network of physical linkages, because tends to each logical link is supported by its own physical connection.

An integration architecture that uses an integration platform as a middleware that makes sure that both service providers, such as service users are connected to the middleware if needed with the bridging elements, which are referred to as an adapter. Adapter as part of the physical coupling between service providers and service users the possibility to be reused for multiple logical couplings. There are less necessary to exactly one logical coupling aligned physical couplings.

The concept of the Enterprise Service Bus follows this approach. It differs in this respect from the other, some older concepts of application integration.

Integration services and capabilities

Functions that support the integration of distributed services are encapsulated in an ESB in so-called integration services ( engl. integration service). The concept of the enterprise service bus assumes that integration services can be distributed similar to business services in the application landscape. It requires no central node that provides all integration services and must go through the news, use these services. This is one of the features that distinguish the concept of the Enterprise Service Bus earlier concepts such as application integration.

The two main integration services are the transformation and routing services:

For further integration services it is debatable whether they are also among the standard services of an ESB:

Protocol and API -driven ESBs

A protocol- driven ESB (protocol driven ESB) defines a protocol that providers and users have to perform in order to access services can. The ESB provides here no tools and libraries available, but the Force protocol changes with each provider and user make appropriate adjustments. Web services (or SOAP) use this approach.

An API - driven ESB (API driven ESB) provides providers and users, platform-specific interfaces (eg Java interfaces ) available to implement services and invoke it.

Applicability and benefits

The concept of the enterprise service bus is applicable when it is necessary to integrate a sufficiently large number of independent services for an overarching purpose. Despite the name component Enterprise (English for companies) the concept of an Enterprise Service Bus can be equally useful in a narrower context, for example within a certain technical domain, within a department or in the context of a project that will be integrated into the isolated services to achieve a specific project goal. It is recommended not to understand an enterprise service bus as an IT infrastructure that provides an IT department in analogy to the cabling in office buildings regardless of specific business needs. Very promising is, rather, with the help of an Enterprise Service Bus to resolve specific local problems and building on cross -border integration solutions in the sense of an Enterprise Service Bus to build.

The concept of the enterprise service bus is independent of the industry applicable to all organizations that are supported to a large extent by IT. These are the financial and insurance industry, the telecommunications industry, retail trade, industry and public administration.

An Enterprise Service Bus alone generated so far no financial benefit, as he always is only a means and not an end in highly motivated IT solutions. Indirectly, the use of an Enterprise Service Bus generate business value, because it can help to make the application landscape of a company more cost efficient and more agile:

• An ESB can allow isolated services can be integrated quickly and cost effectively.
• Integration solutions based on an ESB can usually be adapted to changing requirements quickly and cost effectively.

The IT Architect provides the concept of an Enterprise Service Bus the following additional advantages:

• Integration tasks can be implemented outside the different integration services. This separation of business logic from integration logic helps to reduce the complexity and thus contribute to their mastery.
• The concept is based on a modular, distributed structure of the ESB and can therefore be used effectively in a wide range of solutions in different configurations.
• In the market available ESB products bring prefabricated blocks with ( routing services, transformation services, etc.) that can be reused in a solution with little additional effort.

Definition and classification

Enterprise Application Integration ( EAI) is a discipline of information technology deals with the design of physical couplings between elements of an application landscape. The concept of the enterprise service bus is not a replacement for EAI, but on the one hand a possible architecture style for the design of integration architecture and on the other hand, a possible means to realize physical couplings in the context of EAI concrete.

Service - oriented architecture ( SOA) is an architectural style for the design of application landscapes. The integration of distributed services is of particular importance and integration architecture of this application landscapes benefits from the use of integration middleware. Integration tasks in a designed according to SOA principles application landscape can generally be solved but also without integration middleware or with the well-known since the 1990s, application integration tools. ESB is in this sense not a prerequisite for SOA, but at most timely support. Particular, there is no compelling reason to support integration tasks in a SOA with a tool that is offered on the market as ESB.

Message Oriented Middleware ( MOM) refers to a class of software products, which is used as communication infrastructure in application landscapes. MOM products are secure, robust and scalable transmission of messages between distributed services. An instance of a MOM, the foundation of an enterprise service bus form.

Criticism

Already Schulte pointed out that Enterprise Service Bus does not constitute a new concept. The purpose of an Enterprise Service Bus is very similar to the purpose of the widespread since the 90s of the 20th century, integration brokers. In the same context it is criticized that it Enterprise Service Bus handle yourself with the concept to a slightly catchy and influenced by fashion trends in information technology marketing term that has remained too vague to be able to use it in the solution description for concrete problems of the IT architecture can.

The concept of the enterprise service bus is also suitable as a product category in the software industry. He had outlined to little sharp to describe a homogeneous group of software products.

The way how companies ESBs introduce into their application environments, also met with criticism. The names of components and enterprise service would be taken literally, so companies were in danger of introducing oversized and generic infrastructure for which there was insufficient business needs at the time of realization.

IT departments have partially assumed that the procurement and installation of an Enterprise Service Bus (in the sense of a software product ) is an essential requirement and the critical success factor for the solution to their integration problems. Critics note that the design and operation of a cost-efficient, accurate and flexible integration architecture is a conceptual and controlling task in the first place. The selection and use of a particular tool is rather trivial in comparison.

Physical coupling between services or applications can be divided into three groups: physical couplings of the presentation integration at the level of user interface, physical couplings of logic integration at the level of the business functions of an application and physical couplings of the data integration at the level of direct access to persistent data. In sufficiently complex application landscapes there are physical couplings at all three levels, while the concept of the Enterprise Service Bus is mainly focused on the level of logic integration. Neither the concept nor as related software products support presentation integration as it occurs for example in portals and rich clients. ESBs also represent a solution pattern to prevent direct physical couplings at the data level, not to allow. For justified in individual cases physical couplings at the level of data integration, an ESB provides therefore no support. In summary, we can state that the concept of the Enterprise Service Bus and the derived products are oriented only to a subset of the integration tasks in a sufficiently complex application landscapes.

Implementations

The following table lists the software products that are offered on the market as enterprise service bus.