When the AS/400 development team set out to enable the AS/400 to run shrink- wrapped Java code from software stores, one critical issue came to mind: What about the GUI? Many Java applications have install code that uses a GUI. Because the AS/400 lacks a native GUI, those applications would not install on OS/400. Using the inherent strengths of Java (namely, its object-oriented nature and portability), the IBM development team was able to create a solution to this problem. IBM created a facility that allowed requests for the Abstract Windowing Toolkit (AWT) to be forwarded to any remote GUI platform and named that facility the Remote Abstract Windowing Toolkit (RAWT).

This article describes the concepts behind RAWT and explains how IBM’s RAWT can be used in a production environment. It also discusses the trade-offs that were made to guarantee acceptable RAWT performance and how they affected the construction and implementation of the product. Although this article discusses Java from a conceptual viewpoint, RAWT has been available on the AS/400 since V4R2. To learn exactly how to set up RAWT applications between your AS/400 and a remote client, see the online publication Using the AS/400 Developer’s Kit for Java at http://publib.boulder.ibm.com/pubs/ html/as400/java/rzaha.htm.

Getting the RAWT Concepts Right

Even though the AS/400 has no local GUI, RAWT allows any Java GUI application to run on the AS/400 without requiring modifications to the Java source code, preserving Java’s platform-independent nature. RAWT delivers this ability to run a Java GUI application in three steps. First, you run a GUI “server” program on a PC or other client that has a Java Virtual Machine (JVM) and a graphic display. This server program listens on a TCP/IP socket for graphic requests from an AS/400 host. Second, you specify a RAWT server property on your AS/400 Run Java Program (RUNJVA) commands to inform the JVM that GUI requests need to be intercepted and to provide the TCP/IP address of the client PC. Finally, you invoke a GUI application class from your AS/400, and the class runs as if it were executing locally on the client PC.

In essence, we devised the RAWT solution based on the same concepts as an X- Window solution. RAWT, however, differs from X-Window in two ways: It services only Java applications and is a 100 Percent Pure Java solution.

Those of you who write code for PCs might comment that the AS/400’s RAWT approach to GUI implementation seems inefficient. If a Java application that resides on a client can present a GUI twice as fast as the same Java application running on an AS/400 host using RAWT, why bother? There are five main considerations that make a host-driven strategy more attractive than a client-driven strategy:

• Maintenance. The direct and indirect costs of maintaining and upgrading the hardware, operating systems, and applications in host-based environments are lower than in fat client scenarios.

• Reliability. Server hardware, operating systems, and applications are traditionally more reliable, more secure, and more recoverable (host platforms always seem to have excellent backup strategies) than client versions.

• Capability. The ever-shrinking cost of hardware means that the client might not be a PC at all, but a palm-top computer or another small device that could be very limited in resources. RAWT can enhance the capabilities of thin clients.

• Security. Banks and retail outlets, for example, may desire to keep their hardware and software behind locked doors to prevent malicious or inadvertent tampering. It’s easier to secure a single host than multiple clients.

• Simplicity. Writing a single-server application—one that, from the programmer’s point of view, runs on a single machine—is simpler than writing a client/server or distributed application.

The RAWT operational environment is depicted in Figure 1. RAWT Java applications run and reside on the AS/400 host. The AS/400 Developer Kit for Java is not required to implement the AWT native functions. How could it? How can a machine that has no local graphical or audio capabilities implement the AWT components that use such features as graphics, images, audio, and drag and drop? The client-side Java Development Kit, on the other hand, must provide complete implementations for all of the AWT components. RAWT achieves application transparency by fully implementing the Java.awt.Toolkit class and all other interfaces and classes in a client/server fashion. This implementation enables Java applications to transparently use all the APIs defined in the AWT classes. Figure 2 illustrates RAWT’s generic components and main functions.

Performance Considerations of RAWT

As shown in Figure 2, all native graphics services are provided by the AWT native functions in the client PC. This implies that the method call delegation services of RAWT must be immune to any AWT native implementation. This requirement posed a challenge to IBM’s programmers. The client machine that presents the AWT component (your PC) must be able to communicate all user activity on that component (such as resizing, mouse clicks, and keystrokes) back to the AS/400 server-based RAWT Java class so that the host application can respond to the user activity. This communication is implemented with a technique known as callbacks. The reliance on callbacks has two major effects: performance degradation due to extensive remote calls and deadlocks caused by synchronized remote calls and synchronized callbacks (as can be envisioned from Figure
2).

RAWT takes two main measures to prevent performance degradation. It maintains a partially updated state of all AWT objects used by the application in their surrogate objects (see C_AWT Comps in Figure 2) in the client PC.

Consequently, it can filter out callbacks and AWT events and service them locally rather than remotely.

IBM’s RAWT developers prevented deadlocks by implementing a unique Object Request Broker (ORB) property that switches an incoming remote callback to the thread that issued the outgoing remote call. ORBs are implemented with an industry-standard strategy to provide services that allow complete objects, rather than raw byte streams, to be transferred across the Internet. Numerous ORB implementations are available from a

variety of vendors, but we are not aware of any ORB implementation that provides a service similar to our deadlock prevention scheme.

However, our first attempt at implementing RAWT used Java’s standard mechanism for Internet object communication, Remote Method Invocation (RMI), to delegate remote calls. Since RMI delegates remote calls in separate threads, we ran into a severe deadlock situation. We overcame the problem by adding a thread context preservation mechanism on top of RMI. The performance penalty of such a mechanism over RMI, and other performance limitations that RMI imposed on our implementation, drove us to replace RMI with our own remote call mechanism. You will find it interesting to see where RAWT performance was sacrificed for the relative convenience of using RMI as illustrated by the clock application depicted in Figure 3.

In the Java clock application, the rate at which the second hand is updated can be used to measure one of the performance characteristics of RAWT. Figure 4 shows the clock rate penalty (in seconds) of using some RMI elements in RAWT.

The overhead incurred by RMI made the performance of our initial RAWT implementation unacceptable. With RAWT over RMI, we were unable to reach the mandatory update rate of one second, as in local execution. The RMI performance penalty convinced us to replace RMI with our own remote call mechanism-the ORB mentioned earlier. With our ORB implementation in place, we retested the clock program and obtained an update rate close to one second, a significant improvement.

Checking RAWT Performance with Our RMI Replacement

We also tested RAWT’s performance against the response time we would get running the same Java application locally on a client PC. To do this, we used a four-way MP model AS/400 and a Microsoft Windows NT Pentium 200 PC with Java Development Kit 1.1.6 connected on an IBM 16 MB Token-Ring. The Java program we used—a pure Java implementation of a file dialog (not the FileDialog class from the Java Development Kit)—was programmed to display screens containing directory information. The test compared the performance obtained from running the file dialog program locally on a PC and from running the program remotely on the AS/400 using RAWT. The program displayed a number of file dialog boxes on the AS/400 using RAWT (similar to that shown in Figure 5). The directories navigated on both the PC and the AS/400 were of similar sizes. The functions compared in the test involved selecting directories and going up one level of directory, as noted in Figure 6. The results in the figure reflect the seconds elapsed from the time the selection was made to the time the screen was rebuilt and displayed.

While remote execution can never operate as efficiently as local execution, in this case, the remote implementation turned in acceptable performance.

Thin Clients Model vs. Thin Client Programming Model

Java burst on the scene with the idea that the thin client (TC) was immediately going to replace all the PCs on the planet. IBM, Sun Microsystems, and others have produced TCs as hardware solutions that, in some markets, are quite successful; however, they’ve not met with enough success to create panic among Microsoft execs yet.

As physical beings in a physical universe, most programmers demand tangibles before embracing something new. If we cannot hold it, see it, or experience it in some other physical way, it is harder to accept as real. The production of TC hardware seems reasonable. We would argue however, that a TC is less about hardware than about software, programming models, and the Web. Thin represents more a state of mind or a way of programming, if you will, than it does hardware. It calls for the invention of a new programming model. Therefore, let’s discuss the Thin Client Programming Model (TCPM), for which we suggest the following characteristics:

Server-Centric. Consider the Model-View-Controller structure of a program. With TCPM, the model and controller run entirely on a server, and even the view portion is likely to be directed from there. In a classical client/server model, however, most often nothing but relational data storage resides on the server. In fact, only part of the model

(business logic) actually runs on the server, and the view and controller parts run on the client. A TCPM is far more server-centric than a client/server model.

Platform-Agnostic. Hardware is not the essence of the TCPM, nor is the operating system. The thin model, especially when implemented with Java, is neutral toward hardware and operating systems. Running a JVM on Windows 95/98/NT, UNIX, Linux, or Apple is just fine. So is running it on an IBM NC, a Sun NC, or some other piece of hardware.

Location-Transparent. A smart infrastructure liberates programmers from network and operating system details and lets them focus on what the program does. The main logic of the program should never be aware that it runs on a single machine, in a client/server model, or even in a TCPM. For those of you who have written client/server applications, that might seem impossible.

It Can’t Be That Easy?

The server centricity, platform independence, and location transparency of TCPM may have captured your interest, but we’re also sure you are aware of the following unwritten law: A general infrastructure must do much more than a specialized solution and, therefore, is more complex and slower.

Unfortunately, we cannot provide an unconstrained RAWT solution. The solution must take into account Java’s AWT API and its design and be aligned with the Java development packaging guidelines. Since AWT has not been designed with the three TCPM ideas above (server-centric, platform-agnostic, and location-transparent), these constraints bear a costly contract for the RAWT solution.

For applications based on heavyweight AWT peers, the performance of the current version of RAWT is comparable to that of the X-Window solution (on a PC client). In some parameters (e.g., time to bring up the first window), it even outperforms X-Window.

For lightweight peer-based applications such as the Swing set of Java Foundation Class, the performance with the current RAWT implementation is not adequate for GUI applications. The major reason stems from the requirement to support all Java applications written with Java Development Kit code level 1.0.x and 1.1.x. This imposes on RAWT the task of keeping all AWT objects in the server application host, where AWT events and peer callbacks are handled.

For heavyweight peer-based applications, RAWT can filter out most of the callbacks and AWT event delegation to service them locally. With lightweight peer-based applications, this local servicing becomes significantly harder as lightweight peer components are pure Java classes that override most of the AWT methods. Therefore, RAWT cannot filter out callbacks to these overridden methods, and it pays a high penalty on communication.

In order to further improve performance, it seems that some breakage of the application transparency property is required. A definition of RAWT that allowed user interfaces to be more efficiently distributed to the client in a manner similar to that of a CORBA ORB seems promising. It should be possible to do this with a minimal change to the application while maintaining the ability to display the GUI on any Java client, so the TCPM approach is preserved.

Time for the Next Step?

History, and especially computer history, has a way of repeating itself. Many of the same computing problems have been solved over and over again, first on mainframes, then on midrange platforms, and recently on PCs. The programs and models grow in complexity as they solve ever-larger problems until the complexity of the applications and underlying systems to run them become problems. Then, the cycle starts all over again.

As hardware gets cheaper, the natural desire is to move it ever closer to the user. Well-written client/server applications attempt to split the application correctly so that the desktop user is spared the job change to system operator. However, many times, they fail at this task. Failure results in additional administrative overhead that makes every user a

system operator, with responsibilities for installation of new releases, maintaining security, and backing up system data. The result is that the responsibility for maintaining the system moves with the system’s computing power. The added complexity of having the application take these responsibilities is high, and client/server has been branded as a complex programming model.

We envision the next step in this cycle as the TCPM we have discussed. Client/server is a complex solution to a simple problem: “We need GUI on the desktop and in business programs and control on the server.” We believe that TCPM offers a much simpler and less expensive solution to that problem. Of course, many hurdles must be overcome, the greatest of which is performance. Since the Java and RAWT technologies are new, there appear to be excellent opportunities to improve the future performance without sacrificing the simplicity of the programming model. But, it’s important to remember that new programming models never happen overnight. In the end, it is the application development community that decides if you have to be thin to win.

Acknowledgment

We are indebted to the contributors to the original RAWT project from the Haifa Research Lab: Eyal Zangi, Yosef Moatti, Eran Gal, Alain Azagury, and Hillel Kolodner.

Figure 1: This illustration depicts the Remote Abstract Windowing Toolkit environment as it relates to the AS/400.

Figure 2: This figure displays the generic structure of RAWT on the AS/400 and the associated client requirements and how they fit together.

Figure 3: This a structural view of the clock application IBM used to test RAWT performance. This application was ideal for testing the responsiveness of RAWT.

RMI Category Clock Rate

Penalty

Usage of 1.57 seconds serialization
Usage of 0.20 seconds reflection
Thread context 1.30 seconds preservation
over RMI

Figure 4: The penalties for running the clock application using Remote Method Invocation (RMI) are fairly significant, as this chart shows.

Figure 5: Here’s the screen output from the Java-pure program to display directories. This program was run remotely on an AS/400 using RAWT and locally on a Pentium 200 PC.

Operation Local (sec) RAWT (sec)

Up Directory 0.12 0.38 Repeat 0.14 0.38 Select Directory 0.15 0.29 Repeat 0.14 0.31

Figure 6: This chart shows the performance differences between running the navigation program on a local PC performance and on the AS/400 using RAWT AS/400.

Also Read

Practical Java: Start Your Java Engine!

Practical Java: Making Java Work for You

Book Review: Java for RPG Programmers