Portal Architecture , Portlet- A brief study

PORTAL APPLICATIONS AND PORTLETS
A portal is a gateway of aggregation of information from various sources.
A portal application is a group of portlets that form a logically associated group.
Portlets in an application are installed as a single package. When programmed
appropriately, they’re able to communicate with one another by sending and
receiving messages.  
A portlet is one small piece of an overall portal. It is one element of many that could appear on the user’s screen.

PORTAL ARCHITECTURE

Portlets are run by a component, called a portletcontainer, that provides the

portlet with the required runtime environment. The portlet container manages the life cycle of all the portlets and provides persistent storage mechanisms for the portlet preferences, letting portlets produce user-dependent markup. The portlet container passes requests from the portal on to the hosted portlets. It doesn’t aggregate the content produced by the portlets; that’s the portal’s job. Figure below depicts the overall portal architecture.

Here’s how it works:

1. A registered user (client) opens the portal, and the portal application

receives the client request and retrieves the current user’s page data

from the portal database.

2. The portal application then issues calls to theportlet container for all

portlets on the current page.

3. The portlet container, which holds the user’s preferences, calls the

portlets via the portlet API, requesting the markup fragment from each

portlet and returning the fragment to the portal.

4. The portal aggregates all markup fragments together into one page,

which the portal finally returns to the client/user, giving the user the

integrated, useful interface he or she is used to on the desktop.

There are the two major components: the portal itself and the portletcontainer. Now that you know this much about portals, let’s take a closer look at what portlets really are and what their role is in the big picture.

What Is a Portlet? 

A portlet is a Java-based Web component that processes requests from a portlet
container and generates dynamic content. The content generated by a portlet is
called a fragment, which is a piece of markup (e.g., HTML, WML, XHTML)
adhering to certain rules. A fragment can be aggregated with other fragments to
form a complete document, called the portal page.
Servlet and Portlet a comparison. 

Servlets	Portlets
Web clients interact directly.	Web clients interact with portal. Portal acts as mediator, provides infrastructure.
Each servlet assumes it is the only responding component and produces a complete document.	Portlets assume other portlets are responding to the portal's request and produce markup fragments. Portal coordinates response to client, handles character set encoding, content type, and setting of HTTP headers.
Directly bound to a URL.	Addressed only via portal.
Less-refined request handling.	Request handling includes action processing and rendering options.
	Portlets have predefined modes and window states that indicate the function the portlet is performing and the amount of real estate in the portal page available to the portlet.
	Numerous portlets exist on a portal page and therefore require concepts such as the portlet window and portlet entity.
	Portlets need means for accessing and storing persistent configuration and customization data on a per-user basis. Because portlets need to be plugged into an existing portal, these storage functions must be provided by the portal infrastructure for the portlet and thus need to show up in the portlet API.
	Portlets need access to user profile information to generate user-specific output.
	Because portlets are plugged into portal systems, they need URL rewriting functions for creating hyperlinks within their content, letting URL links and actions in page fragments be created independently of the specific portal server implementation.

Java Portlet Specification is closely aligned with J2EE concepts to permit the reuse of as much of the existing J2EE infrastructure as possible. The following points reflect this close alignment:
• Portlet applications are packaged as WAR files, with an additional portlet
deployment descriptor (portlet.xml) for the portlet component, and can be
deployed using the existing J2EE Web application infrastructure for WAfiles.
• Portlet applications reuse the standard HttpSession; thus, portlets can
share data via the session with other J2EE artifacts, such as servlets and
JavaServer Pages (JSPs).
• Portlets can access the Web application context via the portlet API and
share data with other J2EE artifacts on the context level.
• Portlets can access Web application initialization parameters defined in
the web.xml file via the portlet context.