Moving to Java Portlets and BEA's Portal Server
With a promising portal server, the team was ready to exit the portal server market and enter the portlet content market. Issues the team needed to resolve included:

• Moving modules to portlets
• Translating portal views
• How data filtering would be supported
• Coupling more loosely with authentication and authorization requirements

One of the major differences the team encountered was the use of the PortletURLs and render parameters. By using servlets, SIP 3 could get the entire HTTP request and response, and send any parameters back and forth through Web pages. SIP 3 uses a common coding practice, which involves passing a module ID parameter to help identify a request for a certain module configuration. When a module ID is encountered during a drill down, the SIP portal server displays only the requested module in a maximized window. The SIP portal server had no support for drilling down into two modules at the same time within the same browser. The following JSP snippet is similar to what is found in SIP 3:

<a href="portal?service=<%=serviceID%>&moduleID=<%=moduleID%>">
naviagation link</a>

In the world of portlets for SIP 4, PortletURLs help pass the correct parameters to the correct portlet. A portal server must be able to determine which portlet should receive which parameters and ensure that the portlets retrieve the correct parameters. Using the aforementioned technique would not work; parameter passing needed to be redone. This problem is especially evident when testing in other portal servers, which are free to encode portlet parameters in any way they wish. Changes were made in the SIP portlet code, the display, or both. The following technique corrects this problem of parameter passing:

PortletURL drillDownURL = response.createRenderURL();
drillDownURL.setParameter("service", serviceID);

In addition, the following is updated in the JSP:

<a href="<%= drillDownURL.toString()%>">naviagation link</a>

The SIP product predated some of the Web development tools and technologies used today, and the work described above to correct URL parameter passing was a common task during migration. However, by transferring URL handling into the Portlet API, some additional options were made available. Previously, a drill down in modules would only display the content of a single module. Using the Portlet APIs, the team can drill down and navigate in multiple portlets simultaneously. This can be especially handy when SIP is used to diagnose IT issues, which commonly requires access to a few different spots to obtain the full picture.

Translating Portal Views
The portal view functionality is an easy migration to BEA's terms and technologies. In fact, BEA's concept of books, pages, and nested books provides a significant improvement to SIP users. SIP 3 only supports one level of sheets, which is equivalent to a single BEA portal book with as many pages as needed. There are no possibilities of hierarchical navigation and portal layout within SIP 3. Figure 1 shows the "sheets" provided in SIP 3, and Figure 3 shows SIP content with a nested book and the multiple-level navigation. SIP 3 stored its view files in XML as shown in Listing 1, so an XSL transform can migrate a SIP 3 view file to a BEA portal template file.

Supporting Data Filtering
The data filtering tools within SIP did not change in their capability, but their application was modified. Data filtering can be a key piece of functionality for users, and it's very dependant upon the currently selected role of the SIP 3 user. For SIP 4, a portlet preference is used. When a user accesses a portlet that employs data filtering, SIP 4 obtains the user's filter preference. The filters within SIP 4 contain a new security specification, which details whether a filter is to be available to a list of roles, to all authenticated users, or to all users (including anonymous access). See Figure 4 for the updated relationship between organization filters and SIP portlets.

Moving data filtering into portlet preferences allows far fewer portlets to serve a larger audience of users. In fact, this is true with all portlet preferences. SIP 3 uses module configurations within a view file as shown in Listing 1. If one user prefers a different module view, SIP 3 requires a different role, portal view, and set of module configurations. In contrast, portlet preferences allow any number of users to customize their own personal preferences from a single portlet configuration. Therefore, hundreds or thousands of module configurations used in SIP 3 can now equal a handful of portlet configurations.

Authentication and Authorization
Authentication and authorization concepts were also an easy item to migrate in BEA. All of the BEA tools and integration options to manage users, roles, and groups can now be used for SIP. For existing SIP users, a WebLogic weblogic.Admin batch file can be created to convert all of the SIP users and roles into BEA users, roles, and groups. The following is a weblogic.Admin batch file snippet created during migration.