Enterprise application integration (EAI)

The enterprise application integration (EAI) is a middleware architecture that allows disparate applications to manage their exchanges. It is placed into the information technology category of business integration and urbanization. Its particularity is to exchange data in pseudo real time.

By extension, the acronym EAI means a computer system for performing this architecture by implementing interapplication flow of information system.

Components

A EAI platform consists of several elements:

Connectors for the interface between the EAI and applications. They scrutinize the application events and transmit the data associated to the EAI (or provide to the application the data from the IAE). This data is called application specific business objects (ASBO) as they reflect the application data (field name, format …).
ASBO from (or directed to) connectors go through a correspondence or mapping up operation to convert application-specific data (ASBO) in standard data at EAI: business objects (BO).
BO then reflect the overall data information model from the various business processes. They are then transmitted to treatment called collaborations that reflect the processing logic to be applied to a BO before transmitting it to a target application (complete information by looking in another application, check the validity of the business process …) .
A transport layer: it is the layer which is used to route data between applications. This layer can be implemented by exchanging files (eg using FTP), for message exchange (eg using MOM, JMS or Jabber / XMPP) or per call services (for example, using SOAP over HTTP).

Operation example

To understand how, we can present the following example: An order management application A creates a new section (a pump) and she wants to make it available to application B following technical defects of this article and an application C that displays the article on a web portal.

The application A creates a new section in its database. An automatic processing (trigger) captures this event and the archive into an event table with the associated data (new section).
A connector IAE JDBC (database) scans this table every ten seconds and discover this new event. It then retrieves the data associated and copying in a ABSO by associating a verb (created).
ABSO then passes through a mapping phase to convert the data of the new article (specific to application A) in a generic BO reflecting all the information necessary for the company to represent an item.
The business object Article is expected (recorded) by two collaborations (C1 and C2). The first recover BO, analysis the verb (created) and sends BO in creation to application B (This BO is reset in correspondence to obtain a ABSO article for B and is processed by the B connector making creation). At the same time, the second C2 collaboration retrieves the original BO and sends it to create the C application (mapping, connector C).

Advantages and disadvantages

Advantages :

Centralized flow before the arrival of the EAI, companies had to develop specific interfaces for each application and connect point to point. It resulted in a complex network (spaghetti) flows, difficult to maintain and evolve. Now all EAI interfaces converge on a central server (hub) that processes and distributes flow to the registered applications.
Treated flow “over the water”: the data updates are carried out over the water, that is to say during the events of source application. This reduces the data flow during transfer and offers a particular “update” shortly after its change. This also reduces the loss of performance of applications due to the extraction or update of data because it only deals with small waves and spread over time.
Reusable flow: if a new application wants access to BO already in the EAI, the whole logic of recovery is no longer to develop. In theory it needs to add to EAI concentrator only its collaboration (if it needs a specific treatment), its ABSO, its mappings and its connector.
Interfaces migration cost: when changing from one of interfaced applications (migration, product change), few changes are needed. Only the connector, mapping or specific collaborative application must be changed.

Disadvantages:

Massive flow: for massive flows (eg update 10,000 items at the same time), the logic of the single information processing is very slow. We prefer instead a ETL solution.
Initial cost: the cost of setting up the infrastructure is quite high. But it is greatly reduced as and when adding new flow.
Resynchronization of the bases: following an incident (application bug, operating error, disk damage, …) or the enrichment of data structures, you must resynchronize the databases where the data is copied with that where the data are in reference. This is unfortunately almost certain, even quite common. A special procedure of resynchronization is usually needed. She works on static data that can be bulky and not on events. A functional study is imperative. It often add resynchronization data in databases (reconciliation username, date-time of last update …). In fact, you must double EAI closest features to those of an ETL. Before proposing an update over the water, it should start by studying the resynchronization process. It is common to be sufficient to meet the need. Otherwise architect’s genius must speak to find a modular solution and avoid duplication of business rules between the two tools. It is often sufficient to replicate, for example every four hours changed data the last five days. Five day period limits the volume. The period of recovery allows, when the procedure goes wrong, or when the source database is restored or repaired, to automatically restore consistency in the next run. The same procedure is used to realign the entire data by varying the period. Thus, replication rules are all in the same tool.

EAI in company

The establishment of an EAI requires a willingness to unify the integration of enterprise information systems. An urbanization phase of study will lead to:

identify most of the company’s business data (eg articles, orders, suppliers, clients …)
define which applications will be teachers, for example:
- The supplier management application will be master of supplier data.
- It will disseminate via the EAI other applications that can be used as reference data provider.

These data will be represented in EAI in the form of business object (BO).

We can then build business information flows unified by which each specific application can share information with others in a stage of the business organization.

For example :

The purchasing department has set providers that will identify items used by the production department.
This production facility will build the products sold to customers by the sales department.
The said clients will be followed by the after sales service …

IAE appears as an integration solution relevant only within a complex infrastructure for data exchange. EAI use to connect two very simple systems would be as relevant as handle an anvil to remove a nut from its shell.

It is noted that a new technology seems to be set up against the EAI: the enterprise service bus (ESB).

Translated from Wikipedia