Microsoft Transaction Server

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

The MTS Executive (mtxex.dll) The Factory Wrappers and Context Wrappers for each component The MTS Server Component MTS clients 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.

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:

Acquire a database connection. Read the component's state from either the Shared Property Manager or from an already existing object or from the client. Perform the business logic. Write the component's changed state, if any, back to the database. 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.