Moving Forward with COM and MTS

A key theme common to all the technologies we've discussed in this book is "making it easier"—that is, making it easier for the typical corporate developer to create distributed applications in a timely and cost-effective manner. COM+ builds on and extends COM and MTS to provide an even more powerful and easy-to-use architecture for developing, deploying, and administering highly scalable distributed component-based solutions. At the same time, Microsoft realizes that many companies have already made substantial investments in COM and MTS. Thus, a second key theme for COM+ is leveraging current investments. COM+ is an evolutionary technology that provides a solid foundation for future innovative component services.

A Unified Architecture

One way COM+ makes writing applications easier is by eliminating the distinction between COM and MTS. This distinction arose because MTS was implemented as a service on top of COM rather than as an integral part of COM. As we saw in Chapter 4, MTS provides a surrogate process for hosting MTS components and an executive that provides services to those components. When an object is created, the MTS Surrogate is launched and if necessary the MTS Executive is loaded; the executive then intercepts the creation request and generates a context wrapper for the object that will let MTS intercept calls to the object. MTS also associates an object context with the object during creation. This process is very different from the way COM objects are created.

In COM+, all objects are created the same way. COM+ is built on a general-purpose activation and interception architecture that lets COM+ associate an object context with every object as it's created and intercept calls to the object. During activation, COM+ will use attributes stored with the component or in application configuration information to determine which services, if any, the object uses. These services are built on the activation and interception architecture. COM+ keeps track of which services are in use and determines whether a call to the object requires work on the part of any of the services. If so, the services are automatically invoked at the appropriate point in the call. Instead of using a separate context wrapper to intercept calls, as MTS does, COM+ merges interception into the normal proxy/stub architecture already used to detect calls across apartment, process, or machine boundaries.

Although the architecture is general and all objects have an associated context, only classes implemented in DLL servers can be configured to use the COM+ services. Classes that are configured to use the COM+ services are known as configured classes; all other classes are known as unconfigured classes. Configured classes are hosted by the new COM+ Surrogate, which merges the features of the COM and MTS Surrogates and uses the standard COM Surrogate architecture.

A Unified Programming Model

What the unified architecture means for you as a programmer is that you can use all objects the same way, regardless of whether they use COM+ services. In MTS, to ensure that context information flows from one object to another, you must use the object context CreateInstance method. In COM+, you can just use the normal object creation API functions, such as CoCreateInstanceEx or Microsoft Visual Basic's CreateObject. Thus, instead of writing code that looks like this:

 Dim ctxObject As ObjectContext Dim subObject As IMyInterface Set ctxObject = GetObjectContext() Set subObject = ctxObject.CreateInstance("MyComponentProgID") 

you would write code that looks like this:

 Dim subObject As IMyInterface Set subObject = CreateObject("MyComponentProgID") 

In addition, COM+ supports a more general moniker-based creation mechanism. We haven't yet discussed monikers; basically, they are COM objects that provide a way to name objects. You provide a string name; the moniker finds the object for you. While monikers have always been part of COM, COM+ adds a standard moniker that understands how to create new objects called, appropriately, the new moniker. The moniker-based method is useful because it can be extended at any time to support new features by simply installing a new moniker component and telling developers about the string names the new moniker understands. Extending a system function like CoCreateInstanceEx to support new features, on the other hand, is very difficult. With the new moniker, you can write code such as this to create new objects:

 Dim subObject As IMyInterface Set subObject = GetObject("new:MyComponentProgID") 

Other than these changes to object creation, developers of MTS-based three-tier applications won't see any major changes in writing COM+ applications. COM+ 1.0 is geared toward writing three-tier applications; the programming model it promotes is essentially the MTS programming model. Components that want to use COM+ services must meet the same requirements as they would for running in MTS. All existing MTS components will work without change in COM+.

As in MTS, COM+ emphasizes a declarative, attribute-based model for accessing services. You can set attributes using the COM+ administrative services discussed in the following section, "A Unified Administration Model" Attributes and other meta data about each class are stored in a component library, which supplements the information available in the component's type library. When a component is registered with COM+, information from the component library is cached in a registration database that COM+ uses during activation to determine how to create an object.

The goal of the component library is to make components completely self-describing, including all information needed to register the components. The information in the component library can be used by the COM+ registration service to register your components, eliminating the need for you to write registration code that directly manipulates registry entries under HKEY_CLASSES_ROOT. Because most developer tools generate this code for you, however, this feature probably won't affect you until your developer tools are updated to support COM+. For compatibility with existing components, COM+ will support components that register themselves under HKEY_CLASSES_ROOT as well as components that use the new COM+ registration mechanisms.

As mentioned, every COM+ object has an associated object context, which is associated with the object at creation time; it contains a set of attribute-value pairs that describe the object's execution environment. The exact set of attributes maintained in the object context depends on how the object's class is configured. COM+ uses the object context to determine when specific services must be invoked. The object context is maintained by COM+ itself, based on the service attributes specified for components, classes, and interfaces, as well as the context of the object's caller. You cannot control the object context attribute values at run time. You may query the object context and call the methods it provides, however, in order to access COM+ services programmatically.

A Unified Administration Model

In addition to unifying the programming model, COM+ unites the COM and MTS administration models. A single tool, the COM Explorer, combines the functionality of the DCOM Configuration tool (DCOMCNFG) and the MTS Explorer. The administration model viewed through the COM Explorer is also available programmatically, using a set of scriptable administration objects. (These objects are extensions of the MTS 2.0 administration objects.) Although COM+ 1.0 does not offer a lot of new administrative functionality, the underlying unified administrative architecture has been designed so that future releases of COM+ can provide more flexible and powerful tools for administration and deployment, without requiring massive changes to the model exposed to developers and administrators.

The unified administration model will look very familiar to developers using MTS today, since the model is geared toward three-tier applications. The primary difference is that the terminology has been generalized. Instead of combining components into packages, you combine them into applications. You can create library applications and server applications, just as you create library packages and server packages in MTS. The model has also been enhanced to support the new COM+ services discussed in the following section, "New Services for Enterprise Applications."

You will also see some differences in the way applications are exported. COM+ can export server applications or client applications. Exporting a server application is much like exporting an MTS package, except that an application library (.APL) file is generated instead of a package (.PAK) file. Exporting a client application, on the other hand, takes advantage of new Zero Administration Windows (ZAW) deployment features. When you export a client application, a Microsoft Installer (MSI) application is generated that contains all the "client glue" needed for client machines to connect to your application. The MSI application can be assigned to a group of clients using the ZAW group policy editor and distributed through the Windows NT 5 Class Store. The Class Store is essentially a database that enables centralized deployment and management of applications, components, and services. This technique greatly simplifies the deployment of client applications.