Portlets
Portlets are a central part of WebSphere Portal. Portlets are small portal applications, usually depicted as a small box in the Web page. Portlets are developed, deployed, managed, and displayed independently. Administrators and users compose personalized portal pages by choosing and arranging portlets, resulting in customized Web pages.
WebSphere Portal ships a rich set of standard portlets. See Installed portlets, under Working with portlets for a list of shipped portlets. Then, for the most up-to-date information on portlets, including the latest portlets that are available for download, visit the IBM Workplace Solutions Catalog at the WebSphere Portal Web site.
This topic is divided into the following subtopics:
Portlet applications
Portlets are more than simple views of existing Web content. A portlet is a complete application, following a standard model-view-controller design. Portlets have multiple states and view modes, plus event and messaging capabilities.
Portlets run inside the portlet container of the WebSphere Portal component, similar to the way a servlet runs on an application server. The portlet container provides a run-time environment where portlets are instantiated, used, and finally destroyed. Portlets rely on the WebSphere Portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and store persistent data.
Generally, portlets are administered more dynamically than servlets. For example, portlet applications consisting of several portlets can be installed or removed while the WebSphere Portal component is running. The settings and access rights of a portlet can be changed by an administrator while WebSphere Portal is running, even in a production environment.
Portlet modes allow a portlet to display a different user interface, depending on the task that is required of the portlet. A portlet has several modes of display that can be invoked by icons on the portlet title bar: View, Help, and Edit.
A portlet is initially displayed in its View mode. As the user interacts with the portlet, the portlet can display a sequence of view states, such as forms and responses, error messages, and other application-specific states. Help mode provides user assistance. Edit mode provides a page for users to change portlet settings. For example, a weather portlet might provide an Edit page for users to specify location. Users must be logged in to WebSphere Portal to access Edit mode.
Each portlet mode can be displayed in normal, maximized, or minimized states. When a portlet is maximized, it is displayed in the entire body of a page, replacing the view of other portlets. When a portlet is minimized, only the portlet title bar is displayed on the page.
Portlet API
Portlets are a special subclass of HttpServlet, with properties that allow them to easily plug in to and run in WebSphere Portal. Portlets are assembled into a larger page, with multiple instances of the same portlet displaying different data for each user. Portlets rely on WebSphere Portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and store persistent data. The Portlet API provides standard interfaces for these functions.
The portlet API defines a common base class and interfaces for portlets to cleanly separate the portlet from WebSphere Portal infrastructure. In most respects, 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 redirects as a response. This is done only by WebSphere Portal itself, which controls the overall response page.
Usually, many 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 WebSphere Portal assembles all the markup fragments when all the portlets finish or time out. Portlets that are not considered thread-safe are rendered sequentially.
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 the portlet needing to know how URLs are structured in the particular portal.
Portlet communications
WebSphere Portal provides a way for portlets to communicate with each other. In a production portal, portlet communication could be used to copy common data between portlets. This saves redundant typing for the user and makes WebSphere Portal easier to use. For example, one portlet might display information about accounts while a second portlet displays information about transactions that have occurred for one of the accounts over the last 30 days. To do this, the transactions portlet needs to obtain the corresponding account information when it displays the transaction details.
This is accomplished by communication between the two portlets, using portlet actions and portlet messages. In this example, the account portlet creates a portlet action and encodes it into the URL that is rendered for displaying transactions. When the link is clicked, the action listener is called, which then sends a portlet message to send the necessary data.
Use this event and message feature help unify portlet applications that access disparate back-end applications. WebSphere Portal provides a feature called cooperative portlets which dynamically binds portlets on a page for data exchange. See Cooperative portlets for more details.
Discoverable services
The portlet API provides an interface to enable dynamic discovery of available services. Each service is registered in a portal configuration file and is accessed from the PortletContext.getService() method, which looks up the factory for the service, creates the service, and returns it to the portlet. This makes services available to all portlets without having to package the service code with the portlet.
WebSphere Portal provides discoverable services for its credential vault, for managing persistent TCP/IP connections, and for managing the WebSphere Portal content repository. New services can be implemented by portal developers, such as search, location, notification, content access, or mail services.
Portlets can also be grouped together in a portlet application. Portlet applications are distributed and deployed using Web archive files (WAR). There are portlet-specific extensions to the standard Web application deployment descriptor.
WebSphere Studio Site Developer provides an excellent development, test, and debug environment for portlet applications. You can implement the Java classes for portlet classes and test and debug the Java code. WebSphere Studio Site Developer also provides tools for creating Java Server Pages, HTML pages, images, and other related portal resources. In WebSphere Studio Site Developer, the portlet can be packaged into a WAR file and easily deployed to the run-time server.
See also