A Generic Thin IIOP Client Framework for CORBA Enterprise Applications
By Jay Zou
Abstract
A generic and compact framework has been developed to simplify the development process of thin IIOP client to access legacy CORBA enterprise applications. This framework can be used by EJBs in Weblogic or in other Application Servers or as a stand along application. A list of names of CORBA enterprise server servant objects to be accessed by the IIOP clients is captured by a java.util.ArrayList, nameList. This nameList is initialized as a part of the CORBA ORB initialization process and becomes unmodifiable after the completion of ORB initialization process. An interface, ICORBABase.java, defines CORBA initialization error codes and it can be extended for a specific CORBA IIOP client. Several CORBA User Exceptions are defined based on these error codes. The base class of CORBA IIOP client is an abstract class, IIOPBaseClient, which encapsulates the CORBA server servant object and its name and handles the base exceptions. Two examples are given to illustrate the usage of this generic IIOP client framework through Weblogic EJBs. One is IOR-based CORBA IIOP client, ThinIORIIOPClient.java and another is NamingService-based CORBA IIOP client, ThinNamingServiceIIOPClient.java. All source codes, classes, ejb jar files, xml files and idl file can be found in the thiniiopclient.jar.

Main Content
Many enterprise applications have been developed before the existence of Application Server. In particular, majority of enterprise applications in Telecommunication and Financial industries were written in C/C++ and can be accessed through CORBA interfaces. For example, the Billing System of mobile cell phone can only be accessed through the given CORBA interface. The standard protocol to access CORBA server object from the Weblogic server or other application server is IIOP as defined by the CORBA specification.

In order to provide high performance and reliability, an enterprise system, i.e. the CORBA server, provides finite server objects for the clients to access. These objects may be just different instances of the same class or may be instances of different classes or the combination. These objects can be remotely located by the CORBA clients either through IOR files or Naming Service (a CORBA naming server) or other proprietary protocol such as Smart Agent in VisiBroker. Only the first two standard approaches will be given examples in this article. According to CORBA specification, a CORBA server object must have an unique name. Consequently, the server objects' name can be captured as a name list on the client side. This list of names of object in most case does not change over a very long period of time, e.g. several weeks even months. This is why this list is instantiated during the CORBA ORB initialization process. In order to prevent accidentally delete, add or modify this list during the operation, this list is made unmodifiable. Of course, this list can be modified if the ORB is corrupted and re-initialized. However, the list is NOT modified when the client refreshes the connection to the server object.

The name list of CORBA server servant objects in the real world might come from a table in the database or a properties file. Different CORBA IIOP clients may get them from different resources. Each CORBA IIOP client should extend the base NameList class. For the final IIOPClient, it can take advantage of singleton pattern to improve the performance and guarantee that all IIOPClient object instances share the same name list. Two examples are given in IORNameList.java and NamingServiceNameList.java.

In this article, the name list comes from a properties file through the GetProperties class. This singleton class caches the read properties file and allow re-load of the properties file when it becomes necessary. In a real enterprise production server, this properties class may be the singleton class not only for this package but also for all other packages. The properties may be refreshed by calling a dedicated servlet or jsp in which the re-load function will be called. It's important for a production server that its properties cannot be changed without an operation by someone has the privilage to do it.

In order to materialize the high performance and reliability of application server such as Weblogic Server, it's forbidden to re-initialize CORBA ORB during the operation because the re-initialization of ORB may cause run away of CORBA threads and related resources as well as the lost of transactions. This is why the initialization of ORB, initORB(), is separated from the initialization of CORBA connection to the server object, init() in IIOPBaseClient.java. The implementation of these methods is provided in the two examples, IOR-based IIOP client, IORIIOPClient.java, and NameingService-based IIOP client, NamingServiceIIOPClient.java. These two methods are abstract because its implementation is upon the client. In order to limit the access of these two critical methods to the final client object and its subclasses, these two methods are not part of the interface, ICORBABase.java. The examples, IIOPIORClient.java and IIOPNamingServiceClient.java, illustrate how to use the framework as a concrete CORBA IIOP client.

It is quite common that different thin iiop clients may access different legacy CORBA enterprise servers with different ORB policies and properties to initialize its ORB because each CORBA enterprise server was setup with different environments and purposes or objectives. This is the most important reason to leave the initialization of ORB to the actual iiop client. The reader might further expend this framework to handle the thin iiop client with even more layeres. For example, the ORB initialization function can be extracted out of the IIOPIORClient and into a intermediate layer. This intermediate layer will handle the ORB initialization for different environments with different policies.

Another important aspect of this framework is how to handling general CORBA exceptions and application specific exceptions in a consistent way. Normally, the application specific exceptions are extended from the application's base exception. In order to illustrate the exception handling mechanism especially the CORBA client related exceptions, the base exception is defined in CORBABaseException.java. Each exception is associated with a constant that is defined in the interface, ICORBABase.java. This constant should be the error code in a real enterprise system. Consequently, each specific CORBA IIOP client may have its own exception(s) that will be extended in the similar fashion. IORClientException.java and NamingServiceClientException.java are the examples to show how to extend this base exception.

The ThinIORIIOPClient ejb wraps the IIOPIORClient so the life cycle of these objects can be better handled by the Application Server such as the Weblogic Server. Some Application Servers such as Inprise Application Server use IIOP as their native protocol while Weblogic Server uses T3 as its native protocol. It's a matter of taking proprietary but better optimized for the Weblogic specific applications verse portability cross different Application Servers. It's OK to use T3 as the protocol for the EJBs that wrap IIOP clients.

If the CORBA enterprise server supports CORBA transaction service such as BEA's Tuxedo Server, the EJBs can extend the transaction boundary from Weblogic Server to the external CORBA enterprise server. Unfortunately, most CORBA enterprise server do not provide CORBA transaction service. When the CORBA IIOP client is in a different enterprise than that of the CORBA server, it's quite common that the CORBA enterprise server does not supports the CORBA transaction service even though the CORBA enterprise server itself may provide CORBA transaction service. This is because different enterprises may have different responsibilities. The totally decoupled transaction is much easier to manage for both sides especially on the CORBA server side. This is the same fact that has been observed for the application using the web services.

In general, the security credential of EJBs cannot be passed to the CORBA enterprise server because most of CORBA enterprise servers use proprietary security credentials. The JCA provides translation for that purpose. I may present it in my future article regarding how to implement a JCA compliant adaptor for legacy CORBA enterprise server.

The ThinNamingServiceIIOPClient ejb wraps the IIOPNamingServiceClient in the same fashion. The only difference is that the IIOPNamingServiceClient is initialized during ejb creation process instead of IIOPIORClient.

Both EJBs can be accessed from their clients that can be inside of the application server or outside of the application server. As mentioned in the above, the thin IIOP clients can be instantiated as a stand along classes without using ejbs.

Source Code
All source codes (15 java classes), classes, ejb jars (two ejbs), xml files, idl file and generated classes are include in the same jar file, thiniiopclient.jar, which is about 145 KB. All classes are compiled under JBuilder6 using VisiBroker as the CORBA ORB.

package:
com.vmu.corba.iiopclient

idl generated class:
14 java classes

Author Biography
Jay Zou
Sr. Software Developer
5 years of J2EE enterprise application development
10 years of enterprise C/C++/Java application development