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.
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.