Enterprise Service Bus

from Wikipedia, the free encyclopedia

With Enterprise Service Bus ( ESB ) is referred to in the information technology (IT) network architecture, the integration of distributed services ( English service ) (Engl. In the application landscape of a company enterprise supported).

Sometimes the term Enterprise Service Bus is also used

  • the infrastructure that a specific company builds to integrate the services in its application landscape.
  • an architectural style of integration that prefers communication over a shared communication bus to a variety of point-to-point connections between providers and users of software services.
  • Software products that implement the concept of the ESB.

term

An enterprise service bus is used to "provide services by means of a data bus in a company network". In the German-speaking area, however, no translation has prevailed. Enterprise Service Bus is now generally accepted as a term in German technical language. Even if the name suggests otherwise, the principle is also valid outside the application landscape of a company (English enterprise ).

The term Enterprise Service Bus was coined in 2002 by Gartner . The analyst Roy W. Schulte introduced it to describe a category of software products that, according to his observation, were available on the market from 2002 onwards. Other sources point out that the term was coined in 2002 by Sonic for one of their software products and then adopted by analysts.

He became known to a wider professional audience through the book by David A. Chappell of the same name (published in 2004).

Meanings

The 2002 Gartner report uses the term to refer to a category of software products. Both producers of freely available software and commercial providers refer to their products as the Enterprise Service Bus .

Monographs and comments on the subject of Enterprise Service Bus also use the term in the sense of an architectural concept. In some cases, software manufacturers follow this interpretation, especially when they point out the possibility of realizing the concept of an Enterprise Service Bus with a range of their products.

Other sources use the term in the sense of the specific infrastructure that a company builds for application integration. In 2005 , the Credit Suisse financial institution had three instances of an Enterprise Service Bus : the CS Integration Bus for synchronous communication, the Event Bus Infrastructure for asynchronous communication and the Bulk Integration Infrastructure for the transmission of mass data. David A. Chappell also points out in his book that the specific infrastructure can be described as an Enterprise Service Bus .

Structure and concepts

Integration in an application landscape

The application landscape of an organization supports its business processes with information technology . Is it in the style of architecture service-oriented designed, they can be used in so-called services (Engl. Services ) be broken. A service comprises a functionally and / or technically related subset of the functionality with which IT supports business processes.

Service providers offer their functionality via service interfaces in such a way that they can be addressed by service users in the application landscape. Depending on the company and the specific design of an application landscape, other types of elements of an application landscape, for example domains , applications or components, are possible service users in addition to other services .

If a service user uses the functionality of a service provider, the two elements become dependent on one another. A logical coupling is created that must be physically implemented. The totality of the physical connections forms the integration architecture of an application landscape.

Schematic structure of an ESB according to Chappell
Use case diagram of an ESB (Angeli, 2009)

Bus and endpoints

In data and electrical engineering, a bus is a subsystem that transfers data or energy between parts of the system using a standardized format. The concept of the Enterprise Service Bus transfers this approach to the area of ​​company-wide IT architecture. It replaces the complex network of direct physical connections in an application landscape with a communication infrastructure that is shared by all service providers and service users.

An enterprise service bus is the core of a communication bus, via the News (English. Messages ) can be exchanged. Services connect their service interfaces to the bus via endpoints . Service users now communicate with a service provider by exchanging messages with the service provider via the bus.

adapter

The technical characteristics of service providers and service users differ considerably in heterogeneous application landscapes. Neither the software platforms used, nor the communication protocols, data formats and data structures supported are generally directly compatible. If the integration architecture of an application landscape is mainly characterized by point-to-point connections, the corresponding differences are bridged bilaterally. Complicated networks of physical links arise because each logical link tends to be supported by its own physical link.

An integration architecture that uses an integration platform as middleware ensures that both service providers and service users are connected to the middleware, if necessary with bridging elements called adapters . As part of the physical coupling between service providers and service users, adapters can be reused for several logical connections. There are fewer physical couplings that are aimed at precisely one logical coupling.

The concept of the Enterprise Service Bus follows this approach. In this respect it does not differ from other, partly older concepts of application integration .

Integration services are also distributed in an enterprise service bus and connected to the central message bus (based on Chappell)

Integration services and skills

Functions that support the integration of distributed services that are in an ESB in so-called integration services (Engl. Integration service ) encapsulated. The concept of the Enterprise Service Bus is based on the fact that integration services can be distributed in the application landscape in a similar way to business services. It does not require a central node that offers all integration services and must run over the messages that use these services. This is one of the features that differentiate the concept of the Enterprise Service Bus from previous concepts of application integration.

The two most important integration services are the transformation and routing services:

Transformation services
A transformation service transforms data from one format and model to another format and model. It bridges differences in data formats and data models between service providers and service users.
Routing services
A routing service receives a message via the ESB and forwards it to the correct recipient according to predefined rules. Routing services can support different routing approaches. For example, you can make routing decisions based on a predefined sequence of recipients that a message should reach. This concept is known as itinerary-based routing . You can also make routing decisions based on the content of a message. This concept is known as content-based routing ( CBR ).

For other integration services, it is controversial whether they also belong to the standard services of an ESB:

Orchestration services
An orchestration service can control the flow of messages between service users and service providers based on predefined process models.

Protocol- and API-driven ESBs

A protocol-driven ESB (protocol driven ESB) defines a protocol that providers and users have to comply with in order to be able to call up services. The ESB does not provide any tools or libraries here, but protocol changes force each provider and user to adapt accordingly. Web services (or SOAP) use this approach.

An API-driven ESB (API driven ESB) provides providers and users with platform-specific interfaces (e.g. Java interfaces) in order to implement and call up services.

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 part of the name Enterprise , the concept of an Enterprise Service Bus can also be used meaningfully in a narrower context, for example within a certain technical domain, within a department or in the context of a project in which isolated services are integrated to achieve a specific project goal. It is recommended that an Enterprise Service Bus not be understood as an IT infrastructure that an IT department provides in analogy to cabling in office buildings, regardless of specific business needs. Rather, it is very promising to solve specific, local problems with the help of an Enterprise Service Bus and to build on this to build comprehensive integration solutions in the sense of an Enterprise Service Bus .

The concept of the Enterprise Service Bus can be used regardless of the industry in all organizations that are supported to a high degree by IT. The finance and insurance sector, the telecommunications sector, retail trade, industry and public administration deserve special mention.

An enterprise service bus alone does not generate any business benefit insofar as it is only a means and not an end in technically motivated IT solutions . The use of an Enterprise Service Bus can indirectly generate business benefits because it can help make a company's application landscape more cost-efficient and agile :

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

The concept of an Enterprise Service Bus also offers the IT architect the following advantages:

  • Integration tasks can be implemented outside of the services to be integrated. This separation of the business logic from the integration logic contributes to the reduction of the complexity and thus to its mastery.
  • The concept is based on a modular, distributed structure of the ESB and can therefore be used meaningfully in different configurations in a wide range of solutions.
  • ESB products available on the market include prefabricated modules (routing services, transformation services, etc.) that can be reused in a solution with little additional effort.

Delimitation and classification

Enterprise Application Integration (EAI) is an information technology disciplinethat deals with the design of physical couplings between elements of an application landscape. The concept of the Enterprise Service Bus is not a substitute for EAI, but on the one hand a possible architectural style for the design of integration architecture and on the other hand a possible means of realizing physical connections within the framework of EAI.

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

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

criticism

Schulte already pointed out that the Enterprise Service Bus is not a new concept. The purpose of an enterprise service bus is very similar to the purpose of the integration brokers that have been widespread since the 1990s . In the same context, it is criticized that the term Enterprise Service Bus is an easily memorable marketing term, influenced by fashion trends in information technology, which has remained too vague to be used in the description of solutions for specific problems in IT architecture.

The concept of the Enterprise Service Bus is also unsuitable as a product category in the software industry. It is not sharply defined to describe a homogeneous group of software products.

The way companies introduce ESBs into their application landscapes has also met with criticism. The name components Enterprise and Service are taken literally, so that companies run the risk of introducing oversized and overly generic infrastructure for which there are insufficient business needs at the time of implementation.

IT departments sometimes assume that the procurement and installation of an enterprise service bus (in the sense of a software product) is an essential prerequisite and the critical success factor for solving their integration problems. Critical voices note that the design and operation of a cost-efficient, correct and flexible integration architecture is primarily a conceptual and controlling task. In comparison, the selection and use of a certain tool is rather secondary.

Physical couplings between services or applications can be divided into three groups: physical couplings of presentation integration on the level of user interfaces, physical couplings of logic integration on the level of the business functions of an application and physical couplings of data integration on the level of direct access to persistent data. In sufficiently complex application landscapes, there are physical couplings on all three levels, while the concept of the Enterprise Service Bus is mainly geared towards the level of logic integration. Neither the concept nor the software products based on it support presentation integration, as occurs, for example, in portals and rich clients . ESBs also represent a solution patterns to direct physical coupling to at the data level prevent not to allow . An ESB therefore does not offer any support for physical couplings at the data integration level that are justified in individual cases. In summary, it can be said that the concept of the Enterprise Service Bus and the products based on it are only aimed at a subset of the integration tasks in sufficiently complex application landscapes.

Implementations

The following table lists software products that are offered on the market as Enterprise Service Bus .

Surname providers short description Art
Apache service mix Apache Software Foundation Implementation of the Java Business Integration (JBI) specification of the Apache Software Foundation with many JBI components. free
Apache synapse Apache Software Foundation ESB with a focus on web service support (based on Apache Axis2 ). free
Apache Tuscany Apache Software Foundation Implementation of the SCA specification free
Biztalk Server Microsoft commercially
ChainBuilder ESB Chain Builder ESB Integration Community JBI based ESB with graphic tools to simplify the development effort. free
CrossLoom EESB UMa Soft GmbH In addition to the normal ESB functionalities, there is an application designer , a cross-system workflow engine and browser-based offline forms commercially
E2EBridge Scheer E2E AG Model-based integration (BPMN, UML), large number of adapters commercially
Fiorano ESB Fiorano software commercially
FUSE ESB FUSE open source community based on Apache ServiceMix [1] free
JBoss ESB JBoss ESB based on JBoss messaging support free
Mule ESB MuleSoft free
NServiceBus Particular software Framework for application development under Microsoft .NET , available as open source and under a commercial license. free
OpenESB Sun Microsystems / OpenESB Community Implementation of the Java Business Integration (JBI) specification with good support of the NetBeans IDE free
OpenAdapter OpenAdapter EAI- based approach that provides a variety of adapters for integration solutions. free
Oracle ESB Oracle commercially
Orchestra soffico Consists of designer, monitor, runtime commercially
Petals ESB OW2 Consortium JBI based ESB hosted by OW2 (formerly ObjectWeb). free
Progress Artix ESB Progress software commercially
Progress Sonic ESB Progress software commercially
SAP NetWeaver Process Integration SAP commercially
Seeburg Business Integration Server Seeburger commercially
Service bus Microsoft Enterprise Service Bus for Azure and Microsoft Windows Server (from Windows Server 2008 R2 SP1 ) commercially
SoftProject X4 ESB SoftProject X4 ESB connects IT systems and provides services for a service-oriented architecture (SOA) commercially
Spring integration Spring Source Integration framework based on Spring free
StoneOne EIB StoneOne The EIB is an extended enterprise service bus with a number of additional services for orchestration commercially
Sun Java Composite Application Platform Suite (Java CAPS) Sun Microsystems commercially
Talend ESB Talend Germany free
Transconnect SQL Project AG universal integration server, modeling instead of programming commercially
AMX TIBCO commercially
webMethods ESB platform Software AG commercially
Integration bus IBM commercially
WebSphere IBM commercially
WSO2 Enterprise Service Bus WSO2 based on Apache Synapse free

literature

Individual evidence

  1. ↑ Hiekel 2007 , p. 11
  2. ↑ a b Schulte 2002
  3. ↑ a b c Microsoft 2005
  4. ↑ Chappell 2004
  5. ↑ Apache ServiceMix
  6. ↑ Mule ( Memento of the original from February 21, 2009 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / www.mulesource.org
  7. ^ Sun Enterprise Service Bus (ESB) Suite
  8. ↑ WebSphere Enterprise Service Bus
  9. ↑ Chappell 2004 , pp. 101 ff
  10. ↑ Chappell 2005 : “Myth # 4: Pattern or Product: The term 'Enterprise Service Bus' (ESB) is not really a product category; it is simply an abstract concept that can be applied toward a coupling of an existing application server and integration middleware. "
  11. ^ Wilkes 2005
  12. ↑ Chappell 2005 : "An ESB is an infrastructure for building an enterprise SOA, ..."
  13. ↑ Krafzig et al 2005
  14. ↑ Chappell 2004 , p. 116: "In some sense, the container is the ESB - more so than the underlying middleware that connects the containers together."
  15. ↑ Engels et al 2008 , p. 202
  16. ↑ Engels et al 2008 , p. 207
  17. ↑ Chappell 2004 , p. 105
  18. ↑ Chappell 2004 , p. 110
  19. ↑ a b c Chappell 2004 , p. 109
  20. ↑ Chappell 2005 : “An ESB provides the same base functionality as an EAI broker - connectivity, application adapters, routing of messages based on rules, and data transformation engine - yet, in an ESB, these capabilities are themselves SOA based in that they are spread out across the bus in a highly distributed fashion and hosted in separately deployable service containers. "
  21. ↑ a b c Percival 2006
  22. ↑ Chappell 2004 , p. 127
  23. ↑ Chappell 2004 , p. 129
  24. ↑ Chappell 2004 , p. 140
  25. ↑ Josuttis 2008 , p. 71ff
  26. ↑ a b Woolf 2007
  27. ↑ Chappell 2004 , p. 18
  28. ↑ Chappell 2004 , pp. 19-20
  29. ↑ Woolf 2007 : "An ESB by itself produces no business value."
  30. ↑ Linthicum 2005 : "... I defined the concept of ESBs in the EAI book, as what it is, an enabling technology for EAI."
  31. ↑ Schulte2002 p. 4: "Some [vendors] even deny that the ESBs are anything new, since the purpose of an ESB is so similar to that of a traditional integration broker suite."
  32. ↑ Linthicum 2006
  33. ↑ Engels et al 2008 , p. 201
  34. ↑ Websites of the respective manufacturers or a compilation of free ESBs in Rademakers et al 2008 , pp. 29–30
  35. ↑ uma-soft.ch: CrossLoom (Extended Enterprise Service Bus)
  36. ↑ OpenESB Community
  37. ↑ Service Bus. In: MSDN. Microsoft, July 8, 2014, accessed July 13, 2014 .
  38. ↑ Service Bus for Windows Server (Service Bus 1.1). In: MSDN. Microsoft, October 18, 2013, accessed July 13, 2014 .