1. Portal Vs Website
a. A "Portal" is a subclass of a "Website".
b. Portal is a type of website motivated by stickiness - in a way allowing a user a single window to connect to varying content / services across internet. Typical example here would be RSS Feed viewers - Netvibes, iGoogle, etc.
c. From a corporate perspective - A "portal" can be taken as a framework to render personalized content depending on the logged in person. This is done by aggregating content from various websites and displayed on a screen using layouts - which can be manipulated by the user.
d. These days there are specific products with an administration and configuration tool. These products also have OOTB authentication, authorization, customization, presentation and personalization. Certain product specific API's are exposed that allow configuration of individual content render - also called portlet.
e. In short - "Portal" is a partial destination that allows logged in user to gain access to broad array of destination websites where as a "Website' is a destination in itself.
2. JSR168 vs JSR286
a. JSR-168 – Missing the following
• inter-portlet communication
• serving non-html resources (pdf, doc, images etc.)
• contributing javascript or css to <head>, using cookies
• proper support for common web frameworks
• portlet filters
Inter-portlet communication
• only supported within the same portlet application using session attributes
• target portlets will only “see” messages during next render request
• portlets cannot (should not) update their state during a render request: “event” handling not really possible.
Serving non-html resources
• A portlet can only render html fragments
• Have to fallback/delegate to the servlet container
• Requires coordination between portlet and servlet
Contributing to <head>, setting cookies
• javascript or css can only be embedded withing the content markup; no body onLoad handling hooks
• API forbids adding cookies: only client side setting of cookies using javascript is possible
Proper support for common web frameworks
• Most web frameworks are Servlet API only
• Servlet dispatching not supported from processAction
• Needs Portals Bridges or similar solutions
• JSTL support very limited:
<cut value=”<%= ((FooBean)renderRequest.getSession()
.getAttribute("fooBean",PortletSession.PORTLET_SCOPE))
.getBeanValue() %>"/>
b. JSR-286 - New Features
• Portlet Specification 2.0
• RI will be done under Apache Pluto umbrella with help from a group at University of Jena
• Binary compatible with JSR-168
• Alignment with J2EE 1.4, WSRP 2.0
• Portlet coordination
• Public render parameters - allowing portlets to share parameters with other portlets.
• Shared session state across applications (maybe)
• Portlet events - enabling a portlet to send and receive events and perform state changes or send further events as a result of processing an event.
• Resource serving - provides the ability for a portlet to serve a resource.
• AJAX support
• Portlet filters - allowing on-the-fly transformations of information in both the request to and the response from a portlet.
• Extended cache support
• Improved support for common web frameworks