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.
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.