Chapter 9 -- The MTS Run-Time Environment

Chapter 9

Information systems based on an N-tier architecture that run business objects in the middle tier are becoming increasingly popular. Chapter 1 covers many of the issues that have motivated a number of companies to pursue this style of development. However, as these companies have tried to port their existing two-tier applications, they've discovered many new challenges. One of the biggest hurdles for developers of distributed applications is that of creating an infrastructure to accommodate scalability and throughput for a large user base. In the two-tier model, client applications connect directly to a database management system (DBMS). The two-tier system can leverage the scalability features built into a DBMS such as ORACLE or Microsoft SQL Server for managing connections, pooling threads, and monitoring transactions. Each client that connects to a DBMS consumes memory and processing cycles on the server. In the N-tier model, client applications don't connect to a DBMS. Instead, they connect to a distributed application running in the middle tier. In an N-tier system, a distributed application must take on many of the responsibilities for scalability and throughput that were previously handled by a DBMS.

The most significant cost in assembling an N-tier system has been that of building a sophisticated framework to handle the requirements of a distributed application. To reduce this cost, Microsoft created Microsoft Transaction Server (MTS). Companies can now spend more time writing business logic and less time writing complex code to deal with issues such as connection management, thread pooling, and transaction monitoring. MTS 2.0, which was released with the Windows NT 4 Option Pack at the end of 1997, plays two distinct and important roles. First, it is a refinement of the COM run-time environment. It provides a surrogate process that can load and run COM objects on behalf of clients throughout the network, and it offers many valuable run-time services. You can view MTS as an improved version of Distributed COM. Second, MTS acts as a transaction processing monitor for an online transaction processing (OLTP) system. This chapter concentrates on the important aspects of the run-time environment; Chapter 10 explains how to write MTS transactions for an OLTP application.

MTS makes it easier to configure and deploy applications based on Distributed COM. Once administrators and developers learn how to use a tool called the MTS Explorer, they can deploy distributed objects in a straightforward fashion. This chapter shows you how to install ActiveX DLLs created with Visual Basic in the MTS environment. You'll also learn an easy way to configure the computers involved in a distributed application, and you'll be exposed to many of the services offered by the MTS run time.

You must learn how to talk to the system behind MTS if you really want to take advantage of this environment. In particular, you must learn how to interact with an MTS-supplied component known as the MTS Executive. You'll also learn how to communicate with the MTS Executive through the ObjectContext interface and how to receive notifications from it by implementing the ObjectControl interface when your objects are activated and deactivated. Once you establish the lines of communication with MTS, you can make the most of the MTS threading model and manage the life cycle of your objects.

Finally, this chapter explains the importance of using binary compatibility and how to rebuild and test your DLLs. You'll also learn about options for debugging an MTS application. Debugging components in the MTS environment has always been far more challenging than debugging standard Visual Basic applications. Fortunately, Visual Basic 6 has some new features that make debugging MTS components easier.