Enterprise Integration Solutions

8 Part I Enterprise Integration Overview

Choosing to integrate by using an Enterprise Application Integration (EAI)

product or platform such as Microsoft BizTalk Server comes with a unique set

of assumptions that might not be immediately clear to the client. (EAI is the

technique used to connect systems internally and externally through the use of

interfaces.) A simple exploration of the evolution of integration technologies

and methods will help you to understand some of these assumptions.

The Evolution of EI

Those who cannot remember the past are condemned to repeat it.

—George Santayana

There was a time when the only people in an organization who had any

software to speak of were the accountants. With the advent of the PC, software

became more and more commonplace, and companies began to build and use

business applications. Most of these applications were completely self-con-

tained and stored their data in their own binary file format. These applications

were proprietary, and in many cases, they had no method of communicating

with users and other applications. Apart from the user interface, users had no

way to see what the application was doing. Figure 1-2 shows an example of

such an application.

F01LS02

Figure 1-2 An isolated proprietary application.

Point-to-Point Integration

Soon companies began to feel the pain of upgrading or replacing these applica-

tions, and the ability to share data among applications became desirable. This led

to open database standards and APIs, and the first real opportunities for applica-

tion integration. Developers could now use these APIs and connection points to

integrate (or at least pull the data from) applications, as Figure 1-3 shows.

Application

?

UI

Chapter 1 Understanding Enterprise Integration 9

F01LS03

Figure 1-3 Early integration using APIs or databases.

This approach worked well for a while. Each time a company needed to

share data between applications, it would simply add a new piece of code or

database view, until the number of applications and integration points eventu-

ally made managing the integration nearly impossible. Applications became so

tightly integrated that a small change to one piece of code led to a complex

chain of additional changes just to preserve the integration, making the whole

process extremely fragile and expensive. Organizations soon found themselves

trapped in a giant spider web of point-to-point integrations, praying that their

latest change would not bring the whole system down. Figure 1-4 shows how

quickly such integration could become unmanageable.

F01LS04

Figure 1-4 Point-to-point management headaches.

Application

?

UI

API

Data

Application

?

UI

API

Data

Application Application

ApplicationApplication

ApplicationApplication

10 Part I Enterprise Integration Overview

Hub and Spoke Solutions

The next step in the evolution of integration was the introduction of the hub

and spoke—a modified version of point-to-point integration, where a central

hub is responsible for routing the data being passed between applications. This

approach, which Figure 1-5 illustrates, was a good attempt to solve the prob-

lems created by complex point-to-point methods.

F01LS05

Figure 1-5 The hub and spoke approach.

Though the hub and spoke method certainly eased the configuration and

management issues inherent in a point-to-point solution, significant problems

still had to be overcome. First, all these methods were one-offs in which each

new requirement meant a new chain of code between applications. Even with

hub and spoke solutions, the hub needed modifications to route the new data.

Second, most of the data being moved around was initiated with either a batch

or a polling operation, making it very inefficient.

The Publish/Subscribe Method

Another method known as publish/subscribe, which made extensive use of

messaging, would solve the first issue. In this approach, applications placed

messages on the bus (publish), and any other application could choose to

receive those messages (subscribe). The sender and receiver did not need to be

aware of each other. This also allowed the sender to reach more than one

receiver at a time, with a single message removing many of the barriers of

point-to-point solutions. Figure 1-6 depicts the publish/subscribe method.

Application Application

ApplicationApplication

Integration

Hub

ApplicationApplication