在一般情况下，可以从JSP页面或另一个servlet调用操作servlet，作为表单提交或链接激活的结果。根据请求的类型，该servlet重新从操作库中检索相应的操作类型。由于典型的web应用程序要处理大量的请求，所以操作库中为每个操作类型保持一个操纵实例。对于给定的请求类型，这些操作是可重用的。对于多个请求，重用单个操作可以大幅减少框架实例化所需的操作数量。

要记住，多个线程可以并发地发出相同的请求，这意味着，这些线程可以并发访问单一的操作实例。所以，操作必须是线程安全的。实现线程安全操作的最简单方法就是避免保持固有状态，这可以通过使用局部变量而不是类成员来实现，因为局部变量一次仅可以由一个线程来访问。

Servlet身份验证的过程看上去很简单：1、用户试图访问受保护的资源，例如某个JSP页面。2、如果该用户通过身份验证，servlet容器就会使该资源可用；否则，就请求用户输入用户名和口令。3、如果用户名和口令没有通过身份验证，就会显示错误消息，让用户再次输入新的用户名和口令。上述步骤很简单，但比较含糊。我们不清楚到底是谁请求输入用户名和口令，谁执行的身份验证，如何执行身份验证，怎么请求用户输入用户名和口令。这些步骤没有详细的说明，是因为servlet规范将它们留给应用程序和servlet容器来完成。Servlet规范的这种含糊性对可移植性产生了影响。

Servlet顾虑起是在servlet2.3规范中引入的，它解决了servlet和JSP的最大缺陷：不能过滤servlet输出。该缺陷阻碍了很多能够从顾虑请求中获得好处的功能开发，如登录、身份验证和XSLT处理等。如果用户尚未登录，enforceLogin标记就会过滤出JSP页面的其余部分，并转到登录页面；否则，该标记就什么事情都不做。

使用定制标记作为过滤器不仅麻烦，而且易于出错，因为JSP开发人员要负责将过滤器（标记）应用于适当的内容。对这种类型的标记来说，servlet过滤器通常是更好的选择，因为servlet容器负责将过滤器应用于内容，开发人员只需在部署描述信息中指定过滤器映射。这些映射就会指定一个或多个servlet过滤器，即过滤器链，它们与servlet或URL模式关联。这些过滤器都有机会操纵请求，这样就可以将请求传递给链上的其他过滤器。