JSF的体系

xiaoxiao2021-03-01 26

HTTP 是一个简单的协议—它基于文本头。客户发送一个请求给服务器，服务器发送一个

响应给浏览器并附带所请求的文档。服务器是个哑巴—如果请求了另一个文档，它并不记

住客户的任何东西。这种失忆意味着HTTP 是一个“无状态”协议；它自己并不在请求之

间维护客户的信息。

HTTP 的无状态性意味着它能够很好的伸缩(毕竟它是一个Internet 协议，而Internet 则是

一个巨大的场所)。这种特性对于HTTP 原本要服务的静态文档并不是一个问题。

当时想象一下代客泊车的情况，并且没有给你收据也没有记住你的样子。当你返回的时候，

它一定会花很多时间来找到到底那一辆车是你的。这就是在无状态环境中开发这种应用的

问题。要解决这个问题有两种方式：cookies 和 URL 重写。这有点象泊车人给你一个收据，

它自己也留着一联。

不管你使用何种语言，如果你要编写一个web 应用，它都会使用HTTP。Servlet 和 JSP 的

开发使得在该协议之上构建应用更加容易。JavaServer Faces 的引入更使得开发人员能够彻

底忘记他们所使用的协议。

HTTP 对静态内容来说非常之好， web 本身都自带有这个功能。但是创建动态的内容需要

编写代码。即便HTTP 是很简单的，仍然要花许多工作来编写程序与之一同工作。你不得

不解析头部，理解它们的意义，然后以正确的格式创建新的头。这就是Java Servlet API 所

关心的东西：提供面向对象的视图来使开发Web 应用更加容易。HTTP 请求和响应被封

装为对象，你可以访问输入和输出流，以便能够读取用户请求和写入动态内容。请求由

servlet 处理—Servlet 是处理特定HTTP 请求的对象。

根据定义，一个标准的J2EE web 应用基于Servlet API。 Servlet 运行在一个容器中，容器

本质上是一个Java 应用，它执行所有幕后工作，比如与运行多个servlet 相关的工作，关

联组织为一个Web 应用的资源的工作，以及管理所有其他相关服务的工作。最流行的servlet

容器是Tomcat [ASF, Tomcat]，但是有些J2EE 应用服务器比如IBM WebSphere [IBM, WAS]

和 Sun Java System Application Server [Sun, JSAS] 也提供servlet 容器。

我们前一节说过， HTTP 的一个大问题是其无状态性。Web 应用解决这种问题的方法是

使用会话—它们使得用户好像总是在，即使他们实际上并不在。会话（Session）是Servlet API

提供的一个最大的优点。虽然幕后它还是使用cookies 或者 URL 重写，但对程序员已经屏

蔽了这种复杂性。

Servlet API 也提供其它很多好处，比如安全性，日志，生命周期事件，打包和部署，等等。

这些特征也形成了JavaServer Faces 的基础。事实上，JSF 本身就是实现为一个servlet，而

所有的JSF应用都是标准的J2EE web 应用。

JSF 比Servlet API 稍微更进了一步。Servlets 包含了构建Web 应用的基本的必要的基础架

构。但是这之后，你仍然不得不自己处理下层协议HTTP 的属性：请求和响应。JSF 应用

具有UI 组件，它们和backing bean 相关联，并产生应用逻辑所使用的事件。Faces 在其开

发中使用Servlet API，但是应用开发人员却可以在更高阶的抽象来获得这些优点：你可以开发你的web 应用而不用过多关心HTTP 或者Servlet API 自身的特定之处。

所有的 JSF 应用都构建于Servlet API 之上，使用HTTP 进行通信，并且使用JSP.之类

的显示技术。虽然JavaServer Faces 应用并不是一样需要JSP。它也可以使用象

XML/XSLT，其它模版引擎，或者普通Java 代码作为显示技术。然而，因为Faces 实

现提供了对JSP 的集成基础，所以本书的绝大部分例子都使用JSP。

Faces 的组件架构使用JavaBeans 来处理属性，并提供基本的工具支持，以及事件模型

和其他一些东西。JSF 被视为是一个web 应用框架是因为它它执行了许多通用的开发

任务，所以开发人员可以更加集中精力于更有趣的事情，比如业务逻辑之上。它的一个

关键的特征是支持Model 2 设计模式，这样可以执行表现和业务逻辑代码之间的分离。

但是，Faces 主要还是集中于UI 组件和事件。因此，它可以很好的和其它框架进行集

成，比如Struts，并且在高层次框架上和它们的功能一些重合之处

JavaBeans

相当一部分Java web 开发人员都以为JavaBean 就是一个简单类，具有一些可通过getter

和 setter 方法(访问器和修改器)来暴露的属性。例如，有一个Java 类，具有方法getName

和 setName，就表示暴露了一个可读写的属性name。然而，属性仅仅是其冰山一角，

JavaBean 是一个全能的组件架构，其设计本着工具支持。

这是很重要的，因为这意味着对它来说除属性之外还有很多东西。JavaBeans 遵循一定的

模式，以便其他Java 类能够动态发现事件和其它一些除属性之外的元数据。事实上，

JavaBeans 正是驱动Swing 的技术，并使得 IDE 能够提供GUI builders 来构建桌面应用和

applet。使用JavaBeans，你可以开发一个组件，不仅可以很精确地与可视化的GUI builder

一起工作，也可以提供一个特定的向导 (或者定制器) 以引领用户进行配置流程。JavaBeans

也包括一个强大的事件模型(和Swing 和 JSF 组件所使用的一样)，持久化服务，以及其它

一些优雅的特征。

理解 JavaBeans 的强大之处将有助你领会JSF 的全部魔力所在。象Swing 组件一样，每个

JSF 组件都是一个全功能的JavaBean。另外，Faces 组件设计来就是和backing bean— 实

现为JavaBean 并且也处理事件的对象，一起工作。

如果你只是计划编写应用代码或者构建UI，那么基本的JavaBeans 的知识 (修改器和访问

器) 已经足够。如果你想开发定制组件，对Java Bean 的更深了解将会使你的开发工作更加

容易。

定制标签（custom tags）”

页面结构的管理是另外一个问题。虽然JSP 提供了一个机制来创建动态页面，但它并没有

提供将一个页面组合为更小的，可重用的部件的可扩展性支持。更有意思的是，servlet 的

处理居然不支持国际化，类型转换和错误处理。

图 1.6 Web 应用基础架构可以视为一个服务栈。底层服务提供的基础支撑稍微有一点的抽

象，而栈的顶层的服务则提供更多抽象。将所有服务整合在一起将极端强大。

一个软件组件是一个具有特定的契约接口并且仅具有显式上下文（环境）依赖性的成

分单元。一个软件组件可以独立部署，并且服从第3 方的组成。[Szyperski].

厨房的“上下文依赖性（context dependencies）”就是指对诸如房间本身，配管，电路等等

因素的考虑。本质上，上下文是所有组件的容器。而容器则是拥有组件，并且提供一系列

允许进行组件操作的服务的系统。有时，这种操作在IDE (设计时)中进行，有时则在部署

环境中运行，比如J2EE server 之中 (运行时)。

短语“独立部署” 意味着一个组件是一个自包含的单元，可以被安装到一个容器中。厨房水

槽是一个独立的，自包含的组件，可以安装在工作台中。

当你改造你的厨房时，你雇用一个承包商，由他来将你所选择的组件 (橱柜，抽屉，水槽

等等) 组装成为一个完整的厨房。我们使用组件构建软件时，我们也是将各种组件组装起

来，创建能够运行的软件系统。