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.
