200 likes | 342 Vues
Update on 11073 DIM for Publish/Subscribe. Jeff Plourde , Wayne Saari , Anne Fiore, Diana Esteves May 6, 2013. Agenda. Beyond IDL The nexus of data representation, device models, and publish/subscribe strategy Updates to previous “IDL” discussion X-Types Overview
E N D
Update on 11073 DIM for Publish/Subscribe Jeff Plourde, Wayne Saari, Anne Fiore, Diana Esteves May 6, 2013
Agenda • Beyond IDL • The nexus of data representation, device models, and publish/subscribe strategy • Updates to previous “IDL” discussion • X-Types Overview • Attribute Severability • New Material to discuss • Overall object model mapping to publish/subscribe • Scanner Objects • Guiding Principles
X-Types • “Extensible and Dynamic Topic Types for DDS” • http://www.omg.org/spec/DDS-XTypes/1.0/ • Elaborates on existing standards in four areas • Type System • Type Representations • Data Representation • Language Binding • Partially implemented in RTI Connext 5.0 • Full implementation in next release
X-Types : Type System • Previously implicitly inherited from IDL • X-Types defines a Type System in UML • Encompasses most IDL data types • Adds DDS-specific concepts like key fields • Supports single inheritance • Enables type versioning and evolution • Enables sparse types • Question: How does this impact work in AADL, etc?
X-Types : Type Representation • Previously types represented only in IDL • X-Types Representations • IDL - For CORBA compatibility and existing IDL • XSD - Allows reuse of extant XML Schema Docs • XML - A custom XML schema for representing types • TypeObject- A compact, binary representation for sharing type information on the wire • Questions: Should we consider XML Schema documents? Are they more useful to a wider audience than IDL? Can we build off existing NIST schemas?
X-Types : Data Representation • CDR (Common Data Representation) • Unchanged • Parameterized CDR • Supports type evolution • Previously used only for built-in topics • XML • Previously unsupported • Human-readable representation • Will this be an option on the wire or used mainly for debugging?
X-Types : Language Binding • Plain • Inherits from IDL language mappings • X-Types elaborates on mappings for the new Type System • Dynamic • New in X-Types • Supports dynamic type definition and introspection without compile-time knowledge
X-Types : Summary • Far more flexibility - A standalone type system instead of delegating to CORBA IDL. • Single inheritance / polymorphism • better mapping to 11073 concept of specializations (like Attributes) that should be handled opaquely by an unaware client • Optionality • Still need to decide how to use it. Does a null field specify no update (previously called “granular updates”) or does it specify absence of that value.
Attribute Severability • 11073-10201 section 7 does not directly describe which attributes must be updated simultaneously. • 7.7 Describes the Extended Services package • From the available scanners it becomes clear that attributes from the same “context group” must always be updated together.
Attribute Severability • 7.7.7 Context Scanner object “The scanner provides the object instance containment hierarchy and static object attribute values.” • ALL static attributes are communicated at object create time
Attribute Severability • 7.7.3 Episodic Scanner object • 7.7.3.3 Note 1: “If the EpiCfgScanner scans attribute groups of an object and one or more of the attribute values in the group change, then the scanner reports all values of attributes in the group, even those that did not change their value. This is important so that attributes that are dynamically deleted from an object instance can be detected without a special notification.” • ALL the attributes of an attribute group are always communicated together
Attribute Severability • All attributes of an attribute group are communicated together. • This requires some denormalization structNumericDynamicAttributes { AttributeTypeOne dynamicAttribute1; AttributeTypeTwo dynamicAttribute2; AttributeTypeThree dynamicAttribute3; }
Object Model Publish/Subscribe • Scanner Objects • “A Scanner object is an observer and ‘summarizer’ of object attribute values. It observes attributes of managed medical objects and generates summaries in the form of notification event reports.” 11073-10201-2004 7.7.1 • Without scanners objects themselves only support GET/SET with respect to Attributes … they do not expose Behaviors and Notifications to request attribute updates and respond. • Functionality of a pub/sub scheme should be at least as functional in communicating attributes.
Object Model Publish/Subscribe • Scanner Objects • Scanner objects are explicitly created by an agent at the request of a manager. • 1:1 relationship Scanner:Manager … a point-to-point protocol Manager #1 Create Scanner #1 Agent #1 Confirm Create Scanner #1 Scanner #1 Event Report Event Report
Object Model Publish/Subscribe Publish / Subscribe is not point-to-point Topic Manager #n Agent #n
Object Model Publish/Subscribe Context Scanner (7.7.7) “The Context Scanner object is responsible for observing device configuration changes. After instantiation, the Context Scanner object is responsible for announcing the object instances in the device’s MDIB. The scanner provides the object instance containment hierarchy and static object attribute values. In case of dynamic configuration changes, the Context Scanner object sends notifications about new object instances or deleted object instances.” Static Context Scanner Event Report Metrics Channels • Implies a pub/sub topic • A proto-device model Virtual Medical Device
Object Model Publish/Subscribe Episodic Scanner (7.7.3) “The EpiCfgScanner object is responsible for scanning attributes or attribute groups of objects and for reporting these attributes in episodic, unbuffered (i.e., on change only) event reports.” Dynamic Observed Episodic Scanner Event Report Metrics Channels • Implies pub/sub topics • One topic per unique attribute group / object class Virtual Medical Device
Principles in mapping 11073 • Highest possible fidelity • Deviations • Where a gap or ambiguity is identified in 11073-10201 itself. That ambiguity should be documented separately and referenced along with our disambiguation/interpretation. • Where the DIM is not amenable to a “reasonable” publish/subscribe architecture. Requires “look ahead” to intended publish/subscribe usage.
Principles in mapping 11073 • Least Surprise • Data types should work in the most common way • Inherent Tension … who do we prefer to surprise? • A person familiar with 11073 implementation? • (with no reference implementation this is a small group) • A person familiar with publish/subscribe? • Example: Binary Coded Decimal • Someone is going to be surprised!
Principles in mapping 11073 • Ease of programming… examples • amenable to content filtering capability • reasonable ability to apply QoS • reasonable number of subscriber/datareader structures to maintain • minimal “extra” state information to maintain • i.e. complex hierarchies the client must build from a series of smaller updates the client received