It has already been said—in so many words—that calling
an MTS component does not require a huge learning curve for the developer. The
reason for this is that the details of where the component is running are by and
large hidden from the developer. MTS components are always COM objects. Previous
chapters provided examples of developing with a variety of COM objects such as
ActiveX controls, in-process ActiveX DLLs, and ActiveX EXEs that run in a separate
process from the caller. Although these types of COM objects might differ subtly,
developing with them is essentially the same. That is, in VB terms, it entails
working with properties, methods, and events.
Knowledge of COM objects easily transfers to MTS objects. Also,
like other COM object types, the operating system handles the details of how the
object is instantiated. Again, if you create an instance of an object that is
in a DLL, you don’t need to know the location of the DLL, or even that the
object is in a DLL.
After your project has a reference to the component, you need
only to write the code to create the instance of the object by its familiar classname.
COM services, which are integrated into the operating system, will do the work
of looking up the class information in the Registry and executing the appropriate
code in the appropriate DLL. This is true if the object is contained in a component
implemented in the form of an EXE or an OCX.
The same principle applies to COM objects in an MTS setting. Rather
than look for a local DLL or EXE file, however, it will make the call to a Transaction
Server (which could be the local machine or a remote machine) and the Transaction
Server will handle the request to instantiate the object. The first step for the
developer who is already familiar with calling COM objects is to learn how to
enable a client computer to call MTS objects.
Creating Packages That Install or Update MTS
Components on a Client
Configuring a Client Computer to Use an MTS