Tomcat中的Request & Response 设计结构

老版Tomcat使用catalina作为其连接器和容器的架构，当一个request请求到达时，Tomcat会对其做一系列的封装，并传递给容器进行处理，处理完之后，又会有一些解析工作来获取相应的response。

这里简单的介绍一下request在catalina中的体系结构。

我们都知道当我们进行web开发时，一个servlet只会接收类型为HttpServletRequest的对象，并返回类型为HttpServletResponse的结果。两个类中分别包含了许多web开发人员需要调用的方法，通常这些方法足够使用。

然后作为web container，Tomcat还需要在request中保存许多内部信息及使用方法，这些信息和方法不应该暴露给web开发人员，否则会造成不必要的麻烦。

那么，Tomcat中是如何实现只向开发人员提供有限接口，而内部提供更多接口的呢？

我们以Request为例子来看：

从这张图看，整个request的设计是相当复杂（这还不是全部，有些内容已经被省略掉），我们先看最基础的四个接口:

    ServletRequest: 这个接口来自javax包，是JSP Spec中定义必须要实现的。
    Request: Catalina内部的Request接口，为ServletRequest提供了许多补充方法，供 Catalina内部使用。
    HttpServletRequest: 来自javax包，是JSP Spec中定义作为Http的request必须要实现的。
    HttpRequest: Catalina内部的Request接口，为HttpServletRequest提供了许多补充方法，供Catalina内部使用。

整个设计中共用到了三种设计模式：

    Default Pattern缺省模式，实际上这本身并不能算是一种模式，最多只能是一种编程方法，对于接口的所有子类，提供一个默认实现，在这里就是RequestBase及HttpRequestBase所做的工作，HttpRquestBase向HttpRquestImpl提供了HttpRequest和HttpServletRequest的默认实现。这样以后添加新的继承就只需要实现几个方法。

    Adapter Pattern适配器模式，我们已经知道HttpRequestImpl中包含了HttpRequest和HttpServletRequest定义的所有方法的实现，然而对于Catalina组件，他们并不需要知道任何关于HttpServletRequest接口中定义的内容。因此，我们可以通过适配器模式将任何继承了HttpRequest和HttpServletRequest的类封装起来，并只提供HttpRequest提供的接口（可以看到HttpRequestWrapper继承HttpRequest）。

    Facade Pattern门面模式，门面模式将内部复杂的实现隐藏起来，并提供一个简单的接口给外部的用户使用。在这里，HttpRequestFacade类将只提供HttpServletRequest中定义的方法给web开发人员。

从某种角度上讲，适配器模式和门面模式有一定的类似，都是将已有接口进行封装，并提供新的接口，然而适配器着重于将一个接口转换成另一个接口，门面模式则着重于将复杂的内部实现隐藏起来，提供一个简单的通用接口。

然而在我们这个例子中，似乎并没有这些所谓的区别，两种实现方法几乎一致。

评论

2 楼 mabusyao 2011-05-24  

今天看到Tomcat的session management，似乎对于Adapter Pattern和Facade Pattern这两种模式，Tomcat中并没有明确的区分。

1 楼 mabusyao 2011-05-19  

昨天tech talk，听同事讲Bridge Pattern，略有感悟。觉得这里也用到了这样一个模式。

Request接口和HttpRequest接口直接的继承关系，以及ServletRequest和HttpServletRequest的继承关系，都是桥梁模式的一重体现。

但是具体应该在何时使用这个模式，还需要一番功夫学习。