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
- Application Interface Level
- Method Level
- User Interface Level
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.
