Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 70: IIOP Protocol Adapter for JMXTM Specification

This JSR has been Withdrawn
Reason: Withdrawn following re-prioritization within the company, IONA could no longer commit the resources necessary to complete the specification and build an RI and TCK. In addition, IONA no longer sees a sufficient customer demand for access to JMX MBeans using CORBA clients, so IONA formed the opinion that the specification did not address a common need in the marketplace and therefore was unnecessary.

Update to the Java Specification Request (JSR)

The change of Specification Lead has resulted in the following change to the original JSR.

Section 1. Identification

Submitting Participant: IONA Technologies Plc

Name of Contact Person: Ben Beazley

E-Mail Address:

Telephone Number: +61 8 9288 4027

Fax Number:

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Participant: IONA Technologies Plc

Name of Contact Person: Kevin Curley

E-Mail Address:

Telephone Number: +353-1-662-5255

Fax Number: +353-1-637-2889

(NOTE that this information has been updated since the original.)

List of other companies who endorse this JSR:

Sun Microsystems
Schmid Telecom
Computer Associates

Section 2: Request

2.1 Please describe the proposed Specification:

The CORBA adapter for JMX is part of the second phase of the Java Management Extensions (JMX) umbrella initiative.

CORBA is a technology that enables platform and language independent distributed communication. CORBA uses IIOP as its communication protocol

Java Management Extensions (JMX) is a set of specifications defining the management of Java and through Java. The JMX Instrumentation is the optional package to the J2SE platform, that defines how Java-based or Java-enabled resources should be made manageable. The JMX Agent specification is the optional package to the J2SE platform that defines how JMX resources instrumented in compliance with JMX Instrumentation, can be seen and used by Java-based management systems and applications.

We propose to specify an IIOP based adapter for the JMX Specification to allow CORBA clients access JMX agents.

This specification will allow non-Java environments to access JMX information using IIOP. The most obvious benefit is that management console vendors with non-Java consoles can access JMX agents by using CORBA. Future CORBA management specifications will also be able to interoperate with JMX based management systems.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Any platform with a J2SE Java Virtual Machine and an ORB

2.3 What need of the Java community will be addressed by the proposed specification?

This will allow Java programmers who make management information available through JMX have there management information available to non-Java environments that are CORBA enabled. It will also allow IIOP based environments access JMX information.

2.4 Why isn't this need met by existing specifications?

Protocol adapters were outside the scope of phase 1 of the spec

2.5 Please give a short description of the underlying technology or technologies:

Taken from

The Common Object Request Broker Architecture (CORBA), is the Object Management Group's answer to the need for interoperability among the rapidly proliferating number of hardware and software products available today. Simply stated, CORB A allows applications to communicate with one another no matter where they are located or who has designed them. CORBA 1.1 was introduced in 1991 by Object Management Group (OMG) and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an Object Request Broker (ORB). CORBA 2.0 , adopted in December of 1994, defines true interoperability by specifying how ORBs from different vendors can interoperate.

The (ORB) is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.

In fielding typical client/server applications, developers use their own design or a recognized standard to define the protocol to be used between the devices. Protocol definition depends on the implementation language, network transport and a dozen other factors. ORBs simplify this process. With an ORB, the protocol is defined through the application interfaces via a single implementation language-independent specification, the IDL. And ORBs provide flexibility. They let programmers choose the most appropriate operating system, execution environment and even programming language to use for each component of a system under construction. More importantly, they allow the integration of existing components. In an ORB-based solution, developers simply model the legacy component using the same IDL they use for creating new objects, then write "wrapper" code that translates between the standardized bus and the legacy interfaces.

CORBA is a signal step on the road to object-oriented standardization and interoperability. With CORBA, users gain access to information transparently, without them having to know what software or hardware platform it resides on or where it is located on an enterprises' network. The communications heart of object-oriented systems, CORBA brings true interoperability to today's computing environment.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

To be decided; possibly

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

CORBA/IIOP 2.3.1 Specification p.html

CORBA Java language mappings html#ijlm

JMX JSR http: //

IONA has been working on an internal draft specification. This specification is not yet publicly available.

3.2 Explanation of how these items might be used as a starting point for the work.

The draft specification can serve as a starting point for the work of the Expert Group.