If there's a question that we get more often than When [INSERT_NEXT_PRODUCT_RELEASE_HERE] is going to be available?, it is Should I use Task Flows or Portlets?. I can't remember of a single WebCenter engagement that we on the A-Team have worked on that this question hasn't been asked. Let's see what's currently written up on the internet on the subject and build on top of that.
Not surprisingly, if you search for this topic you're bound to follow some very good information on the subject. I recommend you to also read the following links:
The table below tries to capture some common points when developing ADF and WebCenter based applications, and how these points reflect in each of the three options of developing and deploying a reusable UI flow.
This is not a decision table. The following information should be used for reference when you want to know how each technology maps to a specific requirement or feature. This will give you a better idea of what you need to be aware of and some reference information on how to do it.
|Local Task Flow||URL Task Flow||ADF-based Portlet|
|Interaction Support||Contextual Events here , hereSupports Transactions and Savepoints (when used with ADF BC). Here.||IN/OUT parametersNo transactional support.||Inter-portlet communication and auto-wiringNo transactional support|
|Deployment||Locally within the application's EAR file or as a WLS shared library. Updates require a redeployment and restart of the consuming applications.||Deployed as separate application (EAR) or Web Application.||Deployed as a separate application to a server configured to run as a Portlet Producer. Here|
|Memory Scope||Uses the application's memory scope and can fully leverage application, session, request, view scopes.||Runs on a different memory scope||Runs on a different memory scope|
|Resource Consumption||It can slow down the containing up if it has a processing bottleneck. Likewise, it can cause an out of memory if the code called by the task flow has a memory leak||Does not impact the calling application. Does not offer a time-out mechanism out of the box||Does not impact the calling application. It does offer time out and caching configurations.|
|Architectural Coupling||Tightly coupled modules, composite apps.||Loosely-coupled, but still application-oriented||Loosely-coupled, heterogeneous and legacy application integration.|
|Security||Fully leverages ADF Security Context for ADF and WebCenter Task Flows.||Requires single sign-on (here) or identity federation (here and here) for authentication and correct mapping of enterprise to application roles for seamless authorization.||WS-Security with OWSM is used for authentication. Correct mappings between enterprise and application roles are needed for fine-grained authorization.More info here, here, and here.|
|Run time Configuration Features||None, but can be dynamically added to a page using Oracle Composer and the Resource Catalog.||None||Provides support for personalization (user preferences) and runtime management of Portlet Producer connections.|
|Design Time Features||ADF Library with consumed TFs needs to be in the classpath. Integration tests can be run locally.||No importing required but URL TF information is required: TF URL, IN/OUT parameters. The URL TF needs to be available on a remote server for integration tests. Security infrastructure should be taken into consideration when doing proper integration testing.||No importing required. Producers are configured as connections and portlets define their own metadata/service definition through WSRP (here). Connections can be modified on a post-deployment process from EM or WLST (here).|
Portals, as the name implies, are gateways to other applications. With that in mind, portlets consumed in the portal offer a glimpse - one could say a glass door - to take a quick peek into the application that exposes it. Once it grabs your attention, it should offer you a way of going into that system to check for more detailed information and to take an action - again, using the same analogy glass door analogy, you now opened the door and are inside a specific room. Once inside that room, you're not interested in what's going around in the other rooms.
Ideally, the portlet producer is hosted on the same environment as the application they are exposing. This is so because that application is responsible for managing what is exposing, much like a web service, and can assign the adequate resources to run the portlets without having too much impact on their production environment. For example, you might want to expose a User Profile portlet but you want to limit the amount of information and access to your HR system providing it.
You should use portlets whenever you are aggregating a set of heterogeneous (UI-based) services onto a common view, and these heterogeneous services are isolated, or at least don't have a lot of interdependence between them. If you need more info, or you need to work on a task, you are taken to the real application. In this scenario, the HR team exposed a User Profile info while the Sales team exposed a Your latest sales numbers portlet, both driven say, by the user id, but they don't know about each other.
Composite applications, on the other hand, are assembled by collaborative development of task flows - the task flows are still designed to be modular, but also work together, and often cases to depend on each other, specially when we consider transactions and shared scopes. Not only they will tightly interact, they will leverage the same execution resources. Ultimately, they are contained in the same business domain.
As you probably noticed, my approach to decide to use one over the other is from a pure application integration perspective. Oftentimes I found other decision points that although are technically valid, I don't quite agree with, or at least I don't find them to be able to weigh in as much as my application integration approach. So let's go over some of these points and I will try to explain why I don't find them so important.
If I use portlets I don't need to stop my application when I release a new version or a fix
Yes you do. You need to stop the portlet container no matter what. And that will show up as a portlet timeout on your portal/application. Granted, the main application is still running, but if the portlet is there, it is because it is important. And people will complain.
If you need 24/7 availability (and, believe, you don't most of the time in this scenarios), portlets will not help you. A good infrastructure and the correct deployment process will.
Using a portlet as a patch delivery channel is not a good approach either. If you find yourself in need constantly redeploying portlets than you should review your QA process.
Because portlets render as iFrames I can make my portal run faster
This is often times not true. Yes, in some situations you could have the main page consuming the portlets to render faster, but you still could have portlets taking time to render, and that's not good from a user experience perspective - showing a "loading..." message or empty placeholder box is not the best solution. I'd rather engineer locally running Task Flows to meet the required performance numbers than rely on portlets and iframes as my performance boost option.
I hope I was able to provide you with enough ammunition to make and informed decision when choosing one technology over the other. Please feel free to follow up with your comments; I'm definitely very interested in your experiences and considerations.