Introduction

This document will provide an introduction to COM+ from a hosting perspective. The topics discussed will center on information you should be aware of regarding the hosting of COM+ applications.

COM+ is the next step in the evolution of the Microsoft Component Object Model and Microsoft Transaction Server (MTS). COM+ handles many of the resource management tasks you had to program yourself, such as thread allocation and security. It automatically makes your applications more scalable by providing thread pooling, object pooling, and just-in-time object activation. COM+ also protects the integrity of your data by providing transaction support, even if a transaction spans multiple databases over a network.

You might be interacting with COM+ for a variety of reasons. If you are a system administrator at an Application Service Provider, you will be installing, deploying, and configuring COM+ applications and their components. If you are an application programmer for the ASP or an ISV, you will be writing components and integrating them as applications. If you are a tools vendor, you will be developing or modifying tools to work in the COM+ environment. The documentation is organized to help you quickly find the information that applies to the work you are doing.

COM+ Applications

COM+ is administered by the Component Services MMC snap-in. A COM+ application is the primary unit of administration and security within COM+. The application is a group of COM components that, generally, perform related functions. These components further consist of interfaces and methods, as shown in figure 1.

Figure 1

You can use the Component Services administrative tool to create new COM+ applications, add components to applications, and set the attributes for an application and its components.

By creating logical groups of COM components as COM+ applications, you can take advantage of the following benefits of COM+:

A deployment scope for COM components.

A common configuration scope for COM components, including security boundaries and queuing.

Storage of component attributes not provided by the component developer (for example, transactions and synchronization).

Component dynamic-link libraries (DLLs) loaded into processes (DLLHost.exe) on demand.

Managed server processes to host components.

Creation and management of threads used by components.

Access to the context object for resource dispensers, allowing acquired resources to be automatically associated with the context.

There are four basic types of COM+ applications:

COM+ Application Components

COM+ applications consist of one or more COM components. This section defines the terms component, class, object, interface, and method as they are used in this guide. The section also describes configured and unconfigured components, and details the benefits of component management with COM+.

A COM class is a named, concrete implementation of one or more interfaces. The class exposes its interfaces, which provide a set of related functions called methods. A COM object is an instance of a COM class. A COM component is a binary unit of code (usually a .dll or .exe file) that creates COM objects (which includes packaging and registration code).

A COM class is identified by a CLSID (sometimes a ProgID, too). An interface is a group of related functions that specifies a contract. This includes the name, interface signature, interface semantics, and marshaling buffer format.

An interface is identified by an IID. The interface syntax is defined in IDL and/or type libraries. The class' interfaces should be divided into manageable, cohesive sets of methods. Remember that interfaces are immutable; the COM contract states that they cannot be modified. Any modification (such as adding methods) requires defining a new interface.

Configured Components

To take advantage of the services that COM+ applications support (including increased scalability, robustness, and simplified system management), the COM+ environment imposes specific requirements on COM components built for COM+ applications. Once added to a COM+ application, a component is known as a configured component.

COM components built for COM+ applications are in-process server components. The component must contain a type library (.tlb file) to describe all classes implemented in the component and declare the interfaces on all classes in the component. You can create and implement these components with Visual Basic, Visual C++, Microsoft Visual J++, or any COM-compatible development tool.

An unconfigured component is a component that isn't installed in a COM+ application. You can transform most unconfigured components into configured components simply by integrating them into a COM+ application.

COM+ Services

Transaction Processing

This section introduces general transaction-processing theory, provides a closer look at transactions in COM+, and presents practical tips for writing transactional components.

When you purchase a book from an online bookstore, you trade money (in the form of credit) for a book. If your credit is good, a series of related operations ensures that you get the book and the bookstore gets your money. However, if a single operation in the series fails during the exchange, the entire exchange fails. You do not get the book and the bookstore does not get your money.

The technology responsible for making the exchange balanced and predictable is called transaction processing. Transactions ensure that resources are not permanently updated unless all operations within the transaction complete successfully. By binding a set of related operations together in a transaction that either completely succeeds or completely fails you can vastly simplify error recovery.

When a transaction updates data on more than one networked computer, it is called a distributed transaction. Many aspects of a distributed transaction are identical to a transaction whose scope is a single database.

As you might expect, providing a transaction across multiple systems requires more coordination. Each computer participating in the transaction manages its own resources and data, but also acts in concert with other computers in the transaction. Above all, a distributed transaction must commit or abort its work entirely on all participating computers.

As a transaction processing monitor, COM+ reduces the complications associated with distributed transactions. For example, through the Microsoft Distributed Transaction Coordinator (MS DTC), COM+ uses the OLE Transactions protocol to coordinate transactions that span multiple networked computers. COM+ also supports transaction coordination by X/OPEN XA-compliant transaction managers.

On Windows 2000, MS DTC is a system service tightly integrated with COM+. In essence, to help make distributed transactions work more seamlessly, COM+ directs MS DTC on behalf of an application. This makes it possible to scale transactions from one to many computers without adding special code.

When a COM+ application requires a transaction that will span multiple computers, MS DTC provides it by generating a transaction ID, managing transaction-related communications, and enlisting resources. As MS DTC enlists a resource in a transaction, it extends the transaction's protection to that resource.

Used only in distributed transactions, the two-phase commit protocol ensures that the outcome of a transaction is consistent across all transaction managers participating in the transaction. As the name suggests, the protocol operates in distinct phases to ultimately commit or abort a transaction.

Phase one of the two-phase commit protocol evaluates the condition of each resource manager. The coordinating transaction manager (TM) communicates with each local TM to determine if the local resource managers (RMs) are prepared to commit the transaction. To be prepared, a resource manager must guarantee that it can commit the update. Each RM responds that it can (yes) or cannot (no) guarantee its results.

Phase two completes the transaction. Based on the response from each RM, the coordinating TM instructs all participating resources to commit the transaction if all agree, or roll back the transaction if at least one disagrees. Regardless of the instruction (commit or abort), each RM complies and responds when it is done.

Just-in-Time (JIT) Activation

Just-in-Time (JIT) activation is an automatic service provided by COM+ that can help you use server resources more efficiently, particularly when scaling up your application to do high-volume transactions. When a component is configured as being JIT activated, COM+ will at times deactivate an instance of it while a client still holds an active reference to the object. The next time the client calls a method on the object, which it still believes to be active, COM+ will reactivate the object transparently to the client, just in time.

The advantage of doing this is that you enable clients to hold references to objects for as long as they need them, without necessarily tying up server resources such as memory to do so. Other benefits include the following:

It greatly simplifies the programming model from the client perspective. The client doesn't have to reason whatsoever about how it uses expensive server objects. Without JIT activation, clients have to consider how they are using server resources. When clients are aggressive about releasing server objects, they can incur a significant penalty in frequently calling and releasing objects.

By holding long-lived object references, clients keep open the channel to the object for as long as they need it. The farther the client is from the server, the greater the cost of activating and marshaling the server object opening the channel, setting up the proxy and stub, and so on. With distributed applications, an expensive network round trip is required with every object creation. As the volume of client calls increases, you want to minimize the frequency of object creation, as it can significantly affect the performance of your application.

When you JIT activate those objects to which clients hold long-lived references, but which they aren't necessarily using all the time, server memory is not always tied up keeping those objects alive. With lazy activation, memory is used only when the objects are actually needed. This can significantly increase the scalability of your application. The only performance hit that clients see is the time it takes COM+ to reactivate the object usually just marginally more than the time it takes to allocate memory for the object, and substantially less than the network round trip for remote object creation.

Object Pooling

Object pooling is an automatic service provided by COM+ that enables you to configure a component to have instances of it kept active in a pool, ready to be used by any client that requests the component. You can administratively configure and monitor the pool maintained for a given component, specifying characteristics such as pool size and creation request timeout values. Once the application is running, COM+ manages the pool for you, handling the details of object activation and reuse according to the criteria you have specified.

You can achieve very significant performance and scaling benefits by reusing objects in this manner, particularly when they are written to take full advantage of reuse. With object pooling you can:

Speed object use time for each client, factoring out time-consuming initialization and resource acquisition from the actual work that the object performs for clients.

Share the cost of acquiring expensive resources across all clients.

Preallocate objects when the application starts, and before any client requests come in.

Govern resource use with administrative pool management for example, keep open only as many database connections as you have a license for, by setting an appropriate maximum pool level.

Administratively configure pooling to take best advantage of available hardware resources the pool configuration can change as available hardware resources change.

Speed reactivation time for objects that use JIT activation, while deliberately controlling how resources are dedicated to clients.

Queued Components

Queued Components, a key feature of COM+ and based on Message Queuing Services (MSMQ), provides an easy way to invoke and execute components asynchronously. Processing can occur without regard to the availability or accessibility of either the sender or receiver. A shop-at-home television network is an example of asynchronous processing. Viewers call in their purchases and the information is taken by order processors who may or may not be connected to the server. In an asynchronous, disconnected scenario, the orders are taken as quickly as they can be phoned in and are queued for later retrieval and processing by the server.

In the past, an in-depth knowledge of marshaling was necessary to queue, send, and receive asynchronous messages. Queued Components marshals data automatically in the form of an MSMQ message by using method calls that are easily understood and used by component developers. Because Queued Components offers built-in support for transactions, in the event of a server failure an inconsistent state cannot compromise data. Queued Components enhances the COM+ programming model to provide an environment in which components can be invoked either synchronously (real-time) or asynchronously (queued) the component need not be aware of this environment.

In a typical Queued Components scenario, the client calls a queued component. The call is made to the Queued Components recorder, which packages it as part of a message to the server and puts it in a queue. The recorder records all of the method calls for an object. In its role as proxy for the server component, the recorder selects interfaces from the queueable interfaces described in the COM+ catalog. A representation of the recording is sent to MSMQ as a message to be sent to a server. MSMQ accepts delivery of the message only if the client-side transaction commits, the MSMQ queue is transacted, which is the default normally established, and if the queued component itself has one of the transacted attributes 'requires transaction' or 'transaction supported.' In the 'Requires new transaction' case, MSMQ can accept the message even if the client-side transaction aborts.

The Queued Components listener retrieves the message from the queue and passes it to the Queued Components player. The recorder marshals the client's security context into the message and the player unmarshals it at the server side before making the call. The player invokes the server component and makes the same method call. The method calls are not played back by the player until the client component completes and the transaction that recorded the method calls commits.

Security in COM+

COM+ provides a number of security features that you can use to protect COM+ applications, ranging from services you configure administratively to APIs you can call within code. At a glance, these are:

Administratively configured, or declarative, role-based security.

Programmatic role-based security.

Authentication services.

Impersonation/delegation.

The automatic security services that COM+ offers role-based security and authentication make it possible for you to leave all security-related functionality out of your components. Once you can turn on the services and configure them appropriately, COM+ will handle the details of enforcing the security policy that you specify. However, when these automatic services don't do precisely what you need them to do, you can extend them as necessary, building on the automatic security platform provided by COM+.

Which mechanisms you use to secure a given application will depend on the particular requirements of that application. Some security choices can impact how you write components, some can significantly impact the application's design. Before you make any decisions about how to secure an application, you should consider its security requirements in the context of its overall design performance requirements, data access, physical design and choose the most suitable combination of security features.

Brief descriptions of security features and issues are provided in the following table.