12.5. Plugin Management
Some RTI Services allow for custom behavior through the use of pluggable components or plugins . The type of plugins is described in Software Development Kit. A plugin is represented as a top-level service-owned object whose main role is a factory of other pluggable components, which are responsible for providing the user-defined behavior.
Figure 12.7 shows that for each class of pluggable
components there is a top-level object with the suffix
Plugin. This is the
object that the Service obtains at the moment of loading the plugin. Multiple
Plugin objects can be registered from the same class, each uniquely
identified by its registered name.
Figure 12.7 also shows that there are two mechanisms through which a Service obtains a plugin object: a shared library or the Library API. Both mechanisms are complementary and are described with more detail in the next sections.
12.5.2. Library API
The user provides the plugin object via the Library API, through one of the
attach_[class]_plugin() operations. Upon successful return of
the operation, the Service takes ownership of the plugin object and will
delete it on Service stop.
The plugin lifecycle is as follows:
The user instantiates plugin objects and provides them to the Service through the
attach_[class]_plugin()operation. This is allowed only before the Service starts.
After start, the Service becomes the owner of the registered plugin objects, calls operations on the plugin objects as needed, and keeps them alive while the Service remains started.
On stop, the Service deletes each registered plugin object by calling the class abstract deleter.