Component Configuration

The CORBA component model provides mechanisms to support the concept of component configurability.

Experience has proven that building re-usable components involves mak- ing difficult trade-offs between providing well-defined, reasonably-scoped functionality, and providing enough flexibility and generality to be useful (or re-useful) across a variety of possible applications. Packaging assump- tions of the component architecture preclude customizing a componentÕs behavior by directly altering its implementation or (in most cases) by deriving specialized sub-types. Instead, the model focuses on extension and customization through delegation (e.g., via dependencies expressed with uses declarations) and configuration. Our assumption is that generalized components will typically provide a set of optional behaviors or modalities that can be selected and adjusted for a specific application.

The configuration framework is designed to provide the following capabili- ties:

¥ The ability to define attributes on the component type that are used to establish a component instanceÕs configuration. Component attributes are intended to be used during a component instanceÕs ini- tialization to establish its fundamental behavioral properties. Although the component model does not constrain the visibility or use of attributes defined on the component, it is generally assumed that they will not be of interest to the same clients that will use the compo- nent after it is configured. Rather, it is intended for use by component factories or by deployment tools in the process of instantiating an

¥ The ability to define a configuration in an environment other than the deployment environment (e.g., an assembly tool), and store that con- figuration in a component package or assembly package to be used subsequently in deployment.

¥ The ability to define such a configuration without having to instantiate the component type itself.

¥ The ability to associate a pre-defined configuration with a component factory, such that component instances created by that factory will be initialized with the associated configuration.

¥ Support for visual, interactive configuration tools to define configura- tions. Specifically, the framework allows component implementors to provide a configuration manager associated with the component implementation. The configuration manager interface provides descriptive information to interactive users, constrains configuration options, and performs validity checks on proposed configurations.

The CORBA component model allows a distinction to be made between interface features that are used primarily for configuration, and interface features that are used primarily by application clients during normal application operation. This distinction, however, is not precise, and enforcement of the distinction is largely the responsibility of the component implementor.

It is the intent of this specification (and a strong recommendation to component implementors and users) that operational interfaces should be either provided interfaces or supported interfaces. Features on the component interface itself, other than provided interfaces, (i.e., receptacles, event sources and sinks) are generally intended to be used for configuration, although there is no structural mechanism for limiting the visibility of the features on a component interface. A mechanism is provided for defining configuration and operational phases in a componentÕs life cycle, and for disabling certain interfaces during each phase.

The distinction between configuration and operational interfaces is often hard to make in practice. For example, we expect that operational clients of a component will want to receive events generated by a component. On the other hand, some applications will want to establish a fixed set of event source and sink connections as part of the overall application structure, and will want to prevent clients from changing those connections. Likewise, the responsibility for configuration may be hard to assignÑin some appli- cations the client that creates and configures a component may be the same client that will use it operationally. For this reason, the CORBA component model provides general guidelines and optional mechanisms that may be employed to characterize configuration operations, but does not attempt to define a strict separation of configuration and operational behaviors.

1.9.1 Exclusive Configuration and Operational Life Cycle Phases

A component implementation may be designed to implement an explicit configuration phase of its life cycle, enforcing serialization of configuration and functional operation. If this is the case, the component life cycle is divided into two mutually exclusive phases, the configuration phase and the operational phase.

The configuration_complete operation (inherited from

Components::CCMObject) is invoked by the agent effecting the configuration to signal the completion of the configuration phase. The InvalidConfiguration exception is raised if the state of the component configuration state at the time configuration_complete is invoked does not constitute an acceptable configuration state. It is possible that configuration may be a multi-step process, and that the validity of the configuration may not be determined until the configuration process is complete. The configuration_complete operation should not return to the caller until either 1) the configuration is deemed invalid, in which case the InvalidConfiguration exception is raised, or 2) the component instance has performed whatever work is necessary to consolidate the final configuration and is prepared to accept requests from arbitrary application clients.

In general, component implementations should defer as much consolida- tion and integration of configuration state as possible until

configuration_complete is invoked. In practice, configuring a highly-con- nected distributed object assembly has proven very difficult, primarily because of subtle ordering dependencies that are difficult to discover and enforce. If possible, a component implementation should not be sensitive to the ordering of operations (interface connections, configuration state changes, etc.) during configuration. This is one of the primary reasons for the definition of configuration_complete.

1.9.1.1 Enforcing exclusion of configuration and operation

The implementation of a component may choose to disable changes to the

configuration after configuration_complete is invoked, or to disable invocations of operations on provided interfaces until configuration_complete is invoked. If an implementation chooses to do either (or both), an attempt to invoke a disabled operation should raise a BAD_INV_ORDER system exception.

Alternatively, a component implementation may choose not to distinguish between configuration phase and deployment phase. In this case, invocation of

configuration_complete will have no effect.

The component implementation framework provides standard mechanisms to support disabling operations during configuration or operation. Certain operations are implemented by the component implementation framework (see Chapter 3 - CCM Implementation Framework) and may not be disabled.