X

Best Practices from Oracle Development's A‑Team

ADF Task Flows versus Portlets. Which one to use?

 Introduction

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.

Main Article

What's on Task Flow vs Portlets on the inter-webs?

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:

ADF Task Flows versus Portlets cheat sheet table

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.

How to read this table

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
User Interface Rendering / Skinning Inherit ADF Faces geometry management from the parent container. Uses the same skin as the consuming application automatically.Rendering of TFs is sequential and can add up to the consumer's  rendering time depending on the TFs performance. Do not support geometry managment. Usually URL TFs are opened as browser popup windows or take over the current browser window until it navigates back to the caller. Doesn't know about the skin being used by the caller application.Rendering time is dependent on the server where the URL TF is running. An external URL request is being issued. Renders inside an iframe, so there's no geometry based support for the portlet, but it is somewhat manageable from the showDetailFrame component that surrounds it (here). There is support for skin detection and synchronization but the skin needs to be deployed together with the portlet. TIP: never use inline (rich) popups in a portlet.Overall JSF rendering is still sequential, but because portlets are rendered as iframes browsers can usually request between 4 to 8 iframes in parallel from the same domain which can sometimes translate to a faster page load time. Please check here.Notice that ADF-based portlets can only be rendered as IFRAMEs. This means that each portlet on the page will download its own set of ADF javascript libraries. Although this can be minimized by enabling caching on the browser and using a CDN, the first download will be a big hit on performance depending on how many ADF-based portlets you have on the page.
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).

What should I consider to pick one over the other?

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.

Conclusion

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content