HintTech Engineering | IBM WebSphere® Portal

WebSphere Portal | Portlets

You can select from portlets provided in the WebSphere Portal release, including prebuilt portlets and Web and application integration portlet tools. You can also choose from a catalogue of portlets created by IBM and by IBM Business Partners, or you can create your own portlets.

Any particular portlet is developed, deployed, managed and displayed independent of other portlets. Administrators and end users create personalised portal pages by choosing and arranging portlets, resulting in Web pages that present content tailored for individuals, teams, divisions and organisations

WebSphere portlet screenshot that shows what an effective system integration looks like.

The portal server includes a rich set of standard portlets for storing and sharing documents, displaying syndicated content and performing XML transformation. It also includes portlets for accessing existing Web pages and data applications, Lotus Notes and Microsoft Exchange productivity applications, Lotus Instant Messaging and Lotus Team Workplace applications. IBM also offers new and updated portlets and solutions from IBM and IBM Business Partners, called the IBM WebSphere Portal Catalogue.

Portlet applications

Portlets are more than simple views of existing Web content. A portlet is a complete application, following a standard model-view-controller (MVC) design. Portlets have multiple states and view modes, as well as event and messaging capabilities. Portlets run inside the portlet container of a portal server, similar to a servlet running on an application server. The portlet container provides a run-time 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, search for credentials and store persistent data.

The portlet API

Portlets are a special subclass of the HttpServlet class, with properties that allow them to easily plug into and run in the portal server. They are assembled into a larger portal page, with multiple occurrences of the same portlet displaying different data for each user.

The portlet API provides standard interfaces for portlet functions. It defines a common base class and interfaces for portlets to cleanly separate the portlet from the portal infrastructure. For the most part, the portlet API is an extension of the servlet API, except that it restricts certain functions to a subset that makes sense for portlets running in the context of a portal. For example, unlike servlets, portlets cannot send errors or redirect messages as a response. This can be performed only by the portal itself, which controls the overall response page.

The markup fragments that portlets produce can contain links, actions and other content. The portlet API defines URL rewriting methods that allow portlets to transparently create links without needing to know how URLs are structured in the particular portal.

Generally, you can administer portlets more dynamically than servlets. For example, you can install or remove portlet applications consisting of several portlets while a server is running. You can also change the settings and access rights of a portlet while the portal is running, even in a production environment.

Portlet modes

Portlet modes allow a portlet to display a different user interface, depending on the task required of the portlet. A portlet has several modes of display, which can be invoked by icons on the portlet title bar. These modes include view, help, edit and configure.

A portlet is initially displayed in its view mode. As the user interacts with the portlet, it might display a sequence of view states, such as forms and responses, error messages, and other application-specific states. The help mode provides user assistance about the portlet. Edit mode provides a page for users to change the portlet settings. For example, a weather portlet might include an edit page so that users can specify their location. Users must log into the portal to access edit mode. If configure mode is supported by a portlet, it provides a page for portal administrators to configure portlet settings that are shared by instances of that portlet.

Portlet modus state

Each portlet mode can be displayed in normal, maximised or minimised states. When a portlet is maximised, it is displayed in the entire body of the portal page, replacing the view of other portlets. When a portlet is minimised, only the portlet title bar is displayed on the portal page.

Portlet performance

Because portlets are essentially servlets, similar re-entrance and performance considerations apply to both. A single portlet instance (that is, a single instance of the portlet’s Java class) is shared among all requesters. A limited number of threads can process portlets and servlets, so each portlet must do its job as quickly as possible to optimise response time for the whole page. Just as with servlet programming, you should consider optimisations such as limiting the use of synchronised methods, limiting the use of expensive string operations, avoiding long-running loops and minimising the number of objects created. You can also optimise response times by using JavaServer Pages (JSP) to render the portlet’s views. In general, views created with JSP are faster than views created with Extensible Stylesheet Language (XSL).

Usually, several portlets are invoked in the course of handling a single request, each one appending its content to the overall page. Some portlets can be rendered in parallel, so that the portal server assembles all the markup fragments when all the portlets finish or time out. This improves the performance of portlets that access remote data by HTTP or Simple Object Access Protocol (SOAP) requests. However, not all portlets are thread-safe. For example, portlets that access protected resources cannot run in parallel. The portlet deployment descriptor indicates whether the portlet is considered thread-safe. Portlets that are not thread-safe are rendered sequentially.

Portlet output can also be cached. Caching policies are configured in the portlet deployment descriptor. You can include an expiration time and whether the portlet markup can be shared among users or is user-specific.