Then the client/server cultural revolution exploded. The ramparts of the data center were breach ed and control shifted to the desktop. Relational database management system (RDBMS) vendors proclaimed the virtues of two-tier architecture. Inexpensive desktop PCs had the computing power of first-generation mainframes and offered intuitive GUIs, so why not combine presentation and business logic? Not only were the MIPS cheaper, but replicating the application out to thousands of desktops enabled the simplest form of parallel processing. Now, application programmers could employ easy-to-use, but inefficient, languages like Visual Basic (VB) and PowerBuilder (PB), to write simple, single-user, single-threaded, applications relying on the implicit multitasking of thousands of desktop CPUs for scalability.

The only problem was it didn't scale. The thousands of desktop-based applications pounded RDBMS servers with thousands of chatty dynamic SQL requests, which not only stressed the server to its limits, but also congested LANs and completely choked WANs and dial-up l inks. So RDBMS vendors came up with TP-l ite: Move some of the business logic off the desktop back to the server--but don't put it back into TP monitors, put it into the RDBMS as stored procedures.

The TP Wars Thus began the TP-lite versus TP-heavy wars. RDBMS vendors delighted in pointing out the expense and complexity of TP-heavy. In response, Unix-based TP monitors came forth: BEA Systems' TUXEDO, Digital Equipment's ACMSxp, IBM's Encina, NCR's Top End and UniKix Technologies' UniKix. But even Unix-based TP-heavy was unpopular for all but the largest, most mission-critical applications.

TP-heavy was not popular because there was no way to ease into TP-heavy from TP-lite. You had to throw out your VB and PB code and start from scratch. You had to partition presentation from business logic again and give up the single-user, single-threaded programming model. Finally, everyone assumed (thanks to RDBMS vendor FUD) that you needed a TP monitor if, and only if, you needed heterogeneous two-phase commit--the ability to synchronize updates across two or more databases from different vendors. How many applications need that?

But TP monitors are much more than two-phase commit. They provide two other distinct types of services essential to building scalable distributed applications. First, they offer robust and efficient communication services between clients and servers and between one server and another. This enables applications to run efficiently over low-speed, high-latency WANs, including the Internet. Second, they offer server-based execution environments that handle the low-level multitasking, connection and state management plumbing that enables user-written services to efficiently handle thousands of client requests.

The Transaction Server Renaissance Then the Internet counterrevolution hit. The browser became the next-generation thin client. The bourgeois, two-tier, TP-lite applications, with their intractable fat-client deployment requirements and excessive network and server resource appetites, were publicly criticiz ed and sent to re-education camps. Into the temporary power vacuum swept Web servers, Common Gateway Interfaces and Perl. Although some tried to palm off these academic lightweights as three-tiered, it soon became evident that first-generation Web architectures did not scale. The time was right for the renaissance of TP monitors.

And guess who was leading the way? That great assimilator of other people's ideas--Microsoft. A few years ago, Microsoft hired some of the best and brightest minds in transaction processing, including Jim Gray, who literally wrote the book on it, and set them to work on a next-generation TP monitor. The result was Microsoft Transaction Server (MTS). Released in January, MTS addresses most of the traditional knocks against TP monitors.