Figure 2: This snippet defines one of the icons in the title bar of a portlet.

Portal Administration

Portal administration has a number of facets. It covers everything from the configuration and start/stop of the portal server to the design of the application to the management of users. From this viewpoint, WPE functions more like an end user product, with all the standard issues of configuration.

One of the first major tasks of portal administration is the layout of the pages in your application. While this is partially an issue of programming, one of the key design goals of portals is to allow your developers to write portlets without worrying specifically about the page layout. As long as the interface fits within the constraints of a portlet, they don't have to worry about things like styles and page positioning. The portal server handles all those details. The actual layout of the application pages is actually done at a higher level, with more attention paid to the end user. In fact, part of portal administration is identifying which pages can be customized by the end user and to what extent.

Another job of administration is identifying users, groups, and roles. This is similar to what you do in any other large application development environment. One interesting twist with WPE is that, if you have the appropriate Lotus products installed, you can have WPE interact with those products. Called "People Awareness" in the documentation, this feature allows you to embed special tags in your JSP pages that will act as links to things like email and Sametime chat. You can also access a wide variety of Lotus features in your portlets.

Many global configuration parameters need to be administered, including restart capabilities, language preferences, HTTP proxy configuration, and multiple other things that affect your entire WPE implementation. One of the nicest features of this section is the ability to define special human-friendly URLs for portal pages. As you use the product, you'll see that a typical portal page has a name like this:

http://localhost:9081/wps/myportal/!ut/p/.cmd/cs
/.ce/7_0_A/.s/7_0_4L/_s.7_0_A/7_0_4L

This URL is not particularly pretty, and it's difficult to bookmark and send in emails and so on. One of the administration features in WPE is the ability to map URLs like the one above to a more readable form.

Finally, the act of including new portlets is part of the portal administration process. As your developers create new portlets, you'll be able to add them to your pages. Or, if your application is open-ended, you can make portlets available for the end users to add themselves. Portlet administration, like everything else, is done via a portlet, as shown in Figure 3.

Figure 3: This portlet allows you to manage the other portlets in your system.

One thing that I was particularly pleased to find was the inclusion of a utility for exporting and importing configuration information via an XML file. This capability was a great help with the old WebSphere Application Server (WAS) Standard Edition (the late, great version 3.5), and it looks as though the WebSphere Portal designers decided to carry that functionality over. This feature is crucial to ISVs who need a turnkey way of configuring a portal instance.

Portal Security

Basic issues of security surround any product, and portals are no different. The various WebSphere Portal products all require WAS, so you need to consider how you want to administer WAS. Based on your business requirements, you may need other servers as well, such as an LDAP server, which I'll address in a moment.

In addition to the external issues raised in the previous paragraph, two basic functions need to be considered as part of portal security: authentication and authorization. Authentication is required for most B2B and internal applications; usually, you have to be authenticated before you can access any functions of the system. WPE offers a number of types of authentication.

Authentication is becoming more and more of an issue for shops as they begin to integrate multiple applications. In the good old days of Web applications, you simply allowed your HTTP server to challenge the user for a Web user ID and password. The HTTP server would then place the Web user ID into the session object, and the developer could use that for whatever authentication he needed. This technique doesn't work as well when you have to go to other servers for information, and in these days of multi-tiered applications, the concept of a single sign-on is becoming more and more prevalent. WPE provides multiple ways to address this complex issue, including hooks into IBM's Tivoli Access Manager.

Once you have authenticated the user, the next issue is identifying what they can and cannot do. This involves roles, rights, and access control, all of which are supported by the portal server. This particular task overlaps both the administration and the security aspects of the product; the administrative aspect involves creating the roles and assigning the appropriate rights to those roles, while the security aspect deals with assigning individual users to the appropriate roles (and occasionally giving them special rights outside of their roles).

One side note: SSL setup for WPE is not exactly straightforward. It requires a few simple but crucial tasks on both the WAS and the WPE products in order to successfully establish SSL communication for your application.

Portlet Development

Up until this point, I have barely touched the subject of portlet development. The entire preceding portion of this column assumed that all your development work was already done and that all you needed to do was arrange your portlets in various configurations to satisfy the needs of your end users. Now, I'll introduce you to the various topics that make up portlet development.

The interaction between the programmer and WPE is complex. First, the portal server gets a request for a screen. Most of these screens have specific purposes, such as logging in or presenting error information, and act very much like standard JSP. However, if this is the Home screen, then the portal server determines which portlets are displayed in the screen portion of the display and begins collecting data from them. A special tag in the Home.jsp file starts this process. Currently, this is the tag. (Just as an example of how things change, this tag used to be .)

The next step in the process is to implement the appropriate theme. During portal administration, you define the page layout. This includes the theme for the page as well as the portlets on the page. When the theme is invoked, it renders all the data from the various portlets. As I noted earlier, the tag performs this function.

The theme identifies the overall characteristics of the page, such as logos and banners. Each portlet, however, is defined by a skin. A skin is a special JSP designed specifically to render a portlet. Skins tend to follow a very standardized structure, with lots of calls to the WPS tag library, but specifically to the tag. As long as your skin follows the standards (with buttons for minimize, maximize, and so on), then your code will be very similar to the code in the supplied portlets. But the more your application strays from the general portlet appearance (which I think of as MDI for browsers), the more you'll need to understand how these various pieces work.

Please note how much ground I've covered, and you haven't even begun to write a line of code. That's deliberate--I want you to get a real feel for the amount of infrastructure work that surrounds even a basic portlet. Even more importantly, I want you to see how much of this code is based on conventions that the portal developers have put in place. In order to make the quickest use of WPE, you need to work within these conventions. Although you could certainly implement your own version of many of these features, the further you stray from the syntax used by convention in the IBM portlets, the more work it will be for you to implement.

As a case in point, the style sheets associated with the standard portlets have specific naming conventions for styles. For example, .wpsTableHeadEndNumeric identifies the right-hand element of a table if this is the heading row and the column contains numeric data. In order to use that style, your application has to be modified to add that class to the appropriate cell. You can choose to either use those predefined styles or create your own. But if you create your own styles, you'll need to make sure they exist in every skin available to your end users.

Writing a Portlet

Finally, I can show you a portlet. The portlet code is actually very simple, as shown in Figure 4.

Figure 4: The "Hello Portal World" portlet shows the bare minimum needed to create a portlet.

There's really not much to the class. In fact, a servlet programmer would recognize the code immediately; replace the word "Portlet" with the word "Servlet" or "HttpServlet" throughout the code, and there's little difference between the HelloWorld servlet and the HelloWorld portlet. (I do find it amusing and maybe a little bit disquieting that you must include the jetspeed API in your portlet, but that's a different discussion for a different day.)

The WebSphere Portlet API is very similar to the Portlet Specification developed under JSR168 of Sun's Java Community Process (JCP). That's no surprise, since one of the JSR168 leads is Stefan Hopper, who is also one of WebSphere Portal's architects. This API is quite different from the original Portlet API and from the many vendor-specific portal platforms out there, such as BEA and Oracle. Note that WebSphere's Portal API is not exactly the same as JSR168 (also known as Pluto), but it's very close.

And while you did get a look at the HelloWorld portlet, and you might be led to think that this portlet stuff is pretty simple, do not be deceived. I've avoided everything that's difficult--from URI mangling to data persistence to portlet messaging. Using certain Struts features causes problems. And in certain situations, issues arise relating to authentication and remote servers. All of these complications need to be addressed as early as possible in the design stage. This is no place for "Extreme Programming."

The Poll

Okay, as I promised, there's a poll. I'd like you to tell me what the next area of interest is for you. The only caveat is that the only part of installation I'm going to address is interoperability between the Portal Toolkit and WPE and WDSc; I don't intend to do a blow-by-blow manual on installing WPE, since IBM has already done a great job with that in the instructions that come with the WPE download. Given the size of this product, it's likely that I won't even address the WPE for iSeries product for a couple of months, but there's still plenty of room for discussion.

And we've still got a number of areas in WDSc to cover, so if you're pining for those, feel free to make a note of it in the poll's discussion forum!

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..