Caveats on migrating applications from WebSphere Portal to IBM Lotus Expeditor/Lotus Notes 8

Portlet Factory, Version 6.1.2

Caveats on migrating applications from WebSphere Portal to IBM Lotus Expeditor/Lotus Notes 8

Not every portal based composite application or portlet is a good candidate for running locally on end user desktops using the rich client platform. At the minimum you should perform a thorough review of your application's security needs to determine the risks involved. For example:

Many applications may store sensitive data within the web application archive, assuming that the portal server machine and disks will be protected by physical and network firewall security. Moving such sensitive data to a rich client platform installed on less privileged and less trusted end user laptops where the user has direct access to the physical media has inherent security risks.
Some applications may perform access-control level decisions in application logic or WebSphere Portlet Factory profiles stored with the application. Moving such profiles and application code onto an end-user system where they may be modified (for example, by manually editing profiles or by using one of the freely available java decompilers to modify application code) can expose a security risk.
Applications where a separate backend server, not the web application logic, controls access to data (Mail applications, for example), is an example of a reasonable choice for running directly on end-user client platforms/systems.

Not every WebSphere Portlet Factory based application should be ported "as is" from WebSphere Application Server or WebSphere Portal to the rich client platforms. Some applications and back end data integration assume the application is running on a centralized server, and not on possibly hundreds or thousands of desktop machines. For example:

A Datasource on a J2EE AppServer manages a fixed size pool of connections to databases, shared among all users of that datasource on the appserver. Your IT dept and DB Administrators probably would not allow hundreds or thousands of client machines to connect directly to the corporate database servers, so you might have to redesign an application so that every client does not need direct connectivity to the central database server, for example using the IBM® Lotus® Expeditor documented database synchronization mechanisms.
A connection pool manages the connections between WebSphere Portlet Factory applications running on IBM WebSphere Application Server and WebSphere Portal to an SAP server.It is unlikely that your IT department wants hundreds or thousands of individual client machines holding connections open to your SAP server, even if the server can handle that many open connections. You might want to design such applications passing application data to a centralized application server, for example, using web services or similar mechanism, which then communicates with back end data servers such as SAP.

In addition to these examples, there may be other situations where it is appropriate for a centralized application server to access a back end resource, that should not or may not be accessible directly by all of your client machines. Examine your current architecture and determine if your application design has such connectivity issues that may need a redesign before your application can be deployed in an environment where the code runs on every client machine.
Parent topic: Overview of IBM WebSphere Portlet Factory support for rich client platforms

Library | Support |