Intelligent Event Processing in Quality of Service (QoS) Enabled Publish/Subscribe (Pub/Sub) Middleware

Transcription

1 Intelligent Event Processing in Quality of Service (QoS) Enabled Publish/Subscribe (Pub/Sub) Middleware Joe Hoffert CS PhD Student Vanderbilt University Nashville, Tennessee

2 Context: Event Processing Systems Intelligent Event Processing Wide range of application domains Ambient assisted living Fractionated satellite systems Weather monitoring Disaster recovery Stock quote update systems Challenge: Supporting QoS & Managing Complexity Wide range of QoS needed Examples: low latency, reliable event sender delivery, coordinated data streams, fault tolerance sender Interacting QoS demands Solution: QoS-enabled Pub/Sub Middleware Intelligent processing of events QoS primitives for low level functionality Patterns for higher level functionality Reliability receiver receiver Durability Deadline receiver 11/1/2010 Joe Hoffert, Vanderbilt University 2 X sender replica replica QoS Pattern

3 QoS-enabled Pub/Sub Middleware Case Study Object Management Group s Distribution Service (DDS) Application Application Global Store Application Application Workload & Replicas Connections & priority bands Application CPU & memory Network latency & bandwidth DDS provides flexibility, power, & modular structure by decoupling: Location anonymous pub/sub Redundancy any number of readers & writers QoS async, disconnected, time-sensitive, scalable, & reliable data distribution at multiple layers Platform & protocols portable & interoperable 11/1/2010 Joe Hoffert, Vanderbilt University 3

4 DDS Domains & Domain Participants The domain is the basic construct used to bind individual applications together for communication Domain 2 Domain 3 Like a VPN 2 1 Node 1 Node 3 Node 1 Node 1 2 Node 3 Node DomainParticipant Domain 1 11/1/2010 Joe Hoffert, Vanderbilt University 6

5 DDS Entities DDS Entities include DomainParticipants Entry points Topics Typed data Publishers Manage Writers s Manage Readers can be accessed in two ways Wait-based (synchronous calls) Listener-based (asynchronous callbacks) Sophisticated support for filtering e.g., Topic, Content-FilteredTopic, or MultiTopic Configurable via (many) QoS policies Topic Topic Topic Domain Participant Reader Writer Writer Reader Reader Writer Publisher Publisher Domain 11/1/2010 Joe Hoffert, Vanderbilt University 7

6 QoS Policies Supported by DDS DDS entities (i.e., topics, data readers/writers) configurable via QoS policies QoS tailored to data distribution in distributed realtime & embedded (DRE) information systems DEADLINE RELIABILITY (BEST_EFFORT, RELIABLE) Establishes contract regarding rate at which periodic data is refreshed LATENCY_BUDGET Establishes guidelines for acceptable end-to-end delays TIME_BASED_FILTER Mediates exchanges between slow consumers & fast producers RESOURCE_LIMITS Controls resources utilized by service Enables use of real-time transports for data HISTORY (KEEP_LAST, KEEP_ALL) Controls which (of multiple) data values are delivered DURABILITY (VOLATILE, TRANSIENT, PERSISTENT) Determines if data outlives time when they are written and many more Request/offered compatibility checked by DDS, helps to manage complexity 11/1/2010 Joe Hoffert, Vanderbilt University 8

7 Types & Keys A DDS Type is represented by a collection of data items. e.g. IDL struct in the CORBA Platform Specific Model (PSM) struct AnalogSensor { }; string sensor_id; // key float value; // other sensor data A subset of the collection is designated as the Key. The Key can be indicated by IDL annotation in CORBA PSM, e.g., #pragma DDS_KEY AnalogSensor::sensor_id The type is manipulated by means of automatically-generated typed interfaces. IDL compiler may be used in CORBA PSM implementation A Type is associated with generated code: AnalogSensorWriter // write values AnalogSensorReader // read values AnalogSensorType // can register itself with Domain 11/1/2010 Joe Hoffert, Vanderbilt University 9

8 Topics A DDS Topic is the connection between data writers & data readers. A Topic is comprised of a Name and a Type. Name must be unique in the Domain. Many Topics can have the same Type. Provision is made for contentbased subscriptions. MultiTopics correspond to SQL join Content-Filtered Topics correspond to SQL select. Domain ID 35 Topic name MySensor Type name AnalogSensor string sensor_id [ key ] float value 11/1/2010 Joe Hoffert, Vanderbilt University 10

9 Writers & Publishers Writers are the primary access point for an application to publish data into a DDS data domain The Publisher entity is a container to manage one or more Writers Publishers & Writers can have their own QoS policies User applications Associate Writers with Topics Provide data to Writers is typically defined using OMG IDL As strongly or weakly typed as desired 11/1/2010 Joe Hoffert, Vanderbilt University 11

10 Readers & s A Reader is the primary access point for an application to access data that has been received by a is used to manage one or more Readers s & Readers can have their own QoS policies User applications Associate Readers with Topics Receive data from Readers using Listeners (async) or Wait-Sets (sync) 11/1/2010 Joe Hoffert, Vanderbilt University 12

11 Overview of the Distribution Service (DDS) DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead Writer T Topic T Reader T Publisher RT Info to Cockpit & Track Processing DDS Pub/Sub Infrastructure Tactical Network & RTOS 11/1/2010 Joe Hoffert, Vanderbilt University 13

12 Overview of the Distribution Service (DDS) DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead DDS provides meta-events for detecting dynamic changes Writer T Topic T NEW DATA TYPE Reader T NEW DATA RECEIVER Publisher NEW DATA SENDER 11/1/2010 Joe Hoffert, Vanderbilt University 14

13 Overview of the Distribution Service (DDS) DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead DDS provides meta-events for detecting dynamic changes DDS provides policies for specifying many QoS requirements of tactical information management systems, e.g., Establish contracts that precisely specify a wide variety of QoS policies at multiple system layers Writer T Publisher S7 HISTORY S7X S1 S2 S3 S4 S5 S6 S7 Topic T LATENCY S6 S5 S4 S3 S2 S1 RESOURCE LIMITS Reader T RELIABILITY COHERENCY 11/1/2010 Joe Hoffert, Vanderbilt University 15

14 Overview of the Distribution Service (DDS) DDS is an highly efficient OMG pub/sub standard e.g., fewer layers, less overhead DDS provides meta-events for detecting dynamic changes DDS provides policies for specifying many QoS requirements of tactical information management systems, e.g., Establish contracts that precisely specify a wide variety of QoS policies at multiple system layers Move processing closer to data Writer T Publisher S1 S2 S3 S4 S5 S6 S7 Topic T TIME-BASED FILTER SOURCE FILTER DESTINATION FILTER Reader T 11/1/2010 Joe Hoffert, Vanderbilt University 16

15 All QoS Policies in DDS Deadline Destination Order Durability Durability Service Entity Factory Group History Latency Budget Lifespan Liveliness Ownership Ownership Strength Partition Presentation Reader Lifecycle Reliability Resource Limits Time-Based Filter Topic Transport Priority User Writer Lifecycle Detailed explanations in DDS specification 11/1/2010 Joe Hoffert, Vanderbilt University 17

16 Best Effort Reliability QoS in DDS QoS Reliability = BEST_EFFORT Publisher Global Store Notification of new data objects time-based filter deadline timeout no notification notification time Very predictable is sent without reply Publishers and subscribers match and obey QoS Deadline policy settings Time-based Filter QoS policy gives bandwidth control 11/1/2010 Joe Hoffert, Vanderbilt University 18

17 Reliable QoS in DDS QoS Reliability = RELIABLE history Topic T Writer T Publisher S1 S2 S3 S4 S5 S6 S7 Reader T S7 S6 S5 S4 S3 S2 S1 Ordered instance delivery is guaranteed 11/1/2010 Joe Hoffert, Vanderbilt University 19

18 Topic-Based Publish/Subscribe Pressure Temperature Writer is bound (at creation time) to a single Topic Reader is bound (at creation time) with one or more topics (Topic, ContentFilteredTopic, or MultiTopic) ContentFilteredTopic & MultiTopic provide means for content-based subscriptions & joins, respectively 11/1/2010 Joe Hoffert, Vanderbilt University 22

19 Content-based Subscriptions ContentFilteredTopic (like a DB-selection) Enables subscriber to only receive data-updates whose value verifies a condition. e.g. subscribe to Pressure of type Analog where value > 200 MultiTopic (like a DB-join operation) Enables subscription to multiple topics & re-arrangement of the dataformat e.g. combine subscription to Pressure & Temperature & rearrange the data into a new type: struct { float pres; float temp; }; 11/1/2010 Joe Hoffert, Vanderbilt University 24

20 DDS Content-Filtered Topics Topic Instances in Domain Instance 1 Instance 2 Instance 3 Instance 4 Instance 5 Instance 6 Instance 7 Value = 249 Value = 230 Value = 275 Value = 262 Value = 258 Value = 261 Value = 259 Content-Filtered Topic Topic Filter Expression: Value > 260 Expression Params Filter Expression and Expression Params determine which Topic instances the receives. 11/1/2010 Joe Hoffert, Vanderbilt University 25

21 DDS MultiTopic Subscriptions Topic A Topic B Topic C Topic D MultiTopic Domain Participant Reader Reader Reader Reader Domain Participant MultiTopics can combine, filter, and rearrange data from multiple Topics. 11/1/2010 Joe Hoffert, Vanderbilt University 26

22 QoS Pattern for Consistency Goal: Have all data readers receive same data in same order from all data writers even in event of crash Approach: Compose support for consistency using QoS primitives DURABILITY Set to PERSISTENT survives crash of the data writers/readers Consistency Pattern RELIABILITY Set to RELIABLE sent from single writer received in order sent Durability Reliability DESTINATION_ORDER Set to SOURCE_TIMESTAMP sent from multiple writers received in order sent LIFESPAN Set to INFINITE Designate data as valid until taken by reader Destination Order Lifespan 11/1/2010 Joe Hoffert, Vanderbilt University 27

23 QoS Pattern for Fault Tolerance Goal: Have data writer fail over to replica if non-responsive Approach: Compose support for fault tolerance using QoS primitives LIVELINESS Set to AUTOMATIC Loss of heartbeat triggers failover DEADLINE PERIOD set to maximum latency of data not received within period triggers failover Fault Tolerance Pattern Liveliness Deadline OWNERSHIP Set to EXCLUSIVE only received from one data writer OWNERSHIP_STRENGTH VALUE reflects order/importance of replica Determines who takes over after fault Ownership Ownership Strength 11/1/2010 Joe Hoffert, Vanderbilt University 28

24 Concluding Remarks Supporting & managing intelligent event processing can be challenging Wide range of QoS needed Complex interactions QoS-enabled Pub/Sub middleware can help QoS primitives for low level functionality Patterns for higher level functionality Additional resources OMG DDS specification (portals.omg.org/dds) DDS patterns RT_2006_Workshop_CD/05-1_Hunt.pdf Thank you for your time and attention Reliability Durability Deadline QoS Pattern Soli Deo Gloria 11/1/2010 Joe Hoffert, Vanderbilt University 29