Introduction
The increasing need for real-time and consolidated information has increasingly motivated companies to find a way to
integrate their disparate existing systems. The process of this integration is referred to as Enterprise Application
Integration (EAI).
What is EAI
EAI is the process of integrating multiple software applications that were independently developed, use incompatible
technology, and remain independently managed.
Fundamentally, EAI is about sharing and exchanging data and business processes among the different applications and
data sources in the enterprise.
Types of EAI
EAI can be done at different levels, depending on many factors including company size and industry, integration and/or
project complexity, and budget.
There are four main integration levels:
Data Level
Data Level EAI is a database-centric approach that consists of extracting data from one database and updating it in
another. Sometimes the extracted data can be transformed before entering it into the target database, for example, to
apply specific business rules.
Data-level integration is commonly done through ETL (Extract, Transform, Load) tools that can extract, transform,
cleanse, and load data from various data sources to a common enterprise data repository (a data warehouse) or data
repositories tuned to serve different business needs (data marts).
The main benefits of this approach are its low cost and low risk profile. Because we do not make any modification to
the existing code of the applications, we do not need to incur the expenses related to developing, testing, and
deploying new versions of the applications. The main drawbacks of this approach are the huge quantity of databases and
tables that are generated, the need for the Database
Designer to understand the data that is being moved, and the associated business rules.
Application Interface Level
This EAI level of integration consists of leveraging the interfaces provided by custom or packaged applications to
access business processes and simple information. Usually, this kind of integration is done in a three-step process:
-
Extract the information from one application through a provided application interface.
-
Convert the data in a format understandable by the target application.
-
Transmit the information to the target application.
The most commonly used approach to implement this kind of integration is called "message broker," an approach which
standardizes and controls the flow of information through a bus or a hub framework.
But with the increasing popularity of web services, legacy and packaged applications are starting to use them to expose
their business features. The availability of these business functions as reusable services causes the increased use of
Service-Oriented Architectures (SOA) as an alternative to "message broker."
The main benefits of this approach are the fact that the interfacing between the different applications is relatively
easy due to the fact that the application interfaces are provided by application. A negative aspect of this approach is
the cost of the message broker technology. In the past, these interfaces were often application dependent, obliging the
developers to learn the specific features and functions of each interface. But with the increasing popularity of XML
and its adoption as a standard language for many application interfaces, this problem is disappearing.
Method Level
Method-level integration is similar to application interface level but at a lower level of granularity. The idea here
is not to share business functions (as in application interface level), but to share directly the different methods
used to compose a given business function. All other enterprise applications needing to implement the same methods can
use them without having to rewrite it.
Even if this integration level can be done with a lot of technologies (Java RMI, Corba, DCOM, etc.), the emerging trend
in implementing this approach is to use Web services as a way to share the methods.
The ability to share methods and to reuse business logic make this approach very suited for EAI. But the downside to
this approach is that it is also the more invasive approach because it supposes the modification of existing
applications to allow the sharing at such a low level.
User Interface Level
User interface-level EAI is also commonly called "Refacing" and consists of replacing existing text-based user
interfaces of legacy systems and graphical interfaces of PCs by a standardized interface, typically browser-based.
Enterprise business portals are an emerging solution for this kind of integration and consist of federating the
presentation of multiple applications into one customizable browser-based interface.
This kind of integration is less expensive than other approaches, as the code of the existing applications is not
modified. However, this approach is also less flexible for the same reason.
EAI and Middleware
In EAI, middleware technology is just used as a mechanism to move information and share business processes from one
application to another. The middleware hides the complexities of the communication mechanism between source and target
systems. This allows the developers to concentrate on dealing with the APIs (Application Programming Interfaces) of
each system, while the middleware handles the passing of the information between the two systems. The same middleware
API can be used by different applications running on different platforms.
As an underlying technology of EAI, middleware can be used at any level of integration (even at user interface level because business portals can be considered as a kind of
middleware). However, the most common use of middleware technology is with message broker at application interface level.
EAI and XML
The eXtensible Markup Language (XML) standard is a text-based markup language specification from the World Wide Web
Consortium (W3C) whose objective is to define portable structured data. Because XML is simple and becoming a widely
used interchange format, it is ideal as EAI message format and protocol.
XML can be used with every integration level (except perhaps at user interface level). It can be used at data level as
common data exchange format, at application interface level as messaging format and/or protocol within a message
broker, or in a Service-Oriented Architectures (SOA) as support for web services. Because Web
services are built using XML, it also has a place at method-level integration.
Further Reading and References
-
David Linthicum, Next Generation Application Integration: From Simple Information to Web Services, Addison-Wesley,
2003.
-
Gregor Hope and Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley, 2003.
|