Developing stateless CORBA objects

Stateless CORBA objects are Java™ server applications that communicate with a client application using the IIOP protocol. No state is maintained in object attributes between successive client invocations of remote methods; state is initialized at the start of each remote method call and referenced by explicit parameters.
Note: By a remote method we mean a method that may be called from a remote client. That is, a public method that is exposed as part of one of the object's (potentially multiple) remote interfaces, or declared in the IDL for the object; rather than an internal method that cannot be accessed from a remote client.

In the server programming model, each method is a subroutine. The parameters passed allow you to establish temporary state from any existing databases or applications, to perform business logic, to store data in the existing databases or applications, to return results when the subroutine returns, or to throw an exception. The remote methods of a stateless CORBA object—that is, those that may be called by a remote client—may call each other locally or call non-remote methods without the object's temporary state being lost. The temporary state is only discarded at the end of the client-initiated remote method request, when the JVM is reset.

You can develop a stateless CORBA application using either of two different approaches:
  1. Use the typical CORBA development style, whereby an application interface is defined in Interface Definition Language (IDL) and then the application is coded to that interface. This approach is described in the sections that follow.
  2. Use the typical Java development style, whereby a Java Remote Method Invocation (RMI) application is developed and IDL is optionally generated later. This approach is known as RMI-IIOP. It is described in Developing an RMI-IIOP stateless CORBA application.
To develop a stateless CORBA object using the first (CORBA-style) approach, you need to perform the following steps:
  1. Use the Interface Definition Language (IDL) to define the object's interfaces and operations.
  2. Run the IDL-to-Java compiler (IDLJ) against the IDL to generate stub and skeleton classes for the object.
  3. Write a client application that makes calls to the server using the generated stub class.
  4. Write a server application (the stateless CORBA object) that extends the generated base skeleton class.
  5. Compile and package the client and server applications.
  6. Define CICS® resources for the server and add the server application's JAR file to the shareable application class path in the JVM properties file for the JVM that the application uses.
To develop a stateless CORBA object using the second (Java-style) approach, you need to perform the following steps:
  1. Write a remote interface for the server application (the stateless CORBA object).
  2. Write a client application that makes calls to the server using this remote interface.
  3. Write a server application that implements the remote interface.
  4. Compile the client and server applications.
  5. Run the Java RMI compiler (RMIC) against the remote interface and server application to generate stub and tie classes for the object.
  6. Package the client and server applications.
  7. Define CICS resources for the server and add the server application's JAR file to the shareable application class path in the JVM properties file for the JVM that the application uses.
  8. Optionally, create IDL for the application for use by non-Java CORBA clients.

There are benefits and drawbacks to each of the two approaches. One of the main differences is that the CORBA approach requires the stateless CORBA object to extend a generated base class. Given that Java supports only a single inheritance hierarchy, this means that you cannot make your stateless CORBA object extend a class of your choice. The RMI-IIOP approach allows you to use an inheritance hierarchy of your choice for the stateless CORBA object, because the object only has to implement a specific interface.

The CORBA interface and operation names are mapped to corresponding Java implementations. You can develop server implementations that use the CICS Java classes (JCICS) to access CICS services. See the JCICS Class Reference for details of the JCICS classes, and Java programming using JCICS for an explanation of how to develop server applications using them.

The JCICS classes are fully documented in JAVADOC html that is generated from the class definitions. This is available through the CICS Information Center, in the JCICS Class Reference.