Why a New Layer?

Traditional middleware such as MOM (message-queuing software and pub/sub engines) solves only part of the application integration problem. Integration servers, by building on top of existing middleware technology, address the other part. This makes integration servers the "middleware of middleware" (see Figure 9.1).

Figure 9.1. Integration servers can integrate many different types of middleware, as well as applications and databases.

An effective application integration solution contains a number of components that are neither middleware nor applications, but are routing, reformatting, and flow components. Although these components may be placed in an application or middleware, they are a better architectural fit when they are placed in integration servers, providing a central point of integration.

Given all this, exactly what do integration servers offer? As with any new technology, vendors took individual approaches to define products that address the integration server problem. Despite this lack of standardization, integration servers share some common components a transformation layer, a rules engine, and an intelligent routing mechanism, as well as a number of features we will discuss later in this chapter.

The three primary components of integration servers are the transformation layer, the rules engine, and the intelligent routing mechanism.

An integration server is a software system based on asynchronous, store-and-forward messaging. It works simply to manage interactions between applications and other information resources, using abstraction techniques an application puts (publishes) a message to the integration server. Another application, or applications, consumes (subscribes to) the message (see Figure 9.2).

Figure 9.2. Integration servers publish and consume information to provide information flow between applications.

The application does not need to be session connected in order to work successfully. This eliminates, from the outset, the primary scalability problem associated with most integration technologies. Target systems need not be active. They can receive the information at some future time when they become active.

Integration servers do much more than simply function asynchronously. They extend the basic messaging paradigm by mediating the interaction between the applications, allowing the source and target systems to remain truly anonymous. They also translate and convert data, reformat and reconstitute information, and route information to any number of targets (determined by centrally defined business rules that are applied to the message content). They can do this one-to-one, one-to-many, or many-to-many (see Figure 9.3).

Figure 9.3. Integration brokers can send and receive information from any number of systems, one-to-one, one-to-many, or many-to-many.

To be the solid foundation for a successful application integration strategy, integration servers must offer genuine any-to-any and many-to-many capabilities.

As you might expect, because of the individual approaches vendors take to solve the integration broker problem, not all integration servers are alike. A complete integration-brokering solution demands an underlying messaging system, a brokering layer (or rules engine), a connectivity (adapter) framework, design and development tools, and system management and administration tools. A handful of products currently on the market provide many pieces of the puzzle, but none provide the entire puzzle. A systems integrator is often needed to combine those pieces with the other pieces that are necessary to complete the puzzle.

The success of the finished "picture" depends on the design and architecture of the solution how well the pieces integrate. This is what determines their scalability. IS organizations need to be thorough about "kicking the tires" to make certain they select the right solution for their application integration initiative.

Integration servers are different from traditional middleware because of the services they offer above and beyond such products. They certainly use information. Still, it's difficult to fit them into the MOM category. In addition to relying on the concept of a message, they provide value-added services from the uppermost layer in the ISO model, the application layer.