ADF 11g comes with a nice new feature: taskflows. By using taskflow you are making your application modular. Each taskflow has its own navigation and transactional control. Taskflow navigation control extends the regular JSF navigation control because in the regular JSF navigation control, you only can use JSF pages but in taskflows you can also navigate to methods. This gives you a lot of freedom.
Portlets are designed for portals and standard based. JCR has specified two standards for portlets. The first one is called JSR168 which describes the contract between the portlet and the portal. It defines the interfaces of the portlet and how the portlet can communicate with the portal. After the first standard, they created JSR286 which is an extension of the first standard. JSR286 is more flexible than the first one. It also describes how portlets can communicate together based upon parameters or events.
Portlet is a J2EE technology and because it has been standerdized, you should be able to use a portlet on whatever J2EE portal.
Currently webcenter only supports the JSR168 standard so inter-portlet-communication is not done by using the standard. Oracle has created their own implementation to support IPC.
When you edit a page and use the Oracle Composer you should know about the Resource Catalog. This contains all the resources that you can add to your page. The catalog can contain both portlets and taskflows. You can use both portlets and taskflows to build your pages during runtime so when should you use a taskflow and when should you use portlet...
There are some realy important differences between taskflows and portlets that you should know about. Below you can find a few topics were I compare portlets and taskflows. Based upon your requirements you should be able to know which one to use.
Portlets are standards so "normaly" you could deploy them to any J2EE portal. This means that when you change from webcenter to another portal, you can easily deploy your JSR168 portlets on the new portal. When you use taskflows, you have to recreate everything.
When you are developing ADF portlets, this is something else... I haven't managed to use ADF portlets on a different J2EE portal like Liferay...
In the JSR168 standard, they specify that portlets have the feature to store user preferences so each user can personlize the portlet. This is not possible with taskflows. When you use taskflows, you should create your own system to store preferences but that is realy not simple. You have to find a way to have a unique identifier per instance of a taskflow in order to know which preferences are with which instance. This is realy not easy.
Portlets are like small applications you embed in your portal. The nature of those portlets does not allow to pass the securityContext from your consuming portal.
When you use taskflows, the securityContext from your application is available so you can easily check if a user is in a specific role or not. This is not so easy with portlets.
The JSR168 standard described that you can pass J2EE roles from your consuming application to your portlet but ADF (and webcenter) applications do not use J2EE roles in their security model so when you try to use the JSR168 way to pass the roles from a user, you won't be able to use them.
Rendering ADF portlets
There is also a big difference in rendering the portlets and taskflows. Taskflows are rendered inside the page while ADF portlets are rendered using an iframe. This has lots of disadvantages. For example, say you are creating a portlet that has a popup window with some details about a record. That popup will be rendered inside the iframe. That also means that you will get scrollbars if the popup is bigger than the regular content of your portlet.
A taskflow is always rendered inline and each popup you trigger from the taskflow is rendered in the page and is not limited to the space of the taskflow. This is the case for portlets.
Once a portlet has been set to your page, the size will not change. If you have dynamic content of your page for example you use a panelAccordion and you open a panel, the portlet will not grow but you will get scrollbars to display the content. This is not realy user-friendly.
Because of this constraint you will need to be very carefull when you design an ADF portlet.
When you use taskflows, the deployment proces is a little bit harder. It's not difficult but it's easier with portlets. When you create new taskflows, you should add those to the library of your consuming application, edit the resource catalog en redeploy your application.
When you deploy new portlets, you only need to register the WSRP provider with the enterprise manager in weblogic server so no redeploy of your consuming application is needed. The resource catalog will automaticly pick up every provider registered with the EM.
If you are absolutly sure standards don't mind and you have no need to deploy the same portlets on differnt portals than taskflows are a good way to go. The only problem you will be facing is the personlization. If personlization is not an issue, than go for taskflows.
If personlization is a big requirement than you need to go for portlets. You will have some extra work working around the other issues like rendering and security but it should be possible.