原文链接：

https://msdn.microsoft.com/en-us/library/aa227438(v=vs.60).aspx

Introduction

At the beginning of Chapter 11,"Using ActiveX DLLs from WebClasses," I discussed how WebClasses don't have access to the ObjectContext object or to the ScriptingContext object. You also saw that you have problems accessing objects in external ActiveX DLLs unless they run inside Microsoft Transaction Server (MTS). TheVB Developer's Guide to COM and COM+by Wayne Freeze (1999,Sybex—part of this series of VB Developer's Guides) explains MTS and COM+ in detail. This chapter focuses only on accessing MTS objects from WebClasses. You'll see how to connect WebClasses to transactional and non-transactional components running inside MTS.

What Is MTS?

MTS consists of several unrelated capabilities lumped together under a single name. Microsoft,recognizing that MTS is not an accurate name for this collection of features,has renamed MTS to COM+ in Windows 2000.

MTS is an object broker. That means it maintains a list of objects and facilitates other programs' use of those objects. MTS facilitates code reuse. Without MTS,you would have a difficult time sharing objects within your program and between programs. You would have to set up a pool of objects,then devise ways of sharing them without conflict.

MTS is also a transaction monitor. MTS can monitor and manage transactions—work that must either complete successfully or fail totally across multiple components. For example,suppose you want to send e-mail to an administrator each time an employee changes personal income tax deductions. The transaction consists of all the operations required for the employee to make the change in a database and also all the operations required for the program to compose and send the e-mail message to an administrator. If any error occurs when making the database changes,you don't want the program to send the e-mail. If the database changes succeed,youmustsend the e-mail message successfully; otherwise,you need to roll back the changes in the database and inform the employee that the program cannot make the changes.

If you set this up,you would need to write code to ensure that each part of the process completed successfully before committing the transaction. You would also need to write code to roll back the transaction if any error occurred. MTS handles all these issues for you.

MTS usescomponentsto perform the units of work involved in a transaction. A component and a class are,to the VB programmer,essentially identical. VB programmers discuss classes and objects. MTS programmers discusscomponents. A component has a specific COM interface,and so does a VB class. A DLL may contain several components or classes,just like in VB. You can't create classes with multiple interfaces in VB (although you can make classes thatusemultiple interfaces).

With Visual Basic 6,Microsoft added a design-time property calledMTS-TransactionModethat lets you control whether the classes you create can participate in MTS transactions. The property has five settings,as shown in Table 12.1.

Table 12.1: The FiveMTSTransactionModeSettings

WebClasses don't support theMTSTransactionModeproperty,but standard classes do. That means that although WebClasses don't participate in transactions,they can launch objects that do. Note that components do nothaveto participate in or begin transactions to run under MTS. You can take advantage of some other features of MTS whether you need transactions or not. These features help speed up Web applications:

Object caching and pooling Although MTS doesn't support true object pooling for apartment-threaded DLLs such as those you create with VB (although it may in the future),it does cache one or more instances of the class in memory. Usually,each time you create an object instance,the server creates a new instance of the class. In contrast,after MTS has loaded a class,it keeps it loaded and ready,either forever or for a configurable amount of time. That feature alone is worth using,especially for Web applications in which the object creation/destruction cycle happens for every request. To take advantage of this feature,your code needs to tell MTS when you're done with a component.

State maintenance MTS "fools" clients into thinking that they have exclusive use of a component when in fact that component may be shared between multiple clients. That means that you can create a client reference to an MTS component,use the component,do something else,then use the component again. During the time your code isn't using the component,MTS may let another process—or many others—use the component. To the clients,each component acts as if it belongs to them exclusively. MTS creates new instances of components only if none exist or if all the existing components are busy. In other words,you don't have to worry about creating an object,using it,then destroying it as quickly as possible because MTS frees you from those worries. MTS state maintenance saves not only resources,but also a great deal of server time that would otherwise be spent creating and destroying objects.

Data sharing between components MTS lets you share properties between multiple components. In a standard application,you use global variables and constants to share data. Because MTS objects are shared between multiple clients,you can't store state inside the objects themselves. MTS uses an object called a Shared Property Manager to manage data shared between MTS components.

Process isolation MTS isolates your Web server from the effects of misbehaving components. When you run components in the root Web,any component that crashes can also crash the server. Components running inside MTS don't crash the server. You can group components into Packages,each of which can run in a separate process. There's a performance penalty for cross-process object communication. When maximum speed is imperative,you can run components as a Library Package. Library Packages run in the client's process space; therefore,they're faster (but less secure) than components that run in their own process space.

Security MTS gives you fine-grained security. You can control security down to the interface level (note that's below the object) in MTS. MTS has role-based security,which means that you create roles,each of which can have different permission levels. You can assign user accounts to those roles,then have MTS manage access to resources based on a user's role.

In-memory databases With COM+ in Windows 2000,Microsoft has added support for in-memory database tables. Keeping database tables in memory can provide a huge leap in performance and scalability,because memory access is an order of magnitude faster than disk access. Depending on your needs,this feature alone may be worth upgrading from NT 4.