10
Tue, Dec
5 New Articles

Weaving WebSphere: WebSphere Portal Express Second Step

Development Tools
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times
"Never express yourself more clearly than you are able to think."
--Niels Bohr

I'm sure you'd like to know what I mean by this particular quote. My point here is that as you continue down the path of WebSphere products, they continue to get more and more complex, and at the same time, IBM creates new tools that hide a lot of the confusion. However, it's always been my firm belief that a good IT department only uses tools to help them do things they could do from scratch. That is, to paraphrase Professor Bohr: "Never use tools that do things that you are unable to understand." In this article, I intend to provide a level of understanding of what goes on underneath WebSphere Portal Express (WPE) so that if you decide to use it in your development, you'll know what you're getting.

How Express Is WebSphere Portal Express?

Portals get complicated quickly. Since a portal combines the characteristics of a language, a platform, and an end user tool, it has tasks in all those areas. In order to become expert in all phases of portal implementation, you need to understand not only the portal technology, but also the underlying technologies, including Java, servlets, JavaServer Pages (JSP), and even basic HTML. The idea of an Express version of a product, at least to me, is something that makes this stuff easy to do. WPE seems to succeed in that it makes nearly everything in portal implementation relatively straightforward.

Basic functions of portal implementation include product installation, interface design, security, user management, and development. While each of these is very important, I can't possibly cover them all in one column. As I've done in the past with large subjects, I am going to break the topic into column-size pieces.

Therefore, in this column, I'll introduce the basic tasks of portal implementation:

  • Products and installation
  • Portal design
  • Portal administration
  • Portal security
  • Portlet development

After providing you with a quick glimpse of each topic, I'll provide a poll for you to register your preferences for the next articles.

Products and Installation

This is very much a "good news, bad news" topic. First, the good news: I installed the basic WPE product without a hitch. I actually downloaded the WPE installation software off of the IBM Web site, burned it onto CDs, and have since installed, uninstalled, and reinstalled the software several times without any problems. The installation is not a particularly swift process: Typically, it takes upward of a couple of hours on my 3GHz machine with 1GB of RAM, a 40X CD drive, and a mirrored 7200RPM hard disk.

That's the good news. The bad news is that I'm not yet using WPE for iSeries or the Portal Toolkit. Here was my goal:

  1. Get WPE for Multiplatforms working.
  2. Get the Portlet Test Environment working in WDSc.
  3. Create and test a portlet in the WDSc test environment.
  4. Deploy that portlet to WPE for Multiplatforms.
  5. Get WPE for iSeries working.
  6. Deploy the same portlet to WPE for iSeries.

I ran into some difficulties on step two. When you read this, please understand that IBM hasn't had much of a chance to resolve my problems. I mistakenly thought that the interactions between the various Portal products and tools had been pretty thoroughly exercised, but as it turns out, that's really not the case, so I was asking questions about things nobody else has done. Thus, when I started pushing the issue in earnest last week, I was really only able to get as far as to create a PMR. I hope to get more information on the tools by the time my next column rolls around.

But even though I've really not given IBM a lot of time, my initial results are somewhat disappointing. Level 2 support tells me that the toolkit doesn't work with path names that have folders with periods in them. Unfortunately, the default installation of WebSphere Studio Application Developer (WSAD, the base component of WDSc) uses the folder name v5.1. The best advice from IBM is to uninstall and reinstall WDSc and change the folder name. Since this involves downloading roughly 2.5GB of data, spending several hours uninstalling and reinstalling the product, spending another eight hours or so applying updates to the package, and only then being able to start applying special PTFs required for the toolkit, this is a really poor option. Not only that, I'm not sure I even have control over that particular folder, since it's actually underneath the WSAD folder. I've asked that the installer team fix their program to work with the default folder names of WDSc. If I don't hear from them, I suppose I'll have to try the reinstall route, but that's not something I want to see encouraged.

Second, my IBM contact in the WebSphere Portal development area told me that nobody has installed the Portal Toolkit with WPE and that the recommendation is to install with the standard Portal product. I've been reluctant to do that up until now, because I really wanted to work specifically with WPE, since that's the low-cost alternative and my clients usually can afford only the lower-cost options. The fact that the recommendation is to use the full Portal product rather than WPE doesn't give me a good feeling about testing WPE applications using WDSc. However, the nice man I spoke to in Level 2 said he's sure the toolkit will work with WPE; it's the WDSc folder name that is causing the problem.

I hope this is the case, as I don't want to have to use the full WebSphere Portal product. One major problem with using Portal rather than WPE is the fact that, as a developer, I can download WPE, but I cannot download Portal. (Actually, I just went to the download page, and I can now download WebSphere Portal Express Plus, but I'm not even quite sure what that product is.) As IBM provides me with more information, I'll be sure to provide it to you. But for now, as far as I have been able to determine, WDSc 5.1 is not compatible with the Portal Toolkit.

Portal Design

Portal design is a complex subject by itself. At its simplest, portal design is the concept of aggregating multiple portlets within a single browser page. The key concepts are screens, pages, themes, and skins.

A screen is a JSP that performs a specific function. There are several of them in the basic WPE product, including a login screen, an error screen, and the one you will use most often, the home screen. The home screen is the entry point into your layout of portal pages.

A page is a group of portlets arranged in rows and columns as shown in Figure 1.

http://www.mcpressonline.com/articles/images/2002/040227%20-%20Portal%20Express%20Second%20StepV400.png

Figure 1: A typical screen has a navigation pane as well as one or more portlets. (Click images to enlarge.)

The page has a theme, which identifies the general look and feel of the screen. It might include corporate logos in the upper left corner, for example, or a watermark. It defines a consistent frame that encloses your application. Themes are relatively simple and, in the case of WebSphere Portal, simply identify the basic portions of the screen. Eventually, it will include a special command:

This directs the portal server to execute all of the portlets on the page (as defined by the page layout), aggregate the data into a single HTML stream, and then present the data to the browser.

Finally, there is a skin. A skin details the way a single portlet is rendered. Most skins are very similar to one another. They basically paint the "box" that goes around a portlet, including a title bar at the top like those found on a Windows application, as well as any sort of formatting. And while the skin definition is pretty simple, it's very much a new language, as the snippet in Figure 2 shows.



src=''
alt=''
title=''>

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.

http://www.mcpressonline.com/articles/images/2002/040227%20-%20Portal%20Express%20Second%20StepV401.png

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.

import org.apache.jetspeed.portlet.*;
import java.io.*;

public class HelloWorld extends PortletAdapter {

   public void init(PortletConfig portletConfig)
      throws UnavailableException
   {
      super.init( portletConfig );
   }

   public void doView( PortletRequest portletRequest,
                       PortletResponse portletResponse )
      throws PortletException, IOException
   {
      PrintWriter writer = portletResponse.getWriter();
      writer.println(" Hello Portal World!");
   }

}

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..


BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: