鐵手劍譜

對于RAD 工具的四個層次， JavaServer Faces 定義了其中3個：一個組件架構，一個標準的UI 部件集，以及一個應用架構。JSF的組件架構定義了通用的方式來建立UI 部件。此架構能驅動標準的JSF UI 組件(按鈕，超鏈接，復選框，文本框等等)，也為第3方組件留了空間。組件是面向事件的，所以JSF 允許你處理客戶產生的事件 (如，文本框中值的變化或者點擊了按鈕)。

因為對Web應用來說，不象其桌面應用堂兄弟，它必須總是要滿足多個客戶 (比如桌面瀏覽器，移動電話和PDA等), JSF 有一個強大的架構來以不同的方式顯示組件。它也有一個可擴展的機制來進行輸入校驗 (如字段長度) 以及在顯示字符串和對象之間進行轉換。

Faces 也能夠自動的保持你的UI 組件和收集用戶輸入值的Java 對象之間的同步，并且通過調用后臺Bean來對事件進行響應。另外，它有一個強大的導航系統并且全面支持多語言特征。這些特征構成了JSF的應用基礎架構—即對新應用系統必不可少的基本構建塊。

JavaServer Faces 定義了工具支持的基礎，但是其實現留給了工具廠商，這是Java的習慣。你可以自行選擇業界領導提供的工具，它們都可以是你能夠像使用其他RAD 開發工具如Visual Stu­dio. NET一般可視化的布局和設計你的Web UI。 (如圖1.1, 1.2, 和 1.3 分別展示了在IBM, Oracle, 和 Sun的IDE開發工具中開發JSF是什么樣子) 。或者，如果你愿意在沒有設計工具下開發Faces 應用。

在這些贊美之詞之后，我們應該指出JavaServer Faces 和桌面UI 框架如Swing 或者SWT之間的關鍵不同之處： JSF 是運行在服務器之上。因此， Faces 應用將運行在一個標準的Java web 容器之中，如Apache Tomcat [ASF, Tomcat]，Oracle Application Server [Oracle, AS]，或者IBM WebSphere Application Server [IBM, WAS]，然后向客戶顯示HTML 或者其他標記語言。

如果你點擊一個Swing 應用中的按鈕，它將產生一個事件，而你可以直接在駐留在桌面中的代碼來處理該事件。相反， web 瀏覽器并不知道JSF組件和其事件的任何東西；它僅僅知道顯示HTML而已。所以當你點擊一個Faces 應用按鈕，它將產生一個請求，有瀏覽器發送到服務器。Faces 負責將該請求轉換成一個可以被服務器中的應用邏輯所處理的事件。它也負責保證你在服務器所定義的每一個UI 部件都正確顯示給瀏覽器。

圖1.4 顯示了一個Faces 應用的高階視圖。你可以看到，應用運行在服務器上可以和其他子系統集成，如EJB服務或者數據庫服務。當然， JSF還提供許多其他服務可以幫助你你更小的代價構建強大的Web應用。

JavaServer Faces 有一個特定的目標：使web 開發更快更容易。它允許開發人員以組件，事件，后臺Bean以及它們之間的交互來進行思考，而不是請求，響應和標記。換句話說，它掩蓋了Web開發的大量的復雜性，是開發人員能夠集中于如何使他們的應用做的最好。

工業支持

對JCP社區和Sun 擴展Java的方式來說，最好的事情莫過于有大量的公司，組織和個人投身其中。通過JCP 產生一種規范實際上算不上快速，但結果卻是非常好的。JavaServer Faces 在2001年5月通過Java 規范請求(JSR) 127 引入；規范的最終版本，JSF 1.0，在2004年3月3日才發布。而JSF 1.1 (維護發布版) 則是2004年5月27日發布的。參與開發Faces的公司和組織 (除Sun之外)包括Apache軟件基金， BEA 系統， Borland 軟件，IBM，Oracle，Macromedia，等等。

這些公司開發的產品可分為3類(某些可能適合不止一類)：J2EE 容器，開發工具，和UI 框架。因為JavaServer Faces是一個與工具一起工作和運行于J2EE 容器中的UI框架，這樣做則非常之好。最重要的是這些公司中包括許多業界巨頭。這意味著你可以期望JSF 具有大量的工業支持。并且，如果你的供應商不支持JSF，你也可以免費下載Sun的參考實現 [Sun, JSF RI]。

要跟蹤最新的JSF 新聞，文章，產品和供應商，請訪問JSF Central [JSF Central]，本書作者所運作的一個社區站點。

JSF，Struts，和其他框架

我們面對這一情況：有大量的Java web 框架可用。它們中某些，如Struts [ASF, Struts] 和 WebWork [OpenSymphony, WebWork]，有助于表單處理和其他問題，比如遵循Model 2，集成數據源，以及通過XML配置文件中心化控制引用的所有應用資源。這些基本框架提供了廣泛的基礎設施，但是還沒有屏蔽基本的HTTP請求響應處理。

其他框架，象Tapestry [ASF, Tapestry]，Oracle的應用開發框架 (ADF) UIX [Oracle, ADF UIX]，以及SOFIA [Salmon, SOFIA]，都提供一個UI 組件模型和某些事件處理機制。這些UI 框架，包括JSF，目的是簡化整體變成模型。經常，基礎架構和UI 框架具有重疊的功能。

為了理解這種重疊，你可以想象web 應用架構師一個服務棧。靠近棧底部的服務沒能抽象基礎協議的許多細節；它們更像粗加工品。棧中靠近頂部的服務則隱藏了更多討厭的細節，提供更高級別的抽象。最低層的服務由web servers，Servlet API，和JSP處理。大部分框架都提供一些附加服務的子集。圖1.6顯示了這個棧，以及與JSF，Struts，servlets，JSP，和典型的web server的關系。

你可以從圖中看到JSF 支持足夠多的服務，這也使得它自己成為強大的框架。在大多數情況下，這就是你需要的東西。后續發布的Faces極有可能也會包括傳統的服務。

然而，即使Faces 與Struts這樣的框架有些重疊，也并不是必須替代它們。 (事實上，如Struts的領導, Craig McClanahan, 是JavaServer Faces的開發指導) 如果你將他們集成起來，你就可以訪問棧中的所有服務(第 14 章將包含Struts 集成)。你也可以和其他框架一起使用JSF，比如Spring [Spring-Faces]。

對于面向UI的框架，JSF 和他們很多功能都有重疊。這些項目的某些申明將在其未來版本中支持JSF。Faces 的獨特之處在于有通過JCP的工業巨頭參與的開發聯盟，以及將成為J2EE的一部分。作為結果，它將分享受強有力的工具支持，并將隨很多J2EE server一起交付。

組件無處不在

令人悲哀的是，“組件”一詞的過度使用在今天已經到處蔓延了。操作系統是一個組件，應用程序是一個組件，EJBs 是組件，庫是組件，甚至廚房的水槽也是。有大量的書論及組件，有好的書指出組件有好多定義存在。

如果你知道他的確實意義，對這個詞的濫用，你就不會感到陌生。如果你在詞典中查找“組件（component）”這個詞，你就會看到他有一個同義詞供選—整體的一個部分。因此，如果你使用這個詞的字面意思，在一個分布式應用歡迎用，操作系統確實是一個組件。

更有趣的是，從概念上講，廚房水槽對操作系統相比對Faces組件來說更有共通之處。你不用自己從頭制造它—你只需要購買一個符合你需要的水槽：尺寸，顏色，材料，容器數，等等。對其他廚房用品也是如此，比如櫥柜和工作臺面。所有這些組件都有特定的接口可以使他們能夠和其他東西進行集成，但是依賴于特定的環境服務。(例如，接口管)。最終結果可能是獨特的，但整體是由獨立可重用的部件組成。

如果我們采用廚房組件的概念，并應用到軟件商，我們會得出這個定義：

廚房的“環境依賴性”就是諸如房間本身，配管，電路等等的因素。本質上，環境是所有組件的容器。一個容器是擁有組件，并且提供一系列允許進行組件操作的服務的系統。有時，這種操作在IDE (設計時)中進行，有時則在部署環境中運行，比如J2EE server之中 (運行時)。

短語“獨立部署” 意味著一個組件是一個自包含的單元，可以被安裝到一個容器中。廚房水槽是一個獨立的，自包含的組件，可以安裝在工作臺中。

當你改造你的廚房時，你雇用一個承包商，由他來組裝你所選擇的組件 (櫥柜，抽屜，水槽等等) 成為一個完整的廚房。我們使用組件構建軟件時，我們也是將各種組件組裝起來，創建能夠運行的軟件系統。

JSF 組件， Swing 組件， servlet, EJB, JavaBean, ActiveX 控件，以及Delphi 可視組件庫 (VCL) 組件都符合這個定義。但這些組件卻集中于不同的事情。JSF 和Swing 組件單獨針對UI 開發，而ActiveX 和 VCL 控件可以也可以不影響UI。Servlets 和 EJBs 則更粗糙一些— 他們在應用和業務邏輯領域提供大量的功能。

因為JSF 著眼于UI 組件，我們來相應窄化我們的組件定義。