How to use the COM object broker
Microsoft Transaction Server (MTS) is middleware technology for Windows NT that handles several features for COM components. First and foremost, MTS is an object broker. MTS manages the instantiation (creation) and destruction of objects when another application requests them. MTS is also a transaction-processing system and an object repository that holds references to the objects registered in it. To use MTS, you need to understand how it serves as an interface, manages components, and provides security.
MTS and COM Objects
MTS serves as the interface between COM objects and the applications that use them. Say that a client application uses CreateObject to create the Publication object from Visual Basic (VB) or VBScript:
Set oPubs = CreateObject("Publications.Publication")
This code creates an instance of the Publication object. The OS (NT or Windows 9x) creates the object by looking up the ProgID (Publications.Publication) in the Registry and finding its executable. The executable entry is under the class ID in the HKEY_CLASSES_ROOT\CLSID tree. Under COM or DCOM, NT or Windows 9x uses this information to find and execute the object stored in the component.
COM components can be either in-process or out-of-process. An in-process component executes in the process space of the calling application; an out-of-process component executes in a separate process space. Because MTS works only with in-process components, I won't describe out-of-process components in detail in this article.
Packages
MTS uses a concept called a package to define processes in the MTS system. When you want to use a component with MTS, install it in an MTS package, and MTS will register it. Figure 1 shows the CustomerProcessing package containing two components, Customer and Order. Because the components in a package run in the same process space, they can efficiently pass information back and forth and share the same security context. Packages also provide fault tolerance: If a component fails, it might take down the package it was in, but it won't affect other packages.
The fault isolation achieved through creation of individual packages is especially useful for testing and rolling out new components. If a new component that you place into a separate (or test) package causes a problem, the problem affects only that component or package. After you determine that the component is stable, you can promote it to a production package.
MTS uses the MTS Executive (mtx.exe) to run the components in a package. Because the components run under MTS, MTS can manage them. The object broker services let MTS manage the creation and destruction of objects in a component as needed. Figure 1 illustrates how the components run inside mtx.exe, and how any applications (shown as clients) that use the components access them through MTS. The components are in a package, and mtx.exe manages the interface between the client applications and the objects in a component.
You can also let a package run inside the process that calls an object in an MTS package. For instance, if you set up a package as a library package and an Active Server Pages (ASP) application calls a component in that package, the package executes in the Microsoft Internet Information Server (IIS) process (inetinfo.exe). This results in a large performance gain but less fault tolerance—if an object in a component dies, the inetinfo.exe process dies and every Web application dies with it.
Prev. page
[1]
2
next page 
