|Java GUI - JSP, Struts, JSF, etc|
Feature: Java's Web Presentation Layer options have
grown in richness
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:
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
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.
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.
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).
JSF - Java Server Faces
Java Server Faces were designed to allow for a much richer set of GUI components
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:
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.
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.
But another interesting phenomena is occurring which has been subtly hinted
at in this article. We have used four different Java IDEs
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:
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".
Top of Page Home Tutorials