This chapter shows you how to integrate applets into distributed application programs. It presents a general architecture for distributed systems and discusses Java's role within this architecture. It summarizes current efforts to use Java to support distributed object access. The Common Gateway Interface is introduced, and the integration of applets with gateway programs is discussed.
Most programs can be characterized by three distinct elements: a user-interface element, an information-processing element, and a data-storage element. The user-interface element interacts with the user, displaying information to the user and responding to user-generated events. The information-processing element performs operations on the program's data based on the commands and information received from the user. The data-storage element retrieves, stores, and manages the data generated and consumed by the user-interface and information-processing elements. Figure 32.1 summarizes the interaction between these elements.
Figure 32.1 : Distributed application elements.
Even though most programs consist of some manifestation of these three elements, it is not necessary that they be implemented on the same computer. In fact, separating the elements of an application over more than one computer may lead to greater modularity and more efficient use of processing resources. Distributed applications are based on this notion. Figure 32.2 illustrates a typical distributed application architecture.
Figure 32.2 : Distributed application architecture.
The Web is an example of a distributed application. The Web is highly modular and fully distributed. Anyone with a Web browser and an Internet connection can use this application. Having access to a Web server is the only thing required to publish information on the Web.
Web browsers implement the client user-interface portion of the large distributed application known as the Web. They display information to Web users and respond to interface events generated by user mouse clicks and keyboard entries.
Web servers implement the data storage-and-retrieval element of the Web. They store Web pages, graphics and multimedia files, Java programs, and other information in files and databases. Web servers make this information available to Web users based on the requests made by browsers on their behalf.
The information-processing element of the Web is implemented in terms of Common Gateway Interface (CGI) programs and external programs on Web servers and by Java, JavaScript, and plug-in programs, on Web browsers. CGI programs provide the capability for Web browsers to access external application programs, such as database and search programs. They may be self-contained applications or they may be used as a means to provide an interface to external applications. Whereas CGI programs are executed by Web servers, Java, JavaScript, and plug-in programs are typically executed with Web browsers. In the not-too-distant future, specialized application servers may be set up to perform information-processing functions independent of both Web browsers and Web servers, allowing cleaner separation of the three distributed computing elements.
Figure 32.3 shows how the Web is organized in terms of the user-interface, information- processing, and information-storage elements of distributed applications.
Figure 32.3 : The Web as a distributed application
The Object Management Group (OMG) was founded in 1989; today it comprises all of the prominent computer and software vendors and is the world's largest software-development consortium. OMG was developed to support the standardization of object-based software and has developed a standard approach to using objects to support the distributed systems approach introduced in the previous section. This approach is the Common Object Request Broker Architecture (CORBA).
CORBA supports an object-based approach to distributed systems development by enabling objects on heterogeneous systems to communicate independently of the hardware or software platform on which they are implemented. CORBA makes use of Object Request Brokers (ORBs), which implement client/server relationships between objects. ORBs allow client objects to invoke the methods of server objects without having to consider where the server objects are located or how they are implemented. An Interface Definition Language (IDL) is used to specify the protocol by which distributed objects can be accessed.
CORBA provides the basis for extending the object-based approach that you've used so far to develop fully distributed systems. The ORB and IDL are the basic mechanisms by which CORBA accomplishes this objective. Because Java is a modern, object-oriented language, it is natural that there would be a strong interest in extending Java to support the distributed object approach initiated by CORBA.
The following subsections discuss some of these developments.
Sun Microsystems, the creator of Java, is developing a distributed operating system named Spring for its SPARC line of computers. The Spring system is designed to be fully distributed and to support distributed object access. The current version of Spring is Version 1.1. This version implements the Spring Java IDL system. The Spring Java IDL system provides the capability to integrate Java applications within Spring. Java objects and other Spring objects can be remotely accessed from within Java applets or programs or other non-Java applets.
Whereas the Spring project is essentially a research-and-development effort, Sun's NEO product family is integrating Java into its main network application product line that uses the Solaris operating system. The NEO product line is aimed at providing complete support for networked applications by integrating CORBA and other distributed object standards into Solaris.
JOE is an IDL-to-Java compiler, ORB, and NEO application-programming interface that allows Java applets and programs to be integrated within NEO applications. The JOE ORB is made accessible to Java-enabled Web browsers so they can support remote access to NEO and Java objects within the CORBA framework to implement distributed system applications as described in the beginning of this chapter.
Ernest Friedman-Hill, at Sandia National Laboratories, has developed JIDL, a CORBA- compliant IDL compiler that supports distributed object access from Java applets. It allows applets to access remote CORBA-compliant objects in the same manner as local Java objects.
A prototype of JIDL has been completed using commercial software packages, and work is underway to develop a complete public-domain version of the software.
Black Widow is a product of PostModern computing that provides the capability to connect CORBA-compliant objects with Java applets. Black Widow allows applets to access remote CORBA-compliant objects developed in Java or C++. It provides the capability to automatically generate interface code in Java or C++ and it supports the CORBA Internet Inter-ORB Protocol (IIOP). IIOP is a protocol for using the Internet for communication between local and remote ORBs.
HORB was developed by Dr. Hirano Satoshi at the Electrotechnical Laboratory (ETL) of the Agency of Industrial Science and Technology of the Japanese Ministry of International Trade and Industry (MITI). HORB is a freely available distributed object system, based on Java, that supports object-oriented communication between Java applets and objects running on a server.
Although HORB is not directly compatible with CORBA, it is further advanced than current Java-to-CORBA implementations and can be immediately implemented. HORB is a complete Java solution, supporting both client and server objects. HORB-to-CORBA connectivity can be implemented by custom interface software. The URL http://ring.etl.go.jp/openlab/horb/ is the home page of the HORB project. If you are interested in developing distributed applications using Java, I highly recommend that you download and investigate this package.
The object-based distributed system framework provided by CORBA and HORB will form the basis for the development of next-generation distributed systems. The Common Gateway Interface is the current standard by which Web-based applications are implemented. Although the CGI is not an old technology, in terms of the number of years that it has been around, it is not nearly as powerful and sophisticated as CORBA and will most likely be replaced by CORBA-like applications.
The CGI was developed to provide a standard interface for connecting external programs-such as database, search, and forms-processing programs-to Web servers. CGI programs, sometimes called CGI scripts, provide the capability to forward data between Web servers and these external programs. These programs are referred to as gateway programs because they provide a gateway through which Web servers and external programs communicate.
Although the CGI was developed to support gateway programming, CGI programs are not required to interface with external programs and can be complete programs in and of themselves.
Because CGI programs are executed by remote Web users, it is important to put limits on which programs can be executed in this fashion. CGI programs typically are stored in a special directory on Web servers. Common examples of this directory are /cgi-bin or /htbin. I'll use /cgi-bin in the following discussion, but you can designate any directory as the CGI directory.
When a browser request identifies an URL containing the /cgi-bin directory, the Web server recognizes this URL as containing a reference to a CGI program. The server identifies the CGI program to be executed from the URL; executes the CGI program, passing it any parameters or data; and, upon completion of the CGI program's execution, returns the results of the CGI program's processing to the Web browser.
The methods by which Web servers send and receive data to and from CGI programs is the core of the Common Gateway Interface specification. The current version of the CGI is 1.1. The URL http://www.w3.org/pub/WWW/CGI provides a starting point from which CGI information can be obtained.
Data is passed from a Web server to a CGI program using a combination of command-line arguments, environment variables, and the standard input stream.
Command-line arguments are passed to CGI programs as the result of an ISINDEX query. These queries are a now-archaic method of retrieving information from Web users and are being replaced by HTML forms. The args[] array of String objects defined in the main() method of a Java program provides the capability to access these command-line variables.
Environment variables are the primary mechanism used to pass information from Web servers to CGI programs. Environment variables are variables that are maintained by operating systems that are external to a program being executed. They are accessed by a program via special operating-system calls. Previous versions of Java used the getenv() method of the System class to access environment variables. This method has been declared obsolete and is no longer supported by Java. Java 1.0 replaces the getenv() method with the getProperties() method. This approach requires that environment variables be explicitly passed to Java programs as properties using the -D option of the Java command line.
The environment variables supported by the current version of the CGI specification are as follows:
When an URL containing a CGI program is accessed using the POST or PUT method, data can be passed to the CGI program using the standard input stream. This approach is very convenient, especially for Java programs, because the System.in variable and the classes and methods of the java.io package can be directly used to read the data passed by the server. The CONTENT_LENGTH environment variable is used to identify the number of bytes of data that are passed via standard input.
Although there are three ways to pass data to CGI programs, there is only one way for a CGI program to return data to a Web server: by writing to the standard output stream. The standard output stream of a CGI program is redirected by the Web server when the CGI program is executed. All data written to standard output is returned to the server. This is a bonus for Java-based CGI programs because the System.out variable and the java.io package can be used to return data to the Web server.
Because of the security policy enforced with applets, an applet can connect only with a CGI program on the server from which the applet was loaded. This minimizes the risk associated with an applet reading sensitive data from one system and then disclosing that data to another system. Although this security precaution is prudent, it limits the flexibility with which applets can be integrated with CGI programs.
The following example illustrates an applet that communicates with a Web server to repeatedly access the fortune CGI program. Its source code is shown in Listing 32.1.
Listing 32.1. The Fortune applet source code.import java.applet.*;
import java.awt.*;
import java.net.*;
import java.io.*;
public class Fortune extends Applet {
URL url;
TextArea text = new TextArea(24,80);
Button button = new Button("Again");
DataInputStream inStream;
public void init() {
setLayout(new BorderLayout());
updateText();
add("Center",text);
add("South",new Button("Again"));
}
public boolean handleEvent(Event event) {
if(event.target instanceof Button) {
if("Again".equals(event.arg)) {
updateText();
return true;
}
}
return false;
}
void updateText() {
try {
url = new URL("http://www.jaworski.com/cgi-bin/fortune");
inStream = new DataInputStream(url.openStream());
String newText = "";
String line;
while((line = inStream.readLine()) != null) {
newText += line + "\n";
}
text.setText(newText);
}catch (MalformedURLException ex) {
text.setText("MalformedURLException");
}catch (IOException ex) {
text.setText("IOException");
}
}
}
The Fortune applet cannot be run from your computer because an applet can make a socket connection to only the computer from which it is run. To run the Fortune applet, use your browser to open the URL http://www.jaworski.com/java/fortune.htm. The screen shown in Figure 32.4 should appear.
Figure 32.4 : The Fortune applet.
To get a new fortune cookie, click on the Again button.
The Fortune applet makes a connection to the fortune CGI program located in my /cgi-bin directory. It then reads the fortune cookie generated by this program and displays it in the text window. When you click on the Again button, it establishes another connection to the CGI program, obtains another fortune cookie, and displays the new cookie in the text window.
The Fortune class extends the Applet class and declares four field variables. The url variable is used to hold the URL of the CGI program. The text variable refers to the TextArea component displayed in the applet window. The button variable refers to the Again button. The inStream variable is used to refer to the input stream associated with the URL connection.
The init() method sets the layout of the applet window to a BorderLayout object and adds the TextArea and Button objects to the applet window. It also invokes the updateText() method to update the text displayed in the TextArea object by reading the output of the fortune CGI program.
The handleEvent() method handles the clicking of the Again button by invoking the updateText() method.
The updateText() method implements the heart of the applet's processing. It creates a new URL object using the address of my fortune CGI program and assigns it to the url variable. It then obtains the input stream associated with the URL and assigns it to the inStream variable. The inStream variable is read, line by line, and set in the TextArea object referred to by the text variable.
The fortune.htm file is shown in Listing 32.2. It follows the same format as used in other examples.
Listing 32.2. The fortune.htm file.<HTML>
<HEAD>
<TITLE>Have a fortune cookie!</TITLE>
</HEAD>
<BODY>
<APPLET CODE="Fortune.class" WIDTH=450 HEIGHT=350>
[Fortune applet]
</APPLET>
</BODY>
</HTML>
Listing 32.3 shows the fortune CGI program. It is a shell script that is written in the UNIX shell programming language.
Listing 32.3. The source code of the fortune CGI program.#!/bin/sh
FORTUNE=/usr/games/fortune
echo Content-type: text/plain
echo
if [ -x $FORTUNE ]; then
$FORTUNE
else
echo Cannot find fortune command on this system.
fi
This chapter shows you how applets can be integrated into distributed application programs. It presents a general architecture for distributed systems and has discussed Java's role within this architecture. It also summarizes current Java efforts to support distributed object access. The Common Gateway Interface is introduced, and the integration of applets with gateway programs is illustrated.