Presentation to a Technical Meeting of the Object Management Group (OMG) proposing the issuance of an RFP for an improved Java API for DDS in December 2009. Following this presentation, the RFP was voted for issuance. This presentation has been superseded by later ones on the same subject.

1. Proposed RFP:Java 5 PSM for DDSMARS – Long Beach, CA – Dec., 2009 Rick Warren, RTI rick.warren@rti.com document number: 2009-12-02

2. Introduction Summary & Conclusion Java is a mature platform Established conventions, design patterns Emphasis on portability, safety, manageability Java is an important DDS platform Many of largest, most sophisticated users use it …often alongside other language(s) A vibrant ecosystem requires portability At runtime Across DDS implementations IDL-based DDS Java API does not reflect / support these Doesn’t look, work like most other Java code Requires frequent memory allocation Observation: JMS does reflect / support these © 2009 RTI - All rights Reserved 2

3. IntroductionGoals Improve robustness …by improving type safety (e.g. with generic types, first-class enumerations) …by streamlining error handling (e.g. with appropriate exceptions) Increase performance …by improving memory loan API Simplify integration, flatten learning curve …by following Java conventions / best practices (e.g. naming, organization, design patterns) …by leveraging built-in capabilities (e.g. generics, collections, beans, serialization, run-time type safety, …) Grow the DDS ecosystem …by improving performance and portability …by improving usability …by increasing credibility, which comes from all of the above © 2009 RTI - All rights Reserved 3

4. IntroductionNot the Goals Define new middleware concepts or protocols:this is about DDS / RTPS Invalidate the existing IDL PSM:don’t break existing implementations, applications Improve / replace the IDL  Java language mapping:won’t solve the aforementioned problems © 2009 RTI - All rights Reserved 4

5. IntroductionProcess Presented proposed RFP contents in San Antonio Submitted RFP by Long Beach 4-week deadline Incorporated feedback from AB reviewer Thanks to HuguesVincent of Thales This presentation reflects those changes Vote to issue this week Open Question from Hugues:Assuming this RFP is issued: Is it our intention to roll this PSM (and the new C++ PSM) into a future version of DDS itself, or will they remain separate? © 2009 RTI - All rights Reserved 5

7. First-class, type-safe enumerations

9. Built-in JMX

10. Comprehensive collections (since Java 1.2, improved in Java 5)

11. Built-in serialization (since Java 1.1)

12. Reflection, Java Beans (since Java 1.1, improved in Java 1.4)© 2009 RTI - All rights Reserved 6

13. Mandatory Requirements The proposed PSM shall: Provide a PSM, derived from the DDS PIM, targeting the Java 5 language. Include the rules by which this PSM was derived from that PIM. Implement the DDS PIM in its entirety. Have no impact on interoperability. Avoid the introduction of new container types; use instead Java-standard types. Not modify the existing language used for user-defined data types or their language mapping. Support runtime portability between DDS implementations. Not introduce dependencies on any other communications middleware technology—including, but not limited to, CORBA or JMS. Indicate which Edition(s) they target (Micro, Standard, Enterprise). Be designed such that they can co-exist with other technologies. For example, they should not interfere with the namespaces used by other OMG specifications or commonly used packages. Include an API to allow DDS applications to use QoS profiles. Encompass any APIs introduced by “Extensible and Dynamic Types.” © 2009 RTI - All rights Reserved 7

14. Optional Requirements The proposed PSM may: Define how QoS may be configured and status notifications monitored using JMX. Define how data written and read through DDS may integrate with the built-in data serialization support in the Java platform. Define how dynamic applications can take advantage of the reflective capabilities of the Java platform. Possible uses of reflection include, but are not limited to: Comply with Java Beans-compatible design patterns. Integrate “Extensible and Dynamic Types” with the built-in Java type introspection capability. Provide reflective instantiation of, and/or access to, DataReaders and DataWriters corresponding to a given Java type. Define how applications can load and access a DDS implementation in the context of OSGi. © 2009 Real-Time Innovations, Inc. 8

15. Issues to Be Discussed Performance! Memory usage Vendor extensions: how to make them consistent w/o side effects Consistency w/ existing PSM vs. Java conventions Issues with respect to Java 6, Java 7 Entity lifecycle management Ensuring interoperability Ensuring runtime portability Choice of Java Edition(s) © 2009 Real-Time Innovations, Inc. 9

16. Road Map © 2009 Real-Time Innovations, Inc. 10

17. Conclusion Provide rigorous runtime portability Improve robustness Increase performance Simplify integration, flatten learning curve Grow the DDS ecosystem …with a new Java 5+ PSM …that takes advantage of platform-specific Technologies Best practices Conventions © 2009 RTI - All rights Reserved 11