Introduction
The goal of this article is to help the developer understand the issues associated with migrating an application from an application server architecture to a portal-centric architecture.
Need for Migration to a Portal Server
When should an organization think about integrating application and portal server environments? Let’s consider an example:
Suppose that Company X has more than 15,000 employees all around the world, and has about a dozen applications ranging from a benefits application for all its employees to an inventory system that tracks inventory data from its suppliers. All of these applications were application-server based and worked as expected. As the company grew larger, so did the need for a single sign-on system to the various applications, and access to SAP as well as mail-based systems over the Web. Although many applications were Web-enabled, they were developed by different development teams using a variety of technologies. This led to proliferation of many URLs and, of course, multiple identity systems. The solution to the problem was to use a portal and aggregate all the applications into a single user interface with integrated identity.
Other benefits of using the portal server could include:
- Wireless access
- Secure remote access
- Knowledge management
- Real-time collaboration (chat)
A portal server environment offers the ideal platform since it provides all the above services and much more. For example:
- A user can access e-mail, his local file-system, static Web pages, as well as applications running on either a Web or application server.
- Once someone logs in to the portal, the user doesn’t have to log in again to access any of the above mentioned applications, which require authentication. The Single Sign On (SSO) facility of most portal servers provide this freedom to integrate these types of applications.
- An authorized portal user can telnet/ftp from outside of the firewall to another user’s machine and use the files/resources that user normally would (without opening the ports for ftp/telnet in the firewall).
- The user can personalize the content available through the portal server, such as the look and feel of the pages he or she sees on the browser.
- The contents/applications available through the portal server can be made accessible according to a user’s job role/position in the company.
- Portal and application servers provide very complementary services, so the purpose of this article is to highlight the specific areas the developer needs to think about when building applications.
The following sections attempt to highlight the areas that must be considered when planning to use the portal server and application server in the same environment.
Migration Case 1
In many situations, an IT team knows that the application being built using application servers will ultimately be integrated into a portal environment. Here are some tips on how to make that integration and deployment easier:
- Follow a Model-View-Controller (MVC) pattern as much as possible when building a J2EE-based application. MVC patterns represent best practices development techniques where business logic is separated from presentation logic to provide greater flexibility for applications to change over time without having to recode entire applications.
- Make sure JSP forwards and redirects behave as intended in the portal server. There are cases where these are not allowed. Other forms of navigation, such as HREF, should be used with caution too because these can take the navigation out of a portal environment.
- Do not handle authentication and authorization programatically in the application. Leverage the container-managed security available with the portal server. Almost all portal servers provide some support for authentication. Because an authentication mechanism can be modified declaratively, this will be much easier to maintain.
- Make sure the session bean façades expose remote interfaces also, because the Web tier may be hosted in a separate server in a portal environment.
- The target portal server may not support the version of J2EE that the application server supports; therefore, make sure the JSP/servlets are compatible with the portal server versions.
Migration Case 2
There will be cases where an existing application running in an application server environment has to be moved to a portal environment. This is a tougher job than the previous case, because each case is unique and dependent on the application in question. Nonetheless, most of the points mentioned in Case 1 apply for this case too.
Enterprise JavaBeans (EJBs)
Portal servers typically use a Web server for HTTP services and have access only to the servlet container; hence, there is no support for EJBs in a portal environment.
However, communication via RMI/IIOP can be used to talk to EJBs deployed on a variety of application servers. For applications that were not designed to have the Web tier and the EJB/business logic tier separated, this can be a bottleneck. EJBs with only local interfaces can be retargeted for remote access by defining a remote home and remote business interface. This will, of course, require re-compiling the code.
Resource Access
Servlets that make direct calls to databases might need modifications because, in a portal environment, there may not be any connection pooling as there is in a application server. The same holds true for other resources like JMS connections and connections to integration servers that have to be dealt with separately.
Portal servers may not provide any connection pooling facility; such a facility is typically found in an application server environment. Consequently, servlets that make direct calls to databases might need modifications. One way to do this is to move the database access logic to a session Bean on the application server and use the original servlet in a wrapper, thus reusing the original code for all the business logic.
The same holds true for other resources like JMS connections and connections to integration servers that have to be dealt with separately.
Security
Portal servers generally have the same if not better support for security than application servers. If your application uses an application-specific or custom methods for securing the site, migrating to a portal environment will be difficult. Normally, applications designed for just application server deployment have custom ways of handling roles and access rights. Portal servers provide role-based access to resources by default. The resources in a portal server can be HTML or JSPs or any other resource in the Web server environment that can be accessed by a URL. The application might require a re-design of its security to suit the portal server.
The advantage of using portal server mechanisms is that security can be handled by the administrator and changed according to the deployment scenario. It also makes sense to have the directory (LDAP) of the application users (used for authentication) designed before you make the application changes.
Table 1 lists authentication mechanisms supported by most portal servers.
Table 1: Authentication Modules
| Module | Description |
| Anonymous Authentication | Enables login as an anonymous user. Can be limited to specific types of access, such as read-only and search functions. You cannot customize your desktop when logged in as an anonymous user. |
| Certificate-based authentication | Identifies and authenticates users by means of personal digital certificates (PDC). |
| LDAP directory authentication | Requires authentication with a user name and password stored in the directory server. |
| Membership authentication | Enables creation of a registered account and personalization without the aid of an administrator. Implemented like personalized sites, such as my.netscape.com. |
| RADIUS server authentication | Performs a two-step process that requires configuring the RADIUS server and then registering and enabling the RADIUS authentication server. |
| SafeWord authentication | Authenticates requests to Secure Computing’s SafeWord. |
| UNIX authentication | Processes authentication requests against UNIX user IDs and passwords known to the operating system. |
Personalization
Portal servers are generally designed to provide personalized content with no programming involved. An application server typically does not provide any such feature. Personalization is exclusive to portal servers and the application can’t control it because it is individual preference that controls it. Opening a new window or hardcoding the view to a particular dimension of the window will interfere with the portal server view of things.
Portal servers provide a personalization element that is controlled by the individual end-user. That is, end-users can define which applications and content elements they want to view via a single portal server installation since the portal server aggregates multiple applications together. However, the application server just serves the application—the notion of personalization doesn’t exist, which means that if a developer tries to ensure that an end-user view is locked into a particular application, that would break the portal server model which allows end-users to choose their view, irrespective of which application is served through the portal.
Resources
http://developers.sun.com
http://docs.sun.com
http://java.sun.com
http://java.sun.com/blueprints/patterns/
About the Authors
Srikanth Ramakrishna is a member of Sun’s software engineering team and joined Sun in January 2002. He’s been actively involved in the support and development efforts for the Sun Java System stack, the J2ME platform, Web services, and programming tools. Srikanth also assists ISVs with developing applications on Sun Java System products.
Sanjay Sarathy is director of Sun Developer Network, Sun’s initiative to enable developer success with its technologies and products. Sun Developer Network creates an integrated developer experience combining technology and product access, documentation, support services, content and community offerings.
