Jetty体系结构概述

Jetty 是一个开源的servlet容器，它为基于Java的web内容，例如JSP和servlet提供运行环境。Jetty是使用Java语言编写的，它的 API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的Java应用提供网络和web连接。由于网上关于Jetty的中文资料比较少，本文将其官方文档翻译成中文供初学者学习。英文原文可以参考：http://wiki.eclipse.org/Jetty/Reference/Jetty_Architecture

鸟瞰Jetty

Jetty最上层的体系结构 

Jetty Server是处于一组Connectors(接收Http连接)及一组Handler（从连接进行请求并产生响应）并采用线程池进行工作的一个工具。

Jetty请求/响应接口继承自Servlet API，如果相应的Handlers被配置上的话，应该能够支持Servlet API的所具备的所有特征。例如，请求中的会话API是不可用的除非请求经过SessionHandler的处理，且Servlet本身的一些理念也通过ServletHandler实现了。如果Servlet本身是不必要的，就不需要使用Servlet的请求/响应API了。因此，你可以完全采用Connector及Handlers来构建一个Jetty服务器，而不用借助于Servlets.

配置Jetty的任务就是要构建一系列的connectors和handlers及提供个人的一些配置。由于Jetty的组件都是一些POJOs,你可以通过以下几种技术方式来组装和配置这些组件：

l  通过代码的方式，可以参考Jetty 7 Latest Source XRef

l  采用Jetty XML方式

l  使用自己的依赖注入方式如Spring 或XBean.

l  使用Jetty本身的WebApp and Context Deployers.

设计模式

Jetty本身的实现采用了很多通用标准的设计模式，许多抽象的概念如Connectors、Handlers及Buffers均采用接口的方式来实现，对接口一般化的处理则采用了抽象类的方式进行实现如AbstractConnector, AbstractHandler and AbstractBuffer.

JSR77草案中提倡使用的生命周期管理也在Jetty组件中以LifeCycle接口及AbastraceLifeCycle方式来体现，并作为了其基础组件。

Jetty提供基于字符串、字节数组及NIO缓冲方式的自身IO缓存。可以提供更好的可扩展性、简化NIO层的复杂性及支持更高级的特性。

Connectors

 

Connectors表示一个协议链，用来接受连接，解析请求并产生响应。基于不同的协议、调度模型及IO形成不同类型的Connectors，最常用的有以下几种：

l  SocketConnector：用于忙链接请求不多或者没有NIO的方式

l  BlockingChannelConnector：用于有NIO的方式且忙链接请求较多的方式

l  SelectChannelConnector：用于空闲链接较多或者异步处理 AJAX请求

l  SslSocketConnector：没有NIO的SSL方式

l  SslSelectChannelConnector：非阻塞的NIO支持的SSL方式

l  AJPConnector：对apache mod_jk及mod_proxy_ajp的AJP协议的支持

Handlers

Handler是用于处理接收请求的组件，handler的核心API是handle方法：

public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response)

throws IOException, ServletException

各个参数的含义：

l  target–请求的目标，为URI或者是一个名称；

l  baseRequest–原始的未经包装的请求对象；

l  request–请求对象或者被包装过的请求。如果有需要可以通过HttpConnection.getCurrentConnection()方法来访问该对象；

l  response–响应对象或者是被包装过的请求，如果有需要可以通过HttpConnection.getCurrentConnection()方法来访问该对象；

实现了该方法可以处理请求，将请求传递至另外一个handler(或servlet)或者修改、重新包装该请求并进行传递。在此主要介绍三种类型的handlers:

l  协调整合型Handlers－这种类型的Handlers能够将请求路由至另外一个Handlers(如HandlerCollection，ContextHandlerCollection)

l  过滤型Handlers－这种类型的Handlers用于强化或处理请求，并传至另一个Handlers（如HandlerWrapper,ContextHandler,SessionHandler）

l  生成型Handlers－这种类型的Handlers用于产生所需的内容（如ResourceHandler和ServletHandler）

内嵌的Handlers及序列性的Handlers

你可以组装不同的Handlers用于处理不同的请求，如嵌套型、顺序型或者二者的结合。

l  序列型Handlers执行时，不必依赖于下一次的调用，而且不必依赖于handlers的顺序。它在处理请求并产生响应时不需与其它Handlers的交互，这种的主要类是HandlersCollection.

l  内嵌型Handlers也被称为before/invokeNext/after模式，它的主要代表类是Handler Wrapper.内嵌型Handlers要比序列型的更具通用性。

请参考Writing a Jetty Handler如何写一个具体的Handler。

Servlets

ServletHandler是一个处理器，用于将请求传递至配置好的Filters，再通过URI映射好的Servlet而产生具体内容。

ServletHandler一般是被部署在servletContext中，因为它可以提供便捷的将URIs与Servlets进行映射的方法。

Filters和Servlets也可以使用请求转发器将请求路由至另外一个Context或当前Context中的其它的Servlet。

Context

Contexts是将一组特定URI路径或虚拟主机下的Handlers组织在一起的处理器，一个典型的Context包括以下几个方面：

1、一个上下文路径用于定义该请求能够被context处理；（如/myapp）

2、对于静态资源访问的基本路径（如docroot）

3、用于获取需要装载基本类的地址（如docroot/WEB-INF/classes）

4、虚拟主机名

Contexts有以下几种实现：

l  ContextHandler

l  ServletHandler

l  WebApplication Context

Web应用的上下文是集安全、会话及Servlets于一身的处理器，可以通过web.xml进行配置。

Web Applications

WebAppContext继承自servletContext，可以支持标准的Web应用的框架，而且可以通过web应用的WEB-INF中的web.xml进行会话、安全、监听器、过滤器、Servlets或JSP配置。

本质上WebAppContext就是一个方便性的类，采用构造、配置其它Handler的方式来完成一个Web应用的标准配置。

配置可以采用插件式的Configuration类或者WebXmlConfiguration来完成。