Table of Contents | Previous | Next | Index

Chapter 22
Accessing CORBA Services

This chapter describes using LiveConnect to access CORBA-compliant distributed objects. Through LiveConnect, you can access Java; through Java, you can connect to CORBA objects using Netscape Internet Service Broker for Java.

This chapter contains the following sections:

About CORBA Services

Netscape Internet Service Broker for Java (ISB for Java) is Netscape's object request broker. ISB for Java communicates with itself and with other object request brokers (ORBs) using the Internet InterORB Protocol (IIOP).

ISB for Java enables your JavaScript application to access CORBA-compliant distributed objects deployed in an IIOP-capable ORB (including ISB for Java itself). These objects may be part of a distributed application. To access such a distributed object, you must have a Java stub, and that stub class must be on your CLASSPATH. Conversely, you can use Java and LiveConnect to expose parts of your server-side JavaScript application as CORBA-compliant distributed objects.

It is beyond the scope of this manual to tell you how to create CORBA-compliant distributed objects using ISB for Java or how to make Java stubs for such objects. For this information, see the Netscape Internet Service Broker for Java Programmer's Guide.

Server-side JavaScript applications can access a distributed object regardless of how it is deployed. The simplest alternative to consider is that the distributed object is created and run as a separate process, as illustrated in the following figure.

Figure 22.1   A JavaScript application as a CORBA client

As shown in this illustration, the Java and JavaScript runtime environments are together in the same web server. They communicate using LiveConnect in the standard way described earlier in this chapter. Methods called on the stub wrapper in JavaScript result in method calls on the Java stub object in Java. The stub uses the Java ORB to communicate with the remote service. With this architecture, the object server process can be on any machine that has an ORB and can be written in any language.

The flexi sample application illustrates this. In this sample, FlexiServer is a stand-alone Java application that has implementations of a number of distributed objects. This example is discussed in "Flexi Sample Application" on page 423.

After you have worked with flexi, read "Deployment Alternatives" on page 431 for a discussion of more complicated deployment alternatives.

Flexi Sample Application

The flexi sample application illustrates using server-side JavaScript to access remote services running on an IIOP-enabled ORB and also illustrates a remote service written entirely in Java using ISB for Java. Both the source files and the application executables for the flexi sample application are installed in the $NSHOME\js\samples\flexi directory.

A flexible spending account (FSA) is an account in which employees may deposit pretax dollars to be used for medical expenses. Employees typically elect to sign up for this plan with the administrator of the plan and select a dollar amount that they want deposited into their account. When an employee incurs a medical expense, the employee submits a claim which, if approved, results in a withdrawal from the account and the remittance of the approved amount to the employee.

The flexi sample application provides support for managing flexible spending accounts. With this application, an administrator has these options:

The employee has these options:

CORBA Client and Server Processes

Figure 22.2 shows the two primary parts of flexi. These implement the CORBA client and service.

Figure 22.2   The flexi sample application

The CORBA client is the server-side JavaScript application known as flexi. This application implements the administrator and employee user interfaces described earlier. This application connects with the FSA-Admin object (described next) in a separate process or even on a separate machine. The application then uses that object, and other objects returned by FSA-Admin, to perform most of its operations.

The CORBA server is a stand-alone Java application run from the shell. It contains implementations for all the interfaces defined in the IDL file Flexi.idl. This stand-alone application, called FlexiServer, implements the primary functionality of the FSA system. Upon startup, this application creates an instance of an object implementing the interface ::FSA::Admin and registers it with the name "FSA-Admin." Clients of this service (such as the flexi JavaScript application) obtain access to this object first by resolving its name. Clients use this object to create other objects and to get remote references to them.

Starting FlexiServer

FlexiServer is a stand-alone Java application. You can run it on any machine that has JDK 1.0.2. In Enterprise Server 3.01 and FastTrack Server 3.01, you can also run it on a machine that has JDK 1.1.2. Before running FlexiServer, you need to ensure that your environment is correct.

From the shell where you're going to start FlexiServer, make sure that your PATH environment variable includes $JDK\bin and that CLASSPATH includes the following:

... 
$NSHOME\js\samples\flexi 
$NSHOME\wai\java\nisb.zip 
$JDK\lib\classes.zip
In these variables, $JDK is the directory in which the JDK is installed and $NSHOME is the directory in which your web server is installed.

Once the environment is correct, you can start FlexiServer as follows: 

cd $NSHOME\js\samples\flexi\impl 
java FlexiServer
You should see a message such as the following: 

Started FSA Admin: Admin[Server,oid=PersistentId[repId=IDL:Flexi/Admin:1.0,objectName=FSA-Admin]]
At this point, FlexiServer has started as a CORBA service and registered with the ORB an object with interface ::FSA::Admin and name FSA-Admin. FlexiServer runs in the background, waiting for service requests.

Starting Flexi

You must start FlexiServer before you start flexi, because flexi's start page attempts to connect to FlexiServer.

Add $NSHOME\js\samples\flexi to the CLASSPATH for your web server. For information on how to do so, see "Setting Up for LiveConnect" on page 15.

Using the Application Manager, install the flexi JavaScript application as described in "Installing a New Application" on page 39. The parameters you set for flexi are shown in the following table.

Table 22.1 Flexi application settings  
Setting Value

Name

flexi

Web File Path

$NSHOME\js\samples\flexi\flexi.web

Default Page

fsa.html

Initial Page

start.html

Client Object Maintenance

client-cookie

Using Flexi

To start flexi, you can run it from the Application Manager or enter the following URL:

http://server-name/flexi
The default page lets the user be identified as an administrator or an employee. To get a quick feel for the application, follow this scenario:

  1. Administrator creates an account for a user with a certain balance.

  2. Employee selects the account.

  3. Employee submits a claim.

  4. Administrator selects employee's account.

  5. Administrator accepts claim, which results in a reduction in the employee's account balance and a remittance of a check for the claim amount.

  6. Employee selects the account.

  7. Employee views the status of the account.

  8. Administrator selects employee's account.

  9. Administrator deletes claim.
The system can handle only one claim per employee at any time. Once the claim has been deleted, a new claim may be submitted.

Looking at the Source Files

The following table shows the primary files and directories for flexi.

Table 22.2 Flexi files and directories   
flexi.idl

File defining the interface to the remote service, including Admin, Account, Claim. 

Flexi\

Directory containing code generated from Flexi.idl by the idl2java program. This directory includes the skeletons and stubs for the interfaces.

impl\

Directory containing implementations in Java for all the interfaces defined in Flexi.idl. It also contains the class FlexiServer which implements the main program for the Java application that runs the service. 

*.html

Files implementing the server-side JavaScript application. It also includes the application's web file, flexi.web.

Browse through these files to get a clear understanding of this application. Only a few highlights are discussed here.

Setting Up FlexiServer as a CORBA Server

The main routine of the stand-alone Java application is implemented in flexi\impl\FlexiServer.java. Its code is as follows:

import org.omg.CORBA.*;
class FlexiServer {
   public static void main(String[] args) {
   try {
      // Initialize the orb and boa.
      org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
      org.omg.CORBA.BOA boa = orb.BOA_init();
      // Create the server object.
      Admin __admin = new Admin();
      // Inform boa that the server object is ready.
      boa.obj_is_ready(__admin);
      // Register the name of the object with the name service.
      // First, determine the name service host;
      // by default use <localhost>:80.
      String _nameServiceHost = null;
      if (args.length > 0) {
         // Assume the first arg is the hostname of the name 
         // service host. Expected format: <hostname>:<port>
         _nameServiceHost = args[0];
      }
      else {
         String _localHostName = null;
         try {
            _localHostName= 
               java.net.InetAddress.getLocalHost().getHostName();
            _nameServiceHost = _localHostName + ":80";
         }
         catch (java.net.UnknownHostException e) {
            System.out.println("Couldn't determine local host; 
            can't register name.");
         }
      }
      String _regURL = "http://" + _nameServiceHost + "/FSA-Admin";
      System.out.println("Registering Admin object at URL: " + _regURL);
      // Register the server object.
      netscape.WAI.Naming.register(_regURL, __admin);
      System.out.println("Started FSA Admin: " + __admin);
      boa.impl_is_ready();
   }
   catch (org.omg.CORBA.SystemException e) {
      System.err.println(e);
      }
   }
}
This code initializes the ORB and creates an instance of the Admin class. It then registers the instance as a distributed object, with a URL of the form http://host:port/FSA-Admin. By default, host is the name of the host on which FlexiServer is run and port is 80. You can supply your own value for host:port by passing it as an argument to FlexiServer when you start it. To use the local host but a different port number, you need to change the sample code and recompile. Once the code has an appropriate name, it registers the object using the register method of the netscape.WAI.Naming object. For more information, see Netscape Internet Service Broker for Java Reference Guide.

Finally, if successful the code prints a message to the console and then waits for requests from CORBA clients. In this case, the only CORBA client that knows about it is the flexi JavaScript application.

Setting up flexi as a CORBA client

The file start.html is the initial page of the JavaScript flexi application. This page uses LiveConnect to initialize ISB for Java and establish the connection to FSA-Admin.

<server>
// Initialize the orb.
project.orb = Packages.org.omg.CORBA.ORB.init();
// Establish connection to the "FSA-Admin" service.
// By default, assume name service is running on this server.
nameHost = "http://" + server.hostname;
serviceName = "/FSA-Admin";
serviceURL = nameHost + serviceName;
// Resolve name and obtain reference to Admin stub.
project.fsa_admin = Packages.Flexi.AdminHelper.narrow(
   netscape.WAI.Naming.resolve(serviceURL));
</server>
The first statement initializes ISB for Java by calling the static init method of the Java class org.omg.CORBA.ORB. It stores the returned object as a property on the project object, so that it lasts for the entire application.

The second set of statements determine the URL that was used to register the FSA-Admin object. If you used a different URL when you registered this object (as described in the last section), you need to make appropriate changes to these statements. The URL used in the CORBA server must be exactly the same as the URL used in the CORBA client.

The code then calls the resolve method of the netscape.WAI.Naming object to establish the connection to the Admin object that was registered by FlexiServer as FSA-Admin. Finally, it calls the narrow method of AdminHelper to cast the returned object to the appropriate Java object type. That Java method returns a Java object corresponding to the distributed object. The JavaScript runtime engine wraps the Java object as a JavaScript object and then stores that object as a property on the project object. At this point, you can call methods and access properties of that returned object as you would any other Java object. The other pages in flexi work through this object.

Once again, for more details on how the CORBA objects work, see Netscape Internet Service Broker for Java Reference Guide.

Using the Admin Object to Administer and View Accounts

Other code in flexi creates and then accesses objects in FlexiServer other than the Admin object. These other objects are created by calls to methods of the Admin object. For example, if the employee chooses to submit a claim, a new claim is created in the account-empl.html with the following statement:

__claim = __account.submitClaim(
   parseFloat(request.claimAmount),
   request.serviceDate,
   request.providerName,
   request.details);
This code calls the submitClaim method of the Account object to create a new employee claim. The implementation of that method, in the file impl\Account.java, creates a new Claim object, which the code registers with the ORB and then returns, as follows:

public Flexi.Claim submitClaim(float amount, String serviceDate,
   String providerName, String details)
{
   Claim __clm = new Claim(this, amount, serviceDate, 
      providerName, details);
   org.omg.CORBA.ORB.init().BOA_init().obj_is_ready(__clm);
   _current_clm = __clm;
   System.out.println("***Created a new claim: " + __clm);
   return __clm;
};

Deployment Alternatives

There are two other alternatives for deployment of a CORBA-compliant distributed object that are of interest when working with server-side JavaScript:

In these alternatives, the CORBA client and the CORBA server both run in the same web server process.

From the point of view of JavaScript, if the CORBA client is not a JavaScript application, the first alternative is for all practical purposes the same as having the CORBA server run as a separate process.

However, the second alternative, creating a distributed object in a JavaScript application, in effect makes that application the CORBA service. Figure 22.3 illustrates this alternative.

Figure 22.3   A JavaScript application as a CORBA server

Once again, the Java and JavaScript runtime environments are together in the same web server. They communicate using LiveConnect in the standard way described earlier in this chapter. In this case, however, the Java and JavaScript processes act together to be the CORBA service. This service then communicates with a CORBA client through ISB for Java in its standard way. The bank sample application is an example of a JavaScript application implementing a CORBA service.

Here, the CORBA client can be on any machine that has an IIOP-capable ORB and can be written in any language. One interesting possibility is that the CORBA client can be a client-side Java application (and through LiveConnect on the client, a client-side JavaScript application). This provides a completely different way for a client-side JavaScript application to communicate with a server-side JavaScript application.

Table of Contents | Previous | Next | Index

Last Updated: 11/12/98 15:29:52

Copyright © 1998 Netscape Communications Corporation

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use