Proposed Java 5 API for DDS

Proposed RFP: Java 5(+) PSM for DDS Rick Warren, RTI [email_address] document number: 2009-09-09

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

Not portable across implementations

Observation : JMS does reflect / support these

Introduction Goals

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. enumerations, collections, beans, serialization, run-time type safety)

Grow the DDS ecosystem

… by improving portability

… by providing clarity wrt other technologies

… by increasing credibility , which comes from all of the above

Introduction Not 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

Eliminate / discredit JMS:

Entangle ourselves with the JCP: JCP owns Java distros, acts slowly, imposes high bar

Introduction What Do We Mean by Java 5?

Java Language , versions 5 and later

Modern language features

Generic types

First-class, type-safe enumerations

Annotations

Rich standard libraries

Improved wide character support

Built-in JMX

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

Built-in serialization ( since Java 1.1 )

Reflection, Java Beans ( since Java 1.1, improved Java 1.4 )

Mandatory Requirements Motherhood?

The proposed PSM shall :

Be derived from the DDS PIM

Implement DDS PIM in its entirety, be semantically equivalent to DDS IDL PSM

Have no impact on interoperability

Two communicating applications shall not require any awareness of each other’s PSMs

Avoid introducing new container types (like lists and strings)

Mandatory Requirements Portability

The proposed PSM shall :

Support runtime portability between implementations

Application compiled against proposed APIs shall be able to run against any conformant DDS implementation

For example , here’s how apps use JMS:

At compile time : use standard javax.jms interfaces

At run time : system property locates implementation classes

This standard of portability defines user expectations

Optional Requirements Built-in Serialization

The proposed PSM may :

Define how to leverage Java’s built-in data serialization

Could be as simple as:

public class DataReaderQos implements java.io.Serializable { … }

Or more sophisticated, like:

java.io.ObjectInput in = myDataReader.toInputStream();

Object sample = in.readObject();

Optional Requirements Java Management Extensions (JMX)

Integrate DDS QoS configuration with JMX

Integrate DDS status notifications with JMX

Potential Benefit : Help users to:

Plug into existing management tools, frameworks

Manage DDS-based systems remotely

Optional Requirements Other Optional Requirements

Comply with Java Beans design patterns to provide richer type introspection

… or take advantage of reflection in more novel ways

Integrate with OSGi : Easily plug into Eclipse and other OSGi-based containers

Issues to Be Discussed Motherhood?

Discuss the implications of the proposal for:

Performance

Object lifecycle

Memory usage

Subsequent Java versions (6 and 7)

Issues to Be Discussed Relationships Among Technologies

Discuss the relationships of the proposal to:

DDS PIM conventions vs. Java conventions

Implementation-specific extensions / technologies

Java editions: SE, EE, ME

Existing standard CORBA APIs ( org.omg.CORBA in Java SE)

Existing standard JMS APIs ( javax.jms in Java EE)

Conclusion (Redux)

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

Next Steps Road Map

Determining Level of Interest

Do DDS users have these problems?

Would DDS vendors respond to an RFP?

Possible Timeline

Discuss / complete problem definition, requirements list

Sep. – Dec. 2009

Issue RFP

Dec. 2009 or Mar. 2010

Initial submission(s)

Mar. or Jun. 2010

Revised submission(s)

Sep. 2010

Adoption

Dec. 2010

Proposed Java 5 API for DDS

0 comments

Notes on slide 1

Favorites, Groups & Events