Portals vs Desktop

Hi

Guessing you are familiar with Java Class and Objects (instances), I will give that analogy. Its not exactly same but concept wise it is same. Portal (.portal file) is like a Class file. Desktop(s) that you create from Portal Admin Tool are like Instances of this single .portal file. Note that each java object instance can have its own values for the instance variables. Same thing for each desktop can have its own set of Books/Pages/Portlets, look and feels etc.

.portal file is a single file that has all the Books, Pages, and Portlets on Pages along with some look and feel stuff. Now desktop is derived from this .portal file. Imagine we have a portal for a company that has HR Dept, Marketing Dept, Sales Dept. For this we can have single .portal file, with 3 Pages HR, Marketing, Sales. Now we can create 3 Desktops like HR Desktop, Marketing Desktop, and Sales Desktop. By default all these desktops will have 3 pages. But for HR Desktop you can remove 2 pages (Marketing and sales). For Marketing Desktop you can remove HR and Sales Page etc. So you will have different desktops for different deparments. But .portal file is the central main file having all the pages and portlets. You can achieve this using Entitlements also by setting proper entitlements for each Page and adding users to those Entitlement Roles. Just for explaination I gave above example.

When we access portal application from .portal file, it is rendered from .portal xml file. But when we create Desktop, .portal file is Parsed and all the stuff is stored in the Database like Books, Pages, Portlets information, Look and feel stuff etc etc.

Also we cannot set Entitlements to .portal file. We can set them only to Desktops. Ofcourse once we set to Desktops, it works for .portal file also. I have seen this. But in reality Entitlements gets applied only to Desktops.

Also, if you want End User to customize the Portal application, like they can add or remove Portlets, pages etc, they Cannot do this in .portal mode. They can do this only in Desktop mode. This is called Visitor Tools Customization. Just like in yahoo or google, we can edit and add/remove portlets, change look and feel etc.

Performance wise, Desktop will be little bit slow, speically if you allow end users to customize their Desktops. For each Customized Desktop, there will be chain of records in Portal tables starting from Desktop, Book, Pages, Portlet Tables. You can see multiple records in PF_Desktop_Instance table. There will be slight performance issue.

But it is always good to have Desktop and expose Desktop as the final url for any portal application. In this way, we can edit .portal file anytime like add new books/pages/portlets etc but Desktop will not be affected. When we are ready to move all these changes, then you can update Desktop with all new changes you made in .portal file.

Having multiple .portal files is not a good idea, unless they are totall different from business point of view like totally different areas/applications. Have one .portal file. Make use of Desktops. Also make use of Visitor Entitlements which are very powerful things from BEA. Using Entitements and without any coding involved, you can control what parts of Portal (Desktop) like Books/Pages/Portlets are visible to which set of Users (Roles, Groups etc).

So given a choice, go for Desktop mode only. Atleast one Desktoo should be fine.

You can fine more details in oracle docs on portal.

Using Multiple Desktops - http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/portals/optimize.html#wp1001690

Managing Portal Desktops - http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/portals/creating_staging.html
 
Venkata Sarvabatla