Portal

A portal is a web application that commonly provides personalization, single sign on,
content aggregation from different sources, and hosts the presentation layer of
information systems. Aggregation is the act of integrating content from different
sources within a web page.
Portal functionality can be divided into three main parts:
1. Portlet container: A portlet container is very similar to a servlet container,
in that every portlet is deployed inside a portlet container that controls the
life cycle of the portlet and provides it with necessary resources and
information about its environment. A portlet container is responsible for
initializing and destroying portlets and also for passing user requests to it and
collecting responses.
2. Content aggregator: As defined in the Portlet Specification, one of the main
jobs of a portal is to aggregate content generated by various portlet
applications.
3. Common services:One of the main strengths of a portal server is the set of
common services that it provides. Services are not part of the portlet
specification, but commercial portal implementations provide a rich set of
common services to distinguish themselves from their competitors. A few
common services that you can hope to find in most implementations are:

Single sign on:Allows you to get access to all other applications once
you log into the portal server, meaning you dont have to log into
every application separately. For example, once I log in to my intranet
site, I should get access to my mail application, IM messaging
application, and other intranet applications, without having to log into
each of these applications separately.A portal server will provide you
with a securedcredentials store. What you do is to go to the mail
application and specify your user name and password once. This
information will be stored in the credentials store in encrypted form.
From the next time onwards, when you log into your intranet site, the
portal server will read your credentials from the store and log into your
mail server on your behalf. The same goes for other applications.

Personalization:The basic implementation of personalization service

allows a user to customize her page in two ways. First, the user can
decide what colors she wants for title bars and what icons she wants
for controls. Second, the user can decide which portlets she wants on
her page. For example, if Im a big sports fan, I will probably replace
the stock and news update portlets with a portlet that lets me track my
favorite team.There are also a few advanced commercial
implementations of personalization services that allow you to decide
which applications should be displayed to user based on criteria such
as his income or interests. In this case, you can create some business
rules like Show the premium products portlet to any user with X

amount of income and Show the discount deals portlet to users with
Y amount of income.
Portlet:--> A portlet is an application that provides a specific piece of content
(information or service) to be included as part of a portal page. It is managed by a
portlet container that processes requests and generates dynamic content. Portlets
are used by portals as pluggable user interface components that provide a
presentation layer to information Systems. Web clients interact with portlets via a
request/response paradigm implemented by the portal. Normally, users interact
with content produced by portlets, for example by following links or submitting
forms, resulting in portlet actions being received by the portal, which are forwarded
by it to the portlets targeted by the user's interactions.
Portlet Container: The lifecycle of a portlet is managed by the portlet container.
A portlet container runs portlets and provides them with the required runtime
environment. A portlet container contains portlets and manages their lifecycle. It
also provides persistent storage for portlet preferences. A portlet container receives
requests from the portal to execute requests on the portlets hosted by it.
A portlet container is not responsible for aggregating the content produced by the
portlets. It is the responsibility of the portal to handle the aggregation. A portal and
a portlet container can be built together as a single component of an application
suite or as two separate components of a portal application. The portlet container is
an extension of the servlet container. As such, a portlet container can be built on
top of an existing servlet container or it may implement all the functionality of a
servlet container. Regardless of how a portlet container is implemented, its runtime
environment is assumed to support at least Servlet Specification 2.4.

Portlet lifecycle
The Portlet interface is the main abstraction of the Portlet API. All portlets
implement this interface either directly or, more commonly, by extending a class
that implements the interface.The Portlet API includes a GenericPortlet class that
implements the Portlet, EventPortlet and ResourceServingPortlet interface and
provides default functionality. Developers should typically extend, directly or
indirectly, the GenericPortlet class to implement their portlets.The Portlet provides
the additional optional lifecycle interfaces EventPortlet and ResourceServingPortlet
that the portlet can implement.
Basic four lifecycle methods
The init(PortletConfig config) method is called once, immediately after a new
portlet instance is created. It can be used to perform startup tasks and is akin to a
servlets init method. PortletConfig represents read-only configuration data, specified
in a portlet's descriptor file, portlet.xml(more on this file later). For example,
PortletConfig provides access to initialization parameters.
The processAction(ActionRequest request, ActionResponse response)
method is called in response to a user action such as clicking a hyperlink or

submitting a form. In this method, a portlet may invoke business logic components,
such as JavaBeans, to accomplish its goal.
The ActionRequest and ActionResponse Interfaces are subinterfaces of
PortletRequest and PortalRequest. In processAction, a portlet may modify its own
state as well as persistent information about a portlet.
The render(RenderRequest request, RenderResponse response) method
follows processAction in the chain of lifecycle methods. Render generates the
markup that will be made accessible to the portal user. RenderRequest and
RenderResponse methods, also subinterfaces of PortletRequest and
PortletResponse, are available during the rendering of a portlet. The way in which
the render method generates output may depend on the portlet's current state. The
destroy() method is the last lifecycle method, called just before a portlet is garbage
collected and provides a last chance to free up portlet resources.

Additional lifecycle operation using EventPortlet

An event is a life cycle operation that occurs before the rendering phase. Events can
be described as a loosely coupled, brokered means of communication between
portlets. Events allow portlets to respond on actions or state changes not directly
related to an interaction of the user with the portlet.
A portlet can declare events in its deployment descriptor by using the eventdefinition element in the portlet application section. In the portlet section, each
portlet specifies the events it would like to publish through the supportedpublishing-event element and the events it would like to process through the
supported-processing-event element.
The supported-publishing-event and supported-processing-event elements must
reference the event name defined in the portlet application section in a eventdefinition element.
The portlet creates events using the setEvent() method during action processing.
This will be processed by the portlet container after the action processing has
finished. Portlets can also create events during event phase by calling setEvent()
method on EventResponse.
To receive events, the portlet must implement the javax.Portlet.EventPortlet
interface. The portlet container calls the processEvent() method for each event
targeted to the portlet with an EventRequest and EventResponse object. The portlet
can access the event that triggered the current process event call by using the
EventRequest.getEvent() method. This method returns an object of type Event
encapsulating the current event name and value.
Additional lifecycle operation using ResourceServingPortlet

The serveResource method can be used to implement Ajax use cases by invoking
the resource URL through the XMLHttpRequest(or XMLPortletRequest) in client-side
JavaScript code.

Portlet and Servlet

Similarities with servlets

Portlets are Java technology based web components

Portlets are managed by a specialized container
Portlets generate dynamic content

Portlets lifecycle is managed by a container

Portlets interact with web client via a request/response paradigm

Portlet vs Servlet

Portlets only generate markup fragments in the render method, not complete
documents. The Portal aggregates portlet markup fragments into a complete
portal age

Portlets can only be invoked through URLs constructed via the portlet API.

Web clients interact with portlets through a portal system

Portlets have more refined request handling, i.e. action requests, event
request,render request and resource requests

Portlets have predefined portlet modes and window states that indicate the
function the portlet is performing and the amount of real estate in the portal
page

Portlets can exist many times in a portal page

Special functionality of a Portlet

Portlets have a means of accessing and storing persistent configuration and

customization data

Portlets have access to user profile information

Portlets have URL rewriting functions for creating hyperlinks within their
content, which allow portal server agnostic creation of links and actions in
page fragments

Portlets can store transient data in the portlet session in two different
scopes: the application-wide scope and the portlet private scope.

Portlets can send and receive events from other portlets or can receive
container defined events.

Functionality not supported by a Portlet

Setting the character set encoding of the render response

The URL of the client request to the portal

Sharing between Portlet and Servlet: Portlets, servlets and JSPs are
bundled in an extended web application called a portlet application. Portlets,
servlets and JSPs within the same portlet application share the classloader,
application context and session.

A portlet can call servlets and JSPs just like a servlet can invoke other servlets
and JSPs using a request dispatcher

When a servlet or JSP is called from within a portlet, the servlet request given
to the servlet or JSP is based on the portlet request and the servlet response
given to the servlet or JSP is based on the portlet response.

Attributes set in the portlet request are available in the included servlet
request

The portlet and the included servlet or JSP share the same output stream

Attributes set in the portlet session are accessible from the servlet session
and vice versa

The lifecycle of the PortletContext is tied to the SevletContext of this web

application and the attributes set in the PortletContext are mirrored in the
ServletContext. The lifecycle of the PortletSession is tied to the HttpSession of
this web application and the attributes set in the PortletSession are mirrored
in the HttpSession. Due to this fact the servlet lifecycle listeners for
ServletContext and HttpSession can also be used for notifications on the
PortletContext and PortletSession operations.

Portlet Config

The PortletConfig object provides the portlet object with information to be

used during initialization. It also provides access to the portlet context,
default event namespace, public render parameter names, and the resource
bundle that provides title-bar resources.

The getInitParameterNames and getInitParameter methods of the

PortletConfig interface return the initialization parameter names and values
found in the portlet definition in the deployment descriptor.

The render method of the GenericPortlet uses the ResourceBundle object of

the PortletConfig to retrieve the title of the portlet from the associated
ResourceBundle or the inline information in the portlet definition.

The getDefaultNamespace method of the PortletConfig interface returns the

default namespace for events and public render parameters set in the portlet
deployment descriptor with the default-namespace element, or the XML
default namespace XMLConstants.NULL_NS_URI if no default namespace is
provided in the portlet deployment descriptor.

The getPublicRenderParameterNames method of the PortletConfig interface

returns the public render parameter names found in the portlet definition in
the deployment descriptor with the supported-public-render-parameter
element or an empty enumeration if no public render parameters are defined
for the current portlet definition.

The getPublishingEventQNames method of the PortletConfig interface returns

the publishing event QNames found in the portlet definition in the
deployment descriptor with the supported-publishing-event element or an
empty enumeration if no publishing events are defined for the current portlet
definition.

The getProcessingEventQNames method of the PortletConfig interface returns

the processing event QNames found in the portlet definition in the
deployment descriptor with the supported-processing-event element or an
empty enumeration if no processing events are defined for the current portlet
definition.

The getSupportedLocales method of the PortletConfig interface returns the

supported locales found in the portlet definition in the deployment descriptor
with the supported-locale element or an empty enumeration if no supported
locales are defined for the current portlet definition.

The getContainerRuntimeOptions method returns an immutable Map

containing portlet application level container runtime options merged with
the portlet level container runtime options, containing the names as keys and
the container runtime values as map values, or an empty Map if no portlet
application level or portlet level container runtime options are set in the
portlet.xml or supported by this portlet container.