DDS is built around the abstraction of a, fully distributed, strongly typed global data space where applications can autonomously and asynchronously read and write data. With strong typing come some good properties such as improved efficiency, safety and system maintenance. At the same time, strong typing is sometimes wrongly perceived as limiting the extensibility of a system. This presentation introduces the new DDS type system recently specified as part of the newly adopted “Dynamic and Extensible Topic Types” and explain how newly added features allows the design to extensible and evolvable DDS systems that are without compromising performance, safety and improving maintenance.

1. Angelo CORSARO, Ph.D.
Chief Technology Officer
OMG DDS Sig Co-Chair
PrismTech
angelo.corsaro@prismtech.com!

2. DDS Overview

3. Data Distribution in a Nutshell
struct TempSensor {!
enum TScale {!
@Key long Id; !
C, F, K!
Data distribution is about making float temp;!
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ };!
TScale scale;!
application defined data available }!
where needed and when needed,
while preserving and end-to-end DR
type contract DW
Id Temp Scale
¨ Data is a first class concept, it can be
Created, Read, Updated, and
101 25 C DR
eventually Disposed (CRUD) DW 202 78 F
303 299 K
¨ The last value (or last N-values) of a
Data is always available to
DR
applications DW
Fully Distributed
DW: DataWriter
DR: DataReader
Global Data Space

4. DDS Topics
[1/2]
“com.myco.TTempSensor”
A Topic defines the subject of
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
Name
publications and subscriptions
¨ A Topic has associated a user
defined type and QoS
¨ The Topic name, type and Topic
QoS have a well defined role
in matching subscriptions
Type QoS
¨ Topics can be discovered or
locally defined struct TempSensor {! DURABILITY,
@Key long Id; ! DEADLINE,
float temp;!
PRIORITY,
TScale scale;!
}! …

5. DDS Topics
[2/2]
“com.myco.TTempSensor”
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
Name
¨ DDS Topic types can have
associated keys
¨ Each unique key-value Topic
identify a Topic Instance –
a specific stream of values Type QoS
struct TempSensor {! DURABILITY,
@Key long Id; ! DEADLINE,
float temp;!
PRIORITY,
TScale scale;!
}! …

6. DDS Type System

7. DDS Type System
The DDS Type System is defined by means of:
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Abstract Type System
¨ The definition of types supported by DDS
¨ Concrete Syntax(es) to express types
¨ Syntax for specifying DDS Topic Types
¨ Serialization Format
¨ Format for representing topics types as a byte-stream

8. Limitations in DDS v1.2

9. DDS v1.2 Type System
¨ Abstract Type System
Monomorphic Nominal Type System
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
¨ Not explicitly defined by the specification
¨ Concrete Syntax(es) to express types
¨ IDL Subset (e.g. struct, enum, union, primitive types)
¨ Serialization Format
¨ CDR (Common Data Representation)

10. [Abstract Type System]
Limitations
The monomorphic nominal type system makes it
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
hard to, transparently extend, information models
¨ For a given topic, DataWriters and DataReaders need to
use exactly the same type definition thus limiting
independent evolutions of the reading/writing side
¨ The type system is not formally defined

11. Example
[1/2]
Suppose that a new Temperature Old Sensor
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
Sensor was available that produced struct TempSensor {!
humidity estimates along with @Key long Id; !
float temp;!
temperature }!
TScale scale;!
¨ In DDS v1.2 it would be impossible to
deploy new sensors along with old
New Sensor
sensors while using the same topic
struct TempSensor {!
¨ So what could we do to @Key long Id; !
float temp;!
incrementally update the system? TScale scale;!
float hum;!
!
}!

12. Inconsistent Topic Types
¨ The scenario below would lead, in DDS v1.2, to an Inconsistent Topic Type error
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
TTempSensor TTempSensor
struct TempSensor {!
struct TempSensor {!
@Key long Id; !
@Key long Id; !
float temp;!
float temp;!
TScale scale;!
TScale scale;!
}!
float hum;!
}!
DW TTempSensor DR

13. Example
[2/2]
¨ The solution to the problem is to introduce Old Sensor
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
and Extension Topic/Type struct TempSensor {!
@Key long Id; !
¨ This extension topic/type shares the same float temp;!
key as the original topic and contains the }!
TScale scale;!
new attributes
¨ This gets the job done. Yet it adds Sensor Extension
complexity to the applications that will
struct TempSensorExt {!
want to take advantage of the @Key long Id; !
float hum;!
capabilities provided by new sensors. }!
These applications, will now have to deal
with two topics, or rely on Multi-Topics

14. Topic Extension
¨ The Legacy DR continues to use the old topic, while new DR are made
aware of the extension topic
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
Legacy DR
TTempSensor TTempSensor
DR struct TempSensor {!
struct TempSensor {!
@Key long Id; !
@Key long Id; !
float temp;!
float temp;!
TScale scale;!
TScale scale;!
}!
}!
TTempSensor
DW
DR
TTempSensorEx TTempSensorEx
struct TempSensorEx {!
@Key long Id; ! TTempSensorEx struct TempSensorEx {!
@Key long Id; !
float temp;! float temp;!
}! }!

15. [Concrete Syntax]
Limitations
¨ DDS v1.2 specifies IDL as the only concrete syntax
for specifying Topic Types
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ In addition, no standard/portable way of
specifying keys is defined
¨ Not everyone is happy with using IDL. Some users
would like to use UML to define topic types, other,
XML, etc.

16. [Serialization Format]
Limitations
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ CDR is a very efficient binary serialization format, its only
limitation is the lack of support for extensible types
¨ This stems from the fact that CDR pre-supposes the exact
knowledge of types and assumes that the order of type
attributes is invariant

17. Limitations Recap
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ The main limitations present in the DDS v1.2 type
system are the limited support for information
model extensibility and evolution
¨ Under the current model, information model
evolution or extensions are either non-transparent
or require complete update-redeploy cycles

18. DDS Extensible and
Dynamic Topic Types
[DDS-Xtypes]

19. DDS-XTypes Overview
The DDS-XTypes Specification defines:
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ A polymorphic structural type system for DDS topic types
– which formalizes extends in several ways the DDS v1.2
type system
¨ A set of standard concrete syntaxes for representing
topic types
¨ A set of serialization formats supporting extensible types
¨ A Dynamic API for defining Topic Types and DR/DW
operating over these types

20. DDS-XTypes Type System

21. Type System
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ The DDS-Xtypes type system defines the rules and
the type constructors that can be used to create
valid DDS Topic Types
¨ The type system also defines a structural sub-type
relation that is used to determine assignability of
topic types

22. Primitive Types
¨ The DDS-XTypes defines the following Primitive Types
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ The Type mapping defines how DDS Types are
mapped to native Programming Language Types
(e.g. C99 int32_t, float, etc.)
Primitive
Types
Integral Floating
Types Point Type Boolean
Byte Int16 Int32 Int64 Char8 Char16 Float32 Float64 Float128 Bool

23. Constructed Types
¨ The DDS-Xtypes introduces some new constructed types not
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
originally available in DDS v1.2 (marked in red in the figure below)
Constructed
Type
Collection BitSet Enumeration Aggregation Alias
Map Sequence String Array Union Structure Annotation

24. Annotations
¨ DDS-Xtypes introduces annotation as a way to
attach meta-data to , and control the semantics
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
of, types and type members
¨ Annotations are aggregated types whose
members are restricted to being:
¨ Primitive Types
¨ String
¨ Enumeration

25. Annotations in IDL
¨ Some built-in annotations, such as @Annotation!
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
@ID, @Key, @Optional, etc., are local interface MyAnnotation {!
attribute long attr1; !
defined by DDS-XTypes }!
attribute string attr2 default “zzz”; !
specification !
@MyAnnotation!
struct MyStructA {!
¨ User can define their own long member1;!
string member2; !
annotations }!
!
struct MyStructZ {!
Annotation can also be added
@MyAnnotation (attr1 = 10, !
¨ attr2 = “yyy”)!
as //@ after the annotated type long memberX;!
string memberY; //@Optional!
member }!
!

26. Structure
¨ Structures are the type used to associate user-defined types with
Topics
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Structures defined by the DDS-Xtypes Specification support Single
Inheritance
¨ Structures members have associated some properties, namely:
¨ ID. To uniquely identify an attribute
¨ Key. To identify whether the member is part of the key
¨ Optionality. To express the fact that an attributed is optional and thus
might not be set
¨ Must Understand. To enforce that a given field is not discarded
¨ Shared. To allow for non-inline data-storage of the attribute

27. DDS-XTypes Structures
¨ Built-in annotations can
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
struct TempSensor {!
be used to control the @Key @ID(10) !
long Id; !
semantic associated @MustUnderstand @ID(11)!
float temp;!
with type members @Optional @ID(12) !
float hum;!
};!
Annotations, as
!
¨ !
explained next, are also
Struct InfraRedTempSensor : TempSensor {!
@Shared @ID(20) !
used to control the kind
byte spectrum[1024];!
};!
of extensibility/mutability
!
supported

28. Type Extensibility & Mutability
To better support incremental system updates, the DDS-XTypes Specification
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
defines 3 different kinds of types. The @Extensibility annotation controls the
kind attached to a given type
¨ Final
¨ The type is sealed and nothing can be changed w/o breaking compatibility
¨ Extensible (Default)
¨ The Type is monotonically extensible, meaning that new attributes can be added
while preserving the compatibility previous versions of the same type
¨ Mutable
¨ The Type can be mutated by adding, reordering and removing fields. The type
compatibility depends on structural compatibility

29. Assignability
¨ The compatibility between different types, is expressed in
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
terms of assignability
¨ Given two types, T1 and T2, then based on the kind of
extensibility supported, T1 is-assignable-from T2 if the type T1
can be “projected/widened” from T2
¨ Example
T2 T1
struct TempSensor {!
@Key long Id; ! Projection struct TempSensor {!
float temp;! @Key long Id; !
TScale scale;! float temp;!
float hum;! TScale scale;!
! }!
}!

30. Final Types Assignability Rules
¨ Given two final types T1 and T2, we say that “T1 is-
assignable-from T2”, iff:
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ T1 is-assignable-from T2 iff the two types have exactly the
same members – meaning exactly same names and types
as well as @ID and @Key annotations
¨ Example:
T2 T1
@Extensibility(FINAL_EXTENSIBILITY) ! @Extensibility(FINAL_EXTENSIBILITY) !
struct TempSensor {! struct TSensor {!
@Key long Id; ! @Key long Id; !
float temp;! float temp;!
TScale scale;! TScale scale;!
}! }!

31. Extensible Types Assignability Rule
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Given two extensible types, T1 and T2, we say that
T1 is-assignable-from T2 iff:
¨ T2 is a monotonic extension of type T1, e.g., T1 is a “prefix”
of T2
¨ Example: T2 T1
@Extensibility(EXTENSIBLE_EXTENSIBILITY) ! @Extensibility(EXTENSIBLE_EXTENSIBILITY) !
struct TSensor {! struct TSensor {!
@Key long Id; ! @Key long Id; !
float temp;! float temp;!
TScale scale;! TScale scale;!
float hum;! };!
};!

32. Mutable Types Assignability Rule
¨ Given two mutable types, T1 and T2, we say that
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
T1 is-assignable-from T2 iff:
¨ T1 and T2 share the same keys (e.g. same members
sharing name and ID)
¨ Homonymous members in T1 and T2 share the same ID
and vice-versa
¨ For each member x of T1 (T1.x) and y of T2 (T2.y) sharing a
common ID then T1.x is-assignable-from T2.y
¨ All @MustUnderstand member of T2 also exist in T1

33. Mutable Types Example
T2 T1
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
@Extensibility(MUTABLE_EXTENSIBILITY) ! @Extensibility(MUTABLE_EXTENSIBILITY) !
struct TempSensor {! struct HumSensor{!
@Key @ID(10) long Id; ! @Key @ID(10) long Id; !
@ID(11)float temp;! @ID(13) float hum;!
@ID(12)TScale scale;! };!
@ID(13)float hum;!
};!
T1 is-assignable-from T2
T2 T1
@Extensibility(MUTABLE_EXTENSIBILITY) ! @Extensibility(MUTABLE_EXTENSIBILITY) !
struct TempSensor {! struct HumSensor{!
@Key @ID(10) long Id; ! @Key @ID(10) long Id; !
@ID(11)float temp;! @ID(13) float hum;!
@ID(12)TScale scale;! @ID(20) long status; !
@ID(13)float hum;! };!
};!
T1 is-assignable-from T2

34. Type Consistency QoS
The DDS-XTypes introduces a the Type Consistency
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
Enforcement Policy to control legal type conversion
¨ This Policy defines the following possibilities:
¨ EXACT_TYPE. As DDS today (but with checks)
¨ EXACT_NAME. What DDSI requires today
¨ DECLARED. Compatible type signatures + assignability
¨ ASSIGNABLE. Assignability is what matters

35. Topic Model
“com.myco.TTempSensor”
¨ The DDS-XTypes
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
specification extends
Name
the topic definition by “TempSensor, TSensor”
introducing the concept
of a type signature
Type
Signature Topic QoS
¨ Type signature are used TYPE_CONSISTENCY
to constrain the set of Type
DURABILITY,
DEADLINE,
types that might be struct TempSensor {!
PRIORITY,
considered assignable @Key long Id; !
float temp;!
…
TScale scale;!
}!

36. Information Model
Evolution Example

37. Example – Reloaded
Suppose that a new Old Sensor
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨
Temperature Sensor was struct TempSensor {!
@Key long Id; !
available that produced
float temp;!
TScale scale;!
}!
humidity estimates along
with temperature New Sensor
¨ So what could we do to struct TempSensor {!
@Key long Id; !
float temp;!
incrementally update the TScale scale;!
float hum;!
system?
!
}!

38. Assignable Topic Types
¨ With DDS-XTypes the system evolution does not introduce any burden
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ Types are projected through the assignability rules TTempSensor
struct TempSensor {!
@Key long Id; !
TTempSensor float temp;!
TScale scale;!
struct TempSensor {! DR }!
@Key long Id; !
float temp;!
TScale scale;!
DW TTempSensor
float hum;!
}! TTempSensor
DR struct TempSensor {!
@Key long Id; !
float temp;!
TScale scale;!
float hum;!
}!

39. Guidelines

40. Picking your “Extensibility”
¨ Final Types should be used to express universal invariant of the system.
Something that is so fundamental it should never-ever change w/o
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
requiring a full system update
¨ Extensible Types are the default in the specification because their
semantic is pretty straightforward and safe. Thus, if you don’t want to get
into type refactoring you might stick with this default
¨ Mutable Types give you maximum flexibility, however you should be
designing your information model around them. When using Mutable
Types ensure that you carefully use the @MustUndertand and @Optional
annotations to set structural lower bounds on your type as well as nicely
dealing with absence of members

41. Type Signature
¨ If you design your information model properly, then
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
you are safe in ignoring the type signature and
using the ASSIGNABLE Type Consistency policy
¨ However, when integrating existing systems, the
type-signature is key to scope what you might
match

42. Summing Up

43. Concluding Remarks
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
¨ The DDS-XTypes specification
provides a set of powerful
extensions to deal with system
extensibility and evolution
¨ The Specification is adopted and
under finalization
¨ The OpenSplice DDS team is
already implementing it!

44. OpenSplice DDS
Delivering Performance, Openness, and Freedom
http://www.opensplice.com/
http://www.opensplice.org/ http://www.slideshare.net/angelo.corsaro
emailto:opensplicedds@prismtech.com
Copyright
2010,
PrismTech
–
All
Rights
Reserved.
http://bit.ly/1Sreg
http://twitter.com/acorsaro/
http://www.youtube.com/OpenSpliceTube http://opensplice.blogspot.com