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.
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.
Figure 1-2 An isolated proprietary application.
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.
Chapter 1 Understanding Enterprise Integration 9
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.
Figure 1-4 Point-to-point management headaches.
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.
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.