Packaging with MTS

Packages are a set of COM classes that perform related application functions. They are also the primary administrative units in MTS that define process and security boundaries.

Two types of packages are available in MTS: library packages and server packages. A library package runs in the process of the client that uses its COM classes. A server package runs as a separate MTS-managed process. Each COM class can be installed in only one package on a given computer. A package can be installed on multiple computers to distribute the workload for large numbers of clients.

NOTE

---

It is possible for a component to include multiple COM classes installed in different packages. In general, this practice should be avoided. COM classes in a single component usually have interdependencies that may work only if the classes' objects run in the same process. In addition, splitting classes across packages complicates administration and maintenance.

By default, the MTS administrative tools install all COM classes in a component into a single MTS package. The MTS administrative tools also use the term "component" synonymously with COM's definition of "COM class." For consistency with the MTS administrative tools (UI) and documentation, we'll assume that, when discussing packaging, all COM classes in a component are installed in the same package. Furthermore, we'll refer to performing administrative tasks on components rather than on COM classes.

In physical terms, a package is a collection of DLLs and MTS catalog entries. The MTS catalog stores configuration information for packages, components, interfaces, roles, and so on. This information supplements the registry entries defined by COM. In MTS 2.0, the catalog is implemented using the Windows system registry. When developers create a package and add components to it using MTS administrative tools, they are adding information to the MTS catalog.

To facilitate moving packages from one computer to another, MTS allows all information about a package to be saved to a file, as shown in Figure 8.3. Such package files, which have the extension .pak, are text files containing all catalog entries for a package and its roles, components, and interfaces. Package files do not contain the components' DLLs, but they do contain references to all DLLs so that MTS administrative tools can locate and register the DLLs appropriately.

To enable MTS to use packaged components, each component must be implemented as a DLL. The component must implement the DllRegisterServer function, registering the component's CLSIDs, ProgIDs, interfaces, type library, and any other registry entries the component requires for proper operation. MTS will call this function to register the component when the package is installed on a server computer. A type library must describe all COM classes and interfaces in the component. Most programming tools that support COM produce components meeting these requirements.

Figure 8.3 Exported MTS package file