Portalizing an application
kcibmer 1000007V7A Visits (2081)
There are a number of options for "portalizing" an application. Here are the categories, and examples of applications which fit into them.
Create Portal Application:
These applications provide discrete services with open and/or public APIs. An open API is something like REST, web service, or EJB. Some systems use proprietary APIs (eg. SAP), but at least they're documented and well understood in the industry. IBM has tooling to access SAP, PeopleSoft, and Siebel APIs out of the box, and it can also consume any custom Java API (ex. a jar you wrote to interface to a legacy application) and expose those methods. The tooling can also access JDBC sources directly, and can parse XML or JSON data as well.
Create iWidget Application:
An iWidget is an IBM standard for integrating a UI from a non-portal application. The application publishes its entry point (a URL) via a published XML format, and also indicates whether it can send and/or receive events. The UI is rendered by Portal side-by-side with portlets, and can exchange events with portlets. This is for applications which have discrete UI services, but which cannot be converted to Portal apps (they don't have an open API, or they're written in languages other than Java). Applications written in perl, PHP, .Net, ColdFusion, etc.
If an application has no other access mechanism besides its UI, and you are unable to modify that UI, then it might be a candidate for an iframe interface. The application must use form or basic authentication in order create a single signon experience. Portal can log in on behalf of the user and render the UI in an iframe. However, some UIs don't behave well in an iframe, so careful experimentation is necessary. Also, if the UI is too large, then the user is confronted with annoying scroll bars.
The portal provides a link to the external application. This is for applications which have a closed security system, and you can't change the user interface.