Middleware technologies today play a key role in the vast majority of mission- and business-critical systems. Choosing the right middleware infrastructure for these systems is a non-trivial task that must take into account many different dimensions ranging from the purely technical to tactical and strategic aspects. This Webcast will compare and contrast the Data Distribution Service for Real-Time Systems (DDS) against the Advanced Message Queuing Protocol (AMQP). The comparison will provide an in depth analysis of the technical differences between the two standards and will detail their technology management and technology strategy standpoints.
4. Genesis
DDS AMQP
‣ Emerged from Aerospace and Defense ‣ Emerged from the Financial Market
to address the data distribution from the desire of freeing users from
requirement of a large class of mission- proprietary and non-interoperable
critical systems messaging systems
‣ Evolved to address on-the-wire ‣ Evolved into an effort to define a
interoperability and provide the generic enterprise messaging standard
ubiquitous data-bus for mission-critical
System-of-Systems
5. Standardization Organization
DDS AMQP
‣ DDS is an Object Management Group ‣ AMQP is standardized by the AMQP
(OMG) Standard Working Group
‣ The OMG is a an international, open ‣ The AMQP Working Group is a non-
membership, not-for-profit computer profit organization with a free
industry consortium since 1989 membership based on interest and
‣ OMG is an ISO PAS submitter, able to merit
submit our specifications directly into
ISO’s fast-track adoption process.
6. Standard Evolution
DDS v1.0 DDS v1.1 DDS v1.2 DDSI v2.0 DDSI v2.1 DDS-XTopics
Dec Dec Jan Apr Jan March
2004 2005 2006 2007 2008 2009 2010
Jun Nov Dec
AMQP v0-8 AMQP v0-9-1 AMQP v1-0 draft
???
Dec
AMQP v0-10
AMQP v0-9
7. Scope of Standardization
Application
Application
Object/Relational Mapping
Data Local Reconstruction Layer (DLRL)
DDS v1.2
Content
Ownership Durability
Subscription
API (?) Minimum Profile
Data Centric Publish/Subscribe (DCPS)
DDSI v2.1
AMQP v1-0
Advanced Message Queuing Protocol Real-Time Publish/Subscribe Protocol
Interoperability Wire Protocol DDS Interoperability Wire Protocol
TCP/IP UDP/IP
11. AMQP v1-0 Messages
‣ AMQP is a standard protocol for messaging
‣ As such AMQP the unit of information that
can be sent or received is a message.
‣ An AMQP message encapsulate the “Bare
Message”, provided by the application, within
an annotated message
[Source AMQP specification v1-0]
15. AMQP v1-0 Conceptual Model
‣ An AMQP Network consists of Nodes and Links
‣ A Node is a named source and/or sink of Messages. A Message is created at a
(Producer) Node, and may travel along links, via other nodes until it reaches a
terminating (Consumer) Node.
‣ A Link is a unidirectional route between nodes along which messages may travel. Links
may have entry criteria (Filters) which restrict which messages may travel along them.
The link lifetime is tied to the lifetime of the source and destination nodes.
m m
Link
m
Node Node
16. Destructive Links
Destructive Links consume the message from the originating source.
Destructive Link Destructive Link Destructive Link
m m m m
Node 1 Node 2 Node 1 Node 2 Node 1 Node 2
Time
17. Non-Destructive Links
Non-Destructive Links don’t consume messages from the source node.
Non-Destructive Non-Destructive
Link Link
m m m m m
Node 1 Node 2 Node 1 Node 2 Node 1 Node 2
Time
18. Filtered Links
Links can have associated filters that allow to predicate on the messages that might
traverse. Filter can be based on the non opaque portion of the message.
Link Link m
{color = red} {color = red} m
m m Node Node
m
m m
m
Node Link Node Link m
{color = green} {color = green}
m
Node Node
Time
23. AMQP v1-0 Deployment Model
‣ Nodes within the AMQP network
exist within Containers
‣ A container is a physical or logical
process to which network
connections can be established
[Source AMQP specification v1-0]
27. Sessions
‣ A Session is a named interaction
[Source AMQP specification v1-0]
between two containers providing
for a pair of reliable ordered
command streams (one in each
direction)
‣ Links between nodes in different
containers are created on a
session
‣ Containers and Sessions form an
underlay network, nodes and links
an overlay network atop them
28. Sessions & Commands
‣ Sessions are a transport for commands
‣ Commands are the atomic units of work of the AMQP transport protocol
Commands are used to create links between nodes in the source and destination
containers, to transfer message data, and to issue and revoke credit
‣ In general an AMQP session will be carried over some form of network layer, thus
commands sent on a session are asynchronous.
[Source AMQP specification v1-0]
29. Transport Model
m m
Link
m
Node Node
Links Links
Session Session
Links Links
Session Transport Connection (TCP/IP) Session
Links Links
Session Session
35. AMQP Type System
‣ AMQP defines a type-system
that is used to encode messages
and controls sent as part of the
protocol
‣ This type system can be also
used to encode application data
[Source AMQP specification v1-0]
36. Primitive Types
DDS Type System
boolean long
octet unsigned long
char long long
wchar unsigned long
long
‣ DDS supports the definition of types based on a subset of short
unsigned short
float
double
the IDL specification language. long double
‣ This type system is used internally by DDS and is also Constructed Types Example
available to user for defining topic types enum enum Dimension { 1D, 2D, 3D, 4D };
Template Type Example
string<length = UNBOUNDED> string s1;
string<32> s2; struct Coord1D { long x;};
struct Coord2D { long x; long y; };
wstring<length = UNBOUNDED> wstring ws1;
struct struct Coord3D { long x; long y; long
wstring<64> ws2;
z; };
struct Coord4D { long x; long y; long z,
unsigned long long t;};
sequence<T,length = UNBOUNDED> sequence<octet> oseq;
sequence<octet, 1024> oseq1k;
sequence<MyType> mtseq; union Coord switch (Dimension) {
sequence<MyType, 10> mtseq10; case 1D:
Coord1D c1d;
case 2D:
Coord2D c2d;
union
case 3D:
Coord3D c3d;
fixed<digits,scale> fixed<5,2> fp; //d1d2d3.d4d5 case 4D:
Coord4D c4d;
};
38. DDS AMQP
‣ A generic DDS application is a self-formed ‣ A generic AMQP application is a graph of
federation reads and writes topics over the nodes connected by links over which travel
Global Data Space application provided messages
‣ Communication is hidden to the applications ‣ The link-related traffic is managed by
which is provided with a read/write sematics sessions which in turns communicate via a
transport connection.
‣ UDP Unicast and Multicast are available for
DDS v1.2, DDSI v2.1 ‣ The only transport currently available for
AMQP v1-0 is TCP
39. AMQP v1-0 StatusDDS AMQP
‣ Addressing Scheme. Does not define a standard
‣ Data Centricity. DDS is about data and it is fair global addressing scheme, this will be part of v1-1
to say that data takes life in DDS, thanks to the ‣ Transport Protocol. Currently only supports
support for keys, lifecycle management, etc. TCP, but UDP and SCTP will be added in future
‣ Transport Protocol. Currently supports UDP revisions of the spec
(Unicast and Multicast). TCP will be supported in ‣ Broker Management. A SIG is working on
upcoming revisions of the standard. However, defining an API for Broker Management, today,
there is nothing that prevents DDS today to use each implementation has its own way
TCP as a transport ‣ Topology Configuration. The Broker topology
‣ Topology Configuration. Topology is dynamically can be configured via management tools, yet the
discovered by DDS via its standard discovery spec does not explicitly supports automatic
protocol propagation of queue subscriptions (some
product do)
45. Concluding Remarks
DDS AMQP
‣ DDS provides the abstraction of a Global ‣ AMQP is provides as basic abstraction that
Data Space, a ubiquitous, universal and fully of messages and message routing.
distributed data cache. ‣ AMQP standardized the wire-protocol and
‣ DDS makes user data a first class citizen uses this standard to achieve API
‣ DDS provides a standard API as well as an independence
interoperable Wire-Protocol
DDS and AMQP are very interesting technologies, which at some point might work in synergy.
OpenSplice DDS could be using AMQP as one of its wire-protocols. The DDS API over AMQP could be
standardize...