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

../_images/ArmGeneralView.png

Figure 7.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.

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

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

../_images/ArmExampleDds.png

Figure 7.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.

7.1.2. 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.

7.1.2.1. Escaped Identifiers

An identifier can be escaped by enclosing it within double quotes ("). For example:

/”escaped_identifier”

An escaped identifier is interpreted as a whole and indivisible unit. Escaping a resource identifier is useful; it is also required when the identifier contains the resource separator / or the custom method separator :.

For example, the following full resource path:

/resource_1/"escaped/resource_2"

is composed of two relative resources, resource_id1and escaped/resource2. The use of the double quotes to escape the identifier indicates that the enclosing string shall be interpreted as a single identifier, and therefore Routing Service ignores the resource separator. If the identifier was not escaped, then Routing Service would interpret the resource path as two separate relative resources.

Any time an RTI service sees a resource separator character (/) or the custom method separator : in an entity name (such as in the attribute name), it automatically escapes the name when it constructs the resource identifier. For example:

<service name="A/B">

<service name="A:B">

becomes

/routing_service/"A/B"

/routing_service/"A:B"

in the resource identifier.

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

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

7.1.2.3. Example: Resource Identifiers Generated from XML Entity Model

Consider the following XML configuration that models a generic RTI service:

<service name="MyService">
    <entity_class1 name="MyEntity1"> ... </entity_class1>
    <entity_class1 name="Domain/MyEntity2"> ... </entity_class1>
</service>

The resulting generated resource identifiers will look as follows:

/service/MyService/entity_class1/MyEntity1
/service/MyService/entity_class1/"Domain/MyEntity2"