|
|
This is a document that attempts to answer many of the questions you may have about Java IDL. We will continue to update this document with your questions as we receive them. If you do not find your question answered here, send email to javaidl@eng.sun.com.
What are the command line options for tnameserv, the Naming Service?
Can I use the Java IDL ORB with a C++ CORBA server? (interoperability)
What is the difference between the idltojava compiler and the idlj compiler?
What are my options for developing CORBA applications using Java?
You can download the idltojava compiler for JDK 1.2 from http://developer.java.sun.com/developer/earlyAccess/jdk12/idltojava.html. However, I highly recommend that you consider downloading J2SDK 1.3, which includes the latest version of the IDL-to-Java compiler, idlj. The idlj compiler is downloaded as part of the JavaTM 2 Platform, Standard Edition, v1.3 installation. When installed, idlj will be located in the bin directory.
The JavaTM 2 Platform, Standard Edition, v1.3, also includes RMI-IIOP, a technology that integrates Java RMI (Remote Method Invocation) and Java IDL. As a result, Java IDL now uses a new version of the IDL-to-Java compiler. This compiler supports new CORBA-standard features required for RMI-IIOP.
RMI-IIOP supersedes Java IDL for most purposes, by enabling you to write CORBA-compliant interfaces directly in Java rather than in the OMG-specified IDL (Interface Definition Language) used with Java IDL. For details, see the RMI-IIOP documentation.
Many of the problems we have seen related to running the idltojava compiler can be fixed by using the new IDL-to-Java compiler, idlj, available with the download of the JavaTM 2 Platform, Standard Edition, v1.3.
The idltojava compiler in JDK 1.2 is hard-coded to use a default preprocessor. On Windows machines, it uses the MicroSoft Visual C++ preprocessor. You can change the preprocessor that the idltojava compiler uses by setting two environment variables: CPP and CPARGS. Set CPP to the full pathname of the preprocessor you want to use. Set CPARGS to the complete list of arguments to be passed to the preprocessor. You can also turn off the preprocessor by adding -fno-cpp to the idltojava command line.
More information is available in the idltojava reference page that is downloaded with the idltojava compiler.
We recommend upgrading to the latest version of the IDL to Java compiler, idlj. Version 1.3 of the Java 2 SDK, Standard Edition, includes a new version of Java IDL which is 100% pure Java, so no preprocessor is necessary. The new IDL-to-Java compiler, idlj, is included with the download of J2SE v.1.3. For information on the enhancements to Java IDL that are supported in v.1.3, follow the link to Java(TM) IDL: Changes between JDK 1.2 and J2SDK, SE, v1.3. To download version 1.3 of the Java 2 SDK, Standard Edition, link to http://java.sun.com/j2se/1.3/index.html. To learn more about the new version of Java IDL, link to the Java IDL page for J2SE v1.3.
The most common reason for this error when running HelloServer (and also HelloClient) from the Java IDL tutorial is when a space is added between quotation marks in the following line of code:
NameComponent nc = new NameComponent("Hello", "");There should be no spaces between the quotation marks. Without spaces, this value is passed as a null. With a space between the quotations, a space character is passed.
No, it does not. If you need an events service, you can implement one, purchase one off the shelf, or search for one freely available to start things off with.
No command line options are necessary for running tnameserv, however, it is recommended that you specify a port for the name server to run on , as follows:
tnameserv -ORBInitialPort nameserverport
Or, from an MS-DOS system prompt (Windows), enter:
start tnameserv -ORBInitialPort nameserverport
Note that nameserverport is the port on which you want the name server to run. If you do not specify this, port 900 will be chosen by default. Also note that using Solaris software, you must become root to start a process on a port under 1024. For this reason, we recommend that you use a port number greater than or equal to 1024.
More description of the Naming Service is available on the Web at http://java.sun.com/j2se/1.3/docs/guide/idl/jidlNaming.html.
You need to use the -ORBInitialHost <Host Name where Name Service is Launched> option when starting the client and/or server (whichever is not running on the same machine as the name server). This way the client and server know where to find the Name Service. As example can be found on the Web at http://java.sun.com/j2se/1.3/docs/guide/idl/tutorial/jidl2machines.html.
With the idlj compiler in J2SDK 1.3, we are CORBA 2.3 compliant in some areas but not in others. In J2SDK 1.4, we will be more compliant with CORBA 2.3. RMI-IIOP also mostly comforms to CORBA/IIOP 2.3.1, with the exception that Valuetypes are encoded on a GIOP 1.0 stream although they were defined for GIOP 1.2. The J2SE 1.4 and J2EE 1.3 ORB platforms will have GIOP 1.2 support along the lines of compliance with CORBA 2.3.
The Java IDL ORB is an ORB completely written in Java. The idlj compiler generates code that follows the conventions definded in the IDL to Java Language Mapping Specification. The Java ORB does not provide a compiler that generates code in any languages other than the Java platform. If you want to test interoperability between the Java ORB and an ORB written in another language (such as C++), you will need to find an ORB written in that language and a compiler that conforms to the specific language mapping. Language mapping specifications are available from the Object Management Group Web site at http://www.omg.org/technology/documents/formal/corba_language_mapping_specifica.htm. To find a vendor that provides a CORBA ORB and a language mapping compiler in the language you are working with, search the Web for "C++ CORBA ORB", or equivalent.Although it is true in theory that ORBs written in different languages should be able to talk to each other, we haven't tested the interoperability of the Java ORB with other vendor's ORBs.
The following list provides a summary of changes that occurred in Java IDL between the release of JDK 1.2 and J2SE v.1.3. For more detail, read Java IDL: Changes between JDK 1.2 and J2SDK, Standard Edition, v1.3.
New IDL-to-Java compiler, idlj, is 100% Pure Java, so no preprocessor is necessary when compiling IDL files.
More IDL-to-Java compiler options. See the reference documentation for the IDL-to-Java compiler for a list of options.
Mapping for interfaces is supported. In accordance with the OMG IDL to Java Language Mapping Specification, Section 1.12, Mapping for Interfaces, the signature interface no longer contains the method that corresponds to the interface defined in the IDL file. Instead, the operations interface, <interface>Operations.java, is generated in the <module> subdirectory and contains the methods defined by the interface.
Support for Java mapping to IDL value types.
CORBA technology as part of the Java 2 platform consists of an Object Request Broker (ORB) written in Java (with a small bit of native code), the RMI programming model, and the IDL programming model.
The "magic" that gives us the cross-language, cross-vendor interoperability is the Internet InterORB Protocol, or IIOP. IIOP can be a transport protocol for distributed applications written in either IDL or Java RMI. IIOP allows distributed objects to conform to OMG's CORBA specification.
When using the IDL programming model, the interface is everything! It defines the points of entry that can be called from a remote process, such as the types of arguments the called procedure will accept, or the value/output parameter of information returned. Using IDL, the programmer can make the entry points and datatypes that pass between communicating processes act like a standard language.
CORBA is a language-neutral system in which the argument values or return values are limited to what can be represented in the involved implementaton languages. In CORBA, object orienation is limited only to objects that can be passed by reference (the object code itself cannot be passed from machine-to-machine) or are predefined in the overall framework. Passed and returned types must be those declared in the interface.
With RMI, the IDL and the implementation language are the same thing, so you don't have to worry about mapping from one to the other. Language-level objects (the code itself) can be passed from one process to the next. Values can be returned by their actual type, not the declared type. Or, you can compile the interfaces to generate IIOP-compliant stubs and skeletons to talk to objects written on other machines in other CORBA-compliant languages.
This is a fundamental question and it's important to understand the distinction between these two ways of integrating the Java programming language with CORBA.
Java IDL is for CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA Interface Definition Language (IDL). This is "business as usual" CORBA programming, supporting Java in exactly the same way as other languages like C++ or COBOL.
RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) is for Java programmers who want to program to the RMI interfaces, but use IIOP as the underlying transport. RMI-IIOP provides interoperability with other CORBA objects implemented in various languages - but only if all the remote interfaces are originally defined as Java RMI interfaces. It is of particular interest to programmers using Enterprise JavaBeans (EJB), since the remote object model for EJBs is RMI-based.
There are several scenarios that will define how you will want to create distributed CORBA applications. Here are some of them:
Java IDL! If you have been developing CORBA applications using IDL for some time, you will probably want to stay in this environment. Create the interfaces using IDL, and define the client and server applications using the Java programming language to take advantage of its "Write Once, Run AnywhereTM" portability, its highly productive implementation environment, and its very robust platform.
RMI-JRMP! If all of your applications are written in the Java programming language, you will probably want to use Java RMI to enable communication between Java objects on different virtual machines and different physical machines. Using Java RMI without its IIOP option leverages its strengths of code portability, security, and garbage collection.
RMI-IIOP! If you writing most of your new applications using the Java programming language, but need to maintain legacy applications written in other programming languages as well, you will probably want to use Java RMI with its IIOP compiler option.
|
Copyr ight © 2000 Sun Microsystems, Inc. All Rights Reserved. Send questions or comments to: JavaIDL@eng.sun.com. |
|
