Java Reference
In-Depth Information
It's a tribute to the RMI architecture team that they were able to transparently swap out JRMP for CORBA's IIOP.
There are no changes to developer code at all; it's all done behind the scenes. You can convert an existing RMI
application to IIOP without changing a line of code.
Together, these three technologies compose the CORBA functionality in Java. Actually, Java developers use very
few of the classes in the packages when writing code. For JavaIDL, the ORB class is the one that is used in the
majority of applications. For CosNaming, there are about half a dozen classes and interfaces which are commonly
used. And RMI-IIOP solutions rarely use any of the classes defined in the packages.
So what about all the CORBA classes and interfaces? What happens to them? The CORBA APIs have a total of
143 classes that provide support services. That is, the classes are used by code that is generated by associated
CORBA utilities, such as
idl2java
.
Pattern Use
The CORBA APIs in Java implement a few basic design patterns.
Singleton
(see page 34): The ORB is supposed to provide a single point of contact for CORBA communication in
a JVM. This means that there can only be one instance of an ORB in any running Java application. To satisfy this
requirement, the API uses the Singleton pattern. The ORB class in the
org.omg.CORBA
package provides an
implementation of the Singleton pattern. Its
init
method provides a single-instance ORB resource for use in Java
applications.
Factory Method
(see page 21): The ORB class provides many create methods, since it is the main resource
provider for CORBA solutions. A number of these methods satisfy the requirements for the Factory pattern,
producing objects that can be flexibly specified during the creation process.
