Figure 2 shows the bird's eye view of the Gateway middleware, which includes:

The Java-based middleware is developed using Java JDK 1.1.3 [2] and makes use of the Channel [3]. A Channel is a high-level Java-based abstraction of a bi-directional communication component that supports a generic message format. It is developed using Java sockets and object serialization [4], which is the process of reading or writing an object to a stream of bytes suitable for storage in a nonvolatile location; e.g., file. A Channel is a generic reusable software component which starts a thread to listen for incoming messages on a specified port. Any incoming message through the channel will be buffered into a generic message object. Figure 3 shows the interaction among various components of the Java-based Gateway middleware using Channel as the underlying communication component.

Listing 1 shows the Gateway class specification. The Java-based Gateway middleware is to be started on the same host as the Web server as a standalone application, as shown below:

> java Gateway
Java-based Gateway Middleware set up done

Upon executing, it initiates the four main components of the middleware; i.e., Facilitator, Registry, Receptionist and Dispatcher.

In the following discussion, we will describe the interactions among various components in the Gateway middleware in detail according to the steps outlined in Figure 3. 1. Service agents make their service known to the others. First, each service agent is to be started as a standalone application:

> java Service

whereby the indicates the location of the Gateway middleware.

Each participating service agent will register first with the Registry of the middleware to make its service known so that it can be assigned respective tasks later. For the discussion in this article, homogeneous services are assumed on all service agents. In Figure 4, the service agent contacts Registry through a Channel with a well-known address (a well known port in this case). Then, the registry will assign an unused address (port number) to the requesting service agent which will use it to accept task requests from the Dispatcher in future.
2. Clients submit their requests: The clients submit their requests to the Receptionist through the Web browser (Here, the Hotjava [5] browser is used for illustration). Here, we use a simple example which is to compute the distance between any n-dimensional vectors as an illustration for the task request. In fact, the service can be in any form of executable which is to be executed on the Service Agent. The client submits its request for computing Euclidean distance for the specified two-dimensional vectors (3, 5) and (9, 19). In this case, a C program (euclidean.c) is written to accept data (including the dimension of the vector; i.e., 2 and the two specified vectors) from the standard input and to display the computed result to the standard output (see Listing 2). Upon receiving the request from the client, the Java-based Gateway middleware will direct the request to the respective Service agent for execution. Upon successful execution, the result of the execution will then be displayed in the TextArea box.

Listing 3 shows the class specification of the ClientApplet respectively. Upon loading of the ClientApplet, it connects to the Gateway Middlware by using a Channel with a well-known port (see Figure 5) and the client is initialized. Then, a unique address (port number in this case) and client id are assigned dynamically by the middleware.

The assigned port for the Channel will be used subsequently for receiving the execution outcome from the Gateway middleware. Once the ClientApplet is initialized, it submits the user-specified request commands to the Receptionist after marshalling it into specific message format (see the submitGateway() method in Listing 3). Then, it listens to the channel with the assigned port number for the outcome of its execution.
3. Receptionist is always listening to the Channel, ch_reception (see the run() method of Listing 4) for any incoming request. Upon receiving any request from the clients, the Receptionist, which serves as a single contact-point between the client and the middleware, forwards the request to the Dispatcher for any action to be taken.
4. The Dispatcher delegates the task to a suitable service agent (see the run() method of Listing 5) based on the devised algorithm (a simple First-Come-First-Serve scheduling algorithm is used in this article).
5. Upon receiving the assigned task from the Dispatcher, the respective Service agent spawns the execution (see Listing 6) by creating a SpawnProcess object:

... SpawnProcess sp = new SpawnProcess(gateway_hostname, clientID, request);
sp.start();
...

The SpawnProcess object starts a new process running externally to the interpreter (see Listing 7). The input data and output result for the execution are communicated to the runtime process through standard input and output streams. This is achieved by using the getOutputStream() and getInputStream() methods of the object process shown in Listing 8. In general, the execution process can be any executable programs.

6. Upon successful execution of the spawned process, the execution result is forwarded to the Facilitator of the Gateway middleware as shown in Listing 10.

Finally, the result is relayed to the client through the Receptionist using a channel with dynamically assigned port address.

The Client communicates with the Gateway middleware through a well-defined message format (see Table 1) whereby

The following class specification for the message format is used homogeneously between any two entities such as client-to-Gateway middleware, components of the Gateway middleware, Service Agent-to-Gateway middleware.

/**
* Message Format class.
*/
class Message implements Serializable {
protected String intention;
protected String communication;
protected Object content;

public Message() { super(); }
}

Conclusion
In this article, a prototyped Java-based Gateway middleware is discussed in detail. It is still in its infancy stage, and there is still room for improvement (some aspects of which are currently under investigation):

Currently, the Gateway middleware is being developed using Visibroker [8] (an implementation of the CORBA framework) by Visigenic and more extensive testing is also being carried out.

References
1. Robert Orfali, Dan Harkey, Jeri Edwards (1994). Essential Client/Server Survival Guide. pp. 18-19.
2. Javasoft. Java JDK 1.1: http://www.javasoft.com/products/jdk/1.1/docs/api/package.html
3. Siet-Leng Lai, Joo-Hwee Lim, (1996). "Channel: A Communication Component",
Java Developer's Journal, Volume 1, Issue 3, pp. 20- 27.
4. JavaSoft. Javaª Object Serialization Specification: http://www.javasoft.com/products/rmi/doc/serial-spec/serialTOC.doc.html
5. JavaSoft. HotJava: http://www.javasoft.com/products/hotjava
6. Javasoft, Remote Method Invocation:
http://www.javasoft.com/products/jdk/rmi/index.html
7. CORBA (Common Object Request Broker Architecture): http://www.OMG.org
8. Visigenic, Visibroker: http://www.visigenic.com