Jeffrey Liu

Subscribe to Jeffrey Liu: eMailAlertsEmail Alerts
Get Jeffrey Liu: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

Understanding JavaServer Faces

Assemble your Web applications effectively

The Internet has no doubt become the most popular source of information today. More and more businesses have adopted the Internet as the vehicle to display their business information, advertise their products, and maintain customer interactions. The activity of developing Web applications occupies a fair amount of resources, time, and effort. Doing so in an efficient and timely manner directly contributes to a business's success.

In the past, technologies such as JavaServer Pages (JSP) have provided a primitive approach to develop HTML-based Web applications using Java. However, they have failed to provide a standard and reusable UI framework. The JavaServer Faces (JSF) technology offers a standard and effective way to manage and develop reusable UI components, which together assemble a Web application. This article examines JSF technology in both the business and technical horizons. You will be presented with the benefits of JSF and a scenario demonstrating the JSF support in the IBM WebSphere Studio Application Developer product.

JSF: A Business Perspective
The Internet formulates a virtual environment for companies to conduct their business. More and more companies have exploited the Internet as a means to gain a competitive edge. Through the use of the Internet, companies can increase visibility, increase accessibility, and at the same time, reduce cost, which allows for greater profit and success. In this digital marketplace, a company's Web site represents its value and serves as the starting point for customers to learn about the company. Companies spend thousands and thousands of dollars to research, design, and implement their Web sites, using them to advertise their products, carry out their day-to-day businesses, and service their customers.

As a company grows, its Web site must grow along with it. Specifically, a company's Web site must reflect the latest development of the company. This can be an announcement of a new product release or the addition of a new service. The former may require as little effort as adding a few Web pages and links to the Web site, while the latter may require substantial effort by adapting to the business logic that the new service offers.

The ability to rapidly develop a Web site to support business changes poses a challenge to many companies. Consequently, a reusable, scalable, and extensible user interface (UI) framework for developing Web applications is undoubtedly desirable. In the Java domain, such a framework did not exist until the introduction of JSF, which serves as the strategic solution for developing Java Web applications.

In today's customer-oriented economy, even the best technology does not guarantee market acceptance. Factors such as benefits to business, cost of adoption, and availability of service and support from tools influence a business's decision on whether or not to adopt a new technology. Businesses must understand the implications of a new technology on each of the above concerns.

JSF provides a UI framework that eases the process of designing, developing, and maintaining Java Web applications. JSF brings out the notion of roles in Web development, clearly defining a separation between business logic and presentation logic. This allows the UI (i.e., Web pages) to be developed independently of the business logic, enabling a loose coupling between presentation and business implementation. This, in turn, improves reusability. Previous technologies such as JSP and servlets fall short of reusability because of the mixed usage of UI-centric language HTML and the application-centric Java language in the source files. JSF eliminates this problem by defining different roles in Web development. These roles are page author, component writer, application developer, tool provider, and JSF implementor.

Page authors, who are fluent in markup and scripting languages such as HTML and JavaScript, specialize in the creation of the user interface. They focus on the visual design of the Web application, and are responsible for assembling the user interface using components provided by component writers.

Component writers create reusable UI components, which are Java classes that represent UI controls, such as an input text field on a HTML page. Component writers are also responsible for supplying a render that transforms a UI component into a format that the clients expect, such as HTML.

Application developers provide the underlying business logic. This can be an Enterprise JavaBean (EJB) component that exposes the application functionalities. Application developers are proficient in programming languages such as Java.

Tool providers and JSF implementors are not directly involved in the development of the Web applications. Typically, they are vendors, such as IBM, that provide the development tools to assist in other roles in developing JSF-based Web applications, and provide the platform to run those applications.

Unlike the JSP and servlet technology, such a role-based architecture does not require developers to be skilled in both markup/scripting languages and application programming languages. This architecture allows developers to specialize, to have a field of expertise, which results in greater productivity, better code maintenance, and shorter development cycles. With JSF, businesses may also be concerned about the effort to port existing code such as JSP to the JSF framework. In fact, existing JSP components can coexist with any JSF-based Web pages within the same Web application.

To make JSF more intuitive and appealing to potential users, tools that support the JSF technology play an important role in assisting novice users. Because the majority of the learning effort lies within the JSF syntax, the business incentive to adopt JSF blossoms if development tools can hide the complex details of JSF from the users, offering easy-to-use features such as drag-and-drop action for UI components, lowering the barrier of entry.

JSF: A Technical Perspective
Web development on the Java 2 Enterprise Edition (J2EE) platform has evolved from a primitive approach - servlet technology - to a more architectural approach such as that used in JSP components and the JavaServer Tag Library (JSTL). This transition has dramatically changed the development environment from one that fuses Java and HTML together to one that provides better separation between writing UI and application code. Things are moving in the right direction, but they have yet to fulfill the increasing business demands on Java Web development. Even when using JSP and JSTL technology, Web developers are often required to create their own frameworks to support their Web applications. JSF recognizes the lack of a reusable UI framework with current Java technologies, and therefore offers a standard to ease such effort.

JSF employs an entirely new concept of building Web applications in the Java domain. The design of JSF utilizes a meta-model, which is a collection of UI components, to continuously represent the current state of the client UI. This is quite the opposite of the way previous technologies worked, in which a thin-client approach was used to maintain a stateless client UI. The use of a meta-model grants JSF-based Web applications the same capabilities of state management, event handling, and validation that thick-clients such as a Java Swing-based applications enjoy.

As discussed earlier, in the world of JSF, presentation logic and application logic can be developed independently of each other. However, a Web application cannot be deemed complete until these two pieces are combined. This involves the binding of application data, such as a JavaBean field, to UI components. The synchronization between application data and the client UI is handled by the JSF engine provided by the JSF implementor. In addition to data binding, JSF also allows other types of connections, for example, an association of a JavaBean method with a UI action. These connections are described using XML markups in faces JSP files, making these files free of scriptlets, which in turn increases readability. In Figure 1, we illustrate the faces request processing life-cycle.

Similar to other HyperText Transfer Protocol (HTTP)-based Web applications, the faces request processing life-cycle begins when a client makes an HTTP request via a Web browser. Such requests can be categorized into two types: non-faces request and faces request. A non-faces request originates from a non-UI component. For example, the client enters a Uniform Resource Locator (URL) into the browser and loads a faces JSP file. A faces request originates from a UI component such as a faces submit button. In a typical faces request scenario, the life-cycle goes through six different phases:

  • Restore view: Upon receiving a faces request, the JSF engine retrieves the faces context instance associated with this user session. The faces context instance contains a view (collection) of UI components that represents the client-user interface.
  • Apply request values: In this phase, the states of the UI components are synchronized with those on the client-user interface. This is done by reading the appropriate data from the HTTP request, such as headers and parameters. As part of the synchronization, events may be triggered, and the registered event handlers will be invoked. This enables server-side event handling for client-generated events. Such an event model is something that previous tech nologies did not possess.
  • Process validation: After setting the states of the UI components, validator instances registered with each UI component are triggered. Errors are immediately reported back to the client.
  • Update model values: The purpose of this phase is to update the application data, changing the value of a JavaBean field, for example.
  • Invoke application: The invoke application phase processes the action submitted by the request, such as invoking the JavaBean method associated with the submitted action.
  • Render response: This is the final phase in the faces request processing life-cycle. This phase transforms the UI components into a format that the client expects, such as an HTML document.
JSF Support in IBM WebSphere Studio Application Developer
The WebSphere Studio Application Developer version 5.1.2 marks a significant milestone in developing Web applications on the J2EE platform. It not only provides support for the JSF specification version 1.0, but it also allows seamless integration between JSF and other tools.

Application Developer provides a wizard to guide the user through the creation of a template faces JSP file. This wizard automatically generates the essential faces artifacts, which include the faces servlets in Web.xml, the JSF configuration file faces-config.xml, and a managed bean. The javax.faces.webapp.FacesServlet faces servlet listens for incoming requests and initiates the faces request processing life-cycle. The faces-config.xml file defines configuration settings such as the managed bean facility. The managed bean facility contains one or more managed beans, which serve as the integration points between the presentation logic and the business logic. This wizard serves as a starting point for developing a JSF-based Web application. Other JSF-related tools can be found in the Web perspective, as shown in Figure 2.

From the palette view, users can drag and drop various UI components onto the faces JSP file. Upon dropping a UI component, the XML markup in the faces JSP file and the corresponding Java code for the UI component in the managed bean are automatically generated. This shields the users from the complicated details of JSF.

To leverage the potential of JSF, WebSphere Studio Application Developer provides support for more than just the standard set of UI components. It also makes available other custom UI components, as well as integration with other tools, such as Web services. The Web Service Discovery Dialog demonstrates such integration by allowing users to discover a Web service, generate a JavaBean client for that Web service, and drag and drop the corresponding Web service operations onto a faces JSP file. Figure 3 shows the discovery of a temperature Web service using the Web Service Discovery Dialog.

Upon discovering a Web service,the generation of a JavaBean client is just one click away. This temperature Web service has a single operation that takes in a getTempParamBean as input and returns a getTempResultBean as output. As shown in Figure 4, these two parameters, which can be found in the page data view, have been dragged and dropped onto a faces JSP file. In addition, a submit button, which is bound to the Web service operation, is also generated. When a user clicks on this button, a faces request containing the value of the getTempParamBean is submitted to the faces servlet.

Now, let's uncover the underlying details of the tool. As part of dragging and dropping a parameter, the tool will generate the XML markup in the faces JSP file and the UI component in the managed bean. Listing 1 shows the XML markup for the getTempParamBean parameter, Listing 2 shows its corresponding UI component, and Listing 3 shows the associated application data.

The value attribute of the <h:inputText> element in Listing 1 defines the value binding between the zip code field of the getTempParamBean and the HtmlInputText UI component. Besides the value binding, there's also an action binding shown in Listing 1. The action attribute of the <h:commandExButton> element defines the binding between the doGetTempAction method and the HtmlCommandExButton UI component. During the faces request processing life-cycle, specifically in the apply request values phase, the value of the HtmlInputText UI component is synchronized with the value submitted in the HTTP faces request. Next, in the update model value phase, the zip code field of the getTempParamBean is updated with the value of the HtmlInputText UI component. In the invoke application phase, the submitted action is then processed. The doGetTempAction method is called, in which the temperature Web service is invoked. Figure 5 shows the result of using this faces JSP file to invoke the temperature Web service.

Conclusion
As demonstrated, to manually develop and assemble such applications without the aid of any tools could be very time-consuming and error-prone. With the right tools, developing a JSF-based Web application has never been easier.

The innovative JavaServer Faces technology is a big step forward in Web development on the J2EE platform. With this new standard, businesses benefit from a comprehensive, reusable, and extensible UI framework. The JSF design offers excellent state management, event handling, and validation solutions that modern applications can utilize. As demonstrated in this article, using IBM WebSphere Application Developer to develop a simple JSF-based Web application to invoke a Web service can be done in just a few steps. One doesn't have to be both a Java guru and a Web expert to take advantage of JSF.

References

  • JavaServer Faces specification: www.jcp.org/en/jsr/detail?id=127
  • WebSphere Studio version 5.1.2 trial download: www-306.ibm.com/software/websphere/info/easierjava/index.jsp
  • More Stories By Jeffrey Liu

    Jeffrey Liu is a software engineer on the IBM WebSphere Studio Web Services Tools Development Team at the IBM Toronto Lab. He has comprehensive experience in working with the WebSphere family of products and with emerging Web services standards.

    More Stories By Helen Wong

    Helen Wong is a software developer on the C/C++/Fortran Compiler Team at the IBM Toronto Lab. She is an active contributor to IBM developerWorks.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.