COM+ Administration: Understanding the Component Services Administrative Tool

Article
12/09/2009

By Richard Ersek and Ken Jones Microsoft Corporation

Two UIs in One

When an early test version of COM+ was introduced at Microsoft's 1998 Professional Developer's Conference, we were confronted one evening by an upset programmer. "What is Microsoft trying to do?" he said. "Put us out of business?" At a four-day conference packed with sessions targeted specifically to the over 6000 developers in attendance, this seemed an odd question. Still, we were curious. "Why do you say that?" "Well," he continued, "just look at your new COM+ UI. It lets a system admin do just about anything. They won't need us anymore."

We assured the gentleman that his job was safe. In fact, as a Windows DNA developer, he was perhaps more valuable than ever. And we'd like to start this article making the same assurances to you, the system administrator. At first glance, the new COM+ UI – or, more formally, the Component Services administrative tool – may seem overwhelming. There's so much you can do with it, including setting attributes down to the component level, and even beyond that to the level of a component's interfaces and methods.

But the Component Services administrative tool becomes much less intimidating, and much more versatile, when you consider its dual functionality. It's designed as an all-in-one UI for both the system administrator and the applications developer. In this article, we'll introduce you to the tool's administrative functions, and show you briefly how it can make a system administrator's job much easier. Since this is an overview, we'll explain the tasks conceptually without providing detailed procedures. (For these procedures and further information, see the Component Services Administration Help.)

compl01

First, we'll start by describing a few of the major changes between MTS and COM+. Then we'll discuss how the Component Services administrative tool can be used for three of the most common system administrative tasks:

Deploying applications
Setting role-based security and an application's security identity
Managing object pooling for optimum system performance.

From MTS to COM+

Many IIS users are already familiar with Microsoft Transaction Server (MTS) and its UI, the MTS Explorer. COM+ can be thought of as a set of services that combine traditional COM with MTS on Windows 2000 systems. With the introduction of COM+, the functionality of MTS has been merged into the operating system. As you'll see, COM+ also expands on and enhances the services that were available with MTS.

If you've been using MTS and the MTS Explorer, you'll notice a few major changes when you start the Component Services administrative tool. Most prominently, MTS packages are now called COM+ applications.

The idea of COM applications is not at all new. It's simply the term used to refer to groups of COM components developed to work together. With traditional COM applications, components must be installed by configuring entries in the Registry before they can be run. This is usually accomplished using the Regsvr32 utility. With COM+, this step is automatically performed for your components when you configure them as a COM+ application. COM components can still be registered on Windows 2000 using the Regsvr32 utility and will exist in the COM+ environment as unconfigured components. Unconfigured components are not displayed in the Component Services administrative tool and do not make use of the new COM+ services. Nevertheless, when these components are run, they make use of the portions of the COM+ infrastructure provided for running distributed COM+ applications.

COM+ applications consist of one or more COM components. 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 that creates COM objects (which includes packaging and registration code).

compl02

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.

Deploying COM+ Applications

While the application programmer uses COM+ to write components and integrate them as applications, the system administrator's job is generally to install, deploy, and configure COM+ applications and their components. A developer will typically deliver a partially configured COM+ application to the system administrator. Or, the application may be provided externally; for example, when you purchase a COM+ application from an independent software vendor (ISV). The administrator can then customize the application for one or more specific environments (for example, by adding user accounts in roles and server names in an application cluster). Typical administrative tasks include:

Installing the partially configured COM+ application on an administrative machine.
Providing environment-specific attributes, such as role members and object-pool size.
Setting the identity (the Windows 2000 user account) under which a COM+ application will run.
Re-exporting the fully configured COM+ application.
Creating an application proxy (if the application is to be accessed remotely).

Once an application is fully configured for a specific environment, the administrator can then deploy it on test and/or production machines. This involves installing the full, configured COM+ application on one or more machines.

The Component Services administrative tool facilitates the deployment of COM+ applications across multiple servers using the tool's Application Export wizard. You can use the Component Services administrative tool to create installation packages for COM+ applications and application proxies. COM+ generates Windows Installer-compatible installation packages, which in a single file contain all the necessary pieces to install a COM+ application on another machine.

compl03

The .msi file containing a COM+ application can only be installed on computers that support COM+ 1.0 Services (currently only Windows 2000). As an added benefit, COM+ applications installed using the Windows Installer appear in the Add/Remove Programs control panel, unless the .msi file is modified using a Windows Installer authoring tool.

The .msi file generated by the Component Services administrative tool contains:

Windows Installer tables with COM+ registration information.
An .apl file containing the application's attributes.
DLLs and type libraries that describe the interfaces implemented by the COM+ application's classes.

In addition to the .msi file, the Component Services administrative tool generates a cabinet (.cab) file. This file, in effect, wraps the .msi file, allowing the deployment of the COM+ application through Internet Explorer.

Installing COM+ Application Proxies

In order to access a COM+ server application remotely from another (client) computer, the client computer must have a subset of the attributes of the server application installed, including proxy/stub DLLs and type libraries for DCOM interface remoting. This subset is termed an application proxy.

Through the Component Services administrative tool, you can easily export a COM+ server application as an application proxy. Application proxies generated by COM+ are standard Windows Installer installation packages. After installation, the application proxies appear in the client computer's Add/Remove Programs control panel.

When generating an application proxy, COM+ automatically provides the following information. This information is required for the application proxy to remotely access a COM+ server application.

Class identity information (CLSIDs and ProgIDs); an application proxy supports up to two ProgIDs.
Application identity and relation of classes to applications (AppID).
Location information per application (Remote Server Name).
Marshaling information for all the interfaces exposed by the application (for example, type libraries and proxy/stubs).
MSMQ queue names and identifiers (if the Queued Components service is enabled for the application).
Class, interface, and method attributes, excluding role information.
Application attributes.

Unlike COM+ server applications, application proxies can be installed on any operating system that supports DCOM and Windows Installer. Clients on other Windows platforms can also access COM+ applications running on Windows 2000 servers. On computers that aren't running Windows 2000 (and therefore lacking COM+), only the subset of information required for DCOM remoting is installed. This information is installed into the Windows Registry. When installing an application proxy (.msi file) on computers that aren't running Windows 2000, it is necessary to have Windows Installer running on those machines. Windows Installer is available in redistributable form as part of the Platform SDK.

Setting COM+ Security

Security roles model and enforce an access control policy for a COM+ application. Roles are categories of users that have been defined for the application for the purpose of determining access permissions to the application's resources. The developer assigns the roles (as symbolic user categories) to the application and potentially to finer structures within it — including components, interfaces, methods, or private application resources. These role assignments are then used to determine which user categories have permission to access which elements within the application.

When an application uses role-based security, a caller's role membership is checked on every call into the application. If a caller does not belong to a role having permission to access the item being called, the call will fail. Callers are granted access to the application, or its resources, strictly according to the constraints defined within the roles to which they belong.

The system administrator's job is to populate the roles defined for the application with Windows 2000 user accounts and groups. This is a crucial stage in carrying out the application's security policy. Users must be assigned to the roles that correctly represent their relationship to the data and resources they might access through the application.

The preferred way to populate roles with users is to use Windows 2000 groups. First, you assign a user account to the appropriate groups, and then ensure that the groups are assigned to the appropriate roles. Using Windows 2000 groups to populate roles makes it easier for you to manage large numbers of users.

In enterprise computing environments, it is often difficult to effectively track each user's place within the organization and determine how that maps into the role-based security policy particular to each application. As the number of users, administrators, and applications rises, this task becomes increasingly complicated. The most scalable solution is to assign user groups to COM+ application roles.

Before you assign any groups to roles, you need to be sure that you understand the application's security policy. Ideally, roles should carry names that suggest who should belong to them, such as "Managers" and "Tellers." In addition, there are descriptions for each role that you can access using the Component Services administrative tool that may describe what kinds of users should belong to the role. However, if you are not sure which user groups belong in which roles, consult the documentation that accompanies the application or ask the developer for clarification.

compl04

You can use the Component Services administrative tool both to make the initial assignments to roles during application installation and to make any necessary changes in role membership during the application's lifetime.

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.

compl05

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 administratively configure pooling to take best advantage of available hardware resources. The pool configuration can change as available hardware resources change. You can also govern resource use with administrative pool management.

When you configure a component to be pooled, COM+ will maintain instances of it in a pool, ready to be activated for any client requesting the component. Any object creation requests will be handled through the pool manager.

When the application starts, the pool will be populated up to the minimum level that you have administratively specified, as long as object creation succeeds. As client requests for the component come in, they are satisfied on a first-come first-served basis from the pool. If no pooled objects are available, and the pool is not yet at its specified maximum level, a new object is created and activated for the client.

When the pool reaches its maximum level, client requests are queued. Each request receives the first available object from the pool. The number of objects, both activated and deactivated, will never exceed the maximum pool value. Object creation requests will time out after an administratively specified period, so that you can control how long clients will wait for object creation. Whenever possible, COM+ will attempt to reuse an object once a client releases it, up until the pool reaches its maximum level.

You can use the maximum pool size to govern very precisely how you use resources. For example, if you have licensed a certain number of database connections, you can control how many connections you have open at any time.

When you take into consideration client use patterns, object use characteristics, and physical resources such as memory and connections, you are likely to find some kind of optimal balance when you do performance tuning. Pooling objects will yield diminishing returns after a certain point. You can determine what level of performance you require and balance that against what resources are necessary to achieve it. With pooling you have control over resource use.

Making COM+ Administration Easier

We hope this article has given you a good overview of the new Component Services administrative tool. And we hope it's shown you how the tool's design makes it easier to administer COM+ applications across remote computers. We look forward to your questions, comments, and ideas for future articles.

For those of you seeking more detailed information on COM+, we are blessed with a wealth of resources. The following books are particularly recommended. While these books are targeted mainly to developers, they also present valuable information for system administrators.

Understanding COM+ by David S. Platt (Microsoft Press, 1999)

Designing Component-Based Applications by Mary Kirtland (Microsoft Press, 1999)

Programming Distributed Applications with COM and Microsoft Visual Basic 6.0 by Ted Pattison (Microsoft Press, 1998)