Using CORBA and Java IDL

• About CORBA

• Αβ ο υ τ ϑαϖ α Ι∆Λ

• ΧΟ Ρ Β Α Χο ν χ ε π τ σ ιν α Νυ τ σ η ε λ λ

• ∆εφ ι ν ι ν γ αν δ Ιµπλ ε µ ε ν τ ι ν γ ΧΟ Ρ Β Α
Οβ ϕ ε χ τ σ

• Χλ ι ε ν τ Ιµπλ ε µ ε ν τ α τ ι ο ν

• ϑαϖ α Ι∆Λ Τρα ν σ ι ε ν τ Να µ ε Σερϖ ε ρ

About CORBA

CORBA (Common Object Request Broker Architecture) is the standard distributed object
architecture developed by the Object Management Group (OMG) consortium. Since 1989
the mission of the OMG has been the specification of an architecture for an open
software bus, or Object Request Broker (ORB), on which object components written by
different vendors can interoperate across networks and operating systems. This standard
allows CORBA objects to invoke one another without knowing where the objects they
access reside or in what language the requested objects are implemented. The OMG-
specified Interface Definition Language (IDL) is used to define the interfaces to CORBA
objects.
CORBA objects differ from typical programming language objects in these ways:

• CORBA objects can be located anywhere on a network.

• CORBA objects can interoperate with objects on other platforms.

• CORBA objects can be written in any programming language for which there is a
mapping from OMG IDL to that language. (Mappings currently specified include
Java, C++, C, Smalltalk, COBOL, and Ada.)
The Java 2 Platform, Standard Edition, v1.3, provides a CORBA 2.3.1-compliant Object
Request Broker (ORB) and two CORBA programming models that utilize the Java
CORBA ORB and Internet InterORB Protocol (IIOP). The two programming models are
the RMI programming model, or RMI-IIOP, and the IDL programming model, or Java
IDL. For more information on these programming models, read CORBA Technology and
the Java Platform.

Should I use RMI-IIOP or Java IDL?

This is a fundamental question and it's important to understand the distinction between
these two ways of integrating the Java programming language with CORBA.
RMI-IIOP is for Java programmers who want to program to the RMI interfaces, but use
IIOP as the underlying transport. RMI-IIOP provides interoperability with other CORBA
objects implemented in various languages - but only if all the remote interfaces are
originally defined as Java RMI interfaces. It is of particular interest to programmers using
Enterprise JavaBeans (EJB), since the remote object model for EJBs is RMI-based.
Java IDL is for CORBA programmers who want to program in the Java programming
language based on interfaces defined in CORBA IDL. This is "business as usual"
CORBA programming, supporting Java in exactly the same way as other languages like
C++ or COBOL.
Both Java IDL and RMI-IIOP include the full functionality of a CORBA Object Request
Broker (ORB). The good news for developers is that the JavaTM Standard Edition, v1.2
and higher includes a fully-functional ORB that is available in every deployment of the
Java 2 Platform, Standard and Enterprise Editions. Now you can write Java CORBA code
without having to license any other software!

About RMI-IIOP

Java RMI-IIOP is an Object Request Broker and a compiler, rmic -iiop, that generates
IIOP stub and tie classes. With RMI-IIOP, developers can write remote interfaces in the
Java programming language and implement them simply using Java technology and the
Java RMI APIs. These interfaces can be implemented in any other language that is
supported by an OMG mapping and a vendor supplied ORB for that language. Similarly,
clients can be written in other languages using IDL derived from the remote Java
technology-based interfaces. Using RMI-IIOP, objects can be passed both by reference
and by value over IIOP.

About Java IDL

Java IDL is an Object Request Broker and a compiler, idlj, that maps IDL to the Java
programming language. Java IDL can be used to define, implement, and access CORBA
objects from the Java programming language. Java IDL is compliant with the
CORBA/IIOP 2.2 Specification and the Java Language Mapping to OMG IDL
(formal/99-07-59).
The Java IDL ORB supports transient CORBA objects - objects whose lifetimes are
limited by their server process's lifetime. Java IDL also provides a transient name server
to organize objects into a tree-directory structure. The name server is compliant with the
Naming Service Specification. Transient objects and the name server are discussed later
in this page.
No interface repository is provided as part of Java IDL. An interface repository is not
required because under normal circumstances, clients have access to generated stub files.

CORBA Concepts in a Nutshell

The concepts introduced in this section are more completely discussed in the
CORBA/IIOP Specification.
The diagram below shows a method request sent from a client to a CORBA object
implementation in a server. A client is any code (perhaps itself a CORBA object) that
invokes a method on a CORBA object. The servant is an instance of the object
implementation - the actual code and data that implements the CORBA object.
FPRIVATE "TYPE=PICT;ALT=[requestpath image]"

The client of a CORBA object has an object reference for the object and the client uses
this object reference to issue method requests. If the server object is remote, the object
reference points to a stub function, which uses the ORB machinery to forward
invocations to the server object. The stub code uses the ORB to identify the machine that
runs the server object and asks that machine's ORB for a connection to the object's server.
When the stub code has the connection, it sends the object reference and parameters to
the skeleton code linked to the destination object's implementation. The skeleton code
transforms the call and parameters into the required implementation-specific format and
calls the object. Any results or exceptions are returned along the same path.
The client has no knowledge of the CORBA object's location, implementation details, nor
which ORB is used to access the object. Different ORBs communicate via the OMG-
specified Internet InterORB Protocol (IIOP).
A client may only invoke methods that are specified in the CORBA object's interface. A
CORBA object's interface is defined using the OMG Interface Definition Language
(IDL). An interface defines an object type and specifies a set of named methods and
parameters, as well as the exception types that these methods may return. An IDL
compiler such as idlj translates the CORBA object definitions into a specific
programming language according to the appropriate OMG language mapping. Thus, the
idlj compiler translates IDL defintions into Java constructs according to the IDL-Java
language mapping.
The stub and skeleton files are generated by the idlj compiler for each object type. Stub
files present the client with access to IDL-defined methods in the client programming
language. The server skeleton files glue the object implementation to the ORB runtime.
The ORB uses the skeletons to dispatch methods to the object implementation instances
(servants).

Defining and Implementing CORBA Objects

The goal in CORBA object development is the creation and registration of an object
server, or simply server. A server is a program which contains the implementation of one
or more object types and which has been registered with the ORB. For example, you
might develop a desktop publishing server which implements a "Document" object type,
a "Paragraph" object type, and other related object types.

CORBA Object Interfaces

All CORBA objects support an IDL interface; the IDL interface defines an object type.
An interface can inherit from one or more other interfaces. IDL syntax is very similar to
that of Java or C++, and an IDL file is functionally the CORBA language-independent
analog to a C++ header file. IDL is mapped into each programming language to provide
access to object interfaces from that language. With Java IDL, these IDL interfaces can
be translated to Java using the idlj compiler. For each IDL interface, idlj generates a
Java interface and the other .java files needed, including a client stub and a server
skeleton.
An IDL interface declares a set of client accessible operations, exceptions, and typed
attributes (values). Each operation has a signature that defines its name, parameters,
result, and exceptions. A simple IDL interface that describes the classic "Hello World"
program, follows.
module HelloApp
{
interface Hello
{
string sayHello();
};
};
An operation may raise an exception when an error condition arises. The type of the
exception indicates the kind of error that was encountered. Clients must be prepared to
handle defined exceptions and CORBA standard exceptions for each operation in
addition to normal results.

Java Language-based Implementation

Once the IDL interfaces have been defined and the idlj compiler run on the .idl file,
.java files containing the method implementations may be written. The .java
implementation files are then compiled and linked with the idlj -generated .java files
and the ORB library to create an object server.
An object implementation defines the behavior for all the operations and attributes of the
interface it supports. There may be multiple implementations of an interface, each
designed to emphasize a specific time and space trade-off, for example. The
implementation defines the behavior of the interface and object creation/destruction.
Since only servers can create new CORBA objects, a factory object interface should be
defined and implemented for each object type. For example, if Document is an object
type, a DocumentFactory object type with a create method should be defined and
implemented as part of the server. (Note that "create" is not reserved; any method name
may be used.) The implementation of the create method can then use new to create the
object. For example:
DocumentServant document = new DocumentServant():
orb.connect(document);
A destroy method may be defined and implemented on Document; or, the object may be
intended to persist indefinitely. (Again, "destroy" is not reserved and any name may be
used.)
The Java IDL ORB supports transient objects only - objects whose lifetime is limited by
the server process lifetime. Although a transient object dissapears when its server process
stops running, the object may be implemented to store its state in a file and to re-initialize
itself from this file at creation time.

Client Implementation

Client code is linked with idlj-generated .java files and the ORB library. Examples of
application and applet clients are provided in the Hello World example.
Clients may only create CORBA objects via the published factory interfaces that the
server provides. Likewise, a client may only delete a CORBA object if that object
publishes a destruction method. Since a CORBA object may be shared by many clients
around a network, only the object server is in a position to know when the object has
become garbage.
The client code's only way of issuing method requests on a CORBA object is via the
object's object reference. The object reference is an opaque structure which identifies a
CORBA object's host machine, the port on which the host server is listening for requests,
and a pointer to the specific object in the process. Because Java IDL supports only
transient objects, this object reference becomes invalid if the server process has stopped
and restarted.
Clients typically obtain object references in the following ways:

• from a factory object. For example, the client could invoke a create method on
DocumentFactory object in order to create a new Document. The
 DocumentFactory create method would return an object refererence for Document
to the client.

• from the nameservice. For example, the client could obtain an object reference for
the DocumentFactory by issuing a request on the nameservice.

• From a string that was specially created from an object reference

Once an object reference is obtained, the client must narrow it to the appropriate type.
IDL supports inheritance; the root of its hierarchy is Object in IDL,
org.omg.CORBA.Object in Java. (org.omg.CORBA.Object is, of course, a subclass of
java.lang.Object.) Some operations, notably name lookup and unstringifying, return
an org.omg.CORBA.Object, which you narrow (using a helper class generated by the
idlj compiler) to the derived type you want the object to be. CORBA objects must be
explicitly narrowed because the Java runtime cannot always know the exact type of a
CORBA object.

Java IDL Transient Name Server

The Java IDL Transient Nameservice is an object server provided with Java IDL. Use
tnameserv at the command line prompt to start the Name Server. This object server
conforms to the standard object implementation and invocation techniques described in
the previous sections of this page.
The Name Server stores object references by name in a tree structure similar to a file
directory. A client may lookup or resolve object references by name. Because the Name
Server is an ordinary Java IDL transient server, the entire directory structure of names is
lost each time tnameserv stops running.

See Naming Service for more information.

November 29, 1999 Manual.nw 1

CORBA - the Common Object Request Broker Architecture - is a powerful framework which allows
software
components to be used together. What makes it exciting and powerful is that the different components can
be located
in different processes and on different machines and can be implemented in different languages, such as
JavaTM, C
and C++. The different CORBA objects can be treated identically to local objects making their use
transparent.
This is a very powerful mechanism akin to the UNIX pipe framework. It allows specialized tools to be
developed
and linked with other tools to perform tasks. It offers great possibilities for software in general, and
definitely allows
statistical environments to share services and become less monolothic and more adaptable.
CORBA appears complicated but this is due to the generality it offers as well as the fact that it typically
made
available in newer languages that we do not use in our daily work - namely, C++ and JavaTM. The goal of
the tools
described here is to provide access to and the functionality of CORBA within the interpreted languages we
use to do
data analysis and research. These include S, R, Matlab, etc.
The functions presented here are not intended to form the final end-user API. Instead, they are the
primitives that
others can build upon in the interactive language to provide high-level access to the CORBA environment.
However,
they are already reasonably high-level and can be used immediately.
Future plans involve accessing other CORBA services (e.g. the property service, etc.) and implementing a
version
of the For() function which distributes and manages tasks with fault tolerance.
1 CORBA Basic: IDL
The heart of CORBA is the communication between client and server in the form of attributes and
operations. In order
for this to work, both client and server must agree on what the server can do and how to call it. The server
declares
its list of accessible attributes and operations as an Interface. This is specified using the Interface Definition
Language
(IDL). This is not used to implement the server (or client), just describe its capabilities.
A simple example is given below to illustrate the basic nature of IDL. Here we describe the facilities
available from
a Matrix object. (This is not intended to be complete. We will see how to extend this naturally later in the
document.)
interface Matrix {
long nrow();
long ncol();
double data(in long i, in long j);
};
Note that each parameter has a qualifier that indicates whether the argument is either in, out or inout. An
out
parameter is used to transmit data from the server to the client. An inout argument is used to pass
information from
the client to the server as a regular argument (in) but also is used to communicate values back to the client
from the
server. The out arguments are used much like passing pointers in C so they callee can modify the contents
of the
object. It allows more than one object to returned, avoiding putting them into a container structure and
making this the
return type.
An IDL description of a server’s capabilities is all that is needed to define the communication between a
server
and its clients. Now we implement these. Compilation of the IDL to a suitable target language is the usual
manner of
implementing either a server or client. Most CORBA implementations provide an IDL to C++ compiler.
Others also
offer IDL to JavaTM. Since there are no IDL compilers for interactive languages such as S, R, etc., we have
to create
another mechanism. Fortunately, CORBA provides one which is termed dynamic.
The idea for the dynamic CORBA interfaces is that we store the IDL description of a server in an Interface
Repository (IR). When a client attempts to invoke a method of a server, a generic mechanism fetches the
description
of the operation from the IRand puts the local arguments into that request in some manner and sends the
request to the
server. For its part, the server cannot tell how the client generated the request. It responds and puts the
return value(s)
into the request and transfers it back to the client. There, the generic mechanism unwraps the return
value(s).
This generic mechanism provides direct access to the CORBA facilities from within a language without the
need
for compilation of client stubs from the IDL and their compilation in the native language (e.g. C++). We
can use
a second generic mechanism to allow user-level objects (e.g. an S matrix) to be offered as a CORBA server
that
other clients can access. Again, we wish to avoid compilation and to allow the implementation be done in
the userlevel
language rather than the lower-level native language. This server mechanism creates a proxy CORBA
object
that contains the real user-level object. The proxy object declares that it can service requests from a
particular IDL
November 29, 1999 Manual.nw 2
interface. When it receives such a request, it converts the arguments and passes the call to an the
appropriate user-level
function (e.g. nrow() in our example above). when this has completed, it puts the return value back into the
request
and returns it to the caller.
See adding operations and attributes dynamically.