Calling MTS Components from Visual Basic Clients

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.