My Notes

Portal

We encounter the concept of portals throughout our daily lives. Newspapers and magazines are general portals into world events, sports scores, stock market prices, and local happenings. Company bulletin boards are tailored, providing a look at the world through the eyes of the company for example, by displaying the cafeteria’s current lunch menu, clippings from the latest CEO memo, and workplace safety information.

The lack of a standard approach and technology to address user-experience requirements, such as personalization, customization, and content aggregation in web applications, led to ad hoc ways of implementing these features. The result was maintenance nightmares, lost developer productivity, and longer turnaround time for incorporating new features. The Java portlet technology provides a standard approach to incorporating user-experience features in web applications.

A portal is a web based application that commonly provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems.

Portals aren’t a replacement for web applications but are meant to extend the functionality of existing web applications. Portals gather relevant content from the existing information systems and display it to users based on their identity and preferences. Portals aren’t the answer to every business requirement; organizations should consider carefully whether there is a business case for developing a portal. The personalization and customization features of portals are important from the user’s perspective. From the business’s perspective, the most important requirement to consider is content aggregation.

PORTAL ARCHITECTURE

Portlets are run by a component, called a portlet container, that provides the portlet with the required runtime environment. The portlet container manages the life cycle of all the portlets and provides persistent storage mechanisms for the portlet preferences, letting portlets produce user-dependent markup. The portlet container passes requests from the portal on to the hosted portlets. It doesn’t aggregate the content produced by the portlets; that’s the portal’s job.

A portlet is a Java-based Web component that processes requests from a portlet container and generates dynamic content. The content generated by a portlet is called a fragment, which is a piece of markup (e.g., HTML, WML, XHTML) adhering to certain rules. A fragment can be aggregated with other fragments to form a complete document, called the portal page.

Portlet Vs Servlets:

Portlet windows on a page have several basic elements. In addition to the portlet content, the portlet window has a decoration area that can include the portlet title and controls to influence the window state and the mode. The user can control the size of the portlet window via the portlet window controls, from minimized (only the title is displayed) to normal to maximized (only portlet on the page). The portlet mode influences the requested function of the portlet. A portlet may offer help in a help mode or allow customizing the behavior in an edit mode.

Portlet Lifecycle

The Portlet interface is at the heart of Java’s portlet technology, and it’s mandatory for portlets to implement it, either directly or indirectly. The lifecycle methods defined by the Portlet interface are init, processAction, render, and destroy. The Portlet 2.0 specification also introduced some optional lifecycle interfaces, EventPortlet and ResourceServingPortlet.

The init method is invoked by the portlet container after it has loaded and instantiated the portlet. In the init method, the portlet instance initializes the costly resources (such as setting up a database connection or reading configuration data from an external file) that it will require for request processing.

void init(PortletConfig config) throws PortletException

The javax.portlet.PortletConfig object is provided by the portlet container. The PortletConfig object provides portlet instances with access to their runtime environment and to the information that’s configured in the portlet deployment descriptor (portlet.xml).

The render method is invoked by the portlet container when a render request is received for the portlet instance. The render method is responsible for generating portlet content.

void render(RenderRequest request, RenderResponse response)  throws PortletException, IOException

The RenderRequest and RenderResponse objects are created by the portlet container at request-processing time. The RenderRequest object provides the portlet instance with access to data sent as part of the render request. In the render method, a portlet typically reads information from a data source and uses the RenderResponse object to write content.

The processAction method is invoked in response to an action request. This method represents a user action that results in a state change, such as submitting an order request form.

void processAction(ActionRequest request, ActionResponse response) throws PortletException, IOException

The ActionRequest and ActionResponse objects are provided by the portlet container at request-processing time. ActionRequest provides the action request data to the portlet instance, and ActionResponse is used by the portlet to respond to the action request. The response from an action request may include changing the portlet window state or portlet mode, redirecting to a different URL, or persisting action request data into a persistent store.The processAction method isn’t meant to generate content for the portlet, and any attempt to do so is ignored by the portlet container.

The destroy method is invoked by the portlet container before removing the portlet instance from memory. This is the portlet cleanup method, where the instance may release any held resources (like database connections or EJB references) or save its state to persistent storage (like a database or file).

void destroy()

A portlet’s destroy method can be invoked by the portlet container at any time, depending upon the container implementation. The portlet container ensures that all the requests currently being processed by the portlet instance are completed before destroying the instance.

To create your own portlet class, you can either directly implement the Portlet interface or you can extend the GenericPortlet abstract class.

Portlets Vs Widgets

Similarities:

• Both Portlets and Widgets are mostly concerned with the applications UI. Both assume that there is some useful service on some ‘back end’ system and they provide a user interaction with that service.
• Both Portlets and Widgets can pass information/context to other Portlets or Widgets, and they can also both consume context from other components on the page.
• End users and administrators can put portlets or Widgets onto a page and re-arrange them on the page, and customize their behaviors based on global settings that impact all users in the case of administrators as well as personal settings that only impact that one user.

Difference:

The most obvious is that portlets are a server side component model (designed to execute on the server) and Widgets are client side component models (designed to run in the browser container).

This difference leads to following consideration:

•  Is the team more comfortable with Java or Javascript?
• If there is a lot of logic or data manipulation required, then using a language like Java, or doing that processing on a server vs. on a client is probably a good idea.
• The good and the bad of Widgets is that their source code is down loaded and visible in the browser. Javascript applications can sometimes be malicious, and so you want to do this only with an appropriate client side container such as IBM Mashup Center.  Second, this light weight deployment is only valid when there isn’t server side logic required.
• In the purest sense, Widgets are independent browser calls to server side services and will be, more responsive than the standard portal pattern of rendering all the portlets before returning the page. There are also cases where it is best not to independently render parts of the page. You have more options for rendering individual portlets as well as the portlets using AJAX for improved responsiveness.
• You probably will have some additional testing against different browser types based on how much logic you put into the browser.
• Another consideration is standards and investment protection. Widgets are relatively new and you should expect some amount of evolution and possible churn as the industry moves to standardization.

Refrences:

http://www.jcp.org/en/jsr/detail?id=286

https://www.ibm.com/developerworks/community/blogs/WebSpherePortal/entry/making_sense_of_portlets_and_widgets1?lang=en