Embed Size (px)
DESCRIPTION
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.
Citation preview
Ope
nSpl
ice
DD
S
Angelo CORSARO, Ph.D.Chief Technology Officer OMG DDS Sig [email protected]
Distributed State,Events and Commands:: with OpenSplice DDS
Ope
nSpl
ice
DD
S
Foundations
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Defining a System
¨ A set of interacting or interdependent parts forming an integrated whole
Cyber/Physical.World.
s"mulus&(events/commands)&&
Input& Output&! State&! Transi"ons&
System.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Defining a Distributed System
¨ A Distributed System is a System whose parts can only interact by communicating over a network
Cyber/Physical.World.
s"mulus&(events/commands)&&
Input& Output&! State&! Transi"ons&
Distributed.System.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
State in a Distributed System¨ The State of a distributed system
is the collection of the states of its parts plus the stimulus currently propagating through the system
¨ As Distributed Systems don’t share memory, one problem to address is how to access arbitrary subsets of its state (or of its parts)
¨ The other problem is the consistency of this state...
Cyber/Physical.World.
s"mulus&(events/commands)&&
Input& Output&! State&! Transi"ons&
Distributed.System.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Stimulus in a Distributed System
¨ Internal and Environmental Stimuli in a distributed system are used to¨ evolve the system state
(commands, i.e. do something)¨ notify particular condition on the
state (events, i.e. something happened)
Cyber/Physical.World.
s"mulus&(events/commands)&&
Input& Output&! State&! Transi"ons&
Distributed.System.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
State vs Stimulus
¨ The state of a system is always defined to have a value
¨ A Stimulus only exists at a particular point in time
time
Temp
OverheatAlarm
time
State%
S&mulus%
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Are Commands Different?¨ Commands are a kind of stimulus
that express the need for the system to do something
¨ As commands have the “do something” connotation, it is often useful to synchronously be informed that the “command” has been executed
¨ However systems can be built with both synchronous as well as asynchronous commands
Cyber/Phisycal World
System
Do Something
Done
Asynchronous*
Cyber/Phisycal World
System
DoSomething
Done
Synchronous*
Ope
nSpl
ice
DD
S
State Events and Commands in DDS
Ope
nSpl
ice
DD
S State in DDS
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Distributed State with DDS¨ 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 discipline w.r.t. to the QoS being used and the way in which it is accessed
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
State’s DDS QoSTopics representing state should have the following QoS Settings
¨ RELIABILITY = RELIABLE
¨ HISTORY = KEEP_LAST(1)
¨ DURABILITY = (TRANSIENT |PERSISTENT)
¨ OWNERSHIP = EXCLUSIVE
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Soft-State’s DDS QoSTopics representing soft-state, meaning state that is periodically updated, should have the following QoS Settings
¨ RELIABILITY = BEST_EFFORT
¨ HISTORY = KEEP_LAST(1)
¨ DURABILITY = VOLATILE
¨ OWNERSHIP = EXCLUSIVE
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Accessing State in DDS¨ The DataReader.read operation should be used to
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 following flags:¨ ANY_SAMPLE_STATE¨ ALIVE_INSTANCE_STATE¨ ANY_VIEW_STATE
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example
¨ A Robot Position in 2D is an example of state
¨ Let’s assume that the Robot only update position when it moves
¨ Topic Type:struct RobotPosition { @key long rid; long x; long y;};
[1/3]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example¨ The Topic and DataReader would be constructed as
follows// Create Topic Qosval tQos =
TopicQos() <= KeepLastHistory(1) <= Reliable() <= TransientDurability() <= ExclusiveOwnership() <= SourceTimestamp();
// Create Topicval rpt = Topic[RobotPosition](“RobotPosition”,topicQos)
// Create DataReaderval rpdr = DataReader[RobotPosition](rpt, DataReaderQos(tqos))
[2/3]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example¨ Data can be read as follows
// Read dataval data = rpdr.read(ReadState.AllData) // Or specific to Escalierval data = rpdr.history
[3/3]
Ope
nSpl
ice
DD
S Events in DDS
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Distributed Events with DDS¨ 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 in which it is accessed
¨ Event topics are often keyless
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Events’ DDS QoSEvents should have the following QoS Settings
¨ RELIABILITY = RELIABLE
¨ HISTORY = KEEP_ALL
¨ DURABILITY = VOLATILE
¨ OWNERSHIP = SHARED
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Events’ DDS QoSEvents should have the following QoS Settings
¨ RELIABILITY = RELIABLE
¨ HISTORY = KEEP_ALL
¨ DURABILITY = VOLATILE
¨ OWNERSHIP = SHARED
¨ DESTINATION_ORDER = SOURCE_TIMESTAMP
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Accessing Events in DDS¨ The DataReader.take operation should be used to
access topics representing events¨ This ensures that the DDS cache is always freed by available events
¨ The DataReader data should be accessed with the following flags:¨ NEW_SAMPLE_STATE¨ ALIVE_INSTANCE_STATE¨ ANY_VIEW_STATE
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example
¨ A CollisionEvent could be raised by a Robot when it is colliding (or about to collide) with something
¨ Topic Type:struct CollisionEvent { long detectingRobotId; long collidingRobotId; long xe; long ye;};
[1/3]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example¨ The Topic and DataReader would be constructed as
follows// Create Topic Qosval tQos =
TopicQos() <= KeepAll() <= Reliable() <= VolatileDurability() <= SharedOwnership() <= SourceTimestamp();
// Create Topicval cet = Topic[CollisionEvent](“CollisionEvent”,topicQos)
// Create DataReaderval cedr = DataReader[CollisionEvent](cet, DataReaderQos(tqos))
[2/3]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example¨ Data can be read as follows
// Take dataval data = cedr.take()
[3/3]
Ope
nSpl
ice
DD
S Commands in DDS
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Commands in DDS¨ As explained earlier commands are just a kind of
stimulus
¨ As such could be represented as pairs of events one for the “command request” and the other for the “command reply”
¨ However many people like to deal with commands synchronously, this is why OpenSplice provides now an RMI Framework!
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
OpenSplice RMI¨ Enhances OpenSplice with the ability of defining distributed
Services implementing a well defined service interface
¨ Interfaces are specified in IDL and are fully interoperable with DDS types
¨ Uses DDS mechanism to invoke services
¨ Takes advantage of DDS mechanism for discovery, fault tolerance, one-to-many invocations, etc.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example¨ Suppose our System is composed
by a set of cooperating Robots that are inspecting some assigned region for surveillance, or detecting chemicals, radioactivity, etc.
¨ DDS RMI gives us a way of defining the set of interfaces that constitute the relevant commands and invoke them as traditional RMI
struct Region { long x0; long y0; long width; long height;};
local interface RobotCommands : ::DDS_RMI::Services { void start(); void stop(); void setSpeed(in long s); long getSpeed(); void setSize(in long s); long getSize(); void setRegion(in Region r); Region getRegion(); string getColor(); string getShape();};
[1/2]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Example
¨ Under the hood, appropriate topics are generated by the infrastructure
¨ QoS can be associated to individual methods via an XML file so to further control the semantics of methods invocation
struct Region { long x0; long y0; long width; long height;};
local interface RobotCommands : ::DDS_RMI::Services { void start(); void stop(); void setSpeed(in long s); long getSpeed(); void setSize(in long s); long getSize(); void setRegion(in Region r); Region getRegion(); string getColor(); string getShape();};
[2/2]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Using DDS RMI
Ope
nSpl
ice
DD
S Demo
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Autonomous Robots¨ Let’s build a system in which
¨ 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:¨ A GUI showing the position of the robots and highlighting the
places where something was detected¨ A control application for issuing commands to robots
[1/2]
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
State, Event, Commands¨ State
¨ Robot Position
¨ Events¨ TargetDetected
¨ Commands¨ Robot Control
Ope
nSpl
ice
DD
S Demo in Action
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
Summing Up¨ All Distributed Systems can be decomposed into State and
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 support for Commands!
¨ DDS RMI is built on DDS taking advantage both in terms of performance, fault-tolerance and flexibility.
Copyrig
ht 2010, PrismTech – A
ll Rights Reserved.
Ope
nSpl
ice
DD
S
References
¨ Article comparing performance of Remote Method Invocation using ZeroC ICE and DDS¨ http://bit.ly/nCs66E
¨ DDS RMI Draft RFP¨ http://bit.ly/owCRgK
Ope
nSpl
ice
DD
S
¥ @prismtech
¥ @acorsaro
¥ youtube.com/opensplicetube ¥ slideshare.net/angelo.corsaro
¥ [email protected]¥ [email protected]
¥ opensplice.com ¥ forums.opensplice.org
¥ opensplice.org ¥ [email protected]
:: Connect with Us ::
