Microsoft Transaction Server

The Microsoft Windows NT 4.0 Option Pack includes Microsoft Transaction Server, a transaction processing system for developing, deploying, and managing distributed server applications. MTS takes care of all the server-side plumbing issues, such as automatic management of processes and threads, object instance management, and a distributed security service, so that developers can concentrate on writing the business logic specific to their applications. MTS brings a higher level of scalability to Web applications running on IIS by conserving server resources. As we have seen above, MTS also provides transactional behavior for applications so operations either succeed or fail as a whole.

Once you have installed MTS, take a few minutes to familiarize yourself with the Transaction Server Explorer, shown in Figure 19-1 below. You can access the Transaction Server Explorer by choosing Start|Programs|Windows NT 4.0 Option Pack|Microsoft Transaction Server|Transaction Server Explorer, or by choosing Start|Programs|Windows NT 4.0 Option Pack|Microsoft Internet Information Server|Internet Service Manager. Both of these options will launch the Microsoft Management Console, which contains the Transaction Server Explorer.

Figure 19-1. The Transaction Server Explorer within the Microsoft Management Console.

In the right-hand pane of the Transaction Server Explorer, you'll see the Packages Installed folder. This folder is where you can install, deploy, and maintain your packages and components. We'll now look at some of the MTS terminology: packages, components, roles, interfaces, and methods.

Packages

All components need to belong to a package. A package is a set of components that perform related application functions. While packages are simple to create—using the Transaction Server Explorer—the components that are added to the package should be selected carefully. Packages can define process boundaries, so you want to carefully consider your component design and deployment strategy. For performance reasons, you'll want to minimize the number of process boundaries that are crossed. The following design issues should be considered when defining packages:

• Activation
• Shared Resources
• Fault Isolation
• Security Isolation

A package can be activated either as a Library Package or as a Server Package. A Library Package runs in the same process as the client that created it and offers no component tracking, role checking, or process isolation. A Server Package runs in its own process. It supports role-based security—see the section on roles below—resource sharing, process isolation, and process management.

Components that are in the same package are able to share expensive resources, such as database connections, via database pooling. Sharing of resources allows applications to scale more easily and can also improve performance. This design consideration favors placing components in the same package.

Fault isolation means that components in different packages are protected from each other. If the process for one package dies for some reason, this does not affect the other package, which is running a separate process. This is one design consideration that tends to favor placing components in separate packages. This can be especially relevant during development and testing phases when components are still being verified for correct functionality. A similar consideration applies when deciding whether to run Web projects in a separate memory space from the Web server to avoid crashing the Web server if the application crashes.

Packages also define security boundaries, so by placing components in separate packages you can isolate them from one another. When a component calls another component in a different package, the MTS security model will check the authorization of the calling client. No authorization checking between components within the same package occurs unless it is done at a programmatic level.

Components

A component is an ActiveX DLL that you create and install into MTS. They can be written in any language that supports the creation of COM components. Components provide the objects that clients request at run time.

There are several advantages of running your component under MTS, including simplified management of components via the Transaction Server Explorer, location transparency, thread management, and database connection pooling.

Roles

A role is a symbolic name that defines a class of users for a set of components. Roles are applied at the package, component, or interface level. They are defined within the Transaction Server Explorer and are similar to Windows NT groups. After creating a role, you typically assign Windows NT users and/or groups to that particular role. This tells MTS which users have authorization to access methods within components in packages.

MTS offers two types of security: programmatic security and declarative security. Role assignments are a form of declarative security and are typically handled by an MTS administrator.

Interfaces

An interface is defined as a group of logically related operations or methods that provides access to a component. Within the Transaction Server Explorer, the Interfaces folder shows the methods and role membership for a component.

Methods

Methods are those functions exposed by your components. In the Transaction Server Explorer, the Methods folder contains all the methods defined in a selected interface. The Methods folder is a useful way of browsing a component to see what methods it exposes.