Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

F E A T U R E

Force Fit

August 7, 2003
By Don MacVittie

>> continued from previous page

EAI to the Rescue

	Issue TOC
	Print full article
	Print this page
	Download as PDF
	E-Mail this URL
	Discuss this article
	Flame the author

	In this article
	Introduction
	EAI to the Rescue
	People Skills
	Executive Summary
	By the Numbers \| FYI

Now let's see how you'd resolve this problem if you had EAI in your toolbox: The businessperson would still need to determine what process is necessary. But he or she would have a graphical tool--a business process modeler--to draw out the interaction, probably with help from the systems analyst; and a developer or EAI specialist would implement the bottom layer of the system, where data is transferred between the customer-information and order-fulfillment systems. While a developer would still need to write code to accomplish complex integration goals, where systems interact without any human intervention, most simple data transfer or validation would be achievable through a GUI, ultimately saving time and money.

If each system in our typical organization interfaces only with the EAI server, we're down to eight interfaces for four systems--one each to get data from the EAI server and one to send data to the EAI server (see "With EAI" in the illustration below).

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.