David deLisi
Microsoft Corporation
August 1997
TP development just went nova. . . and the ignition factor in this marketplace is Microsoft's Transaction Server. Ease of development coupled with low prices (by TP standards) have made the TP industry rethink its strategies and schedules. Microsoft's marketing prowess will likely start the mainstreaming of object-oriented transactional technology.
—Norton Greenfeld, Unix Review
Transaction processing (TP) systems are quite literally what make the world run. Every phone call results in a billing transaction. Every time you buy gas, shop at a supermarket, book a flight, check a book out at the library, reserve a theater seat, use an automated teller machine—all day, every day, you participate in transactions.
One of the consequences of the Internet is an increase in the need for transactions. Once you've used a site that exposes transactions directly, nothing is more frustrating than to visit another site that talks about products and services but doesn't let you buy them immediately. So people everywhere are increasingly expecting to complete transactions using their desktop, notebook, or palmtop computer, from their home, car, or office. In the long run, transaction platforms will be as important as operating systems have been.
TP solutions have typically been offered by large hardware vendors with proprietary technology, such as IBM, Sun Microsystems, and Hewlett-Packard. Microsoft offers an alternative called Microsoft Transaction Server, designed for application scalability, security management, easy development and maintenance, and integration of new technologies. Together with the Microsoft Windows NT® operating system and Microsoft SQL Server™ database system, affordable, complex, distributed-transaction processing for companies of any size is now practical.
An application developer must learn to design, implement, and manage such systems to make a successful leap to three-tier applications that span departments, companies, and the Internet. This document provides detailed information about transaction processing and shows the developer how to build applications that are scalable to high-transaction loads.
The pursuit of scalability is taking client/server applications from two- to three-tier architectures, with the middle tier being a transaction processing (TP) monitor. The reality is that this architecture, while easy to implement, does not scale well. Organizations need to move beyond document sharing to running actual business functions online. Instead of simply publishing sales reports and product catalogs, businesses can operate accounting systems and order-entry systems on servers, with users accessing the shared business functions from browsers and desktop systems. This new environment of online solutions will require shared business applications running on servers.
Historically, there has been a problem with this vision. Building and deploying shared applications in this manner is more challenging than deploying them on desktop systems. Server applications require a sophisticated infrastructure that is costly to develop and difficult to maintain. Server applications also need to be more reliable than desktop applications because the impact of system failure or data corruption on a server can effect an entire business, not just a single user. Server applications need to be as easy to deploy and maintain as desktop applications, without requiring special training or a costly infrastructure.
To address these problems, Microsoft has developed Transaction Server—a component-based transaction processing system for developing, deploying, and managing high-performance, scalable, and robust enterprise, Internet, and intranet server applications. Microsoft Transaction Server (MTS) defines an application programming model for developing distributed, component-based applications. It also provides a run-time infrastructure for deploying and managing these applications. When combined with Microsoft SQL Server, Transaction Server provides the easiest way to run scalable, robust applications on the Windows NT Server operating system.
Transaction Server represents a natural convergence of object request brokering and transaction processing monitoring services. With Microsoft Transaction Server, server resources are distributed as objects and their activity monitored—the objects themselves become part of the transaction.
Distributed transaction processing is handled by Microsoft Distributed Transaction Coordinator (MS DTC), which was released in 1996 as part of SQL Server version 6.5. Basically the two-phase commit protocol states that there is a prepare phase and a commit phase to the transaction. The DTC notifies each resource manager (such as SQL Server) enlisted in a given transaction to prepare to commit. In this step, the resource manager must be sure that the commit will proceed and report back to the DTC success or failure. After all resource managers have reported, the DTC tells all to either Commit or Abort. If all reported back success and there are no other determinants, then it tells all to Commit. If any reported that the prepare failed or some other determinant failed, the DTC tells all to Abort.
Microsoft Transaction Server, SQL Server, and MS DTC work together for optimal transaction processing. Requests for objects are received using DCOM. MTS processes the requests, allocates server resources and begins an MS DTC transaction. It then hands this object back to the client. MTS sits between the object and the client monitoring everything that the client does. By doing this, it is acting as a TP monitor and, as a result, can perform the duties of the TP monitor. It can schedule requests, pool resources during idle time, and so on, automatically. When the client is finished with the object, it releases the object, which causes MTS to complete the transaction and free or pool the resources.
Building and deploying a networked server solution is no easy task. Implementing the actual business function (for example, handling online orders) is just one part of the process. As more users access a shared system, the threat to data integrity and system reliability increases. Because these problems become harder to solve in a distributed environment, businesses have been willing to pay a premium, using proprietary, high-end technologies to ensure that their solutions are built to operate under mission-critical situations. This sophisticated application infrastructure enables the business function to be shared by a large number of users. Server infrastructure, or plumbing, includes:
Creating this infrastructure in an application is expensive and has traditionally been a barrier for many organizations. Independent software vendors (ISVs) estimate server plumbing consumes 30 to 40 percent of their development costs. This applies across a broad spectrum of applications, from large warehouse-management applications to small systems used to manage a doctor's office. Microsoft SQL Server and Transaction Server solve these problems.
This document describes transaction processing and how to implement it, including how Transaction Server delivers low-cost server development, mainframe-class reliability, more deployment choices, and easy management. It explains how to build applications for Microsoft Transaction Server and SQL Server.