One way to combine the benefits of the X- and Web- based approaches is offered by the Java object-oriented programming language. An HTML document can refer to a Java program called a Java applet that is stored at the site of the server managing the document. When a browser fetches the document, it also dynamically loads the applet code and executes it. The applet code executes within the context of the browser, that is, uses, for I/O, a section of the space allocated by the browser to display the document. Thus, like an X client, a Java applet is programmer-defined and can create an arbitrary user interface, and like a Web browser, it executes at the local site. This idea of dynamically downloading code in an I/O package is not new, and was pioneered (by the inventor of Java) in the Network Window System (NeWS) []. Dynamic downloading of code was also supported in Computational Mail, as we saw earlier. As we saw in computational mail, downloading and executing code from an arbitrary site raises security issues. Java addresses them by allowing a Java applet to accesses files at and send messages to only the site from which it was downloaded.
It makes sense to not only download code in an HTML browser but also an HTTP server, as illustrated by the Sun Java HTTP server, wich is written in Java. The server is composed of smaller modules, called servlets, each of which serves a particular kind of browser request. Like applets, user-defined servlets may be dynamically loaded into the server. When a browser request comes in, the server determines the servlet that must process it. If the servlet is trusted, then it executes in the same OS process as the server, but in a separate Java thread; otherwise the it executes in a separate thread group (OS process?).
A new servlet thread does not have to be forked on each request - once created, it keeps processing requests until there are no more requests, after which it may be terminated. Moreover, unlike an HTTP server, it can (since it is user-defined) create state that persists across multiple browser requests. To allow a browser to name this state, a servlet, like an HTML document or a cgi script, is associated with a URL, which can be used by the browser to invoke a service in it.
Java programs do not have to be dynamically loaded and executed within the context of a Web browser or server. Local Java programs can be executed as standalone Java processes, which, like processes written in any other programming language, have all rights of the users who create them.
Java also provides a high-level RPC-based mechanism for communication among arbitrary processes. Traditional RPC executes a global procedure of a remote process and (implicitly or explicitly) identifies the target process. Java extends this idea by supporting remote method invocation, that is,
direct invocation of a method of an object in a remote process. Instead of identifying the process, the invocation presents a remote object reference to directly identify the target object, using the same syntax as a local invocation. A process can register an object it wishes to export with a Java-provided name server, called a registry, by associating it with a string name, which can be looked up by some other process to receive a remote reference to the object.
How should parameters
of remote invocations be handled?
Traditional implementations of remote procedure calls
do not allow address
parameters and make remote copies of value parameters.
Some implementations do allow address parameters,
but make copies of the referants at the remote
site and return pointers to these copies.
As a result,
dereferencing the address refers to the local
copy and not the original remote object.
Java extends these semantics by sending copies of parameters that do not
implement the Java remote interface and remote references to
parameters that do.)
The remote references can be dereferenced to access the remote objects and not local copies.
Another interesting feature of Java is that if a process does not have the class of a (copy of or reference to a) remote object it receives from another process, Java will dynamically download the class into the process, much as it dynamically downloads applets into a Web browser. Since Java classes are also objects, they can probably be transmitted explicitly in parameters of methods.
Example: Servlet-based Centralized Version:
This is like the above version, except that we replace the session manager and CGI scipt with a Java servlet, and instead of invoking the CGI script, the browser now invokes the servlet. Not sure if form data can be passed to a servlet.
Example: Applet-based Centralized Version: As in the Web-based version, we define an HTML document for the session, which users load in their browsers to join the session. Instead of containing a form, it contains a Java applet, which, like the form, creates a local copy of the greeting, and displays it the user in an editable text widget. We also create a central stand-alone master Java process at the site from which the document is loaded. As before, it keeps track of the current value of the greeting and the users that have joined the session. It exports to the registry on its machine a session object defining methods for joining/leaving the session. The applet uses the session object objects to register its local copy of the greeting with the master and get a reference to the global copy. Both copies define update methods, which are used to keep them consistent. Thus, on each character typed by the user, the applet invokes the update method in the global-greeting object with the local value of the greeting. This update method, in turn, invokes the update methods of all local-greeting objects.
(Later we will see a more modular Java-based implementation based on the Observer/Observable interface).
Example:Applet and Servlet-based Centralized Version:
This is like the above version, except that we replace the standalone Java session manager with a Java servlet, and the local Java applets communicate with this session manager through the server. Not sure if applets can invoke servlet functions.
Example: Replicated Version: It is also possible to use Java to build a replicated version, but we cannot use Java applets since they can communicate only with processes at the HTTP server site. The implementation is similar to the one we saw under interprocess communication except that the local replicas use the predefined Java registry and Java remote method invocation for IPC. Thus, the session manager registers a session object with its registry, and the session manager and the replicas define local copies of the greeting that provide update methods. The replicas and the session manager to establish connections among their copies of the greeting objects and use the update methods to keep them consistent.
With its support for remote object references, Java can be considered as a language supporting distributed shared memory.
However, a remote reference is not a first-class reference in that it can not be used to access instance variables of the referant or invoke methods in any interface other than the Java remote interface. (Perhaps with the Java reflection model this will not be an issue since we could invoke reflection methods to retrieve arbitrary fields and invoke arbitrary methods.)