Creating the Interface Definition Language (IDL)

Note: This section assumes that you're using the CORBA development style to create a stateless CORBA object application (approach 1 in Developing stateless CORBA objects, rather than the RMI-IIOP approach). The RMI-IIOP approach is described in Developing an RMI-IIOP stateless CORBA application.

If you're using the CORBA development style to create a stateless CORBA object application, your first step will be to create an OMG IDL file that contains the definitions of interfaces the server implementation will support. An OMG IDL file describes the data-types, operations, and objects that the client can use to make a request, and that a server must provide for an implementation of a given object.

For information about writing IDL, see the OMG publication, Common Object Broker: Architecture and Specification, obtainable from the OMG web site at
http://www.omg.org/

You process the IDL definitions with an IDL-to-Java™ compiler (sometimes called a “parser” or “generator”). You must use a compiler provided by the server environment to generate server-side skeletons and helper classes, and a compiler provided by the client environment to generate client-side stub (sometimes called “proxy”) and helper classes. Skeleton classes appropriate for use with CICS® can be created using the IDLJ compiler provided with any IBM® Java 2 SDK. If you use a non-IBM IDLJ compiler, the resulting skeleton class may or may not be suitable for use with CICS. If in doubt, you may use the IDLJ compiler that ships with the Java SDK supplied on z/OS® that is used by CICS.

The stub or proxy classes produced by the IBM IDL compiler (IDLJ) are appropriate for use with any IBM ORB. If you use a client-side ORB from a different vendor (for example, Sun MicroSystems or Borland) you should use the IDL compiler supplied with that ORB. If you use stub classes generated for one vendor's ORB with another vendor's ORB, the results are undefined—the stubs may or may not work.

The proxies and skeletons provide the object-specific information needed for an ORB to distribute a method invocation.

Figure 1 shows how the same IDL file is used to generate different classes used by the client and the server.

Figure 1. IDL and generated code
This diagram shows the same IDL source file being processed by the server side idl compiler and the client side idl compiler to generate the skeleton and stub, as described in the text.