2.4 Servlets versus portlets

 <  Day Day Up  >  

Those coming from a servlet background will find many similarities when first working with portlets. This section will address some of the more important conceptual differences between servlets and portlets. When designing your portlet applications, the most important factor to initially consider is that unlike servlets, portlets are only a small piece of a large presentation.

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.

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.

 <  Day Day Up  >  


IBM WebSphere Portal V5 A Guide for Portlet Application Development
IBM Websphere Portal V5: A Guide for Portlet Application Development
ISBN: 0738498513
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net