 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 70: IIOP Protocol Adapter for JMXTM Specification
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. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: This specification will establish an IIOP based adapter for the JMXTM specification to allow CORBA clients access JMX agents. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn 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: ben.beazley@iona.com.au 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: kevin.curley@iona.com 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 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 http://www.omg.org/corba/whatiscorba.html 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 javax.management.corba 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?No 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 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 http://www.omg.org/corba/corbaiio p.html CORBA Java language mappings http://www.omg.org/corba/clchpter. html#ijlm JMX JSR http: //java.sun.com/aboutJava/communityprocess/jsr/jsr_003_jmx.html 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. |
|||||||||||||||||||||||||||||||||||||||||
