Guideline: Identifying Servlets
This guideline discusses how to identify and model servlets for a J2EE application.
Relationships
Related Elements
Main Description

Introduction

This guideline focuses on identifying Servlets. Additional guidance on Servlets is provided in Guideline: Servlet

Identifying Servlets

Servlets are server classes that interact with web-based clients. They are primarily identified from control classes (see Guideline: Analysis Class) in web architectures. They may be used to generate web pages for presentation purposes, but in general this is better suited to JSPs (see Guideline: JavaServer Page (JSP)). They may also be used to interact with databases, as in a Web-centric deployment configuration, as described in Concept: J2EE Deployment Configurations. And since J2EE 1.4, servlets can also be used to implement web services as defined in the JAX-RPC specification.

However, for applications with significant business logic, or applications which require the features offered by EJBs, a multi-tier deployment configuration (see Concept: J2EE Deployment Configurations) is more appropriate. In this case, servlets are typically used to coordinate presentation logic and provide a bridge to the business logic and data provided by EJBs.

A typical use of a servlet is as a Front Controller. Front controllers provide a single entry point to an application, thus making security, application state, and presentation uniform and easier to maintain.   A front controller accepts a user request, processes the request and determines the appropriate presentation component to forward it to. See Core J2EE Design Patterns - Front Controller ([ALU01]) for details.

If your design contains a large number of JSPs with similar control code, consider introducing a servlet to consolidate this logic in one place.

Modeling Servlets

Servlets are represented in RUP by Artifact: Design Class, and so are modeled as classes. Servlets for handling HTTP requests are stereotyped as <<HTTPServlet>>. Servlets for handling other protocols are stereotyped as <<GenericServlet>>.

Every servlet may be thought of as providing the same interface, a single operation that services requests and provides standard client, session, and servlet context information. So, modeling a servlet is not concerned about defining interface operations, but rather defining its responsibilities and how it interacts with other design elements, such as clients, JSPs, helper classes, EJBs, and so on.

Web Services Endpoint

As we have seen previously, servlets can be used to implement web services and need to fill the following requirements:

  • It must have a default public constructor.
  • It must implement all the methods declared by the Service Endpoint Interface and its business methods must be public and not final or static.
  • It must be stateless.
  • The class must be public, but not final nor abstract.