The J2EE SIG Presents: A Comparison of User Interface Alternatives

Dr. Paul Dorsey

Dulcian, Inc.

Shay Shmeltzer

Oracle Corporation

About the J2EE SIG

The J2EE SIG is the first SIG jointly sponsored by IOUG, OAUG, ODTUG, and Oracle Corporation. It brings together IT professionals from the entire Oracle community interested in building, administering and deploying better web applications on the J2EE technology stack.

Look for presentations by members of the J2EE SIG at Oracle conferences and user group meetings.

Also, please visit the J2EE SIG web page for links J2EE related resources including the ODTUG JAVA-L List Serv where J2EE topics are discussed: http://www.odtug.com/2005_J2EE.htm

About this Paper

The Steering Committee of the J2EE SIG wanted to prepare a series of “best-practices” white papers. Each white paper would summarize the consensus of the steering committee and propose a standard for J2EE development. Unfortunately, there is not yet even a consensus about what the right questions are, let alone the right answers. We found that, just as there is no clear industry standard for J2EE application development, there was a similar lack of consensus within the J2EE Steering Committee.

Therefore, we decided to publish papers that present more than a single point of view. If people have different opinions about the right answer to a question, each person would be invited to contribute a part of the paper. This way, readers will be able to simultaneously read about multiple perspectives on each question posed.

The committee compiled a list of important questions to answer regarding where the database industry is going with J2EE and other topics of interest to the Oracle user community related to the J2EE technology stack. For the first paper, the committee selected the question: What is the right user interface product direction? (JSP/Struts, UIX, etc.)?

This paper represents two separate viewpoints regarding the approach to building user interfaces for J2EE-compliant systems. The first is provided by Dr. Paul Dorsey, President of Dulcian, Inc. and the chair of the J2EE SIG. The second perspective is offered by the Oracle JDeveloper product management team.

A Comparison of User Interface Alternatives -

Dr. Paul Dorsey, Dulcian, Inc.

One of the most daunting challenges of moving into the world of J2EE web development is the dizzying array of user interface (UI) choices. Currently, there are several competing alternatives that have all been used to successfully (and unsuccessfully) build applications.

To make matters worse, there is a new emerging standard - JavaServer Faces (JSFs) which will likely become dominant in the next year or two. Despite the current buzz that heralds JSF as the next standard for web development before there are any products supporting it, or any consensus from the existing development community, JSFs are still the latest bleeding edge technology. Given the resources and all of the marketing forces behind JSFs, it is likely that this technology will win the day. Personally, I would like to see a working, integrated development environment prior to committing to a technology whose formal declaration occurred only a few months ago. Those of you who attempted to use Struts in JDeveloper 9i are likely to share my skepticism regarding how rapidly JSFs should be adopted.

WHERE DO WE GO FROM HERE?

For those of us who actually have to build systems today and do not have the luxury of waiting for the JSF environment to mature, which direction should we go now?

First, it is important to recognize that there are three independent decisions that must be made when building a J2EE compliant system:

1. What is the UI (View layer) architecture? This is the part of your application where you build the screens and control the ultimate user interface.
2. How will page flow and user interface logic (Controller layer) be controlled?
3. How will you connect to the database?

Rather than trying to provide a series of contingency plans for a matrix of possible environments, I would like to propose a “one-size-fits-all” architecture. For very simple applications, this approach is probably overkill and you could use HTML DB or even .Net and not bother with the infinitely more robust, but more complex J2EE architecture.

1. User Interface (View) Layer

For the UI view layer, use JavaServer Pages (JSPs). Although JSPs are not the easiest structures to work with, they are currently the industry standard. They work well and are robust enough to handle embedding JavaScript to place logic that executes in the client interface. Using dynamic HTML, you can gain even greater control over what is happening on your screens. With a bit of effort, you can achieve near client/server user interface quality.

2. The Controller Layer

For the controller layer, use Struts. The Controller manages the logic of how JSP pages link to one another. It determines what pages are called under what circumstances and controls the interaction with the database during the transitions between pages. All of this logic can just as easily be built into the JSP pages themselves; however, the application will be much better organized if this logic is encapsulated within a dedicated controller.

Just as JSPs are the industry standard for the view layer, Struts is the industry standard for the Controller layer. Struts uses a state transition engine metaphor for managing JSP pages. JDeveloper 10g includes a nice graphical interface to create Struts code. Without JDeveloper or a similarly sophisticated IDE, using Struts may be more trouble than it is worth. Hand-coding of a Struts application is a painful and inconvenient exercise.

3. Connecting to the Database

To connect to the database, use Oracle’s Application Development Framework - Business Components (ADF BC). Currently, manually written Enterprise JavaBeans (EJBs) are most often used to connect classes to tables in the database. In my opinion, this latest industry standard is a mistake. In its effort to avoid any proprietary solutions, the Object-Oriented (OO) community has embraced a culture of inefficiency and complexity that is frequently the cause of many project failures. Oracle’s ADF BC provides a first-rate, sophisticated, and relatively easy to implement solution to allow J2EE applications to connect to the database. This solution supports management of business rules in the middle tier as well as data caching to improve performance.

Given the frequency of project failure guided by development teams trying to do better than Oracle writing their own EJBs, I am dismayed that ADF BC is not being used more frequently. In many cases, much time, money and entire projects could have been saved by using ADF BC rather than hand-coded EJBs.

Where should the business logic go?

It is just as important to understand what should not go into web-deployed applications as what should be included. As long as the development team has some requisite PL/SQL skills and is not attempting to create a database-platform independent system, whenever possible, business logic should be placed in the database, either in functions and procedures, or encapsulated as complex views (perhaps with INSTEAD OF triggers).

As mentioned earlier, JSFs are an emerging standard. It is even possible for organizations to give up and decide to change their entire development platform to .Net. Whether through the evolving J2EE stack or the political arbitrariness of organizations, architectures change. Drastic changes in the UI architecture are protected by placing as much logic as possible into the database. In addition, even though it is logically possible that using ADF BC (where data is cached in the middle tier) may result in some performance improvements over having this same logic placed in the database, in most cases, systems where business logic is stored in the database will outperform those where this same logic is stored in the middle tier. The industry standard (particularly in the OO community) is to pull logic out of the database and place it in the middle tier. Rarely does this strategy have any beneficial impact on system performance.

Other Alternatives

There will always be disputes about the latest technologies. In addition to those discussed here, the Spring framework and Oracle’s UIX/JHeadstart are also competing in the J2EE space. These efforts have not been embraced by the mainstream development community. They should be viewed with skepticism and only used when there is a compelling argument to do so. There is such a compelling argument to use ADF BC. ADF BC has not been embraced by the majority of J2EE development efforts, even within the Oracle community. However, the efficiencies and power of the ADF framework override the often deserved skepticism of using frameworks that do not have a dominant presence in the marketplace.

User Interface Technology Choice for Web-Deployed J2EE Applications – The Oracle Perspective

introduction

The J2EE platform provides a set of low level routines in the form of the Servlet Application Programming Interfaces (APIs ) which allow the programmer to directly construct the output that is streamed to the browser. On top of this basic set of APIs exists a whole hierarchy of convenience layers, which make it simpler to output dynamic content in particular. These layers encompass both the user interface visualization and the Front Controller functionality required for typical multi-page applications.

There are many players in the UI and Controller framework space, some of which serve both functions, some only one. Later on the document we’ll focus on the big fish in this pond, but that’s not to deny the presence of many alternatives.

Fast Forward to The Future

By this time next year, this paper will be effectively obsolete and the discussion contained within largely irrelevant. The industry wide road map for development of thin client applications is very clear. JavaServer Faces (JSF), a standard defined by JSR-127 and accepted into the J2EE 1.5 standard, is rapidly gaining headway as an effective and rich way to develop applications. Within a year we will see JSF support built into many of the mainstream application servers as a core service, and of course design time support will also be available from the various vendor and open source IDEs.

Although, JSF is a standard environment, it is not the only possible standards based stack for enterprise development: Servlets and JSP are, and will continue, to be a part of the core J2EE standards and still be applicable to mainstream development.

It is likely that many smaller frameworks such as Tapestry, Webworks, Velocity and many custom JSP tag libraries will fall by the wayside, and the thin client development space will coalesce into two distinct spheres: JSF and JSP. Of these, the latter will still largely depend on external controller functionality such as Apache Struts or Spring MVC.

The Playing Field Today

So, we have a good idea where the industry will be in a dozen months time or so, but what does this all mean to a developer using Oracle JDeveloper as an IDE and Oracle ADF as a framework today?

Right now, the 10.1.2 release of JDeveloper 10g, provides the developer with the choice to use just about any interface technology or framework that they choose. The IDE and the ADF design time integration provides extra support for developing with both JSP and ADF UIX with visual WYSIWYG design time environments and drag and drop data binding to any business service via the ADF Model layer (JSR-227). Developers are also encouraged to adopt a style of development that utilizes a separate controller for handling page flow, and Apache Struts, as the de-facto standard in this space, is provided along with a corresponding design time environment.

Looking then at the two most common options for Web UIs:

JSP in detail

JSP is a widely used and understood technology. The current generation of tools across the industry provide productive design time environments for JSP with good editors and design time rendering. Much functionality within JSP is provided in the form of sets of tag libraries. These extend the syntax of the JSP markup within the page, to represent data in a richer way and provide other value added functions such as conditional logic, on top of the basic HTML capabilities.

Recent advances in the JSP arena, specifically the introduction of the JSTL tag libraries and the JSP 2.0 specification, have improved the JSP working environment further by reducing the need for 3rd party tag libraries, whilst at the same time making the construction of the same simpler if required.

On the negative side, JSP presents a relatively low level interface into the world of web application development. The programmer is beholden to understand much of the Servlet API, and even with the aid of frameworks such as Apache Struts and Oracle ADF they are not totally shielded from this reality. Once understood, however, this closeness to the low level APIs does provide the programmer with an immense amount of power and flexibility if they need it.

ADF UIX

UIX stands for User Interface XML, rather than being a version of the markup to be streamed to the browser, ADF UIX is a more abstract representation of the page as component model defined in XML. At runtime the actual implementing markup required for the browser is generated from this definition. Such a level of abstraction offers several benefits over straight JSP/HTML.

· The page abstraction is not tied to a particular browser or indeed markup language such as HTML

· The model defines a large set of components which themselves can be rich and complex and result in an actual implementation that consists of both markup, images and JavaScript, all handled transparently by the ADF UIX framework rather than the programmer

· The logical page contents as defined by the XML can be manipulated programmatically before rendering. This allows for applications that can be much more dynamic

· The framework handles page layout through formal components and templates making it simple to swap out the look and feel, encompassing not only the colors and fonts but also the gross layout of the page and styles of buttons and tabs

So ADF UIX provides a very rich and flexible UI creation framework, but is not aligned with any industry standards for UI definition. With the 10.1.3 release of JDeveloper, ADF UIX will be still be available but most developers will probably want to choose the standards based JSF framework for new developments instead.

What Does JSF Bring to the Party?

JSF is in many ways similar to ADF UIX, and this is no great surprise given that Oracle was heavily involved in the definition of the JSF standard. Like UIX, JSF provides the developer with a more abstract description of a user interface based around a component based layout model.

JSF also provides a listener based approach to event handling in the page, this is much more natural for both Java Swing programmers and users of 4GL tools such as Oracle Forms . Code is simply associated with an action event, and the programmer is shielded from all of the low level tasks such as inspecting the Servlet request to detect what events to handle. In fact, JSF is designed in such a way as to insulate the programmer from the whole Servlet API and the loose coupling provided by the JSF abstraction means that JSF is not confined to serving up applications based around HTML markup through a web browser. JSF as a development approach can equally be used to create applications for running on portable devices, phones and even telnet style terminals.

Part of the JSF standard also defines exactly how components for use with the framework should be created. This opens up the market to an influx of components all of which are cross compatible, both with JSF runtime implementations and design time environments. Oracle for instance has already released early access versions of it’s JSF ADF Faces component suite comprising of over 100 components, many of which have evolved from the UIX framework to embrace the new component standard.

Looking even further forward, JSF has one very important strength. With the component based model that JSF uses, it becomes possible for the framework to adapt to newer user interface technologies as they evolve without changing the fundamental page or programming model. There is already a move within the industry towards very rich dynamic html clients using DHTML and XMLHttpRequest. JavaServer Faces is ideally placed to embrace that technology, giving rise to interactive desktop applications running inside a browser but without the need for applets or downloads.

Deciding On A User Interface Technology Today

Now we’ve met the main protagonists in the discussion, let’s return to the question: What technology should I be using today?

These scenarios are based around the following facts and assumptions:

· We’re concentrating on a thin client (no plug-ins) application

· Both JSF and the JSP+Struts development approaches will continue to be mainstream

· ·The JSP + Struts combination will continue to be supported with ADF as long as industry acceptance is widespread

· Full ADF and JSF support will be combined in the JDeveloper 10.1.3 release due this summer

· JSF will become the preferred UI development platform for use with the Oracle ADF framework

Let’s look at a series of common scenarios.

Scenario 1: I don’t use ADF Model data binding

In this case, if you want to start to use JSF then you can do so today, either with JDeveloper 10.1.2 or with the JDeveloper 10.1.3 J2EE developer preview, which provides visual editor support for the JSF Reference implementation and the ADF JSF component set.

Scenario 2: I am already well underway with a project that uses JSP and Struts with ADF

This will be a fully supported scenario in future releases and is already a proven approach to application development. There is no reason to change the technology stack in use.

Scenario 3: I am already well underway with a project that uses ADF UIX and Struts with ADF

As with the JSP case, this configuration will be supported in the 10.1.3 release and so there is no need to revise the technology choice at this time.

Scenario 4: I am about to start a long-term project which will take many months to complete

In this case, you may have the opportunity to wait for the 10.1.3 release for the creation of the user interface portions of the project.

If you have a prototyping phase ahead, consider using JDeveloper 10.1.2 and ADF UIX as a reasonable approximation of the kind of interface that will be achievable with ADF and JSF.

If you are risk adverse and don’t want to use the first release of a new technology combination such as ADF and JSF then you should use the existing ADF + JSP + Struts technology stack on the grounds that this is stable and proven.

Scenario 5: I have a short-term project that needs to be started and completed within the next few months

As in both scenarios 2 and 3 either choosing JSP or ADF UIX are viable strategies. However, much of the decision-making will have to rest on the skills that are available to you and the kind of user interface that you need to achieve.

conclusion

JavaServer Faces is clearly the technology of choice for future thin client application development, however, given the size of the existing JSP code base it is likely that the industry will largely polarize around JSF on the one hand and JSP and Struts on the other. As such a technology decision based on either of these two paths is likely to be a sound one.