Oracle8i's ORB does the trick

Develop scalable and secure Java CORBA applications with Oracle8i

1 2 Page 2
Page 2 of 2
package helloServer;
import hello.*;
public class HelloImpl extends _HelloImplBase {
   public String helloWorld() {
      String v = System.getProperty("oracle.server.version");
      return "Hello client, your javavm version is " + v + ".";

The server-object implementation employs the helloServer package, as seen above. The helloWorld() method simply returns a string that tells what version of Oracle the server is using.

Client implementation

Now let's write a simple client to look up the Hello object in the name server and invoke the helloWorld() method on it (see

import hello.Hello;
import oracle.aurora.jndi.sess_iiop.ServiceCtx;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.util.Hashtable;
public class Client
  public static void main (String[] args) throws Exception {
    if (args.length != 4) {
      System.out.println("usage: Client serviceURL objectName user password");
    String serviceURL = args [0];
    String objectName = args [1];
    String user = args [2];
    String password = args [3];
    Hashtable env = new Hashtable();
    env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
    env.put(Context.SECURITY_PRINCIPAL, user);
    env.put(Context.SECURITY_CREDENTIALS, password);
    Context ic = new InitialContext(env);
    Hello hello = (Hello) ic.lookup(serviceURL + objectName);

The above client first sets up the properties for the JNDI lookup. URL_PKG_PREFIXES simply indicates where the SPI drivers are available for the URL prefix that will be passed to the lookup() method. In this case, it is called sess_iiop, as will be evident below. SECURITY_PRINCIPAL is set as the user name to connect to the database, while SECURITY_CREDENTIALS is set as the corresponding password. Next, we set the authentication mechanism as NON_SSL_LOGIN, meaning an explicit login object mechanism (this uses a challenge/response protocol, as you will recall) using a non-SSL connection. The client then simply creates a JNDI initial context and does a lookup passing the object name. The JNDI lookup returns the already narrowed-down object to the given type (in this case Hello, as explained above), and the client simply invokes the helloWorld() method. (For details on various other login mechanisms and JNDI environment properties, see Resources for the Oracle8i documentation.)

Compile it

Now that we have written all the necessary code, we should compile all these files, including the code generated by the IDL compiler. To that end, it's convenient to put all these class files in a jar file -- server.jar. Be aware that Oracle8i 8.1.6 supports both JDK 1.2 and JDK 1.1 on the client side.

Load the classes into the database

As explained earlier, since the server code runs inside the database, the Java classes need to be uploaded into the database. To accomplish this, we turn to the loadjava tool. At the command line, type:

loadjava  -oci8 -u scott/tiger -v -r -f  server.jar

In the above command, -oci8 indicates we'll use the OCI driver (as opposed to thin JDBC) while talking to the server. Scott/tiger is the username and password (so the classes will now load into Scott's schema.) Next, -v indicates verbose mode, and -r indicates the tool should resolve all the classes being loaded for their transitive closure -- useful for early diagnostics in case of errors such as missing classes. -f indicates that loadjava should replace the classes if they already exist. server.jar represents the resulting file with all the compiled classes.

Publish the object to the name service

The next step is to publish the Hello object to the name service, so that clients doing JNDI lookups can discover it. We do this with a tool called publish, as seen below:

publish -republish -u scott -p tiger -schema SCOTT -s   sess_iiop://localhost:2481:ORCL /test/myHello   helloServer.HelloImpl hello.HelloHelper

Table 1 describes the command line options given above.

Table 1. Command line options to publish
-republishReplace the entry if it already exists
-schemaFind the classes for this object's implementation in Scott's schema
-sThe URL of the boot service in the form: sess_iiop://host:port:oracle_sid
/test/myHelloThe object name under which the Hello object is published.
helloServer.HelloImplThe object's implementation class name
hello.HelloHelperThe helper class name used to narrow down the object type.


Now we're all set to run the client program, after appropriately setting the classpath. At the command line, type:

java Client sess_iiop://localhost:2481:ORCL   /test/myHello scott tiger

You should see the output as:

Hello client, your javavm version is 8.1.6.

Invoke CORBA objects from Java stored procedures

So far, we've learned how, using Oracle8i, to develop client/server applications where the standalone client runs outside the database. Needless to say, the server can act as a client when talking to other servers. Moreover, it is possible to write the CORBA client as a Java stored procedure and invoke the procedure through either JDBC or an existing tool such as sqlplus. This is particularly useful for people accustomed to developing stored procedures, but interested in using new middleware technology -- the ORB, EJB, and so on -- provided in Oracle8i.

For the Java program to run in the stored procedure, we'll need to define a PL/SQL wrapper. The Java code could remain exactly the same, as if it were run outside the database. Details on this can be found in Oracle8i manuals. (See Resources.)


Every development environment requires some sort of debugging facilities. Standalone Java applications can be debugged using the standard jdb tool. Debugging distributed applications, on the other hand, is more cumbersome. Oracle8i 8.1.6 includes a server-side debugger that follows the standard Java remote debugging protocol, so the user can remotely debug the application's server portion. With the CORBA debugger object, prepublished with the name service, applications can invoke the methods to start the debug agent. We can then employ the standard jdb to attach to that remote agent and debug the server application. For details, please refer to the manuals in Resources.

Advanced topics: a look at presentations

As a topic for further research, Oracle8i includes a concept called presentations -- a means whereby any new client/server protocol can be implemented with no concern about issues such as network communications, scalability, load balancing, or threading. Presentations allow developers to concentrate on their protocol/logic implementation alone. Oracle implemented the Aurora ORB itself (as well as the component models that 8i supports, including the ORB, EJB, the Webserver/servelets, and so on) as a presentation. Presentations are particularly useful to customers or vendors who develop some sort of bridging software (to support legacy applications) that interoperates with the standard component models.

Interoperability/C++ clients

Last, but certainly not least, interoperability with other vendors is an important consideration. The goal is to allow clients that use ORBs from other vendors to successfully talk to Oracle8i CORBA servers. Although, at the wire level, IIOP is interoperable out of the box, more often than not different ORB vendors use different bootstrapping, security, or activation models. As a result, Oracle came up with a small list of issues that ORB vendors will need to address to allow clients to seamlessly interoperate with the Oracle8i server. A couple of ORB vendors have already successfully done interoperability testing with Oracle8i ORB.

As for C/C++ ORBs, Oracle also provides a C++ version of its Login object to log on to the database so clients using C/C++ ORBs can also interoperate with Oracle8i CORBA servers.


Aurora ORB is a unique product because of its built-in security, simplicity, and scalability. If you have read this entire article, you have learned to develop secure Java CORBA applications using Oracle8i, without having to solve the issues of networking, load balancing, security, and so on. It is also worthwhile to note that the applications you develop are interoperable with applications developed with other vendors' ORBs. More advanced users will also note how simple it is to create their own component model using the Presentations scheme.

Future versions of Aurora ORB will support POA, GIOP 1.2, IIOP firewall, standard objects by value (OBVs), and many other enhancements to keep up with the ongoing OMG standards. As part of the 8.1.7 release due out this summer, look for a generic name service with which arbitrary objects can be registered and activated.

Sastry K. Malladi boasts 12 years of systems- and network-programming experience. For the past 4 years, Sastry has worked at Oracle Corp. as a principle member of the technical staff in the Java Internet Services group. His current responsibilities include leading the EJB/CORBA distributed objects group. He has been working in distributed object-oriented programming for the past several years, and on OMG's CORBA model for the last four years. Sastry is a lead developer of Oracle's ORB and is a co-author of OMG's IIOP firewall specification. Sastry has also been working in the security area, particularly SSL-based security.

Learn more about this topic

1 2 Page 2
Page 2 of 2