Administering MTS

Why can't a developer build a single-user application, install it on an enterprise server, and accurately call it an enterprise application? The answer has to do with scarce server resources such as network sessions and database connections. If a server application attempts to perform a unit of work but has to wait for these resources to become available, scalability has stopped.

Microsoft Transaction Server (MTS) helps you ensure that applications will use server resources economically. This overview describes several issues Windows NT systems administrators face when they manage MTS servers.

What Is Microsoft Transaction Server?
MTS is a product for running business applications on an NT server. It combines the ease and flexibility of PC programming with the reliability of mainframe applications. MTS automatically provides functionality to single-user applications that lets them run reliably as multiuser applications. MTS also provides process isolation, network sessions, shared data, database connections management, multithreading, application security, automatic transactions, and an easy-to-use point-and-click administrative interface.

MTS relies heavily on packages. Packages are collections of ActiveX components that function together as an MTS application. MTS implements these components as single-use DLLs that provide business functions to the application. The MTS package can provide services to Web clients and to LAN-based applications. In addition, MTS provides access to several types of databases, including SQL Server databases, UNIX databases, and mainframe databases.

Although MTS has existed in one form or another for more than 3 years, widespread use of the product has only recently begun to take off. Several technology companies, including Digital Equipment, Texas Instruments, and HP, use and support Active Server Technologies such as Distributed Component Object Model (DCOM) and MTS.

In an effort to demonstrate that MTS can scale to support enterprise applications, at the May 1997 Scalability Days, Microsoft used NT Server, SQL Server, and MTS to demonstrate a system that generated one billion transactions. In addition, IBM has used MTS to demonstrate a distributed online transaction processing system that executes one billion transactions per day on a cluster of servers running NT Server 4.0.

With MTS, developers do not have to change any code to scale single-user applications to multiuser applications. This factor is important to systems administrators because application changes usually involve disrupting the server and spending time implementing the software upgrade. At the very least, upgrades usually involve a server reboot. In addition, changes to working software sometimes introduce new bugs to the server. MTS eliminates these problems.

With MTS, systems administrators use a consistent interface, the MTS Explorer, to create and administer applications. The interface provides flexibility in deploying applications. For example, you can use the same code to configure an application to run on a standalone system, on one server, or on multiple servers. Because the interface is consistent across applications, you do not have to learn a new configuration tool with each new application. The MTS Explorer runs as a snap-in to the Microsoft Management Console (MMC), the management interface that Microsoft now distributes with NT. You install components, such as MTS and IIS 4.0, into the MMC and administer those components from within the MMC.

MTS can help simplify your job. By making applications scalable and reliable, developers write less code. This scenario means fewer application components and fewer possible points of failure. With fewer possible points of failure, an application is less likely to fail and bring the server down with it.

With code that takes advantage of context objects, you can build ActiveX components specifically for MTS. Context objects are like guardian angels that follow around each instance of MTS objects to provide information about that instance. MTS can provide advantages to applications whether or not they have been built specifically for MTS, although the use of context objects makes an MTS application more robust.

We'll highlight some specific benefits available to components that are installed into MTS. MTS-specification applications can take advantage of all these benefits but even applications not written with MTS-specific code can take advantage of the first four.

Database Connection Pools. When using an Open Database Connectivity (ODBC) database with an MTS application, database connections can service more clients because MTS recycles the connections when the MTS application no longer needs them. Performance and scalability improve because neither the application nor MTS has to create new connections for each request and user. The same connections are shared and recycled among instances of MTS applications.

Secure MTS Applications. MTS can configure security into components. Developers do not need to add security code. MTS security uses NT security features to grant levels of access to MTS packages and components.

Component Management. MTS can distribute components across multiple machines to ease the processing burden placed on a server. You can use the MTS Explorer to distribute components to a client machine whether or not that client is running MTS. If the client is not running MTS, MTS can generate an executable that will automatically install and configure clients to access remote MTS server applications. The client must support DCOM for this procedure to work.

Transaction Monitoring. MTS can manage transactions in components that are not coded specifically to use the context object. Even without MTS-specific code, you can use MTS to roll back transactions if an operation fails.

Just-In-Time (JIT) Activation and As-Soon-As-Possible (ASAP) Deactivation. With JIT and ASAP, MTS improves scalability and performance because it activates components only when it needs them and deactivates them otherwise. As MTS deactivates objects, they become available to other processes. Because objects are already warmed-up and the server does not have to create new objects for each client, the objects are served up more quickly to subsequent processes. Components that do not use MTS-specific code must wait for the client application to release objects. The SetAbort and SetComplete methods provide immediate object deactivation.

Shared Properties. Components can create, use, and update global data. Objects do not need to manage state information because components can share information with other components in the same package. MTS handles state management for any number of simultaneous clients.

Improved Security. MTS provides two types of package security: programmatic and declarative. Programmatic security deals with MTS-specific interfaces that developers use to create customized security within application logic. Available to all MTS applications, declarative security lets you take advantage of existing NT security to assign various levels of permissions to access packages, components, and interfaces. You can run packages on nearly any computer on the network, as long as the operating system (including Windows 9x) supports DCOM. Because declarative security is based on NT security, you can use it only for packages running on NT.

   Previous  [1]  2  Next