Windows 2000 COM Services

In the preceding sections, we have looked at the Microsoft technologies that can be used to build component-based three-service layered distributed applications. Central to the Microsoft strategy is a programming model based on COM and on MTS. In September 1997, Microsoft announced that COM and MTS would be unified in the future. The name given to this unified set of component services is COM+. The initial release of COM+ will appear in Windows 2000. We'll take a brief look at the features expected to appear in COM+ 1.0 and how COM+ will affect distributed application development.

At the time this chapter was written, Windows 2000 and COM+ 1.0 were still in beta release; some details might change prior to release.

In COM+, all objects, remote or local, are created in the same manner. 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 also allows COM+ to intercept calls to the objects created. 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 computer 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.

Unified Programming Model

What the unified architecture means for developers is that they 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, the object context CreateInstance method must be used. In COM+, the normal object creation API functions, such as CoCreateInstanceEx or Visual Basic's CreateObject, may be used. Thus code such as this:

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

would be replaced by code such as this:

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

In addition, COM+ supports a more general moniker-based creation mechanism. Monikers are basically COM objects that provide an inherent naming standard. Developers provide a string name; the moniker then locates the object. While monikers have always been part of COM, COM+ adds a standard moniker that identifies how to create new monikers. The moniker-based method is useful as it can be extended at any time to support new features. Such an extension is possible by simply installing a new moniker component and informing developers about string names compatible with the new moniker. On the other hand, extending a system function like CoCreateInstanceEx to support new features is difficult. With the new moniker, new objects can be created by writing code such as this:

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

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

As in MTS, COM+ emphasizes a declarative, attribute-based model for accessing services. Developers can set attributes using the COM+ administrative services. Attributes and other metadata 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 the required registration information. The information in the component library can be used by the COM+ registration service to register components, eliminating the need to write registration code that directly manipulates registry entries under HKEY_CLASSES_ROOT. Because most of this code is automatically generated by development tools, this feature probably won't affect developers until their 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. Every COM+ object also 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. The object context attribute values can not be controlled at run time; however, developers may query the object context and call the methods it provides to access COM+ services programmatically.

Primary COM+ Services

COM+ is a combination of the COM specification and the addition of COM Services. The primary new and improved services are:

  • Servers
  • Transactions
  • Security
  • Administration
  • Load balancing
  • Queued components
  • Events
  • In-memory database

More information about these services is presented in Case Study 9.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: