The document discusses RPC (remote procedure call) over DDS (Data Distribution Service). It outlines goals of providing a standard and interoperable way to support RPC communication patterns in DDS. Key points covered include supporting request/reply and remote method invocation patterns, leveraging DDS qualities of service, and language bindings. The status of the work as an OMG standard is also summarized.

1. DDS
RPC over DDS
Gerardo Pardo-Castellote, Ph.D.
Chief Technology Officer, RTI
Sumant Tambe, Ph.D.
Senior Software Reseach Engineer, RTI
October 2014

2. © 2014 Real-Time Innovations, Inc.
Outline
• Goals
• Background
• Status
• Details
• More info

3. Goals
• Provide standard and interoperable way means to
support “RPC” communication patterns in DDS
• Support the Patters:
– Request/Reply
– Service Invocation
– Remote Procedure Call
– Remote Method Invocation
• Support invocation of IDL-specified interfaces over DDS
– Provide a simpler way to migrate CORBA applications to
DDS
– Support familiar “remote interface” programming style
equivalent to Java RMI and Apache Thrift
© 2014 Real-Time Innovations, Inc.

4. Advantages of RPC over DDS
• Client and Servers are decoupled
– No startup dependencies
• QoS enforcement to support service SLAs
– Ownership–Redundant pool of servers
– Lifespan–request is only valid for the next N sec
– Durability-request/replies will be eventually received and processed
– Cancellation– after a good quality response has arrived
© 2014 Real-Time Innovations, Inc.
• Data-Centricity
– Explicit trace-ability
– Interaction state can be Monitored, Logged, Audited, Stored,
Manipulated
• Watch by subscribing to requests and/or responses (wire-tap)
• One middleware – leverage DDS infrastructure
– Suited for real-time systems
– Multiplatform, Multilanguage, Interoperable

5. But I can already do it...
True:
• I can write my own RCP using request/reply Topics
• RTI Connext already supports a “Request/Reply”
equivalent to RPC
• Some other vendors do similar things
But…
• The mapping from service to Topics and Types is ad-hoc.
• These approaches are not portable/Interoperable
• Getting everything right is cumbersome at best
© 2014 Real-Time Innovations, Inc.

6. How can I do it myself?
• Map Interfaces to types & Topics…
– One Topic per interface, one per operation?
– What are the types. How to map exceptions, output
parameters, …
– What happens if the interfaces change, e.g. operation
is added or moved?
• Implement necessary
plumbing:
• Setup request topic and type
• Setup reply topic and type
• Filter unwanted requests
• Filter unwanted replies
© 2014 Real-Time Innovations, Inc.

7. But RPC is not a good/robust
idea/design pattern….
• RPC versus Desired State Pattern
– Insight: Often a request-reply can be modeled as
stateful data-centric interactions
Goal
State
© 2014 Real-Time Innovations, Inc.
write
Current
State
Affect
Service
Client
Service
Provider
Desired
State
read
write
read
read

8. RPC vs Desired State
• Desired state is good & more robust if the “request”
actually represents:
– a request to change of system state
– Take a long time to fulfill
– Needs to be observable by others
© 2014 Real-Time Innovations, Inc.
• However:
– Many requests that do not represent changes to state:
Database Query, Read a File…
– People familiar for “Service” or “Request/Reply” pattern
may find Directed State cumbersome –specially if extra
robustness is unwarranted
RPC over DDS provides best of both worlds!

9. Example: RobotControl
© 2014 Real-Time Innovations, Inc.
module robot {
@DDSService
interface RobotControl
{
void command(Command command);
float setSpeed(float speed) raises (TooFast);
float getSpeed();
void getStatus(out Status status);
};
}

10. RobotControl Client
© 2014 Real-Time Innovations, Inc.
import org.omg.dds.rpc.*;
public class TestRobot {
static void createRobotClient() {
RPCRuntime runtime = RPCRuntime.getInstance(TestRobot.class.getClassLoader());
ClientParams clientParams = runtime.createClientParams(); // optional
RobotControlSupport.Client robotClient =
RobotControlSupport.createClient(
clientParams.withServiceName(”TestRobot”)
.withInstanceName(“iRobot”)); // more configs available
robotClient.waitForService(); // optional
robotClient.getSpeed();
}
}

11. RobotControl Service (Java)
package robot;
import robot.RobotControl;
public class MyRobot implements RobotControl
{
public void command(Command command) { }
public float setSpeed(float speed) { return 1; }
public float getSpeed() { return 2; }
public void getStatus(/* out */ Status status) { }
© 2014 Real-Time Innovations, Inc.
}
import org.omg.dds.rpc.*;
public class TestRobot {
public static void createRobotServer()
{
RPCRuntime runtime = RPCRuntime.getInstance(TestRobot.class.getClassLoader());
MyRobot myRobot = new MyRobot();
Server server = runtime.createServer(); // Configurable using ServerParams
RobotControlSupport.Service service =
RobotControlSupport.createService(myRobot, server); // Configurable using ServiceParams
server.run(); // blocking
}
}

12. RobotControl Requester
© 2014 Real-Time Innovations, Inc.
public class TestRobot {
static void createRobotRequester() {
RPCRuntime runtime =
RPCRuntime.getInstance(TestRobot.class.getClassLoader());
RequesterParams reqParams = runtime.createRequesterParams();
// change params here if you like
Requester<RobotControlSupport.RequestType,
RobotControlSupport.ReplyType>
requester = runtime.createRequester(
RobotControlSupport.RequestType.class,
RobotControlSupport.ReplyType.class,
reqParams);
RobotControlSupport.RequestType request =
new RobotControlSupport.RequestType();
// populate request
requester.sendRequest(request);
}
}

13. RobotControl Replier
public class TestRobot {
static void createRobotReplier() {
RPCRuntime runtime =
RPCRuntime.getInstance(TestRobot.class.getClassLoader());
ReplierParams repParams = runtime.createReplierParams();
// change params here if you like
Replier<RobotControlSupport.RequestType,
RobotControlSupport.ReplyType>
replier = runtime.createReplier(
RobotControlSupport.RequestType.class,
RobotControlSupport.ReplyType.class,
repParams);
Sample<RobotControlSupport.RequestType>
request = replier.receiveRequest();
© 2014 Real-Time Innovations, Inc.
}
}

14. RobotControlSupport
public abstract class RobotControlSupport {
public final static class RequestType {
// omg.dds.rpc.RequestHeader header;
// robot.RobotControl_Call data;
© 2014 Real-Time Innovations, Inc.
}
public final static class ReplyType {
// omg.dds.rpc.ReplyHeader header;
// robot.RobotControl_Return data
}
public interface Client
extends RobotControl,
RobotControlAsync,
ClientEndpoint
{
}
public interface Service extends ServiceEndpoint
{
}
public static final RobotControlSupport.Client createClient();
public static final RobotControlSupport.Service createService(RobotControl impl);
// more client and service factory methods here
}

15. What needs to be specified
• Mapping to DDS Topics & Filters
– Each operation maps to a pair of topics?
• Simplicity, Flexibility vs Scalability
– Each interface to a pair of Topics?
• What are the types? Inheritance?
– Is publish-subscribe allowed? e.g. auditing, monitoring…
• Mapping to DDS Data-types
– How to model operations? Parameters (in, our) return, exceptions, …
– Fragility upon interfaces / operations changes?
– Describable using X-TYPES?
• DDS API and DDS-RTPS impact
– Are extensions required?
– Deployment on top of existing DDS
• Language Bindings (C, C++, Java, C#, …)
© 2014 Real-Time Innovations, Inc.

16. Architecture
Client Application Service
Data
Writer
Message-id1
© 2014 Real-Time Innovations, Inc.
Service
Implementation
Lang.
Bind.
GUID2
Client-side
Invoker
Data
Reader
Data
Reader
Data
Writer
GUID1 SN1 Foo
GUID2 SN2 GUID1 SN1 Bar
Message-id2
Correlation-id1
Content-based Filter for filtering
unwanted replies
Language Binding
Bar Svc.method(in Foo);
Foo
Bar
GUID1
Invoke
Return
Call Topic
Return Topic
Foo
Bar

17. Basic and Enhanced Service Mappings
• Basic
– Highest portability
– Enables RPC on top of existing (v1.3 or earlier) DDS Implementations
© 2014 Real-Time Innovations, Inc.
• Enhanced
– Elegant, Clean
– Leverages DDS-XTypes for type matching,
– Adds support for Robust service discovery, Implicit request/reply correlation
Mapping Aspect Basic Service Mapping Profile Enhanced Service Mapping
Profile
Correlation Information
(request-id)
Explicitly added to the data-type Implicit. They appear on the Sample
meta-data.
Topic Mapping One request topic and one reply topic
per interface. 2*N for a hierarchy of N
interfaces.
One request and one reply topic per
interface. Independent of interface
hierarchy.
Type Mapping Synthesized types compatible with
legacy (pre DDS-XTypes)
implementations.
Use facilities of DDS-XTypes for type
descriptions, annotations, and type-compatibility
checks.
Discovery No special extensions. Robust service discovery (no sample loss
due to transient states)

18. Language Bindings
• Two types of language bindings
– High-level binding that provide function-call semantics
– Low-level binding that are akin to send/receive (but still higher level than raw DDS
© 2014 Real-Time Innovations, Inc.
read/take/write)
• Strong separation between the data model and language binding
Client
Application
Function-call
language
binding
DDS API
Service
Specification
(IDL)
Client
Application
Request-Reply
language
binding
DDS API
Service
Implementation
Function call
language
binding
DDS API
Service
Implementation
Request-Reply
language
binding
DDS API
Service-specific Interoperable/Evolvable Data model (DDS/RTPS)

19. QoS Mapping
• Default strict reliable (request and reply)
– RELIABLE reliability
– KEEP_ALL history
– VOLATILE durability
• Can be changed by the user on a per-service level
© 2014 Real-Time Innovations, Inc.

20. struct RobotControl_setSpeed_In {
long s;
};
struct RobotControl_getSpeed_In {
boolean return_;
};
© 2014 Real-Time Innovations, Inc.
@DDSService
interface RobotControl
{
float setSpeed(float speed) raises (TooFast);
float getSpeed();
void start();
void stop();
};
@choice @autoid
struct RobotControl_Request {
RobotControl_setSpeed_In setSpeed;
RobotControl_getSpeed_In getSpeed;
RobotControl_start_In start;
RobotControl_stop_In stop;
};
@empty
struct start_In { octet dummy_;};
@empty
struct stop_In { octet dummy_;};

21. struct RobotControl_setSpeed_Out {
float return_;
// Also inout and out params
};
…
© 2014 Real-Time Innovations, Inc.
@DDSService
interface RobotControl
{
float setSpeed(float speed) raises (TooFast);
float getSpeed();
void start();
void stop();
};
@choice @autoid
struct RobotControl_setSpeed_Result {
RobotControl_setSpeed_Out out;
SystemExceptionCode sysx_;
TooFast toofast_ex;
};
…
@choice @autoid
struct RobotControl_Reply {
RobotControl_setSpeed_Result setSpeed;
RobotControl_getSpeed_Result getSpeed;
RobotControl_start_Result start;
RobotControl_stop_Result stop;
};

22. Status
• Ongoing standard at OMG
• RFP was issued in June 2012
• Initially 2 competing submissions:
1. Joint RTI + eProsima (later joined by TwinOaks)
2. PrismTech
• Very different approaches – not converging
– Evaluation team representing 5 companies formed to provide
feedback
• Recommendation was to simplify RTI/eProsima submission
• PrismTech dropped their submission and joined RTI/eProsimas’/TwinOaks
• Expected to be voted and adopted in Dec 2014
• Completed Function-Call and Request/Reply language binding
– Java (https://github.com/rticommunity/dds-rpc-java)
– C++* (https://github.com/rticommunity/dds-rpc-cxx)
– eProsima has POC implementation of “basic” profile working with several DDS
© 2014 Real-Time Innovations, Inc.
implementations

23. Questions?
© 2014 Real-Time Innovations, Inc.

24. Find out more…
www.rti.com
community.rti.com
demo.rti.com
www.youtube.com/realtimeinnovations
blogs.rti.com
www.twitter.com/RealTimeInnov
www.facebook.com/RTIsoftware
www.slideshare.net/GerardoPardo
www.slideshare.net/RealTimeInnovations
© 2014 Real-Time Innovations, Inc.
dds.omg.org
www.omg.org
© 2014 RTI