Overview

Portlets are reusable components that provide access to Web-based content, applications, and other resources. Web pages, applications, and syndicated content feeds can be accessed through portlets. Companies can create their own portlets or select portlets from a catalog of third-party portlets. Portlets are intended to be assembled into a larger portal page, with multiple instances of the same portlet displaying different data for each user.

From a user's perspective, a portlet is a window on a portal site that provides a specific service or information, for example, a calendar or news feed. From an application development perspective, portlets are pluggable modules that are designed to run inside a portlet container of a portal server.

The portlet container provides a runtime environment in which portlets are instantiated, used, and finally destroyed. Portlets rely on the portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, lookup credentials, and to store persistent data. The Portlet API provides standard interfaces for these functions. The portlet container is not a stand-alone container like the servlet container. Instead, it is implemented as a thin layer on top of the servlet container and reuses the functionality provided by the servlet container.

IBM is working with other companies to standardize the Portlet API, making portlets interoperable between portal servers that implement the specification. The Portlet API provided in WebSphere Portal is the first step toward the Portlet API standardization. For more information about the portlet specification, see 

   http://jcp.org/jsr/detail/168.jsp

 

Portlets and the Servlet API

The abstract Portlet class is the central abstraction of the Portlet API. The Portlet class extends HTTPServlet, of the Servlet API. All portlets extend this abstract class indirectly, and inherit from HttpServlet, as shown: 

...   +--javax.servlet.http.HttpServlet
         |
         +--org.apache.jetspeed.portlet.Portlet
               |
               +--org.apache.jetspeed.portlet.PortletAdapter
                    |
                                        +--com.myCompany.myApplication.myPortlet

Therefore, portlets are a special type of servlet, with properties that allow them to easily plug into and run in the portal server. Unlike servlets, portlets cannot send redirects or errors to browsers directly, forward requests, or write arbitrary markup to the output stream. The portlet container relies on the J2EE architecture implemented by WebSphere Application Server. As a result, portlets are packaged similar to J2EE Web applications and are deployed like servlets.

Generally, portlets are administered more dynamically than servlets. The following updates can be applied without having to start and restart the portal server:

The portlet container relies on the J2EE architecture implemented by WebSphere Application Server. As a result, portlets are packaged in WAR files similar to J2EE Web applications and are deployed like servlets. Like other servlets, a portlet is defined to the application server using the servlet deployment descriptor (web.xml). This file defines the portlet's class file and read-only initialization parameters.

The following figure shows a portlet after its WAR file is deployed. For each portlet deployed on the portal server, it creates a servlet, or portlet class instance, on the application server.

style="border:1 solid #000000;margin:12;"> Application server and portal server view of a portlet

The initialization parameters are set by the portlet developer and can be read by the portlet using the PortletConfig object. The servlet deployment descriptor can contain multiple Web applications, each defined by the <servlet> element. In addition, each servlet definition can point to the same portlet class file, thus creating different PortletConfig objects with different initialization parameters for each portlet class instance. For more information, see Web application deployment descriptor.

 

Portlet deployment descriptor

In addition to the servlet descriptor, portlets must also provide a portlet deployment descriptor (portlet.xml) to define the portlet's capabilities to the portal server. This information includes configuration parameters specific to a particular portlet or portlet application as well as general information that all portlets provide, such as the type of markup that the portlet supports. The portal server uses this information to provide services for the portlet. For example, if a portlet registers its support for help and edit mode in portlet.xml, the portal server will render icons to allow the user to invoke the portlet's help and edit pages.

The following is an example portlet.xml with the minimum tags. 


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE portlet-app-def PUBLIC "-//IBM//DTD Portlet Application 1.1//EN" "portlet_1.1.dtd">
<portlet-app-def>
  <portlet-app uid="com.myCompany.myPortletApp.54321">
    <portlet-app-name>My portlet application</portlet-app-name>
    <portlet id="Portlet_1" href="WEB-INF/web.xml#Servlet_1">
      <portlet-name>My portlet</portlet-name>
      <supports>
        <markup name="html">
          <view output="fragment"/>
        </markup>
      </supports>
    </portlet>
  </portlet-app>

  <concrete-portlet-app uid="com.myCompany.myConcretePortletApp.54321">
    <portlet-app-name>My concrete portlet application</portlet-app-name>
    <concrete-portlet href="#Portlet_1">
      <portlet-name>My concrete portlet</portlet-name>
      <default-locale>en</default-locale>
      <language locale="en_US">
        <title>My portlet</title>
      </language>
    </concrete-portlet>
  </concrete-portlet-app>
</portlet-app-def>

For detailed information, including a description of each tag, see Deployment descriptors .

See also