Application integration (sometimes called enterprise application integration or EAI) is the process of bringing data or a function from one application program together with that of another application program. Where these programs already exist, the process is sometimes realized by using middleware, either packaged by a vendor or written on a custom basis. An common challenge for an enterprise is to integrate an existing (or legacy) program with a new program or with a Web service program of another company. In general, for new applications, the use of object-oriented programming and actual or de facto standard development tools and interfaces (such as Java or .NET) will help ensure that new application programs can be easily integrated with those that may be needed in the future. The Extensible Markup Language (XML) promises to serve as a tool for exchanging data among disparate programs in a standard way.

In today's enterprise infrastructure, system and application integration is more and more frequently a mission critical concern.  The wide variety of approaches and ideologies aimed at achieving  this goal are proof of this fact.  When you're just getting started researching application and data integration solutions, it's easy to get lost in a sea of acronyms, opinions, and confusing marketing language.  
Rapid advancements in EAI technology to meet the increasing demand for integration in the enterprise often results in arguments about what EAI is or isn't, or how the small differences between one proprietary approach or another make it the only viable solution.
In this article, we'll clear up the confusion, with an easy to understand, clearly organized look at the evolution of EAI.  
Starting with a brief history of the origins of EAI, we'll walk through all the major developments in EAI architecture, and learn how traditional "hub and spoke" broker-based EAI systems are now being replaced by agile, distributed, standards-based Enterprise Service Bus architectures.

The Origins of EAI

Enterprise Application Integration, or EAI, has existed as a technical term since the early 2000s, but the central problem that it attempts to solve is much older.  In a nutshell, EAI is an approach, or more accurately, a general category of approaches, to providing interoperability between the multiple disparate systems that make up a typical enterprise infrastructure.

Enterprise architectures, by their nature, tend to consist of many systems and applications, which provide the various services the company relies upon to conduct their day to day business.  A single organization might use separate systems, either developed in-house or licensed from a third party vendor, to manage their supply chain, customer relationships, employee information, and business logic.  This modularization is often desirable.  In theory, breaking the task of running a business into multiple smaller functionalities allows for easy implementation of the best and newest technological advancements in each area, and quick adaptation to changing business needs.  

However, to gain the benefits of this kind of distributed, modular system, an organization must implement technologies that deal with the problems presented by this architecture:

• Interoperability: the various components of the infrastructure may use different operating systems, data formats, and languages, preventing connection via a standard interface.
• Data integration: in order for a modular, distributed system to be functional, a standard method of handling the flow of data between applications and systems to enforce consistency across the database is crucial.
• Robustness, Stability, and Scalability: Because they are the glue that holds together a modular infrastructure, integration solutions must be highly robust, stable, and scalable.

The EAI Approach To Integration

To avoid the complexity and fallibility of integrating complex infrastructures using a point to point approach, EAI solutions use various models of middleware to centralize and standardize integration practices across an entire infrastructure.  
Rather than each application requiring a separate connector to connect to every other connector, components in an EAI-based infrastructure use standardized methods to connect to a common system that is responsible for providing integration, message brokering, and reliability functionalities to the entire network.
In other words, EAI solves the problem of integrating modular systems by treating integration as a task for a system, like any other task, rather than a snarled mess of brittle connections.  EAI systems bundle together adapters for connectivity, data transformation engines to convert data to an appropriate format for use by the consumer, modular integration engines to handle many different complex routing scenarios simultaneously, and other components to present a unified integration solution.

EAI loosens the tightly coupled connections of point to point integration.  An application can send a message without any knowledge of the consumer's location, data requirements, or use for the message - all of this information can be handled by the EAI implementation. This allows for a more flexible architecture, where new parts can be added and removed as needed, simply by changing the configuration of the EAI provider, and simplified modular development, where a single service can be re-used by multiple applications.
Many modern EAI approaches also take advantage of the opportunity presented by adding a central integration mechanism to further consolidate messaging tasks.  In addition to data integration, a modern EAI may also include functionalities such as network administration, security, acceleration, and scalability.

The first EAI solutions on the market took the idea of unifying integration literally, and incorporated all the functionality required for integration into central hubs, called brokers.  
In this section, we'll look at the advantages and disadvantages of this model, and learn why it is being abandoned in favor of ESB architecture. 

 

The Different Levels of Applications Integration

There are four different levels of applications integration. At the presentation level, integration is achieved by presenting several different applications as a single application with a common user interface (UI). Also known as “screen scraping,” this older approach to integration involves using middleware technology to collect the information that a user enters into a web page or some other user interface. Presentation-level integration was previously used to integrate applications that could not otherwise be connected, but applications integration technology has since evolved and become more sophisticated, making this approach less prevalent.
With business process integration, the logical processes required by an enterprise to conduct its business are mapped onto its IT assets, which often reside in different parts of the enterprise and increasingly, the cloud. By identifying individual actions in a workflow and approaching their IT assets as a meta-system (i.e. a system of systems), enterprises can use applications integration to define how individual applications will interact in order to automate crucial business processes, resulting in the faster delivery of goods and services to customers, reduced chances for human error, and lower operational costs. Business process integration thus supports a Service Oriented Architecture (SOA), which promotes the development of composite applications through the use of existing services (i.e. individual units of functionality) within the enterprise.
Aside from business process integration, data integration is also required for successful applications integration. If an application can’t exchange and understand data from another application, inconsistencies can arise and business processes become less efficient. Data integration is achieved by either writing code that enables each application to understand data from other applications in the enterprise or by making use of an intermediate data format that can be interpreted by both sender and receiver applications. The latter approach is preferable over the former since it scales better as enterprise systems grow in size and complexity. In both cases, access, interpretation, and data transformation are important capabilities for successfully integrating data.
Underlying business process and data integration is communications-level integration. This refers to how different applications within an enterprise talk to each other, either through file transfer, request/reply methods, or messaging. In many cases, applications weren’t designed to communicate with each other, requiring technologies for enabling such communication. These include Application Programming Interfaces (API’s), which specify how applications can be called, and connectors that act as intermediaries between applications. At the communications level it is also important to consider the architecture of interactions between applications, which can be integrated according to a point-to-point model, hub-and-spoke approach, or Enterprise Service Bus (ESB).

EAI  refers to the plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications in an enterprise. Typically, an enterprise has existing legacy applications and databases and wants to continue to use them while adding or migrating to a new set of applications that exploit the Internet, e-commerce, extranet, and other new technologies. EAI may involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new model, and then devising ways to efficiently reuse what already exists while adding new applications and data.  More recently the term "Service Oriented Architecture" or "SOA" has been coined to describe a system that maps standards-based interfaces to business functions.  An SOA is a common solution to enterprise application integration challenges.