Distributed Systems can be thought of as a collection of computations evolving a distributed state in response to stimuli. These stimuli can be events triggered by certain states or by external entities, such as physical entities like sensors, operators, etc. The Data Distribution Service (DDS) provides first-class support for representing distributed states as well as asynchronous event distribution. Recently, OpenSplice DDS has added a new feature that simplifies synchronous interactions by means of a Remote Method Invocation (RMI) infrastructure implemented directly over DDS. In this presentation we will first explain the difference between state, events and commands and how these concepts can be used to structure distributed systems. Then we will show the key idioms for implementing distributed state, events and commands with OpenSplice DDS.

1. Distributed State,
Events and Commands
:: with OpenSplice DDS
OpenSplice DDS
Angelo CORSARO, Ph.D.
Chief Technology Officer
OMG DDS Sig Co-Chair
PrismTech
angelo.corsaro@prismtech.com

2. OpenSplice DDS
Foundations

3. Defining a System
Cyber/Physical.
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
World.
¨ A set of interacting
System.
or interdependent Input& ! State& Output&
parts forming an ! Transi"ons&
OpenSplice DDS
integrated whole
s"mulus&
(events/commands)&&

4. Defining a Distributed System
Cyber/Physical.
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
World.
¨ A Distributed System Distributed.
is a System whose Input&
System.
Output&
! State&
parts can only ! Transi"ons&
interact by
OpenSplice DDS
communicating over s"mulus&
a network (events/commands)&&

5. State in a Distributed System
¨ The State of a distributed system
is the collection of the states of its Cyber/Physical.
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
parts plus the stimulus currently World.
propagating through the system
Distributed.
¨ As Distributed Systems don’t System.
Input& Output&
share memory, one problem to ! State&
OpenSplice DDS
! Transi"ons&
address is how to access arbitrary
subsets of its state (or of its parts)
s"mulus&
¨ The other problem is the (events/commands)&&
consistency of this state...

6. Stimulus in a Distributed System
Cyber/Physical.
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Internal and Environmental World.
Stimuli in a distributed
system are used to Distributed.
System.
¨ evolve the system state Input& Output&
! State&
OpenSplice DDS
(commands, i.e. do something) ! Transi"ons&
¨ notify particular condition on the
state (events, i.e. something
happened) s"mulus&
(events/commands)&&

7. State vs Stimulus
Temp State%
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ The state of a system is always
defined to have a value
time
OpenSplice DDS
OverheatAlarm S&mulus%
¨ A Stimulus only exists at a
particular point in time
time

8. Are Commands Different?
Cyber/Phisycal System
¨ Commands are a kind of stimulus World
Do Something
that express the need for the
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
system to do something
Done
¨ As commands have the “do
something” connotation, it is often Asynchronous*
useful to synchronously be
OpenSplice DDS
informed that the “command” has Cyber/Phisycal
World
System
been executed DoSomething
¨ However systems can be built with
both synchronous as well as Done
asynchronous commands
Synchronous*

9. State Events and
OpenSplice DDS
Commands in DDS

10. OpenSplice DDS
State in DDS

11. Distributed State with DDS
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ The “public” state of the elements making the
distributed system can easily be captured via topic
definitions
Representing state with topics is more a matter of
OpenSplice DDS
¨
discipline w.r.t. to the QoS being used and the way
in which it is accessed

12. State’s DDS QoS
Topics representing state should have the following QoS Settings
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ RELIABILITY = RELIABLE
¨ HISTORY = KEEP_LAST(1)
DURABILITY = (TRANSIENT |PERSISTENT)
OpenSplice DDS
¨
¨ OWNERSHIP = EXCLUSIVE
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

13. Soft-State’s DDS QoS
Topics representing soft-state, meaning state that is periodically
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
updated, should have the following QoS Settings
¨ RELIABILITY = BEST_EFFORT
¨ HISTORY = KEEP_LAST(1)
OpenSplice DDS
¨ DURABILITY = VOLATILE
¨ OWNERSHIP = EXCLUSIVE
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

14. Accessing State in DDS
¨ The DataReader.read operation should be used to
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
access topics representing state
¨ This ensures that the last value for the state will be kept in DDS and will
be readable again and again
¨ The DataReader data should be accessed with the
OpenSplice DDS
following flags:
¨ ANY_SAMPLE_STATE
¨ ALIVE_INSTANCE_STATE
¨ ANY_VIEW_STATE

15. Example [1/3]
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ A Robot Position in 2D is an example of state
¨ Let’s assume that the Robot only update position
when it moves
OpenSplice DDS
¨ Topic Type:
struct RobotPosition {
@key
long rid;
long x;
long y;
};

16. Example [2/3]
The Topic and DataReader would be constructed as
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
follows
// Create Topic Qos
val tQos =
TopicQos() <= KeepLastHistory(1)
<= Reliable()
<= TransientDurability()
OpenSplice DDS
<= ExclusiveOwnership()
<= SourceTimestamp();
// Create Topic
val rpt = Topic[RobotPosition](“RobotPosition”,topicQos)
// Create DataReader
val rpdr = DataReader[RobotPosition](rpt, DataReaderQos(tqos))

17. Example [3/3]
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Data can be read as follows
// Read data
val data = rpdr.read(ReadState.AllData)
// Or specific to Escalier
val data = rpdr.history
OpenSplice DDS

18. OpenSplice DDS
Events in DDS

19. Distributed Events with DDS
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Events raised by a distributed system can be easily
captured via topic definitions
¨ Representing events with topics is more a matter of
discipline w.r.t. to the QoS being used and the way
OpenSplice DDS
in which it is accessed
¨ Event topics are often keyless

20. Events’ DDS QoS
Events should have the following QoS Settings
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ RELIABILITY = RELIABLE
¨ HISTORY = KEEP_ALL
DURABILITY = VOLATILE
OpenSplice DDS
¨
¨ OWNERSHIP = SHARED
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

21. Events’ DDS QoS
Events should have the following QoS Settings
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ RELIABILITY = RELIABLE
¨ HISTORY = KEEP_ALL
DURABILITY = VOLATILE
OpenSplice DDS
¨
¨ OWNERSHIP = SHARED
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP

22. Accessing Events in DDS
¨ The DataReader.take operation should be used to
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
access topics representing events
¨ This ensures that the DDS cache is always freed by available events
¨ The DataReader data should be accessed with the
OpenSplice DDS
following flags:
¨ NEW_SAMPLE_STATE
¨ ALIVE_INSTANCE_STATE
¨ ANY_VIEW_STATE

23. Example [1/3]
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ A CollisionEvent could be raised by a Robot when it
is colliding (or about to collide) with something
OpenSplice DDS
¨ Topic Type: struct CollisionEvent {
long detectingRobotId;
long collidingRobotId;
long xe;
long ye;
};

24. Example [2/3]
The Topic and DataReader would be constructed as
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
follows
// Create Topic Qos
val tQos =
TopicQos() <= KeepAll()
<= Reliable()
<= VolatileDurability()
OpenSplice DDS
<= SharedOwnership()
<= SourceTimestamp();
// Create Topic
val cet = Topic[CollisionEvent](“CollisionEvent”,topicQos)
// Create DataReader
val cedr = DataReader[CollisionEvent](cet, DataReaderQos(tqos))

25. OpenSplice DDS
¨
// Take data
Example
[3/3]
val data = cedr.take()
Data can be read as follows
Copyright
2010,
PrismTech
–
All
Rights
Reserved.

26. Commands in DDS
OpenSplice DDS

27. Commands in DDS
¨ As explained earlier commands are just a kind of
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
stimulus
¨ As such could be represented as pairs of events one for
the “command request” and the other for the
“command reply”
OpenSplice DDS
¨ However many people like to deal with commands
synchronously, this is why OpenSplice provides now an
RMI Framework!

28. OpenSplice RMI
¨ Enhances OpenSplice with the ability of defining distributed
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
Services implementing a well defined service interface
¨ Interfaces are specified in IDL and are fully interoperable
with DDS types
OpenSplice DDS
¨ Uses DDS mechanism to invoke services
¨ Takes advantage of DDS mechanism for discovery, fault
tolerance, one-to-many invocations, etc.

29. Example [1/2]
struct Region {
long x0;
¨ Suppose our System is composed long y0;
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
long width;
by a set of cooperating Robots };
long height;
that are inspecting some local interface RobotCommands : ::DDS_RMI::Services {
assigned region for surveillance, void start();
or detecting chemicals, void stop();
radioactivity, etc. void setSpeed(in long s);
long getSpeed();
OpenSplice DDS
void setSize(in long s);
¨ DDS RMI gives us a way of long getSize();
defining the set of interfaces that void setRegion(in Region r);
constitute the relevant Region getRegion();
commands and invoke them as string getColor();
traditional RMI };
string getShape();

30. Example [2/2]
struct Region {
long x0;
long y0;
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
long width;
long height;
};
¨ Under the hood, appropriate local interface RobotCommands : ::DDS_RMI::Services {
topics are generated by the void start();
infrastructure void stop();
void setSpeed(in long s);
long getSpeed();
QoS can be associated to
OpenSplice DDS
¨
void setSize(in long s);
individual methods via an XML long getSize();
file so to further control the void setRegion(in Region r);
semantics of methods invocation Region getRegion();
string getColor();
string getShape();
};

31. OpenSplice DDS
Using DDS RMI
Copyright
2010,
PrismTech
–
All
Rights
Reserved.

32. OpenSplice DDS
Demo

33. Autonomous Robots [1/2]
¨ Let’s build a system in which
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ robots move autonomously on an assigned region
¨ look actively for some specified target and raise event when the
target is at reach
Along with autonomous robots the system will have:
OpenSplice DDS
¨
¨ A GUI showing the position of the robots and highlighting the
places where something was detected
¨ A control application for issuing commands to robots

34. State, Event, Commands
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ State
¨ Robot Position
¨ Events
¨ TargetDetected
OpenSplice DDS
¨ Commands
¨ Robot Control

35. Demo in Action
OpenSplice DDS

36. Summing Up
¨ All Distributed Systems can be decomposed into State and
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
Stimulus, where typical stimulus are Events and Commands
¨ DDS provides first class support for both Distributed State
and Event
With DDS RMI now OpenSplice also provide first class
OpenSplice DDS
¨
support for Commands!
¨ DDS RMI is built on DDS taking advantage both in terms of
performance, fault-tolerance and flexibility.

37. References
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Article comparing performance of Remote Method
Invocation using ZeroC ICE and DDS
¨ http://bit.ly/nCs66E
OpenSplice DDS
¨ DDS RMI Draft RFP
¨ http://bit.ly/owCRgK

38. :: Connect with Us ::
¥ opensplice.com ¥ forums.opensplice.org
¥ @acorsaro
¥ opensplice.org ¥ opensplicedds@prismtech.com ¥ @prismtech
OpenSplice DDS
¥ crc@prismtech.com
¥ sales@prismtech.com
¥ youtube.com/opensplicetube ¥ slideshare.net/angelo.corsaro