When I was a kid, I loved to put things together. I especially liked building things with LEGO. Never mind the TV, dump a huge pile of LEGO blocks in front of me and I'd be quiet for hours, building a LEGO version of the Eiffel Tower, or some other construct that only a kid could imagine.

One of the things that made it possible for me to test the limits of LEGO architectural stability was the fact that it had all been designed to work together. Every LEGO piece was created with the sole intention of fitting together with another block of LEGO. Didn't matter what color the blocks were, how high, or what shape, they all worked.

Unfortunately, in the IT world software isn't quite LEGO. It doesn't have the advantage of all coming from a single vendor, and even in the more limited cases when it does, it frequently isn't designed to work together. Sometimes it can be like trying to make the LEGO fit to some of those cheap imitation blocks that value price stores try to sell you - a painful proposition, but sometimes it worked. Sometimes it can be like trying to build with LEGO and an Erector set; both are good tools, but neither fits the other's idea of how to put the world together.

Enterprise application integration (EAI) is a software approach to solving this problem. Much like the approach you might take to making LEGO and the Erector set work together, EAI serves as the glue between applications.

It also solves the input impedance problem. Take three systems. If you wire them each to work with the others, you have three times three, or nine adapters to write. If you add a fourth system, you end up with sixteen, and so on. EAI, by acting as a bus on which communication takes place, reduces that number to one adapter per system, vastly reducing the complexity of application integration.

EAI also offers the ability to manage aggregation of software into a higher-level business service. This is not a trivial task, as it requires coordination of transactions, systems, and a mechanism for compensating transactions for the cases where a transaction must be rolled back. The value of this capability is enormous. Many organizations have a heavy investment in technologies that they cannot or will not modify for strategic reasons. Their business processes, on the other hand, change and grow dynamically, and as new software becomes available, parts of functionality tend to migrate from one application to another.

Take, for example, the definition of a "customer." Typically this information resides in a system of record. But when you add a CRM application, and allow for Web-based self-registration, the location of the customer information may migrate from the existing legacy system into the CRM system. But the old system still needs the information. EAI helps solve this problem.

Web services has become the next step in the evolution of EAI. While it is easy to believe the concept that Web services provides all you need for EAI, it's not really the case. UDDI, WSDL, XML, and SOAP provide the basic underpinning of application cross-communication, that's very true. But the real value added by EAI is not just in the plumbing, it's in the management of services as they are needed across the enterprise bus. While Web services standards such as WS-Orchestration are designed to address parts of this issue, it's clear that EAI already has a large head start in that area, and will be well positioned to take advantage of those specifications.

This issue focuses on Web services and EAI - how to use them, how they impact each other, and how they complement each other. Kind of like LEGO and the Erector set: once you can get them to work together, you can accomplish amazing things. Now where did I put my glue gun?