Qo SAware PublishSubscribe Service for RealTime Data Acquisition
Qo. S-Aware Publish-Subscribe Service for Real-Time Data Acquisition Xinjie Lv, Xin Li, Tian Yang, Zaifei Liao, Wei Liu, Hongan Wang Institute of Software Chinese Academy of Sciences
Outline ¡ Related works ¡ Expression of Qo. S of Pub-Sub ¡ Enforcement of Qo. S of Pub-Sub ¡ Case Study-A simple application with three requirements ¡ Conclusion 2
Publish-Subscribe Service ¡ Applications: 3
Why Publish-Subscribe Service ¡ Advantages l Space decoupling do not need to know each other. l Time decoupling do not need to be actively participating in the interaction at the same time. l Synchronization decoupling publishers are not blocked and subscribers can get asynchronous notification. 4
Existing Models and Systems ¡ Models l CORBA Event Service l CORBA Notification Service l Java Message Service (JMS) ¡ Systems l Cambridge Event Architecture (CEA) l Distributed Asynchronous Collections (DAC) l Scalable Internet Event Notification Architectures (SIENA) 5
Problem ¡ ¡ ¡ Limited support for the expression of Quality of Service (Qo. S) parameters Limited support for the enforcement of Qo. S parameters Limited support for the Real-Time and active capabilities 6
Expression of Qo. S-DDS ¡ ¡ Data Distribution Service Specification from the Object Management Group (OMG) Aiming at users requiring data-centric publish-subscribe communications Enumerating and providing formal definitions for the Qo. S settings 7
Outline ¡ Related works ¡ Expression of Qo. S of Pub-Sub ¡ Enforcement of Qo. S of Pub-Sub ¡ Case Study-A simple application with three requirements ¡ Conclusion 8
Expression of Qo. S-DDS l Data-Centric Publish. Subscribe (DCPS): efficient delivery of the proper information to the proper recipients. l Data Local Reconstruction Layer (DLRL): integration into the application layer. 9 DCPS conceptual model
Expression of Qo. S-DDS ¡ Supported Group Resources Timeliness Reliability . . . Qo. S of DDS Qo. S Policy Meanings Resource_Limits Controls resources used to meet requirements Time_Based_ Filter Deadline Mediates exchanges between consumers and producers Determines rate at which periodic data is refreshed Latency_Budget Sets guidelines for acceptable end-to-end delays Durability Determines if data outlives the time when written or read Lifespan Sets time bound for “stale” data History Sets how much data is kept to be read Reliability Controls reliability of data transmission . . . 10 . . .
Outline ¡ Related works ¡ Expression of Qo. S of Pub-Sub ¡ Enforcement of Qo. S of Pub-Sub ¡ Case Study-A simple application with three requirements ¡ Conclusion 11
Enforcement of Qo. S-QRTPS ¡ Qo. S-aware Real-Time Publish. Subscribe (QRTPS) service based on an active real-time database named Agilor Overview of Agilor l Real-time Event-Condition-Action (RECA) l 12
Enforcement of Qo. S-Agilor ¡ kernel modules and critical services in Agilor 13
Enforcement of Qo. S-RECA ¡ Primitive events in Agilor: system events l method events l custom events l ¡ Extension Events of Complicated Temporal Durative event, Durative sequence l Durative conjunction, Durative disconjunction l Durative between l 14
Enforcement of Qo. S-RECA ¡ Primitive conditions in Agilor: Selection condition: OP. Gas>20 l Aggregation condition: Max(OP. smog)>100 l Join condition: OP 1. Pressure= OP 2. Pressure l Transition condition: OP 1. Gas> OP 1. Get. Last (Gas) l Application-specific condition l 15
Enforcement of Qo. S-RECA ¡ Actions in Agilor: database operations: deletion, update l external actions: publish data, signal an alarm. l deadline assigned to the action: relative to the occurrence time of the triggering event. l 16
Enforcement of Qo. S-RECA ¡ Coupling Modes in Agilor: CMEC: Event-Condition; CMCA: Condition-Action CMEA: Event-Action; CMRR: Rule-Rule ¡ Semantic for RECA Rules Rule: : =BEGIN RULE <Rule. Name> VALUE <Value> WHEN <Event> IF <Condition> CMEC [immediate|detached] CMEA [immediate|detached] THEN <Action> WITHIN <Deadline> CMCA [immediate|detached] CMRR [immediate|concurrent] END RULE 17
Outline ¡ Related works ¡ Expression of Qo. S of Pub-Sub ¡ Enforcement of Qo. S of Pub-Sub ¡ Case Study-A simple application with three requirements ¡ Conclusion 18
Case Study-Overview ¡ Real-Time monitoring in a coal mine 19
Case Study-Requirements ¡ Three requirements: 1. Late-joining applications shall receive meta information about its sensors automatically; 2. Receiving gas sensor data every 500 ms and temperature data every 1000 ms; 3. If no data from most-trusted sensor source is received within 4000 ms, temperature data shall automatically be received from another Observation Point (OP). 20
Case Study-Data Structures l l Gas : transmitting the sensor readings Gas. Sensorlnfo : containing meta-information to interpret the sensor data correctly Class Gas{ private: long datacollector_id; long observationpoint_i d; double value; }; Class Gas. Sensor. Info{ private: long datacollector_id; long observationpoint_id ; Measuring. Unit unit; double max. Gas; 21 double min. Gas;
Case Study-Qo. S Parameters Require ment Data Entity Qo. S Policy of Topic. Consumer 1 Gas. Sensor. Info, Temperature. Sens or. Info, Smog. Sensor. Info 2 Gas TIME_BASED_FILTER =500 ms Temperature TIME_BASED_FILTER =1000 ms 3 Temperature Qo. S Policy of Topic. Producer HISTORY. depth = 1 RELIABILITY. kind=RELIABLE DURABILITY. kind =TRANSIENT_LOCAL OWNERSHIP. kind=EXCLUSIVE OWNERSHIP. kind OWNERSHIP_STRENGTH. value =EXCLUSIVE = datacollectorid of the data collector DEADLINE. period. sec = 5 =5 22
Case Study-Expressing in RECA BEGIN RULE Rule_1 // Requirement 1 VALUE 1 WHEN On. Start. Up(“Data. Collector. ID”) IF True THEN global Gas. Meta. Info ggasmetainfo; ggasmetainfo. datacollector_id=1; ggasmetainfo. observationpoint_id=1; …… ggasmetainfo. sample. Rate=5; WITHIN 1 END RULE BEGIN RULE Rule_2 // Requirement 2 VALUE 1 WHEN On. Timer("Timer 1 ", 1) IF True THEN variant currentvalue; currentvalue =Tag. Value(“OP 1. Temp. Sensor 1”); …… WITHIN 1 END RULE 23
Case Study-Expressing in RECA BEGIN RULE Rule_3 //Requirement 3 VALUE 1 WHEN On. Timer("Timer 2", 10) IF True THEN variant currentvalue; long currenttime; long begintime; begintime = Current. Time(); while(Tag. State(“Temp. Sensor 2”)) { currentvalue =Tag. Value(“OP 1. Temp. Sensor 1”); currenttime = Current. Time(); if((currenttime- begintime)>4) { currentvalue =Tag. Value(“OP 2. Temp. Sensor 2”); …… break; } } WITHIN 1 END RULE 24
Case Study-Application Screenshot 25
Outline ¡ Related works ¡ Expression of Qo. S of Pub-Sub ¡ Enforcement of Qo. S of Pub-Sub ¡ Case Study-A simple application with three requirements ¡ Conclusion 26
Conclusions ¡ Expressing Qo. S with DDS ¡ Enforcing Qo. S policy with Agilor ¡ ¡ Improving Real-time and active capabilities with RECA Evaluating QRTPS for a Real-time monitoring 27
Thank you 28
- Slides: 28