Not only is this much more manageable, but you get the added benefit of centralized management to enforce error-reporting and log-generation rules.

Granted, the real world is more complex than this scenario, both in number of systems and number of interfaces per system, but look at how much you stand to gain.

The Business

If your organization is like most, each project team independently creates the systems needed for integration. Every team must spend time addressing integration management issues--time that could be better spent maintaining and enhancing the systems that keep your business running.

The EAI business case follows three basic lines:

1. Centralized management with automated error reporting provides a single place to discover all the system interactions in the organization and a way to help eliminate redundancy.

2. EAI technology allows you to change from interactions between multiple systems to interactions with the EAI server--when a system performs an update, it reports that update to the EAI server, which then propagates changes out to all the systems dependent on this transaction.

3. A dedicated integration staff offloads the time-consuming task of system integration from each project team, allowing teams to focus on making their systems solve business problems, and building teams that specialize in the quality and stability of your integration code.

Level Truths

Like any technology that streamlines a complex process, EAI is far from simple. To be generic enough to work with disparate databases, programming languages, operating systems and even hardware architectures, most EAI products are layered on top of Java, which offers independence from hardware and operating system issues, allowing vendors to focus

on their core apps. IMany vendors use JDBC as a primary database connectivity tool (see "Typical EAI Application" for an overview of an EAI product).

There are now two levels of EAI: conventional, low-level EAI and BPM (business process modeling).

Typical EAI Application click to enlarge

BPM EAI is used to design high-level overviews of system interactions, making broad statements such as, "When an order is fulfilled by the order fulfillment system, that order should be marked as filled in the CIS system." Each statement is then given a specific definition to use with low-level EAI--for example, field names or stored procedures that map from the affected fields in the order-fulfillment system to the target fields in the CIS system.

For conventional EAI, there are two basic architectures--queue-based and message-based. In a queue-based system, changes in one system are placed into a queue by that system and pulled off the queue by any system interested in the changes. In a message-based system, changes in the source system immediately trigger a message that is propagated to the target systems by the EAI server.

Over time, most vendors have implemented hybrids that support both of these models. The queue-based system is often called the "publish/ subscribe" model--a misnomer because most message-based systems also allow for publishing and subscribing. The real difference is in the time needed to deliver the message and reliability if any part of the system goes down.

In a queue-based system, messages placed in the queue are retained until the receiver can deal with them. In a pure message-based system, if the receiver is not available, the message is lost; not surprisingly, pure systems are rarely implemented.