MTS in the Middle

How to use the COM object broker

Microsoft Transaction Server (MTS) is middleware technology for Windows NT that handles several features for COM components. First and foremost, MTS is an object broker. MTS manages the instantiation (creation) and destruction of objects when another application requests them. MTS is also a transaction-processing system and an object repository that holds references to the objects registered in it. To use MTS, you need to understand how it serves as an interface, manages components, and provides security.

MTS and COM Objects

MTS serves as the interface between COM objects and the applications that use them. Say that a client application uses CreateObject to create the Publication object from Visual Basic (VB) or VBScript:

Set oPubs = CreateObject("Publications.Publication")

This code creates an instance of the Publication object. The OS (NT or Windows 9x) creates the object by looking up the ProgID (Publications.Publication) in the Registry and finding its executable. The executable entry is under the class ID in the HKEY_CLASSES_ROOTCLSID tree. Under COM or DCOM, NT or Windows 9x uses this information to find and execute the object stored in the component.

COM components can be either in-process or out-of-process. An in-process component executes in the process space of the calling application; an out-of-process component executes in a separate process space. Because MTS works only with in-process components, I won't describe out-of-process components in detail in this article.

Packages

MTS uses a concept called a package to define processes in the MTS system. When you want to use a component with MTS, install it in an MTS package, and MTS will register it. Figure 1 shows the CustomerProcessing package containing two components, Customer and Order. Because the components in a package run in the same process space, they can efficiently pass information back and forth and share the same security context. Packages also provide fault tolerance: If a component fails, it might take down the package it was in, but it won't affect other packages.

The fault isolation achieved through creation of individual packages is especially useful for testing and rolling out new components. If a new component that you place into a separate (or test) package causes a problem, the problem affects only that component or package. After you determine that the component is stable, you can promote it to a production package.

MTS uses the MTS Executive (mtx.exe) to run the components in a package. Because the components run under MTS, MTS can manage them. The object broker services let MTS manage the creation and destruction of objects in a component as needed. Figure 1 illustrates how the components run inside mtx.exe, and how any applications (shown as clients) that use the components access them through MTS. The components are in a package, and mtx.exe manages the interface between the client applications and the objects in a component.

You can also let a package run inside the process that calls an object in an MTS package. For instance, if you set up a package as a library package and an Active Server Pages (ASP) application calls a component in that package, the package executes in the Microsoft Internet Information Server (IIS) process (inetinfo.exe). This results in a large performance gain but less fault tolerance—if an object in a component dies, the inetinfo.exe process dies and every Web application dies with it.

You can add a new package either by installing a prebuilt package that you export from another system or by creating an empty package and manually adding components to it. Screen 1 shows the MTS Explorer with the CustomerProcessing package after I dropped the Client.Customer component into the package.

From the time you place a component into an MTS package, MTS controls the component. MTS modifies the Registry entry for the component by creating an entry that makes mtx.exe the local server for the component (LocalServer32 entry). MTS takes care of instantiation for objects under its control. When COM receives a request to instantiate an MTS object, COM finds the LocalServer32 entry and uses mtx.exe to create the component, instead of doing so directly as in the first example. MTS Explorer makes the Registry changes automatically, and COM handles the instantiation; this process hides the implementation of the component in MTS from the developer. This integration is a major reason why Microsoft has folded MTS into NT 4.0 via the NT Option Pack and why MTS will be an important part of COM + (as Component Services) in Windows 2000 (Win2K).

Management

MTS uses just-in-time (JIT) object management to manage components. When MTS receives a request to instantiate an object, MTS creates the object and passes a reference to the object back to the requesting application (client). Usually, clients using COM objects must release references to an object when the clients no longer need the references. A client application can hold a reference to an MTS object even if MTS has already deactivated the object, because MTS gives the calling application a reference to a proxy for the object. When the client accesses the referenced object, MTS uses the proxy to recreate an instance of the object to fulfill the request. This function provides a powerful mechanism for scaling an application, because MTS efficiently handles the object-brokering services.

Also, MTS can handle the transaction management for components. To let MTS manage transactions, you must set the transaction support option for any class (object) in a component. You can do this either during development or with the Transaction tab of the component's Properties dialog box, which Screen 2 shows. If you set Transaction support to Requires a New Transaction, Requires Transaction, or Supports Transactions, MTS can automatically enlist the connection in the current transaction each time a transactional component opens a database connection. This automation frees the developer from having to create and maintain transactional code (e.g., commit work, rollback) to manage the transaction. Automatic enlistment also makes creating transactions in multiple components easy, because as MTS instantiates each object, MTS adds the instance to the context of the original executing transaction.

Because a transaction includes all components created within its scope, it can easily commit or roll back across vastly different data sources—for instance, between CICS on a mainframe and Oracle on a UNIX box. Also, MTS Explorer provides an interface for monitoring transaction volume and outcomes. By using the Transaction Statistics window in the MTS Explorer, you can monitor the transactions and track the overall statistics for transactions on a system. From the system display, you can quickly get a view of current activity and system performance. And if a transaction fails, you can view information about its failure in the transaction list and the Trace Messages window.

Security

MTS uses the existing NT security infrastructure and decreases the need to embed security in applications. MTS provides a rich security model, with security enforceable at the package, component, and interface levels. This variety gives the system manager and developer a security hierarchy that they can use to tailor security levels for specific applications.

The System Package contains the components that interact with MTS to perform the administrative functions in MTS Explorer. The System Package defines two roles: Administrator and Reader. Initially, the System Package de-fines no users with the Administrator role, so anyone who can connect to your MTS server can remotely administer the MTS system. Immediately after you install MTS, assign users to the System Package's Administrator role. This step enables security on the system. Assign the Reader role to users that you want to let view but not update items in MTS.

Declarative security in MTS is a system of creating roles and assigning groups or NT users to those roles. As soon as the system has authenticated a user, that user's role membership determines access to MTS objects. You create roles at the package level, and you can implement them at the component and interface level. Use MTS Explorer to set up declarative security for components you've already installed into MTS.

Programmatic security involves using MTS security methods and properties to embed security logic in a component's application code. By using programming logic in your application's code, you can easily control what users can and cannot do. This capability is useful when you need to control what each user can update. You can't manage this type of granular control with declarative security.

Interfaces

The MTS Explorer provides administration facilities to create packages, install components, and monitor transactions. Microsoft implemented most of these functions as COM interfaces, which let you control creation, administration, and deletion of components from other applications and scripts. The Microsoft Management Console (MMC) provides a common interface for MTS Explorer and other management services. (For details on the MMC, see Ken Spencer, "SQL Server Snap-In Management," July 1999.)

Each system defined in the Computers folder in the MTS Explorer has several packages installed on it. To view the packages, select the Packages Installed folder. By clicking on any of the packages, you can view the components in the package.

MTS is a powerful middleware system for NT. This article has only scratched the surface of how MTS works and integrates with other technologies. Future articles will dig into the various aspects of MTS and demonstrate how you can use it with VB, Visual InterDev (VID), and other technologies. Also, I'll report on some testing that shows how MTS scales and point out tips for making objects work efficiently with it.