Thursday, June 28, 2012

Traditional Portals are dead! Long live 'Script Portals'!

A little history of assumptions

As business grows and competition toughen, enterprises need to make business information more mobile. Around a decade ago, many believed unified web portals to be a rescuer in this mobility game. Technologists betted on web portals based on few two major assumptions:
  • Users will use web as their preferred channel for information consumption 
  • Users would prefer unified information under a single user interface


The reality of generation-i 

World wide web (www) is no longer the talk of the town. Users of generation-i do not believe in unified information anymore. They need information to be available as per relevancy. Today much greater information mobility is demanded where;
  • access channel is flexible and appropriate (www, mobile, tablets, etc.) 
  • controlled flow of relavant information push is preferred over pull behaviors


Limitations of traditional portal platforms  

With the massive buzz around portals, most major technology companies invested in own portal frameworks around a decade ago. Most of these were actually enhancements for existing CMS products, causing portals to be too heavy for the desired purpose. On the other hand, portal standards that emerged (such as JSR 168/268, Web Parts, etc.) were always server side standards causing the developers to be bound to a particular technology and to a specific portal platform.


Life is even harder for 'product' portals 

Product portals (built by ISVs) had even more challenges compared to application portals. 
  • If your product is serving B2B domain, your customer may have own information systems including portals and other channels. Your product information needs mobility and integration capabilities towards those existing eco system. Yet another separate portal could be challenging to sell specially for large customers. 
  • Product are expected to be maintained and developed for a longer time period. It is vital to select a platform which is developer friendly for coming years. Selecting between EpiServer, DotNetNuke, SharePoint, LifeRay, etc is not a simple choice to make. All these platforms will vendor lock you when you start implementing your custom portlets. 


New architecture for product portals - 'script portal architecture'

Imagine placing a Facebook widget inside a simple html portlet of your portal server. It is just a matter of coping and pasting few lines of scripts to make the widget to appear inside the portlet. For example following picture shows Facebook like-box placed inside DNN portal.

We can also develop our custom product portlets in a similar manner as Facebook widgets. With the advancement of HTML(5)/JS technologies, one can avoid dependency on server side portlet rendering completely. Development of each custom product portlet (lets call it a 'script portlet') can be fully decoupled from the server side portal platform, and may even be served from a different server altogether.

This doesn't necessarily eliminate the need for traditional portal systems. Most of the portal/CMS functionality may be used in conjunction with script portlets. Just that we do not develop custom portlets using server side APIs of the portal platform.

Under such an architecture, all your script portlets may be placed on any web page not just on the default product portal. If your customer already has an own portal these components can be easily integrated with copy-pasting simple scripts.
  • The information portlets of your product are decoupled from the traditional portal platform (DNN in this case) and the rendering is done at the client side using javascript DOM manipulations. Developers are now free to move between different portal platforms as need arises. 
  • Data required are fetched as JSON objects (JSONp for cross domain communication) and it is our own custom 'script portal' that integrates with business systems in preparing data. This architecture automatically builds a REST API for business functionality which could be used for deep integrations with third party systems. 
  • If script portlets need to communicate with each other, it is easy to implement DOM based messaging bus that will allow interportlet communication. Use of events will make the smart portlets to be independent without requiring knowledge about related portals. 

4 comments:

creed - Uchitha said...

Hasith,

Doesn't the server portal need to have the capability to host such portlet scripts? I mean can you deploy the same portlet across different portal engines regardless?

Uchitha.

Indika Rathnasekara said...

The question is can you simply put a such portlet script into a SharePoint page ?

Hasith Yaggahavita said...

@Uchitha: Generally traditional portal servers has mechanisms to embed javascripts on portlets (for example on default html portlet in DNN). Even if not, we may write a single serverside portlet as a script host. The only ability needed from the host portal server is the ability to embed a javascript on a portlet. Javascript execution happens on the browser, so that part is independent of the host portal server.

Hasith Yaggahavita said...

@Indika ayya: Im confident Sharepoint allows a way of execution of javascripts on webparts. I found this blob post from msdn which explains how to do it (though I didn't expect it to be that complex ;) ):
http://blogs.msdn.com/b/sharepointdev/archive/2011/02/15/creating-a-web-part-with-client-side-script.aspx