11.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 11.1 shows a general view of this concept.

../_images/ArmGeneralView.png

Figure 11.1 Application modeled as a set of related Resources

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.

11.1.1. Example: Simple Resource Model of a Connext DDS Application

Figure 11.2 depicts a UML class diagram to provide a generic resource model for Connext DDS applications.

../_images/ArmExampleDds.png

Figure 11.2 Connext DDS application resource model

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.

11.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:

\[{/resource\_id_1/resource\_id_2} ... {/resource\_id_N}\]

where each individual identifier references a concrete resource object by its name. The object name is either:

  1. Fixed and specified by the resource model of the parent Resource class.
  2. 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.

11.1.2. Example: Resource Identifiers of a Generic Connext DDS Application

Consider the Connext DDS application resource model in Section 11.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.