Topics

Introduction To top of page

This guideline focuses on designing of servlets. Additional guidance on servlets, such as how to identify and model them, is provided by Guidelines: Servlets.

Session State To top of page

Session state data managed by a servlet should be documented in the design of the servlet. See Guidelines: Designing State for J2EE Applications for additional guidance on session state.

Servlet ContextTo top of page

Any interactions with the servlet context should be documented in the design of the servlet. Servlet context is data global to the application, and should be managed carefully. See Guidelines: Designing State for J2EE Applications for additional discussion of this mechanism.

Longer-Lived State To top of page

A servlet may also manage data intended to outlive a single client session. For example, it may directly access a database via JDBC, or it may store data in cookies on the client side.

If a servlet manages such longer-lived data, this should be stated in the description of the servlet in the Design Model. The design of longer-lived state is also discussed in Guidelines: Designing State for J2EE Applications.

GranularityTo top of page

Servlets can invoke other servlets, JSPs, helper classes, and EJBs. If a servlet is becoming too large, consider the following options:

  • introducing helper classes that can be separately unit tested.
  • moving all HTML code into JSPs
  • pushing any business logic into EJBs.

TransactionsTo top of page

Generally servlets deal with non-persistent session state, and so do not require transactions. If transactions are to be used, then guidance for when to use them should be specified in the project-specific design guidelines.



Rational Unified Process   2003.06.15