- Moving Components from MTS to COM+
- Architectural Changes
- New Interfaces
- New Services
- Article.SetComplete
Architectural Changes
It’s not surprising to learn that COM+ takes the best features of MTS and builds them into the COM infrastructure in order to provide tighter integration and simplify life for both the operating system and the developer. After all, MTS was developed and shipped as part of the NT Option Pack after NT 4.0, and as a result, it had to fool the COM Library in order to work its magic. Three of these changes include the method of interception, automatic deactivation, and use of the Registry.
Both MTS and COM+ use a technique called interception in order to provide a layer of abstraction between the client and the component. This provides the opportunity to add a variety of run-time services. In other words, when a base client (such as an executable program) asks for an instance of a component, MTS and COM+ intercept the call, create the instance, and hand the client a pointer to the object. While this general technique remains the same, the details differ.
In MTS, the interception is performed by a separate context wrapper object, which stores all MTS-related information for the object and through which all calls to and from the object must pass. In COM+, interception and activation are more complex. When a client asks for an instance of a configured COM+ component, the COM+ Library consults the COM+ Catalog and creates a set of policy objects on both the client and the server that identify the set of services the component will use. Examples of the services implemented through these policies include synchronization and JIT. When the object is instantiated, the component instance is automatically created within a COM+ context that contains all the COM+-related information pulled from the COM+ Catalog and policy objects. You can think of contexts as subdivisions within a process where objects live that require the exact same set of services. Each context stores information about the services and their state that objects within the context will use. This architectural difference between MTS and COM+ can be seen in Figure 2:
){kind=link}
Figure 2: Differences in the MTS and COM+ architectures
Fortunately, the programming model that is exposed in the COM+ Services Type Library is backward compatible with the MTS object model. For example, the IObjectContext interface is still used to provide the component with information about the context in COM+, just as it provided information about the context wrapper in MTS. However, you’ll notice in that Figure 2, calls into and out of a COM+ object automatically pass through context-aware proxies where COM+ can make decisions about transaction enlistment and other run-time services. In MTS, the context wrapper is not necessarily notified; developers must also ensure that it receives information about the calls using the CreateInstance and SafeRef methods so that the context information can be included in the call.
For example, consider a method called Transfer in a banking component that calls Deposit and Withdraw methods, which are housed in a different component. In MTS, you had to use the CreateInstance method in order to ensure that when the Bank.Services object was created, the context information from the context wrapper (such as the status of a DTC transaction) was carried along, and that the object was enlisted in the caller’s transaction upon activation. Without this information, the database changes made by the Bank.Services object would not be coordinated with any other work done by the Transfer method.
Dim objctx as ObjectContext Dim objBank as Bank.Services Set objctx = GetObjectContext Set objBank = objctx.CreateInstance(“Bank.Services”) objBank.Deposit strAccount, dblAmount objBank.Withdraw strAccount, dblAmount
In COM+, however, you can simply use the standard CreateObject function and COM+ will automatically create a context-aware proxy and stub that determine which services (including transaction enlistment) the component will use.
Set objBank = CreateObject(“Bank.Services”)
CreateInstance is still supported for backward compatibility, and you can also use the New operator instead of CreateObject. However, keep in mind, that using New when instantiating a component that exists in the same DLL as the caller instructs VB to use an optimized method to create the object, therefore bypassing the COM+ Library and its Service Control Manager (SCM). This results in an object that will not be able to participate in the transaction. Because calls always pass through the COM+ context, you also no longer have to use the SafeRef method to generate a reference for an object you want to pass outside a component.
A second architectural change is the timing of deactivation. As you know, MTS introduced the concept of Just-In-Time activation, or JIT. JIT allows MTS to destroy objects once they have completed their work and rebuild them on demand without the client knowing or caring about this process. This technique is primarily used to ensure transactional consistency, but it can also be used independently. However, in order for JIT to take place, you must explicitly call the SetAbort or SetComplete methods of the IObjectContext interface within each method of your component.
Dim objctx As ObjectContext
On Error Goto MyErr
Set objctx = GetObjectContext
‘ … do your work here
objctx.SetComplete
Exit Sub
MyErr:
‘ Failed so abort
objctx.SetAbort
In COM+, because the context information is always available, you can use the Component Services snap-in to configure each method of a component to trigger a deactivation of the object when the method completes (as shown in Figure 3). This allows components that do not explicitly contain calls to SetAbort and SetComplete (such as third-party components for which you do not have the source code) to participate in JIT. This feature also automatically calls the equivalent of SetAbort if the method raises an error.
){kind=link}
Figure 3: The method properties dialog of the Component Services Manager allows deactivation to be administratively configured.
You may also be aware that COM+ now supports object pooling as well as JIT, as foreshadowed by the CanBePooled method of the ObjectControl interface available in MTS. Object pooling allows COM+ to create a pool of objects from which to choose when a client requests an instantiation. Unfortunately, components created in VB 6 cannot take advantage of this service because it requires the components to support the Neutral Threaded Apartment (NTA) architecture rather than the simpler Single Threaded Apartment (STA). Look for this feature to be added to VB 7.
Finally, you’ll notice that the Registry entries that are associated with configured components in COM+ differ from those that are required for registered components in MTS. When a component is registered with MTS as a Server application, its HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID key is modified by MTS to look like this:
{CLSID for component}
InProcServer32=””
LocalServer32=”c:\winnt\system32\mtx.exe /p:{package GUID}”
In this case, the InProcServer32 key was blanked out, and the LocalServer32 key that was created contained the new activation string that pointed to the host executable. This explicit call to the host executable MTX.EXE was required because the NT 4.0 SCM did not know anything about MTS and its services. This arrangement also required that the MTS Explorer and the MTS VB Add-In make options available that ensure that these Registry entries remain correct in the event that you recompile the component on the server or register it using REGSVR32.EXE. Of course, doing either of these things will, of course, rewrite the Registry as if the component were a traditional component running as an in-process server. In COM+, Registry entries are identical for configured and non-configured components, so recompiling the component on the server does not cause problems. The COM+ Catalog contains the additional settings for configured components.