jump to navigation


What is a portal ?
A portal can be best described as a web site that acts as a “point of entry” or a gate to a larger system. While it seems pretty difficult to define a portal in the strictest sense, these are some of the common features of portals:
Content aggregation:Portals tend to aggregate content from multiple, disparate sources and provide one unified view of the same.
Personalization:This refers to the ability of the portal to tailor the content/services that it offers according to the user of the portal.
Search:Most if not all portals, offer some form of searching of it’s content and sometimes even content from external sources.
Single Sign On:Allows users to authenticate once to the portal and thereby allows access to many other systems without the need for reauthentication.

Do I need a portal server to build a portal ? What is a portal server ?
No, you don’t. You can build a portal using any web based technology: J2EE, Dot Net , PHP or plain old CGI.
A portal server however provides a base infrastructure for rapidly developing/deploying portals. It also provides, out of the box implementations of most of the services that any portal would require.

What is a JSR 168 Portlet ?
Prior to JSR 168, almost all portal platforms offered their own proprietary approach to create pluggable portal components. For example, IBM had IBM portlets, Sun(iPlanet) had Providers, SAP had iViews and Plumtree had Gadgets.
JSR 168 aims to standardize these pluggable portal components so that they are independent of the actual portal server that they are written to. What this means is that one can migrate portlets seamlessly from one portal server to another without any code change.

What are the benefits of JSR 168?
Portal integration components based on the new standard will enable interoperability independent of the portal vendor solution — and enable enterprises to more easily use portal platforms for the secure delivery of personalized Web services and aggregated content between multiple internal and external portal deployments.
For Developers:The new standard will allow developers to reuse existing integration methods for faster addition of data, applications, and services from multiple back-end sources. Developers and independent software vendors (ISVs) will benefit from reduced development time and cost since the specification is based on Java APIs and extends J2EE capabilities to portals.
For Customers:Enterprises will benefit from greater efficiency and ROI since personalized, aggregated content can be delivered from portal platforms to end-users from a multitude of sources previously difficult to integrate.
For Integrators:Integrators will have an easier time integrating and aggregating content for their Portal customers, facilitating the delivery of web services.

What is a portlet container and where will I find one?
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.

Do I need a portal server to deploy/test my portlets?
Yes, Portlets only generate markup fragments, not complete documents. The Portal aggregates portlet markup fragments into a complete portal page. Also,Portlets are not directly bound to a URL and so web clients interact with portlets through a portal system.

What are the differences between portlets and servlets?
Essentially, Servlets provide content that normally takes up the whole page in a browser (unless you’re using frames), and portlets provide content that is wrapped by a window. With portlets, you can have multiple portlets side by side with one another and each one can provide content and functionality that is different from the other. A portlet can provide the complete interaction for one type of application, while another portlet can provide content for another type of application. The portal can provide some house keeping functionality and secured single point of entry to all of the portlets on a page. As for the particulars (similarities/differences) between them, please continue reading.
Here are some similarities:
Servlets and portlets are web based components that utilize Java for their implementation
Portlets are managed by a portlet container similar to a servlet container
Both of these components generate content, which can be static or dynamic
Both portlets and servlets have a lifecycle that is controlled by the container
The client/server model is used for both servlets and portlets
The packaging and deployment are essentially the same
The manner in which the classes are loaded and the class loaders that perform the work are also the same
Lifecycle management is similar
The Request and Response semantics are also similar
Here are some differences:
Servlets can provide complete web pages, whereas portlets only provide fragments. These fragments are then aggregated to form a complete web page by the portal
Portlets aren’t allowed to generated HTML code that contains tags such as base, body, frame, frameset, head, html, or title. The iframe tag can be used with caution.
The user cannot access a portlet directly using a URL in the way that a servlet is accessed. Instead, the URL points to the page containing all of the portlets on one page
Communication between the web client and the portlets is performed through the portal
Portlets can be provided with buttons or controls to manipulate the portlets’ window states or portlet modes
Multiple instances of a single portlet can be placed onto the same page
Portlets support persistent configuration and customization
Portlets also support user profile information
Portlets support two scopes within the session; application scope and portlet scope
There are several things that servlets are allowed to do, but portlets aren’t. These include the following:
Portlet aren’t allowed to set the character set encoding of the response
Portlet also aren’t allowed to set the HTTP headers on the response
Portlet cannot manipulate the URL of the client request to the portal

Developer FAQ
Can I get the HttpServletRequest from a Portlet?
The PortletRequest object is supposed to give you everything you need i.e. parameters, attributes, dispatching, etc. As per the spec, you should not need the HttpServletRequest.
However, some portlet container implementations do provide some kind of hack to get hold of HttpServletRequest e.g. in Pluto you can cast the RenderRequest to HttpServletRequest. But, be aware that this behavior cannot be relied upon.

Can I use sessions in portlets?
Yes, the specification defines a PortletSession interface that allows a portal/portlet-container to use any of the session tracking approaches (such as HTTP Cookies, SSL Sessions or URL rewriting) to track a user’s session. The PortletSession interface defines two scopes for storing objects, APPLICATION_SCOPE and PORTLET_SCOPE.
Use APPLICATION_SCOPE, if you want to access attributes which have been placed within the session in external resources like your servlet. The PORTLET_SCOPE attributes, although available to other resources, are used for attributes that are meant for the portlet’s use only.

What’s difference between PortletConfig.getInitParameter() and PortletContext.getInitParameter()?
Context-wide init-params share the same context space as Servlets and JSPs belonging to the same application and they are defined in the web.xml file. You can get them using PortletContext.getInitParameter() method.
Portlet-wide initialization parameters on the other hand belong in the portlet.xml file and you can get them using PortletConfig.getInitParameter() method.

How can I set/retrieve a cookie from a portlet?
No you cant.There is no direct way to set/retrieve a cookie value from a portlet.
Cookies are used a mechanism for session tracking. The portlet specification does not mandate the portal server to use any particular session tracking mechanism. In fact, the portal server is free to use whatever mechanism it chooses: Cookies, URL rewriting, Https Sessions etc. Portlet developers are expected to use the PortletSession object and leave it to the portal server to deal with the underlying mechanism.

Can I set a cookie from an included Servlet/ JSP ?
This will not work. The Portlet Spec (PLT 16.3.3) mandates that the addCookie() call on an included Servlet or JSP does no operation. If this does work on some containers, then it should be considered a bug and should not be relied upon.

Is there a hack to get/set cookies ?
PortletRequest Properties:The getProperties() method of the PortletRequest would return the HTTP headers,if available. This can be used to retrieve the cookie values in most containers. This behavior cannot be relied upon as there might be circumstances where they are unavailable.
Javascript:You can embed javascript functions in a JSP page and include that JSP in your response. In the javascript,you can have code that can set/retrieve cookies and if needed, pass it over to the portlet

How do I achieve inter-portlet communication ?
Inter-portlet communication refers to the ability by which portlets can communicate with each other in a spec compliant way. There are currently two approaches to achieve inter-portlet communication. The exact approach you choose would depend on the problem you are trying to address
Using the PortletSession:
A PortletSession is created for each user per portlet application. This makes the PortletSession useful for communicating all user related information among different portlets in the same portlet application.
When you set attributes in a PortletSession you have two options: To use a PORTLET scope (this is the default) or to use an APPLICATION scope. If you want the particular attribute to be shared among portlets, you need to use the APPLICATION scope.
For example, consider CityPortlet and WeatherPortlet, two portlets in the same application.In processAction() of CityPortlet: portletSession.setAttribute(“cityName”, newCityName, PortletSession.APPLICATION_SCOPE);
In the WeatherPortlet, you can retrieve the changed city name by getting it from the PortletSession:In doView() of WeatherPortlet: currentCityName=(String)portletSession.getAttribute(“cityName”,PortletSession.APPLICATION_SCOPE); showWeatherForThisCity(currentCityName);
Pretty simple, but here is a caveat. The portlet spec does not mandate any order in which the doView() (or for that matter doEdit() or doHelp()) be called for multiple portlets on the same portal page. This means if you were to set an attribute in the doView() method of CityPortlet you may or may not get the attribute in the doView() of WeatherPortlet (depending on the portal server and perhaps the layout that you are using). The spec, however, does mandates that the processAction() be called before any rendering method is called. Therefore you need to ensure that any state change that needs to be propagated across multiple portlets in the same portlet application is confined to the processAction() method.
Using the PortletContext:
A PortletContext (very similar to a ServletContext) is shared between all users and all portlets in a portlet application. You can get and set attributes from the PortletContext and this can be used as a global point of communication.
For example, if the WeatherPortlet uses a webservice which is currently unavailable. You might have code like this:In doView() of WeatherPortletif(portletContext.getAttribute(“errorMessage”) = null) { displayErrorMessage();}
In this case, all instances of WeatherPortlet irrespective of which user is seeing it, would see the error message.
While inter-portlet communication can be done using any of the above stated methods, one must be careful about the dependencies that are introduced when utilizing interportlet communication.
In the CityPortlet/WeatherPortlet example, what would happen if the user decides to remove the CityPortlet from his page? Would the WeatherPortlet still be functional? Should we force the user to remove the WeatherPortlet as well? These are some of the design considerations that need to be taken in account before using inter-portlet communication.

What if I need two portlets from two different portlet applications to communicate with each other ?
This situation occurs rarely and if it does, you may need to review your packaging structure. Do you really want to couple two unrelated portlets? If they are dependent wouldn’t you rather package them in the same application?
If you still need the portlets to communicate, you will have to use some other standard J2EE communication mechanisms like JNDI , Database with JDBC, messaging through JMS etc

But there should be a way to communicate between portlets in different wars, right ???
Yea. It’s called “remoting”. The fact is that when two portlets are in two different wars, they are consider to be essentially in two different applications. One war = one wep app. The only exception to this rule is when the two wars happen to be actually the same application (meaning the same war) spread across a cluster (running in different JVMs).
That said, if you want two different portlets in two different applications to communicate with each other, there is nothing to stop you from using any of the other J2EE remote communications mechanisms to make it happen. You have your choice of EJBs, RMI, or Messaging. There is nothing in the Portlet spec that would keep you from doing so.
Before you attempt to go this route, there are two questions you should be asking yourself:
How do you go about refreshing the appearance of portlet2 based on the state change? For example, if portlet1 and portlet2 are in two different applications and possibly two different windows, how do you cause portlet2 render method to be called. Normally, this is called on a pull operation (not a push). The only way around this is to use an applet on the client to keep a communication link open, allowing the portlet to push content down to the client.
How do you go about placing two portlets from different web apps in one window if this is the look you desire?
You could also possibly solve these issues using WSRP. However, you are adding more to the layers and therefore taking away from your performance when it just might not be necessary.
It sounds like you’re going about this all wrong. One of the possible uses for Portals is to bring together content from multiple sources. If you have two applications producing output that you wish to bring together in one portal application, the best thing to do (and one of the reasons that portals were designed to begin with) is to create an application that provides the portlets with each portlet pointing to their respective applications. That way you can gather the content from their respective sources easily and effiently and provide their output through the same portlet app. So, essentially, in your case you might have three applications. Two provide content that is channeled and rendered to the user through the third, which happens to be the portlet app.
In this case, you could still use the APPLICATION_SCOPE session attributes to pass content from one portlet to the other. As portlet1 interacts with the user, it places content into the session during its processAction call, and portlet2 uses the content in its doView call. During the doView call of portlet2, it can communicate with whatever application or resource it needs to, in order to gather the content and then produce it back to the portal page in its rendition.


1. riyaz - October 8, 2007

hai srinivasule hai this is riyaz ,i want to learn the portlets can u give the suggestion to me which books i want to study and which sites can i get portal documentations and pdf’s. i have studied portal faqs in ur site . is good , Thanks alot yaar. can u send your mail id if i have any doubts i will ask to you. bye all the best

2. pradeep - December 1, 2007

hai srinivas ,your article is nice .Where can i find more information about portals.
nice job..

3. Naga - January 22, 2010

Hi Allu,

Can you clearly explain
the usage of
portletpreferences ?

4. Rakesh kuimar - February 8, 2011

hai srinivas ,your article is nice and good.Where can i find more information about portals.can i get u r email id so tht i can ask many question on ibm portlet and jsr 168

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: