6.1. Application Resource Model¶
RTI services are described through a hierarchical application resource model. In this model, an application is composed of a set of Resources, each representing a particular component within the application. Resources have a parent-child relationship. Figure 6.1 shows a general view of this concept.
Each application specifies its resource model by indicating the available resources and their relationship. A Resource is determined by its class and a concrete object instance. It can belong to one of the following categories:
- Simple–Represents a single object.
- Collection–Represents a set of objects of the same class.
A Resource may be composed of one or more Resources. In this relationship, the parent Resource is composed of one ore more child Resources.
6.1.1. Example: Simple Resource Model of a Connext DDS Application¶
Figure 6.2 depicts a UML class diagram to provide a generic resource model for Connext DDS applications.
In this diagram, the composition relationship is used to denote the parents and children in the hierarchy. The direct relationship denotes a dependency between resources that is not parent-child.
6.1.1.1. Resource Identifiers¶
A resource identifier is a string of characters that uniquely address a
concrete resource object within an application. It is expressed as a
hierarchical sequence of identifiers separated by /
, including all the
parent resources and the target resource itself:
where each individual identifier references a concrete resource object by its name. The object name is either:
- Fixed and specified by the resource model of the parent Resource class.
- Given by the user of the application. This is the case where the parent resource is a collection in which the user can insert objects, providing a name for each of them.
The individual identifier can refer to one of the two kinds of resources, simple and collection resources. For example:
/collection_id1/resource_id1/resource_id2 |
If the identifier refers to a collection resource, the following child identifier must refer to a simple resource. Both simple and collection resources can be parents (or children). In the previous example, resource_id1 is a simple resource child of collection_id1; it is also the parent of resource_id2.
The hierarchy of identifiers is known as the full resource identifier path, where each resource on the left represents a parent resource. The full resource identifier path is composed of collection and simple resources. Each child resource identifier is known as the relative resource to the parent.
The resource identifier format follows these conventions:
- The first character is
/
, which represents the root resource and parent of all the available resources across the applications. - A collection identifier is defined in lower
snake_case
, and it is always specified by the resource class. - A simple resource identifier is defined in
camelCase
(lower and upper) and may be specified by both the resource class or the user.
6.1.2. Example: Resource Identifiers of a Generic Connext DDS Application¶
Consider the Connext DDS application resource model in Section 6.1.1. The following resource identifier addresses a concrete DomainParticipant named “MyParticipant” in a given application:
/domain_participants/MyParticipant
In this case, “domain_participants” is the identifier of a collection resource that represents a set of DomainParticipants in the application and its value is fixed and specified by the application. In contrast, “MyParticipant” is the identifier of a simple resource that represents a particular DomainParticipant and its value is given by the user of the application at DomainParticipant creation time.
The following resource identifier addresses the implicit Publisher of a concrete DomainParticipant in a given application:
/domain_participants/MyParticipant/implicit_publisher
where “implicit_publisher” is the identifier of a simple resource that represents the always-present implicit Publisher and its value is fixed and specified by the DomainParticipant resource class.