With Internet penetrating all the walks of life, a web page today has to display diverse information. Sometimes this information is not related to each other, but is relevant to the user. Even thought the result is an integrated web page, several components contribute in creating parts of the web page.
For the developer, this brings in more complexity. As more and more diverse applications have to be integrated to display the integrated output to the user, the complexity involved in developing them increases. It is important to keep the applications independent of each other to make sure that they are not affected by each other. This isolated application, which works as a web component and creates part of the resultant document is the portlet.
The Java community has taken lead to establish the context of a portlet in the Java domain. It has released a Java Specification Request (JSR) – JSR 168 – which provides a standardised Application Programming Interface (API) for portlet development. Portlets were being used by multiple portals even before JSR 168, but every vendor has a personalised portlet development framework. JSR 168 aimed at enabling interoperability between portlets and multiple portals by introducing the standard portlet API.
By definition, a portal provides a common and integrated interface for information from varied sources. Naturally, portlets perfectly apply and JSR 168 addresses portlets in the portal domain.
The portlets runs in a runtime environment provided by the Portlet Container. It also controls lifecycle of a portlet – creation, usage and destruction. The Portlet Container uses the Portlet API to communicate with the portlets. The portlets should comply to the Portlet API so that the Portlet Container can invoke them.
The browser or other clients can use a request/response paradigm to communicate to a portlet. It then processes the requests and create dynamic content in any markup language (XHTML, WML, VoiceXML, …). Along with the appropriate Cascading Style Sheets (CSS) for multiple media, the same portlet can be displayed on multiple devices like a computer, PDA, mobile phone or other devices.
The portal application processes the user’s request and identifies the portlets to be loaded to display the current page. It then calls the portlet container using the Portlet Invoker API. Inversely, the portlet container can get information about the portal itself by using the Portlet Provider Service Provider Interface.
Portlets and Servlets
Portlet is actually a special type of servlet that runs inside a portlet container and use the JSP to render content. The Portlet API is an extension of the Servlet API, so portlets can do everything that servlets can, but in a customised manner. Instead of doGet and doPost, it processes doView and doEdit requests which are sent by the portal application.
Portlets are different from servlets in some aspects, one of them being support for different modes. Depending on the modes, the portlet performs different functionalities. Some of the modes are Help, Edit, View, Config, Preview and custom modes are also supported. Any portlet must support atleast the View mode where the portlet renders the content. Edit mode is a typical property of portals which allow personalised settings of a portlet.
Porlets also support windows states, similar to the windows in other window managers – Normal, Minimized and Maximized. The Normal state is used when the portlet is part of an page that contains other portlets, Maximized indicates that the page will contain only this specific portlet and the Minimized indicates display of minimal or no output.
The Portlet API is powerful and provides access to the user information, caching, portal context. Using this the portlets can have customized behaviour depending on the user or the portal vendor.
Web Services for Remote Portlets
Web Services for Remote Portlets (WSRP) enables integration of different portlets running on different remote machines and different run time environments. This enables portals to access content from remote portlets and also enables publishing portlets as web services. WSRP allows reuse of even the user interface saving lot of time and avoiding duplication of portlets. JSR 168 entities have been aligned with WSRP entities to allow the interaction between two standards.