View on GitHub

Chapter 8
Services

8.1 Introduction

In the context of REDHAWK, infrastructure software is managed by the Device Manager. Infrastructure software can take two forms: hardware management and system Services. Hardware management is discussed in Chapter 9. System Services are the equivalent to Linux services like an Hyper Text Transport Protocol (HTTP) server; the Service does not directly control hardware but is some facility that becomes automatically available when the host is started.

8.2 Management

A Service is managed through the Device Manager. In Chapter 9, Nodes are described as a Device Manager instance and the set of Devices and Services associated with that Device Manager instance. When the Device Manager instance is created, it reads its configuration file (dcd.xml), which contains a list of all Devices and Services that the Node contains. The Devices and Services are forked as individual processes and remain running until the Device Manager is shut down. Devices are bound to the Naming Service under the Device Manager’s context. Services, on the other hand, are bound to the Domain’s naming context.

8.3 Files Defining a Service

A Service, much like a Component or Device, is a binary file and a set of XML descriptors, normally just the SPD (describing the Service’s software package) and SCD (describing the Service’s interfaces). The Service file package resides in $SDRROOT/dev, usually in a services subdirectory or the devices subdirectory.

8.4 Service API

REDHAWK does not include any standard Service interfaces; the SCA specification includes a logging service, but in REDHAWK logging is performed through log4j/log4cxx, as described in Chapter 13, not a Service. To use a Service, it either needs to use one of REDHAWK’s standard interfaces or it needs to implement a specialized interface supporting some specific behavior.

As discussed in Section 8.2, a Service is created and torn-down by the Device Manager. Because there is no defined interface for the Service, Services do not support the LifeCycle interface, and more importantly, the releaseObject() method. Since there is no release method, the Device Manager issues operating-system level signals to terminate the Service. It is the Service’s developer’s task to perform whatever cleanup functionality needs to be performed in response to the receipt of a signal from the operation system.

8.5 Finding a Service

In Chapter 11 Application descriptor files (sad.xml) are described; these files describe a logical collection of Components that are deployed to support some system-level Application. In the Application descriptor file, connections between deployed entities can be described in a variety of ways. These connection descriptions are how an Application, or more specifically a Component in an Application, can interact with a Service.

The Find By feature enables users to find Services through either their (globally unique) name or by the interface that they support. Using a globally unique name as the search key allows a developer to specify an single instance of a Service to connect to. On the other hand, by searching for a Service through its supported interface, a developer can create a generalized search for a service that satisfies a particular need, irrespective of how it is associated with the Domain. For more information about the Find By feature, refer to Section 11.4.7.


Creative Commons License
REDHAWK Documentation is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.