Documentation Contents |
Note: All command and troubleshooting instructions apply to the Java 2 Platform, Standard Edition, version 1.4 and its version of idlj only.
Before you start working with Java IDL, you need to install version 1.4 of J2SE. J2SE v.1.4 provides the Application Programming Interface (API) and Object Request Broker (ORB) needed to enable CORBA-based distributed object interaction, as well as the idlj compiler. The idlj compiler uses the IDL-to-Java language mapping to convert IDL interface definitions to corresponding Java interfaces, classes, and methods, which you can then use to implement your client and server code.
This section teaches you how to write a simple IDL interface definition and how to translate the IDL interface to Java. It also describes the purpose of each file generated by the idlj compiler.
These topics are included in this section:
module HelloApp { interface Hello { string sayHello(); oneway void shutdown(); }; };
OMG IDL is the language used to describe the interfaces that client objects call and object implementations provide. An interface definition written in OMG IDL completely defines the interface and fully specifies each operation's parameters. An OMG IDL interface provides the information needed to develop clients that use the interface's operations.
Clients are written in languages for which mappings from OMG IDL concepts have been defined. The mapping of an OMG IDL concept to a client language construct will depend on the facilities available in the client language. OMG specifies a mapping from IDL to several different programming languages, including C, C++, Smalltalk, COBOL, Ada, Lisp, Python, and Java. When mapped, each statement in OMG IDL is translated to a corresponding statement in the programming language of choice.
For example, you could use the tool idlj to map an IDL interface to Java and implement the client class. When you mapped the same IDL to C++ and implemented the server in that language, the Java client (through the Java ORB) and C++ server (through the C++ ORB) interoperate as though they were written in the same language.
The IDL for "Hello World" is extremely simple; its single interface has but two operations. You need perform only three steps:
A CORBA module is a namespace that acts as a container for related interfaces and declarations. It corresponds closely to a Java package. Each module statement in an IDL file is mapped to a Java package statement.
The module statement looks like this:
module HelloApp { // Subsequent lines of code here. };
When you compile the IDL, the module statement will generate a package statement in the Java code.
Like Java interfaces, CORBA interfaces declare the API contract an object has with other objects. Each interface statement in the IDL maps to a Java interface statement when mapped.
In your Hello.idl file, the interface statement looks like this:
module HelloApp { interface Hello // These lines { // declare the // interface }; // statement. };
When you compile the IDL, this statement will generate an interface statement in the Java code.
CORBA operations are the behavior that servers promise to perform on behalf of clients that invoke them. Each operation statement in the IDL generates a corresponding method statement in the generated Java interface.
In your Hello.idl file, the operation statement looks like this:
module HelloApp { interface Hello { string sayHello(); // This line is an operation statement. oneway void shutdown(); // This line is another }; };The interface definition for our little "Hello World" application is now complete.
The tool idlj
reads OMG IDL files and creates the
required Java files. The idlj compiler defaults to
generating only the client-side bindings. If you need both
client-side bindings and server-side skeletons (as you do for our
"Hello World" program), you must use the
-fall option when running the
idlj compiler. For more information on the IDL-to-Java compiler options,
follow the link.
New in J2SE v.1.4: The default server-side mapping generated when either the -fall or -fserver arguments are used conform to Chapter 11, Portable Object Adapter (POA) of the CORBA 2.3.1 Specification (formal/99-10-07). For more information on the POA, link to Portable Object Adapter.
The advantages of using the Portable Object Adaptor (POA) are:
idlj -fall Hello.idl
If you list the contents of the directory, you will see that a directory called HelloApp has been created and that it contains six files. Open Hello.java in your text editor. Hello.java is the signature interface and is used as the signature type in method declarations when interfaces of the specified type are used in other interfaces. It looks like this:
//Hello.java package HelloApp; /** * HelloApp/Hello.java * Generated by the IDL-to-Java compiler (portable), version "3.0" * from Hello.idl */ public interface Hello extends HelloOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { } // interface Hello
With an interface this simple, it is easy to see how the IDL statements map to the generated Java statements.
IDL Statement | Java Statement | |
---|---|---|
module HelloApp | package HelloApp; | |
interface Hello | public interface Hello |
The single surprising item is the extends statement. All CORBA objects are derived from org.omg.CORBA.Object to ensure required CORBA functionality. The required code is generated by idlj; you do not need to do any mapping yourself.
In previous versions of the idlj compiler (known as idltojava), the operations defined on the IDL interface would exist in this file as well. Starting with J2SDK v1.3.0, in conformance with the CORBA 2.3.1 Specification (formal/99-10-07), the IDL-to-Java mapping puts all of the operations defined on the IDL interface in the operations interface, HelloOperations.java. The operations interface is used in the server-side mapping and as a mechanism for providing optimized calls for co-located clients and servers. For Hello.idl, this file looks like this:
//HelloOperations.java package HelloApp; /** * HelloApp/HelloOperations.java * Generated by the IDL-to-Java compiler (portable), version "3.0" * from Hello.idl */ public interface HelloOperations { String sayHello (); void Shutdown (); } // interface HelloOperations
Because there are only two operations defined in this interface, it is easy to see how the IDL statements map to the generated Java statements.
IDL Statement | Java Statement | |
---|---|---|
string sayHello(); | String sayHello(); | |
oneway void shutdown(); | void Shutdown (); |
The idlj compiler generates a number of files. The actual number of files generated depends on the options selected when the IDL file is compiled. The generated files provide standard functionality, so you can ignore them until it is time to deploy and run your program. Under J2SE v.1.4, the files generated by the idlj compiler for Hello.idl, with the -fall command line option, are:
This abstract class is the stream-based server skeleton, providing basic CORBA functionality for the server. It extends org.omg.PortableServer.Servant, and implements the InvokeHandler interface and the HelloOperations interface. The server class, HelloServant, extends HelloPOA.
This class is the client stub, providing CORBA functionality for the client. It extends org.omg.CORBA.portable.ObjectImpl and implements the Hello.java interface.
This interface contains the Java version of our IDL interface. The Hello.java interface extends org.omg.CORBA.Object, providing standard CORBA object functionality. It also extends the HelloOperations interface and org.omg.CORBA.portable.IDLEntity.
This class provides auxiliary functionality, notably the narrow() method required to cast CORBA object references to their proper types. The Helper class is responsible for reading and writing the data type to CORBA streams, and inserting and extracting the data type from Anys. The Holder class delegates to the methods in the Helper class for reading and writing.
This final class holds a public instance member of type Hello. Whenever the IDL type is an out or an inout parameter, the Holder class is used. It provides operations for org.omg.CORBA.portable.OutputStream and org.omg.CORBA.portable.InputStream arguments, which CORBA allows, but which do not map easily to Java's semantics. The Holder class delegates to the methods in the Helper class for reading and writing. It implements org.omg.CORBA.portable.Streamable.
This interface contains the methods sayHello() and shutdown(). The IDL-to-Java mapping puts all of the operations defined on the IDL interface into this file, which is shared by both the stubs and skeletons.
When you write the IDL interface, you do all the programming required to generate all these files for your distributed application. The next steps are to implement the client and server classes. In the steps that follow, you will create the HelloClient.java client class and the HelloServer.java server class.
If you try to run idlj on the file Hello.idl and the system cannot find idlj, it is most likely not in your path. Make certain that the location of idlj (the J2SDK v.1.4 bin directory) is in your path, and try again.
Provides the basics for mapping IDL constructs to the corresponding Java statements.
Provides the complete specification for OMG Interface Definition Language. At this writing, the specification can be downloaded from http://cgi.omg.org/c gi-bin/doc?formal/99-10-07.
Next: Developing the Hello World
Server
Previous: Getting Started with Java
IDL
Java IDL Home |
Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. |
Java Technology |