ADF 11g的配有一个不错的新功能：taskflows。 通过使用任务流，使您的应用程序的模块化。 每个任务流有自己的导航和事务控制。 导航控制任务流延伸常规JSF导航控制，因为在常规JSF导航控制，你只能使用JSF页面，但你也可以在taskflows导航方法。 这给了你很大的自由。
Portlet是门户和基于标准的设计。 JCR已经指定了两个标准的portlet。 第一个被称为JSR168描述portlet和门户之间的合同。 它定义了接口的Portlet和Portlet可以如何与门户沟通。 后的第一个标准，他们创建JSR286，它是一个扩展的第一标准。 JSR286是比第一种更灵活。 还介绍了如何Portlet可以一起交流，根据参数或事件。
Portlet是一个J2EE技术和因为它已经standerdized，，你应该能够使用任何J2EE门户网站上的portlet。
目前的WebCenter只支持JSR168 portlet间通信的标准，所以不使用标准的。 甲骨文公司已经建立了自己的实现，支持IPC。
当你编辑一个页面，并使用Oracle作曲，你应该知道的资源目录。 这包含了所有的资源，您可以添加到您的页面。 该目录可以包含portlet和taskflows。 您可以同时使用portlet和taskflows的建立你的网页在运行过程中，所以，当你应该使用一个任务流时，你应该使用的portlet ...
有一些REALY taskflows和Portlet之间的重要区别，你应该知道。 下面你可以找到几个主题，我比较portlet和taskflows的。 根据你的要求，你应该能够知道使用哪一个。
标准
Portlet是标准，所以“normaly”你可以将它们部署到任何J2EE门户。 这意味着，当你改变从网络中心到另一个门户网站，你可以轻松地部署新门户JSR168的portlet。 使用taskflows当你，你必须重建一切。
当你正在开发ADF的portlet，这是另一回事... 我没有管理使用ADF的portlet，不同的J2EE像Liferay的门户......
首选项
在JSR168标准，他们指定的portlet功能来存储用户的喜好，所以每个用户都可以在portlet personlize。 这不是可能与taskflows。 当你使用taskflows的，你应该创建自己的系统存储的偏好，但就是不是简单的继电器。 你必须找到一种方法，为了知道哪些偏好是哪个实例都有一个唯一的标识符每一个任务流的实例。 这是REALY并不容易。
安全
Portlet是像小门户网站中嵌入的应用程序。 这些portlet的性质不允许通过的SecurityContext从消费门户。
当你使用taskflows的，所以你可以很容易地检查，如果用户是在一个特定的角色或从您的应用程序的SecurityContext。 这不是那么容易的portlet。
JSR168标准的描述，你可以通过J2EE角色从您的portlet但ADF和WebCenter应用程序不使用J2EE角色在他们的安全模型，使您的消费应用程序，当你尝试使用JSR168的方式，从用户的角色传递，您将无法使用它们。
渲染ADF的portlet
也有在渲染portlet和taskflows的一个很大的区别。 Taskflows呈现在页面内而ADF的portlet是使用iframe呈现的。 这有很多缺点。 例如，你正在创建一个portlet有一个弹出窗口，为创记录的一些细节。 将会呈现iframe里面的弹出。 这也意味着，你会得到弹出窗口的滚动条，如果大于常规内容对您的portlet。
联和触发任务流每个弹出的页面中呈现，并不仅限于空间的任务流，任务流总是呈现。 Portlet的就是这种情况。
一旦一个portlet已设置为您的网页的大小也不会改变。 如果你有你的页面的动态内容，例如，你使用一个panelAccordion，你打开一个面板中，portlet将不会增长，但你会得到滚动条显示的内容。 这是不是REALY用户友好。
由于这种约束，你将需要非常当心，当你设计一个ADF的portlet。
部署
当您使用taskflows，部署PROCES，是有点困难。 这并不困难，但它更容易与portlet。 当您创建新taskflows，你应该将它们添加到您的消费应用程序库，编辑：资源目录EN重新部署你的应用程序。
当您在部署新的portlet，你只需要注册WSRP的供应商，所以没有你的消费应用程序需要重新部署在WebLogic Server中的企业经理。 资源目录全自动拿起注册的每一个供应商与EM。
结论
如果你是绝对确定的标准不介意你有没有需要部署相同的不同的充门户网站比taskflows的portlet的是一个很好的方式去。 唯一的问题你将面临personlization的。 ，如果personlization是不是一个问题，比去taskflows。
如果的personlization是一个很大的要求比你需要去为portlet。 你将有一些额外的工作，周围的其他问题，如渲染和安全工作，但它应该有可能。
Difference between ADF portlets and taskflows
published by Yannick on 12 January, 2011 - 22:10
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.
Standards
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...
Preferences
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.
Security
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.
Deploying
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.
Conclusion
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.