Middleware: The kind of word that software industry insiders love to spew. Vague enough to mean just about any software program that functions as a link between two other programs, such as a Web server and a database program. Middleware also has a more specific meaning as a program that exists between a "network" and an "application" and carries out such tasks as authentication. But middleware functionality is often incorporated in application or network software, so precise definitions can get all messy. Avoid using at all costs.

Middleware is plumbing.

There are four ways that this is true.

First, it's mostly invisible.

You don't generally see much of the plumbing in your house. What you see is the water. As a consumer, you don't see middleware. You see the web sites and the information flow that middleware makes possible. This is part of why middleware is hard to define. If you live and work with software, and if you're reading this you probably do, then you're very aware of software packages at the top level in a logical view, such as e-commerce web applications, and packages that exist at the bottom level, such as databases and the operating system. The middle part, that plumbing that ties everything together, can seem less concrete and identifiable.

Second, as a developer, you rely on middleware to provide a standard way of doing things.

If you wanted to build your own plumbing from scratch, you could. But it's much easier to just buy plumbing fixtures. You, as a software developer, could design and build your own application servers, database connection drivers, authentication handlers, messaging systems, etc. But these wouldn't be easy to build and maintain. It's much easier to make use of middleware components that are built according to established (and especially open!) standards. In middleware, these standards take the form of libraries of functions that your applications use through well-defined application programming interfaces (APIs). You call these functions instead of having to invent your own to handle tasks such as accessing databases or executing transactions.

Third, it ties together parts of complex systems.

There's another similarity about your household plumbing and middleware; tying systems together. They both enable you to tie together systems that were built by different people, at different times, without your having to reconstruct everything from scratch. Think about your house for a minute. If your house is older, you probably have several generations of plumbing all working together. You didn't have to upgrade your washing machine with multiple service packs when you installed a new hot water heater. In middleware, one of the most powerful approaches is Service-oriented Architecture (SOA) based on an Enterprise Service Bus (ESB). As its name implies, an ESB provides a server, messaging, and APIs that function like a hardware bus. In order to integrate enterprise software applications developed at different times, by different organizations, and even communicating via different protocols, you don't have to rewrite them to speak one consistent language. The ESB enables you to "plug" these applications as services into the bus. The ESB takes care of transforming messages between the protocols and routing the messages to the correct services.

Fourth and finally, it lets you worry about other things.

When you put an addition onto a house, what do you worry about? Bathroom fixtures, kitchen appliances, flooring, colors, and how to pay for it all. It's a very stressful process. The last thing you want to worry about is whether you want 3/4-inch or half-inch pipe, copper or PVC connectors, #9 or #17 solder, etc. With middleware taking care of all the invisible functions, you, as a software developer, can concentrate on building software to solve your business problems and fulfill your customers' needs.