Once you have a class library that includes the stack class, you can write a SOM-compliant client to use that class. Listing 8.2 shows such a client.

Listing 8.2  -A SOM Client that Links to Class Tstack

#include <stack.h >
int main()
{
  Tstack theStack;
  Environment* theEnvironment;

  theEnvironment = SOM_CreateLocalEnvironment();
  theStack = TStackNew();

  _push(theStack, theEnvironment, 100);
  _push(theStack, theEnvironment, 200);
  if (!_isEmpty(theStack, theEnvironment))
    somPrintf("Top: %d\n", _top(theStack, theEnvironment));
  _somFree(theStack);

  SOM_DestroyLocalEnvironment(theEnvironment);
  return(0);
}

Distributed COM and SOM  On a single platform, both COM and SOM are sometimes more trouble than they're worth. If objects could communicate across a network the way COM and SOM allow them to do on a single platform, however, such a technology might be useful.

Both Microsoft and the OMG recognized the usefulness of defining a distributed version of their single-platform specification. This section describes Distributed SOM, or DSOM. Microsoft's Distributed COM (DCOM) is similar but runs only on Windows platforms.

DSOM is an object-oriented framework for accessing objects across address spaces-on the same machine or across networked machines. SOM insulates clients from the server object's implementation; DSOM further insulates the client from the server object so that the client doesn't even have to know the server's location.

If all this talk about insulating the client object from the server object sounds familiar, it should. DSOM is an implementation of OMG's Common Object Request Broker Architecture (CORBA) for an ORB.

The similarities between DSOM and SOM are striking. Listing 8.3 shows how to convert the SOM client from Listing 8.2 into a DSOM client. Again, the bold lines show the changes.

Listing 8.3  -A DSOM Client that Links to Class Tstack

#include <somd.h>
#include <stack.h >
int main()
{
  Tstack theStack;
  Environment* theEnvironment;

  theEnvironment = SOM_CreateLocalEnvironment();
  // theStack = TStackNew();
  // The following lines replace the SOM call to TStackNew
  SOMD_Init(theEnvironment);
  TStackNewClass(TStack_MajorVersion, TStack_MinorVersion);
  theStack = _somdNewObject(SOMD_ObjectMgr, theEnvironment, "Stack", "");

  _push(theStack, theEnvironment, 100);
  _push(theStack, theEnvironment, 200);
  if (!_isEmpty(theStack, theEnvironment))
    somPrintf("Top: %d\n", _top(theStack, theEnvironment));
  //somFree(theStack);
  //The following lines replace the SOM call to somFree
  _somDestroyObject(SOMD_ObjectMgr, theEnvironment, theStack);
  SOMD_Uninit(theEnvironment);

  SOM_DestroyLocalEnvironment(theEnvironment);
  return(0);
}

The stack class itself doesn't have to be modified. To implement a DSOM Stack Server you need a DSOM server, which consists of a separate thread of execution (for example, a process), a server object, and one or more class libraries with object implementations. DSOM comes with a default server program, named somdsvr, and a default server object, SOMDServer. To implement the Stack Server, you do the following:

1. Build the stack class into a dynamically loadable library (DLL).
2. Register the TStack implementation.
3. Start the DSOM daemon, somdd, on the server machine.

To register the TStack implementation so that the ORB knows where to find it, you take the following three steps:

1. Register the stack class in the Interface Repository, using the SOM compiler.
2. Register the server in the Implementation Repository-IBM supplies the utility program regimpl for this purpose. If you're using IBM's AIX implementation of DSOM, you type:

   regimpl -A -StackServer
   regimpl -a -I StackServer -c TStack
   

3. Set up certain environment variables such as HOSTNAME, SOMDDIR, SOMIR, and LIBPATH so that the server machine can find the DLL.

When the DSOM client runs and requests an object of class TStack, the DSOM daemon looks in the Implementation Repository to find out which server offers class TStack. Because we ran regimpl, the client finds StackServer. When the client requests StackServer, the DSOM daemon starts the somdsvr server program, which uses the default server object SOMDServer, which loads the class DLL.

At runtime, the client machine has a stub stack.dll. The real stack.dll, and the real instance of the class TStack (which our client calls theStack) are on the machine that is running StackServer.

DSOM and CORBA  The Common Object Request Broker Architecture (CORBA) specifies how clients talk to the ORB, how servers register with the ORB, and how ORBs talk to each other. Various ORB vendors implement slightly different parts of the CORBA specification-DSOM is one such implementation. Nevertheless, ORB vendors have adopted CORBA to such a high degree that you can count on an "out-of-the-box" guarantee of compatibility between any two CORBA-compliant ORBs.

Understanding Object Request Brokers

ORBs have been around since the early '90s. If you work in a corporate environment, chances are good that one or more of the applications you use on your desktop is communicating through an ORB. Recall from Figure 8.3 that a typical ORB installation includes object services and common facilities. Typical common facilities include support for:

• Compound documents
• Object linking
• Help facilities
• User interface
• Desktop management
• Vertical markets

The OMG has identified the following seven major areas for object services:

• Lifecycle-creation and deletion of objects
• Naming-mapping human-usable names to references for actual objects
• Event Notification-registration of required and expected notification of events
• Persistence-long-term existence of objects, including management of their storage
• Transactions-including concurrency, relationships, and externalization
• Properties-including queries and licensing
• Security

Developers use object services and common facilities as building blocks to assemble application objects. Since the exact mix of services varies with the user's requests, the set of software that comprises the application is dynamically activated and connected at runtime. Developers in end-user organizations can buy server objects from multiple vendors and integrate them under one or more client applications. A single set of business objects can be shared across the entire enterprise, or each division can buy and access those objects that meet its specific needs.

Introduction to CORBA and the IIOP

Just as the corporate LAN has grown to become the intranet, so CORBA has expanded to include the Internet. Recall that the CORBA specification includes information about how two ORBs can communicate. The CORBA architecture exemplified by DSOM now includes the Internet Inter-ORB Protocol, or IIOP, which specifies how ORBs communicate over the Internet or a corporate intranet.

Netscape's LiveConnect technology allows you to integrate JavaScript, Java applets, and plug-ins on a single platform. Even though all of the components may come from different hosts, they are downloaded to a single machine (the client machine) and execute there.

When IIOP becomes widespread, look for something like a LiveConnect page to be distributed. The page might include a plug-in that is downloaded to the client machine, as well as applets that run remotely. Both the applets and the plug-ins may call back out to the Internet and request services from any CORBA-2.0-compliant application in order to get their job done.

A developer also might be able to write an object in C++, Java, or some other language and register services for use by other parts of the application that are distributed around the network.

Talking to an ORB

Netscape has announced that both Navigator 4.0 and the next generation of servers will be IIOP-compliant. In addition, they have announced that they are integrating VisiBroker, Visigenic's IIOP-compliant Java-based ORB, into Netscape ONE. Developers can use another Visigenic product, Caffeine, to program IIOP-compliant objects directly in Java.

Netscape's plan for communicating with the ORB is called Distributed LiveConnect. When a service becomes available, it registers itself, just as the stack server was registered under DSOM. A Netscape ONE application references the service by using a well-known name (such as StackServer). After that, the service appears as a LiveConnect component. Just as a developer can now say

<APPLET NAME="myApplet" ...>
<FORM>
<INPUT TYPE="Button" VALUE="doSomething NAME="doSomethingButton"
onClick="document.myApplet.doSomething()">
</FORM>

the developer with a service in his or her document will be able to directly call the methods associated with the service.

Application Design

Development of an application that is based on distributed LiveConnect is similar to the development of a single-computer application. The two major differences have to do with bandwidth and system load.

If the components of your application reside on only a single machine (for example, the user's desktop computer), there is little opportunity for sharing code (which reduces required disk space) or data (which increases corporate collaboration). On the other hand, the user never has to wait for something to download over the network. If the computer is fast enough, the user perceives the application as having good performance.

If the application's components are distributed but require downloading to the desktop machine (as are applets), the amount of disk space required is reduced, but the user incurs delay time when downloading the components. Many applets can fit into just a few kilobytes-a 12K applet is considered large. Such an applet takes about five seconds to download over a 28.8Kbps dial-up link. On most intranets, the download time will be a fraction of a second.

The browser needs a few more seconds to load the applet and start the thread. Size and start-up time are similar for plug-ins. Of course, plug-ins are generally downloaded only once and are stored on the local hard drive.

If the amount of data used by the application is large, you have little choice but to leave the data on a server and send queries to the server. LiveWire Pro, with its server-side JavaScript, and CGI scripts, with an interface to a database management system, work this way. The results of the query can often be downloaded in just a second or so, even over a dial-up link. The speed of the application is determined largely by the speed of the server and by the number of simultaneous requests for access.

If your application uses distributed LiveConnect, consider leaving as much of the application on large, powerful servers as possible. This way, you avoid downloading penalties and you can take advantage of shared data. Increase the capacity of the servers to meet heavy demand. (Often you can get a dramatic improvement in server performance just by adding memory.)

Most user interface components, which should provide near-instantaneous response to keypresses and mouse clicks, should be downloaded and run on the user's desktop machine. You can leverage your development effort by writing as many of these components in Java and JavaScript as possible. If you need platform-specific capability, write a Navigator plug-in.

Using the Internet Inter-ORB Protocol

Netscape is bundling a runtime version of Visigenic's VisiBroker for Java ORB, formerly known as Black Widow, into Navigator (starting with version 4) and its servers (starting with the Orion-class servers). Using the runtime version of the ORB, you can open Java applets that are IIOP-aware and use them to access remote applications.

To transform IDL into Java, you'll need Visigenic's development version. They support development on Windows 95, Windows NT, and major versions of UNIX.

Overview of the Development Process

The development process under VisiBroker for Java is similar to the development process provided earlier in this chapter for SOM and DSOM. Use the VisiBroker IDL to Java compiler to transform IDL into Java; then expand the Java to form a complete class. Finally, access the remote class from a Java applet. Visigenic's documentation shows a simple application that returns bank balances.

Banker Client  First, here's the client's side of the application. Listing 8.4 shows the HTML file that contains the applet; Listing 8.5 shows the applet itself.

Listing 8.4  -The HTML File that Embeds the Applet

<HTML>
<HEAD>
<TITLE>Black Widow Client Applet</TITLE>
</HEAD>
<BODY>
<H1>Black Widow Client Applet</H1>
<HR>
<CENTER>
<APPLET CODE=ClientApplet.class WIDTH=200 HEIGHT=60>
<H2>You are not running a Java-enabled browser.</H2>
</APPLET>
</CENTER>
</HR>
</BODY>
</HTML>

Listing 8.5  -The Banker Applet-Half of This Distributed Application

import java.awt.*;
public class ClientApplet extends java.applet.Applet {
  private TextField _nameField, _balanceField;
  private Button _checkBalance;
  private Bank.AccountManager _manager;
  public void init() {
    // This GUI uses a 2 by 2 grid of widgets.
    setLayout(new GridLayout(2, 2));
    // Add the four widgets.
    add(new Label("Account Name"));
    add(_nameField = new TextField());
    add(_checkBalance = new Button("Check Balance"));
    add(_balanceField = new TextField());
    // make the balance text field non-editable.
    _balanceField.setEditable(false);
    try {
      // Initialize the ORB (using the Applet).
      CORBA.ORB orb = CORBA.ORB.init(this);
      // Locate an account manager.
      _manager = Bank.AccountManager_var.bind("Post-Modern Bank");
    }
    catch(CORBA.SystemException e) {
      System.out.println(e);
    }
  }
  public boolean action(Event ev, Object arg) {
    if(ev.target == _checkBalance) {
      try {
        // Request the account manager to open a named account.
        // Get the account name from the name text widget.
        Bank.Account account = _manager.open(_nameField.getText());
        // Set the balance text widget to the account's balance.
        _balanceField.setText(Float.toString(account.balance()));
      }
      catch(CORBA.SystemException e) {
        System.out.println(e);
      }
      return true;
    }
    return false;
  }
}

Banker Server  Listing 8.6 shows the IDL that is used to describe the server interface. Once that IDL has been processed by the VisiBroker server, the programmer adds implementations to the Java skeleton to finish the Java application. Listing 8.7 shows the finished Java classes for the server.

Listing 8.6  -The Banker Server's Interface Definition

Module Bank {
  interface Account {
    float balance();
  };
  interface AccountManager {
    Account open(in string name);
  };
};

Listing 8.7  -The Banker Server-The Other Half of This Distributed Application

public interface Account
public class _sk_Account extends Skeleton implements Account {
  protected _sk_Account();
  protected _sk_Account(String _iName);
  public abstract float balance() throws SystemException;
};
public class AccountImpl extends _sk_Account {
  AccountImpl(float balance) {
    _balance = balance;
  }
  public float balance() throws CORBA.SystemException {
    return _balance;
  }
  private float _balance;
};

public interface AccountManager extends Object {
  public abstract Account open(String name) throws SystemException;
};

public class _sk_AccountManager extends Skeleton implements AccountManager {
  protected _sk_AccountManager(String _iname);
  protected _sk_AccountManager();

import java.util.*
public class AccountManagerImpl extends Bank._sk_AccountManager {
  AccountManagerImpl(String name) {
    super(name);
  }
  public Bank.Account open(String name) throws CORBA.SystemException {
    Bank.Account account = (Bank.Account) _accounts.get(name);
    if (account == null) {
      float balance = Math.abs(_random.nextInt()) % 100000 / 100f;
      account = new AccountImpl(balance);
      System.out.println("Created " + name + "'s Account: " + account);
      _boa().obj_is_ready(account);
      _accounts.put(name, account);
      }
      return account;
    }
    private Dictionary _accounts = new Hashtable();
    private Random _random = new Random();
}
public final class Account_var extends Object {
  public Account_var();
  public Account_var(Account value);
  public static Account narrow(Object object) throws SystemException;
  public static Account bind(String name) throws SystemException;
  public static Account bind() throws SystemException;
  public static Account bind(String name, String host)
throws SystemException;
  public static Account bind(String name, String host,
BindOptions options) throws SystemException;
  public static Account any(Any x) throws SystemException;
  public static TypeCode typecode() throws SystemException;
//AccountManager_var is similar to Account_var, and is omitted here.

public class Server {
  public static void main(String[] args) {
    try {
      CORBA.ORB orb = CORBA.ORB.init();
      CORBA.BOA boa = orb.BOA_init();
      Bank.AccountManager manager =
new AccountManagerImpl("Post-Modern Bank");
      boa.obj _is_ready(manager);
      System.out.println(manager + " is ready.");
      boa.impl_is_ready();
    }
    catch(CORBA.SystemException e) {
      System.err.println(e);
    }
  }
}

The VisiBroker for Java ORB comes with a program called GateKeeper, which provides the bridge between clients and servers. You can start GateKeeper from the command prompt:

java pomoco.iiop.GateKeeper

Once you have GateKeeper running, and class Server has registered itself, the client code

manager = Bank.AccountManager_var.bind("Post-Modern Bank");

succeeds and manager is associated with a valid AccountManager. As Listing 8.7 shows, you can call open on an AccountManager to map a name to an account. Once you have an account, you can call balance(). Each account's balance is initialized with a random number. Accounts are stored in the Dictionary object accounts.

In the SDK…

Netscape is going after the corporate intranet market and has made it easier for Netscape ONE applications to access CORBA-compliant legacy applications through the IIOP. For more information on Netscape's implementation of IIOP and the Java ORB, visit http://developer.netscape.com/library/one/technologies.html#IIOP.