Getting Started in DDS with C++ and Java

Angelo Corsaro, Ph.D.
Chief Technology Ofﬁcer
PrismTech
OMG DDS SIG Co-Chair
angelo.corsaro@prismtech.com
OpenSpliceDDSOpenSpliceDDOpenSpliceDDSOpenSpliceDDSOpenSpliceDDS
Getting Started with DDS
For C++ and Java Programmers
1

./background-info
2

The OMG DDS
The OMG DDS Standard
‣ Introduced in 2004 to address the Data
distribution challenges typical of Defense
and Aerospace Mission Critical Applications
‣ Key requirements for the standard were high
performance and scalability from embedded
to ultra-large-scale deployments
‣ Today recommended by key administrations
worldwide and widely adopted well beyond
Aerospace and Defense in domains, such as,
Automated Trading, Simulations, SCADA,
Telemetry, etc.
3

DDS Recommendations
Increasingly Mandated/Recommended by Administrations
‣ US Navy: Open Architecture
‣ DISR/DISA: Net-centric Systems
‣ EuroControl: Air Traffic Control Center Operational
Interoperability
‣ QinetiQ & MILVA: Recommending DDS for Vehicles
Electronic Architecture
! The infrastructure evolution cycle is churning…
– New -> Emerging -> Standard -> Commodity
– Middleware is emerging as OS declines
! …DDS is maturing…
– OMG focus
– Wire spec
– Tools
– Enterprise integration
– Multiple products fielded
– Deployed applications!
! …and adoption is on the rise
– Navy
– DISR
– FCS/SoSCOE
– Many significant applications 4

The OMG Data Distribution Service
DDS v1.2 API Standard
‣ Language Independent, OS and
HW architecture independent
‣ DCPS. Standard API for Data-
Centric, Topic-Based, Real-Time
Publish/Subscribe
‣ DLRL. Standard API for creating
Object Views out of collection of
Topics
Object/Relational Mapping
Ownership Durability
Content
Subscription
Minimum Proﬁle
Data Centric Publish/Subscribe (DCPS)
Data Local Reconstruction Layer (DLRL)
DDS Interoperability Wire Protocol
Application
UDP/IP
Real-Time Publish/Subscribe Protocol
5

The OMG Data Distribution Service
DDS-RTPS v2.1 Wire Protocol
Standard
‣ Standard wire protocol allowing
interoperability between different
implementations of the DDS
standard
‣ Interoperability demonstrated
among key DDS vendors in March
2009
Object/Relational Mapping
Ownership Durability
Content
Subscription
Minimum Proﬁle
Data Centric Publish/Subscribe (DCPS)
Data Local Reconstruction Layer (DLRL)
DDS Interoperability Wire Protocol
Application
UDP/IP
Real-Time Publish/Subscribe Protocol
6

./dds-foundations
7

What is Data Distribution?
‣ Data distribution is about
making application defined
data available where needed
and when needed
‣ Data is a first class concept,
it can be created, updated,
read and eventually disposed
‣ The last value (or last N-
values) of a Data is available
VehicleSpeedVehicleSpeedVehicleSpeed
plate
“A123”
“B456”
“C789”
dx dy
50 0
0 45
10 30
VehiclePositionVehiclePositionVehiclePosition
plate
“A123”
“B456”
“C789”
x y
101 202
303 404
505 606
[1/2]
TrakCo.VehiclePosition
struct VehiclePosition {
string plate;
long x, y; }
TrakCo.VehicleSpeed
struct VehicleSpeed {
string plate;
long dx, dy; }
Brokers
8

What is Data Distribution?
‣ Producer, Consumers as well
as Topics are dynamically
discovered
‣ A rich set of QoS is used to
control the non-functional
properties of data (e.g.
durability, availability, etc.)
[2/2]
TrakCo.VehiclePosition
string plate;
long x, y; }
TrakCo.VehicleSpeed
struct VehicleSpeed {
string plate;
long dx, dy; }
plate
“A123”
“B456”
“C789”
dx dy
50 0
0 45
10 30
plate
“A123”
“B456”
“C789”
x y
101 202
303 404
505 606
Brokers
9

./dds-topics
10

Data in DDS
‣ The definition of Data in DDS is tied
to the definition of a Topic
‣ A Topic is the association between:
‣ Unique Name
‣ Type
‣ QoS
‣ A Topic can have associated a key
in order to express data instances
identities
VehiclePosition
TrackCo.VehiclePosition
{
Reliability
Deadline,
Priority
Transient,
...
}
TopicType QoS
Name
[1/2]
Topics
11

Data in DDS
‣ A Topic key can be made of an
arbitrary number of Topic Type
attributes
‣ Each unique key value identify a
Topic Instance
‣ Topic Instance, can be Created,
Read, Updated, and Disposed
(CRUD)
[2/2]
plate
“A123”
“B456”
“C789”
x y
101 202
303 202
101 606
TrakCo.VehiclePositionTopic
TopicType
Topic Instances
Topic Key
Topic Instances
12

./qos
13

DDS QoS Model
Publisher
DataWriter
Topic
Type
QoS
Name
writes
QoS
DataWriter
Topic
Typewrites
Subscriber
DataReaderreads
DataReaderreads
...
QoS
Name
QoS
QoS QoS
QoS matching
......
QoS QoS
Type Matching
DomainParticipant DomainParticipant
QoS QoS
‣ QoS-Policies provide
control over local and
end-to-end properties of
DDS entities
‣ Local properties
controlled by QoS are
related resource usage
‣ End-to-end properties controlled by QoS are related to temporal and spatial aspects
of data distribution
‣ Some QoS-Policies are matched based on a Request vs. Offered Model thus QoS-
enforcement
14

QoS Policy Applicabilit
y
RxO Modifiable
DURABILITY
DURABILITY
SERVICE
LIFESPAN
HISTORY
PRESENTATION
RELIABILITY
PARTITION
DESTINATION
ORDER
OWNERSHIP
OWNERSHIP
STRENGTH
DEADLINE
LATENCY
BUDGET
TRANSPORT
PRIORITY
T, DR, DW Y N
Data
Availability
T, DW N N
Data
Availability
T, DW N/A Y
Data
Availability
T, DR, DW N N
Data
Availability
P, S Y N
Data
Delivery
T, DR, DW Y N
Data
Delivery
P, S N Y
Data
Delivery
T, DR, DW Y N
Data
Delivery
T, DR, DW Y N
Data
Delivery
DW N/A Y
Data
Delivery
T, DR, DW Y Y
Data
Timeliness
T, DR, DW Y Y
Data
Timeliness
T, DW N/A Y
Data
Timeliness
TIME BASED
FILTER
RESOURCE
LIMITS
ENTITY
FACTORY
USER DATA
TOPIC DATA
GROUP DATA
LIVELINESS
WRITER DATA
LIFECYCLE
READER DATA
LIFECYCLE
DR N/A Y
Resources
T, DR, DW N N
Resources
Configuratio
n
DP, DR, DW N Y Configuratio
nT N Y
Configuratio
n
P, S N Y
Configuratio
n
T, DR, DW Y N
Configuratio
n
DW N/A Y
Lifecycle
DR N/A Y
Lifecycle
QoS Policy Applicability RxO Modifiable
QoS Policies
15

./dds-in-action
16

Brokers
Data Distribution in Action
17

Brokers
plate dx dy
plate x y
17

Brokers
plate dx dy
plate x y
plate x y
plate dx dy
plate x y
plate x y
plate x y
18

Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202
“A123” 101 202
“A123” 101 202
plate x y
plate x y
plate x y
18

Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202
“A123” 101 202
“A123” 101 202
plate x y
plate x y
“B456” 303 404
“B456” 303 404
“B456” 303 404
plate x y
18

plate x y
“A123” 101 202
“B456” 303 404
Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202“A123” 101 202
plate x y
“B456” 303 404“B456” 303 404
plate x y
“A123” 101 202
“B456” 303 404
19

plate x y
“A123” 101 202
“B456” 303 404
Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202“A123” 101 202
plate x y
“B456” 303 404“B456” 303 404
plate x y
“C789” 505 606
“C789” 505 606
“C789” 505 606
“A123” 101 202
“B456” 303 404
19

plate x y
“A123” 101 202
“B456” 303 404
Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202“A123” 101 202
plate x y
“B456” 303 404“B456” 303 404
plate x y
“C789” 505 606“C789” 505 606
“A123” 101 202
“B456” 303 404
“C789” 505 606
“C789” 505 606
20

plate x y
“A123” 101 202
“B456” 303 404
Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202“A123” 101 202
plate x y
“B456” 303 404“B456” 303 404
plate x y
“C789” 505 606“C789” 505 606
“A123” 101 202
“B456” 303 404
“C789” 505 606
“C789” 505 606
“A123” 50 0
20

plate x y
“A123” 101 202
“B456” 303 404
Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202“A123” 101 202
plate x y
“B456” 303 404“B456” 303 404
plate x y
“C789” 505 606“C789” 505 606
“A123” 101 202
“B456” 303 404
“C789” 505 606
“C789” 505 606
“A123” 50 0
plate dx dy
21

plate x y
“A123” 101 202
“B456” 303 404
Brokers
plate dx dy
plate x y
plate x y
plate dx dy
“A123” 101 202“A123” 101 202
plate x y
“B456” 303 404“B456” 303 404
plate x y
“C789” 505 606“C789” 505 606
“A123” 101 202
“B456” 303 404
“C789” 505 606
“C789” 505 606
“A123” 50 0
“A123” 50 0
plate dx dy
21

./cxx-java-psm
22

DDS PIM/PSM Approach
‣ The DDS standard is composed
by a PIM specified in UML and
A PSM specified in IDL
‣ Language specific APIs are
derived via IDL-based mappings
(e.g. IDL2C++, etc.)
PIM (UML)
PSM (IDL)
C JavaC++
IDL2C
IDL2C++
IDL2Java
23

What is the problem?
‣ IDL is very good for describing DDS Topic Types, yet...
‣ IDL’s biggest strength, namely (programming) language
independence, becomes its biggest weakness when trying to
define APIs that are well integrated with a programming
language
‣ For some programming languages (e.g. C++) the IDL2C++
mapping is “seasoned”
24

Why is this a problem?
‣ Resulting DDS APIs are more complicated than they should
‣ API don’t feel natural or ergonomic to programmers
‣ API (esp. for C++) don’t integrate well with standard libraries
nor implements common idioms/patterns.
25

Native C++/Java PSMs
‣ The new C++/Java PSM are derived
starting directly from the PIM
‣ The new C++/Java PSM take
advantage of all the features
available in C++/Java to provide a
natural, productive, efficient, safe and
portable API
PIM (UML)
ISO C++ PSM
The new PSM simplify DDS programming w/o limiting the
expensiveness or introducing limitations in what possible
Java 5 PSM
26

ISO C++ PSM in a Nutshell
‣ Provides transparent, safe, precise and real-time automatic
memory management
‣ Takes advantage of C++ Template Meta-programming to
automate tasks such as type registration and provide a strongly
typed API (no downcast ever!)
‣ Provides a DDS API that exploits Iterators and containers as well
as other C++ Standard Types
‣ API is extensible, efficient and portable
27

Java 5 PSM in a Nutshell
‣ Takes advantage of Java Generics to simplify the API and
facilitate tasks such as type registration
‣ Provides a DDS API that exploits Iterators and containers
‣ API is extensible, efficient and portable
28

Anatomy of a DDS Application
‣ Tree-like dependency between
DP->(P,S)->(DR, DW) in creation
and life-cycle management
‣ Example: DW alive requires
the parent P to be alive
‣ This tree-like dependency
allows precise GC of DDS
Entities via reference counting
DomainParticipant
Publisher Subscriber
DataWriter DataReader
Topic
Partition
Domain
DP: DomainParticipant DR: DataReader
P: Publisher DW: DataWriter
S: Subscribe
29

DDS App Steps
1. Define the Information Model1
30

DDS App Steps
1. Define the Information Model
2. Connect to proper Domain/Partition
1
2
31

DDS App Steps
3. Create Topic
1
2
3
32

DDS App Steps
3. Create Topic
4. Create DataWriter
1
2
3
4
33

DDS App Steps
3. Create Topic
5. Create DataReader
1
2
3
4
4
34

DDS App Steps
1. Define the Information Model1
35

./cxx
36

Topics in C++
‣ Topic are associated to a C++ template class parametrized in the
topic type, e.g. Topic<VehiclePosition>, Topic<VehicleSpeed>
‣ Topic types can be described in IDL, XML, UML, and Java
‣ Topic types are mapped to C++ classes having one set of
accessors per Topic attribute
37

Types Mapping
‣ DDS primitive types are mapped to
C99/C++ standard types
‣ DDS container types are mapped to
standard C++ containers, namely
std::vector and std::map
38

TopicType Mapping
! string plate;
! long x;
! long y;
};
#pragma keylist VehiclePosition plate
IDL Topic Type Deﬁnition
class VehiclePosition {
! VehiclePosition();
! VehiclePosition(const std::string& plate,
! ! ! int32_t x, int32_t y);
! virtual ~VehiclePosition();
! const std::string& plate() const;
! void plate(const std::string& s);
! const int32_t x() const;
! void x(int32_t i);
! const int32_t y() const;
! void y(int32_t i);
private:
! // Encapsulated state representation
};
C++ Topic Type Mapping
39

./java
40

Topics in Java
‣ Topic are associated to a Java Generic class parametrized in
the topic type, e.g. Topic<VehiclePosition>,
Topic<VehicleSpeed>
‣ Topic types can be described in IDL, XML, UML, and Java
‣ Topic types are mapped to Java classes having one set of
accessors per Topic attribute
‣ Properly annotated, user provided Java classes, can be used as
topic types w/o the need of code generation
41

Types Mapping
‣ DDS primitive types are mapped to
Java primitive types
‣ DDS container types are mapped to
standard Java containers
DDS Type Java Type
Boolean boolean
Char8 char
Char32 int
Byte byte
Int16 short
UInt16 short
Int32 int
Uint32 int
Int64 long
Uint64 long
Float64 double
Float32 float
string<Char8> String
string<Char32> String
sequence<T> Collection
map<K,T> java.util.Map
T[] T[]
42

Java Topic Type Mapping
TopicType Mapping
public VehiclePosition() { /* impl */ }
public VehiclePosition(String plate,
! ! ! int x, int y) { /* impl */}
String getPlate() { /* impl */ }
void setPlate(String plate) { /* impl */ }
int getX() { /* impl */ }
void setX(int x) { /* impl */ }
int getY() { /* impl */ }
void setY(int y) { /* impl */ }
// Private state implementation
}
! string plate;
! long x;
! long y;
};
#pragma keylist VehiclePosition plate
IDL Topic Type Deﬁnition
43

JavaTopicType Deﬁnition
@key
private string plate;
private int x;
private int y;
public VehiclePosition() { }
public VehiclePosition(String plate,
! ! ! int x, int y) {
this.plate = plate;
! this.x = x;
! this.y = y;
}
String getPlate() { return this.plate; }
void setPlate(String plate) {
this.plate = plate; }
int getX() { return this.x; }
void setX(int x) { this.x = x; }
int getY() { return this.y; }
void setY(int y) { this.y = y; }
}
44

DDS App Steps
1
2
45

Domain
‣ A Domain is one instance of
the DDS Global Data Space
‣ DDS entities always belong
to a specific domain
Partition
‣ A partition is a scoping
mechanism provided by DDS
organize a partition
DomainId = 0
VechicleTelemetry
Domain and Partitions
46

./cxx
47

Joining Domain/Partition
Note:
‣ Reference types are
always created via
factory methods on
the parent entity
‣ Policies can be
“streamed” into QoS
objects
// Create Domain Participant in the Domain “0”
DomainId id = 0;
DomainParticipant dp =
TheParticipantFactory().create_participant(id);
// Set the Publisher QoS with the proper partition
pub::qos::PublisherQos pqos;
pqos << policy::Partition("VehicleTelemetry");
// Create the Publisher
pub::Publisher pub =
dp.create_publisher(pqos);
using namespace dds::core;
using namespace dds;
using namespace dds::domain;
48

./java
49

Joining Domain/Partition
Note:
‣ The Boostrap class
allows to run multiple
DDS instances, even
from different vendors
on the same
application
// Create Domain Participant in the Domain “0”
DomainId id = 0;
DomainParticipantFactory factory =
! ! DomainParticipantFactory.getInstance
(Bootstrap.createInstance());
factory.createParticipant(id);
// Create the Publisher
pub::Publisher pub =
dp.create_publisher(pqos);
import org.omg.dds.core.Bootstrap;
import org.omg.dds.domain.DomainParticipant;
import org.omg.dds.domain.DomainParticipantFactory;
50

DDS App Steps
3. Create Topic
1
2
3
51

./cxx
52

Topic Creation
Note:
‣ QoS setting is
optional and only
required to override
defaults
‣ QoS override shown
to highlight how
effective is the new
QoS API
// Create and set TopicQos (if different from
// default)
topic::qos::TopicQos tqos;
tqos << policy::Reliability::Reliable()
<< policy::Durability::Transient()
<< policy::History::KeepLast(10)
<< policy::TransportPriority(14);
// Create the Topic with specific Qos
topic::Topic<VehiclePosition> topic =
dp.create_topic<VehiclePosition>("VPosTopic", tqos);
// Create the Topic with default Qos
topic::Topic<VehiclePosition> topic =
dp.create_topic<VehiclePosition>("VPosTopic");
53

./java
54

Topic Creation
Note:
‣ The TopicType class
is passed to work-
around Java
Generics type-
erasure
import org.omg.dds.topic.Topic;
Topic<VehiclePosition> topic =
dp.createTopic("VPosTopic", VehiclePosition.class);
55

DDS App Steps
3. Create Topic
1
2
3
4
56

./cxx
57

Writing Data
Note:
‣ The DataWriter is
parametrized on the
Topic Type
‣ The stream operator
can be used to
write sample as well
as override Qos,
policies and to do
coherent updates
// Create and set DataWriterQos from TopicQos
pub::qos::DataWriterQos dwqos(tqos);
// Create DataWriter
pub::DataWriter<VehiclePosition> dw =
pub.create_datawriter(topic, dwqos);
// Create Sample
VehiclePosition vpos("A123", 100, 200);
// Write
dw.write(vpos);
// Stream-like Write
dw << vpos;
// Stream-like Write + Policy override
dw << policy::TransportPriority(55) << vpos;
58

./java
59

Writing Data
Note:
‣ No need to pass
the class type since
it is maintained by
the Topic
import org.omg.dds.pub.DataWriter;
DataWriter<VehiclePosition> dw =
pub.createDataWriter(topic);
// Create Sample
VehiclePosition vp =
new VehiclePosition("A123", 100, 200);
// Write Sample
dw.write(vp);
60

DDS App Steps
3. Create Topic
5. Create DataReader
1
2
3
4
4
61

./cxx
62

Reading Data
Note:
‣ The read API is heavily
based on iterators
‣ The stream operator can
also be used read
samples and a mutator is
used to control the
read/take behaviour
‣ Back-inserting iterators
and zero-copy API also
supported
// (1) Create and set DataReaderQos from TopicQos
sub::qos::DataReaderQos drqos(tqos);
// (2) Create DataReader
sub::DataReader<VehiclePosition> dr =
sub.create_datareader(topic, drqos);
// (3) Read with using Forward Iterators on std::vector
std::vector<VehiclePosition> data(N);
std::vector<SampleInfo> info(N);
dr.read(data.begin(), info.begin(), N);
// (3) Read with using Forward Iterators on arrays
VehiclePosition adata[N];
SampleInfo ainfo[N];
dr.read(&adata[0], &ainfo[0], N);
63

./java
64

Reading Data
Note:
‣ No need to pass
the class type since
it is maintained by
the Topic
import org.omg.dds.pub.DataReader;
DataReader <VehiclePosition> dr =
sub.createDataReader(topic);
List<Sample<VehiclePosition>> data =
new Vector<Sample<VehiclePosition>>();
dr.read(data);
65

Putting all together
int main(int, char**) {
// -- Create Domain Participant
! ! TheParticipantFactory().create_participant();
// -- Create Publisher
pub::Publisher pub = dp.create_publisher();
// -- Create Topic
dds::topic::Topic<VehiclePosition> topic =
! ! dp.create_topic<VehiclePosition>("VSPosTopic");
// -- Create DataWriter
pub::DataWriter<VehiclePosition> dw =
! ! ! pub.create_datawriter(topic);
// -- Write Sample
dw << VehiclePosition("A123", 100, 200);
}
‣ Writing a DDS can take as
5 lines of code
‣ Default domain
‣ Default Qos
66

./summ-up
67

Concluding Remarks
‣ DDS provide a powerful abstraction for building high available,
scalable and high performance distributed systems
‣ The new C++ and Java API make DDS very simple to use while
improving safety, performances and portability
‣ These new API are now finalized and planned for adoption
during the December 2010 OMG meeting
68

./references
69

References
‣ Working incubator from which most of
the ISO C++ PSM was derived
‣ Available at:
‣ http://code.google.com/p/simd-cxx
The Simple DDS API
SimD
‣ OMG submission for C++/Java PSM are also available as Open
Source project at the following URL
‣ http://code.google.com/p/dds-psm-cxx/
‣ http://code.google.com/p/datadistrib4j/
70

http://www.opensplice.com/
http://www.opensplice.org/
emailto:opensplicedds@prismtech.com
http://www.youtube.com/OpenSpliceTube http://opensplice.blogspot.com
http://bit.ly/1Sreg
http://www.slideshare.net/angelo.corsaro
http://twitter.com/acorsaro/
D e l i v e r i n g P e r f o r m a n c e , O p e n n e s s , a n d F r e e d o m
OpenSplice DDS
References
71

Getting Started in DDS with C++ and Java

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Getting Started in DDS with C++ and Java

Similaire à Getting Started in DDS with C++ and Java (20)

Plus de Angelo Corsaro

Plus de Angelo Corsaro (20)

Dernier

Dernier (20)

Getting Started in DDS with C++ and Java