Incorrect terminology used in UAVCAN interface description

[pavel-kirienko]

The UAVCAN node documentation uses the term "service consumer" incorrectly to describe what are in fact UAVCAN RPC-services. This applies both to the English and Russian docs.

The term "service consumer" is used in UAVCAN in the same sense as it is used in service-oriented architectures: a service consumer is a component of the distributed system whose operation is facilitated by another component via a well-defined contract. That latter component is commonly called a "service provider".

It is important to understand that while the terms "RPC-service" and "network service" sound similar, they describe entirely different entities:

• An RPC-service is what you define using the three-dash DSDL notation ---, or like .srv files in ROS. For example, uavcan.node.GetInfo defines an RPC-service.

• A network service is a well-segregated functionality accessible via the network that upholds a certain behavioral contract. For example, this is the definition of the UDRAL ESC service: https://nunaweb.uavcan.org/api/storage/docs/fgsfds/reg/index.html#reg_udral_service_actuator_esc

To quote the Guide:

A given component of a distributed UAVCAN-based computing system is said to provide service if it participates in the data exchange using a specific well-defined set of UAVCAN data types following the formal requirements imposed by their definitions. Usually, this involves publishing messages of well-defined types carrying particular data at specific rates. Also, it may involve responding to UAVCAN service requests as dictated by their data type definitions.

Similarly, a given component is said to consume service if it relies upon the formal contractual obligations upheld by a service provider as defined above. Usually, that involves subscribing to messages of a specific type or making calls (sending requests) to a specific UAVCAN service.

There is an unfortunate linguistic complication in the fact that a service can mean both the type of UAVCAN communication (as opposed to messages) and a higher-level architectural entity. In this piece, we’re mostly focused on the latter.

[PonomarevDA]

Thanks! My mistake. Fixed.