RPC Over DDS Avatar
  1. OMG Specification

RPC Over DDS — Open Issues

  • Acronym: DDS-RPC
  • Issues Count: 4
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Consider replacing @Choice annotation with XTYPES 1.2 unions

  • Key: DDSRPC11-4
  • Status: open  
  • Source: Twin Oaks ( Clark Tucker)
  • Summary:

    The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

    Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

    However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

    An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

  • Reported: DDS-RPC 1.0 — Tue, 24 Sep 2019 13:26 GMT
  • Updated: Tue, 24 Sep 2019 13:26 GMT

Remove the 'default' case in Requst and Return union types

  • Key: DDSRPC11-3
  • Status: open  
  • Source: Twin Oaks ( Clark Tucker)
  • Summary:

    Section 7.5.1.1.4 Mapping of Interfaces to the Request Topic Types, and Section 7.5.1.1.5 Mapping of Interfaces to the Reply Topic Types, each define a union and specify that the union should have a 'default:' case.

    This makes it difficult to extend the union to support interface inheritance.

    The 'default:' case should be removed.

  • Reported: DDS-RPC 1.0 — Wed, 12 Dec 2018 23:42 GMT
  • Updated: Wed, 12 Dec 2018 23:42 GMT

Errors in non-normative IDL of section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types

  • Key: DDSRPC11-2
  • Status: open  
  • Source: Real-Time Innovations ( Alejandro Campos)
  • Summary:

    Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

    @Choice @Autoid
    struct RobotControl_command_Result { 
        RobotControl_command_Out result;
    };@Choice @Autoid
    struct RobotControl_stop_Result { 
        RobotControl_getSpeed_Out result;
    };
    };@Choice @Autoid
    struct RobotControl_setSpeed_Result {
          RobotControl_setSpeed_Out result;
          TooFast toofast_ex;
    };
    };@Choice @Autoid
    struct RobotControl_getSpeed_Result {
          RobotControl_getStatus_Out result;
    };
    

    This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places.

    In Addition in IDL42 all annotations are lower case. Specifically @autoid is defined there.

    Therefore the correct IDL would be:

    @choice @autoid
    struct RobotControl_command_Result { 
        RobotControl_command_Out result;
    };
    
    @choice @autoid
    struct RobotControl_stop_Result { 
        RobotControl_getSpeed_Out result;
    };
    
    @choice @autoid
    struct RobotControl_setSpeed_Result {
          RobotControl_setSpeed_Out result;
          TooFast toofast_ex;
    };
    
    @choice @autoid
    struct RobotControl_getSpeed_Result {
          RobotControl_getStatus_Out result;
    };
    
  • Reported: DDS-RPC 1.0 — Thu, 6 Sep 2018 00:04 GMT
  • Updated: Thu, 6 Sep 2018 00:04 GMT

Mapping of one single Topic per Service does not work well with DDS Security

  • Key: DDSRPC11-1
  • Status: open  
  • Source: Real-Time Innovations ( Alejandro Campos)
  • Summary:

    This issue has also been entered into DDS-Security as the solution could also involve changes to that specification. See:
    https://issues.omg.org/browse/DDSSEC12-31

    DDS-RPC maps each DDS-Service to a single (unkeyed) Topic-pair (request topic & reply Topic).

    DDS-Security provides access control per Topic and per Instance (Key). Moreover, the builtin plugins only provide access control per Topic.

    With these mappings is it not possible to configure access control per operation/method in the service. This is a common requirement for many service definitions.

    One way to overcome this would be to provide a mapping where each a Service would map to multiple Topic pairs. E.g. one Topic pair per method/operation. That way it would be possible to separately grant permissions to call operations on a service or to implement operations on a service.

    The mapping of a Topic pair per method/operation would also setting different Qos per operation...

    Alternatively one could

  • Reported: DDS-RPC 1.0 — Tue, 28 Aug 2018 23:45 GMT
  • Updated: Tue, 28 Aug 2018 23:45 GMT