The document discusses the need for enterprise service buses (ESBs) and their role in service-oriented architectures (SOAs). ESBs are needed to integrate heterogeneous information systems and ensure consistency across subsystems. They provide loose coupling between systems using standards-based integration. The document compares ESBs to other integration approaches like extract-transform-load tools, message-oriented middleware, and enterprise application integration, noting advantages of ESBs like separating mediation and orchestration roles. The key aspects of ESBs are that they provide a bus-like infrastructure to decouple applications and use adapters to transform data between application and canonical formats.

1. Mr. Abdessattar Ettaieb
ARS1/2 - 2016-2017
E-Services
Entreprise Service Bus

2. Content
ESB: Why do we need them?
ESB: Role in the SOA?
Use case of ESB
1

3. ESB:Why do we need them?
2
Information Systems Context:
•IS (Information Systems) are heterogeneous from a technological point of view.
•Each domain builds it’s own IS .
Need for Integration:
•How to trigger a process within a system from another system?
•How to insure the consistency and the propagation of data between many sub-
systems?
Two types of solutions:
•Extract-Transform-LoadTools
•Middleware solutions

4. 3
ETL Tools: Extract-Transform-Load
ETL comes from Data Warehousing and stands for
Extract-Transform-Load. ETL covers a process of how
the data are loaded from the source system to the data
warehouse, source system and destination system are
generally heterogeneous.
ETL Performs:
◦ Data extraction: extracts data from homogeneous or
heterogeneous data sources
◦ Data transformation: transforms the data for storing it
in the proper format or structure for the purposes of
querying and analysis
◦ Data loading: loads it into the final target (database,
more specifically, operational data store, data mart, or
data warehouse)
Disadvantages:
◦ Data centric approach.
◦ Cannot garantee the processes integration

5. 4
Network-Centric Middlewares (1/2)
MOM: Message Oriented Middleware:
◦ System Store and Forward
◦ Asynchroneous : The client builds a message and
sends it to the middleware, who routes it to the
destination.
◦ There is no technical coupling between different
third-parts.
◦ All third-parts must know the interfacing mode of
the middleware.
◦ Limited routing capacity, necessity of explicitly
configuring the routes.
Disadvantages :
◦ Require an extra component in the architecture, the
message transfer agent (message broker).
◦ Adding another component can lead to reductions
in performance and reliability, and can also make

6. 5
Network-Centric Middlewares (2/2)
ORB: Object Request Broker: is a
middleware which allows program calls to
be made from one computer to another via
a computer network. It takes care of all of
the details involved in routing a request
from client to object, and routing the
response to its destination.
Disadvantages :
◦ Deployment is very complex.
◦ Development and interoperability issues.
◦ A solution that needs important technical
skills.

7. EAI: EnterpriseApplication Integration
6
◦ Object-oriented programming.
◦ Distributed, cross-platform program communication using message
brokers with Common Object Request Broker Architecture and COM+.
◦ Modification of enterprise resource planning (ERP) to fit new objectives.
◦ Enterprise-wide content and data distribution using common databases
and data standards implemented with the Extensible Markup Language
(XML).
◦ Middleware, message queueing, and other approaches.
Disadvantages:
◦ High startup and initial development costs.
◦ Requires smart business design, which may not be able to be envisioned
with the help of a consulting firm.
◦ Need special development for connectors.
◦ SPOF (Single Point of Failure).
◦ Does not separate roles of mediation and orchestration.

8. 7
ESB: Entreprise Service Bus
EAI were transformed to two types of products:
◦ ESB to accompish the interconnections and mediation.
◦ BPM (Business Process Management) for orchestration
Data are not processed/treated on the on the ESB itself, they are sent to
the applications to through connectors.
ESB are designed basing on SOA principals: they are loosely coupled
and can be deployed seperatly.
ESB are designed basing on standards.

9. 8
ESB: Definition
ESB stands for Enterprise Service Bus and it’s fundamentally an architecture.
It is a set of rules and principles for integrating numerous applications together over a
bus-like infrastructure.
The "bus" concept decouples applications from each other.
The data that travels on the bus is a canonical format and is almost always XML.
There is an "adapter" between the application and the bus that marshals data
between the two parties.
The adapter is responsible for talking to the backend application and transforming
data from the application format to the bus format.The adapter can also perform a
host of other activities such as message routing transaction management, security,
monitoring, error handling, etc.
ESBs are generally stateless; the state is embedded in the messages passing through
the bus.