Microsoft Transaction Server (MTS) has been available for Windows NT since 1996. Its name and evolution indicate that it is mainly a transaction-processing (TP) system. But the fact is that professional Windows developers have exploited MTS more for its ability to manage Component Object Model (COM) objects in Web applications and in similar client/server environments. The MTS framework provides a whole range of application services and is a pivotal element of Microsoft’s Distributed interNet Architecture (DNA). And, by the way, it is an equally capable, if somewhat nontraditional, TP system. In this article, I will show you how MTS-distributed transactions can, in certain cases, span more than one database. This article is for those who are somewhat familiar with COM, TP, and security issues.

Component Services

Anyone who has implemented an Active Server Pages (ASP) application running on Internet Information Server (IIS) Version 4.0 has, whether he knows it or not, used the component services provided by MTS. In this version of IIS, MTS is fully integrated; IIS won’t work without it. Even the simplest ASP applications use system components hosted by MTS. MTS is as a component host platform, providing access to COM and ActiveX objects in client/server application domains, such as ASP. MTS acts as a surrogate, comprising the runtime environment for the component objects used by external agents, such as IIS and ASP.

But wait a minute. Isn’t one of the “big ideas” about COM that it’s a binary standard for components that allows you to create objects that can run in any COM environment? If so, why introduce MTS, a “middleman” runtime environment that could only harm the performance of the application? The payback is the management features that MTS provides. You can use MTS facilities to control which agents have authority over your components. You can force components to run under a particular user profile. And, yes, you can, with the help of the Microsoft Distributed Transaction Coordinator (DTC), set up database transaction boundaries in your applications. With the MTS Explorer tool, sets of components, or “packages,” can be installed in MTS to share runtime attributes. Finally, most of these runtime attributes are under the control of an on-site administrator

(and are defaulted by the programmer), so the application can easily be adapted to certain real-world conditions.

Name Game

MTS is part of the Windows NT Server 4.0 Option Pack, which is freely downloadable from Microsoft. It is also installed with the newer releases of IIS. In the Windows 2000 release (formerly Windows NT 5.0), Microsoft decided to bundle MTS as part of the operating system and change its name. MTS has become COM+ Services, but the theory of operation and most of the tools are basically the same as NT’s MTS. This article discusses their common features in terms of the MTS version of component management services as distributed in the Option Pack. The underlying concepts of COM+ Services are identical to MTS, but some of the management tools may be slightly different in their approach. MTS component programmers needn’t worry much about the name change, either, since the MTS interfaces are completely compatible and will allow their component objects to run on both the Windows 2000 and the Windows NT platforms.

The NT Option Pack can be installed on any Windows NT 4.0 system, and it contains IIS and MTS as well as other related system add-ons, such as Microsoft Message Queue Server (MMQS). When installing the Option Pack, select Custom installation, then the Internet Service Manager, and, finally, Transaction Server Explorer to make sure these tools are installed. If you have a recent version of IIS installed on your Windows NT 4.0 Server machine, you may not need to install the Option Pack, because MTS and the other tools will have already been installed as part of the IIS upgrade. As mentioned previously, Windows 2000 comes with the equivalent COM+ Services already installed. Windows 95/98 users can play, too: MTS and Personal Web Server (a scaled-down version of IIS) can be installed on these platforms with the NT 4.0 Option Pack. Note that, on Windows 95, Distributed COM (DCOM) support (also a free OS enhancement available from Microsoft at www. microsoft.com/com) must be installed before MTS.

MTS Transaction Processing

MTS provides the TP framework for components, but it has a lot of help. MTS cannot, by itself, provide the traditional commit and rollback functions associated with TP; these functions must be provided by the database management system (DBMS), or data source, in use by a component object running in MTS. So why not just use the data source’s TP functionality directly? The beauty of MTS transactions is that they may be transparently distributed over more than one component object and over more than one underlying data source. You can use MTS to coordinate a transaction encompassing several component instances simultaneously, some or all of which may be using a different database or database connection.

Traditionally, TP environments have consisted of ad hoc, proprietary solutions. They usually consist of APIs or commands called to initialize and shut down the environment, in addition to the commit and rollback APIs or commands. These work great if you are accessing a single database. In a world where data is increasingly distributed, application data may come from several different sources. Distributed transaction processing and the “two-phase commit” protocol involve the coordination of the TP environments of each data source taking part in the transaction. Two-phase commit ensures that transactions applied to more than one data source are complete on all data sources or none at all. This can be accomplished with a lot of DBMS manuals and some advanced application programming or more easily with system “middleware” designed to facilitate a solution.

MTS and DTC dramatically reduce the effort involved in maintaining TP environments on separate data sources by consolidating transactions in the MTS context. So even if you only use one data source now, it may be worth the effort to investigate using MTS TP; in some cases, it may even be simpler than using the proprietary TP

environment. Another reason to consider using MTS for distributed TP is that it is an integral part of IIS. Transaction-oriented Web applications may be designed using Active Server Pages with your modular business logic contained in COM components.

Distributed Transaction Coordinator

The DTC is a Windows NT service. Its sole purpose is to coordinate transactions encompassing separate data sources. It “holds” the transaction context for one or more data sources being accessed by one or more component objects. While the component programmer uses only one transaction context, the MTS transaction context, DTC juggles separate transaction contexts for each data source being accessed by an object. For DTC to manage the transaction context of a particular data source, it must be able to access that transaction context in a uniform way. The data source provider implements so-called Resource Manager functions in its ODBC or OLE DB driver implementation. Most OLE DB provider implementations include a Resource Manager for participating in DTC. DTC communicates with Resource Managers via the XA protocol, a standard for distributed TP developed by The Open Group vendor consortium, or the OLE Transactions COM interfaces. In either case, the Resource Manager and DTC may run on either one machine or separate networked computers. Figure 1 (page 103) shows an example scenario where the relationship between two data sources (in this case, SQL Server and IBM AS/400 databases) is DTC and an application.

DTC is closely integrated with MTS. MTS facilities discussed in the next section allow component objects running in MTS to exploit the features of DTC in a very simple, configurable way.

Components for MTS Transactions

Component objects running in MTS have a runtime context. This context can be thought of as a “session” that encompasses the lifetime of the object and provides access to the resources of the environment. A component object running in MTS obtains a reference to its object context via the MTS “global” method GetObjectContext. The object reference returned by GetObjectContext implements the IObjectContext interface. This interface includes methods resembling the traditional commit and rollback functions, named SetComplete and SetAbort. The component object participating in a transaction may call SetComplete when it has successfully completed its operation. This notifies MTS that, as far as the object is concerned, it completed its operations successfully and any changes to the data sources accessed may be committed. In the opposite case, SetAbort is called when MTS is to be notified that things didn’t work out, and the transaction should be aborted. Note that these methods indicate a transaction boundary only within the component instance. An MTS transaction may encompass more than one component object.

Other than these and a few other IObjectContext method calls, the object participating in an MTS transaction need not have any awareness of the transaction context. Normal database access using Microsoft ADO and other mechanisms will be protected by the transaction, provided the data sources being used implement the Resource Manager functions. Direct ODBC access can also be protected with MTS transactions with some restrictions.

Initiating a Transaction

MTS transactions come in two flavors: automatic and “client-initiated.” The TransactionContext object may be used to manually create a new transaction. The MTS application (the client) instantiates the TransactionContext object and then uses the CreateInstance method to create the application’s component instances. These new components (and any components they subsequently create) will participate in the transaction denoted by the originating TransactionContext object. When the transaction is complete, the application will call the TransactionContext object’s Abort or Commit method

to end the transaction. Abort will roll back all the database work of the objects participating in the transaction. Commit confirms the changes if none of the components have called the SetAbort or DisableCommit method of their ObjectContext object. Client-initiated transactions offer the programmer the most control over transaction timing.

Automatic transactions are initiated by the MTS runtime when a component that has been marked as requiring a transaction is instantiated. As shown in Figure 2 (page 103), a component installed in MTS has a Transaction support property. This property has four possible values:

• Requires a transaction
• Requires a new transaction
• Supports transactions
• Does not support transactions

These values tell MTS how to handle transaction contexts when creating a new component instance. If a component instance Requires a transaction but is created by a different component instance not participating in a transaction, a transaction is automatically created for it to run in. If the instance is created by a different component instance already participating in a transaction, it, too, will participate in the transaction. So, regardless of the state before the object’s creation, MTS ensures that it runs in a transaction context. Similarly guaranteed are components marked as Requires a new transaction, except that MTS always creates a new transaction context for the new instance, regardless of whether or not the parent component is already participating in a transaction. Supports transactions indicates that the component will participate in the transaction only if one exists when it is created. By default, components are installed in MTS with the Does not support transactions property, indicating that the component will not participate in transactions.

An automatic transaction is complete when the object that caused its creation calls SetComplete or SetAbort. Note that calling these methods from other objects participating in the transaction does not end the transaction immediately, but such calls do affect the eventual outcome. Success must win a unanimous vote; if any component object in the transaction calls SetAbort, the transaction is doomed to failure, delayed only by the final SetComplete or SetAbort call of the transaction’s “parent” object.

Although automatic transactions reduce the burden of the application to support transactions, the sequence of component object creation must be carefully considered to avoid unnecessary nested transactions. Because the application programmer is subject to the rules of automatic transactions whether or not client-initiated transactions are being used, it may reduce the complexity of a program to refrain from using client-initiated transactions.

Initiating Transactions in ASP Pages

Finally, ASP scripts may control the creation of a transaction for the components instantiated within the script by using a directive in the “@” tag of the script. This tag usually only designates the language interpreter for the script. However, it can also designate the transaction property of the page as in the following:

<%@ LANGUAGE=VBScript TRANSACTION=Requires_New %>

The TRANSACTION property value may be one of the usual four values: Required, Requires_New, Supported, or Not_Supported. Because a transaction initiated with this tag is under the control of ASP, event subroutines such as the following are the only methods of observing the result of the transaction. This allows the ASP script programmer to tailor responses to the user based on the success or failure of a page transaction. These subroutines would be placed in the same script as the above tag:

<%

Sub OnTransactionCommit()

Response.Write “

Transaction committed!

Sub OnTransactionAbort()

Response.Write “

Transaction aborted!

Consistency Control

Another pair of interesting methods of the ObjectContext object are DisableCommit and EnableCommit. A component instance participating in a transaction uses these to maintain control during critical operations. DisableCommit is called to force any subsequent attempts to commit the transaction, by itself or by any other component or mechanism, to fail. For example, a multiple-record update could leave the data in an inconsistent state if failure occurs during the update. It is prudent, especially in a multithreaded application, to protect such a sequence of code with these methods as shown in this VB snippet:

Dim objContext As ObjectContext
Set objContext = GetObjectContext()
objContext.DisableCommit
‘ Code to perform critical data source update here...
‘ Commitment attempts will fail until the next line.
objContext.EnableCommit

Not Such an Odd Name After All

So MTS really is about transaction processing, at least partially. The TP features you’ve seen here allow all three levels of Web application development to shape a useful transaction strategy. The component programmer may use client-initiated transactions and the transaction context to establish and manipulate transactions. Alternatively, automatic transactions can be influenced by the ASP scriptwriter, with the TRANSACTION= tag and the page-level event subroutines. In addition, the MTS administrator may choose which components should and should not participate in transactions and observe transaction progress using the MTS Explorer tool. You’ve also seen how the powerful MTS/DTC combination simplifies the implementation of single-transaction-protected access to more than one database (even the databases of different vendors!). Try that with your proprietary TP solutions. The true utility of MTS, however, is its intelligent integration of several related database and distributed component programming features, including TP.

References and Related Materials

• “IBM DB2 products deliver support for Microsoft Transaction Server”: www.ibm.com/software/data/db2/db2tech/db2mts.htm

• Microsoft COM Web site: www.microsoft.com/com

• Microsoft Windows NT Server download page: www.microsoft.com/NTServer/all/downloads.asp

• MSDN online Web Workshop—Server Technologies: msdn.microsoft.com/asp

• Professional MTS and MSMQ Programming with VB and ASP. Alex Homer and David Sussman. Chicago, Illinois: Wrox Press Inc., 1998

Resource

Manager (SQL Server)

SQL Server AS/400

Context Object

Client Application (ASP Script, Windows Program) Component

ADO/OLE DB DTC

MTS

Resource

Manager (IBM DB2 Connect IEE)

Transaction Control Data Flow

Figure 1: Microsoft DTC allows an application transaction to be a distributed transaction, consolidating the transaction capabilities of more than one data source.

Figure 2: The MTS Explorer tool allows you to examine a component’s various properties.