Jeff Nelson

Subscribe to Jeff Nelson: eMailAlertsEmail Alerts
Get Jeff Nelson via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn




Scripting languages provide a powerful tool for easily gluing together components of a system. The CORBA community has recently begun work on a CORBA Component framework which incorporates many of the architectural insights of JavaBeans. This article explores how JavaScript could serve as a scripting language for such CORBA components to quickly create script applications which draw on mission critical network services.

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.

Another benefit of a CORBA scripting language is the ability of entry level developers to learn and use scripts. That scripts often don't have data types or require compilation steps makes them easy to use. Developers may start with a small set of example script commands and combine them in different ways to achieve their desired effect, slowly learning the complete set of script commands over time. This approach to learning a scripting language is common in the Visual Basic and JavaScript communities and has proven remarkably successful. CorbaScript would leverage these benefits of scripting languages, allowing entry level developers to become immediately productive in the development of CORBA software while gradually learning to perform more complex tasks over time.

Some scripting languages also have come under the spotlight of the Internet. JavaScript, in particular, has been recognized as an international standard supported in both Netscape and Internet Explorer. Since these Web browsers are already installed on virtually every computer in the world, a CORBA scripting engine based on JavaScript could come pre-installed on every machine.

With these observations in mind, Netscape has designed a CORBA scripting facility for JavaScript provided within their Component Development Kit. This facility integrates with Borland's VisiBroker to access CORBA objects from within the JavaScript environment. VisiBroker is wrapped as part of Netscape's Enterprise Server so that developers do not necessarily need to purchase separate licenses from Borland to begin development immediately. Furthermore, Netscape's flagship JavaScript development suite, Visual JavaScript, also integrates well with the CORBA component model. Developers can add CORBA components to the Visual JavaScript component palette and then add these components into applications through simple drag and drop mouse operations. Entry level developers don't necessarily even need to be aware that they are working with CORBA under the covers, just drag and drop components!

Under the covers, the standard VisiBroker tools like Web Naming are still used to coordinate the access to the CORBA servers. JavaScript has always had a fairly nice integration model with Java. This new support for CORBA objects is merely a fairly straightforward extension of this Java integration. The IDL file is compiled into Java stubs and skeletons under the covers; then the Java stubs and skeletons are integrated into JavaScript. The end result is the illusion that the IDL file magically became a JavaScript component because the developer doesn't necessarily need to be aware of the underlying implementation details.

Hello, World!
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:

  • Communicator 4.03 or better
  • Enterprise Server 3.0 or better
  • Visual JavaScript

    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.

    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.

    // IDL
    interface Hello
    string getMessage();

    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:\>".

    This compilation step produces a number of Java source files, including Hello.java, HelloHelper.java, HelloHolder.java, _st_Hello.java, _sk_Hello.java and others. These are the normal files provided by a CORBA compiler to perform its task of providing the illusion of network transparency to the distributed objects. These files are not related directly to this example of integrating CORBA with JavaScript other than their normal role in a CORBA-based distributed system.

    In order to proceed with building an example of access to a CORBA server from within a JavaScript application, we also need to create a CORBA server. Since the design and construction of such a CORBA server in Java isn't the point of this article, the code is presented in Listing 1 without additional explanation.

    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.

    %javac *.java

    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.

  • 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.

    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.

    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!

    If HelloImpl doesn't crash within about two minutes of starting up, everything is probably configured correctly up to this point. Leave the server running for now; we will use it later once the JavaScript is ready.

    The next step is to use Visual JavaScript to make use of the CORBA components. Visual JavaScript uses a component palette paradigm for software development. The application developer just clicks and drags appropriate components into an application to make use of the component. Little or no source coding is required to create a complete application in this manner.

    First, create a new project and add a new blank page to the project. This page will serve as a host for our JavaScript once it is developed. Next, create a palette called "Corba" to hold CORBA components. If you need help in doing this, see the ShowText example provided with Visual JavaScript. To import the Hello component into this new palette, select the "Corba" tab on your Components Palette. Click the right mouse button on the "Corba" tab to view a context menu. Choose "Install" and then "Corba Component". Use the File Dialog box to navigate to the location of the Hello.idl file and select this file. The component should now appear in your "Corba" palette.

    Now we are ready to develop a JavaScript application with the Hello component. Click and drag the component onto the blank page of your project to add the component to the project. The CORBA component is now part of the project, although we haven't configured it to communicate with the server yet. In order to do that, double click on the Hello component in the project (not the one in the palette). You should see a prompt for "Object URL Address". The Hello component in this project needs to be connected with the HelloImpl server by specifying the URL for the CORBA server. This URL was configured in the source code of HelloImpl and should be something like "http://localhost/iiop_objects/Hello". Type this URL in as the value of the "Object URL Address" for the Hello component. Now the component in your JavaScript application can find the CORBA server.

    Finally, let's create a simple form to display the results of this CORBA invocation. Select the tab labeled form elements. Click on a button and drag it onto the blank page. You should see a new form automatically created for you in the project with your button in it. Double click on the button and change the "Button Label" to "Get Message". Next, click on a "Text Field" and drag it into the form. Select the connection point of the button and drag it on top of the Hello component. A Connection Builder dialog box will appear asking you to configure how the Button and Hello component are connected to each other. Choose "View Parameters" inside the Connection Builder. Enter the action as getMessage and then press the "View JavaScript" button. In the JavaScript event handler box, change whatever is shown there to read:

    document.Form1.Text1.value = Hello1.getMessage()

    The JavaScript is ready to publish as a Web page. Choose "Apply", "Close", then select the Deploy button on the toolbar to load this project into your Enterprise Server.

    Start up Communicator and navigate to the URL where you deployed the Web page. The form you created a second ago using Visual JavaScript should appear. Just click the "Get Message" button to invoke the CORBA object! You should see the message "Hello, World!".

    Not so fancy you say? Well, remember that this is a distributed system. The JavaScript in this Web page is invoking the CORBA component, which could be located anywhere in the world. It doesn't have to be on your machine; it might be on another Web server. The CORBA component might implement the accounting system for a sales organization or provide the electronic commerce API for customers. The CORBA component in the JavaScript locates the component, even though it might be running on another machine and communicates with it transparently. This empowers you, the developer, to build complex JavaScript applications that make use of all kinds of network services.

    The Details
    When JavaScript accesses a CORBA object, each of the constructs in the CORBA object must map onto some equivalent constructs in the JavaScript language. Constructs such as data types, structures, object references and modules in CORBA must have corresponding features in JavaScript in order to provide the API sufficient for the JavaScript developer to manipulate CORBA objects.

    CORBA has a fairly rich set of data types, including float, double, short, long, char and others. JavaScript, like many scripting languages, tries to minimize the software development overhead of data types by providing only one or a small set of data types. The main four data types in JavaScript are object, number, string and boolean. JavaScript doesn't differentiate types of numeric data types like long, short, float and double. Rather, all the numeric data types in CORBA are mapped to the JavaScript number.

    Perhaps surprisingly, CORBA char and wchar data types, representing characters, also map into the JavaScript number. No character data type is present in JavaScript, the closest data types being string and number. The designers of the mapping made the choice to map the char and wchar onto the corresponding numeric values of the character. The JavaScript application may then determine which character was returned by testing the numeric value.

    The CORBA boolean and string data types both map naturally into the JavaScript string. CORBA strings are normally strings of 8-bit chars, but the conversion between the CORBA 8-bit char string and the JavaScript 16-bit char string is automatic. An exception is raised if one of the characters can not be converted back and forth between the different formats of string, as might happen if a particular 16-bit character could not map into the limited set of available ASCII 8-bit characters. CORBA also recently added support for a new wstring data type, which is a string of 16-bit characters. The wstring also maps well into the JavaScript string.

    CORBA also has a set of less intuitive data types present in other languages, such as enum, struct, union, array, and exception to name a few. All of these map into a JavaScript object. A particular custom JavaScript object is created for each of these data types to provide the capabilities of these data types within a JavaScript application. When a JavaScript application requires an enum to invoke a particular CORBA server that happens to use an enum as a parameter, the script must simply instantiate an object of the appropriate enum type and pass it into the invocation. In the reverse case, JavaScript objects of the enum type might come back as a return or out parameter in a CORBA invocation.

    Do all of these many-to-one mappings of different data types in CORBA to a single data type in JavaScript cause problems? Not really. The CORBA stubs and skeletons contain all the data type information about the interface, including the types of all the parameters for a particular operation. The different data type can be translated back and forth easily under the covers by CORBA and JavaScript. When a developer passes a number data type as part of an invocation of a CORBA Calculator object, the stub for the Calculator defines the appropriate data type to pass into the invocation, perhaps double. JavaScript converts the number data type into the Java double data type in the process of invoking the invocation on the Calculator stub. Developers don't have to spend a lot of time worrying about doing it themselves. However, a basic awareness of the process can help eliminate tricky bugs down the road that might be the result of data type conversions going on under the covers. For example, don't try to pass the number 100,000 into a CORBA invocation that expects a short or you'll get undefined behavior.

    One of the final and most important questions is how to actually access the CORBA objects from within JavaScript. That is, when a CORBA object is running someplace across the Internet - say, on the Netscape Web server - and you are writing a JavaScript that uses that CORBA object, how do you make your script communicate with the remote CORBA object? JavaScript introduced the concept of an ObjectURL, a normal Internet URL specifying the location of the instance of the CORBA object running out there on the Internet. By setting the ObjectURL of the CORBA component to the appropriate URL of the CORBA object, the component knows how to invoke the appropriate CORBA server.

    Other Approaches
    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.

    CorbaScript and CorbaBeans are inseparable in this sense. You can't have a CorbaScript language before you talk about the CORBA component model formed by CorbaBeans. Netscape is far ahead of the game by integrating CORBA components with JavaScript.

    Where to Go From Here
    The example described in this article can be downloaded from http://www.DistributedObjects.com.

    Information on CORBA standards can be found at http://www.omg.org.

    Netscape product information can be found at http://www.netscape.com.

  • More Stories By Jeff Nelson

    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/

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.