A Closer Look at MTS

Microsoft Transaction Server (MTS) is Microsoft's key enterprise technology with which it hopes to gain a larger segment of the lucrative middle to large corporate computing market. This paper examines the components of MTS and how they address the challenges the TPM are traditionally designed to meet.

Those in the know, by the way, sometimes call MTS by its old internal but much leaked codename, Viper. Other pages on this site sometimes refer to it as such.

ODBC, Transactions and Resource Dispensing

The main database thrust in MTS is the use of Open Database Connect (ODBC). ODBC is Microsoft's mechanism to provide database connectivity, usually remotely, and has thus long been part of Microsoft's Client/Server Two Tier strategy as well as offerings. Most large Database vendors offer an ODBC and there are several independents software firms about with products in this market too.

ODBC provides a familiar SQL interface, but in a procedural form. In Two Tier Client/Server the SQL flows and data returns over medium speed local area networks with low latency (such as Ethernet). With MTS some modifications have been made to ODBC. It has acquired the necessary API to support a Two Phase Commit protocol and thus the ability to support distributed Transactions. It has also acquired something called connection pooling. Traditionally, just as with native SQL programs, ODBC programs would connect to a Database, do work and then disconnect. The connection and disconnection is a high cost business and a major obstacle to scaling. As we have seen other TPM have provided a mechanism where the business logic, encapsulated in a service remains constantly connected to the Database. In the new ODBC the connections are maintained with the Database too and ODBC presents a pool of available connections to potential applications. The size of this pool is dynamic, with little used connections being shut down and new connections being acquired on demand, should the current pool be inadequate.

Microsoft have coined a new term for ODBC in this rôle. It is now a Resource Dispenser.

OLE Transactions

Object Linking and Embedding (OLE) Transactions are Microsoft's native alternative to the XA standard as the preferred mechanism to manage Transactions on Resource Managers (the transaction interface between ODBC and the Database). MTS does however support XA and Microsoft have provided XA interfaces to both MS SQL Server and MS MQM, also known as Falcon, Microsoft's Reliable Queue. The mapping between OLE Transactions and XA (in both directions) is supplied by part of MTS known as the Distributed Transaction Coordinator (MSDTC). MSDTC also provides the mapping between Transactional OLE and ODBC. MSDTC was originally distributed with MS SQL 6.5.

The interface to the Microsoft programmer of OLE Transactions is object oriented, being class based in Microsoft's C++ or Visual Basic. There is no provision for the standard TX interface, as with other TPM and this therefore severely limits the programming language and tool choices that can be made and consequently the portability of existing programs to use this TPM. A single class is used to control a Transaction, ObjectContext. Creating the class with GetObjectContext starts a Transaction and it is normally terminated with a member function SetComplete. The member function SetAbort allows a negative vote and a rollback of the Transaction. Interestingly this model has two further member functions, EnableCommit and DisableCommit. DisableCommit allows a Transaction's state to be suspended in an Abort state, while further work is done. If a SetComplete is called from any transaction branch then the Transaction is effectively aborted. The state can be reversed by the member function EnableCommit.

A Critique of Microsoft's Approach

The MTS system can be considered proprietary, even more proprietary than, say IBM's various offerings on Mainframes, for these have been emulated to varying degrees on other platforms. The use of Microsoft's underlying technology and object system effectively limits the languages that can be used to program with this TPM to Microsoft's C++ and Visual Basic. While this may be considered a barrier to porting successful programs from other TPM to TMS the goal seems to be, on Microsoft's part, to extend the existing DCOM and ODBC technology with Transactions and a measure of scalability. The goal only works if it is true that existing DCOM/ODBC applications were written with MTS in mind.

While enormous strides have been made to increase the reliability of Windows NT, even the most ardent of its supporters would contend that there is still a great deal of work to do here. While the reliability of Windows NT can compromise the reliability of other TPM based on it, just as easily as that of MTS, the other TPM have, for the most part, an escape route to another arguably more reliable platform. Replatforming is not an option should the reliability of Windows NT prove a risk to a project based on MTS.

It is perhaps a truism to say that the majority of two tier Client Server applications running to day are based on ODBC. This initially proprietary interface was seen as being needed to allow the mixed presentation and business logic running on the new generation of powerful PCs to communicate with databases, often running on UNIX platforms. They do this by transmitting SQL and returning the data, which at high volumes with large numbers of users becomes a performance bottle-neck. Simply implementing MTS and a Resource Dispensing ODBC will not allow scaling to be achieved. The application will have to be recoded to compartmentalize it into presentation component and a business logic. The business logic will then have to be migrated to a Windows NT box running a database which supports the newer ODBC 3.0 standard. Given the effort involved, MTS presents no greater advantage as recoding to use a more established TPM.

Resource Dispensing ODBC works on the premise that connection to a ODBC resource will be that much quicker than establishing and breaking a connection to the database. It undoubtably is, but other TPM maintain their connections permanently and one would assume that this would be quicker still. That having been said this approach has been adopted by others notably the Java community with a Java ODBC clone, Java Database Connect (JDBC).

Future Directions

MTS's current version is 2.0 but it seems that MTS will disappear in the next Windows NT, now provisionally called Windows 2000. This, however, appears to be something of a renaming exercise as the technology becomes more tightly coupled with DCOM and this itself is renamed COM+.

Further Reading

MTS used to have a clearly defined URL, but currently these seem to be moving, with the introduction of Windows 2000, no doubt. It is suggested that the Microsoft home page be visited and searched from there.

A number of papers have appeared about MTS, here's a few:

[Box]

Box D (1999) "Windows 2000 Brings Significant Refinements to the COM(+) Programming Model" Microsoft Sys. J. 14(5) p17-34.

Changes to MTS for the next generation of Windows. Introduces, interestingly, the concept of reversible Transactions.

[Tomsen]

Tomsen MI (1998) "Build Reliable and Scalable N-tier Applications that Run on both Windows NT and UNIX" ibid. 13(12) p13-44

Vapourish pronouncements about Microsoft's plans for COM integration with CORBA and SNA (well the SNA's a little more concrete).

[Reed &al]

Reed D, Trewin T & Tomsen MI (1997) "Microsoft Transaction Server Helps You Write Scalable, Distributed Internet Apps" ibid. 12(8) p51-70.

Microsoft's formal introduction of MTS.

Date: 1999/07/04 08:34:50