The OMG Real Time Data Distribution Service HansArno
The OMG Real Time Data Distribution Service Hans-Arno Jacobsen E-mail: jacobsen@eecg. toronto. edu Phone: 416 -946 7586 Department of Electrical and Computer Engineering & Department of Computer Science University of Toronto
Outline • • Motivating Example Requirements & Characteristics The OMG DDS Service Our Research in this Space ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Motivating Application Examples • • Air traffic control Network equipment management Industrial automation Traffic control Railroad control Command control (e. g. , C 4 I) Distributed control and simulations … ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Characteristics and Requirements • Data-centric exchange of information and coordination of activities • Loosely coupled • Operate on global data space • Publish/Subscribe-style interactions • Continuously and dynamically evolving • All are (soft, hard, or quasi) real-time needy – Primary concern: efficient data distribution with minimal overhead – Requires ability to control Qo. S properties: predictability, overhead, and resources used – Also requires ability to scale to hundreds and even thousands of entities • Hierarchical data model • Need for reliability and ICDCSfault 1 DDRTStolerance Workshop, 2003 st Hans-Arno Jacobsen, University of Toronto
Global Data Space node ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Hierarchical Data Representation controller(s) plants subscribe sub-systems sensors 1000+ ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Publish/Subscribe TSX Stock markets NASDAQ NYSE AMG N Publisher =58 12 ORCL= HON=24 MSFT =27 Publisher =84 IBM JNJ= 58 19 = C T Publications IN Broker Subscriptions: IBM > 85 ORCL < 10 JNJ > 60 Notification Subscriptions Subscriber ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
The OMG DDS • • Overview Architecture Data-Centric Publish/Subscribe Layer Data Local Reconstruction Layer Aims to address many of the afore mentioned requirements and more. ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
The OMG DDS • Request for Proposal issued in 9/2001 • Speared-headed by Real-Time Innovations, THALES, Objective Interface Systems, MITRE, and University of Toronto • Submission “proof-of-concept” in existing products and research prototypes – NDDS from RTI – SPLICE from THALES – To. PSS (Toronto Publish/Subscribe System) MSRG @ Uof. T ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DDS Overview • DDS comprises two layers: – DCPS (Data Centric Publish/Subscribe) • To distribute the data – DLRL (Data Local Reconstruction Layer) • To build a local object cache allowing applications to access the data “as if it was local” • Specified according to OMG’s MDA approach – PIM (abstract view of the service) – CORBA PSM (concrete view when using CORBA) • Focuses only on the interface between the application and the service – Does not address the exchanges between the different actors implementing the service – Does not address scheduling of resources internal to DDS ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DDS Logical Architecture I Application Data Local Reconstruction Layer Data-centric Publish/Subscribe ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DDS Logical Architecture II { The Application DLRL DCPS Communication ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto Application DLRL
DCPS Overview • DCPS Models the DDS service with – – – Domain. Participant Topic & Data Type Data. Writer Publisher Data. Reader Subscriber • Configurable by Qo. S profiles • Data can be accessed in two ways – Listener based (asynchronous via callbacks) – Wait based (synchronous) • Similar for queriying communication status ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Domains and Participants Domain 2 3 1 1 2 1 Domain. Participant 3 1 • like a virtual private network ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto Domain Node
Domain. Participant Publisher Subscriber Data. Writer Data. Reader • Domain. Participant ~ Represents participation of the application in the communication collective • Data. Writer ~ Accessor to write typed data on a particular Topic • Publisher ~ Aggregation of Data. Writer objects. Responsible for disseminating information (i. e. , for publishing). • Data. Reader ~ Accessor to read typed data regarding a specific Topic • Subscriber ~ Aggregation of Data. Reader objects. Responsible for ICDCS 1 DDRTS Workshop, 2003 receiving information (i. e. , for subscribing). Hans-Arno Jacobsen, University of Toronto st
Topic-Based Publish/Subscribe • Topic is used to associate Data. Writers and Data. Readers – Described by a string. E. g. “Pressure” – Bound on a single data-type e. g. struct Analog. Sensor { … }; – Represents a collection of data-objects distinguished by means of an application-defined key e. g. struct Analog. Sensor { string sensor_id; // key float value; // other sensor data }; ICDCS 1 DDRTS Workshop, 2003 • Provision for content-based subscriptions Hans-Arno Jacobsen, University of Toronto st
Types • Represent the data-type (format of the information) – E. g. “IDL struct” in the CORBA PSM – Provides description of application-defined key • Manipulated only by means of automatically -generated typed interfaces • Given type “Foo” associated with generated code: – Foo. Data. Writer – Foo. Data. Reader – Foo. Type // write values // read values) // register type // description in DDS DDRTS Workshop, 2003 ICDCS 1 st Hans-Arno Jacobsen, University of Toronto
Topic-Based Publish/Subscribe Pressure Temperature • Data. Writer is bound (at creation time) to a single Topic • Data. Reader is bound (at creation time) with one or more topics (Topic, Content. Filtered. Topic, or Multi. Topic) • Content. Filtered. Topic and Multi. Topic provide means for content-based subscriptions ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Subscription = Topic + Data. Reader application Data Reader Qo. S Topic 1 Topic 2 Topic n Qo. S subscriber ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Qo. S • All DCPS entities configurable by means of Qo. S. • Qo. S tailored to data-distribution in real-time systems. – RELIABILITY (BEST_EFFORT, RELIABLE) • Enables use of efficient transports for repetitive data – DEADLINE • Establishes contract regarding rate at which repetitive data is refreshed – LATENCY_BUDGET • Establishes guidelines for acceptable delays – RESOURCE_LIMITS • Controls resources utilized by the service – TIME_BASED_FILTER • Decouples fast producers from slow consumers – HISTORY (KEEP_LAST, KEEP_ALL) • Supports semantics of state-data – DURABILITY (VOLATILE, TRANSIENT, PERSISTENT) – and others… • Request/offered compatibility checked by DDS ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Content-based Subscriptions • Content. Filtered. Topic (like a DB-selection) – Enables subscriber to only receive data-updates whose value verifies a condition. – E. g. subscribe to “Pressure” of type Analog. Data – where “value > 200” • Multi. Topic (like a DB-join operation) – Enables subscription to multiple topics and rearrangement of the data-format – E. g. combine subscription to “Pressure” and “Temperature” and re-arrange the data into a new type: struct { float pres; float temp; }; ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Support for State-data Coherence • Allow to access a set of modifications as-if made “atomically” – Restricted to modifications by the same Publisher ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Example: Subscription Subscriber subs = domain->create_subscriber( subscriber_qos, subscriber_listener); Topic topic = domain->create_topic( “Track”, “Track. Struct”, topic_qos, topic_listener); Data. Reader reader = subscriber->create_datareader( topic, reader_qos, reader_listener); ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Example: Publication Publisher publisher = domain->create_publisher( publisher_qos, publisher_listener); Topic topic = domain->create_topic( “Track”, “Track. Struct”, topic_qos, topic_listener); Data. Writer writer = publisher->create_datawriter( topic, writer_qos, writer_listener); Track. Struct my_track; Writer->write(&my_track); ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Summary of DCPS features • Efficient Publish/Subscribe interfaces • Qo. S suitable for real-time systems – deadlines, levels of reliability, latency, resource usage, time-based filter • Listener and wait-based data access – Suits different application styles • Support for content-based subscriptions • Support for data-ownership • Support for history and persistence of data-modifications ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Overview of DRLR • • • Goals of DLRL objects Structural Mapping DLRL entities Layer is optional and it still is under discussion ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Data Local Reconstruction Layer Track 3 D_Track DLRL Cache Track_Topic 3 D -Track ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto DCPS
Goals of DLRL • • Data Local Reconstruction Layer DLRL model is local to an application Object oriented access to data Application developer will be able to – describe classes with their methods, data fields and relations – attach some of those data fields to DCPS entities – manipulate these objects (i. e. create, read, write, delete) using native language constructs – activate attached DCPS entities to update objects – have these objects managed in a cache • Like a mapping or binding (intuition only) ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DLRL Objects • DLRL objects are (native) language objects with: – data members and methods • Only the data members are relevant to data distribution; they can be: – attributes, i. e. , values – relations, i. e. , reference other objects – plain local data membres (i. e. , not known or involved in data distribution) are also supported • DLRL classes can be organised by inheritance • DLRL objects maps to one or more DCPS Topics ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DLRL Object Examples ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Structural Mapping • The structural mapping describes the links between DLRL objects and DCPS data – e. g. , in which 'topic' a given DLRL attribute will be put. . . – close to Object-to-Relational mapping ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Example TRACK_TOPIC Class Oid x y radar Track 1 100 200 11 Track 3 D 2 102 201 11 COMMENTS_TOPIC Class T 3 D_TOPIC z Oid 2 300 11 comments Track 1 0 a comment Track 1 1 another comment RADAR_TOPIC Oid index RADAR-TRACKS_TOPIC R_Oid index T_Class T_Oid 11 0 Track 1 ICDCS DDRTS Workshop, 2003 11 Hans-Arno Jacobsen, University of Toronto 1 Track 3 D 2 1 st
How This May Work? Model description Model Tags DLRL Generator Native model description Dedicated DLRL entities ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto DCPS description
Mapping DLRL to DCPS continued • Structural mapping relationship between DLRL objects and DCPS data (i. e. , topics) • Operational mapping of DLRL objects to DCPS Entities (i. e. , Publisher, Data. Writer, …) • Functional mapping relation between DLRL functions and DCPS functions (write/publish) • DLRL entities: Cache … ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
The MSRG’s Research Projects in this Context research projects ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Overview of Our Research Interests • Efficient single-broker design (To. PSS project) – Publish/subscribe matching problem – Application programming model and data model – DDS design, implementation, and evaluation • Efficient data-routing in multi-broker network (distributed To. PSS project) • Design and implementation of nonfunctional requirements in middleware via aspect oriented programming (AOM project) ICDCS 1 DDRTS Workshop, 2003 st Hans-Arno Jacobsen, University of Toronto
Qualitatively Speaking Research Challenges & Requirements • large number of subscriptions (several per user) • volatile subscriptions (changing subscriber interests) • high rates of information input (e. g. , news, location information per user … ) • different content formats (XML, HTML, WML, ASCII) We develop efficient filtering, matching, correlation and data routing algorithms ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
The Toronto Publish/Subscribe System Project (To. PSS) • overall middleware platform framework to address these challenges • support information dissemination applications in networked environments (mobile wireless, Internet, Intranets) • support location-based services • support network management and monitoring & control applications • framework components: – To. PSS: Toronto Publish/Subscribe System • high-performance matching kernel – pervasive notification engine (unified messaging) – context-aware extension to pervasive notification engine ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
To. PSS Information consumer subscribe to information of interest. Information producer publish information. To. PSS-broker(s) match and route relevant information to interested subscriber. To. PSS, the Toronto Publish/Subscribe System is a flexible, highperformance matching kernel with numerous extensions: Location-based matching (L-To. PSS) Semantic matching-based (S-To. PSS) Approximate matching-based (A-To. PSS) Prof. Arno Jacobsen Distribution and mobility support Applications: Selective information dissemination and location-based services etc. publishers subscribers To. PSS Family of Publish/Subscribe Systems
Research Projects Overview • To. PSS: Toronto Publish/Subscribe System – research prototype that can manage up to 10 million subscribers with an event matching performance in the millisecond range – High-performance matching kernel • L-To. PSS: location-based – support location information as additional dimension • A-To. PSS: approximate matching-based – processing of uncertain information • subscribe to events “close to downtown” Toronto • publish approximate subscriber location: “nearby CN tower” • X-To. PSS: XML-based – subscribe to documents marked up in XML (e. g. , web-pages) – publish XML content • S-To. PSS: semantic-based – subscribe to one concept (e. g. , in English “born in 1962”) – publish an ontologically related concepts (e. g. , in French, Chinese, … “Elle a 42 ans”) ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Subscription Matching Performance (byte / bit-matrix vs. list-based) bit list ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto 10 M
Thanks for coming ! ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Selected References • www. eecg. toronto. edu/~jacobsen • • soon www. msrg. org S-To. PSS. VLDB 2003. A-To. PSS VLDB 2002 Quantifying Aspect in Middleware. AOSD’ 02. Middleware Services for Location-based Information Dissemination. H. -A. Jacobsen. Middleware 2001. The Push-Mi, Pull-Yu Event Notification Kernel for Enhanced Publish/Subscribe. H. -A. Jacobsen. Middleware 2001. Publish/Subscribe Systems. H-Arno Jacobsen, F. Llirbat Tutorial at ICDE 2001. Filtering Algorithms and Implementation for Very Fast Publish/subscribe Systems. F. Fabret, H-Arno Jacobsen, F. Llirbat, J. Pereira, K. A, Ross, D. Shasha, SIGMOD 2001. Web. Filter: High-Throughput XML-based Publish/Subscribe. F. Fabret, H-Arno Jacobsen, F. Llirbat, J. Pereira, D. Shasha, VLDB 2001. • … ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Conformance Statement • Several profiles: – Minimum: Just mandatory features of DCPS • must always be supported – Content-subscription: Minimum plus… • classes: Content. Filtered. Topic, Query. Condition, Multi. Topic – Persistence: Minimum plus… • ‘PERSISTENT’ setting of the DURABILITY Qo. S • Enables use of permanent storage to persist data – Ownership: Minimum plus… • ‘EXCLUSIVE’ setting of the OWNERSHIP Qo. S. • OWNERSHIP_STRENGTH policy. • Setting of depth > 1 for the HISTORY Qo. S. – Object model: Minimum plus… • ‘GROUP’ setting of PRESENTATION access_scope • DLRL layer • Implementation might support multiple profiles – E. g. Minimum + Content-subscription + Ownership ICDCS 1 DDRTS Workshop, 2003 st Hans-Arno Jacobsen, University of Toronto
Predicate Matching Performance (tables-based vs. list-based scheme) for the mixed domain 4 M 1 st ICDCS DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Predicate Matching Data Structure Size (table-based vs. list-based scheme) 1. 4 GB 20 MB ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto 4 M
Subscription Matching Data Structure Size list bit ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto 10 M
DBMS-based Matching ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DLRL backup slides ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Operational Mapping • Describes associations between a DLRL class and DCPS entities – DLRL class -> several 'topics' -> several 'datareaders/writers' – All attached to the same 'subscriber/publisher' • DLRL operations are provided to create all the entities that correspond to a set of DLRL classes • No Qo. S settings at DLRL level – Means to retrieve the DCPS entities to set Qo. S if needed ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
Functional Mapping • Describes translation between DLRL functions and DCPS functions • DLRL functions – Publishing only nodes • create objects, modify them, possibly destroy them • request for publication of the performed changes (creations, modifications, destructions) – Subscribing only nodes • load objects (i. e. make subscribed DCPS data, DLRL objects) • read their attributes and/or relations, • possibly use the relations to navigate among the objects, • be made aware on changes on the objects that are there, or on the arrival. ICDCS of 1 new objects. DDRTS Workshop, 2003 st Hans-Arno Jacobsen, University of Toronto
DLRL Entities • Cache and Cache. Access – A Cache represents a set of objects managed consistently. It comprises a Publisher and/or a Subscriber – It comprises one or more Cache. Access that isolate a set of objects in a given access mode (read/write) • Object. Home – An Object. Home is an object that manages all the instance of a given application class, inside a Cache – It is typed according to the application type it manages • Object. Root is the root for all the application classes ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
DLRL Entities at Run-Time 2/2 • A set of typed entities represent relations and collections • Selections are typed objects to gather a set of objects matching a given criterion • Listeners are interfaces that the application may implement to be notified of the arrival of incoming modifications: – Cache. Listener • begin/end of a set of modifications – Object. Listener • creation/update/deletion of an object ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto – Selection. Listener
Typical Publishing Node 1. Create a Cache and attach the Object. Homes; enable the infrastructure 2. Create a Cache. Access (if not using the default one) 3. Populate that Cache. Access (i. e. , create and/or attach objects) and/or modify the attached objects (native calls) 4. Write the Cache. Access (i. e. , write all the modifications on objects attached to it) ICDCS 1 DDRTS Workshop, 2003 5. Eventually, Hans-Arno purge the Cache. Access Jacobsen, University of Toronto st
Typical Subscribing Node 1. Create the Cache and attach the Object. Homes; enable the infrastructure 2. If needed, create Selections 3. Attach Listeners 4. Just wait. . . – – In the listener, access to the objects is made using native constructs If needed to take a consistent picture of a part of the graph, use a Cache. Access ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
How to get data (listener-based) Listener listener = new My. Listener(); Reader->set_listener(listener); My. Listener: : on_data_available( Data. Reader reader ) { Foo. Seq received_data; Sample. Info. Seq sample_info; reader->take( &received_data, &sample_info, READ | NOT_READ, NEW | MODIFIED | DISPOSED); // Use received_data } ICDCS 1 st DDRTS Workshop, 2003 Hans-Arno Jacobsen, University of Toronto
How to get data (wait-based) Condition foo_condition = reader->create_readcondition( READ | NOT_READ, NEW | MODIFIED | DISPOSED); waitset->add_condition(foo_condition); Condition. Seq active_conditions; waitset->wait(&active_conditions, timeout); … Foo. Seq received_data; Sample. Info. Seq sample_info; Reader->take_w_condition(&received_data, &sample_info, ICDCS 1 foo_condition); DDRTS Workshop, 2003 // Use received_data. Hans-Arno Jacobsen, University of Toronto st
- Slides: 57