Strategies for Integrating J2EE-Based Applications into a Portal Server Environment, Page 2
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.
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.
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
|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.|
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.
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.
Page 2 of 2