General Java

With the proliferation of Java-based application servers at the core of today's Web applications, the preferred Web architecture that has emerged places Java in the middle tier, gathering data from myriad sources, and HTML presenting that data through a Web browser.

As developers, we have a number of options for merging the two (Java and HTML, that is): JavaServer Pages (JSP), JHTML, Java Servlets and other proprietary APIs specific to vendors' application servers. But whichever path we choose, we all eventually struggle with the same challenge: keeping the Java and HTML code separate. Whether we're writing Java code directly into JSPs and JHTML pages or inserting HTML code in servlets, the merging of Java and HTML frequently create development headaches and, occasionally, strife between Java and HTML programmers during the development process. Once the application is finished, our headaches turn into migraines upon the realization that we have to dig through all of the intermingled code for maintenance and enhancements.

This article provides some relief for those headaches in the form of presentation logic. After we look at why there's this chasm between the two languages, and its implications, I'll demonstrate how to use session beans from the Enterprise JavaBeans (EJB) specification in conjunction with the Model-View-Controller design pattern to solve some of our problems. Then I'll give you my thoughts on bridging the Java-HTML gap in the future.

Web Application Architecture
Before we go about building the bridge, let's take a look at the source of the problem: the typical Web application architecture (see Figure 1).

Over the past few years, Java application servers have increasingly been positioned at the core of many Web applications' middle tier. Application servers are responsible for accumulating data from a number of sources so as to create and deliver dynamic Web pages to HTML browsers. With the support that Java-based application servers offer for rapid development and access to countless numbers of application services and data sources, it's no surprise that their use continues to grow. For any given Web application, it's likely that business objects of all shapes, sizes and flavors are created with the ultimate goal of presenting their attributes in an HTML page.

However, Web browsers don't display Java objects. They parse and display HTML documents, which, as we all know, are character-encoded files. And let's not forget that HTML provides no direct APIs for manipulating and processing the data contained within its pages as requests are sent to the application server; rather, it's accomplished indirectly using the data encoded in an HTTP request.

The Java-HTML Gap
Now that we've identified the gist of the problem, let's see why it exists. Starting with a quick definition of each of these languages:

• Java: According to Sun Microsystems, Java is "a simple, object-oriented, network-savvy, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic language." It's safe to assume that we all know what Java is (or else we wouldn't be reading this magazine!).
• HTML: HyperText Markup Language has established itself as the lingua franca for publishing content on the Internet. It's a nonproprietary language based on Standard Generalized Markup Language (SGML) which, to all intents and purposes, means that it's a tag-based language for marking up text and graphics on the Web and linking pages together via hyperlinks.

In layman's terms Java is the language used for implementing business logic and connecting to back-end data sources and legacy systems, while HTML is the language of choice for creating the user interface of a Web application. The interdependencies between the two are apparent: Java code processes business logic and HTML code displays the results. However, as the two languages evolved independently of one another, little thought was given to their marriage in Web applications until recently.

Looking at some of the specific problems we're trying to solve will help crystallize the issue at hand. Keep in mind that we're walking down a two-way street. Data is not only sent from the server to the Web browser for display, but is also entered by a user in a Web page and sent to the application server for processing.

There are different complexities associated with both routes. Following are some typical steps that occur as users interact with Web pages:

From the Browser to the Application Server

1. Form submission: Users enter information into an HTML form and click a submit button. The data is marshaled into name-value pairs and sent via an HTTP request to the Web server. The Web server, in turn, forwards the request to the application server.
2. HTTP data extraction: Using APIs supported by the application server, data is extracted from the HTTP request in the form of Java strings. For example, the Servlet API provides access to an HttpServletRequest object on which we call the getParameter() method to retrieve data from the HTTP request. This step often involves the hard-coding of the name attributes of form fields directly in Java code.
3. Form field validation: Before setting business object attributes and sending updated information to a database, we often want to check the validity of the information entered by the user through the Web page. One example is checking that dates are specified in the format of MM/DD/YYYY and that the month, day and year are all integers.
4. Set business object attribute(s): Once the data has been validated, business object attributes are set and the application uses the updated business objects as defined in its workflow.

From the Application Server to the Browser

1. Workflow: As seen in the previous example, several steps are required to process an HTTP request and update the business entities of the application. Once this process is complete, the application now needs to decide what to do next. If the user-entered data is invalid, then an error page is displayed. If the data is valid, the application needs to determine what to display next.
2. Business object instantiation and data retrieval: A business object containing the data that will eventually be displayed is needed. Where the business object acquires its data is inconsequential provided that the appropriate data is readable. We can even reference the business objects updated in the previous steps as long as they are still in memory.
3. Conversion to "Web-friendly" strings: Since HTML pages are entirely character-encoded, we'll need to convert the nonstring data to "Web-friendly" strings. This includes converting Java primitives and objects (such as java.util.Date) to strings.
4. Populate HTML pages with dynamic data: The final step in this process is to construct an HTML page with the dynamic content that's accumulated and converted in the previous steps.

The next section looks at the different approaches to populating HTML pages with dynamic content.

Mixing Apples and Oranges
Ever since CGI scripts enabled the creation of dynamic Web pages, the complexity of Web applications has continually increased, establishing the need for powerful server-side programming solutions capable of gathering data from a countless number of sources and processing it. Enter Java. With the robust features of Java and the ubiquity of HTML as the window to the Internet, application servers began to cultivate the relationship between Java and HTML with several different solutions emerging:

• Servlets: Thought of as a replacement for CGI scripts, servlets burst onto the Java development scene in 1997 promising all the benefits of the Java programming language as an extension to the Web server. Servlets are essentially HTTP request handlers that provide full access to Java APIs and endow Web programmers with a powerful tool for creating dynamic Web pages. To display a Web page, HTML tags are encoded into the servlets, with dynamic content added as necessary. Servlets were the first Java-HTML solution that began to appear in industrial-strength application servers and are in wide use today.
• Proprietary HTML Rendering Engines: As Java application servers became more widely used, the limitations of the servlet model became apparent, especially with the increasing size and complexity of Web applications and development teams. HTML programmers were responsible for building the front end of the Web application in HTML, while the Java programmers wrote code for the middle-tier business logic and back-end data sources. Embedding HTML within Java Servlets was no longer viable. Proprietary tagging schemes and Java data structures were created by some of the application server vendors as an attempt to separate Java and HTML as much as possible. Java programmers would populate data structures with the dynamic content of a Web page, and an HTML rendering engine would merge that data into proprietary tags in HTML templates. If you ever worked with Netscape application server in its AppLogic days, you know what I'm talking about.

• JavaServer Pages (JSP): Recognizing that the separation of Java and HTML in a nonproprietary and standardized format was highly desirable, Sun Microsystems led an industry-wide, collaborative effort to develop an extension to the servlet specification that provided an XML-like scripting syntax for incorporating dynamic content from Java components into Web pages. JSP offers the most promising solution to date for componentized development and separation of business and presentation logic. However, realizing the benefits of JavaServer Pages requires a sound architectural design.

Presentation Logic
A quick recap of what we've looked at so far. First, with the explosion of n-tier Web applications using Java application servers at their core, we're continually building systems that connect to myriad data sources through Java APIs and displaying that information via HTML pages. Second, utilizing HTML as the user interface through a Web browser carries several implications from a programming perspective, primarily focused on how data is moved back and forth between Java and HTML. Third, in order to address the issues of the Java-HTML gap, competing technologies including servlets and JSP have been developed. Fourth, without an established framework for developing with these technologies, Java and HTML code are often mixed together, resulting in a nightmare of code development, flexibility, scalability and maintenance.

Building a presentation logic framework is essential for bridging the Java-HTML gap in our efforts to build successful Web applications that are both scalable and flexible. The remainder of this article illustrates one of several reasonable presentation logic frameworks based on the Model-View-Controller design pattern.

Model-View-Controller
Let's refresh our memories on the Model-View-Controller (MVC) design pattern. It's commonly used for designing GUI applications and is the underlying architecture for the Java Swing components. In the simplest sense, an application stores its data in some format (the model) but has different ways of displaying it (the views). The controller portion of the application serves as the central point of control, coordinating a user's actions with the views to update the model(s) and ensuring that the views are supplied with the latest additions to the model(s). Okay, enough with the abstract talk, let's dive into the specifics and see how the MVC pattern translates into the core components of a Web application. (Take a look at Figure 2.)

• Model: Business objects hold the data needed by the application and play the role of model in the MVC pattern. With a Java application server, business objects are often built using Enterprise JavaBeans, JavaBeans and other Java classes. They represent the business entities of the system (e.g., User, Account).
• View: The user interface of a Web application represents the view. For simplicity's sake we'll restrict the user interface to HTML pages viewed through a Web browser (although it's entirely conceivable that the UI could be an applet, a PDA, and so on). Note that the view does not include JSP pages but rather the end product of processed JSP pages (which is, of course, HTML).
• Controller: Everything between the business objects and Web pages in a Web application can be considered controllers. This includes Java classes, servlets and JSPs. Think of it as all the Java code to process incoming data, delegate workflow and populate pages with business object data.

In Control
We already discussed steps that occur when data is moved from the browser to the application server and vice versa; the question is how to develop presentation logic that's efficient and scalable with the goal of eliminating the jumble of Java and HTML code. Breaking out the controller into a group of discrete components with specific functions to perform will help answer that question.

• Request Dispatcher: As the central point of control for a Web application, the Request Dispatcher is a Java servlet that receives all incoming HTTP requests and forwards the HttpServletRequest and HttpServletResponse objects to the appropriate Web controller. Exactly how this is accomplished is a design issue that's far too lengthy and complicated to address here. The Request Dispatcher also performs application-wide functionality such as user authorization and session management.
• Web controller: Web controllers are the glue that hold a Web application together. They are session beans and can be stateful or stateless depending on the needs of the application. The primary responsibility of a Web controller is to process the business logic defined for workflows within functional subsets of the application. For example, there's a Web controller for login, registration and shopping cart. Some of the logic Web controllers perform includes session data management, exception handling and workflow.

At a very basic level, a Web controller is instantiated via the Request Dispatcher and is forwarded the HttpServletRequest and HttpServletResponse objects. Reading data from the HTTP request, the Web controller identifies the page the request came from and forwards the request to the corresponding page bean. Once the page bean is finished with processing the incoming request data, the Web controller regains workflow control and instantiates a page bean for the next Web application page to be displayed. If an exception occurs at any point in the process, the Web controller catches the exception and displays an informative error page using the HttpServletResponse object. Listing 1 shows a representative pseudocode for a Web controller.

• Page bean: Page beans are session beans conforming to the JavaBeans standard (i.e., they have private attributes with appropriate get/set methods for the purpose of referencing from a JSP). For each page of the application requiring interaction with the application server, there is a corresponding page bean. Let's say we have a user account maintenance page to display. There will be an analogous page bean that populates itself with the user data the page needs as well as processes updates to the user's information once the page is submitted. The page bean is the Java equivalent of the HTML page and processes information both going to and coming from the Web browser (at different times, of course). The superclass of all page beans contains utility methods for common functionality such as conversion of Java primitives to strings, HTTP data extraction and form validation. Over time, page beans can be grown to accommodate a number of different user interfaces rather than strictly HTML (more on that later). As the implementation details are lengthy enough for a book, we'll reserve that discussion for some other time.

Why Session Beans?
I know what you're thinking: why use session beans? The way I think of them is as replacements to the service(), doPost() and/or doGet() methods of a typical servlet. Their primary task is processing the presentation logic in a manner that's as independent of the user interface as possible. In the preceding examples, I realize that I've focused on what happens as requests are sent in from a Web browser. In these instances, servlets make sense. Down the road, as requests are dispatched from PDAs, pagers and toaster ovens, the servlet model makes less sense. A client-agnostic method for processing incoming requests and outgoing responses in a Web application environment provides greater flexibility for future growth. With session beans we also have the ability to distribute the aforementioned processing across many systems as well as perform session management without having to rely on cookies or URL rewriting. Remember, it's the architectural framework that's vital to ensuring the health of development efforts as the system grows in functionality and complexity.

Making It Work
Okay, so we have all these request dispatchers, Web controllers and page beans, but how are we going to get this architecture to work? With any Web application the possibilities for implementing presentation logic that varies in detail and scope are limitless. What's important is realizing the value of separating your Java and HTML code. In a perfect world, using today's technologies, HTML developers will create the look-and-feel of the pages, in which Java developers will then insert JSP tags to incorporate dynamic content. The only overlap between the two will be the JSP tags. However, this utopia is achievable only through intelligent application and presentation logic design that is enforced throughout the development process. This means taking into consideration details such as data that needs to be moved between screens and the mechanism for instantiating a page bean for a given page. What's presented above is just one of many viable solutions that provide the flexibility and scalability we're all looking to achieve.

The Future of Presentation on the Web
All of us who have built Web applications know that the Java-HTML solution is, at best, far from elegant. Invariably, Java and HTML will be mixed with each other, creating a muddle of confusion that will be called a Web application at the end of the day. With a solid presentation logic design fleshed out from the beginning of a Web application project, some of the obstacles imposed by the Java-HTML gap can be overcome, but never will all of them be eradicated. What's needed is an intermediary step between the Java and HTML code. My opinion is that the XML (eXtensible Markup Language) is the answer.

Without going into a great amount of detail, the ideal Web application development environment I envision is one in which Java application servers sit in the middle tier churning through business logic as requests come in and creating XML documents on the fly as responses. With XML documents being sent to clients, we don't have to worry about the details of transporting data from our Java code directly into HTML. That becomes the job of the XML Stylesheet Language (XSL) and an XSL processor...a true separation of content and its layout. With this technique the data required for a page is moved around in a platform-neutral and well-defined format that can have its view changed as required depending on the device users are accessing it from. I can't wait!