02
Sat, Nov
2 New Articles

IBM Explains How to Use the Remote Abstract Windowing Toolkit (RAWT)

Java
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.


IBM_Explains_How_to_Use_the_Remote_Abstract..05-00.jpg 600x465

IBM_Explains_How_to_Use_the_Remote_Abstract..06-00.jpg 600x465

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


IBM_Explains_How_to_Use_the_Remote_Abstract..07-00.jpg 600x465

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.


IBM_Explains_How_to_Use_the_Remote_Abstract..08-00.jpg 601x472

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.


BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: