FAST DDS PRO FEATURE
Bring typed service calls into your DDS system.
Define service operations in IDL, generate asynchronous client and server APIs, and run request/reply or streaming interactions over Fast DDS.
One typed service contract.
Client, server and DDS mapping.
Unary and streaming operations.
FAST DDS PRO RPC over DDS is a commercial Fast DDS Pro capability.
The complete RPC API, Fast DDS-Gen interface guide and implementation examples are included with the Pro distribution.
How it works
From service definition to remote call.
The generated layer handles the DDS plumbing so application developers work with the typed operations declared in the interface.
Define the interface
Describe operations, parameters, return values, streams and exceptions in an OMG IDL interface.
Generate typed APIs
Fast DDS-Gen produces the client, server and DDS types required by the service contract.
Implement and call
Add the service logic, call it asynchronously and let Fast DDS correlate every result with its request.
IDL service contract
Describe calls, streams and failures in one place.
Standard operations generate asynchronous request/reply calls. Add @feed when an operation needs streaming, and use raises for typed service exceptions.
get_status
One request, one typed result.
watch
One request, a stream of samples.
SensorFault
A failure defined in the contract.
module telemetry
{
struct SystemStatus
{
boolean ready;
string message;
};
exception SensorFault
{
string reason;
};
interface TelemetryService
{
SystemStatus get_status(in string sensor_id)
raises (SensorFault);
@feed TelemetrySample watch(in string sensor_id)
raises (SensorFault);
};
};Core capabilities
A complete service model on the DDS foundation.
Use generated high-level APIs while retaining control over the behavior that matters in a distributed system.
Start from one typed interface
Fast DDS-Gen turns the operations declared in IDL into high-level client and server APIs. The low-level DDS mapping is generated underneath.
- OMG IDL interface definitions
- Generated client and server source
- Generated request, reply and type support
Keep the application responsive
Regular operation calls return an RpcFuture. The application can continue working, wait with a timeout and retrieve the typed result when the reply arrives.
- RpcFuture-based results
- Automatic request and reply correlation
- Configurable waiting and timeout handling
Go beyond one request and one reply
Use the @feed annotation to generate server streaming, client streaming or bidirectional streaming operations.
- Server-to-client output feeds
- Client-to-server input feeds
- Independent bidirectional feeds
Make failures part of the contract
Declare domain-specific exceptions in IDL and handle generated exception types at the client.
- IDL-declared operation exceptions
- Built-in middleware and remote errors
- Typed information returned to the caller
Choose how requests are processed
Use the generated thread-pool scheduler or inject a custom scheduling strategy when the service requires a different execution model.
- Generated thread-pool scheduling
- Configurable thread-pool size
- Custom scheduling strategy support
Operation data flows
Choose the interaction pattern operation by operation.
Keep simple calls simple, then introduce a generated feed only where multiple values need to move.
Unary
One typed request returns one correlated reply.
Server streaming
One request opens an output feed with multiple server replies.
Client streaming
An input feed sends multiple client values before one reply.
Bidirectional streaming
Independent input and output feeds exchange values in both directions.
DDS-native underneath
A familiar API without a separate service transport.
The generated client and server map to DDS Requester and Replier entities. Requests and replies travel through correlated DDS samples in the same domain as the rest of the system.
- Requester publishes requests and receives replies.
- Replier receives requests and publishes replies.
- Correlation associates every response with its original call.
- DDS QoS, transports, discovery and security remain available.
Where it fits
Use RPC when an operation has a clear owner.
Combine data-centric distribution with explicit service interactions where a caller needs a correlated outcome.
Commands and configuration
Invoke an operation on the component responsible for it and receive a typed outcome.
Queries and diagnostics
Ask a remote service for computed state without designing a separate application protocol.
Long-running operations
Return progress, batches or partial results through a generated output feed.
Architecture first
Design service interactions around the complete system.
Tell us what must be called, where each service runs and how results need to flow. We will help you assess RPC over DDS with Fast DDS Pro.
IDL interface and operation design.
Unary and streaming flow selection.
Error, timeout and scheduling strategy.
Fast DDS Pro licensing and documentation access.
