Enterprise Application Integration (EAI) Approaches

EAI has developed over time in different phases. At the beginning, enterprises had to implement integration solutions themselves (so called homegrown integration (Busler, 2003)). The reason was that there were no integration products available on the market at that time. Enterprises started integrating their systems by modifying their systems in two different ways (cf. Figure 3-23):

System A

Business and Integration logic

System C

Business and Integration logic System B

Business and Integration logic

– The systems have been modified to call each other synchronously and exchange data at the right moment of processing.

– The systems have been modified to use an intermediate storage, such as a file system or a dedicated database, to store and retrieve data that needed to be exchanged.

Over time, it became clear that these approaches have two main disadvantages. First, the system sending the data had to know about the system receiving the data. This means, that every time when a new system had to be added to or removed from the integration, the system sending the data had to be modified. Second, since systems have not been designed to interoperate, they had to implement data transformation logic themselves.

For example, either the system that sends the data (or stores it at some location) had to transform the data in a format expected by the recipient or the recipient had to transform the data to its format. In this way, the systems had not only to implement the business logic but also to implement and mange the integration logic themselves. Ultimately, such tightly-coupled integration solutions, with no clear separation between business and integration logic became very difficult and expensive to maintain. This created market opportunity for integration products that did not require enterprise information systems to be aware of the integration. In the following, we present the most prominent integration approaches.

Figure 3-23 Homegrown integration

3.1.1 Point-to-Point Integration

In the point-to-point (P2P (Bussler, 2003)), a direct connection has been established between each pair of systems that needed to be integrated (cf.

Figure 3-24).

Integration logic

System A System C

System B

Integration logic In

tegra tion log

ic Business

logic

Business logic

Business logic

The software, implementing the connection, is responsible for extracting data from the first system, transporting them and inserting data into the second system. When necessary, the integration software performs all required data transformations before inserting the data into the recipient system.

While providing basic integration functionality, the P2P approaches have some limitations that are unacceptable in more complex integration scenarios. First, for each new system that needs to be integrated, a new connection has to be added to each existing system part of the integration.

In addition, logic that transforms data from (to) the new system and existing systems has to be specified. Second, more complex data exchange sequences cannot be defined. The reason for that is that connections between the systems are unaware of each other. For example, it is not possible to extract data from two different systems, combine it and then insert it into third system.

3.1.2 Hub-and-spoke

In the hub-and-spoke approach (Bussler, 2003), the communication between different systems has been implemented in a central system, called hub. The hub is responsible for receiving data from every system (called spoke), transforming it in the right format of a recipient system, and then inserting it into it (cf. Figure 3-25).

Figure 3-24 P2P integration

System A

With this approach, the effort to maintain several different connections between enterprise information systems has been notably reduced.

Using a publish/subscribe mechanism, each spoke can provide its requirements to receive specific data. The hub matches the received data against these requirements, identifies the right spoke, transforms the data in the right format, and inserts it into the recipient system. Using publish/subscribe mechanism data from one system can be inserted into multiple destination systems.

The main advantage of hub-and-spoke approach is that adding a new system only requires adding one new connection between the system and the hub. The other systems, that have been already integrated, are not affected by the addition. In addition, new routing rules can be dynamically added to the hub enabling data to be correctly routed to the new system.

While improving on P2P integration approach, hub-and-spoke has some (major) drawbacks. First, it is not possible to implement multistep integration.

For example, the following scenario cannot be achieved by P2P integration approach: a system sends a message to another system; the second system returns a message that has to be forwarded to a third system based on the content of the first message. The reason is that the data in the first message is no longer available. Second, hub-and-spoke provides only a one-way integration. For example, if a system sends a message to request date from another system and the second system responds, the hub does not know that the two messages are related. In this way, implementing even a simple request/response pattern requires definition of complex routing rules.

Finally, the hub-and-spoke approach did not allow for adding additional business logic (such as notification or authorization) between the extraction and inserting of the data.

3.1.3 Process-based Integration

To address the limitations of hub-and-spoke integration approach, the process-based integration approach (Bussler, 2003) has been proposed. This approach extends the hub-and-spoke by adding process management

Figure 3-25 Hub-and-spoke integration

functionalities using a workflow management system (WFMS) (cf. Figure

In this way, instead of directly inserting the data into a recipient system, the hub inserts data into a workflow instance that determines the right way to process the message itself, together with other related messages.

The process-based integration approach supports both multistep integration and addition of custom steps between the extraction/insertion of the data. In fact, the process-based integration solutions are stateful, i.e., each instance of an workflow keeps all received and sent messages and can use this information to construct new messages or execute some processing logic. In this way, more complex business scenarios can be supported. In addition, the integration logic can be specified in a workflow definition, using constructs such as a conditional branching or a parallel execution.

Service-orientation is a promising design paradigm for building process-based integration solution. According to this paradigm different system has knowledge only about how to request and consume services provided by other systems, and has little (or no) knowledge about their internal data structures and processing logic. In this way, integration solutions can be specified using only service description (i.e., without knowledge about the internal implementation of these services) at higher level of abstraction.