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:
- 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.
- 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:
- Use the Interface Definition Language (IDL) to define the object's interfaces and operations.
- Run the IDL-to-Java compiler (IDLJ) against the IDL to generate stub and
skeleton classes for the object.
- Write a client application that makes calls to the server using the
generated stub class.
- Write a server application (the stateless CORBA object) that extends
the generated base skeleton class.
- Compile and package the client and server applications.
- 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:
- Write a remote interface for the server application (the stateless CORBA
object).
- Write a client application that makes calls to the server using this remote
interface.
- Write a server application that implements the remote interface.
- Compile the client and server applications.
- Run the Java RMI compiler (RMIC) against the remote interface and server
application to generate stub and tie classes for the object.
- Package the client and server applications.
- 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.
- 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.