Click here to Skip to main content
Click here to Skip to main content

What is an ESB ?

, 7 Jan 2012
Rate this:
Please Sign up or sign in to vote.
A brief introduction for an Enterprise Service Bus

Introduction:In software engineering, a Service-Oriented Architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration.

One of the main platforms that was introduced is the Enterprise Service Bus referred to as ESB.

ESB:

ESB is considered a platform to realize a service-oriented architecture.

An 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.

ESB architecture

Use of the word “bus” stems from the physical bus that carries bits between devices in a computer. The ESB 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. Such an approach has the primary advantage of reducing 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.

ESB as software

In such a complex architecture, the ESB represents the piece of software that lives 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 will both transmit and receive. 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 will have 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).

ESB High level Architecture:

Salient characteristics

Category

Functions

Invocation

support for synchronous and asynchronous transport protocols, service mapping (locating and binding)

Routing

addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing

Mediation

adapters, protocol transformation, service mapping

Messaging

message-processing, message transformation and message enhancement

Process choreography

implementation of complex business processes

Service orchestration

coordination of multiple implementation services exposed as a single, aggregate service

Complex event processing

event-interpretation, correlation, pattern-matching

Other quality of service

security (encryption and signing), reliable delivery, transaction management

Management

monitoring, audit, logging, metering, admin console, BAM (BAM is not a management capability in other words the ESB doesn’t react to a specific threshold. It is a business service capability surfaced to end users. )

Key benefits

Faster and cheaper accommodation of existing systems.

Increased flexibility; easier to change as requirements change.

Standards-based

Scales from point-solutions to enterprise-wide deployment (distributed bus).

Predefined ready-for-use service types.

More configuration rather than integration coding.

No central rules-engine, no central broker.

Incremental patching with zero down-time; enterprise becomes "refactorable".

Key disadvantages:

Increase overhead, slow down communication speed; especially for those already compatible services.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Wael Al Wirr
Program Manager INVESTBANK
Jordan Jordan
Wael Al Wirr’s Specialties:
•Microsoft BizTalk Server 2004, 2006, 2010
•ASP.Net, C#, ADO.Net and .Net Framework (1.1, 2.0, 3.0, 3.5, 4.0)
•Windows Communication Foundation
•Windows Workflow Foundation
•Windows AppFabric
•ADO.NET Entity Framework
•Microsoft Line Of Business Adapter Framework
•SQL Server 2000, 2005
•Web development
•HTML, XML, XSD, XSLT
•JavaScript
•Database design
•Web Services
•Build, deployment script
•Microsoft Source Safe, Microsoft Team Foundation Server
Follow on   Twitter

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web04 | 2.8.140721.1 | Last Updated 8 Jan 2012
Article Copyright 2012 by Wael Al Wirr
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid