Hi Veera,
I am pasting the difference between portlets &
servlets. Please find then below. For more you can take a help of Portlet Redbook.
Servlets have the luxury of knowing they will be the only presentation resource returned to the client at any given time. Portlets, on the other hand, must understand that the presentation resource they return will be aggregated into a larger resource returned to the client. As a result, they are forced to consider constraints such as screen real estate, portlet interactivity, and events as well as overall performance.
Real estate
Portlets can access a variety of information through the API to help it understand its current condition in the portal. The PortletState informs the portlet if the user has requested the portlet to be minimized, maximized or restored (normal).
A
portlet should attempt to tailor the content it returns in accordance with the requested state.
For example, if the user has maximized the portlet window, the content returned should adequately fill the portal page. However, if the user has requested that the portlet be minimized, there is no need to return any content. It is important to remember that although the portlet is simply deciding not to return content, it is still executed and any business logic encapsulated in the model will still be performed. It is not possible to dynamically change the state of the portlet except
during event handling.
Page aggregation
Although a servlet may be a single piece of a much larger Web application, at any given point in time only a single servlet is fulfilling a user�s request. This provides a great deal of predictability in that as the master controller, it can guarantee what is executed and returned to the client. This is not true of portlets.
Each portal page is potentially the aggregation of several portlets.
Furthermore, when a servlet executes and returns content to the user, it can be sure that the content it returns will not be affected by any other servlet in the system. This is not true of portlets. A portlet has the ability to write markup to the top of the page even though its normal content is placed inside a cell in a table.
This provides a mechanism to include JavaScript functionality the portlet may need. Be aware, however, that as one portlet has that ability, so do all. As such, you must properly encode variable names and functions.
60 IBM WebSphere Portal Toolkit V5
This functionality must be used with care as there is no inherent mechanism for one portlet to control the presence or absence of another portlet on a page, and as such it cannot reasonably predict what other page-level code may be present.
Inter-portlet communication
Servlets have the ability to share data through a variety of scopes but since they are executed serially by the client, they cannot interact with each other during a single request. Because portlets are pieces of a larger portal, they have the ability to communicate with other portlets and to be affected by other portlets in a single request. This inter-portlet communication provides a way to create a dynamic portlet application crossing multiple portlets on the same page.
For example, one portlet can inform other portlets in the same portlet application or the same page that a user has performed some action. The listening portlets can then alter their presentation, perform alternative logic or otherwise change their behavior.
Event handling
In the servlet architecture, events are represented via HTTP methods. For
example, when a user submits a form, the doPost method is called. The portlet event model, however, closely mirrors the traditional
Java event model in that portlets implement appropriate interfaces and are notified by the Portal Server when these events are fired. For example, when a user clicks button, an action event is generated and sent to the registered listener. The Portlet API also provides WindowEvents and MessageEvents.
Security
Servlets execute in a neutral environment and are inherently responsible for validating the user�s authenticity and/or authority to make a specific request. This is traditionally a function of the controller role. A portlet, on the other hand, operates only in the context of the portal server and cannot be called directly.
The Portal Server is responsible for authentication and authorizing all user access. Therefore, portlets can be reasonably assured that authentication and authorization has been performed prior to their execution. They may however perform some authorization in order to tailor content to a specific user or role.
Where in servlets, authentication is a daily concern of developers, it is an option for portlet developers.
Regards,
Gaurav
