Introduction

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

Session State

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

Servlet Context

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 Guideline: Designing State for J2EE Applications for additional discussion of this mechanism.

Longer-Lived State

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 Guideline: Designing State for J2EE Applications

Granularity

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.

Transactions

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.