Download pdf - RPC Over DDS

DDS

RPC over DDS Gerardo Pardo-‐Castellote, Ph.D. Chief Technology Officer, RTI Sumant Tambe, Ph.D. Senior SoBware Reseach Engineer, RTI

October 2014

© 2014 Real-‐Time InnovaJons, Inc.

Outline

•  Goals •  Background •  Status •  Details •  More info


Goals •  Provide standard and interoperable way means to support “RPC” communicaJon paQerns in DDS

•  Support the PaQers: –  Request/Reply –  Service InvocaJon –  Remote Procedure Call –  Remote Method InvocaJon

•  Support invocaJon of IDL-‐specified interfaces over DDS –  Provide a simpler way to migrate CORBA applicaJons to DDS

–  Support familiar “remote interface” programming style equivalent to Java RMI and Apache ThriB


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 –  CancellaJon– aBer a good quality response has arrived

•  Data-‐Centricity –  Explicit trace-‐ability –  InteracJon 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-‐Jme systems –  MulJpla`orm, MulJlanguage, Interoperable


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 •  Gebng everything right is cumbersome at best


How can I do it myself? •  Map Interfaces to types & Topics…

– One Topic per interface, one per operaJon? – What are the types. How to map excepJons, output parameters, …

– What happens if the interfaces change, e.g. operaJon is added or moved?

•  Implement necessary plumbing:

•  Setup request topic and type •  Setup reply topic and type •  Filter unwanted requests •  Filter unwanted replies


Goal State

But RPC is not a good/robust idea/design paQern…. •  RPC versus Desired State PaQern

–  Insight: OBen a request-‐reply can be modeled as stateful data-‐centric interacJons

write

Current State

Affect Service Client

Service Provider

DesiredState

read

write

read

read


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 Jme to fulfill –  Needs to be observable by others

•  However: – Many requests that do not represent changes to state: Database Query, Read a File…

–  People familiar for “Service” or “Request/Reply” paQern may find Directed State cumbersome –specially if extra robustness is unwarranted

RPC over DDS provides best of both worlds!


Example: RobotControl

module robot {

@DDSService interface RobotControl { void command(Command command); float setSpeed(float speed) raises (TooFast); float getSpeed(); void getStatus(out Status status); };

}


RobotControl Client 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(); } }


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) { } }

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 } }


RobotControl Requester 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); } }


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(); } }


RobotControlSupport public abstract class RobotControlSupport { public final static class RequestType { // omg.dds.rpc.RequestHeader header; // robot.RobotControl_Call data; } 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 }


What needs to be specified •  Mapping to DDS Topics & Filters

–  Each operaJon 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. audiJng, monitoring…

•  Mapping to DDS Data-‐types –  How to model operaJons? Parameters (in, our) return, excepJons, … –  Fragility upon interfaces / operaJons changes? –  Describable using X-‐TYPES?

•  DDS API and DDS-‐RTPS impact –  Are extensions required? –  Deployment on top of exisJng DDS

•  Language Bindings (C, C++, Java, C#, …)


Architecture

Service Implementa8on

Lang. Bind.

GUID2

Client-‐side Invoker

Client Application Service

Data Writer

Data Reader

Data Reader

Data Writer

GUID1 SN1 Foo

GUID2 SN2 Bar GUID1 SN1

Message-id1

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


Basic and Enhanced Service Mappings •  Basic

–  Highest portability –  Enables RPC on top of exisJng (v1.3 or earlier) DDS ImplementaJons

•  Enhanced –  Elegant, Clean –  Leverages DDS-‐XTypes for type matching, –  Adds support for Robust service discovery, Implicit request/reply correlaJon

Mapping Aspect Basic Service Mapping Profile Enhanced Service Mapping Profile

Correla8on Informa8on (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 compaJble with l e g a c y ( p r e D D S -‐ X T y p e s ) implementaJons.

Use faciliJes of DDS-‐XTypes for type descripJons, annotaJons, and type-‐compaJbility checks.

Discovery No special extensions. Robust service discovery (no sample loss due to transient states)


Language Bindings •  Two types of language bindings

–  High-‐level binding that provide func%on-‐call semanJcs –  Low-‐level binding that are akin to send/receive (but sJll higher level than raw DDS

read/take/write) •  Strong separaJon between the data model and language binding

Client ApplicaJon

FuncJon-‐call language binding

DDS API

Service Specification (IDL)

Client ApplicaJon

Request-‐Reply language binding

DDS API

Service ImplementaJon

FuncJon call language binding

DDS API

Service ImplementaJon

Request-‐Reply language binding

DDS API

Service-‐specific Interoperable/Evolvable Data model (DDS/RTPS)


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


struct RobotControl_setSpeed_In { long s; };

struct RobotControl_getSpeed_In { boolean return_; };

@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_;};


struct RobotControl_setSpeed_Out { float return_; // Also inout and out params }; …

@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; SystemExcepJonCode 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; };


Status •  Ongoing standard at OMG •  RFP was issued in June 2012 •  IniJally 2 compeJng submissions:

1.  Joint RTI + eProsima (later joined by TwinOaks) 2.  PrismTech

•  Very different approaches – not converging –  EvaluaJon team represenJng 5 companies formed to provide

feedback •  RecommendaJon 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 FuncJon-‐Call and Request/Reply language binding

–  Java (hQps://github.com/rJcommunity/dds-‐rpc-‐java) –  C++* (hQps://github.com/rJcommunity/dds-‐rpc-‐cxx) –  eProsima has POC implementaJon of “basic” profile working with several DDS

implementaJons


QuesJons?


Find out more… www.rJ.com

community.rJ.com

demo.rJ.com

www.youtube.com/realJmeinnovaJons

blogs.rJ.com

www.twiQer.com/RealTimeInnov

www.facebook.com/RTIsoBware

dds.omg.org

www.omg.org

www.slideshare.net/GerardoPardo www.slideshare.net/RealTimeInnovaJons