Basics of Enterprise Application Integration:

Introduction:
Enterprise Application Integration (EAI) is defined as the uses of software and computer
systems architectural principles to integrate a set of enterprise computer applications.

In today’s competitive and dynamic business environment, applications such as Supply

Chain Management, Customer Relationship Management, Business Intelligence and
Integrated Collaboration environments have become imperative for organizations that
need to maintain their competitive advantage. Enterprise Application Integration (EAI) is
the process of linking these applications and others in order to realize financial and
operational competitive advantages.

When different systems can’t share their data effectively, they create information
bottlenecks that require human intervention in the form of decision making or data entry.
With a properly deployed EAI architecture, organizations are able to focus most of their
efforts on their value-creating core competencies instead of focusing on workflow
management.

For generations, systems have been built that have served a single purpose for a single set
of users without sufficient thought to integrating these systems into larger systems and
multiple applications. EAI is the solution to the unanticipated outcome of generations of
development undertaken without a central vision or strategy. The demand of the
enterprise is to share data and processes without having to make sweeping changes to the
applications or data structures. Only by creating a method of accomplishing this
integration can EAI be both functional and cost-effective.

One of the challenges facing modern organizations is giving all their workers complete,
transparent and real-time access to information. Many of the legacy applications still in
use today were developed using arcane and proprietary technologies, thus creating
information silos across departmental lines within organizations. These systems
hampered seamless movement of information from one application to the other. EAI, as a
discipline, aims to alleviate many of these problems, as well as create new paradigms for
truly lean proactive organizations. EAI intends to transcend the simple goal of linking
applications, and attempts to enable new and innovative ways of leveraging
organizational knowledge to create further competitive advantages for the enterprise.

EAI is a response to decades of creating distributed monolithic, single purpose

applications leveraging a hodgepodge of platforms and development approaches. EAI
represents the solution to a problem that has existed since applications first moved from
central processors. Put briefly, EAI is the “unrestricted sharing of data and business
processes among any connected application or data sources in the enterprise.”
Undoubtedly, there are a number of instances of stovepipe systems in an enterprise, such
as inventory control systems, sales automation systems, general ledger systems, and
human resource systems. These systems typically were custom-built with specific needs
in mind, utilizing the technology-of-the-day. Many used non-standard data storage and
application development technology.

However, EAI is not just about sharing data between applications; it focuses on sharing
both business data and business process. Attending to EAI involves looking at the system
of systems, which involves large scale inter-disciplinary problems with multiple,
heterogeneous, distributed systems that are embedded in networks at multiple levels.

Objectives of EAI:
EAI can be used for different purposes:

• Data (information) integration: ensuring that information in multiple systems is

kept consistent. This is also known as EII(Enterprise Information Integration).
• Process integration: linking business processes across applications.
• Vendor independence: extracting business policies or rules from applications and
implementing them in the EAI system, so that even if one of the business
applications is replaced with a different vendor's application, the business rules do
not have to be re-implemented.
• Common facade: An EAI system could front-end a cluster of applications,
providing a single consistent access interface to these applications and shielding
users from having to learn to interact with different applications.

Integration methods:
EAI has five common integration methods:

• Data-level integration
• User interface (UI)-level integration
• Application-level integration
• Method/component interface-level integration

Data-level integration

With data-level integration, you integrate the backend datastores that the integrated
applications use. Data-level integration can be push- or pull-based. With push-based, one
application makes SQL calls (through database links or stored procedures) on another
application's database tables. Push-based data-level integration pushes data into another
application's database. In contrast, pull-based data-level integration utilizes triggers and
polling. Triggers capture changes to data and write the identifying information to
interface tables. Adaptors can then poll the integrated application's interface tables and
retrieve the pertinent data. You'd use pull-based data-level integration when an
application requires passive notification of changes within another application's data.

UI-level integration

UI-level integration ties integration logic to user interface code. UI-level integration is
scripting- or proxy-based. Scripting-based UI-level integration embeds integration code
into the UI component events, common with client/server applications such as
PowerBuilder or Vantive. For example, when you click the Submit button of an Add
Customer screen, data must be sent to the application's database and a JMS (Java
Message Service) topic. Proxy-based UI-level integration uses the integrated application's
interface (through screen scraping) to pass data to and from the legacy system.

Application-level integration

Application-level integration, probably the best way to integrate applications, uses the
integrated application's integration frameworks and APIs. Application interfaces let you
invoke business logic to preserve data integrity. Integration API examples include Siebel's
Java DataBeans and SAP's JCA (J2EE Connector Architecture). Prefer application-level
integration because it is transparent to the integrated application and preserves the
application's data integrity.

Method-level integration

Method-level integration, a less frequently used superset of application-level integration,

aggregates common operations on multiple applications into a single application that
fronts the integrated applications.

EAI Topologies:
There are two major topologies: hub-and-spoke, and bus.

In the hub-and-spoke model, the EAI system is at the center (the hub), and interacts
with the applications via the spokes.

Hub-and-spoke architecture

Hub-and-spoke architectures consist of a centralized hub that accepts requests from

multiple applications that are connected to the centralized hub as spokes. The spokes are
connected with the central hub through lightweight connectors, which are constructed and
deployed on top of existing systems and applications. One of the key goals of the hub-
and-spoke architecture with connectors is to leave the current systems untouched and
unchanged as much as possible.
Inside the hub there are capabilities for requirements such as message transformation,
validation, routing, and asynchronous message delivery. Furthermore, most hub-and-
spoke-based EAI solutions provide process management functionality to orchestrate
interapplication message exchanges, and an administration console to monitor and track
the workings of the hub.

In the bus model, the EAI system is the bus (or is implemented as a resident module
in an already existing message bus or message-oriented middleware).

The ESB Architecture

The ESB is often characterized as the backbone upon which to build SOA. There are
numerous articles and white papers about the ESB, and they all have the following
elements in common when describing what the ESB is: an ESB is seen as a distributed
services architecture based on Web services standards, which delivers messaging
middleware, intelligent routing, and XML transformation in conjunction with a flexible
security framework and a management infrastructure for configuring, deploying, and
monitoring the services.

At the heart of the ESB architecture is the enterprise services bus, a collection of
middleware services that provides integration capabilities. Applications are connected to
this logical bus through smart connectors, which encapsulate system functionality and
provide a layer of abstraction between bus and application. In this smart connector we
may find typical capabilities such as transformation services and security services.
Through the use of open communication standards, connectivity between bus and
applications is established.
The aforementioned description points out that an ESB is more a logical concept than it is
a product. There are some vendors claiming that ESB is a product, but this perception
comes more from a traditional view of integration architecture, which is based on
products instead of standards.

One way or another, experts and analysts unanimously agree that for those companies
and organizations pursuing an SOA or an EDA, the shift towards an ESB-based
infrastructure is a major step in this evolvement.

Message-oriented middleware
Message-oriented middleware, as shown in is software that resides in both portions of a
client/server architecture and typically supports asynchronous calls between the client
and server applications. Message queues provide temporary storage when the destination
program is busy or not connected. MOM reduces the involvement of application
developers with the complexity of the master-slave nature of the client/server mechanism.
Figure 1: Message-Oriented Middleware

MOM increases the flexibility of architecture by enabling applications to exchange

messages with other programs without having to know what platform or processor the
other application resides on within the network. The aforementioned messages can
contain formatted data, requests for action, or both. Nominally, MOM systems provide a
message queue between interoperating processes, so if the destination process is busy, the
message is held in a temporary storage location until it can be processed. MOM is
typically asynchronous and peer-to-peer, but most implementations support synchronous
message passing as well.

Technologies:
Multiple technologies are used in implementing each of the components of the EAI
system:
• Bus/hub: This is usually implemented by enhancing standard middleware
products (application server, message bus) or implemented as a stand-alone
program (i.e., does not use any middleware), acting as its own middleware.

• Application connectivity: The bus/hub connects to applications through a set of

adapters (also referred to as connectors). These are programs that know how to
interact with an underlying business application. The adapter performs two-way
communication, performing requests from the hub against the application, and
notifying the hub when an event of interest occurs in the application (a new record
inserted, a transaction completed, etc.). Adapters can be specific to an application
(e.g., built against the application vendor's client libraries) or specific to a class of
applications (e.g., can interact with any application through a standard
communication protocol, such as SOAP or SMTP). The adapter could reside in
the same process space as the bus/hub or execute in a remote location and interact
with the hub/bus through industry standard protocols such as message queues,
web services, or even use a proprietary protocol. In the Java world, standards such
as JCA allow adapters to be created in a vendor-neutral manner.

• Data format and transformation: To avoid every adapter having to convert data
to/from every other applications' formats, EAI systems usually stipulate an
application-independent (or common) data format. The EAI system usually
provides a data transformation service as well to help convert between
application-specific and common formats. This is done in two steps: the adapter
converts information from the application's format to the bus's common format.
Then, semantic transformations are applied on this (converting zip codes to city
 names, splitting/merging objects from one application into objects in the other
applications, and so on).

• Integration modules: An EAI system could be participating in multiple concurrent

integration operations at any given time, each type of integration being processed
by a different integration module. Integration modules subscribe to events of
specific types and process notifications that they receive when these events occur.
These modules could be implemented in different ways: on Java-based EAI
systems, these could be web applications or EJBs or even POJOs that conform to
the EAI system's specifications.

• Support for transactions: When used for process integration, the EAI system also
provides transactional consistency across applications by executing all integration
operations across all applications in a single overarching distributed transaction
(using two-phase commit protocols or compensating transactions).

Advantages and Disadvantages

Advantages
• Real time information access among systems
• Streamlines business processes and helps raise organizational efficiency.
• Maintains information integrity across multiple systems

Disadvantages
• Prohibitively high development costs, especially for small and mid-sized
businesses (SMBs).
• EAI implementations are very time consuming, and need a lot of resources.
• Require a fair amount of up front design, which many managers are not able to
envision or not willing to invest in. Most EAI projects usually start off as point-
to-point efforts, very soon becoming unmanageable as the number of applications
increase.

Tools
BIZTALK SERVER 2006

BizTalk Server 2006 is Microsoft's premiere server for building solutions for business
process and integration. BizTalk Server 2006, the fourth major version of the product,
builds on the innovation and success introduced by the previous three versions—BizTalk
Server versions 2000, 2002, and 2004.
The 2006 version includes new capabilities and engine improvements that allow a
developer to create more flexible solutions for integrated business processes, and BizTalk
2006 empowers and enables administrators and business users to more effectively
monitor ongoing business processes.

SUN ONE INTEGRATION SERVER

Sun ONE Integration Server, EAI Edition is a standards-based enterprise application

integration solution that can handle multiple styles of integration by integrating the data,
transforming and transporting it and leveraging it within the context of business process
management. Sun ONE Integration Server handle multiple styles of integration:

• business process management

• data transformation and
• data messaging

It enables enterprises to create new business opportunities by leveraging their custom,

packaged apps and legacy systems to create new business solutions out of those systems.
It does this by enabling any application to connect into a standards-based integration
broker while managing the business processes that those systems support. Sun ONE
Integration Server has SOAP support for creating web services and is the integration
solution for the Sun ONE architecture &#150 the hub that brings together a new
generation of smart Web services.