Building Reactive Applications with DDS

Post on 10-May-2015

1853 Views

Category:

Technology

3 Downloads

Preview:

Click to see full reader

DESCRIPTION

Reactive architectures are emerging as the way to build systems that are responsive, scalable, resilient and event-driven. In other terms, systems that deliver highly responsive user experiences with a real-time feel, that are scalable, resilient, and ready to be deployed on multicore and cloud computing architectures. The Reactive Manifesto (see http://www.reactivemanifesto.org/) captures the key traits that characterize reactive architectures. The Data Distribution Service (DDS) incarnates the principles enumerated by the reactive manifesto and provides a very good platform for building reactive systems. In this webcast I will (1) introduce the key principles of Reactive Architectures, (2) explain the DDS features that are essential to build reactive systems, and (3) introduce some programming techniques that remove inversion of control while maintaining applications even-driven.

Transcript

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Defense and Aerospace

Integrated Modular Vetronics Training & Simulation Systems Naval Combat Systems

Air Traffic Control & Management Unmanned Air Vehicles Aerospace Applications

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Industrial Internet

Autonomous Vehicle Systems

Train Control / Management Systems Connected Medical Devices

Smart CitiesSmart Grids / Power Generation

Financial Services

Reactive Systems

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Reactive

• react to an environment which “cannot wait”, e.g. reacting late has harsh consequences

• response time needs to be deterministic

• distributed concurrent systems

• data-centric

Reactive vs. Interactive SystemsInteractive

• react to an environment which “doesn’t like to wait”, e.g. reacting late induces QoS degradation

• response time needs to be acceptable

• distributed concurrent systems

• data-centric

The term reactive systems is increasingly used to denote interactive systems with stringent response time, performance and scalability constraints.

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Concurrency

• Aside from the concurrency between the system and its environment, it is natural to decompose these systems as an ensemble of concurrent components that cooperate to achieve the intended behaviour

Strict Temporal Requirements

• Reactive Systems have strict requirements with respect to the rate at which the need to process input as well as the response time for their outputs

Determinism

• The output of these systems are generally determined by the input and the occurrence time, e.g. no scheduling effects on the temporal properties of the output

Reliability

• Reactive Systems are often life/mission critical, as such reliability is of utmost importance

Reactive Systems Key Traits

Architectural Styles for Reactive Systems

Stream Processing with DDS

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

•As explained in the previous slide a topic defines a class/type of information

•Topics can be defined as Singleton or can have multiple Instances

•Topic Instances are identified by means of the topic key

•A Topic Key is identified by a tuple of attributes -- like in databases

•Remarks:

• A Singleton topic has a single domain-wide instance

• A “regular” Topic can have as many instances as the number of different key values, e.g., if the key is an 8-bit character then the topic can have 256 different instances

Topic and Instances

DDS Architectural Benefits

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

• The Data Distribution Service (DDS) was introduced as an OMG standard in 2006 to address Real-time and interoperable Data Sharing in Network Centric Systems

• Key requirements for the standard were high and predictable performance, and scalability to ultra-large-scale deployments

• DDS is recommended by key administration worldwide, e.g. DoD, MoD, EUROCAE, etc. and widely adopted across application domains, e.g., Automated Trading, Simulations, SCADA, Telemetry, etc.

Standard and Interoperable

Escape from Callback-Hell

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

• The Inversion of Control induced by callback-based code in known to make applications brittle and harder to understand

• As an mental exercise, think about the call-back style code you’d have to write to in Java for drawing when the mouse is being dragged. Although the logic is simple, it is far cry from having a “declarative style”

• The problem of callback management, infamously known as Callback Hell, has become even more important due to the surge of Reactive Systems…

• Can we escape the Callback Hell?

The Callback Hell

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

• Reactive Programming is a paradigm based on a relaxed form of Synchronous Dataflow Programming

• The Reactive Programming is built around the notion of continuous time-varying values and propagation of change

• Reactive Programming facilitates the declarative development of non-blocking event driven applications — in essence you express what should be done and the runtime decides when to do it

• Reactive Programming was popularised in the context of Functional Programming Languages by the seminal done by Elliot and Hudak in 1997 as part of Fran — a framework for composing richly interactive multimedia animations

Reactive Programming

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Time for Common Operations

http://norvig.com/21-­‐days.html

execute typical instruction 1/1,000,000,000 sec = 1 nanosecfetch from L1 cache memory 0.5 nanosecbranch misprediction 5 nanosecfetch from L2 cache memory 7 nanosecMutex lock/unlock 25 nanosecfetch from main memory 100 nanosecsend 2K bytes over 1Gbps network 20,000 nanosecread 1MB sequentially from memory 250,000 nanosecfetch from new disk location (seek) 8,000,000 nanosecread 1MB sequentially from disk 20,000,000 nanosecsend packet US to Europe and back 150 milliseconds = 150,000,000 nanosec

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

• Beside from the standard RxJava/RxScala Observable, each framework that wants to integrate with RxJava/RxScala has to provide its own factory methods to create observables

• For DDS you have to use the DdsObservable defined as follows:

DDS Observables

object  DdsObservable  {  

   def  fromDataReaderData[T](dr:  DataReader[T]):  Observable[T]  

   def  fromDataReaderEvents[T](dr:  DataReader[T]):  Observable[ReaderEvent[T]]  

   //  more  methods  which  we’ll  ignore  for  the  time  being  

}

Coding Lab

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Step 1: Implement Listenerclass  ShapesListener  extends  DataReaderListener[ShapeType]  {  !    def  onRequestedDeadlineMissed(p1:  RequestedDeadlineMissedEvent[ShapeType]):  Unit  !    def  onRequestedIncompatibleQos(p1:  RequestedIncompatibleQosEvent[ShapeType]):  Unit  !    def  onSampleRejected(p1:  SampleRejectedEvent[ShapeType]):  Unit  !    def  onLivelinessChanged(p1:  LivelinessChangedEvent[ShapeType]):  Unit  !    def  onDataAvailable(p1:  DataAvailableEvent[ShapeType]):  Unit  !    def  onSubscriptionMatched(p1:  SubscriptionMatchedEvent[ShapeType]):  Unit  !    def  onSampleLost(p1:  SampleLostEvent[ShapeType]):  Unit  }

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Midpoint Triangle        val  circles  =  DdsObservable.fromDataReaderData  {              DataReader[ShapeType](Topic[ShapeType](circle))          }          val  squares  =  DdsObservable.fromDataReaderData  {              DataReader[ShapeType](Topic[ShapeType](square))          }          val  ttopic  =  Topic[ShapeType](triangle)          val  tdw  =  DataWriter[ShapeType](ttopic)  !!        //  Compute  the  average  between  circle  and  square  of  matching  color  with  flatMap          val  triangles  =  circles.flatMap  {              c  =>  squares.dropWhile(_.color  !=  c.color).take(1).map  {                  s  =>  new  ShapeType(s.color,  (s.x  +  c.x)/2,  (s.y  +  c.y)/2,  (s.shapesize  +  c.shapesize)/4)              }          }  !        triangles.subscribe(tdw.write(_))  

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

Using for-comprehension            //  Compute  the  average  between  circle  and  square  of  matching  colour  with  flatMap          val  triangles  =  circles.flatMap  {              c  =>  squares.dropWhile(_.color  !=  c.color).take(1).map  {                  s  =>  new  ShapeType(s.color,  (s.x  +  c.x)/2,  (s.y  +  c.y)/2,  (s.shapesize  +  c.shapesize)/4)              }          }  

           //  Compute  the  average  between  circle  and  square  of  matching  colour  with  for  comprehension          val  triangles  =  for  {                c  <-­‐  circles;                s  <-­‐  squares.dropWhile(_.color  !=  c.color).take(1)          }  yield  new  ShapeType(s.color,  (s.x  +  c.x)/2,  (s.y  +  c.y)/2,  (s.shapesize  +  c.shapesize)/4)  

Summing Up

Cop

yrig

ht P

rism

Tech

, 201

4

PrismTech

• Many of the requirements of traditional Reactive Systems are applicable to many mainstream application domains

• Stream Processing Architecture and Reactive Programming can greatly help in the design and implementation of Reactive Systems that are efficient, responsive, resilient, scalable and highly available

• As proven through years of deployments DDS provides the ideal infrastructure technology for Reactive Systems

• The combination of DDS with Reactive Programming makes for a very powerful platform!

Concluding Remarks

top related