From the Tactical Edge to the Enterprise: Integrating DDS and JMS
•Als PPT, PDF herunterladen•
3 gefällt mir•610 views
Presentation to a Real-Time Workshop of the Object Management Group (OMG) describing concerns, approaches, and best practices for integrating systems based on DDS and JMS middleware in July, 2009.
![Introduction ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],© 2009 Real-Time Innovations, Inc. Assumption: Some knowledge of DDS and JMS](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (11)
Andere mochten auch
Ähnlich wie From the Tactical Edge to the Enterprise: Integrating DDS and JMS
Ähnlich wie From the Tactical Edge to the Enterprise: Integrating DDS and JMS (20)
Mehr von Rick Warren
Mehr von Rick Warren (19)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
From the Tactical Edge to the Enterprise: Integrating DDS and JMS
- 1. From the Tactical Edge to the Enterprise: Integrating DDS and JMS Rick Warren, Principal Engineer
- 8. System Architecture © 2009 Real-Time Innovations, Inc.
- 11. Throughput of Data-Centric Implementation | Traditional JMS Implementations | JMS PSM for DDS © 2009 Real-Time Innovations, Inc. http://www.rti.com/products/jms/latency-throughput-benchmarks.html
- 12. Data Model © 2009 Real-Time Innovations, Inc. http://blogs.rti.com/2009/04/20/designing-information-models-for-distributed-applications/
- 21. Destinations and Delivery © 2009 Real-Time Innovations, Inc.
- 25. Conclusions © 2009 Real-Time Innovations, Inc.
- 30. Q & A © 2009 Real-Time Innovations, Inc.
Hinweis der Redaktion
- Context for this talk: Many people trying to find best practices for: 1. Taking data from “edge” systems (real-time and/or tactical systems), 2. Transforming data into situational awareness/business intelligence 3. By fusing, correlating, mining that data Technically, means connecting edge systems to DBs, CEP engines, app servers, etc. People doing this now, but in ad hoc way. Very broad problem; this talk is narrow: integrating messaging and data distribution across subsystems.
- What do I mean by a “data-centric core” and “JMS PSM”?
- The performance penalty will be decreased somewhat if one or both of the adapters shown can run in-process with the broker (such a configuration may or may not be possible; see below). However, if the system depends on the broker for other critical functions, running these adapters in-process means potentially exposing other system components to failures in those adapters. The performance penalty will be increased if the DDS implementation and/or the JMS implementation require per-node daemons, as these introduce additional data copies, context switches, potential priority inversions, and potential points of failure.
- Company Confidential
- Benefits of data-centric, “JMS PSM” approach should now be clear. Remaining concerns mostly apply to either approach. First: data model differences.
- Before we can talk about the particulars of data definition and representation, we have to understand the different communication models typical of each API. … but just as you can write object-oriented code in C or procedural code in Java, you can design message-centric or data-centric systems around either JMS or DDS.
- On to the particulars: how do we transform the data? Two approaches considered in detail: JMS-centric: IDL representation of JMS messages DDS-centric: JMS Message implementation in terms of DDS-compatible data
- Approach #1: IDL definition for all JMS message types, all unioned together
- Two main parts of the message: properties and body. Zoom in on properties first.
- Now zoom in on body. Before we move on, a summary of where we stand: If problem is just to represent JMS system in DDS, then don’t need to worry about keys/instances, instance lifecycle, etc.: JMS doesn’t have those. … but then DDS system needs to know it’s talking to JMS, and approach loses a lot of value. Next part of the presentation provides a more general mapping.
- Approach #2: Define JMS message interfaces to access DDS-compatible data Currently, implementation would be DDS-vendor-specific Extensible Topics specification will enable DDS-vendor-agnostic implementation (mars/08-06-22)
- Presentation of DDS-compatible meta-data through JMS API eases data-centric design in JMS … but doesn’t require it: ignore these properties and design message-centric system
- Instance lifecycle not totally transparent to JMS application. May be necessary to allow user to turn DDS lifecycle support on/off.
- Talked about data and messages. But where do we send those messages? Next step: delivering messages to destinations.
- JMS topic names may be simple or hierarchical and may have any syntax: flat, directory, dot-delimited, LDAP/other URL, etc. Changing JMS vendors can entail info model change: applies to any vendor change … but possibly even more so when moving from traditional JMS to JMS with more data-centric capabilities.
- JMS gives great freedom to vendors. Could be bad wrt JMS portability, but one good thing: allows JMS topics to be defined in terms of DDS topics OMG can show leadership in JMS configuration; QoS profile format from DDS/LwCCM spec is relevant but not perfect match (e.g. terminology differences)
- Can previous model (DDS destination == JMS destination) work for queues too? Queues don’t promise much – this is also a benefit when mapping to DDS.
- Each ESB and CEP vendor has their own adapter APIs. JMS adapters usually come out of the box; DDS adapters don’t. DDS adapters for some products may be available from your DDS vendor. Otherwise, build your own.
- In the shorter term, if you have an existing design and code base to preserve, and if you can live with the limitations of bridging, then bridge. In the longer term, if you’re making a strategic investment, work towards a unified information model based on a data-centric JMS implementation.
- QoS profiles and libraries done: DDS for Lightweight CCM (ptc/2009-02-02), UML Profile for DDS Extensible Topics in progress: mars/08-06-22 Java 5 PSM discussed in SIG, but no process started