Developing Web Portals in Jetspeed Using JSP

A Web portal is an application that aggregates multiple Web applications on a single Web page. Popular examples of portals are My Yahoo (my.yahoo.com) and My MSN (my.msn.com). These portals allow users to aggregate multiple Web applications (like Stock Quote, News, and Weather). In addition these portals allow users to personalize and customize the presentation and content of the individual Web application. This means users may do both: change the color, style, and layout of the page, and specify the content - list of stocks in a Stock Quote application and categories of news in a News application.

The Java community has created a standard for developing portal applications; it's called the Portlet API. The individual Web applications described above are called portlets. In August 2003, Portlet API specification, JSR 168 (http://jcp.org/en/jsr/detail?id=168), completed the public review process. The goal of the specification effort is to "enable interoperability between portlets and portals by defining a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security." This allows portlets to be developed once and deployed on any Web portal that is compliant with the portlet standard.

This article will describe how to develop JSP portlet applications using Jetspeed. Jetspeed (http://jakarta.apache.org/jetspeed) is an open source project from the Apache Foundation that provides tools to build Web portal applications. Its current release, Jetspeed 1.4, provides a portlet-based implementation. Jetspeed 2.0 is currently under development for release in early 2004. This will be compliant with JSR 168 portlet standards and built on Apache's Pluto, which is a reference implementation of JSR 168 (http://jakarta.apache.org/pluto/).

This article demonstrates a method to develop JSP portlets with a declarative specification of server-side logic instead of server-side programming. This is in contrast to current methods of developing JSP portlets that involve a significant amount of server-side programming.

The Jetspeed application is available as a WAR file and may be downloaded from http://jakarta.apache.org/jetspeed/. The WAR file may be deployed in Tomcat 4.1, WebLogic, WebSphere, or other J2EE application servers. The tutorial at http:// jakarta.apache.org/jetspeed/tutorial/ is a good guide to getting started. It explains how to aggregate, personalize, customize, develop, and deploy new portlets, therefore it will not be repeated here. This article focuses on developing portlets using JSP. To illustrate how JSP applications are developed in Jetspeed, we'll use a simple User Profile example (this will be referred to as Portlet 1 in Figure 1), with the following functionalities:

1. When a Web page with the User Profile portlet is loaded on the browser, the logged in user's address and phone number are displayed.
2. User changes the information and clicks on Update. The changed values are updated in the database.
3. The returned page displays the updated information. Standard Method for a JSP Portlet

Standard Method for a JSP Portlet
An implementation of the sample application in Jetspeed, using the traditional method, will consist of the following files (see Listings 1-3). (Listings 5-7 can be downloaded from www.sys-con.com/java/sourcec.cfm.)

• profile.jsp: JSPPortlet requires that the name of the submit form element have this prefix: "eventSubmit_". The name after this prefix, for example, "doUpdate," is the method that is called in profileJSPActionClass.
• profileJSPActionClass.java: The action class must contain two methods - buildNormalContext and a method called from the JSP page. The buildNormalContext() method is the last method called every time the portlet is displayed or refreshed. If ProfilePortlet is submitted, Jetspeed calls doUpdate() first and then calls buildNormalContext().
• profile.xreg (the Jetspeed registry file): An XML file for registering a portlet, it specifies the type of portlet, JSPPortlet; the action class, indentJSPPortletAction, that will handle the submit event and deliver content to Jetspeed for rendering; and the startup parameters for the portlet.

Figure 2 shows the flow logic for four conditions in the action class:

• When the portlet application is first loaded in a Web browser
• When the portlet application issues a submit request that involves a database update
• When the portlet application issues a submit request that involves getting data
• When the page containing the portlet application is refreshed or another portlet application on the same page is submitted

A Jetspeed container typically contains several Portlet classes - JSPPortlet, RSSPortlet, IframePortlet, VelocityPortlet, etc. A JSPPortlet may be servicing several portlet applications - P1, P2, … Pn. When a Portlet is submitted from a browser, the Jetspeed container determines which portlet class will process the request. The portlet class then hands over the request to the action class of the appropriate application. For each portlet application, developers write an action class and several methods in the action class. The action class typically calls a business component or database to satisfy the request. The data returned by the business component is used to render the return JSP page of the portlet application that was submitted. Other portlet applications on the same page are returned from the cache.

In the traditional method of developing JSP portlets (see Figure 3), developers write action classes and methods that are request specific. For example, if Portlet 1 has five JSPs and each has two different submits, in a worst case scenario a developer would write 10 methods in Portlet 1's action class. Each portlet is typically configured to be processed by a different action class. Extending this analysis to four portlets with each requiring 10 methods would suggest that a developer would write 40 methods.

The issue with this approach is that for any reasonably sized Web portal, the collection of action classes and methods proliferates and becomes unmanageable.

Declarative Method for Creating a JSP Portlet
Faced with this problem, we have developed a broker class that provides a single action class, IndentJSPAction- Class, and a single action method, doSubmit(), to which all JSP pages are submitted (see Figure 4).

For brevity the broker class will be illustrated with an example in which action is limited to a database transaction. Two parameters are sent to the action class: actionType and actionName. actionType is "select" or "update" and actionName is the name of a request, whose purpose will become apparent soon. The broker action class calls Aspire, which is a declarative middle tier (www.indent.org/aspire.htm). Aspire is an open source J2EE program developed by coauthor Satya Komatineni. To download Aspire's JAR file and the source code of the examples go to www.indent.org/jetspeedDownload.htm.

In Figure 4 JSPPortlet forwards the request to a single class and single method in the broker. Action Class calls Aspire with a parameter aspireURL. Aspire reads the declarative definition for aspireURL and transacts with the database. The retrieved data is transformed to a hierarchical data set (HDS). The outgoing JSP page then uses HDS to create the display.

The broker is employed in simplifying the action class. The role of the action class is twofold. In the case where "actionType=select", the action class is responsible for retrieving data from a database as an HDS. The outbound JSP uses the HDS for display in the browser.

In the case where "actionType= update", the action class is responsible for modifying content in a database. Once the update takes place, the user can be redirected to an appropriate page. Separating the role of the action class into these two categories offers clarity in the design of portlets.

The broker class has prebuilt parts that can construct an HDS declaratively from a set of SQL statements. This means the action class can make use of these definitions to automatically generate the necessary data for a Web page. In case of an update, the broker class provides a declarative update pipeline of parts where multiple update SQLs or stored procedures are executed against a database transactionally. By coupling these two declarative facilities, a generic action class for the JSPPortlet has been developed that streamlines the process for developing Jetspeed portlet pages rapidly. For more information about HDS and Aspire see "Using Hierarchical Data Sets with Aspire and Tomcat," www.onjava.com/pub/a/onjava/2003/03/05/hds.html.

An implementation of the sample application in Jetspeed contains the following files, shown in Listings 4-7.

• Aprofile.jsp: Uses Aspire and hierarchical datasets to get data for display. A hierarchical dataset is generated by Aspire and inserted into rundata in the action class. There are two methods, getValue(column name) that returns data for a column and getChild(loop name) that returns a hierarchical dataset containing multiple rows of data. This JSP page displays all the past phone numbers and addresses of this user and allows the most recent to be edited.
• Java source for the Action class: Uses Aspire, a declarative middle tier for all database transactions; see Figure 2 for the flow logic.
• profile.xreg: Three additional parameters - aspireAction, aspireURL, and appName - have been added compared to the standard version. Values assigned to these parameters are used in buildNormalContext() to initialize the portlet and get the initial set of data from the database through Aspire.
• Aspire properties file: The database calls are declaratively specified in this file. AspireURLs illustrated here are "SaveAddress" and "addressURL." dprDB is an alias for a database. In SaveAddress, the first part of request gets user_id, and the second part executes an insert. In addressURL, there are three parts to the request: the first two return a single row and the third returns multiple rows.

Summary
A broker class is presented as a means of simplifying the process of creating JSP portlets. The custom Java coding-based approach in the action class is replaced with a declarative approach in which data access and update methods are specified in external properties files. This greatly simplifies the development and maintenance of portlets.