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

From the Tactical Edge to the Enterprise: Integrating DDS and JMS Rick Warren, Principal Engineer

Introduction

Rick Warren

Principal Engineer, RTI

 [email_address]

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

R&D, previously Services

Integration : usability, portability, scalability, *ility

Agenda

DDS+JMS Integration Challenge

DDS & JMS: Towards Best Practices

System Architecture

Data Model

Destinations

Closing Remarks

Q & A

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

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

Solution Alternatives: JMS PSM for DDS

JMS front end to leverage existing JMS-compatible components

Data-centric back end for interop. with DDS systems

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

Performance and Fault Tolerance: DDS  JMS Bridge

Performance inversely proportional to number of clients per broker

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

© 2009 Real-Time Innovations, Inc. 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

DDS Representation of JMS Messages

Any JMS Message can be sent to any Destination

BytesMessage

MapMessage

ObjectMessage

StreamMessage

TextMessage

… but DDS Topic is strongly typed

© 2009 Real-Time Innovations, Inc. 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

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;

};

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");

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

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 spec Open issue for application developers

Bridged Integration Leverages Existing JMS 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

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

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?

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)

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

0 comments

Notes on slide 1

1 Favorite