I'm afraid the following decision tree slightly over-simplifies the process of determining what application integration technique should be chosen for WebSphere Portal. It is not meant to be the "gospel" by which all integration techniques are decided. Instead, it should serve as a guide for the types of information that needs to be factored into the decision making process. (This blog post is a continuation of the previous post, where the integration techniques are described in detail.)
The questions below are posited in order. If I believe the answer to a question leads to a certain integration technique, I will say so. Otherwise, I'll direct you to the next question.
After reading through the questions, it may seem odd at first that I lead with NOT starting with portlets, but I found it easier to eliminate the lower fidelity, less elegant solutions first than to try to arrive at the decision to run everyting as a portlet first. There are just too many advantages to using portlets to enumerate as a series of discrete questions, where as there are very few questions that can help you eliminate portlets outright. Hopefully this will make sense to you as you work your way through the list below. Let's get started:
- Will the application remain as an external Web application using some technology that does not easily lend itself to being projected as a remote portlet (via WSRP), or is an application made of several parts that would be very difficult to decompose into portlets (remote or local) and reassembled on the Portal back into the application itself? (The answer can be different based on tactical versus strategic needs, as the decisions made here are not necessarily permanent ones. Also consider that just because the existing technology may not be portlet based, this does not mean that the technology cannot be projected as a remote portlet. Several competitors and IBM business partners offer techniques and technologies for either fronting existing Web applications with or converting them to portlets or WSRP producers.) If so, then proceed to the next question. If no, proceed to question #5.
- Do you have control over the application, to the extent that you can alter aspects of its presentation (such as removing navigational elements, banners, footers, etc)? If so, proceed to the next question. If not, proceed to question #4.
- Will the end user's browser have access to ("see") the application? If so, then IFRAMEs may be the way to go, since you can alter the application to render without redundant navigational or site-level decorations. If not, then Web Clipping, or similar technology, is probably the way to go, since WebSphere Portal must act as the reverse proxy, granting access to the backend web application through requests to the Portal itself.
- You don't have the ability to refactor the site, so site level federation is probably the best way to go. This is manifested as a combination of similar styling (hopefully) between the Portal and the backend app, as well as proper single sign-on linkage between the sites, such that the user's experience of moving from Portal to this external site is as smooth as possible. Tools such as Web Application Integrator (see Portal Catalog) can make this better, as elements of WebSphere Portal itself can be projected into the other application, further making it appear as if it belongs with, or appears to be part of, WebSphere Portal.
- Will this application provide data or services to other applications besides WebSphere Portal? Or are you only after the data from this existing Web application, and not so much its user interface? If so, on either account, then refactoring the application into a Web Service is probably in order. Both RAD and Portlet Factory can quickly and easily help you build a portlet that consumes and renders the Web Service. If not, then proceed to the next question.
- If you are at this point, then the application is most likely destined to become a portlet application. Now we just need to decide if you are going to run it locally or remotely. If you are concerned about the stability or weight (higher than usual CPU or memory requirements) of the portlet, then you are better off running it remotely in a light weight WSRP producer where it can be isolated and scaled independently from the consuming Portal. If you are not so concerned about the portlet, then proceed to the next question.
- If the owner of the portlet is concerned about governance and process issues related to having to distribute the portlet through a central portal management team, then allowing the portlet owner to have their own WSRP producer, where they can own the portlet's entire lifecycle, is probably the best approach. If there are no such concerns, then proceed to the next question.
- Is this portlet application a part of a series of portlets that together make up a composite application, where the user's application is actually a series of portlets and pages that act in concert to provide a unified application experience, AND will it be likely that this composite application will be used in several different portal contexts, OR do you have concerns that this composite application may put high demands on memory and CPU? If so, then you may want to consider dedicating a portal instance, or cluster, to host this composite application and federate this portal with the main portal. This is similar in concept to site-level federation described in question #4, except that we are talking multiple portal's here, so there is great potential for reuse of themes, skins, CSS, and other portal and J2EE artifacts that make the transition between portals much more seamless. If this is not the case, the move on to the next question.
- Well, this one isn't really a question as much as a conclusion. With all other options eliminated, we are left with a portlet, or series of portlets in a composite application, that is running in the local portal. Congratulations, since this is the easiest route by far.
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.
There are other variations on the themes above, some in more experimental stages, such as the use of client-side AJAX-style content fetching or mashups of external web content.
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.