from the tactical edge to the enterprise: integrating dds and jms

The Real-TimeMiddleware Experts

From the Tactical Edge to the Enterprise:Integrating DDS and JMS

Rick Warren, Principal Engineer

Introduction

Rick Warren

Principal Engineer, RTI

[email protected]

http://blogs.rti.com/author/rtirick/

R&D, previously ServicesIntegration: usability, portability, scalability, *ility

Agenda DDS+JMS Integration

Challenge

DDS & JMS: Towards Best Practices– System Architecture– Data Model– Destinations

Closing Remarks

Q & A

© 2009 Real-Time Innovations, Inc. 2

Assumption: Some knowledge of DDS and JMS

Problem Statement

JMS established in enterprise applications– Integrates web services,

legacy applications, etc.– App servers, ESBs provide

adapters

DDS, newcomer, successful at edge and moving in– For example:

• Sensor networks• Distributed real-time control• Military tactical systems

– Offers things JMS doesn’t:• Improved determinism• QoS for explicit configuration and

resource management• Cross-vendor interoperability


Problem Statement

Large JMS-compatible ecosystem already exists

DDS-compatible ecosystem still developing

…So how do I plug my DDS app into a JMS-compatible system?


Solution Alternatives

What do you mean by “JMS”?

“JMS” as a middleware implementation– e.g. WebLogic JMS, TIBCO EMS– JMS and DDS subsystems can’t communicate directly:

different protocols (even across JMS implementations) Build a bridge; could be based on ESB or CEP engine


DDS App

DDS App

Ad

apter

Ad

apter

BrokerBroker

Ad

apter

Ad

apter

JMS App

JMS AppRTPS ???

Solution Alternatives

What do you mean by “JMS”?

“JMS” as a portability API– Raison d'être for JMS specification Implement JMS API atop data-centric middleware core

aka “JMS PSM” for DDS


DDS App

DDS App

JMS App

JMS AppRTPS

Solution Alternatives:JMS PSM for DDS

JMS front end to leverage existing JMS-compatible components

Data-centric back end for interop. with DDS systems


JMS APIJMS API

App Servers, ESBs, etc.

Data-Centric CoreData-Centric Core

RTPS

Real-Time Systems

System Architecture


DDS App

DDS App

Performance and Fault Tolerance:DDS JMS Bridge

Leverages existing components and infrastructure while isolating subsystems

Broker is handy place to locate data translation, impedance mismatching, and other services


Ad

apter

Ad

apter

BrokerBroker

Ad

apter

Ad

apter

JMS App

JMS App

copy copy

pt of failure pt of failure pt of failure

DDS App

DDS App

Performance and Fault Tolerance:DDS JMS Bridge


Ad

apter

Ad

apter

BrokerBroker

Ad

apter

Ad

apter

JMS App

JMS App

DDS App

DDS App

DDS App

DDS App

JMS App

JMS App

JMS App

JMS App

Performance inversely proportional to number of clients

per broker

| Traditional JMS Implementations |

Throughput of Data-Centric Implementation

JMS PSM for DDS

© 2009 Real-Time Innovations, Inc. 11http://www.rti.com/products/jms/latency-throughput-benchmarks.html


Data Model

http://blogs.rti.com/2009/04/20/designing-information-models-for-distributed-applications/

Data-Centric Model Deliver updates to the

data itself– Most effective: data lives

in middleware– Leverages configuration

(QoS)-driven behavior

…Transparently, according to a well-defined data type

…Using user-defined interfaces

Message-Centric Model Deliver messages about

changes to the data– Most effective: data lives

in app-managed store– Behaviors implemented in

application code

…Opaquely, according to an implicit or ad hoc “data type”

…Using middleware-defined interfaces


Many distributed systems contain both, regardless of the API(s) they use.

Data-Centric vs. Message-Centric Design

http://blogs.rti.com/2009/06/03/thinking-differently-about-messaging/

DDS JMS Data Interoperability

Specialized Mapping– Build custom transformation in system-specific

bridge

General-Purpose Mappings– Pack DDS-compatible data objects into JMS ObjectMessage

– Define DDS-compatible type for representing JMS messages

– Implement Message interfaces reflectively in terms of DDS-compatible data


More S

pecificM

ore Generic

More S

pecificM

ore Generic

Application

JMS

Provider

Application

JMS

Provider

DDS Representation of JMS Messages


module JMS { struct BytesBody { … }; struct StreamBody { … }; struct MapBody { … }; struct TextBody { … }; union switch (BodyType) { case BYTES: BytesBody bytes; case STREAM: StreamBody stream; case MAP: MapBody map; case TEXT: TextBody text; }} IDL Definition

Any JMS Message can be sent to any Destination

– BytesMessage– MapMessage– ObjectMessage– StreamMessage– TextMessage

…but DDS Topic is strongly typed

DDS Representation of JMS Messages:Message Properties

struct Message { sequence<NameValuePair> properties; …;};

struct NameValuePair { string name; union switch (ValueKind) { case SHORT_KIND: short short_value; case LONG_KIND: long long_value; case …: } value;};

Any Message can contain arbitrary name-value pairs


IDL is verbose

Content filtering is a challenge

DDS Representation of JMS Messages:Message Body

struct Message { sequence<NameValuePair> properties;

union switch (BodyKind) { case BYTES_KIND: sequence<octet> bytes; case MAP_KIND: sequence<NameValuePair> map; case OBJECT_KIND: sequence<octet> object; case TEXT_KIND: string text; case …: } body;};


Not transparent: DDS subsystem coupled to JMS concepts

JMS Representation of DDS Messages:Message Body

struct MyType long my_long; string my_string;};

int intVal = msg.getInt( "my_long");msg.setString( "my_string", "my value");


IDL:

JMS:

JMS Representation of DDS Messages:Sample Metadata and Instance Lifecycle

DDS Meta-Data:

Key fields

Sample state, view state, instance state

Source and reception time stamps

Generation counts and ranks

Proposal:

JMS_* message properties

* JMS app must be aware of DDS if it uses these, but it doesn’t have to


JMS Representation of DDS Messages:Sample Metadata and Instance Lifecycle

Publication: DDS unregister() and dispose()

send() message with a property set

Subscription: Detecting unregistration/disposal

Receive (body-less?) message with a property set

Open Issue: Not transparent to JMS applications May not be compatible with existing JMS subsystems


Destinations and Delivery


A Topic is a Topic is a Topic…

DDS and JMS both describe topics for 1-to-many comm.

DDS specification rigorously defines what a Topic is– Name: literal string– Data type– QoS configuration: fully specified, application-visible

JMS specification leaves Topic concept to vendors– Names of unspecified syntax; info model flat or hierarchical– No data type– Config. vendor-specific; not available through std. interfaces Changing JMS vendors can entail information model changes:

configuration, code, and/or design changes!


A Topic is a Topic is a Topic…

DDS Topic = JMS Topic

Simple topic name

Specified data type– Enforce message contents based on type definition– …or use “self-describing” type as in previous above

DDS-compatible configuration


A Queue is a … ?

JMS defines queues in addition to topics; DDS doesn’t– At-least-once delivery: messages must be kept until ack’ed– Only relevant message ordering is per-producing Session– Behavior with respect to concurrent consumers is unspecified

JMS queues can be mapped to DDS topics– DDS addition beneficial: at-least-once delivery (or at-least-n)

• Proposal: min_acknowledgements = [1,n], LENGTH_UNLIMITED• In DurabilityQosPolicy?

– Existing 1-to-many delivery is compliant; does it match use case?

No def’n of exactly-once delivery in either specOpen issue for application developers


Conclusions


DDS App

DDS App

Bridged Integration Leverages ExistingJMS Subsystems

Preserves investment in JMS design, which may or may not be portable

Requires adapter implementations specific to broker implementation

Limits levels of performance and integration across DDS/JMS interface

May limit fault tolerance of combined system© 2009 Real-Time Innovations, Inc. 26

Ad

apter

Ad

apter

BrokerBroker

Ad

apter

Ad

apter

JMS App

JMS App

JMS PSM for DDS Empowers Data-Centric Integration with Enterprise Infrastructure

Requires JMS provider with data-centric core

May require data-centric application design

Provides maximum performance and fault tolerance

Provides interoperability:DDS DDS, DDS JMS, JMS JMS

Supports high performance and tight integration with unified data model


JMS APIJMS API



RTPS

Real-Time Systems

JMS APIJMS API



RTPS

Real-Time Systems

Information Mapping Concerns are the Same, Regardless of System Architecture

Information Model Components– Message/sample contents: body and properties– Instances and instance lifecycle– Message/sample destinations: topics, queues, and

configuration

Mapping Considerations– Completeness:

Are all data and meta-data needed from both APIs?– Transparency:

Does DDS have to understand JMS or vice versa?– Data-centric vs. message-centric design:

Do instances, keys, etc. need to be represented?

© 2009 Real-Time Innovations, Inc. 28http://blogs.rti.com/2009/04/30/data-transparency-why-you-should-care/

Needed: Standards Leadership

QoS profiles allow configuration where JMS API is lacking

Extensible Topics specification will improve portability of DDS JMS data type interoperability implementation

Java 5 PSM for DDS would improve portability– Easier to create ESB, CEP adapters for multiple DDS impls.– To what extent should it be aligned with JMS?

OMG/JCP collaboration could improve portability and integration for combined DDS + JMS implementation(s)


Done

Done

In Progress

In Progress

Hypothetical

Hypothetical

Q & A


from the tactical edge to the enterprise: integrating dds and jms

Technology