The purpose of configuration objects is to provide data for runtime objects. A runtime object is an application specific object that contains both state and behavior that provides an application specific function. This section describes common patterns for runtime objects and some guidelines for managing them.
There are various patterns you can use to define the correspondence between configuration and runtime objects; the following sections discuss some of these patterns.
In many cases, each configuration object is used to create and configure a runtime counterpart. The runtime object can be a Managed Object or a POJO. For example, when a Printer configuration object is activated, the activate notifier method would create a runtime printer object. The configuration data is copied into the runtime object fields.
Similarly, when the configuration object is deactivated, the runtime object is deleted or released. This is the least complex pattern to use, and results in the fewest design and implementation issues.
This pattern is best used when the application quickly locates a runtime object, uses it, and detaches. This pattern is also used when it seems that the existence of the runtime object should be initiated by activating a configuration, and destroyed by deactivating a configuration.
Another pattern is used when a small number of runtime objects have a lifecycle that must be longer than the configuration object. In this case, upon activation, the configuration object should simply locate the runtime object, copy attribute values from the configuration object to the runtime object, and notify the runtime object to take appropriate action based on the configuration change. This pattern is also simple to use.
Another pattern is used when a large number of runtime objects share the same configuration objects. A large number could be thousands, or even millions of runtime objects. This pattern is used when the configuration objects form a repository, as a product catalog might for an example application. The product catalog (configuration data) defines the characteristics of the product, while the runtime objects would represent instances of products. In this case, the runtime objects would attach to the configuration object every time it needs to use the configuration data.
![[Note]](images/note.png) | |
Runtime objects should never cache handles to configuration objects. These handles will become stale when the configuration version state changes. |