Moving Components from MTS to COM+

This article discusses the design changes from MTS and new features of COM+ as it relates to the Visual Basic developer. Use this article to get started porting your applications from MTS to COM+, and taking advantage of its new services.

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.”

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.