The Struts Framework from Apache is a very popular, robust Web application framework. Many corporate companies have deployed tons of Web applications using Struts. And they hit the ground with abundant technical resources. They can develop newer applications quickly. Portal implementations offer a new challenge by introducing new frameworks and APIs. To leverage existing assets and skills, WebSphere Portal supports the Struts Portlet Framework so Struts Web applications can be easily migrated to a portal.

 AJAX, or Asynchronous JavaScript and XML, is a new happening technology to make Web applications function like client/server applications. I mean Web pages triggering requests based on events (asynchronously) that refresh only specific parts of a page as opposed to refreshing the whole page.

The Struts Framework
There's tons of information on Struts, AJAX, and the Struts Portlet Framework available on the Web. In this article I'm going to provide a brief introduction to these topics; for more details check out the resources section.

The Struts Framework is an implementation of the MVC architecture, with Model being the business logic represented using JavaBeans, EJBs, etc., View the presentation layer represented by using JSPs, ActionForms, and tag libraries, and Controller the ActionServlet and Action classes (see Figure 1).

Struts Control Flow
Here is the typical request-response cycle for the Web application using Struts:

• The client requests a path matching the Action URI pattern.
• The Web container passes the request to the ActionServlet.
• The ActionServlet looks for the Struts configuration file, if this application has multiple modules it looks for the appropriate mapping for the given path in any of the Struts configuration file.
• If the mapping specifies a form bean, ActionServlet looks to see if one exists or it creates one.
• Once the form bean is created, ActionServlet populates values from the HTTP request. If the mapping has a validate property as true, ActionServlet invokes the validate method on the form bean. If the validation fails, the control flow ends there.
• If the Struts configuration file specifies action mapping then the appropriate action class 'execute' method is invoked with an instantiated form bean as a parameter.
• The Action may call other business objects and repopulate the form bean with the latest values and other business functions as needed.
• Based on where you want to send the control next, the Action reads ActionForward and the Action URI from the Struts configuration file and returns to the ActionServlet.
• If the ActionForward is a URI to the JSP to display the page, the control flow ends by sending the output to the browser or if it's forwarded to another Action URI the above flow starts again.

AJAX in Action
AJAX is not a new technology, but is the most happening thing in the Web world that gives a desktop or client/server application feel to your Web applications (see Figure 2).

AJAX Control Flow

• A Web page sends its requests using an XMLHttpRequest object and JavaScript function, which handles talking to the server.
• Nothing has changed for the Web application server; it still responds to each request, the way it did it before.
• The server's response only has the data it needs in the XML form, without any markup or presentation.
• The JavaScript dynamically updates the Web page without redrawing the whole page.
• Most of the page doesn't change, only the parts of the page that need to change is updated, and that asynchronously.

Struts Portlet Framework Developers who have experience with the Struts Framework should adapt easily to the Struts Portlet Framework. The packaging for Struts Portlet Application is similar to a Struts application in the servlet environment. However, WebSphere Portal introduces additional challenges such as portlet modes, states, inter-portlet communications, portlet two-phase processing, and multiple device support, which are addressed through the Struts Portlet Framework. For a detailed explanation of this topic, see the Redbook IBM Rational Application Developer V6 Portlet Application Development and Portal Tools.

A portlet processes and renders differently than a servlet. A servlet will do all its processing in the service method, while the portlet will divide action processing and rendering into two separate methods, hence portlet processing is defined as a two-phase approach. Figure 3 explains the two-phase processing approach of a Struts portlet. To invoke actions in the rendering phase there is a new interface called IStrutsPrepareRenderer. For more details see Executing Struts actions during the render phase of IBM WebSphere Portal.

IBM supports Struts Portlet Framework for both IBM API and JSR 168 API portlet containers. Users can easily migrate existing Struts applications to Struts portlet applications using either of the portlet's APIs. For more information on migrating and developing newer applications using the Struts Portlet Framework see the Portal Info Center.

Struts Portlets with AJAX
Though AJAX isn't the right solution for every Web application, there's increasing curiosity and enthusiasm among organizations to explore its benefits and see how it works for their applications. AJAX isn't new, but it's all on the client side and making it work with different server-side frameworks is a challenge. This article is a result of my client experience in developing Struts portlet applications with AJAX. In the sections above I briefly described Struts and AJAX. In the sections below I'll describe some of the challenges faced during implementation. To develop AJAX applications there are several toolkits such as Google Web Toolkit (GWT), DOJO, AJAX Faces, and JSON, but for simplicity's sake we chose a plain vanilla implementation.

The tricks to rendering content asynchronously using AJAX has more to do with JavaScript and XMLHttpRequestObject than any server-side technology, however, getting the blend of AJAX working with server-side frameworks involves careful design and architectural thinking.

Making asynchronous calls to the server using AJAX best fits a portal scenario with different portlets representing different back-end application views. However, this feature isn't supported with portlet URLs since each response from the portlet container represents a portal page with different portlets with different window states and modes. Given this limitation, the alternative we have is the XMLHttpRequest object calling a servlet from a servlet container as depicted in Figure 4.

To demonstrate the above scenario I have used the simple downloadable example shown below.

As in Figure 5 and Figure 6, when the user clicks on the menu items, the right-side blue box items get refreshed without unloading the whole page.

Below are some of the challenges we had and I'll explained how we addressed them.