IBM has introduced the full set of features from Lotus Connections (or inhouse IBM Blue) to the Developerwork member community. Now, one can enjoy the full social networking features available as part of Lotus Connections (Profiles, Dogear, Communities, Blogs, Activities) as part of the DW membership.

Check out a sample My developerWorks : Home Page

Check out my profile page here and do tag my profile.

I have moved from blogger to my own domain - http://www.techspot.co.in. Nothing else has changed !

IBM as part of the User Experience Optimization Initiative has releases a white paper on integration of WebSphere Portal with Omniture. The integration helps in tracking the following

• What pages/site sections receive the most views?
  
• What is the affinity between pages and site sections?
  
• What content drives further site consumption?
  
• What pages/site sections exits and entries?

The Omniture integration makes use of Dojo libraries that are now bundled with WebSphere Portal V6.1

For WebSphere Portal integration with Omniture SiteCatalyst, you will need 2 files - s_code.js and specific dojo analytics class created specifically for the WebSphere Portal integration. The javascript file is placed in the theme folder and referenced within the default.jsp.

In addition, if the requirement is to track the specific events (or special events that need to triggered on user button clicks), one can edit the _eventRegistry variable found in analytics.js to add listeners to specific buttons and links on the site.

The integration is support only from WebSphere Portal V6.1 onwards.

Check out the white paper here .

In WebSphere Portal V6.1, there is a new feature available called the Web 2.0 theme. 

Till the previous version, all portlets on a page use to get the rendering aggregation done at the server side-also called Server Side Aggregation(SSA). 

The Web 2.0 theme allows what is called the Client Side Aggregation(CSA). The CSA is made possible by using AJAX. The CSA provides definite advantages over the SSA

• Faster rendering and Performance - since the theme is already pre-compiled and ready, the theme gets rendered to the browser immediately. From the browser, requests are invoked for individual portlets. Overall, gives the impression of faster loading of page to the user. Also, as the aggregation does not happen at server side, load on server also comes down
• Better user experience - since with CSA, the entire page need not be refreshed, only the relevant portlet area is refreshed where user activity takes place. Giving a better user experience

For the enterprises that are planning to migrate to WebSphere Portal V6.1 and want to make use of the Web 2.0 theme, the existing portlets that can used with the theme and they can also make use of AJAX calls for getting their portlet area's refreshed instead of the whole page.

For the user's who may not have JavaScript enables, the theme defaults to Server Side aggregation for such scenario's.

To take advantage of all the functionality provided by CSA, IBM has introduced Client Side Portlet Programming model. The Programming model provides additional tags to handle portlet preferences change, changing portlet window state, changing portlet mode on the client side itself.

When developing Portal applications, there is a tendency to pit too many functionalities on the portal node. There are easier ways by which we can reduce the load on the portal node by following some of these guidelines

• Avoid running multiple services on the same portal node. e.g. Set up Search on a different node or serve images from a dedicated server ( can be edge server)
• Avoid synchronising session data across portal nodes. Sync user session data using Dynacache is huge overhead on the CPU and is very memory intensive. Try using sticky sessions or avoid storing huge data on session
•  When using WCM off the portal node, see if you can make use of remote rendering instead of local rendering
• Try bundling logical portlets in the same EAR. Helps to avoid multiple classloaders
• Uninstall the portlets that are not being used in the environment. If you are managing the environment using XMLAccess, one can even uninstall the adminstrative portlets
• Cache as much as possible - whether it is WCM content or portal assets
• If you deploying newer portal applications - see if you can make use of Client Side Aggregation (CSA) 

Check my earlier post Why Portals might be crawling??