Portals can serve many purposes, including the delivery of information used for IT management purposes. A team of engineers within Hewlett-Packard has developed a portal-based J2EE-application, Service Information Portal (SIP), which brings together various management products from HP OpenView, HP's IT management software, and provides a single portal view to many groups of users.

Originally developed before the Java Portlet standard (JSR-168) was released, this product delivers its own portal server and framework. While the team successfully integrated data from the various management systems, the portal lacked the ability to have more flexible layout and navigation. The portal was also limited when it attempted to integrate data from outside sources.

With the Java community's adoption of JSR 168 the SIP team saw the clear benefits of exiting the portal server market. The SIP product provides the content customers want in a single access point, rather than the underlying proprietary portal framework. Many customers of SIP have also built their own enterprise information portals. A big part of portals' value is in the ability to consolidate many pieces of data from various places into one place, so having both an EIP and SIP was a problem for customers.

This growth in the portal server market provided the SIP team with many options for a reference portal server. The team had additional requirements that were atypical of many portal projects. They must deliver functionality in a new portal server that is equivalent to what was available in previous versions. Such functionality that was previously available includes authorization, portal layout and view design, and configuration and application of data filtering. The product had survived for several years and was on version 3.2; developing a migration path was critical as well.

This article describes SIP as it exists in version 3.2, and the changes needed to move to a JSR-168 application using BEA WebLogic Portal Server. It also discusses the benefits of moving to WebLogic Portal Server, compared to using SIP 3.2.

Overview of SIP 3 Portal Architecture
SIP's modules are conceptually very similar to Java Portlets. The modules' implementations are based on Servlet technology, but the configurations of SIP modules and Java Portlets are very different. Within SIP 3, a single module (servlet instance) can be used with many different configurations, and no concept of user-specific settings (portlet preferences) is available. SIP contains a large number of module configurations, instead of a great number of user-specific preferences, as Java Portlets provide. For some installations, a few thousand module configurations would not be unusual. Listing 1 shows a section of what a SIP 3 view file might look like, just to display two columns with a module in each.

SIP 3 contains portal view files for portal layout and overall view and navigation configuration. These portal views are similar to BEA portal template files; they contain the sheets within the view (BEA pages) and module (portlet) placement. However, all of the module configuration information is stored within the SIP view files. Within Java Portlets, portlet configuration is kept in the portlet.xml file. The view file might have five sheets (think BEA pages) and 20 modules (think portlets). The lack of significant overhead encountered when many module definitions are present is a key difference between module configurations stored in view files versus portlet definitions stored within a portlet.xml file. The modules' implementation is a single servlet instance receiving multiple requests with varying configuration information. In a portal server, each unique configuration for a portlet might mean a new portlet instance.

Data filtering is a key piece of SIP functionality. Sometimes a specific audience should only have access to certain management data. An IT service provider may want to provide unique views of management data to different audiences - HR may need to have one view of IT services, and accounting should have their own individualized view. This concept is even more critical when applied to an outsourcing situation, where isolating a customer's access to their own pertinent data can have serious business and legal implications.

Basic SIP authentication requires user validation. The traditional concepts of users and roles are defined within SIP 3, even if this already exits within the authentication system. SIP requires knowledge of roles and users to perform authorization for various portal activities, including who can view or edit which items. Additionally, SIP supports alternative authentication mechanisms such as LDAP, the underlying Web server authentication, or an API to create custom authentication.

The SIP 3 portal framework contains several facets of the term "role" that are critically important. The SIP role delineates which data filter to use and which view a user will see. This, in turn, defines all of the module configurations (see Figure 2). In addition, an SIP user only actively uses one role at a time, whereas, in most Web application servers, a user can be in more than one role simultaneously. If an SIP 3 user has more than one role available, he or she is presented with a drop down box, which allows the user to switch from one portal role to another (see Figure 1).

Portal Server Analysis
The team had to evaluate and choose a portal server that would suit their emerging needs. Two key themes played into portal server selection: the team needed to deliver the same functionality as had been previously available, and they wanted to develop within a robust portal platform that would allow many other integration possibilities. There are some strong open source portal platforms, but these platforms are typically geared toward a more technical community; they may not be JSR 168 compliant, and they may not have sufficient easy-to-use, robust integration possibilities available.

The team chose BEA WebLogic portal server 8.1 for their next release. The portal solutions catalog (http://dev.bea.com/products/wlportal/psc/index.jsp) provided many integration possibilities, and the portal administration application provided a user-friendly administration tool with much of the same functionality available within the previous versions of SIP.

• Figure 5
• Table 1