Developing an IIOP server program

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.

The server program can be developed on any platform that supports Java™. For example, an NT workstation, AIX® or the UNIX System Services environment of z/OS®. The following steps are required:

  1. Write the IDL definition of the interfaces and operations that form your application.
  2. Compile the IDL file to generate CORBA skeleton and helper classes, using the IDL compiler idlj command which is part of the Java 2 SDK.
    Note:
    1. You must use an IBM®-supplied IDL-to-Java compiler to do this. The IDL-to-Java compiler supplied with the Sun version of the Java 2 SDK may not be 100% compatible with the IBM ORB.
    2. The idlj command is not supplied as part of the Java Runtime Environment (JRE); you will need a full SDK installed on your machine before this will work.
    The IDL compiler can be invoked as follows:
    idlj [options] <idl file>
    Where <idl file> is the name of the file containing the IDL definitions, and [options] is any combination of the following options, which may appear in any order. <idl file> is required and must appear last. At least -f must be specified.
    For example:
     idlj -v -fall myidl.idl 
    If you are using a version of the IDL compiler from Java 1.4, you must also specify the -oldImplBase option to ensure that a CICS-compatible implementation is generated. If you do not use this option, the generated implementation will use the Portable Object Adapter (POA), which is not supported in CICS. For example:
     idlj -v -fall -oldImplBase myidl.idl
    -d<symbol>
    The equivalent of the following line in an IDL file: #define <symbol>
    -emitAll
    Emit all types, including those found in #included files.
    -f<side>
    Define the bindings to emit. <side> can be:
    client
    not applicable to CICS®.
    server
    does not generate sufficient classes for normal use.
    all
    emits all bindings.
    serverTIE
    not supported in CICS.
    allTIE
    not supported in CICS
    If this option is not specified, then -fclient is assumed. In most cases you should use -fall.
    -i<include path>
    Add another directory. By default, the current directory is scanned for included files.
    -keep
    If a file to be generated already exists, do not overwrite it. By default it is overwritten.
    -oldImplBase
    Required if you are using the version of the IDLJ compiler supplied with Java 1.4 SDK. If you omit this option, IDLJ generates code which uses the Portable Object Adapter (POA). The POA is not supported under CICS.
    -pkgPrefix <t> <pkg>
    Make sure that wherever the type or module <t> is encountered, it resides within <pkg> in all generated files. <t> is a fully qualified Java-style name.
    -v
    Verbose mode.
  3. Write your server implementation in Java code. The idl compiler will generate an abstract class called_interfacenameImplBase. Your program must extend this. If objects of this type are to be created by the Generic Factory, your implementation class must be called _interfacenameImpl. If you do not use this naming convention, the GenericFactory will not be able to create references to your CORBA object. For example:
    public class _BankAccountImpl extends _BankAccountImplBase

    Your implementation class may make use of the JCICS API to interact with traditional CICS services.

  4. Compile your program and the output from step 2, using the javac compiler or an equivalent, such as VisualAge® for Java. Ensure that the location of the output files is added to the end of the CICS shared application classpath, ibm.jvm.shareable.application.class.path, in the JVM properties file.