Moving Components from MTS to COM+
- Moving Components from MTS to COM+
- Architectural Changes
- New Interfaces
- New Services
- Article.SetComplete
Okay, the Windows 2000 hoopla has subsided, and after much procrastination, you’re finally getting around to researching how to move the scores of VB components your team has written from MTS to COM+. In this article, I’ll walk through a few of the most significant changes (broken down by category) to get you started.
Although the name has changed (thankfully, because the name MTS attributed to a fundamental misunderstanding of the product), the purpose of COM+ remains the same: to provide a run-time environment and a set of services (of which, transactions are only one) for COM components that enable the development of multi-tiered distributed applications. You can think of COM+ as MTS version 3.0, albeit with plenty of subtle and some not-so-subtle changes.
Get Your Terms Straight
Right from the start, you’ll notice that COM+ is administered through the Component Services snap-in (shown in Figure 1) instead of the MTS Explorer. Each “package” in MTS is now called an “application,” and as before, each serves the function of security and isolation when configured as a “Server application” in the Activation tab of the Properties dialog box. When it’s running as a Server application, components within the application run in a separate process, which is now hosted by instances of DLLHOST.EXE instead of MTX.EXE. As in MTS, components within an application can be alternatively loaded into the process of their creator when the application is configured as a “Library application.”
){kind=link}
Figure 1: Component Services
In COM+, you’ll also run across the terms “configured” and “non-configured” as they are related to components. Simply put, a configured component is one that has been registered with the Component Services snap-in; a non-configured component has not been registered as such. (You additionally hear these referred to as “COM+ components” and “COM base components,” respectively, although I think “configured” is more descriptive.) Configuring a component allows the COM+ Library (the set of system software that underlies COM+ and provides APIs to register and create component instances), to store additional information about the component in the COM+ Catalog, which is a binary database of information that is now separate from the Registry. The COM+ Catalog is then used by the COM+ Library to determine which services the component will use and how the component will be instantiated. This arrangement is analogous to MTS, where you think of a component that is registered with MTS as “configured.” However, behind the scenes, the two methods differ. By the way, you can also programmatically administer the COM+ Catalog from within a VB application using the COMAdminCatalog component and its associated collections. For more information on automating administration, see http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/cossdk/pgadminobjectstoplevel_959v.htm.