Microsoft Corporation
June 1997
This article describes how you should package your Microsoft® Transaction Server (MTS) components. Consider the following design issues when defining package boundaries:
In Microsoft Transaction Server version 1.1, you should set one of the following activation levels for your component:
It is recommended that all components within a package run with the same activation level. In MTS 2.0 the activation level is set at the package level; you can no longer use component-level activations.
MTS developers should also avoid using the Remote setting, as MTS provides an easier way to set up remote components by using the Remote Computer and Remote Component folders in the MTS Explorer hierarchy. For more information about "pulling" or "pushing" components between computers, refer to the Administrator’s Guide in the Microsoft Transaction Server Help. The Remote activation option could be used to switch quickly between local and remote activation of a single component for test purposes. You should note that if a component is marked for remote activation, this setting only affects local clients. Think of remote activation as a "redirection" that is in effect only for local clients. Note that this redirection can only include one “hop." If component activation is redirected from computer A to computer B, computer B cannot further redirect activation to a third computer. You should also note that the properties that are to be applied to the component at run-time (for example, transaction support) will be picked up from the configuration information on the target computer. For example, if a component is configured on computer A for remote activation on computer B, the properties settings that are stored on computer B will be applied to the component at run-time. The properties set for the component on computer A (other than activation) would be ignored.
Due to the restrictions noted above you should use the remote activation option sparingly and only for test purposes. Once the final location of a server component is determined, you will find it easier to manage if you install it in a package on that target computer and set it for local activation.
By default, components run in a server process on the local computer. If you run your components within the MTS server process, you enable resource sharing, security, and easier administration by using the MTS Explorer for your component. Running components in-process provides an immediate performance benefit, because you do not have to marshal parameters cross-process. However, in-process components do not support declarative security and you lose fault isolation.
Note that in-process components do not support declarative security or offer the benefits of process isolation. In-process components will run in any process that creates the component. Role checking is disabled between components because IsCallerInRole returns True (the direct caller always passes the authorization check).
Also, try to place your components as close as possible to the data source. If you are building a distributed application with a number of packages running on local and remote servers, group your components according to the location of your data (if possible). For example, in the following figure below, the Accounting server hosts an Accounting package and Accounting database.
Sharing resources in a multi-user environment results in faster applications that scale more easily. Note that only components marked with the Local activation setting can share resources. You should package your components to take advantage of the resource sharing and pooling that MTS provides for your application.
Pool your resources by server process (note that MTS runs each hosted package in a separate server process). The fewer pools you have running on your server, the more efficient the pooling of resources. Consider the type of resources that components are sharing in your package, and try to group components that share "expensive" resources, like connections to a specific database. If you reuse the expensive resources within your package, you can greatly improve the performance and scale of your application. For example, if you have a database lookup and a database update component running in a customer maintenance application, you should package those components together so they can share database connections.
Fault isolation entails separating components into packages that can operate in their own server process. Components in the same package will share the same server process if all the activation settings are the same. By placing components in separate packages, you can mitigate the impact of a component failure because each package runs in a separate server process.
Fault isolation can also be used to test new components. Using fault isolation, you can stage updates to MTS applications by introducing new components. Fault isolation for packages greatly reduces the risk of your local server package failing when you introduce a new component to a shared environment.
MTS security roles represent a logical group of users that are mapped to Microsoft Windows NT® domain users and groups during the deployment of the package. You can use the MTS Explorer to define declarative authorization checking by applying roles to components and component interfaces. Applying a security role to a component defines access privileges for any user assigned as a member of that security role. Users who are not assigned to a role with access privileges to a package will not be able to use the package. Because security authorization occurs between packages rather than between components within a package, you should consider the MTS security model when determining your package boundaries. Note that security isolation only applies to packages with components running under the Local activation setting.
Security authorization is checked when a method call crosses a package boundary (such as when a client calls into a package or one package calls another). When you package your components, make sure you group components that can safely call each other without requiring security checks within one package.
All components within a package will run under the identity established for the package. If two components must run under different identities then they should be separated into two different packages.
You can use declarative security between the client and server, and database security based on package identity between the server and data source. You can restrict access to a data source by assigning an identity to a package and configuring the database to accept updates according to package identity.
If you use package identity to set up your database security, the database recognizes the package identity as a single user. If database access occurs under an identity set by the package, the database connection set up for the package identity name can be used by all the users mapped to role or roles for that package. This kind of resource sharing improves application performance and scalability.