Portlets - Relationship With J2EE and Servlet Specification

In my previous post - An Introduction to Portal and Portlets we had an overall idea about Portal and Portlets and got answer to many common questions like - What is Portal ? What is Portlet ? What is Portal Container ? What are the features provided by Portal applications ? etc.

In this post, I will try to explain What is Portlet Specification ? What is relationship between Portlet API and J2EE specification ? What is similarities and differences between Portlet API and Servlet Specification ?

Let's start with What is Portlet Specification?

Portlet Specification, or Java Portlet Specification is a specification provided by JCP (Java Community Process) which defines Portlet API and standardizes rules for various components of Portlet API (like portlet preferences, user data, portlet request and response, deployment, packaging, security etc) to achieve interoperability among various portlets and portals.

The first version of Portlet Specification (JSR-168) was released in October, 2003. In  February 2006, the second enhanced version of Portlet Sepecification (JSR-286).

(To learn about differences between JSR-168 and JSR-286, keep following my future posts :-) )

Well, we all know that for Web Applications, a specification is already there named: J2EE (Java 2 Enterprise Edition) specification. Then why we need a separate specification for Portlets.

The answer lies in similarities and differences between Portal application (or Portlets) and Web Applications (or Servlets).

Just have a look at following pictorial comparison between a J2EE Web Application and a Portal Application.

Web Application vs Portal Application

Don't both of them look and work in almost same manner? For example, a web application can contain multiple servlets and a portal application can contain multiple portlet applications. Servlets process incoming requets and generates output (HTML), same way, portlets also process incoming requests and generates markup fragments (a part of entire output). 

Yet, there are some subtle  differences. For example, incoming requests in case of portlets are further divided into two categories: ActionRequests and RenderRequests (Keep following my future posts for more details about Request Types in Portlets), portal does content aggregations from different portlets before sending output back to the client. Each portlet can have their own preferences (called portlet prefrences), portal provides personalization and other features which a general web application doesn't do. 

From above, what we can say is that portal applications are sophisticated version of web applications with all the features a web application provides along with some specialized features like content aggregation, personalization, single sign-on etc.  Similarly, portlets are also analogous to servlets in terms of functionality, concepts and behavior. 

Due to all these reasons, Portlet Specificaiton (or Portlet API V1.0) is based on J2EE V1.3  specification. Portlets and Portlet Containers meet all the requreiments specified in J2EE specification.  Poerlet API V1.0 derives many functional and behavioral specifications from Servlet Specificaton 2.3.

Similarly, Portlet API 2.0 is based on J2EE V1.4 and Servlet Specification 2.4.

Following table provides comparision between Portlet and Servlets from various angle:

Servlets	Portlets
Servlets are Java technology based web components which are managed by Servlet Container or Servlet Engine	Servlets are Java technology based web components which are managed by specialized containers called Portlet Container
Servlets generates dynamic content as output	Portlets also generates dynamic contents as output but the output is only fragment of the markup which will be aggregated by portal into final page
Servlets works via request/response mechanism	Portlets also work via request/response mechanism, however, portlet  request/response mechanism is more refined (further categorized into action request and render request)
Servlets are directly bound to URLs	Portlets are not directly bound to URLs
Servlets don’t have concept of modes and window states	Portlets have pre-defined modes (View,Edit,Help etc) and window states (minimized,normal,maximized)
In servlet, there is no concept of multiple instances because they do not directly have any visibility on client side.	Portlet can exists multiple times on a single page each instance being independent of each other
Servlets don’t have any concept of preferences to store any customization data like portlets	Portlets have concept of Portlet Preferences where you can store and retrieve any customization and configuration data specific to that particular instance of the portlet on the page
Servlets don’t have access to user profile information (infact in web app, there is no direct concept of user profile)	Portlets have access to user profile information
Servlets do not have URL rewriting functions similar to Portlets	Portlets have URL rewriting functions for creating hyperlinks within their content, which allow portal server indenpendent creation of links and actions in page fragments
Servlet session has only one common scope for store session level data	Portlet session is further  divided into two scopes: Application-Wide scope and Portlet’s Private scope.
Servlets have access to client request URLs, can set character encoding and HTTP headers on response.	Portlets don’t have access to client request URLs directly and cannot set character encoding or HTTP headers on the response.

 

A portlet application  can contain JSPs and Servelts bundled with Portets and shares classloader, application context and session.

Portlets can leverage servlets, JSPs and JSP tab libraries to generate output markup fragments. A portlet can call a JSP or Servlet using portlet request dispatcher just like a servlet can invoke another servlet or JSP.

When a portlet invokes a servlet or JSP,

• All the portlet request attributes gets transferred to servlet request. 
• Attributes set in portlet session are accessible from servlet session and vice-versa.
• Both portlet and servlet shares same output stream. 

A portlet container is nothing but extension of servlet container. It can be built on top of existing servlet container or a portlet container itself can implement all the features of a servlet container.

That's it on Portlet Specification and it's relationship with J2EE and Servlets. 

Keep following my future posts on more details about Portlet API. 

Please provide you valuable comments/suggestions.