A vast array of technologies can be used for application integration—including distributed objects, distributed databases, distributed transactions, and message queuing. In the past, technologies that could participate in integration have been lumped together under the title "middleware." The problem with this term is that the different technologies have very different characteristics and capabilities. Grouping them all together as middleware disregards these differences and implies some equivalence that does not exist. Using the same term tends to imply that it doesn't much matter which middleware a customer chooses because all products provide basically the same set of functions. However, nothing could be further from the truth.
There's a historical reason for this muddled thinking about middleware. During the height of the client/server revolution of the late 1980s and early 1990s, many vendors added distributed capabilities to their existing products. Each vendor added these capabilities in ways that made sense to its product's programming model. Transaction manager products got distributed transactions that were capable of spanning machines. Database products got distributed database capabilities that allowed access from remote systems. Object technologies gained distributed objects that could be accessed from other machines. In many cases, standards bodies worked with vendors to provide at least some level of common definitions that would allow different products in a given category to work together.
But even so, different kinds of middleware have completely different ways of dealing with distribution. Applications that use one type of middleware cannot easily be converted to use a different kind. Different sorts of middleware provide very different capabilities, but there is often considerable overlap if multiple technologies are used together, for example. In the past, this has proven to be an intractable problem for customers who are trying to select combinations of integration products in order to satisfy a specific need.
What we really need is a classification scheme so that we can position these various technologies and describe their contribution to eAI solutions. Only then will we be able to compare integration products fairly, even though they are built on very different technology bases. We'll look at this scheme in the next section.