Feature: Java's Web Presentation Layer options have grown in richness
Motivation: Creating Java Web interfaces means deciding among Java GUI options

The Presentation Layer of programs that controls input/output and program flow of control (think GUI interface for many programs)has always been an area of software development subject to the sweeping tides of hardware change and client-server design. Sometimes all the input and output processing is done from a central program(think games, Microsoft Word, Adobe Photoshop, Apple Garageband and tens of thousands of personal computer programs). And other times the GUI interface is downloaded from one central server to one or hundreds of smart clients and executed locally (think Lotus Notes, Cognos ReportNet, Oracle Applications, etc, etc).

This pendulum swing goes all the way back to the days of timesharing systems in the late 1960's and early 1970's where input and output to line terminals really blossomed(replacing punched card readers). But when IBM introduced the 3270 terminal, with its onboard smarts for displaying fields and doing simple validations, significant chunks of processing went over the wire and were distributed down to the smart terminal for local processing and faster response times. Then in the early 80's with the rise of the personal computer, most of the I/O processing was again done locally by the program on the PC. However with rise of LANs , the tide shifted again and presentation was distributed between the server program and connected PCs. The rise of the Web in the 90's just made the server more remote - not necessarily on the LAN but anywhere in the world with a big enough server and a fast enough Internet connection.

The big advantage of the Web interface are a)the same, common Web fields and components that everybody knows how to use; b)ability because of the browser interface to run on many different desktop operating systems and devices; c)one central point of deployment and upgrades. This latter point is not small as shops with 100s to 1000s of users present a formidable task of keeping all on the same coding page.

Now the latest Web based applications present developers with a new set of Presentation Layer Problems:
1)multiple device support - a central server is generating the interface for potentially many different targets- a PC, a PDA, a Mobile phone, an embedded processor and display - each of varying display dimensions and processing capabilities;
2)multiple operating environs - the central server may be transmitting through to the same devices but diverse client environs with different connections, storage capacity, and operating system support and functionality;
3)offline operations - the client may want to work offline with the same functionality, including GUI look and feel, as they get in the online sessions;
4)network latency/roudtrip delay - the client will want to minimize the amount of delays and waits associated with refreshing screens and change of state processing - network traffic has to be minimized or made transparent;
5)same service level - system administrators want to be able to deliver the same security, reliability, availability and response time that users on the local LAN get;
6)ease of admin - system administrators want better management of the server software that delivers the n-tier applications. Admin and operations people the same ease of instant, on-demand centralized updates that prevents the problems of diverging local copies processing the same data differently.

These are an imposing set of demands for service that leave developers sometimes with near mission impossible sets of requirements. Lets look at the Java Web Presentation Layer solutions to these problems.

Java Web Presentation Tools

Java applets were originally designed to handle these Web presentation problems - and applets were close to an ideal solution because they brought the requisite security, functionality and cross platform performance to just about any client. But Microsoft had other ideas and thwarted the use of Java applets by imposing an obsolete version of the JVM on their operating system users knowing full well those users would not bother to download the latest JVM. Unfortunately, the IT community caved into Redmond's blackmail and neither the ISVs (many of whom have profited mightily from their other Java offerings) nor the major IT users (who have suffered the consequences because the Microsoft solution, ActiveX, has been full of security holes and interoperability deficiencies) called Microsoft's bluff and said if you do this we will pull your browser and other software from our systems. But as we shall see, in a touch of irony, applet-like solutions are starting to comeback.

So what Java has delivered over the past 5-7 years is successively more refined, central server based Web resonation capabilities. It all started with Java Servlets which still are

                Figure 1 NetBeans Java IDE used for Java Servlet development
used in applications coded with Java Servlets. Servlets are Java programs running on a central server that generate HTML pages which are passed on through any HTTP Web server ( Apache, IIS, Netscape, Zeus, etc) to a client browser. When the user is finished interacting they send a reply back thru the HTTP Web which is directed to the appropriate Servlet process with an appropriate Request. The central Servlet can then talk to other central application server(s) and databases on behalf of the web client picking up data, modifying it or even adding/inserting into appropriate database tables and/or files. So Java servlets substantially enhance the smarts of the Web Server by a simple pass through mechanism. The Web Server is devoted to directing traffic to and from the various subscribing Servlets and other server programs.

This is effective for performance reasons because it simplifies load balancing, caching, and identity/security operations. In effect, Java Servlets solve a number of the Presentation Layer Problems by delivering point (2)the same Web experience to any browser on any operating system on any PC (but not any device in early versions). Servlets also deliver points (5) and (6) central service responsible for most of the systems reliability, security and performance while considerably simplifying updates because they come from one source, the centrals server. As we shall see Java Servlets form the base model for Java interface development on the Web.

JSP - Java Server Pages
JSP-Java Server pages are designed to enhance substantially Java Servlets by creating

                         Figure 2 - Eclipse Java IDE with Nitrox JSP editor plugin
tags, scriptlets, and Beans that are embedded in an HTML page on the JSP Server and are preprocessed into Java Servlet code and then into final HTML pages ready to be served to the client. So what is gained by adding a pre-processing step ? JSP scriptlets and tags are much easier to code by web developers because they look like special HTML tags. So in the Hello World example the following JSP code:

<html><body>
  <h1>Hello World</h1>
   Today is <%=new java.util.Date().toString() %>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-4281076-1");
pageTracker._initData();
pageTracker._trackPageview();
</script><script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-4281076-1");
pageTracker._initData();
pageTracker._trackPageview();
</script></body></html>

gets converted into approximately 40 lines of Java Servlet code. In sum, JSP simplifies substantially writing Java Servlets. It allows programmers to setup the tags and code while web developers can write and/or modify the HTML markup. JSP has been so much simpler such that it made it more tenable to add support for mobile phones and other devices to the Java Servlet set of input/output devices. Thus JSP starts to address the multiple device point (1) of the Presentation Layer Problems while continuing to preserve (2) multiple environ support. Finally, JSP also helps to simplify aspects of the EJB processing and database connectivity strengthening Java's options at backend operations.

But even with JSP, developing and structuring multiple HTML pages with complex interactions has proved very challenging. This difficulty has required an organizing design framework - enter the open source Apache project with its Jakarta Struts package.

Jakarta Struts

                                 Figure 3 Exadel Eclipse Java IDE with Struts support
Struts is above all an organizing structure for use of JSP and Java Servlets - the so called model 2 or MVC-Model-Viewer-Controller. Struts provides a framework using XML, JSP, and JavaServlets together for delivering web applications. Think of the MVC framework -Model (think backend operations and metadata), Viewer (think the initial through final target HTML page layout and design) Controller (think the Java Servlet and JSP tags and scriptlets) coupled with XML configuration files as organizing JSP development and allowing for declarative changes/configuration through the XML config files.

Because designing with JSP and Java Servlets affords developers a universe of diverging options, Struts helps by putting an organizing and standard framework around JSP and Java Servlet coding. And in the process, Struts certainly helps to add more effective development of JSP Presentation Layers and thus preserves JSP as a solution to (5).

But Struts very success underlined three problems with Java Web applications. First, the richness of UI widgets and components available was limited to the the standard HTML form widgets. Second, Struts enabled UI widgets are restricted in their ability to respond to client side events and specific device and/or OS platform capabilities or lack thereof. Third, Presentation Layer Problem of offline operation and network processing delays are not being effectively addressed by Java Struts solutions except perhaps those using Javascripting options. Enter JSF-Java Server Faces.

Tools supporting Struts:
Borland JBuilder Enterprise Edition 2005
Eclipse with Exadel Studio IDE
Eclipse with Nitrox Struts IDE
MyEclipse with Struts Designer
Oracle's JDeveloper IDE

JSF - Java Server Faces

Java Server Faces were designed to allow for a much richer set of GUI components and

            Figure 4 - Oracle JDeveloper IDE using Apache's MyFaces components
and events. It also was a response to the success of Microsoft's WebForms as implemented in Visual Studio - WebForms offered a richer set of GUI components for Web developers. Here is what Sun says about the purpose of JSF:
"Java Server Faces technology simplifies building user interfaces for Java Server applications. Developers of various skill levels can quickly build web applications by: assembling reusable UI components in a page; connecting these components to an application data source; and wiring client-generated events to server-side event handlers".

So JSF is not only about events and mapping them back to Server-side event handlers but also making the connection to backend data sources simpler plus starting to address response time and screen refresh issues with local validators coupled with more general server side routines.But JSF does not make a dent in offline operation and has yet to be applied to multiple devices except in very specific solutions. So JSF starts to address two more Java Presentation issues while not losing any ground on what JSP and Struts already deliver. This should not be a surprise as JSF has on board some of the key designers of Struts and JSP.

Finally, JSF has been designed with the idea of making its UI components as universal as possible. Thus one design declaration may have several different device specific implementations, with JSF responsible for much of the plumbing of sending the right component to the associated requesting client device. This is the ideal - the pragmatics is that even mobile phones and PDAs have yet to see major JSF implementations(although Oracle is working on it).

Tools supporting JSF-Java Server Faces:
Borland JBuilder Enterprise Edition 2005
Eclipse with Exadel Studio Pro IDE
Eclipse with Nitrox JSF IDE
IBM Rational with JSF Support
Macromedia Dreamweaver with JSTL & JSF extensions
MyEclipse with JSF Designer
Oracle's JDeveloper IDE
Sun's Java Studio Creator

But even with these extraordinary advances, the Java Web platform is not yet addressing the issues roundtrip performance delays or of offline and online operation as effectively as rival Macromedia Flash, Adobe XDP super-forms (based on PDF design) or Microsoft Smart Clients. So Java ISVs have come up with some very interesting solutions - its Back to the Future.

Java UIs : Back to the Future

In order to address the Presentation Problems (3)online and offline operation plus (4) better response over the network response time while not losing the hard earned other 4 problem point solutions, innovative Java ISVs have been going Back to the Future - using the JVM in novel ways.

                                        Figure 5 - Borland JBuilder IDE using Droplets
By tapping into a JVM in novel ways, all of the solutions below preserve solutions to Presentation Problem points (1), (2), (5), (6); but now are able to address directly problems (3) offline/online operation and (4) better response time by minimizing network traffic. Because the JVM affords huge validating and display options and its security model allows strict and secure access to files and data both locally and remotely - these latter problem points are effectively addressed. Here is a summary list of the major rich client Java players:

Altio Live - uses an applet that is JVM 1.1 compatible (think Microsoft's JVM) to perform client side operations, communication layer for efficient crosstalks and XML backend.
Canoo ULC - uses an Ultra Light Client of Swing classes that are tied back into J2EE server through diverse communication channels to help optimize traffic.
Droplets - also uses a smart Java Server and thin communication using XML to maintain minimum possible transmissions between client and server.
Insitech XTT - uses Java Swing on the Client with XMLHTTP for asynchronous tunneling back to its Java-based director server which calls through Web Services and a variety of protocols
JDNC - is a Java Open Source project that defines a rich set of Web components that can be used in standalone applets as well; uses Swing classes and Web Start JVM
NexaWeb Technologies - uses very thin J2ME equivalent on client driving Mozilla XUL with its own Java Server to allow for targeting any data source delivery to any data device.
RSWT - is another open source Java development tools that uses a Java Server to communicate with minimal impact but high local GUI fidelity
Widget Server (WiSer) -is a Java/XML server-side GUI-framework which enables an application to run as either
- a monolithic application with a Swing GUI,
- a client/server application with a thin Swing client,
- or as an application with a rich Web client based on HTML and JavaScript
Covering all the online and offline bases in the process.

This a a partial list of the rapidly evolving Java Rich Internet Clients. But Java is not the only solution space for these Rich Internet Clients. Macromedia and Laszlo have been using Flash as the GUI front-end and a variety communication methods including compression technologies and Web Services to talk to the backend Java Servers. And there is the whole set of Java-based (Jython, Groovy, etc) and other scripting language like PHP, Perl, and Python that are sporting ever more capable local client machines.

But another interesting phenomena is occurring which has been subtly hinted at in this article. We have used four different Java IDEs
- Borland JBuilder
- Eclipse Java IDE
- NetBeans Java IDE
- Oracle JDeveloper
(and there could have been a dozen more)to showcase the different Java presentation layers solutions. The Java developer space is alive with very good options for development from GUI IDEs to Wizard and Refactoring developer environs through to MDA and other code generation tools. The presentation layers solutions do not lack for good overall Java development tools.

Summary

Java has had a diverse set of solutions for the GUI and presentation layer. Now users are saying to vendors provide us with both - online central server based tools that minimize upgrade hassles; but also rich client side interfaces with offline as well as online operation. This is a very formidable task. It looks like basic JSP and Struts user may be giving way to the new and more versatile JSF-Java Server faces. But even JSF does not meet all of the new GUI/presentation layer

CIOs and Enterprise Architects are going to have to make organizational commitments to an IT architecture and solution space in which the Presentation layer is a critical component. Their decisions may turn on the following logic:

Microsoft has yet to deliver a secure and reliable desktop operating system and has proved itself to be a vigorous if not vicious defender of its market positions. This means Redmond will act in the interest of maintaining its monopolies over and above all. This in turn means that a latest Sun JVM on the desktop delivered by Redmond and the chances that the new IE 7 due out by Summer 2005 will have major standards improvements (JavaScript 1.4 with E4X extensions, full CSS 2 and DOM 3 plus SVG, and XForms - all currently delivered by Mozilla) are about as likely as Longhorn being delivered in 2006 with the same reliability, security, and performance form factor of say Windows 2000 or XP.

Meanwhile given that the mobile, embedded and PDA/tablet markets represent some of the largest market growth and opportunities for lower cost of business productivity, we would like our desktop and Web systems to be able to reach these devices and markets with the least amount of retooling. The question then becomes - can Java which has serious J2ME and mini-sized Java Swing and JSP efforts in these mobile/embedded/PDA/tablet markets make its Struts, JSF, or even Swing/AWT/SWT Web GUI layers fit and integrate together in an effective way? Or are we back to looking at AJAX-fortified JavaScripting, Flash-based rich clients or - horrors - Microsoft Smart Clients ?

These are tough architectural questions - because fast evolving tecnologies such as WiMAX; smart, huge-capacity, small power+size, portable iPod-like data containers; and the ingenuity of hacker and fraudsters tend to rapidly obsolete and turn topsy turvy GUI interface and Presentation layer assumptions. But one would think that the open, cross platform and fairly interoperable/interchangeable Java solutions with the added value of much testing, rich features, and many competing approaches - these would hold sway over the 1 Microsoft Way => "it should eventually run best on Windows ... but don't look to EULA for any relief if it does not".