Ajax Programming in BEA WebLogic Portal 8.1, Part 1

by John Margaglione
01/24/2006

Abstract

Portal applications do an excellent job of surfacing information from multiple sources and providing application services to the portlets that comprise the portal Web application. To the user, the portlet applications are independent entities, similar to windowed applications on a desktop. Extending that analogy, what if taking an action in one windowed application caused the content in all other applications to be refreshed? That is the current state of most portals. Moving through a page flow in one portlet causes the entire Web page to be refreshed, including all other portlets on that page.

To combat this sometimes undesirable behavior, Web developers have employed what is referred to as Ajax-style programming. Ajax, or Asynchronous Java and XML, is a collection of technologies including XHTML, CSS, JavaScript, DOM, and the XmlHttpRequest object to create interactive Web applications. This article explains the rationale for using Ajax programming methods within the BEA WebLogic Portal environment, and offers some best practices and advice to avoid the many pitfalls awaiting the new Ajax programmer.

A Brief Introduction to Ajax

Consider a Web application that draws street maps based on some user criteria such as the street address, city, and state. This type of application has been around for years with little change in the user interface. The user enters an address and clicks a button, and a map of the surrounding area is displayed in the center of the page. More often than not users need to zoom in and out to show more of the surrounding area, or they need to nudge the map a bit to the left or right to see some major street or landmark that will help them navigate. Try this scenario using maps.yahoo.com or mapquest.com. Go on, try it! Try this address:

100 East Wacker Drive
Chicago, IL

Eventually you are greeted with a map of downtown Chicago, centered on Wacker and Michigan. To the right you'll see a series of zoom levels you can choose. Choose to zoom in one level. What happens? The entire page refreshes, taking quite some time to do so. Now, what happens when you nudge the map left or right? You inevitably end up refreshing the entire page, with the entire map needing to be downloaded again. The page size is generally 75 to 100k, and the average turnaround time is about 3 to 10 seconds, depending on your Internet connection.

Now try the same thing using Google Maps, a site that uses Ajax techniques to the fullest. Type in the address and click Search. The page loads in its entirety. Now zoom in a level. Notice that the page contents outside of the map did not refresh. This is what happened in the background:

1. The user clicked the zoom control.
2. The zoom control called a JavaScript method.
3. The JavaScript method called the server to request new map information.
4. The server created the new image and sent it back to the browser.
5. The browser replaced the existing image data with the new image data.
6. The user sees the new image in place of the old image.

Notice that there are no arrows surrounding the map indicating north, south, east, and west. How does the user interact with the map? You simply drag the map around as if it were in a scrolled window. Try clicking the center of the map and dragging the map to the left. Notice how responsive the map is when it is dragged! Here is what's happening in the background:

1. The user drags the map to the left.
2. The Web page uses image information that it downloaded while the user was idle to redraw the map from data already on the client.
3. If image data has not been retrieved previously, the browser calls the server for only the incremental information it needs (the area of the map that just appeared).
4. The new data is added to the existing data and is redrawn in the browser.
5. The user sees the map scroll to the right as if the image were really one giant image.

Here's what the use of Ajax achieves

• The amount of data moved between the client and server is significantly reduced.
• The perceived response time of the system has improved drastically.
• Users feel more in control of the application because of the immediate feedback.
• Users really like this site because it lets them do their work faster.
• Users will be back again, and the competition loses customers.

That should be an impressive demonstration of Ajax-style user interfaces. (If, after using Google Maps for a few days, you aren't convinced that the competition is annoying and very 1990s, you need not read the rest of this article.)

For a more thorough introduction to Ajax, please read An Introduction to Ajax (dev2dev, August 2005).

Portal Issues that Ajax Remedies

Consider potential customers who are heavy users of Java applets and want to create portals using their existing assets. It is simple enough to wrap existing applets and other page flows into portlet containers, but consider what issues will emerge as the portal testing begins. For example, an action in one portlet causes the refresh and subsequent reload and reinitialization of all other applet-based portlets on the page. If the applets in question have backend connections, as would streaming portlets, then the reinitialization of the portlet causes the server to drop the existing connection and forces the applet to reconnect, which is not only a strain on the server but also presents users of the portal with several seconds of "dead time" during which the applet-based portlets must remain grayed out as they finish their initialization.

This is obviously a potential showstopper. Telling customers to rewrite all their applets as JSP-based applications is not a useful response, especially for customers that have invested significant resources into the existing assets. Besides, a portal is supposed to help customers surface their existing applications, not force a rewrite of their entire system.

What is needed is a way for an individual portlet to take actions or get new data without causing a page refresh. While this obviously has some downsides I will discuss later in this article, it is necessary in this case to avoid page refreshes simply as a barrier to entry for using the portal.

Side note: One possible solution to this problem is iframes, or inline frames, a browser-based mechanism that makes an area of the screen an independent entity that does not refresh when the page is reloaded. Using techniques similar to those used in Ajax programming, it is possible to make server calls using XML-RPC to get data and load it into a DOM document. An article on Apple's developer Web site summarizes the pros and cons of this method very well. I am sure there are great arguments on both sides for why iframes and Ajax are both better, but Ajax has caught on and iframes have not. Therefore, this article deals with Ajax and not iframes.

Use Cases

Ajax technologies are useful when any of the following conditions are present:

• One or more applet-based portlets are in use in the portal.
  Example: See the scenario described in the previous section.

• A portlet needs to refresh its data or redraw its contents on a cyclical basis.
  Example: A executive dashboard with a table of stock values that is updated every minute.

• Inter-Portlet Communication (IPC) is done that should not refresh the entire Web page.
  Example: A portlet that lists stock names needs to update a second portlet that gives a brief description of the current status of those stocks, such as current, high, and low price.

• The page contains a large amount of mostly-static data, where a page action only needs to replace a small amount of the data.
  Example: Google Maps.

• A portlet needs to retrieve a limited set of data based on a selection made elsewhere in the portlet.
  Example: A form has three combo boxes: State, City, and ZIP. When the user selects a state, all the valid city names for that state are filled into the City combo box. The user then selects a city from the City combo box, which fills the ZIP combo box with valid ZIP codes for that city.