I'm asked quite often about what the best approach for integrating applications into an existing portal. Should they be rewritten as portlets and run in the Portal itself? What about application isolation, because I don't want a bad portlet taking down my portal? What about the latency effects of running some applications remotely? The answer for what options to use, in typical developer fashion, is "it depends."
First, I think it makes sense to briefly outline your options. You can find more detail on all of these through our product's Info Center as well as from the wide variety of white papers and wiki posts available from the Portal Zone (http://www-106.ibm.com/developerworks/websphere/zones/portal/).
- The first, most obvious, option is to run as a portlet within the portal itself. This of course gives you access to all of the local portal services/facilities, such as Personalization/customization, inter-portlet communication, access control, content integration, etc.
- Build a Web service to front the application, having it perform the heavy lifting outside WebSphere Portal and consume the service in a portlet running local in WebSphere Portal. This has the benefit of offloading the potentially resource-intensive business logic, so the application and Portal don't both compete for the same limited resources, while at the same time projecting a portlet presentation in Portal as a thin shim of logic which like a native portlet gives the application access to other portal features. This web service can also be re-purposed by other business applications, consistent with a SOA approach.
- Run the application as a remote portlet, such as in the lightweight WAS 6.1 or 7.0 WSRP Producer. Portlets can be run either local or remote, so you are not always locked into a remote application model. Plus, portlets can be easily tested outside a portal environment, using the default WAS lightweight portlet aggregators that come with WAS 6.1 and 7.0 (e.g. URL Addressability portal). Also, since the portlet is self contained and requires no component to be specifically developed to run in Portal, as with the web service approach, this promotes a distributed governance model where other groups (departments, lines of business, etc) own the lifecycle of their own application (maintenance, test and deployment) and are not beholden to the processes and schedules of a central portal administration team. Like running as a web service, WSRP is consistent with a SOA distributed application approach.
- Integrate the existing Web application as is. Perhaps there are no plans to refactor an existing application into a portlet or web service; what then? There are several approaches for site-level application integration, none of them rocket science, but all of them effective in their own way and heavily in use today with very good results, including within our own IBM Intranet portal.
- IFRAMEs - customers usually chuckle when I mention this, either because they scoff at the primitive technology, or they are already using it, and are familiar with its limitations. Yes, IFRAMEs can yield highly undesirable effects, such as embedding scrollable regions within the browser, as well as including the other site's navigation and headers. However, if you have some amount of control over the other application, you can make simple modifications to have that site eliminate certain elements of its page, such as navigation and banner regions, if invoked in a certain way. Couple that with an effective single signon implementation, and you can get quite good results, especially since you can still apply portal access control to the IFRAME portlet, protecting it from unauthorized use.
- Site-level federation - If you can't effectively integrate an external site within the Portal page, then don't try. As the old adage goes: "If you can't beat them, join them." The idea of site-level federation is simple, and goes back to the earliest days of portal implementations: link to the other site from within Portal. With common styling and effective single signon, you can make other sites look just like your portal and give your users the impression that they are still in the portal. WebSphere Portal's goal, anyway, is not to have you run everything within Portal, but have Portal be the point of entry and the governor and gatekeeper of all user experience. Couple this with what we call "inside portal" techniques that project Portal navigational and content items into your remote site (a la Web Application Integrator, or WP 6.1 Navigational REST services), you can give the user impression that they have never left the portal.
- Federated portals - A corollary to site-level federation is the notion of running multiple portals and linking between them. The portals can be organized around applications or communities and can be service providers of their own, such that a single application-oriented portal can be reused (linked to) by multiple other portals or sites.
In my next blog post, I'll walk through the decision making process to help you decide which one of the above options would work best for you.