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.