DDS Tutorial -- Part II Hands On - OMG

DDS Tutorial -- Part IIHands OnGerardo Pardo-Castellote, Ph.D.The Real-TimeMiddleware ExpertsGerardo Pardo-Castellote, Ph.D.Co-chair OMG DDS SIGCTO, Real-Time Innovationsgerardo.pardo@rti.com

Agenda• Context: Middleware Technologies• Overview: DDS Model & Applicability• Details: DDS in depth© 2009 Real-Time Innovations, Inc.

Context: Middleware TechnologiesThe concept of network middleware:– Communications Model– Object Model– Architecture Model– Protocol© 2009 Real-Time Innovations, Inc.

With increased complexity…End User Application© 2009 Real-Time Innovations, Inc.

With increased complexity…End User ApplicationNetwork StackRouting protocolsFile SystemKernelOperating SystemDevice Drivers© 2009 Real-Time Innovations, Inc.

With increased complexity…End User ApplicationHTTP ServiceMail ServiceFTP ServiceData baseNetwork StackRouting protocolsFile SystemKernelOperating SystemDevice Drivers© 2009 Real-Time Innovations, Inc.

… middleware becomes necessaryEnd User ApplicationApplication ServerMessage ServiceData baseEvent ProcessingEngineMiddlewarePhysics EngineGraphics EngineHTTP ServiceMail ServiceFTP ServiceNetwork StackRouting protocolsFile SystemKernelDevice DriversOperating System & Pre-Packaged Services© 2009 Real-Time Innovations, Inc.

What is network middleware?Middleware =API and service layer above operating system and below“application” code that abstracts common interaction patternsNetwork Middleware =Most popular class of middlewareMiddleware used for developing distributed applicationsDistributed Applications =Those requiring interaction/communication between multiplecomputers© 2009 Real-Time Innovations, Inc.

Network Middleware Examples• DDS, RTI DDS, OpenSplice, tao-dds,• JMS, WebSphere MQ, ActiveMQ, SoniqMQ• DCE/RPC, DCOM, CORBA, ICE• TIBCO RV, 29West, GigaSpaces• Bundles & ESBs:– Application Servers (WebSphere, WebLogic, JBOSS) Include networkmiddleware as a component• NOTE: Middleware “packages” are building blocks, not stand-aloneapplications like…– Skype, gtalk, …– BitTorrent, eMule, …• Why aren’t ‘popular’ consumer applications built on top ofmiddleware?© 2009 Real-Time Innovations, Inc.

Historical note: From Telephone to Blogs• Why so many flavors?• Parallels evolution of general communication patterns:– Started with point-to-point connections– Then request-reply services– Then Message Queue Services– Then Publish-Subscribe Services– Then Data-Caching services• Other examples:– FTP, email -> WEB -> Blogs, RSS -> Podcasts© 2009 Real-Time Innovations, Inc.

Middleware Communication ModelsPoint-to-PointTelephone, TCPSimple, high-bandwidthLeads to stove-pipe systemsClient-ServerFile systems, Database, RPC, CORBA, DCOMGood if information is naturally centralizedSingle point failure, performance bottlenecksPublish/Subscribe MessagingMagazines, Newspaper, TVExcels at many-to-manycommunicationExcels at distributing time-criticalinformationReplicated DataLibraries, Distributed databasesExcels at data-mining and analysis© 2009 Real-Time Innovations, Inc.

RMI vs Pub-Sub/Messaging/Data-Distribution• RMI (WebServices, CORBA, DCOM) offer a remote methodabstraction– Familiar OO programming model– Results in a tightly-coupled system• Forces synchronous invocations• Imposes global object model• Limited QoS (appearance of local method call)• Lack robustness: cascading points of failure– Typically built on top of TCP:• impacts scalability and time-determinism– Best-suited to smaller, closely-coupled systemsTopic/Queue• Pub-Sub (Messaging Data-Distribution) offer a queue-basedand/or replicated-data model– Subsystems are decoupled in time, space, and synchronization• Contracts established by verifying QoS compatibility– Supports a variety of transports including multicast UDP– Better suited for high-performance and real-time© 2009 Real-Time Innovations, Inc.

Queue versus Pub-Sub• Queue– Message sent to Queue– Multiple readers can read from the queue– Each message is delivered to ONLY onereader• Readers “affect each other”– Apps:• Job Scheduling• Load Balancing• Collaboration1 2 3Queue132• Pub Sub– Message Sent to Topic– Multiple readers can subscribe to Topic withor without filters– Each message delivered to ALL subscribersthat pass filter• Readers are decoupled1 2 31 2 3Topic/Queue1 2 3– Apps:• Notifications• Information Distribution11 3© 2009 Real-Time Innovations, Inc.

Pub-Sub versus Data-Distribution• Pub-Sub– Only messages no concept of data– Each message is interpreted without context– Messages must be delivered FIFO or according tosome “priority” attribute– No Caching of data– Simple QoS: filters, durability, lifespan• Data-Distribution– Messages represent update to data-objects– Data-Objects identify by a key– Middleware maintains state of each object– Objects are cached. Applications can read atleisure– Smart QoS• Ownership• History (per key)• Deadline– Subsumes Pub-Sub1 2 31 2 3Topic/Queue11 31 2 2 31 2 31 2 3 1 2 3 1 2 3© 2009 Real-Time Innovations, Inc.

DDS Service Model:Communication ModelProvides a “Global Data Space” that is accessible to all interestedapplications.– Data objects addressed by Domain, Topic and Key– Subscriptions are decoupled from Publications– Contracts established by means of QoS– Automatic discovery and configurationParticipantPubPubParticipantSubTrack,1Track,2Track,3SubParticipantGlobal Data SpaceParticipantPubAlarmSubParticipant© 2009 Real-Time Innovations, Inc.

DDS Service Model: Object ModelTopicTopicDataWriterOfferedQoSDataReaderRequestedQoSPublisherDomainParticipantSubscriberDomainParticipant© 2009 Real-Time Innovations, Inc.Global Data Space• DomainParticipant – Allows application to join a DDS Domain (Global Data Space)• Topic – A string that addresses a group of objects in the Global Data Space– Each Object is identified by a Key (some fields within the object data)• Publisher, Subscriber – Pools resources for DataWriters and DataReaders• DataWriter – Declares intent to publish a Topic and provides type-safe operations to write/senddata• DataReader – Declares intent to subscribe to a Topic and provides type-safe operations toread/receive data

Other (non DDS)Commercial Pub-Sub Models• Older, but widely deployed– TIBCO (RendezVous, EMS)– IBM WebSphere MQ• Limited deployment:– CORBA Event Service– CORBA Notification Service• Emerging standards – not widely deployed– WS-Eventing– WS-Notification• Proprietary Systems– 29West– IBM LLM© 2009 Real-Time Innovations, Inc.

Agenda• Context: Middleware Technologies• Overview: DDS Model & Applicability• Details: DDS in depth© 2009 Real-Time Innovations, Inc.

History:DDS the Standard(s)• Data Distribution Service for Real-Time Systems– Joint submission (RTI, THALES, OIS)– DDS version 1.0 Adopted December 2004– DDS version 1.1 Adopted December 2005– DDS version 1.2 Adopted October 2006• Interoperability wire protocol– Joint submission (RTI and PrismTech)– DDS-RTPS version 1.2 adopted in July 2006– DDS-RTPS version 2.0 adopted in June 2007– DDS-RTPS version 2.1 approved in June 2008• Related Standards– Joint submission (Sparx, RTI, PrismTech)– UML Profile for DDS adopted June 2008– DDS for light weight CCM adopted 2008• Standards under Development– Extensible and Dynamic Topic Types for DDS– Native Language C++ API for DDS© 2009 Real-Time Innovations, Inc.

© 2009 Real-Time Innovations, Inc.

DDS mandated for data-distribution• DISR (formerly JTA)– DoD Information TechnologyStandards Registry• US Navy Open Architecture• FCS SOSCOE– Future Combat System –System of System CommonOperating Environment• SPAWAR NESI– Net-centric Enterprise Solutions forInteroperability– Mandates DDS for Pub-Sub SOA© 2009 Real-Time Innovations, Inc.

DDS Adoption –Aerospace & DefenseBoeingAWAKSBoeingFuture CombatSystemsE2C HawkeyeNorthtrop?Qinetiq?SAAB?RaytheonSSDSLockheedAEGISInsituUnmannedAir Vehicles© 2009 Real-Time Innovations, Inc.22

DDS Adoption –Transportation, IndustrialWiTronixTrain and vehicleTrackingSchneider ElectricIndustrial AutomationTokyo JapanTraffic ControlKukaRoboticsEU and USAir TrafficManagementVarianMedical Instruments© 2009 Real-Time Innovations, Inc.23

Many others© 2009 Real-Time Innovations, Inc.

Main differences of DDS vs other Pub-Sub• Flexibility and Power of the data-centric model• Performance & Scalability• Rich set of built-in services• Interoperability across platforms and Languages• Natural integration with SOA building-blocks© 2009 Real-Time Innovations, Inc.

#1 RTI Data-Centric Model“Global Data Space” generalizes Subject-Based Addressing– Data objects addressed by DomainId, Topic and Key– Domains provide a level of isolation– Topic groups homogeneous subjects (same data-type & meaning)– Key is a generalization of subject• Key can be any set of fields, not limited to a “x.y.z …” formatted stringData WriterData WriterKey (subject)TopicData ObjectData ReaderData ReaderData WriterData Reader© 2009 Real-Time Innovations, Inc.

Demo: ConceptsDisplay Area:Shows state of objectsStart demo• Topics– Square, Circle, Triangle– Attributes• Data types (schemas)– Shape (color, x, y, size)• Color is instance Key– Attributes• Shape & color used for key• QoS– Deadline, Liveliness– Reliability, Durability– History, Partition– OwnershipControl Area:Allows selection of objects and QoS© 2009 Real-Time Innovations, Inc.

DDS communications modelNewsubscriber!DataWriter“Alarm”DomainParticipantGot newdataDataReader“Alarm”DomainParticipantListenerOfferedQoSListenerRequestedQoS• Participants scope the global data space (domain)• Topics define the data-objects (collections of subjects)• Writers publish data on Topics• Readers subscribe to data on Topics• QoS Policies are used configure the system• Listeners are used to notify the application of events© 2009 Real-Time Innovations, Inc.

QoS: Quality of ServiceQoS PolicyDURABILITYHISTORY (per subject)READER DATA LIFECYCLEWRITER DATA LIFECYCLELIFESPANENTITY FACTORYRESOURCE LIMITSRELIABILITYTIME BASED FILTERDEADLINECONTENT FILTERSQoS PolicyUSER DATATOPIC DATAGROUP DATAPARTITIONPRESENTATIONDESTINATION ORDEROWNERSHIPOWNERSHIP STRENGTHLIVELINESSLATENCY BUDGETTRANSPORT PRIORITY© 2009 Real-Time Innovations, Inc.

Demo: Quality of Service (QoS)Writers and readers stateTheir needsStart demo• Topics– Square, Circle, Triangle– Attributes• Data types (schemas)– Shape (color, x, y, size)• Color is instance Key– Attributes• Shape & color used for key• QoS– Deadline, Liveliness– Reliability, Durability– History, Partition– OwnershipRTI DDS delivers© 2009 Real-Time Innovations, Inc.

#2 Performance & ScalabilityDDS was designed to support high performance• DDS uses high-performance data-access APIs– Read data by array (no additional copies)– Buffer loaning for zero copy access• DDS Supports advanced features such as:– Message prioritization (via latency budget QoS)– Network prioritization (via transport priority QoS)– Source filtering (via Content-based and Time-based filters)• DDS does not require the presence of intermediate brokers– Applications can communicate directly peer-to-peer• DDS Protocol supports UDP, multicast and reliable multicast– Multicast can be used for high-performance scalability– Use of UDP avoids head-of-line blocking– Best efforts can be used for repetitive time-critical data© 2009 Real-Time Innovations, Inc.

Data-Distribution and Real-TimeMessaging Technologies and StandardsWeb ServicesJava RTSJ (soft RT) RTSJ (hard RT)Java/RMI Java/JMSCORBART CORBAData Distribution Service / DDSNon-real-time Soft real-time Hard real-time Extreme real-timeMPI© 2009 Adapted Real-Time from Innovations, NSWC-DD Inc. OA Documentation

Latency – (Linear Scale)DDS/JMS/Notification Service Comparison - Latency250020001500DDS JMS Notification Service100050004 8 16 32 64 128 256 512 1024 2048 4096 8192 16384Message Size (bytes)Message Length (samples)© 2009 Real-Time Innovations, Inc.Adapted from Vanderbilt presentation at July 2006 OMG Workshop on RT Systems

Jitter – (Linear Scale)DDS/CORBA Notification Service Comparison - Jitter100DDS/JMS/CORBA Notification Service Comparison - JitterStandard Deviation (usecs)2000180016001400120010008006004002000Standard Deviation (usecs)8060DDS JMS Notification serviceDDS JMS Notification service402004 8 16 32 64 128 256 512 1024 2048 4096 8192 16384Message Length Message (samples) Size (bytes)4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384Message Message Length Size (samples) (bytes)© 2009 Real-Time Innovations, Inc.Source: Vanderbilt presentation at July 2006 OMG Workshop on RT Systems

DDS compared to JMS( 2KB messages )Throughput with a single publisher[1000's sample/s]454035302520151050DDSJMS2 4 6 9 11 18CPU load [%]Platform: Linux 2.6 on AMD Athlon, Dual core, 2.2 GHz© 2009 Real-Time Innovations, Inc.

Study on impact of WS technologies for future European ATC: XML isnot suitable for European Flight Data Distribution• Data size explodes 10X vs. CDR– Flight Plans go from 100KB to 1MB• Communication speed drops 20XNot good for Real-Time!!Source: Christian Esposito and Domenico Cotroneo, Dario Di Crescenzo.SELEX-SI/Consorzio SESM/University of Naples.“Flexible Communication Among DDS Publishers and Subscribers”July 2008, Real-Time Systems Workshop, Washington, DC© 2009 Real-Time Innovations, Inc.

Message bus architecturesJMSEnterpriseMessagingCentralizedClusteredEnterpriseMessagingFederatedDDSPeer to Peer© 2009 Real-Time Innovations, Inc.

#3 Powerful ServicesIncluded in the Standard:– Discovery– Ownership, Redundancy & Failover– Persistence (Durable) Data– Last value and historical cachesEnabled by the DDS protocol:– Recording service– Routing Service© 2009 Real-Time Innovations, Inc.

Discovery Service• DDS provides the means for an application to discoverother participants on the Domain– And the Topics the Publish and Subscribe– And the Quality of Service of the remote endpoints• A participant can determine who it is communicatingwith…– And selectively decide who to communicate with…shapes_demodiscovery_in_excel© 2009 Real-Time Innovations, Inc.

Ownership and High AvailabilityProducer / Writerstrength=10Producer / Writerstrength=5Producer / Writerstrength=1I1 PrimaryI1 BackupI2 BackupI2 PrimaryTopic T1I1I2• Owner determined per subject• Only extant writer with highest strength can publish a subject (or topic fornon-keyed topics)• Automatic failover when highest strength writer:– Loses liveliness– Misses a deadline– Stops writing the subjectStart demo• Shared Ownership allows any writer to update the subject© 2009 Real-Time Innovations, Inc.

Data PersistenceA standalone service that persists data outside of thecontext of a DataWriterCan be configured for:• Redundancy• Load balancingDataReaderDataWriterDataWriterGlobalData SpaceDataReaderDemo:1. PersistenceService2. ShapesDemo3. Application failure4. Application (ShapesDemo) re-startPersistenceServicePermanentStoragePersistenceServicePermanentStorage© 2009 Real-Time Innovations, Inc.

Persistent Data Service• Modes:– High-performance “direct” model. Data flows in directly to subscribers and to thepersistent service– Transactional “relay” mode persists first, then sends to subscribers• Fault-tolerant: Redundant services are supportedDirectModeDataWriterRelayModeDataWriterRedundantServiceDataWriterPersistenceServicePersistenceServicePersistenceServicePersistenceServiceDataReaderDataReaderDataReaderDataReaderDataReaderDataReader© 2009 Real-Time Innovations, Inc.

Durable Writers• Durable Writers keep their history cachein permanent storage• Upon re-starts they automatically rebuildtheir history from storage• New messages will automatically beappended to the history• Readers will treat the writer re-start as a“temporary” disconnect• Automatically-assigned sequencenumbers ensure no messages aredropped or duplicatedApplicationwritePermanentStorageTo ReadersMsg(GUID, SN)© 2009 Real-Time Innovations, Inc.

Durable Readers• Durable Readers Keep information onthe messages read on permanentstorage• Information uniquely identifies eachmessage• Upon re-start they automatically loadinformation so they only request newmessages and avoid duplicates• Combined with the other services itcan guarantee exactly-once deliveryFrom WritersMsg(GUID, SN)readApplicationPermanentStorage© 2009 Real-Time Innovations, Inc.

Last value cache• A last-value cache is already built-in into every Writer inthe system– Can used in combination with a Durable Writer• A late joiner will automatically initialize to the last value• Last value cache can be configure with history depthgreater than 1• The Persistence Service can be used to provide a lastvalue cache for durable data© 2009 Real-Time Innovations, Inc.

Historical cacheStart demo• A partial historical cache is already built-in into every Writer in thesystem– Can used in combination with a Durable Writer• The Persistence Service can be used to provide a historical cachewith larger/unlimited depth• A late joiner will automatically initialize to the desired history– Currently amount of history can only be specified as message count.– Next release will also allow a age/time based specification.• Request for historical cache is done by creating a Reader with thedesired history depth specified as a QoS© 2009 Real-Time Innovations, Inc.

DDS Real-Time Recording Service• Applications:– Future analysis anddebugging– Post-mortem– Compliance checking– Replay for testing andsimulation purposes• Record high-rate data arrivingin real-time• Non-intrusive – multicastreceptionDemo:1. Start RecorderService2. Start ShapesDemo3. See output files4. Convert to: HTML XML CSV5. View Data: HTML XML CSV© 2009 Real-Time Innovations, Inc.

#4 Interoperability• Protocol– Interoperability Wire protocol adopted in 2006• Languages: C/C++, Java, ADA, .NET• Systems/Platforms/Models– Data distribution (publishers and subscribers): DDS– Data management (storage, retrieval, queries): SQL– ESB Integration, Business process integration: WSDLDistributedNodeSQLSQLDistributedNodeDBMSDDSD TGlobal Data SpaceSQLDistributedNodeDistributedNodeWSDLDBMSDBMSDDSDistributedNode© 2009 Real-Time Innovations, Inc.

#5 Natural with SOA building blocksReal-TimeDevicesFaultToleranceAuditing &RecordingWS-DDSReal-Time Pub-Sub/Caching/MessagingSOA &Real-TimeWeb ServicesDatabaseEventProcessingTools &Visualization© 2009 Real-Time Innovations, Inc.

Relational Database IntegrationMessaging ActionsWrite()Read() & Take()Dispose()Wait() & ListenerRelational ActionsUPDATE & INSERTSELECTDELETETopic T1I1 I2 I3Table T1I1I2I3Event driven – The fastest way to observe databasechanges!© 2009 Real-Time Innovations, Inc.

Complex Event Engine Integration• CEP: programmable engines used to transform “data” into “information”• CEP engines are programmed using a derivative of SQL• CEP engines save time: They can implement a lot of the application logic:– Classification, Correlation, Aggregation, Filter, Cleansing, Pattern Detection, etc.• DDS is the perfect ‘data’ and ‘information’ pipe for CEP engines– Use high-speed data streams (1,000-1,000,000 msg/sec)– Require latency measured in sub-milliseconds– Demand access to events from a heterogeneous systemsDashboardsDDSApplicationsAlertsCEP Engine© 2009 Real-Time Innovations, Inc.

Web-Enabled DDS (upcoming spec)WebEnabledProtocolsHi-PerformanceEmbeddedReal-TimeHTTPGenericWeb Client(.NET / Java)SOAPWebEnabledDDSGlobalData SpaceRTI, DDS, Real-TimeDDS-RTPSDDSParticipantIONAWeb ClientIONA Artix TransportsSOAP, JMS, IIOPDDSParticipant© 2009 Real-Time Innovations, Inc.

Agenda• Context: Middleware Technologies• Overview: DDS Model & Applicability• Details: DDS in depth© 2009 Real-Time Innovations, Inc.

Do-yourself Message-Centric System• Model– 1-1, FIFO• Applications coupled in Lifespan & Content– Both must be present simultaneously– Everything sent is received• Excellent performance• Doesn’t scale– To large-scale systems– To loosely-coupled systemsApplicationApplicationQueue co-located with each application© 2009 Real-Time Innovations, Inc.

Middleware-based Message-Centric Systems (JMS)• Model– Broker-based, nn communication– Independent messages, No state• Coupling– Not coupled in Lifespan– Coupled in Order and Content (presentation)• Worse performance• Better scalabilityApplicationApplicationApplicationGlobal QueuesQueue per message kindApplication© 2009 Real-Time Innovations, Inc.

Do-yourself Data-Centric System• Model– Shared/replicated structured data/state– Asynchronous, Selective sharing• Coupling:– Coupled in Lifespan, Decoupled in Presentation & Content• Excellent performance & scalabilityApplicationReplicationMechanismApplication© 2009 Real-Time Innovations, Inc.

Middleware-based Data-Centric Systems (DDS)• Shared data-space, shared state• Asynchronous communication• Decoupled in Lifespan, Content, presentation• Excellent performance & scalability• Subsumes Message-Centric via QoSApplicationApplication© 2009 Real-Time Innovations, Inc.

DDS Data-Centric ModelProvides a virtual “Global Data Space” that is accessible to allinterested applications.– Data objects addressed by DomainId, Topic and Key– Subscriptions are decoupled from Publications– Contracts established by means of QoS– Automatic discovery and configurationData WriterData WriterKey TopicData ObjectData ReaderData ReaderData WriterData Reader© 2009 Real-Time Innovations, Inc.

DDS Global Data• Address in Global Data Space = (DomainId, Topic, Key)– Each topic corresponds to a multiple data instances with a common schema– A DataWriter can write to any instances of a single topic– Multiple DataWriters may write to the same instance– A DataReader receives updates from all instances of a single topic– Multiple DataReaders may read from the same instances & valuesData WriterData ReaderData WriterData ReaderData WriterData Reader© 2009 Real-Time Innovations, Inc.

DDS Global Data: Domains• Address in Global Data Space = (DomainId, Topic, Key)– Each Domain is identified by the value of the domainId– Each Domain is a separate Global Data Space• The same Topic name can mean different things in different domains• The same Topic can have different Types on each Domain– An application may join multiple Domains– Domains can be used for isolation, scalability, modularity© 2009 Real-Time Innovations, Inc.

Example: Publication// Entities creationDomainParticipant participant =TheParticipantFactory->create_participant(domain_id, participant_qos, participant_listener);Publisher publisher = domain->create_publisher(publisher_qos, publisher_listener);Topic topic = domain->create_topic(“MyTopic”, “Text”, topic_qos, topic_listener);DataWriter writer = publisher->create_datawriter(topic, writer_qos, writer_listener);TextDataWriter twriter = TextDataWriter::narrow(writer);TextStruct my_text;twriter->write(&my_track);© 2009 Real-Time Innovations, Inc.

Example: Subscription// Entities creationSubscriber subscriber = domain->create_subscriber(subscriber_qos, subscriber_listener);Topic topic = domain->create_topic(“Track”, “TrackStruct”,topic_qos, topic_listener);DataReader reader = subscriber->create_datareader(topic, reader_qos, reader_listener);// Use listener-based or wait-based access© 2009 Real-Time Innovations, Inc.

How to Get Data? (Listener-Based)// Listener creation and attachmentListener listener = new MyListener();reader->set_listener(listener);// Listener codeMyListener::on_data_available( DataReader reader ){TextSeq received_data;SampleInfoSeq sample_info;TextDataReader reader = TextDataReader::narrow(reader);}treader->take( &received_data, &sample_info, …)// Use received_dataprintf(“Got: %s\n”, received_data[0]->contents);© 2009 Real-Time Innovations, Inc.

How to Get Data? (WaitSet-Based)// Creation of condition and attachementCondition foo_condition =treader->create_readcondition(…);waitset->add_condition(foo_condition);// WaitConditionSeq active_conditions;waitset->wait(&active_conditions, timeout);// Wait returns when there is data (or timeout)FooSeq received_data;SampleInfoSeq sample_info;treader->take_w_condition(&received_data,&sample_info,foo_condition);// Use received_dataprintf(“Got: %s\n”, received_data[0]->contents);© 2009 Real-Time Innovations, Inc.

Listeners, Conditions & WaitSetsMiddleware must notify user application of relevant events:– Arrival of data– But also:• QoS violations• Discovery of relevant entities– These events may be detected asynchronously by the middleware… Same issue arises with POSIX signalsDDS allows the application to choice:– Either to get notified asynchronously using a Listener– Or to wait synchronously using a WaitSetBoth approaches are unified using STATUS changes© 2009 Real-Time Innovations, Inc.

Status ChangesDDS defines• A set of enumerated STATUS• The statuses relevant to each kind of DDS EntityDDS entities maintain a value for each STATUSSTATUSEntity© 2009 Real-Time Innovations, Inc.INCONSISTENT_TOPICDATA_ON_READERSLIVELINESS_CHANGEDREQUESTED_DEADLINE_MISSEDRUQESTED_INCOMPATIBLE_QOSDATA_AVAILABLESAMPLE_LOSTSUBSCRIPTION_MATCHLIVELINESS_LOSTOFFERED_INCOMPATIBLE_QOSPUBLICATION_MATCHTopicSubscriberDataReaderDataReaderDataReaderDataReaderDataReaderDataReaderDataWriterDataWriterDataWriterstruct LivelinessChangedStatus{long active_count;long inactive_count;long active_count_change;long inactive_count_change;}

Listeners, Conditions and Statuses• A DDS Entity is associated with:– A listener of the proper kind (if attached)– A StatusCondition (if activated)• The Listener for an Entity has a separate operation for each of the relevantstatusesSTATUSINCONSISTENT_TOPICDATA_ON_READERSLIVELINESS_CHANGEDREQUESTED_DEADLINE_MISSEDRUQESTED_INCOMPATIBLE_QOSDATA_AVAILABLESAMPLE_LOSTSUBSCRIPTION_MATCHLIVELINESS_LOSTOFFERED_INCOMPATIBLE_QOSPUBLICATION_MATCHEntityTopicSubscriberDataReaderDataReaderDataReaderDataReaderDataReaderDataReaderDataWriterDataWriterDataWriterListener operationon_inconsistent_topicon_data_on_readerson_liveliness_changedon_requested_deadline_missedon_requested_incompatible_qoson_data_availableon_sample_loston_subscription_matchon_liveliness_loston_offered_incompatible_qoson_publication_match© 2009 Real-Time Innovations, Inc.

Listeners & Condition duality• A StatusCondition can be selectively activated to respond toany subset of the statuses• An application can wait changes in sets of StatusConditionsusing a WaitSet• Each time the value of a STATUS changes DDS– Calls the corresponding Listener operation– Wakes up any threads waiting on a related status changeStatus ChangeDDSEntityAsynchronous notificationvia Listener operationSynchronous notificationvia activation/wakeup ofconditions/waitsets© 2009 Real-Time Innovations, Inc.

Hands-on Example (C++)MyType.slnMyType.hMyTypeSupport.crtiddsgencompilerTypeDefinitionMyTypeMyTypePublisher.cppMyTypeSubscriber.cppFour easy steps:1. Define your data2. Create your project3. Build4. Run: publisher subscriberAux:File BrowserConsolePublisher.exeSubscriber.exe© 2009 Real-Time Innovations, Inc.

Components/Mechanics of the GDSApplicationApplicationGDS DefinitionDiscoveryApplicationApplicationListenerProtocolListener© 2009 Real-Time Innovations, Inc.CacheManagementCacheManagement

Components/Mechanics of the GDSApplicationApplicationDomain Modeling& Sys. DesignGDS DefinitionDiscoveryApplicationConfig &QosApplicationListenerProtocolListener© 2009 Real-Time Innovations, Inc.CacheManagementCacheManagement

Designing a Data-Centric System• Define/Model the Global Data Space• Configure the Cache Management• Configure Discovery• Configure the Protocol• Configure/Use hooks for– Fault detection– Controlled access© 2009 Real-Time Innovations, Inc.

Global Data Space / Global State• Identify the number of domains• Domain Information model– Topics– Types– Keys– Ownership© 2009 Real-Time Innovations, Inc.

Domain and Domain ParticipantsN1 App 1Pub/Sub(A,B/C,D)N4 App 4Pub/Sub(D/C,E,F)• Container forapplications thatwant to communicateN2 App 2Subscribe(C)DomainN4 App 5Publish(C)• Applications canjoin or leave adomain in any order• New Applicationsare “Auto-Discovered”N3 App 3Pub/Sub(E,F/A,C)N5 App 6Subscribe(B,C)• An application thathas joined a domainis also called a“Domain Participant”Single ‘Domain’ System© 2009 Real-Time Innovations, Inc.

Domain and Domain ParticipantsUsing Multiple domains for Scalability, Modularity & IsolationNode 1 - App 1Pub/SubDomain ANode 4 - App 1Pub/SubNode 2 - App 1SubscribeNode 3 - App 1Pub/SubDomain BNode 4 - App 2PublishNode 5 - App 1SubscribeNode 5 - App 2Pub/SubDomain CAdded Func.Node 6 - App 1Pub/Subdemo_domain_0© 2009 Real-Time Innovations, Inc.Multiple Domain Systemdemo_domain_1

Topics & Datatypes, Keys & SubjectsTopic “MarketData”Data-type (name-type-value pairs)sourcetypesymbolExchangevolumebidaskOPRAIBMNYSE200000118.30118.36OPRAAAPLNASDAQ171.20171.28RTFPEQKey fields SubjectAdditional fields (payload)Topic “OrderEntry”ExchangetypeSymbolOrder numnumberlimitstopexpirationNYSEBUYIBM11956500120-DAYNYSEBUYIBM119571000124.5124DAYNASDAQSELLAAPL11958400-160DAY© 2009 Real-Time Innovations, Inc.Subject Key fields demo_filters

QoS: OwnershipSpecifies whether more than one DataWriter canupdate the same instance of a data-objectOwnership = EXCLUSIVE“Only highest-strengthdata writer can updateeach data-instance”DataWriterDataWriterDataWriterDataWriterDataWriterDataWriter© 2009 Real-Time Innovations, Inc.Ownership = SHARED“All data-writers caneach update datainstance”Data-InstanceData-InstanceProvides fast, robust, transparent replacement for failoverand/or take-over.

demo_ownershipQoS: Ownership StrengthSpecifies which DataWriter is allowed to update thevalues of data-objectsORDEROWNERSHIP_STRENGTH“Integer to specify thestrength of an instance”Strength = 1DataWriter“LEFT”Strength = 4After Data QoS ExpiresWriter- Deadline“RIGHT”- LivelinessDataReader“RIGHT”“LEFT”DomainParticipantPublisherPublisherSubscriberSS© 2009 Real-Time Innovations, Inc.Note: Only applies to Topics with Ownership = Exclusive

Configure the Cache Management• Cache State Content– History– Lifespan– Persistence– ResourcesWriterApplication• Reader Cache View– Partitions– Content-Based Filter– Time-Based Filter– OrderReaderApplication© 2009 Real-Time Innovations, Inc.

QoS: History – Last x or AllKEEP_ALL:Publisher: keep all until deliveredSubscriber: keep each sample until theapplication processes that instanceKEEP_LAST: “depth” integer forthe number of samples to keep atany one timedemo_historyDataWriterPublisherS7S6S5S4S3S2DataWriterPublisherS7S6DataReaderSubscriberS7S6S5S4S1Keep AllKeep Last 2Keep Last 4S7 S6 S5 S4 S3 S2 S1© 2009 Real-Time Innovations, Inc.

lifespan_pubQoS: Lifespanlifespan_subTopicUser can set lifespan durationManages samples inthe history queues, attached to eachSampleDataWriterPublisherDataReaderSubscriberS1S2S3S4S5S6Perm.StorageS7S1S2S4 S3 S2 S1© 2009 Real-Time Innovations, Inc.

Content-Based FilteringInstance 1Instance 2Instance 3Instance 4Instance 5Instance 6Instance 7Value = 249Value = 230Value = 275Value = 262Value = 258Value = 261Value = 259Content FilteredTopic“Filter Expression ”Ex. Value > 260Topiccontent_filter_exampleThe Filter Expression and ExpressionParams will determine which instances of theTopic will be received by the subscriber.© 2009 Real-Time Innovations, Inc.

Subscriptions: By Topic, Subject, ContentTopic: “Market Data”Field Source Symbol Type ExchangePayloadVolume Bid Ask …Value* * * * *Topic: “Order Entry”FieldSymbol Type ExchangeOrderNumberPayloadSymbol OrderKind Stop Limit…Value* * NYSE *Subject Filter (for a Reader)content_filter_exampleTopic: “Market Data”FieldSourceSymbol Type Exchange PayloadValueREUTERS * EQ NYSE Volume > x, Ask < ySubject Filter (for a Reader)Payload Filter (for a Reader)© 2009 Real-Time Innovations, Inc.

QoS: TIME_BASED_FILTERDomainParticipantTopictime_filter_example“minimum_separation”:Data Reader does not want to receive datafaster than the min_separation timeDataWriterDataReaderPublisherDiscardedsamplesSubscriberS S S S S S Sminimum separationData Samples© 2009 Real-Time Innovations, Inc.

Cache Management in Action• Topics– Square, Circle, Triangle– Attributes• Data types (schemas)– Shape (color, x, y, size)• Color is instance Key– Key• Color field used for key• QoS– History, Partition– Time-Based Filter– Content-Based Filter© 2009 Real-Time Innovations, Inc.demo

Configure the Protocol• Discovery• Reliability• Liveliness• Flow Control• Asynchronous write• Network Configuration– Enabled Transports +transport properties– Multicast addresses– Transport Priority• OS settings– Threads– MemoryWriterApplicationReaderApplication© 2009 Real-Time Innovations, Inc.

Tunable Reliability Protocol• Configurable AckNack reply timesto eliminate storms• Fully configurable to boundlatency and overhead– Heartbeats, delays, buffer sizes• Performance can be tracked bysenders and recipients– Configurable high/low watermark,Buffer full• Flexible handling of slowrecipients– Dynamically remove slowreceiversDataWriterPublisherS7S6S5S4S3S2S1Reliable•GuaranteedOrdered Delivery•“Best effort” alsosupportedDataReaderSubscriberS1S2S3S4S5S6S7S8 S7 S3 S5 S4 S2 S1S6NACK #6© 2009 Real-Time Innovations, Inc.

Best Efforts010203040506070801020304050607080102X0405060708© 2009 Real-Time Innovations, Inc.Company Confidential

Confirmed Reliability INo packet loss0102030405060708ACK 1-4ACK 1-801020304, HB05060708, HB0102030405060708© 2009 Real-Time Innovations, Inc.Company Confidential

Confirmed Reliability IISome packet loss0102030405060708ACK 1-2, NACK 3ACK 1-801020304, HB0503060708, HB0102X0405060708© 2009 Real-Time Innovations, Inc.Company Confidential

Configure Notifications, Fault Detection &Management• Listeners• Deadline Qos• Liveliness Qos• Built-in Readers• Notification of matchingWriterApplicationReaderApplication© 2009 Real-Time Innovations, Inc.

QoS: Deadlinedeadline_exampleTopicDEADLINE “deadline period”DataWriterCommitsto providedata eachdeadlineperiod.Failed toget dataListenerDataReaderPublisherExpects data everydeadline period.SubscriberdeadlineS X S S S S S© 2009 Real-Time Innovations, Inc.

QoS: Liveliness –Type and Durationliveliness_exampleType: Controls who is responsible for issues of ‘liveliness packets’AUTOMATIC = Infrastructure ManagedMANUAL = Application Managedkill_appsTopicTopicDataWriterFailed torenewleaseListenerDataReaderPublisherSubscriberlease_duration© 2009 Real-Time Innovations, Inc.LP LP LP SLiveliness Message

Summary• Designing a fault-tolerant high-performance distributedsystem is not a simple task• A powerful middleware framework can provide a lot ofvalue and help you focus on the business logic• The middleware can save you a lot of time and effort.– It is worth learning how to use its power!© 2009 Real-Time Innovations, Inc.