What is DDS?
The "Data Distribution Service for Real-Time Systems" (DDS) is an open standard from the Object Management Group (OMG) released in 2003 and revised in 2007. This standard is the specification of the API of a Publish-Subscribe Communication Middleware for distributed systems.
Distributed applications using DDS can publish or subscribe to "topics" of information and use a rich set of Quality of Service parameters to set up the different aspects of the communication (reliability, persistence, redundancy, lifespan, transport settings, resources...).
To learn more about DDS you can read our Introduction to DDS.
Remote Procedure Calls (RPC) vs Publish/subscribe:
DDS focuses in completely data-centric and asynchronous publish/subscribe operations and any distributed system can be designed just with this pattern leading to a very modular and decoupled design, but many times the traditional client/server or request/reply pattern should be used for a variety of design reasons.
Remote operations such as executing a database query, perform a computation, executing an action and return the result, etc. are usually implemented using the request/reply pattern. Moreover, the developer usually prefers this kind of pattern because natural thinking: I ask A to do B and return me the result C.
It is also a fact that most of the available middleware technologies use the request/reply pattern as their core and main pattern (Web Services, Rest, Corba, Thrift, Java RMI…)
RPC over DDS:
In a Remote Procedure Call simple model, the client sends a Request message containing the input parameters of the remote procedure, and the server sends a Reply message containing the return value of the procedure and the output parameters. More fields should be added to the Request and Reply messages in order to correlate the request with the reply, identify the client and the server, account for exceptions, etc.
Consider the following procedure example “Fun”:
funReturnValueDataType Fun(DataType1 parameter1,DataType2 parameter2…);
DDS is a specification following the publish/subscribe pattern, but it is straightforward to implement a request/reply pattern using two publishers/subscriber pairs. The first pair to handle the request and the second to handle the reply, using the corresponding Reply and Request DDS Topics. Thus, the outline of an RPC over DDS is simple as depicted in the following diagram:
Generic Remote Procedure Invocation Using DDS
In the simplest model, the request topic would contain the procedure parameters and the reply the procedure return value.
Automatic code generation:
To automatize RPC over DDS the definition of the procedures can be stated using an interface definition language, such as the OMG IDL, and a parsing tool can generate code to manage the required DDS entities, in particular, it could create a “proxy” for the client and a “skeleton” for the server using the typical approach in middleware technologies such as Web Services, Apache Thrift, etc.
The proxy object would expose the remote procedures as local procedures and it would manage the DDS entities to send the request. The server skeleton object would be a where the user would write the Remote Procedure implementation.
Automatic Code Generation
Performance:
The request/reply pattern is easy derived from the publish/subscribe pattern and as a result the implementations of RPC over DDS should have a performance comparable with “native” RPC implementations.
eProsima RPC over DDS for example, has shown a performance tens of times faster than web services:
OMG Standard:
In June 2012, the Object Management Group (OMG) released a Request for Proposal for a new standard: RPC over DDS. Several companies, including eProsima have responded to this request, and the new standard is expected along 2013.
For more information about RPC over DDS:
For more information, please contact
