1.3.2 Catalog

A catalog is a data store that holds configuration for a single ORB, hereafter known as the target ORB. A COMA catalog organizes the configurations as hierarchically structured collections of various types of configurable objects. Most of the configuration in the catalog can be understood in terms of the following object types: component, component configuration entry, conglomeration, partition, and machine settings. The following Unified Modeling Language (UML) [UML] diagram shows the relationships between these types of objects.

Relationship between objects in the catalog

Figure 1: Relationship between objects in the catalog

A component is an indivisible unit of software functionality. Examples of components include DCOM object classes [MS-DCOM] and event classes described in [MS-COMEV]. Each component known to the server is identified by a GUID, known as the class identifier (CLSID).

A component configuration entry represents a particular configuration of a component. In general, it is possible for a component to have more than one component configuration entry on a server. It is also possible for a component to have no component configuration entries, in which case it is said to be an unconfigured component.

A conglomeration is a collection of component configuration entries for components that a component developer or administrator wishes to be managed as a group, and is identified by a conglomeration identifier. A component that has a component configuration entry in a conglomeration is said to be configured in that conglomeration. A conglomeration also has a set of configuration properties that apply to members of the collection. The conglomeration model assumes that component developers and administrators group together components based on application architecture, administrative policies, and performance concerns related to the shared use of system resources.  Most of the configuration exposed by [MS-COMA] at the conglomeration level is therefore related to broad-level security policy, such as role membership (section 1.3.4), and configuration of shared system resources such as compensating resource managers (section 3.1.1.1.1) and queue listeners (section 3.1.1.1.5). Some conglomeration-level configuration properties might not apply to all component configuration entries, as explained in more detail in the sections that follow.

There are two types of component configuration entries, component legacy configuration entries and component full configuration entries, each of which has a different purpose and a different set of configuration properties. Component full configuration entries support configuration for the full set of services provided by the target ORB. Component legacy configuration entries, if supported by the target ORB, enable configuring a component to be part of a conglomeration, where for technical reasons it might not be possible or desirable to create a component full configuration entry for the component.

Many of the configuration properties of component full configuration entries are not supported by component legacy configuration entries. For example, component legacy configuration entries do not have properties for synchronization or queuing. Additionally, some of the configuration properties of conglomerations do not apply to component legacy configuration entries. Component legacy configuration entries do however have equivalent configuration properties at the component level for a subset of configuration, such as user identity and authentication level, that is usually managed at the conglomeration level.

Types of component configurations

Figure 2: Types of component configurations

A partition is a container for conglomerations and is identified by a partition identifier. Every server has at least one partition, the global partition, and can have additional partitions and support the creation of new partitions. Multiple partitions on a server enable multiple configurations of a component. Component configuration entries for a component are subject to the following constraints:

  • There can be at most one component configuration entry for any one component in a single conglomeration.

  • Only conglomerations in the global partition can contain component legacy configuration entries.

  • There can be at most one component configuration entry in the conglomerations in each partition that is associated with a given component, or at most one per bitness, if multiple bitnesses are supported (section 1.3.5).

  • A component that has a component legacy configuration entry cannot have any other component configuration entries, or no other component configuration entries for the same bitness, if multiple bitnesses are supported (section 1.3.5).

The singleton machine settings object represents machine-wide configuration for the server.