Microsoft Transaction Server

The Microsoft Transaction Server (MTS) for Windows NT is an object-oriented transaction server for COM-based components. It includes a transaction manager, the Distributed Transaction Coordinator (DTC), and currently supports two protocols:

OLE Transactions
XA protocol

It also includes some ORB-like capabilities — MTS provides tools to deploy clients and servers, and a snap-in to the Microsoft Management Console, a GUI-based system management framework, which it shares with Internet Information Server (IIS) and other Microsoft servers.

MTS Architecture

MTS defines system components that map nicely into our overall TP architecture. Besides the Microsoft Distributed Transaction Coordinator (DTC), the components include:

Clients, which correspond directly with our presentation servers
MTS objects, which contain application logic and correspond to both workflow controller and transaction servers
Resource managers
Resource dispensers.

The MTS executive manages the MTS object threads in a server process, and is responsible for starting and committing transactions for applications written using implicit transaction bracketing, as explained below. Thus, the usual problems associated with managing multiple users using the same business objects are handled for you behind the scenes. MTS objects shouldn't be multi-threaded themselves — instead, their classes should support multiple instancing, and leave the details to MTS.

MTS objects are used to build both workflow controllers and transaction servers. MTS does not enforce any architectural distinction between these components. It is up to the system architect to configure the components accordingly.

Resource dispensers are like resource managers, but the objects they control are not persistent. An example would be a shared memory heap that is used to construct objects for several processes. Resource dispensers do not participate in two-phase commits, as they have no persistent data, but they are shared resources, and applications access them using synchronization primitives.

MTS Objects

Programming an MTS object requires you to adhere to three simple rules:

The MTS objects must be compiled into an in-proc (DLL) server, as they will need to run within the MTS server process
A standard COM class factory is required for each object, so that MTS can create them automatically
The MTS object must support standard COM marshaling mechanisms, so that it can be invoked by clients both local and remote

MTS objects are grouped together by function into packages, the creation of which couldn't be easier. Dragging the DLL into the package folder on the management window, exposes all the public COM objects. Security is organized at the package level, using the concept of roles.

A role is a list of NT users or groups allowed to access that package, defined according to how they will need to use it. Thus clerks have one role, managers another, sys-admins yet another. Different components and component interfaces within the package can support differing access depending on what role the client is playing. Thus a clerk would have access to the data entry objects, while a manager might also have access to report-creation objects.

Transaction Bracketing

MTS applications may be designed using implicit transaction bracketing. This is done by marking all DCOM components with respect to the relationship of their transactional boundary and that of their parent. Specifically, all DCOM components follow one of the following four types of semantics:

Not Supported: The object must not run within a transaction.
Required: The object must run within a transaction.
Requires New: The object must run within its own transaction.
Supported: The object may run within the parent's transaction.

Context Object

An important part of the architecture is the context object. It contains the information about any transactions in which the MTS object is engaged, and which role the client has assumed.

The MTS executive creates one every time an MTS object is created. The MTS object can get a reference to an

ObjectContext

object, available from the MTS type library, using the GetObjectContext()
call. IObjectContext
's methods include:

SetComplete()
— specifies that this object's transaction may complete and the object be deactivated, other things being equal.
SetAbort()
— abort the transaction, when the transaction manager asks and deactivate the MTS object.
DisableCommit()
—your MTS object may maintain state while it's working; for instance, if it calls another object and waits for that to return, or if the client makes several calls during a transaction. If this is the case, the transaction mustn't commit in the meantime.
However, MTS may reuse an MTS object for a different client — by default, it assumes that the object carries no state between method calls. DisableCommit()
guarantees that the client will get the same MTS object during a transaction.
EnableCommit()
— this re-enables the MTS object's ability to commit or abort if asked.
CreateInstance()
— if your MTS object creates another MTS object as part of its work within a transaction, you don't want to lose that transaction's context information. If the second object fails, the calling object must know, so that it can rollback its changes. CreateInstance()
allows an MTS object to create a child object such that it shares its context information.
IsCallerInRole()
— this allows your MTS objects to check that their client has the right security clearance to continue.

Calling

DisableCommit()

and EnableCommit()
needs to be done when an MTS object is first activated and when it is ready to be deactivated, respectively — and this is handled by the IObjectControl
interface, and its Activate()
and Deactivate()
methods.

MTS Clients

MTS clients are normal DCOM components. This includes standalone programs written in Visual C++ as well as COM objects that live inside a web page. DCOM provides the communications infrastructure that allows clients to use the normal object-invocation mechanism in their programs. Of course, if the method is for a remote object, the invocation will be on a proxy object. To help you with deployment, MTS can create an installation program that can be used to provide the correct proxy on each client machine.