Interoperability, extensibility and efficiency are increasingly required to enable and effectively operate Smart Energy Grids, Smart Cities, Exploration and Production Systems in the Oil and Gas industry, and international Air Traffic Control and Management Systems. Yet, these key architectural attributes are often an after-thought as opposed to axioms upon which the entire architecture is designed – with the result that many systems are non-interoperable, hard to extend and inefficient.
This presentation will (1) precisely define the meaning of interoperability, extensibility and efficiency, (2) propose metrics for their evaluation, and (3) explain these important properties can be “designed in” system architectures.
We will introduce data-centricity as the paradigm and architectural pattern that fosters interoperability, extensibility and efficiency and will explain how existing standards such as the OMG DDS can be used to implement data-centric architectures.
3. SESAR: The Single Sky
☐ Enable operational interoperability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
across ATM/ATC in EU
☐ Allow information to flow
seamlessly within the ATC/ATM
OpenSplice DDS
ecosystem and across Europe
☐ Ensure the system is incrementally
extensible and evolvable
☐ Ensure the system makes efficient
use of resources such as network
4. Smart City / Smart Grid
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Make relevant information
available in real-time to an
open ended number of
OpenSplice DDS
consumers
☐ Ensure interoperability with
third parties, efficient use of
resources and extensibility
6. Defining Interoperability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
The ability of two or more systems or components to exchange
information and to use the information that has been exchanged.
OpenSplice DDS
7. Syntactic Interoperability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ The ability of two or more systems to communicate and
exchange data
☐ Requires specified data formats and communication protocols
OpenSplice DDS
☐ Syntactical Interoperability is a necessary condition for higher-
level of interoperability
8. Semantic Interoperability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ The ability to meaningfully and accurately interpret exchanged
information
☐ Semantic interoperability requires communication parties to agree
OpenSplice DDS
on a common information model
9. Interoperability in Summary
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Interoperability requires agreements at a syntactic and
semantic level
☐ Syntactic Interoperability is commonly achieved by agreeing
OpenSplice DDS
a communication protocol and a data representation
standard
☐ Semantic Interoperability is commonly achieved by agreeing
on a Common Information Model
10. Measuring Interoperability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
Based on the previous definitions we can define 3 levels of
interoperability:
OpenSplice DDS
☐ Level 0: No Interoperability (closed interfaces)
☐ Level 1: Syntactic Interoperability (open protocol/data format)
☐ Level 2: Semantic Interoperability (common information model)
11. Example: Syntactic Interoperability
☐ Suppose that we define legal messages as any word created over
alphabet, more formally:
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ ∑ = {a, b, ..., z, ?, !}
Che ora?
☐ words := { x ∈ ∑ } +
☐ sentence = words+ Sapresti dirmi
OpenSplice DDS
che ore sono? What?
☐ Example:
☐ Can Talk and hear w/o problems
☐ Don’t necessarily “understand”
12. Example: Semantic Interoperability
☐ Suppose now that we constrain our grammar to a subset of legal
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
English phrases:
Thanks!
Excuse me, do you
OpenSplice DDS
Sure, it’s 11
know the time?
o’clock.
14. Defining Extensibility
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
Extensibility is a systemic measure of the ability to extend a system
and the level of effort required to implement the extension
Extensions can be through the addition of new functionality or the
OpenSplice DDS
modification of an existing functionality
Modularity and loose coupling foster extensibility
15. Forward Compatibility
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Forward compatibility (at times considered as part of extensibility)
OpenSplice DDS
aims at the ability of a system to gracefully accept input intended
for a later version of the system
16. Measuring Extensibility
☐ Extensibility can be measured w.r.t. the cost associated with
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
adding a new functionality to the system
OpenSplice DDS
Extensibility
=
CDNF/(CINF
+
CDNF)
☐ Where:
☐ CDNF: Cost of developing the new feature
☐ CINF: Cost of integration for the new feature
☐ For any system: 0 < Extensibility ≤ 1
17. Measuring Forward Compatibility
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ For simplicity we will assume that forward compatibility is binary,
thus either is supported or not
OpenSplice DDS
☐ In general, many systems support forward compatibility under
certain conditions. Yet for our discussion it is OK to consider it as a
binary property.
19. Defining Efficiency
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
In general terms, efficiency describes the extent to which a
valuable resource, such as time, space, network bandwidth, etc.,
is well used for the intended task of purpose
OpenSplice DDS
20. Measuring Efficiency
☐ Efficiency can be measured as follows:
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
Efficiency
=
CO/CA
OpenSplice DDS
☐ Where:
☐ CO: Optimal Cost to perform the given task/operation
☐ CA: Actual Cost to perform the given task/action
☐ For any system: 0 < Efficiency ≤ 1
21. Example: Data Encoding
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ As an example of efficiency, let’s consider different data
encoding for a relatively simple Temperature Sensor
☐ Let’s assume a very simple temperature sensor defined as
OpenSplice DDS
follows:
struct
TempSensor
{
short
temp;
short
hum;
};
22. Example: Data Encoding
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
TempSensor
t
=
{35,
75};
CDR JSON
OpenSplice DDS
byte 0 1 2 3
byte 0 1 2 3
{ “ t e
0 23 0 4B
m p “ :
3 5 , “
h u m “
4
bytes
: 7 5 }
16
bytes
23. Example: Data Encoding
☐ Let’s compute now the efficiency. If we ignore variable length
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
encoding, then the cost of encoding two short integers is 4 bytes,
thus CO = 4 bytes
☐ CDR Efficiency. The actual cost of encoding our temperature sensor
OpenSplice DDS
in CDR was CA = 4 bytes this leads to EfficiencyCDR = 4/4 = 1
☐ JSON Efficiency. The actual cost of encoding our temperature sensor
in JSON was CA = 16 bytes this leads to EfficiencyJSON = 4/16 = 0.25
☐ Note: We have taken a few short cuts here since a formally sound
derivation of CO should have considered the entropy of the data
source. Instead we have silently assumed a binary entropy function.
25. Data-Centric Architecture (DCA)
Abstract Definition
A Data Centric Architecture consists of:
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Abstract Data Types: A, B, C, ...
☐ Arrows: f, g, h, ...
where arrows satisfy the following properties:
OpenSplice DDS
Given f: A → B, g: B → C, and h: C → D
then the following holds true:
∃ g ∘ f: A → C [Composition]
∃ 1A : A → A [Identity Arrow]
h ∘ (g ∘ f) = (h ∘ g) ∘ f [Associativity]
f ∘ 1A = f = 1B ∘ f [Unit]
A Data Centric Architecture is a Category
26. Data-Centric Architecture (DCA)
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
The abstract definition of a Data-Centric Architecture formally
captures its key properties:
☐ The Abstraction Barrier is defined in terms of Abstract Data Types
OpenSplice DDS
☐ The System Behaviour is specified in terms of transformations
(functions or arrows) over these Abstract Data Types
Note: From this emerges a natural relationship between DCA and
Functional Programming Languages
27. Example: Space Traveller [1/3]
☐ Suppose we want to create a
distributed game in which we have
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
(some) UFOs that are trying to
destroy our spaceship
☐ UFO can be our allies/enemies and
can be played by other players or
OpenSplice DDS
computers
☐ Some UFOs, might just be space
travellers and should not be
destroyed
☐ The goal of the game is to destroy
the UFOs that have been classified
as threats
28. Example: Space Traveller [2/3]
☐ The DCA for this game could be described as follows
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
(keeping it simple...)
Data Types Arrows
OpenSplice DDS
☐ FlyingObject ☐ animate: Dynamics → Dynamics
☐ Dynamics ☐ classify: FlyingObject x Dynamics → Classification
☐ Classification ☐ collide: [FlyingObject x Dynamics] → [Collision]
☐ Collision ☐ pilot: IO → Dynamics x FlyingObject
☐ fire: IO → FlyingObject x Dynamics
☐ display: FlyingObject x Dynamics x Classification x Collision
→ IO
29. Example: Space Traveller [3/3]
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
FlyingObject FlyingObject
IO pilot Dynamics animate Dynamics classify Classification
Dynamics Dynamics
OpenSplice DDS
FlyingObject
FlyingObject [FlyingObject] Dynamics
IO fire [Dynamics]
collide [Collision] display IO
Dynamics Classification
Collision
30. Data-Centric vs. Service-Centric
Data-Centric and Service-Centric architectures, such as SOA, Distributed
Objects, etc., differ in several dimensions:
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Abstraction Barrier:
☐ Data-Centric architectures rely on data abstractions
☐ Service-Centric architectures rely on service abstractions
OpenSplice DDS
☐ Level of Coupling
☐ Data-Centric architectures rely solely on the shared knowledge of abstract data
types (agree on the “what”)
☐ Service-Centric architectures rely on the shared knowledge of operational
interfaces along with the knowledge of the service provider and of its existence
(agree on “what”, “who”, and “when”)
31. DCA Benefits
☐ Loose Coupling
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Anonymicity (e.g. only things to be known are the data types and
not who produces/consumes them)
Composability (especially when combined with functional
OpenSplice DDS
☐
languages)
☐ Extensibility
☐ Ease of Integration
☐ Performance (easier to parallelize)
32. DCA Interoperability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ To enable Interoperability DCA should rely on middleware
technology that provides a Level 2 Interoperability
OpenSplice DDS
☐ In other terms, middleware technologies that define
☐ open/standard communication protocols
☐ open/standard data representation format, and
☐ open/standard ways of describing a Common Information Model
33. DCA Extensibility
☐ Extensibility is enabled by DCA through modularity, composability
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
and loose coupling
☐ Modularity is tied to the granularity of the “arrows/functions” that
defined in the system
OpenSplice DDS
☐ Composability follows from the properties (refer to definition) of DCA
☐ Loose coupling follows from the fact that the only “contract”
between the different element of a system are the abstract data
types and nothing else. Neither topological nor existential
informations, e.g. it does not matter if there are consumer for a given
type T nor how many of those are there and where they are located
34. DCA Forward Compatibility
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Forward compatibility depends entirely from the technology used
to implement the DCA
OpenSplice DDS
☐ However, the presence of a typed Common Information Model
can facilitate the implementation of efficient and safe “forward
compatibility” mechanism
35. Efficiency
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ The efficiency of a DCA depends on
OpenSplice DDS
☐ The definition of the Common Information Model (e.g. its level of
normalization), and
☐ The efficiency of the infrastructure used to implement the DCA
37. DDS Core Standard
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ DDS is a family of Application
standards addressing the
Data Centric Publish Subscriber (DCPS)
communication needs of Content
Ownership Durability
Data Centric Architectures Subscription
OpenSplice DDS
Minimum Profile
☐ The two standards at the
core are: DDS Interoperability Wire Protocol - DDSI-RTPS
☐ DDS v1.2 -- API
UDP/IP
Application
☐ DDSI v2.1 -- Wire Protocol
38. DDS Standard Ecosystem
Application Application
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
2012 API 2012
DDS RMI DDS RMI
2012 2010 2010 2012
ANSI C ISO C++ Java-5 Scala
OpenSplice DDS
2004 2010 2010 201x
Security
Security
X-Types
X-Types
DDS 2004
Wire Protocol
DDSI-RTPS network DDSI-RTPS
2006 2006
39. DCAs with DDS
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ DDS provides first class support for DCAs
☐ DCAs Abstract Data Types are captured in DDS via Topics
OpenSplice DDS
☐ DDS does not provide primitive support for specifying DCAs Arrows.
These are defined by the architect using her/his favorite
formalism / programming language
40. DDS Topics
“net.gva.VehiclePosition”
☐ A Topic defines a typed data
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
stream Name
☐ A Topic has associated a data
type and QoS
Topic
Typ
S
OpenSplice DDS
Qo
☐ The Topic name, type and QoS DURABILITY,
e
DEADLINE,
defines the key functional and PRIORITY,
…
non-functional invariants
struct Position2D {
☐ Topics can be discovered or long
long
vid; //@Key
x;
locally defined };
long y;
45. Extensibility
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ DDS-based applications feature all the extensibility benefits
deriving from DCA
OpenSplice DDS
☐ In addition, due to the built-in dynamic discovery, DDS-based
Systems are completely decoupled from deployment details
46. Forward Compatibility
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ DDS supports Forward Compatibility, specifically, it allows for both
monotonic as well as generalized type extensions
OpenSplice DDS
☐ Monotonic type extensions allow old systems to consume new
types as far as changes consist of additions to the tail of the type
☐ Generalized type extensions allows attribute reordering and
removal
48. DDS Efficiency
OpenSplice DDS Performance Metrics
The DDS standard was
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐
designed in such a way to Latency
maximize time and space ☐ 15-20 usec Inter-Core Latency
efficiency ☐ 75 usec over GBps Ethernet
OpenSplice DDS
☐ OpenSplice DDS has been Throughput
designed to minimize ☐ Up to 10+M msg/sec inter-core
resource usage while
maximizing performance and ☐ Up to 5M msg/sec inter node
scalability
53. SESAR: The Single Sky
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Adopted the DDS standard as
the foundation of their DCA
OpenSplice DDS
☐ Defined and standardized a
domain specific Common
Information Model concerning
flights and their management
54. City
Service
-‐
Architecture
Urbio&ca
APPLICATIONS
User,
City
agent
Urbio2ca
MESH
network
City
Message
BUS
–
Opensplice
DDS Data
warehouse
Esper
–
Park
systems
Exis2ng
Control
55. UK Generic Vehicle Architecture
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Adopted the DDS standard
as the technology at the
foundation of next
generation military vehicles
OpenSplice DDS
☐ Defined a domain specific
Common Information
Model -- the GVA
Information Model
57. Concluding Remarks
Copyright
2011,
PrismTech
–
All
Rights
Reserved.
☐ Interoperability, Extensibility and Efficiency is key for an increasing
number of applications
☐ Data Centric Architectures (DCAs) provide an architectural
OpenSplice DDS
framework that facilitates the design of systems that are
interoperable, extensible and efficient
☐ DDS is the middleware infrastructure that most naturally supports
DCAs