Most Read This Week
Developing Web Portals in Jetspeed Using JSP
Simplify the process
Jun. 3, 2004 12:00 AM
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:
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.)
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
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.
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.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads