Scripting languages have established a role in the software industry as a powerful tool for quickly whipping together applications. The applications developed with scripting languages, called scripts, can be used as the glue language for large components. Some of the benefits of scripting languages include speed of development, ease of use, lack of strong typing and runtime customization.
CORBA is an incredibly popular, open standard for developing complex distributed systems. More than 800 companies have joined the Object Management Group, the standards body which maintains the CORBA standard.
CORBA stresses different goals from those of scripting languages. While scripts are short programs that solve simple problems, CORBA was designed to provide scalable solutions to complex problems. While scripts are not compiled, most languages used to build CORBA objects, such as Java and C++, are. Finally, while scripts rarely use strong typing, CORBA mandates that every object define its operations using a strongly typed interface.
That both tools have different goals is an indication that a synergy might exist in combining them into a scripting language that leverages the power of CORBA called, say, "CorbaScript". Though CORBA applications are written in strongly typed languages and developed to scale to the enterprise, scripts might provide a path to quickly composing these objects to solve complex problems. Here, the objects used in the scripting language is not a simple "button" or "number", as might be found in your typical scripting language; instead, the target of these scripts is CORBA objects solving enterprise scale problems. CorbaScript addresses the easy integration of existing CORBA systems in such an application.
Let's face it. Most software developers, myself included, don't understand a new technology until they see a "Hello, World!" example. For those of us who think in source code, here is such a demo.
In order to follow along with developing this yourself, the first task is to collect the software that you will need to run this example. You should obtain the following from Netscape if you don't already have them:
You also need a Java development environment. Netscape recommends JDK 1.1.2 or better for component development. As long as your Java development environment is compatible with Java 1.1.2.\, your environment should work.
- Communicator 4.03 or better
- Enterprise Server 3.0 or better
Next, be sure that your CLASSPATH includes nisb.zip and wai.zip from your installation of Netscape Enterprise Server 3.0. These contain the required Java classes related to VisiBroker bundled into Enterprise Server.
We are now ready to write an IDL file. For this example, let's just use the following simple interface that has only a single operation returning a string. Save this in a file called Hello.idl.
The next step is to compile this CORBA interface. Provided your CLASSPATH is set up appropriately and you have all the right software, the command for compiling this interface is the following:
> java com.visigenic.vbroker.tools.idl2java Hello.idl
In the above command, the ">" represents the prompt on the command line or shell that you are using. This varies quite a bit between operating systems and shells. In Microsoft operating systems, it looks something like "C:\>".
Once you have the server ready, you can compile the example within your favorite Java development environment. Something as simple as the following could be used with the JDK.
The next step is to create a directory for CORBA objects on your Enterprise Server. The Web Naming feature of VisiBroker makes use of this directory to store the object references for your CORBA servers. If your Enterprise Server is not already running on port 80, start it on that port.
Now that Enterprise Server is completely configured to run the example, let's try to start the CORBA server and see if it runs properly. We don't have a client yet, so it won't do anything interesting. However, if it starts up and at least stays running, that probably is a good indication that Netscape Enterprise Server is configured correctly.
- Open up the System Administration URL on your Enterprise Server and confirm that "Web Publishing" is set to "On".
- Choose the HTTPD that you would like to broadcast with CORBA objects.
- Select "Content Management" and then "Additional Document Directories". A new URL prefix is required to host your CORBA objects. Netscape requires this to be called "iiop_objects".
- Next, provide a directory for the contents of iiop_objects. This must be directly under your primary document directory in Enterprise Server.
- Finally, go under the "Server Preferences", then "Restrict Access" frames, to configure the access permissions of the new "iiop_objects" directory.
- Select Edit Access Control. Confirm that access control is turned on, but configure it to "Allow anyone from anyplace all rights". In practice, you wouldn't want to do this for a Web server that contains mission critical documents because it could represent a security risk. For the purposes of this simple example, though, not much risk is present.
- Save and apply the changes you've made in the System Administrator.
You can run the example from within your Java development environment or on the command line with the JDK. From the command line, something like the following command is required:
> java -DDISABLE_ORB_LOCATOR HelloImpl "Hello, World!"
The -DDISABLE_ORB_LOCATOR command line argument instructs the VisiBroker ORB not to worry about using the normal ORB locator feature built into VisiBroker. This example uses Web Naming and doesn't need the ORB locator functionality. If you are running this example from within a Java development environment, be sure to specify this command line option by configuring the execution options for HelloImpl. How this configuration is performed varies considerably between development environments, though, so you are on your own!
document.Form1.Text1.value = Hello1.getMessage()
Is scripting of CORBA distributed systems a radical new technology? Not necessarily. Several scripting languages have had CORBA support for some time, such as TCL, Perl and Python. Interpreted object-oriented languages such as Smalltalk and Lisp also have a long history of CORBA support. Should we standardize a single "CorbaScript" language when all these other languages are already available?
In my opinion, the key seems to be that the CORBA scripting language is not aimed at the simple integration of CORBA with a scripting or interpreted language. Rather, the goal is to standardize a single language as the common glue for a CORBA Component model. This approach is analogous to the use of Visual Basic as the standard scripting language for COM-based components. Such COM components can be accessed to a limited extent in other languages, such as C and C++, but Visual Basic has become the de facto standard that the majority of the COM community has rallied behind.
Where to Go From Here
The example described in this article can be downloaded from
Information on CORBA standards can be found at
Netscape product information can be found at
About the Author
Jeff Nelson is a distributed systems architect with DiaLogos Incorporated, experts in CORBA and Java Technologies (http://dialogosweb.com) and active participants in the Object Management Group. He has 8 years of experience in distributed computing and object technology. Jeff can be found on the Web at http://www.distributedobjects.com/ or by e-mail at [email protected]
public class HelloImpl
public String message = "The default message.";
public HelloImpl(String n)
public String getMessage()
public static void main(String args)
// Use first command line argument as the message, if provided.
if (args.length > 0)
message = args;
org.omg.CORBA.ORB orb = orb.omg.CORBA.ORB.init();
org.omg.CORBA.BOA boa = orb.BOA_init();
HelloImpl h = new HelloImpl("Hello");
System.err.println("HelloImpl: " + e);