Packages

As you'll recall from our brief glimpse at packages in Chapters 4 and 7, conceptually a package is a set of COM classes that perform related application functions. Packages are the primary administrative units in MTS. They also 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 machine. A package can be installed on multiple machines to distribute the workload for large numbers of clients.

NOTE

---

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

By default, the MTS administrative tools install all COM classes in a component in the same package. The MTS administrative tools also use the term "component" to mean the same thing we mean by "COM class." For consistency with the MTS administrative tools user interface and documentation, in the remainder of our discussion of packaging, we'll assume that all COM classes in a component are installed in the same package and 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. (These registry entries were discussed in Chapter 2.) In MTS 2.0, the catalog is implemented using the Microsoft Windows system registry. When you create a package and add components to it using the MTS administrative tools, you are adding information to the MTS catalog.

To facilitate moving packages from one machine to another, MTS enables you to save all the information about a package to a file. These package files, which have the extension .PAK, are text files containing all the catalog entries for a package and its roles, components, and interfaces, as shown in Figure 10-1. Package files do not contain the components' DLLs, but they do contain references to all the DLLs so that the MTS administrative tools can locate and register the DLLs appropriately.

To enable MTS to use packaged components, developers must ensure that each component is 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 machine. All COM classes and interfaces in the component must be described by a type library. Most programming tools that support COM produce components that meet these requirements.

Figure 10-1. An exported MTS package file.