Datasheet

The differences between portlets and servlets are as follows:
❑ Portlets generate fragments, whereas servlets generate complete documents.
❑ Unlike servlets, portlets are not bound directly to a URL.
❑ Portlets have a more sophisticated request scheme, with two types of requests: action and render.
❑ Portlets adhere to a standardized set of states and modes that define their operating context and
rendering rules.
Portlets are able to do some things that servlets cannot, such as the following:
❑ Portlets have a far more sophisticated mechanism for accessing and persisting configuration
information.
❑ Portlets have access to user profile information, beyond the basic user and role information pro-
vided in the servlet specification.
❑ Portlets are able to perform portlet rewriting, so as to create links that are independent of the por-
tal server implementation (which have various methods to track session information, and so on).
❑ Portlets have two different session scopes in which to store objects: application wide and portlet
private.
Portlets lack some servlet features:
❑ Portlets cannot alter HTTP headers or set the response encoding.
❑ Portlets cannot access the URL that the client used to initiate the request on the portal.
Portlet applications are extended Web applications. Therefore, both types of applications are deployed
in Web archive files (WAR) and both contain a Web application deployment descriptor (
web.xml).
However, a portlet application also contains a portlet application deployment descriptor
(
portlet.xml).
Because a portlet application is an extension of a Web application, it is logical that it could contain other
Web application components. Portlets can use JSPs and servlets to implement their functionality. This
capability is discussed later in the chapter.
Portal Interactions
It makes sense to show how a typical portal interaction occurs before diving into details about how
portlets can render themselves with JSPs and servlets. Figure 1.2 demonstrates the chain of events that
occur inside a portal to manage a typical client request.
Inside a portal is a Portlet API–compliant portlet container that manages the runtime state of portlets. The
container evaluates those portlets into fragments, either by making requests of the portlet or by taking a
fragment from cache. Then, the container hands the fragments to the portal server that manages aggregat-
ing them into portal pages.
Now that you have looked at portals, portlets, and portal containers at a high level, it is time to dig into
the specifics about how to build portlets.
6
Chapter 1
04 469513 Ch01.qxd 1/16/04 11:04 AM Page 6