Current and Future Trends in
Enterprise Application Integration
Ehsun Saeed1, Shafay Shamail2
1.
2.
MSc Student, Department of Computer Science, LUMS, Defence, Lahore, ensaeed@yahoo.co.uk
Associate Professor, Department of Computer Science, LUMS, Defence, Lahore,
sshamail@lums.edu.pk
Abstract
The advances in the Information System
Technology have allowed enterprises to use and
apply increasingly sophisticated computer
systems to run their businesses effectively.
Organizations newly emerging as a result of
mergers or takeovers of existing enterprises face
the challenges of information inconsistency,
systems heterogeneity, and incompatible
overlaps. Solution of such conflicting factors lies
in systems integration. There are many
dimensions to the integration problem:
integration across geographically distributed
enterprise, integration with suppliers and
customers, integration of various activities,
integration of different tools etc. This paper
discusses different levels of Enterprise
Application Integration (EAI) each with its own
requirement
and
consideration.
Various
integration frameworks and architectures are
examined, focussing on the issues and challenges
involved. Limitations of traditional integration
approaches and associated pitfalls of these
methods are also highlighted. Future generation
of EAI is discussed emphasizing on the process
automation and the development of hybrid
product
for
integrating
separate
and
incompatible systems.
1. Introduction
Enterprise Application Integration is the
combination of processes, software, hardware,
and standards resulting in a seamless integration
of two or more enterprise systems allowing them
to operate as one. EAI is the process of
integrating multiple, independently developed
applications that may use incompatible
technology and need to remain independently
managed.
Today most organizations are using packaged
software for their key business processes.
Enterprise Resource Planning (ERP), Supply
Chain Management (SCM), and Customer
Relationship Management (CRM) systems
enable organizations to improve their focus of
using information systems (IS) to support their
operational and financial goals [1].
Successful implementation of consistent,
scalable, reliable, incremental, cost-effective
solutions depends on the standards and the
methodologies used for integration.
When writing new applications, one can select
the exact technologies and methodologies best
suited to the enterprise. In most situations,
Component–Based Development (CBD) is the
right choice. It promotes the development of
tightly coupled, well-defined highly reusable
components.
Microsoft designed its Component Object Model
(COM) specifically for this purpose. The
CORBA (Common Object Request Broker
Architecture) as implemented in several different
Object Request Broker (ORB) products, also fit
in this space, as does Enterprise JavaBeans
(EJB).
Components written on the same standard, using
any of these technologies can easily operate in a
flexible, scalable environment. Two applications
running on the same computer, written to the
same standard can communicate easily using
COM.
However,
application-to-application
integration running on two different computers
can communicate using CORBA or EJB, but
both have shortcomings. CORBA is a standard
but products that implement it (ORBs) are not
standard. None of the three technologies are
designed to work seamlessly with the others.
A true EAI architecture must recognize that
applications that run with in an enterprise were
written to different standards, use different
technologies and are implemented across
distributed heterogeneous platforms. Most A2A
(Application-to-Application) integration isn’t as
simple as having one component communicate
with solely via COM, CORBA, EJB. These
object request brokers don’t have all the features
of the message brokers [2].
2. Integrating Approaches
Different approaches of integration are:

Homogeneous with one instance: One
process is supported by one application and
one database. This model avoids problems
emerging from redundant data storage and
asynchronous data exchange between
separated applications.

Homogeneous with several instances:
Several identical processes in different
business units are supported by several
identical applications that run on different
computers and rely on logically separated
databases. An example of that kind of
integration is the Application Link Enabling
(ALE) from SAP which provides a
mechanism of coordination of data in
physically distributed SAP environments.

Heterogeneous: Several different processes
in different business units are supported by
several different applications. An additional
problem compared to the integration in a
homogeneous environment is that the
concerned applications are build upon
divergent data models, which means they
provide different semantics of data to be
exchanged.
Integrating
information
systems
means
establishing communication between these
systems. Inter-process integration requires that
all the aspects of the communication are identical
between both systems (ISO/OSI model) A
common syntax is required, which defines the
order, length, and the type of data being
exchanged. In addition, semantics is needed to
assign real world subjects and notions to the
transmitted characters. Semantics add a certain
meaning to individual data fields. Without open
semantics standards an automated exchange of
information among anonymous business partners
will remain illusive because it will require a
human interpreter. The third element – the
pragmatic element ensures that the transmitted
data has not only been understood but those
subsequent actions are triggered. For instance,
the IS would automatically issue an invoice once
a product has been delivered.
4. Traditional Integration Methods
Traditionally the following integration
methods have been in practice:

Figure 1: Point-to-Point Integration

Client/server:
Three-tier
client/server
models, in which business logic is separate
from data access, make it possible to
integrate multiple databases in a scalable
fashion. Integrating multiple applications,
however, remains a problem in a
client/server environment.

Data integration: A workable integration
approach needs to encompass data
integration, but cannot be based solely on it.
For example, data integration by itself is of
little help when transactions are involved,
nor does it directly address the integration of
business rules into business processes.

Enterprise Resource Planning: ERP systems
can be used to integrate non-ERP
applications. This approach, however, ties
non-ERP applications into essentially
proprietary framework, which does not
adapt quickly or cost effectively to business
change [3].
3. Integration Mechanisms

Call Interface: Applications provide a
callable interface, usually referred to as an
Application Programming Interface (API).
Such as Object interfaces (COM, CORBA,
or JavaBeans).

Messaging: Applications are integrated by
send and receive messages, usually via some
queing mechanisms. Message Queing
products are IBM MQSeries, MSMQ, ALE.

Data Access/File Transfer: Applications are
integrated by direct access to their
databases, or via file transfers.
Point-to-Point Integration: In this approach
each application requires a separate interface
with every other application. Thus, four
applications require 16 interfaces that have
to be developed, managed, and maintained;
eight application requires 56 interfaces and
so on. The net effect is a complex and
expensive-to-maintain fabric, or skein, of
application. A change in one application
requires a series of changes to be
implemented across all applications.
5. EAI Systems
Systems that enable companies to implement
inter-process communications are traditionally
known as middleware. Middleware is primarily
concerned with data level integration, which
means that these systems do not provide any
functionality that enables higher levels of
integration such as message or process
integration. In contrast to this EAI systems
encompass the technologies as well as the
process definition to enable custom built and/or
packaged business applications to exchange
semantic level information in formats and
contexts that each system understands. EAI offer
several types of services in addition to classical
middleware. These are:
5.1 Connectivity Services
Connectivity services enable data integration.
They extract information from one application
and transport it to another.



Communication services: They transport the
physical transport of data between
distributed
applications
by
using
synchronous
and
asynchronous
communication mechanisms.
Addressing and delivery services: These
kind of services offer functionality to
implement different addressing schemes,
such as point-to-point, broadcast/multicast
or publish-and- subscribe.
Security services: In some integration
scenarios such as inter-organizational ones,
sensitive information may be needed to be
transported between applications. That is
where security services offer functionality
for authentication, message integrity and
authorization.
5.2 Interface Services
Custom-built and packaged applications provide
different interfaces to communicate with other
applications; the only way to integrate with them
often is an intermediate resource, such as
database of text files. Interface services
normalize the way that communication,
transformation and process management services
access and interact with all applications to be
integrated with the EAI system. The suppliers of
EAI systems refer to this functionality as
connectors, integrators, adapters and building
blocks. They provide the following services:

Interface translation services: They assist
with data integration by providing links
between EAI’s own connectivity services
APIs and resource specific data access or
APIs.

Metadata representation services: They
assist with message and process integration.
They make elements of individual
resources’ object models and behavior
available to EAI solution developers so that
transformations are running correctly.
5.3 Transformation Services
Transformation services are the core of every
EAI system. They enable message integration by
taking incoming information that is passed to
them by connectivity services and convert it
from the formats imposed by its resource(s) into
formats acceptable to its destination(s).

Identification services: Incoming messages
are identified by a metadata discovery and
storage service. These messages can be
identified and validated based on their
content.

Synchronization services: In many cases,
transformation will require more than one
input from more than one source and inputs
will probably not arrive at the same time.
The synchronization services then provide
the functionality to ensure that the
predefined set of messages has arrived
before carrying out a transformation.

Routing services: Transformation may also
need to produce more than one output or the
output of a message defines the destination
in some cases. Transformation must be
flexible enough to direct outputs to different
destinations even via different connectivity
services.
5.4 Process Management Services
These services enable intra and interorganizational process integration by operating
above the level of individual transformations.
Just as transformation services coordinate sets of
messages, process management services
coordinate sets of transformations. Process
management services control the execution of a
sequence of transformations as specified by a
pre-defined model. With process management
services, multiple distributed application can be
integrated.

Interface development services: In most
companies and even business units of these
companies, packaged applications like SAP
R/3 are customized specifically which
means that integration scenarios between
distributed ERP systems even within one
company are not easy to handle. Therefore
interface development services assist the
developer with a functionality to customize
preconfigured adapters for packaged
software and develop adapters for custombuilt applications.

Transformation
specific
services:
Transformation specification services are
used for the definition of mapping
mechanisms, in order to transform a
message format from a source application
into a format of the destination application.
Simple transformation in most products can
be specified graphically via commonly used
drag-and-drop interfaces. These tools
provide repository interfaces which allow
the developer to find and select multiple
sources and targets for the transformation,
and a canvas on which the developer drops
source and target structures before creating
connections between elements of sources
and targets.
Process modeling services: The most
convenient way to specify a process model
is via graphical modeling environment like
those provided with CASE tools. In context
of EAI state-transitions diagrams are the
obvious choice. A process is represented by
a set of states linked by transitions. Each
transition links two states, and each state can
be linked to many other states by multiple
transitions. Most of EAI solutions offer
simulation environments with which
developers can validate the workflow [1].
5.5 Runtime Services
As EAI systems provide an additional software
layer between the applications to be integrated,
criteria like performance, reliability, availability
and scalability play an important role in using
such a system.



Distribution services: To improve the
performance of the integration architecture,
developers have two options when it comes
to distributing the runtime services. On one
hand, interface and connectivity services can
be implemented locally to each resource to
be
integrated,
and
connectivity,
transformation and process management
services can be installed centrally with in
one or more brokers. This scheme is called
hub-and-spoke architecture. On the other
hand, services can be implemented wherever
it makes more sense for a specific
architecture that is then called a federated
architecture.
Scalability services: Scalability services
offer load balancing and failover
mechanisms. Load balancing improves
scalability by spreading workload between a
group of servers. In this context, load
balancing can be used to spread the load on
transformation services when large volumes
of messages are received with in a short
time. Load balancing can either be static, so
the groups of servers that can be included in
the scheme are preconfigured or it can be
dynamic, in which case the load balancing
function can start new instances of servers
as needed. The failover service improves
availability by automatically re-directing
requests for services to one or more backup
servers when a server fails.
Monitoring Services: EAI systems offer
monitoring services to monitor and analyze
their availability and performance.
5.6 Development Services
EAI systems assist with variety of functionality:

6. Middleware
It is a transport software that is used to move
information from one program.A software layer
between the operating system –including the
basic
communication
protoocls-and
the
distributed applications that interact via the
network. This software infrastructure facilitates
the interaction between among distributed
software modules running across multiple
platforms [4,5].
Types of Middleware
Transactional middleware
TP monitors
TP monitors provide a complete environment for
transaction applications that access relational
databases. In TP monitors, clients invoke remote
procedures that reside on servers, which also
contain a SQL database engine.Procedural
statements (transaction), which either all succeed
or all fail as a unit.
TP monitors should be considered when
transactions need to be coordinated and
synchronized over multiple databases. TP
provides transaction integrity, state management,
resource management and load balancing[4].
Application Servers
The real benefit to application server is the
ability to multiplex and manae transactions that
result in the reduction of the number of
connections and procesing load that larger
systems place on a database.
When the number of incoming client requests
surpasses the number of shared processes that the
system is able to handle, other processes start
automatically.
Application servers use dynamic switching to
reroute transactions around server and network
problems.the transactions work through a twophase-commit process to assure that the
transactions are complete [6].
Obect Request Brokers
They are language independent object-oriented
RPC’s. There are two standards for CORBA and
DCOM. ORB’s are used in projects that require
a
strict
object-oriented
approach.ORB’s
aregenerally synchronous and operate in a point
–to–point manner.
Message Oriented Middleware
Message oriented middleware works by passing
information in a message from one program to
more programs. The informtion can be passed
asynchronously, where the sender does not have
to wait for a reply. MOM products provide
services for translaying data, security,
broadcasting data to muliple programs, error
recovery, locating resources on the network, cost
routing, priortization of messages.
Two different types of MOM have emerged.

Meessage Queing
 Message Passing
Message Queuing
In message queuing, program-to-program
communication occur via queue, which typically
is a file. It allows program to send and receive
information without having a direct connection
established between them. A program simply
gives a message to the message queing services,
identifies the name of the queue in which it
wishes the message to be placed.
Message Passing
This approach is different from message queuing
in that rather the application to retrieve the
informtion they request, the information is
published to interested parties (pub/sub). In
pub/sub
programs
subscribe
to
a
subject.Programs also publish messages to the
subject. Once the subject has been subscribed to
by program, the program will receive the
messages published to that subject-distributed
application.
MOM vendors implement publish subscribe with
a set of agents that maintain a real time database
, listening which program are interested in which
subjects. A program published a message by
connecting it with one of the agents and send the
message to it. The agent then routes the message
to the appropriate programs [4].
Java Message services
JMS is Java framework for MOM. The Java
language is platform independent. JMS defines a
set of standard Java interface for Java programs
that can create, send, receive and read message
from an enterprise messaging system. Normally,
the JMS complaint MOM products would act as
a buffer between the application and the lower
communication layer. This help protect the
application from the transport layer faults,
making the application more fault-tolerant. By
aggregating the code responsible for low level
message transport and delivery into a separate
layer the application architecture becomes
modular,
promoting
higher
application
scalability. JMS can also improve distributed
application performance by providing a
centralized
facility for inter-applicationmessaging. JMS benefits are portable, open
framework, more resilient programming model
as it protects the application from the network or
communication fault, modular design ensures
message handling occurs with in a separate layer
JMS makes an application more modular with
JMS as a separate component apart from the
application’s business logic ,it can be easily
upgraded with little or no code revision. [6].
Messaging vs. object Request Brokers
Messaging can be considered when:
 Implementing loosely coupled applications.
 Require guaranteed delivery of messages
between applications.
ORB products can be considered when:
 Tightly coupled applications are needed.
 Sources of integration are already well
structured and have clear interfaces.
 Implementing architectural standards.
 Wrapping existing application interfaces
into a single technology.
 Integrating in-house applications
7. Adapters
Applications are logically attached to the
integration system by means of adapters. An
adapter translates between an application ‘s API
and the integration system’s unit of information
exchange, the event. A typical adapter subscribes
to events that related to its application. When ti
recieves an event, the Adapter invokes the
application’s API tp perform the operation
described in the event. An adapter may publish
or deliver an event to signal that it has processed
an incoming event. An adapter may also be
invoked by its application, in which case it
publishes an event, typically a notice that
announces something that has happened in the
application.
Static and Dynamic Adapters
Static Adapters-When a typical static adapter is
started, it subscribes to the set of event types
coded into it. When an event arrives, the adapter
invokes its applications, usually passing data
obtained from the event. If the event is a request,
the adapter delivers a new event containing data
returned by the application. The main benefit of
a static adapter is that the programmer doesn't
have to work with all the different application
program interfaces, since the adapter handles the
basic translation behind the scenes
Dynamic Adapters-They have a general
processing framework coded into them and
discover the specifics of what they are to do at
run time. By eliminating programming, dynamic
adapters decrease the time required to integrate
an application and reduce the risks of failure and
error. Dynamic adapters are a combination of
agent containers and adapter components. The
adapter components consist of the actual code for
communicating with the enterprise application.
The agent container handles services such as
session management, error handling and
exception management.
These agent adapters provide node-level filtering
and transformation of data, so that large amounts
of raw data do not have to be shipped over the
network to the integration broker but, rather, can
be handled out at the nodes, where the source
application resides. At run time, the "agent
service" component of the agent adapter receives
the data from the adapter component, filters the
data, performs transformation mappings and
translates the native form into a document before
invoking the messaging system to deliver it to
the queue. That added intelligence makes the
integration process more efficient and puts less
of a strain on network bandwidth [7].
8. Message Brokers
Message brokers are specialized publishsubscribe systems with additional services that
simplify the process of building EAI solutions.
Message brokers services can be separated into
several
distinct
categories:
message
transformation services, rules processing,
intelligent routing, message warehousing, and
flow control, repository services and directory
services.
Message Transformation. Many message
brokers have a message translation layer that
understands the formats of each message being
passed among applications and changes their
formats “on the fly”. The message broker
restructures the data from one message into a
new message that makes sense to the receiving
applications. The message layer provides a
common directory with information on how each
application communicates.
Rules processing. The rules processing engine
within most message brokers allows for the
creation of rules to control message processing
and distribution.
Intelligent routing. Intelligent routing builds on
the capabilities of both the rules and the message
translation layers. The message broker can
identify messages dynamically coming from the
target application and route that information to
the proper source application, translating
messages, if required.

Process-level EAI deals with building
enterprise-wide business processes and
incorporating existing applications into
those processes. Process level EAI is an
extension of message level EAI .The actual
data exchange still occurs via messaging,
but EAI middleware acts as a workflow
engine-orchestrating message exchange.
This is ultimate EAI implementation
because it transforms existing disparate
applications into a cohesive system of the
business processes, supporting all the
functions the enterprise requires [8].
Data-Level EAI
Figure 2: Message broker use a hub-andspoke architecture.
Message warehousing. It is a database that store
messages that flow through the enterprise
Graphical User interfaces. GUI lets you create
rules, link applications, define transformation
logic, etc. It also allows system management of
the message broker. System management tools
support tracking, monitoring of message broker
components.
Directory Services. A directory service is a
mechanism that provides the location,
identification, use of authorization of network
resources (such as source or target application)
6. Types of EAI
There are three different types of EAI:


Data-level EAI deals with moving data
between multiple data stores. This supports
data exchange between disparate data stores
when applications must share information.
In data-level EAI one can access different
databases with virtually no changes to
application code.
Message–level EAI deals with the exchange
of messages between multiple exchanges.
This approach differs from the data-level
EAI in that the applications themselves do
the messaging. This provides more
controlled information exchange. This
approach also leverages data transformations
and validations. Message–level EAI is more
invasive than data-level EAI because it
requires more modifications to existing
applications to create interfaces for sending
and receiving messages.
Data-level Enterprise Application Integration
assumes bypassing the application logic and
extracting or loading data directly into the
database through its native interface. Application
code rarely requires modification. Most users
and applications will remain ignorant of the fact
that data is being shared.
Data-Level EAI Design
Identify data. The first task in the process of data
identification is creating a list of systems needs
to be integrated. Based on that list it is possible
to determine which databases exist in support of
those systems.
Identify data format: This allows for
determining how information is structured.
Different structures and schemas require an
understanding of data formats in order for those
schemas and structures to be transformed as
information moves from one system to another.
Catalog data. Create data dictionary that
includes metadata and other data through out the
problem domain. This includes system
information, security, ownership, connected
processes, communications and integrity issues
etc.
Metadata model. The metadata model defines all
the data structures and how these structures will
interact with the EAI solution domain. The data
catalog defines the problem parameters. The
The enterprise metadata model solves it.
Data-Level EAI Implementation
There are two basic approaches to build datalevel EAI:
Database-to-database EAI means simply sharing
information at the database level. Traditional
database middleware, database replication
software or database integration software to
implement this solution. There are two flavors:
basic and complex. The basic replication solution
moves data between databases with the same
basic schemas. The more complex solution is
replication with the transformation. This
approach allows moving data between different
database models (relational, object-oriented etc)
with different schemas by transforming data on
the fly. The advantage of this approach is
virtually no impact on existing applications.
Federated Database EAI. This approach allows
various applications to access any number of
databases, using different brands, models, and
schemas through the single “virtual” database
model. This virtual database model exists only in
software and is mapped to any number of
connected physical databases. This approach
relies on middleware to share information
between applications. Moreover, middleware
hides differences in the integrated databases
from all the applications using these integrated
databases [9].
Message-Level EAI
Message–level
Enterprise
Application
Integration assumes message exchange between
integrated
Information
Technology
(IT)
components. Any tier of an application – GUI,
application logic and database, can originate or
consume the message. When messages are both
produced and consumed by a database, messagelevel EAI becomes an implementation of datalevel EAI. The only difference that the actual
implementation is done using messaging
software,
rather
than
database
tools.
Implementing
message-level
requires
understanding
business
events,
message
producers and consumers, message content, and
applying business principles to determine which
data flows to implement.
Message-Level EAI Design
Define and catalog business producers. When an
event occur, the IT system is responsible for
creating a message and publish it to message
consumers. There can be one or many producers
of the same message. Producers of every event
are catalogued along with the event and message.
Define and catalog message consumers. Every
consumer requires a certain amount of
information from the message to react to the
particular event.
Define and catalog message content Define data
requirements for the messages. Analyze carefully
the data for these messages to extract common
definitions, which will form the foundation of
the message dictionary.
Extensible Markup Language (XML) can be
used for presenting and capturing message
content. It is platform independent and human
readable, which makes it easier to use between
multiple IT platforms. In addition, XML
provides a data transformation facility for
standardizing message transformation between
consumers and producers.
Message-Level EAI Implementation
Message-level EAI is normally built using some
type of middleware. Middleware is connectivity
software that consists of set of enabling services
that let multiple processes run on one or more
machines to interact across the network.
Middleware provides an isolation layer of
software by presenting its own enabling layer of
Application Program Interfaces (APIs). This
layer hides the differences incurred by such a
heterogeneous environment.
There are several ways to implement messagelevel EAI:



Define and catalog business events and
messages. Messages are the result of the
business events. A message is a method of
sharing information about the event with other
applications. Defining the events effectively
creates an overall message structure of the
integrated enterprise.
Synchronous
versus.
asynchronous
messaging.
Point-to-point versus. publish–subscribe
architecture.
Request/reply versus. multicast request/reply
Synchronous vs. Asynchronous Messaging:
Messaging systems are built on top of generic
middleware, which can employ two types of
communication mechanisms:
Asynchronous. The sending application sends
the message and continues its processing.
Asynchronous middleware decouples message
delivery from both sending and receiving
applications by serving as a separate process that
provides synchronization and message delivery.
Message consumer and producer don’t have to
be running simultaneously for message delivery
to occur.
Synchronous. The sending application is
blocked during the process of message delivery.
Synchronous middleware is organized as a set of
services, which become part of message
producer process for the duration of the message
delivery. The message producer and consumer
are tightly coupled and must run simultaneously
for message delivery to occur.
Point to Point vs. Publish Subscribe:
In point-to-point communication a messaging
pipe is created between applications. The biggest
limitation of this approach is its inability to
properly bind together more than two
applications. The message – level EAI using
point-to-point
communication
leads
to
unmanageable webs of pipes, going between
multiple applications. On the other hand, linking
only two applications is significantly easier than
taking into account many-to-many relationships.
A publish-subscribe model consists of
applications that publish information on a
network and applications that have subscribed to
receiving information on specific topics of
interest. These subscribers can then consume the
particular information they are interested in after
the information is published. The advantage of
publish-subscribe model is that it enables
development of loosely coupled, highly flexible
business systems. Producer and the consumer
applications do not have to know about each
other’s existence, location, or state. New clients
can be added without interruption of the
operation. Publish-subscribe is the only
reasonable approach for building message-level
EAI.
Request/Reply vs. Multicast Request/Reply:
In Request/Reply a client requests data from a
server; the server computes an individual
response and returns it to the client.
Communication flows in both directions.
Examples:
 Transaction processing (as in ATM
banking).
 Database query (with a remote DBMS).
 Factory equipment control.
In request/reply interactions, data producers
coordinate closely with data consumers. A
producer does not send data until a consumer
makes a request. Each program sends its
message to a specific inbox name within the
other program
In Multicast Request/Reply interactions multiple
servers can receive the request and respond as
appropriate. Communication flows in both
directions, and only some servers respond to the
client. The complete interaction consists of one
multicast request message, and any number of
point-to-point reply messages.
Example applications:
 Database query with multiple servers.
 Distribution of computing sub-tasks to the
first available server [10].
Process-Level EAI
Implementing the process-level EAI requires
understanding business processes as well as the
business rules and events and IT components
participating in those business processes.
Following steps are involved while designing the
process-level EAI.
Process-Level EAI Design
Business Process: Identify the business
processes that need to be created or supported in
the integration enterprise.
Business Events: Define the business events that
will initiate business processes.
Process Participants: Identify the essential IT
components for every process and any additional
required IT components or additional
functionality.
Process rules and functionality: Business rules
define the sequence of invocation of IT
components, capture and catalog these along
with the types of messages providing data
exchanges.
Message Content: Build message dictionary of
all the messages across the enterprise. Define the
data requirements of all the messages.
Figure 3:Message Broker-Based Process Level
EAI
Process-Level EAI Implementation
There are two commonly used approaches for
implementing process-level EAI
 message broker–based and
 application server-based.
Message Broker-Based, Process-Level EAI
Advantages:
 Every IT component is connected only to
the message broker, not to each other, so
every component is connected only to one
place in the enterprise.
 Overall messaging is asynchronous,
providing decoupling of IT component
execution.
 The message broker is responsible for all
data transformations, providing a central
point of control for this throughout the
enterprise.
 Message brokers provide GUI-based
facilities for creating simple business rules,
thus simplifying both control and
modification of business rules.
 Guaranteed
message
delivery
is
implemented in most message brokers.
 Pre-built adapters and connectors simplify
system construction.
Disadvantages:
 Because messaging is asynchronous end-toend transactions aren’t supported. Hence
compensating
transactions
must
be
introduced.
 End-to-end security is difficult to
implement. There are no standard APIs for
message brokers.
 There are no standard interfaces, standard
specifications or standard abstractions.
Application Server-Based, Process-Level EAI:
As shown in the figure component wrappers
introduce all of the IT components to the
application server. From the application server
perspective, the execution occurs among
components within the application server. The
application server is oblivious to the fact that
those components are only the façade for the
existing IT components, which are doing the real
work. The adapter/component wrapper pair is
responsible for providing a layer of abstraction,
allowing for IT component communications as if
the components were executed with in the
application server environment itself. The
responsibilities of the application server are:
 Message routing
 Data transformation
 Business rules implementation
 Business process support
Figure 4 Application server based, Processlevel EAI.
The java2 platform, Enterprise Edition (J2EE)
connector architecture defines a standard
architecture
for
connecting
J2EE
to
heterogeneous Enterprise Information Systems
(EIS) such as ERP systems, transaction
processing monitors.
Advantages:
 Each IT component is connected only to
application servers, not to each other, so
every component is connected only to one
place.
 The application server is responsible for all
data transformations, thus providing a
central point of control.
 Any proprietary connection can be created
to implement a component wrapper.
 The application server is highly scalable so
overall scalability is limited only by IT
components scalability.
Disadvantages:




All communication are synchronous so there
is a strong coupling between IT components.
All processing occurs synchronously, so
long-lived processes can starve application
server resources.
Few tools are available to support
implementation of business processes,
business rules, and data transformation.
Resource pooling is necessary to speed up
communications
between
component
wrappers and components [11].
EAI Architecture Pattern
Following patterns are used for EAI
 Integration Adapter: Converts an existing
application interface to a desired interface.
 Integration Messenger:
Describe
an
approach
to
minimize
application
communication
dependencies
between
applications.
 Integration Façade: Provides a simplified
interface
to
back-end
applications,
minimizing dependencies between client and
the server applications.
 Integration
Mediator:
encapsulates
application integration logic, minimizing
application dependencies.
 Process automator: Describes an architecture
approach that minimizes dependencies
between process automation logic and
applications [12].
7. EAI Architectures


Bus Architecture
A producer broadcasts a message using a
network transport cable
that
supports
broadcasting. This results in all machines within
a certain range receiving the messages.
Therefore, there is an additional requirement for
filtering the information locally [14].

Federated Static Architecture
Federated static architecture allows applications
and data sources to connect to a single
integration server or hub statically. These hubs
can exchange information with each other. This
means that all the information produced or
consumed from a particular application is only
available for processing within a particular hub.

Federated Dynamic Architecture
This is quite similar to federated static
architecture except that all the available
integration servers work together as a single
integration sever to meet the application
integration needs of the connected applications.

Transactional Architecture
Transactional architecture is based on the
transactional model employed by the application
server and the transaction processing (TP)
monitors. This architecture provides integration
between applications through discreet atomic
transactions that are able to share and recycle
server resources.
Hub-and Spoke Architecture
Message brokers require that all the information
consumed from source applications is processed
within a single server, the hub. Message broker
processing is a mixture of a schema and content
transformation, rules processing message
splitting, message combining, as well as message
routing. Once the processing is complete, the
information is sent to any target system that
needs to receive that information using whatever
native format of the target application can
understand (for example XML, iDOC, Java
Messaging Service (JMS), proprietary and so
on).This architecture is preferred when there
needs to be access control over the information
being published. It forces the subscriber to
authenticate itself to the hub before it will
receive the message.
Leveraging a transaction middleware layer that’s
able to consume information for one or more
applications, process that information in the
boundaries of a transaction, and publish that
information to one or more target systems before
the transaction completes.
Figure 4: Integration Architecture

Peer to Peer Architecture
This architecture is much like the message
broker architecture but with one twist: there is no
central integration server. Instead the message
translation, routing, splitting, and combining
occurs at the source and target systems with in
little message brokers known as agents. The
While most application integration vendors offer
some business process automation capabilities
today, this technology is still in the early stages.

agents consume the information from the single
system they are connected to, process that
information and send it directly to any target
system(s) interested in receiving that information
(message). The end result is the virtual hub and
spoke type architecture with centralized rules
and business flow, but with most of the
processing occurring at the source and the target
systems [13].
8.
Next-Generation EAI
It is expected that EAI services market will
become the most important and fastest growing
IT sector in the next three to five years.
Revenues in this market are expected to jump
from $5billion in 2000 to nearly $21 billion in
2005 [15].

Continued focus on B2B
Application integration is something that needs
to occur both within and between companies.
Leading B2B integration vendors are looking to
expand their offerings to provide deeper
application integration capabilities within the
enterprise, while existing EAI vendors are
looking to retool to provide B2B-oriented
features such as partner management,
collaboration and support for long transactions.

Growing Interest in Process Automation
While most application integration technologies
are focussing on just connecting application A to
application B, interest in the use of process
models, or business process automation, within
application integration is growing. Process
model provides layer of abstract business
processes that define how applications work
together above the physical middlware layers.
Adapters Assuming a Key Role
Currently enterprise application interfaces
continue to be largely cryptic and proprietary.
While more open interfaces are in the application
roadmaps, application integration technology
providers will continue to focus on providing
adapters that abstract the user from having to
deal with native application interfaces. Moreover
there will be shift in the usage of adapter, from
static software components that simply pass
information to intelligent adapters that manage
application interaction, including information
and rules processing within the adapter.

Normalization of Standards
Currently, the application integration space too
many standards with XML, RoseettaNet,
ebXML and the OAG specification. Clearly, the
number of standards is confusing for the
integration architects, however, few of the
standards will have a great impact going forward
and will provide more flexibility and openness
down the road. For instance, XSLT (XML
Stylesheet Language Transformations) is clearly
the standard mechanism of choice for
transformation. There are tradeoffs, however,
XSLT, for instance, does not provide most of the
features found in proprietary transformation
engines. XML, being at its core a hierarchy of
simple text data with embedded metadata, does
not serve as an efficient message format.

Focus on Scalability
Most EAI and B2B problem domains-that is the
projects are still small. Moving forward,
application integration projects will grow to
exchange information and processes among more
than 100 systems, and then more than 1,00. The
problem, however, is that existing application
integration technology won’t provide that kind of
scalability. Future technology that leverages
architectural features such as distributed message
processing, resource pooling and support for
massively parallel processing. Leveraging these
proven architectures will bring the capacity of
many application integration systems to several
thousand messages per second.

Emergence of Hybrid Products
REFERENCES
It is clear that application server vendors are
looking to incorporate basic messaging
brokering capabilities in their application server
products. At the same time, message brokers are
looking to incorporate application server
features, including transactional application
development capabilities, imbedded object
request brokers and support for traditional
application server standards, such as Enterprise
JavaBeans [16].
6. Conclusion
The advantage of data-level EAI is its low
invasiveness. It provides a database view that’s
tightly integrated and easier to manage or
change. Initial tendency to solve all integrationrelated problems, however, is confronted with
considerable complexity and difficulty in case
such linking is attempted for large-scale systems.
Additionally, the systems integration may suffer
from the constraints in its applicability as the
process involves bypassing of validation logic
while affecting direct data transfer to the
databases, which may not be acceptable for all
application.
The message-level EAI approach allows
organizations to build a significantly more
responsive system compared to the data-level
EAI. This owes to the fact that messages
immediately follow the occurrence of business
events. Message-level EAI also preserves
validation and data transformation logic in the
applications, therefore leading to a safer
integrated system.
A process-level EAI approach requires
concentrating on internal processes and drives
the overall integration based on these processes,
automating business processes and helps
organization to built more agile and flexible
enterprise systems. It also improves the
flexibility of business processes within and
between organizations.
Every EAI problem domain is unique,
characterized by its unique requirements. There
is no single architecture that fits all scenarios.
Merits and demerits of each type of EAI
framework and the associated architecture need
to be carefully discerned before deciding on its
adoption under a specific environment.
[1] Puschmann, T., Alt R. Enterprise Application
Integration –The Case of Robert Bosch Group.
Proceedings of the 34th Hawaii International
Conference on System Sciences-2001.
[2] Longo, R, J. The ABCs of Enterprise
Application Integration. eAI Journal May 2001.
http://www.eaijournal.com
[3] Enterprise Application Integration Zero
Latency
Enterprise
white
paper:
CompaqNonStop TM Solutions Integrator
www.compaq.com.
[4] Talarian TM: Everything You need To know
about Middleware-A Guide to selecting A Real
Time Infrastructure.
http://www.talarian.com/industry/middleware/w
hitepaper.shtml.
[5] Geihs, K. Middleware Challenges Ahead
Computer, June 2001,pp. 24-30.
[6] Gao Raymond JMS A portable framework
fpr connecting the enterprise the enterprise. eAI
Journal may 2001 http://www.eaijournal.com
[7] Hildreth Sue Smart Adapters How new
Adapter technologies can provide a scalable,
more distributed architecture.
http://eai.ebiq.net/enterprise-integration.
[8] Linthicum.S, D. Application Servers and
EAI.eAI Journal July/August 2000
http://www.eaijournal.com.
[9] Lublinsky B. Achieving the Ultimate EAI
Implementation. Part 3: Data-Level Integration
eAI Journal February 2001.
http://www.eaijournal.com
[10] Lublinsky B. Achieving the Ultimate EAI
Implementation. Part 2:Message-level
Integration eAI Journal February 2001.
http://www.eaijournal.com
[11] Lublinsky B. Achieving the Ultimate EAI
Implementation. eAI Journal February 2001.
http://www.eaijournal.com
[12] Lutz, C. Jeffry. EAI Architecture Patterns
eAI Journal March 2000
http://www.eaijournal.com
[13] Linthicum, S, D Making EAI Scale
Intelligent EAI/ The Linthicum Report April
2001.
[14] Moragenthal, J., Laforge, L B. Enterprise
Application Integration with XML AND JAVA
Prentice Hall PTR (2001).
[15] EAI overview ITtoolbox
http://eai.ittoolbox.com/pub/eai_overview.htm
[16] Linthicum, S, D. Next-Generation EAI:
Eight Prophecies for 2001.
http://www eai.ebizq.net/str/linthicum_1.html.