Recently, the development of Rich Internet Applications (RIA) using Java 2
Enterprise Edition (J2EE) technologies such as JavaServer Pages (JSP) has been
given a boost with the release of JSP 2.0 and JavaServer Faces (JSF). Add to
that the flexibility of Expression Language (EL), and the J2EE web application
developer is, perhaps for the first time, able to focus on what they are getting
paid for: building feature-rich Internet applications.
Is JavaServer Faces the end of the J2EE web application evolution? Is the rate
of platform changes about to slow down? Is the time right for business developers
on their 4GL client-server rafts to eventually test the J2EE waters? This article
attempts to answer these questions, and give some background to the technologies.
Furthermore it gives a brief overview of JavaServer Faces support in Oracle
JDeveloper 10.1.3 as well as an introduction to ADF Faces.
Java: 3GL World, 3GL Productivity? Not so
The common perception of Java is that it is complex and lacks productivity
features. In fact, the J2EE platform has grown massively since the first release
of Java in 1995 and is still going (J2SE 5.0 and counting). New APIs, the nuts
and bolts of Java programming, are continually being added in all areas. At
the same time, the Java and J2EE developer market is beginning to attract more
and more business application developers who by their very nature are not necessarily
technology purists. This group of developers requires a productive and easy
to learn development environment that allows rapid development of applications
that support business processes. For this type of developer maturity, ease of
use and productivity are more important than technology.
Although there are plenty of J2EE visual editors available today, there is
a scarcity of proven Rapid Application Development (RAD) tools specifically
targeted at the J2EE architecture. Because of this, business application developers
working on client-server applications are finding it extremely difficult to
switch to web development in J2EE. Today client-server RAD tools like Visual
Basic and Oracle Forms still come with clear productivity advantages compared
to what’s available for J2EE. Using RAD tools it is difficult (some would
say almost impossible) to write bad application code, no matter what the developer’s
skill set is. To address the RAD market, the Java industry has invented a new
term, J2EZ, to describe its effort to provide the business application developer
with a J2EE RAD experience: visual, declarative, highly productive. The following
requirements all fall within the J2EZ remit.
Availability of RAD tools
Support for quick application prototyping
High productivity rates for beginners and experts alike
Good abstraction of the J2EE core APIs
Powerful application infrastructure and component architectures
Rich set of UI widgets
Consistent look and feel across browsers and platforms
Client-side integration capabilities
Low level of complexity
That’s the problem space. Let’s now take a look at what currently
exists for J2EE to address these requirements, investigate how JavaServer Faces
fits in, and see if it does indeed come to the rescue.
Model-View-Controller Architectures and J2EE Frameworks
Most modern J2EE web applications are based on Model-View-Controller (MVC2)
[1] architectures. MVC cleanly separates the
three layers from each other to improve application manageability and maintainability.
The Model layer handles the business logic and operates on business data, while
the View layer manages the presentation logic. The Controller layer is the link
between the two and defines their interaction.
J2EE frameworks abstract the J2EE platform and its core APIs, shielding the
application developer from implementation details that normally require expert
level skill sets. Both types of developers, J2EE experts and novices, benefit
from productivity enhancements provided by frameworks. J2EE frameworks exist
as commercial, standard and open source offerings for all layers in a Model-View-Controller
architecture. Apache Struts has become the de-facto standard for the controller
layer, while Enterprise JavaBeans (EJB), Oracle TopLink, Hibernate, Web services,
JavaBeans, and Application Development Framework (ADF) Business Components operate
on the model layer.
Several web development frameworks are available today, but until the advent
of JavaServer Faces there has been no standard framework for building the view
layer. JSF not only provides a solution for the presentation layer, it also
includes a controller for page navigation that can coexist with Struts. With
JSF, the last piece of the RAD puzzle would appear to be available.
Overview of JavaServer Faces
JSF is the outcome of JSR (Java Specification Request) 127 [2]
. In a nutshell, JSF defines a web application framework that consists of a
standard component architecture and application infrastructure for developing
rich web applications. JSF (or simply ‘Faces’) comes with a set
of default UI components that the developer can extend with custom components.
To quote the JSR 127 specification:
“JavaServer Faces (JSF) is a user interface (UI) framework for Java web
applications. It is designed to significantly ease the burden of writing and
maintaining applications that run on a Java application server and render their
UIs back to a target client.”
Common web application development problems for which JSF provides elegant
solutions include:
state management
error handling
input validation
type conversion
event handling
page navigation
State management – UI components in JSF are represented by server-side
Java objects. This allows the framework to save and retrieve the component state
across page requests in a server-side component tree. In other words, state
information no longer needs to be passed along with the request using hidden
fields or session cookies.
Error handling – Depending on the severity and type of error,
the response to it may vary, but at least a sensible error message usually should
be shown to the end user. The JSF framework has several points within its page
request processing lifecycle that can raise errors and display consistent error
messages.
Input validation – Input validation can be programmed in UI components,
back-end code, or more commonly in separate Validator classes. Validators in
JSF are optional classes that can be plugged into UI components on the server
to evaluate the correctness of user input. Because validators are separate classes,
they can be reused and shared across components.
Event handling – A powerful component event model is missing in
today’s web application frameworks and technology. JSF provides a component
event model that is similar to the JavaBeans event model in J2SE Swing, except
that events are handled on the server and not on the client. Because the event
model doesn’t require the HTTP protocol, it works independently of any
protocol used.
Type conversion – Converters are pluggable classes that can be
used with UI components to transform the display type (typically String) to
the data type of the component. Before converting a data type, the converter
performs syntax validation to ensure that the user enters the correct format
for the value. Default converters exist with the core installation of JSF.
Page navigation – JSF provides an event-driven page navigation
model that allows application developers to design the page flow of an application.
In the same way as Struts, all page flow information is defined in the JSF configuration
XML file (faces-config.xml) as opposed to being hard-coded in the application.
Equivalent to the Struts Action class that could be used to dynamically change
the default page flow, JSF can use the return objects (String) from methods
defined in the backing code to change the default page navigation sequence.
JSF avoids the complexity and programming inconvenience of the HTTP protocol.
The latter was never designed for handling rich Internet applications and to
do so requires a deep understanding of its request and response lifecycle to
effectively program web applications. JSF masks the HTTP protocol in the JSF
framework, transforming the request-response model into a highly interactive
component-event model. Developers no longer have to think in terms of request
and response objects but can think in terms of components and their events.
Developing JSF applications is more about assembling and configuring pre-fabricated
components than programming against low-level APIs. Similarly, UI components
are modified by setting their properties rather than hand-coding changes to
the DHTML, CSS or JavaScript code that compose a specific web component.
JSF conforms to the JavaServlet specification, and JSF applications execute
in a J2EE container on the server. UI components in JSF are server-side objects
that render back to the client using external renderer classes. This allows
a JSF application to be developed for different output devices (for example
browsers, PDAs, smart phones) without having to change the application itself.
Renderer classes on the server are responsible for displaying the UI in a format
that is understood by the target device. A renderer kit for HTML is provided
with the core JSF release. Other output devices need to be supported through
commercial or open source renderer kits or custom developments.
Inside JavaServer Faces
Most web application developers, especially those with a RAD development background,
don’t really need to worry too much about what’s happening below
the surface. For those interested, this section provides a brief overview of
how things work together. Most of the detail should be handled automatically
by the development tool or done declaratively by the developer. You might even
begin to see similarities between this approach and your favourite 4GL!
Technically, a web page in JSF is represented by server-side Java objects and
the UI components. Similar to the Document Object Model (DOM) in browsers, Faces
pages exist on the server in form of a component tree, the view. The state information
is either kept on the client or the server and can be changed through configuration.
Within the tree, each component is addressed by a unique identifier and can
have child-components of it’s own. For instance, take the case of a toolbar
component that consists of a panel and several button elements. Adding this
toolbar to a JSF page will make the toolbar panel a child of the root tree,
with the toolbar buttons being children of the toolbar panel.
UI components are reusable JavaBeans that define the behaviour of a component
through properties and that can optionally be associated with backend data.
To associate a UI component with a property of a backing bean, JSF supports
Expression Language. The EL used in JSF is currently not the same as in JSP
2.0, but this is subject to change with the next releases of JSF and JSP (JSR
252 ) [3].
UI components typically are display-agnostic. JSF delegates the display of
a UI component to specific renderer classes. Renderer classes by default exist
for HTML in JSF, but can also be created for any other output device. Renderer
classes are organized in renderer kits. These are groups of renderer classes
focusing on a specific type of output.
Figure 1: JSF architecture
Backend code in JSF consists of backing beans along with helper classes such
as validators and converters.
Backing beans are specialized JavaBeans that handle the data exchange between
the business model and the UI component. JSF uses its own EL value binding to
associate a UI component to a property on the backing bean. A backing bean can
have a connection to the data model to retrieve and store data. By handling
the interaction between the view and the model, backing beans also take on part
of the role of the controller. Unlike Struts, JSF has a pure page-oriented navigation
model. If you need to you can combine the Struts navigation model with JSF because
non-JSF interaction (both request and response) are fully supported. An integration
library already exists for this.
JSF has a strongly typed event model that is based on the JavaBeans event listener
model. Typically backing beans contain event handler methods that are called
by component listeners as a response to specific event occurrences. Standard
events in JSF are action events, value-change events, data model events and
phase events. An event is similar to a trigger that fires on a certain condition.
Interested parties can register event listeners using a component to receive
event notifications. For example, a command button raises an action event when
pressed. This event is recognized by registered action listeners that process
the response directly or call event handler methods. Events are executed on
the server and thus don't involve the HTTP protocol.
The JSF framework itself raises events during the request processing lifecycle
that consists of six individual steps:
restoring the view tree
applying the request values
processing validations
updating the model
invoking the application
rendering the response
Application developers can register listeners for each of these events to execute
custom code where needed, or to add extra messages.
JSF Integration in Oracle JDeveloper 10.1.3
Oracle believes that JSF as a technology will increase J2EE developer productivity
to a level close to that which tools like Visual Basic and Oracle Forms provide.
Oracle also believes that JSF will deliver on the rich web client promise by
providing high quality feature-rich UI components.
Oracle JDeveloper 10.1.3 Developer Preview, which is currently available for
download on OTN [4], provides a comprehensive
and visual development environment for JSF. It provides a visual page flow editor
that can be used as the starting point for each application development. The
visual page editor is synchronized with the faces-config.xml configuration file.
All pages and page flows are visually designed in this environment. Selecting
the overview tab on the page flow editor allows developers to access and edit
several configurations of the JSF configuration file visually. This includes
all the available JSF components including those discussed above, such as backing
beans, validators, converters and the life cycle.
A JSF page can be visually edited using the integrated visual page editor in
Oracle JDeveloper 10.1.3, which is opened by a double click on a page symbol
in the visual page flow designer.
Oracle Application Development Framework and ADF Faces
Oracle Application Development Framework (Oracle ADF) is a comprehensive J2EE
design time and runtime framework that is based entirely on industry standards.
Oracle ADF provides a common data binding based on JSR 227 [5]
for most of the common business services like EJB, TopLink, Web services,
POJOs [6] and ADF Business Components. Using
Oracle ADF, application developers can build applications on top of different
data models without needing to deal explicitly with their implementation details.
JSF as a technological concept will not be entirely new to Oracle JDeveloper
users because it’s similar to Oracle’s ADF UIX framework. As an
active member of the JSF specification group, Oracle contributed to the development
of the current JSF specification.
ADF Faces is a set of JSF standard components that are built on top of the
JavaServer Faces APIs. The next version of Oracle ADF will include ADF Faces
and will also provide enhanced data binding (JSR 227) support to ADF Faces.
You can download an early adopter version of ADF Faces [7]
components and an ADF faces cache tag library [8]
from OTN.
Oracle ADF Faces brings more than a hundred rich UI components to JSF, including
some that are not contained in the original JSF specification. For example,
ADF Faces provides calendar picker components, color pickers, bi-directional
support, and a consistent look and feel on the client, as well as client-side
validators and converters. The plan is to bring rich-client functionality to
Internet clients; this includes interactive menus and trees as well as partial
page rendering to improve web application performance. In addition, ADF Faces
components all support internationalization.
ADF Faces, in combination with Oracle ADF and the Oracle JDeveloper IDE is
about to provide a compelling RAD development environment that brings web application
development in J2EE to the next level.
Conclusion
JavaServer Faces is a new view-controller framework and is the natural evolution
of JavaServer Pages. Though new as a technology, the JSF developer community,
including major software vendors like Oracle, IBM and SUN, as well as open source
projects like MyFaces [9] , has grown quickly.
Extended rich sets of JSF components as well as visual RAD tools for JSF already
exist with Oracle ADF Faces and Oracle JDeveloper 10.1.3 being a prime example.
For business application developers JSF promotes declarative development by
component assembly, which is pretty much the RAD approach of today’s client
server tools.
JSF is a milestone reached in building RAD style web applications and provides
a great opportunity for every developer to start building J2EE applications.
The most compelling argument for this is that your JSF skills grow with the
platform itself while still being able to leverage your existing 4GL skills!
Oracle ADF Faces is a set of JSF standard components that are built on top
of the JavaServer Faces APIs and is currently available as an early adopter
release on OTN. ADF Faces and its forthcoming integration with Oracle ADF (which
includes an early implementation of JSR-227) will make Oracle JDeveloper 10.1.3
a comprehensive, and most likely the first, end-to-end RAD tool for building
rich Internet applications based on JavaServer Faces and MVC.
JDeveloper pages on OTN: http://www.oracle.com/technology/products/jdev/index.html
JSR 227: http://www.jcp.org/en/jsr/detail?id=227
POJO: Plain Old Java Objects. A term coined by Martin Fowler, Rebecca Parsons,
and Josh MacKenzie. For more detail see Martin Fowler’s blog at http://www.martinfowler.com/bliki/POJO.html
Oracle ADF Faces Components, Early Access Release:
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html,
How To Use Oracle ADF Faces Cache Tag Library With JDeveloper 10g: http://www.oracle.com/technology/products/ias/web_cache/afc-10gjdev.htm
MyFaces Open Source Project: http://www.myfaces.org/
Bookmark
