Background

Part 2 of this series examined the overall project plan for the MetroSphere online technical community and information marketplace, and explained the process for deciding what the site needed to accomplish, and how. The major caveat in that article was that things were likely to change, and even this early in the process, they have. We started out with WebSphere Portal - Express V4.1 on Windows while waiting for our Linux box. Now that the box is here and we're ready to install WebSphere Portal Enable, we can see where the road has taken some unexpected (but welcome) turns.

This article describes the changes to the process with the migration from Express V4.1 to Enable V4.2, and chronicles the path we'll take to complete Phase 1 of the MetroSphere site. Or at least, the path we think we'll be taking.

Back to top

Where we are now

Before thinking about moving on, it's a good idea to look at what we've already accomplished. So far in this project we have created an overall project plan, installed a temporary development system using WebSphere Portal - Express, and gotten familiar with the portal way of doing things.

The overall project plan starts with defining the project itself. As a technical community and information marketplace, the goal is to provide users a central location from which to get all of their technology information, but also to be able to meet people with similar interests and eventually, to buy and sell technology-related content. To do this, we'll create a community weblog that includes the ability to create and manage personal pages.

When acquisition delays meant we wouldn't have our main Linux box in time to start work, we decided to install WebSphere Portal - Express on an existing Windows box. Although its structure is similar to Enable, installation is much simpler, so it seemed the perfect development platform. Applications built for Express will also run on Enable, so we could try out various approaches, build spike solutions meant to solve specific problems, and be confident that we weren't wasting time or resources.

Perhaps most valuable, though, was a look at the overall process of building applications based on Portal. A portal page isn't like a "normal" Web page, where processing is performed (for the most part) in one big chunk, and the results are returned to the browser. Instead, we have to get into the habit of thinking about our applications as portlets, or individual applications that are mostly independent of each other. A page can have one or more portlets, and as the output of each is produced, it's aggregated to create a complete page. These portlets are written in Java and added to the system through administrative pages.

The modular nature of portlets seemed to be a problem at first, but we quickly realized that it was an asset. Because portlets are (for the most part) independent entities, users can create a page that mixes and matches them, to some extent, and control their layout on the page. Customization is built into Portal, so we won't have to create that function ourselves.

Back to top

Where we go from here

The planning and research has been interesting, but now it's time to move on. The server is here, the software is here, and it's time to start moving forward. The plan includes the following tasks:

Check business patterns

In Part 3 of this series, we looked at documented business patterns and got some perspective on development by looking into the Portal composite pattern, which includes many of the functions we will be trying to implement. Since then, implementing the Portal pattern using WebSphere Portal has been documented more fully in a Redbook, so we'll check that out to see if there are any additional resources we can use.

Install the software

Installing WebSphere Portal Enable V4.2 consists of several steps. First, Tom will install RedHat Linux 8.0 on the main server. He'll then install all the pieces of Portal, including IBM Directory Services and some Domino and Lotus products to support later functions. We might wind up with an installation on more than one machine, which will be interesting.

Create the blogging application

The heart of the MetroSphere site is the community weblog, with entries automatically appearing on both the home page and the user's personal blog page. We'll start simple, building the framework as a JavaServer Pages (JSP) application, and then converting it to portlets. Eventually the portlets will talk to each other. To do some simple personalization, we'll make use of custom user properties.

Create user pages

We'll be working the actual portal interface pretty hard, enabling users to create their own places so they can control the layout and look-and-feel of their own areas. Because adding a new theme is not possible for a user without access to the file system on the server, development includes providing a way for users to control the look of their pages without having to register a new theme. User pages will also need to make use of persistent data.

Create user content

In addition to adding entries to the community weblog, users will be able to add independent content to the site. To start with, users can create their own mini-sites, and because the pages will be part of the portal, they'll be able to control who gets to see them using Portal's built-in access control capabilities. Originally, we discounted the idea of storing these documents in Domino, but now the idea is back on the table because of changes in Enable, described in the next section.

Create the environment

It's easy to get caught up in the modular nature of a Portal site, but it's just as important to remember that you've got to tie it all together. The more sophisticated the site is, the more users can customize their environment, but the easier it is for them to get confused and achieve less-than-desirable results.

In some ways, it's like the difference between a professional's camera and a disposable one you buy at the drugstore. You can do more with the professional's camera, to be certain, but it's also much easier to take a bad picture. We're planning on putting a lot of power into the user's hands, so will have to make sure we take usability into account early and often, and make things as easy to use as possible.

Integrate personalization

One of the key features of WebSphere Portal is the ability to allow the Portal itself to perform personalization of content, either by creating "rules" it has to follow, or by watching user patterns and suggesting appropriate content. We'll be adding this capability later, when most of the other functionality is in, so we have something to personalize.

Back to top

New features in WebSphere Portal Enable 4.2

And all of our plans, of course, depend on the function we'll find within WebSphere Portal Enable. We've waited longer than we expected to, because shortly after we began, IBM announced WebSphere Portal V4.2, with some exciting enhancements. We decided a short wait for the new version would be worth it. And besides, we still had the Express box to develop on while we waited.

WebSphere Portal Enable V4.1 has similar capabilities to WebSphere Portal - Express V4.1, though with expanded capabilities. For example, we performed a "development" install of Express, which meant that we didn't install an external LDAP server to handle user logins and information. (Instead, it was all handled by DB2.) Enable would have corrected that situation in any case, but the move to version 4.2 provides several additional advantages:

Preconfigured content

Version 4.2 of WebSphere Portal Enable comes with preconfigured portlets that provide live weather, stock market, and news information from Pinnacor and the Financial Times. Eventually we'll have to subscribe if we want to keep using the content, but at least we have it while deciding what kinds of content work best for users.

Click-to-Action

WebSphere Portal Version 4.1 included a means for portlets to send messages to each other, and our first versions of the blogging application use it. For example, when the user clicks a topic in the topic list portlet, that information needs to affect the portlet that displays portlet entries. It's a system that works, but is a bit cumbersome, and fortunately, version 4.2 provides a better, easier way. Click-to-Action provides a way for portlets to discover whether information is available to be sent or received, and automatically generates a drop-down menu for the user. Later, we'll integrate Click-to-Action into the blogging application.

Page customizer

This is more of a "non-change" than a change, really. WebSphere Portal - Express has links to the Quick Customizer, an easy way for users to create new pages and edit existing pages, which is perfect for MetroSphere. Version 4.1 of Enable, however, didn't include this function, though an extensive Work with Pages section was available. Fortunately, the Quick Customizer has been added to 4.2, so we'll have it available for the site.

New navigational controls

WebSphere Portal Enable V4.2 lets you create not just the page groups and pages of previous versions, but also nodes, which can be nested indefinitely. Navigation can be treated as a tree, with multiple levels instead of just two, as in previous versions. Version 4.2 includes new JSP tags that can be used to create menus based on these new levels. Because users will have the ability to create new pages, enabling them to create multiple levels will be useful.

Struts support

Struts is an emerging Web technology that attempts to separate content, function, and presentation by providing a way to implement the Model-View-Controller design pattern. We've been looking into using Struts for some other projects, and eventually might want to move the blogging application over to it.

Better content management

Version 4.1 of Enable included a content organizer, but it was intended to integrate with other external products. Version 4.2, however, includes both Domino Server and Lotus Workflow, which work with the newly-included WebSphere Portal Content Publishing capabilities. This combination will let users submit content to the site through their browser, so we'll be looking seriously at using this function instead of creating something from scratch.

Back to top

Summary

We started the MetroSphere project by creating a temporary development environment within WebSphere Portal - Express to familiarize ourselves with programming for Portal. Now we're moving on to the actual project itself using WebSphere Portal Enable. This process involves completing the installation, creating the basic applications and eventually, enhancing them to use the new features in WebSphere Portal Enable V4.2.

Resources

• Keep up with MetroSphere.com developments by checking out the overview.
  
  
• Get a feel for the project itself by reading the original project plan (developerWorks, March 2003).
  
  
• Read more about choosing a business pattern (developerWorks, March 2003), and about implementing the Portal pattern using WebSphere Portal.
  
  
• Find technical information for developers and administrators on the WebSphere Portal Zone.
  
  
• Find out more about WebSphere Portal Enable version 4.2 by reading the Guide to WebSphere Portal 4.2.
  
  
• Learn more about the way WebSphere Portal works by taking the tutorial Getting Started with WebSphere Portal - Express (developerWorks, April 2003).
  
  
• "Using Click-to-Action to Provide User-Controlled Integration of Portlets" (WebSphere Developer Domain, December 2002) offers more information about Click-To-Action capabilities in WebSphere Portal Enable 4.2.
  
  
• "Struts, an open-source MVC implementation" (developerWorks, February 2001) discusses Struts and how it relates to the Model-View-Controller pattern.
  
  
• Want to try these products? Enterprise-level developerWorks Toolbox subscribers can access WebSphere Portal Express V4.1 - WebSphere Portal 4.1 Setup Manager, JRE & HTTP Server for Windows 2000 and IBM WebSphere Portal Enable V4.2 for Multiplatforms.
  
  

About the author

Nicholas Chase has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, and an Oracle instructor. Recently, he was the Chief Technology Officer for Site Dynamics Interactive Communications in Clearwater, FL, and is the author of three books on Web development, including Java and XML From Scratch (Que). He loves to hear from readers and can be reached at feedback@metrosphere.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Background
• Where we are now
• Where we go from here
• New features in WebSphere Portal Enable 4.2
• Summary
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community