Container Managed Models-The Microsoft Transaction Server (MTS)

25 Mar 1998

Container-Managed-Models

MTS is primarily a container for in-process server side components.

In database applications, Transactions ensure integrity of data by combining a set of actions into a single atomic unit. A transaction is said to be committed if all the actions succeed as a whole and a rollback occurs if they fail. MTS allows you to define and use transactions within COM objects.

MTS can also be defined as a component-based programming model. An MTS component is a type of COM component that executes in the MTS run-time environment. To be qualified as an MTS component, it has to meet all the requirements of a COM component and the component should be developed as a DLL. Components that are implemented as EXEs cannot run in an MTS environment.

Just as a COM component can be modelled on the basis of interfaces and their implementation, MTS enforces modelling based on the component’s state and behavior. This allows applications to coordinate their state across multiple machines. Since they are composed of COM objects, MTS applications can be implemented in a variety of different languages including Visual Basic, Java, C++ and even COBOL!

MTS handles communication between components through DCOM and HTTP protocols. This allows MTS to expose its components both to 16-bit and 32-bit applications from anywhere on the net or the web.

Some of the unique features that MTS brings into the component world are:

A unique Threading model

Components that use the Thread Neutral model (TNA), mark themselves as Free Threaded or Both. MTS handles thread synchronization for you by automatically creating threads when required and preventing you from creating threads of your own from within MTS components. MTS defines an Activity as a single execution context ( single logical thread of execution ) across different machines. MTS prevents more than one thread from calling into an Activity at any single point in time.

Roles and Packages

MTS takes Security to a totally new level. Packages are defined as a collection of MTS components that make up an application. Roles are a logical group of users of an MTS application. Security is administered to the whole package instead of its individual components. MTS thus separates the application security model from the OS’s security model. This way, the security level of an MTS application can be programatically set.

Just in Time(JIT) Activation

MTS components are created only when they are required and are released as soon as they have finished. This concept called Object pooling increases the efficacy of object life-time management by calling methods on one of the object’s interfaces to tell it when to obtain and free resources.

The MTS run-time is divided into three different parts:

1. The Surrogate process (MTS.EXE)
2. An NT Service called the Microsoft Distributed Transaction Coordinator ( MS DTC )
3. An Administrative tool called the MTS Explorer

Figure 1: Transactional model in MTS

The Surrogate Process (MTS.EXE)

MTS can wrap components to provide a single execution context without you having to write components specifically for MTS. Once a component is registered as an MTS object, MTS.EXE will create a surrogate object or a class factory wrapper for that component and a context object through COM containment. This surrogate object now calls the class factory of the original component. This means that whenever calls are made to any component, MTS intercepts these calls. This allows MTS to provide facilities without either the client or the component having to be specifically written for MTS. One of the responsibilities of the context object is to cache the typelib info for each interface so that MTS can do object pooling efficiently.

Microsoft Distributed Transaction Coordinator (MS DTC)

The DTC facilitates distributed transactions. If an MTS object were to fail during a transaction, all other objects in the transaction are aborted regardless of what machine they are running on. This service helps create transaction context objects that are used in the component context objects and helps in ensuring proper rollback of transactions. It is the MS DTC which provides MTS the scalability and the fail-safety required of any TP monitor program.

Resource Managers and Resource Dispensers

While the DTC coordinates transactions, it relies on the resource providers to understand particular types of data and know how to commit or rollback changes on those resources. Resource Managers handle data that is not lost should the system fail. If the system should fail, the state of a dispenser is not maintained because, Resource Dispensers handle non-durable data. MTS comes with one resource manager SQL Server 6.5 and a couple of resource dispensers ODBC Resource dispenser and Shared Property Manager.

MTS Explorer

To the system administrator, this is the visible part of MTS. It has a couple of main roles. It manages the objects that MTS can use and it allows the administrator to monitor the state of running objects.

In MTS, methods are invoked across a network or machine boundaries, using a modified version of DCE’s RPC (like DCOM) or are directly accessed using the Microsoft Message Queue Sever (MSMQ).

Distributed security services are provided by the NT Lan Manager (NTLM) security protocol supported by both Windows and Windows NT.

MTS today relies on the Domain Name System (DNS) for Directory services. With NT 5.0, both DCOM and consequently MTS, will make use of a combination of the Lightweight Directory Access Protocol (LDAP) and DNS for providing directory services.

The MTS model

A basic MTS architecture is shown in the Figure below and is made up of:

1. The MTS Executive (mtxex.dll)
2. The Factory Wrappers and Context Wrappers for each component
3. The MTS Server Component
4. MTS clients
5. Auxiliary systems like COM runtime services, the Service Control Manager (SCM), the Microsoft Distributed Transaction Coordinator (MS-DTC), the Microsoft Message Queue (MSMQ), the COM-Transaction Integrator (COM-TI), etc.

Figure 2: A basic MTS architecture

COM components that run under the control of the MTS Executive are called MTS components. MTS components are all developed as in-proc DLLs and are implemented as one or more COM components. These components are deployed and run in the MTS Executive which manages them. As is usual with COM components, the object implementing the IClassFactory serves as a Factory Object to create new instances of these components.

MTS inserts a Factory Wrapper Object and a Object Wrapper between the actual MTS component that MTS manages, and it’s Client. Therefore, whenever the client makes a call to the MTS component, the Wrappers (Factory and Object) intercept the call and inject their own instance management algorithm called the Just In Time Activation (JITA) into the call. The wrapper then makes this call on the actual MTS component.

In addition to this, based on the information from the component’s deployment properties, transaction logic and security checks are also done in these wrapper objects.

For every MTS component, there also exists a Context Object which implements the IObjectContext interface. The Context Object maintains specific information about that component such as it’s transactional information, security information and deployment information. The MTS component calls into the Context Object through it’s IObjectContext interface.

In MTS, the actual middle-tier MTS component is not created until the call from a client reaches the container. Since the component is not running all the time, it does not use up a lot of system resources (even though an object wrapper and skeleton for the component are still hanging around for the component).

As soon as the call comes in from the client, the MTS wrapper process activates its Instance Management algorithm called JITA. The actual MTS component is created “Just In Time” to service the request from the wrapper. And when the request is serviced and the reply is sent back to the client, and the component either calls SetComplete()/SetAbort(), or the transaction that it’s part of ends, or the client calls Release() on the component, the actual MTS component is destroyed. In short, MTS is a stateless component model.

Generally, this is what happens on the Server when a client requests services from a typical MTS component:

1. Acquire a database connection.
2. Read the component’s state from either the Shared Property Manager or from an already existing object or from the client.
3. Perform the business logic.
4. Write the component’s changed state, if any, back to the database.
5. Close and release the database connection.

It is thus possible to implement high latency resources as asynchronous resource pools, which should take advantage of the stateless JIT activation afforded by the middleware server.