什麼是Seam呢？JBoss Seam是「Java EE 5.0的一個輕量級的框架」.這是什麼意思？難道Java EE(Enterprise Edition) 5.0本身不是一套「框架嗎」？為什麼在官方規範之外,還需要另外一個框架？好吧,我們就將seam看作是本應該被包括在Java EE 5.0中的一個「遺漏的框架」吧.
它在Java EE 5.0框架的上層,為所有的在企業Web應用中的組件提供了一個統一的、易於理解的編程模型.它同樣使基於狀態的應用和業務流程驅動的應用的開發易如反掌.換句話說,Seam致力於開發者生產力和應用擴展性.
1. 整合和強化Java EE框架
Java EE5.0的核心框架是EJB(Enterprise JavaBeans)3.0和JSF(JavaServer Faces)1.2.EJB 3.0(以下簡稱EJB3)是基於一個POJO(Plain Old Java Objects)的業務服務和資料庫持久化的輕型框架.JSF是一個基於MVC(Model-View-Controller)的Web應用框架.大多數的Web應用都將包含有業務邏輯的EJB3組件和Web應用前端顯示的JSF組件.EJB3和JSF雖然互補,但是他們是根據各自的理念設計的獨立的框架.
例如,EJB3使用註解（annotation）來配置服務,而JSF使用的是XML文件.更進一步講,EJB3和JSF組件在框架層面上是互不敏感的.要整合EJB3和JSF,開發者必須手動地構造facade對象（如：JSF支持bean）,將業務組件與Web頁面和樣板代碼（又稱plumbing代碼）聯結起來,以便能跨框架調用方法.將這些技術粘合起來是Seam的職責之一.
Seam打破了EJB3和JSF之間的人工層,它為整合EJB3和JSF提供了一個一致的,基於註解的途徑.只需要個別簡單的註解,Seam中的EJB3業務組件就能直接被用來支持JSF Web表單或者處理Web UI事件.
Seam允許開發者將「同一種東西」——有註解的POJOs——應用與所有的應用組件.與其他Web框架開發的應用相比,Seam應用概念簡潔,同樣的功能卻需要較少的代碼（在JAVA和XML中）.如果沒有耐心,或者想要快速預覽,一個Seam到底有多簡單,你可以現看看本文描述的hello world一例.
在JSP來說困難的任務,Seam可以輕易的完成.例如,JSF頭疼的一個問題就是過分依賴HTTP POST.這是的將一個添加到書籤中的JSF網頁,通過HTTP GET訪問相當困難.但是有了Seam,生成一個REST網頁是非常容易的.Seam提供了一系列JSF組件標籤和註解,增加了「web友好」和JSF應用的網頁效率.
同時,Seam拓展了EJB3到POJO的組件模式, 從web層到業務層都有了狀態上下文.進一步說,Seam整合了一系列主要的其他開放源代碼框架,例如jBPM、JBoss Rules(又名Drools)、JBoss Portal、JBoss Microcontainer等等.Seam不僅能將它們「有機結合」起來,
可以像整合JSF和EJB3一樣強化原有的框架.
Seam位於Java EE 5.0底層,但它的應用並不局限與Java EE 5.0伺服器.一個Seam應用可以部署在J2EE 1.4應用伺服器和Tomcat伺服器上.這意味著現在能在Seam應用中得到產品化支持.
1 1 > 2
或許有這樣一種誤解,認為Seam僅僅是將各種不同框架串起來的另外一個集成框架.Seam提供了它自身管理的狀態上下文,允許框架通過註解和EL（表達式語言）表達式與其他框架進行深度整合.整合的程序來自於Seam開發者對第三方框架的認知.
2. 一個為ORM設計的Web框架
對象關係映射(ORM)解決方案在當今企業應用中廣為使用.但是,大多數當前的業務和web框架並不是為ORM設計的,它們並不在整個Web交互生命周期——從請求來臨到響應完成——管理持久上下文.這就導致了包括可怕的LazyInitializationException在內的各種ORM異常,帶來了如「數據傳輸對象（DTO）」等醜陋的伎倆（ugly hacks）.
Gavin King發明了Seam,同時他也發明了在世界上廣為使用的ORM解決方案Hibernate.為了繼承和發揚ORM的最佳實踐,Seam進行了重新設計.有了Seam,就不必再寫DTO,你所做的就是延遲載入.
擴展后的持久上下文就如同一個自然的高速緩存,可以減少和資料庫的交互,ORM的性能就會被極大地改進.
進一步講,Seam整合了ORM層、業務層和表示層,開發者就能夠在表示層直接展示ORM對象,也能把資料庫驗證註解用於輸入表單,以及重新定向ORM例外到定製的錯誤頁面.
3.專為有狀態Web應用而設計
Seam是專為有狀態Web應用而設計的.Web應用是天生的多用戶應用,電子商務應用天生也是有狀態的和有事務的.但是,大多數已有Web應用框架是面向無狀態應用的.開發者必須操作HTTP會話（session）對象來管理用戶狀態,與核心業務邏輯無關的代碼不僅會混亂你的應用,帶來了一系列的性能問題.
在Seam中,所有的基礎應用組件天生地有狀態.它們使用起來要比HTTP session容易,它們的狀態由Seam公開管理.沒有必要在Seam應用中編寫引起麻煩的狀態管理代碼——只需在其組件上註解其做用域、生命周期方法以及其他狀態屬性,Seam就會掌管其他[譯者註：指這些組件的生命周期].Seam狀態組件要比HTTP會話（session）能更好的管理用戶狀態.例如,你能有多個「會話」進行,每個「會話」由在一個HTTP會話（session）中一系列的Web請求和業務方法調用組成.
進一步說,在Seam中,資料庫緩存和事務能自動與應用的狀態相連.Seam在內存中自動保存資料庫更新,等到對話結束后提交到資料庫.內存中的緩存能大大減輕複雜狀態應用中資料庫的負載.
除了以上這些,Seam支持整合開源JBoss jBPM業務程序引擎,大大提升了Web應用中的狀態管理.你現在能為一個機構中不同工作人員（諸如客戶、經理、技術支持人員等等）的指定工作流程,利用工作流程來驅動應用,而不是依賴用戶界面事件處理和資料庫.
4. 支持Web 2.0
Seam為Web2.0應用進行了充分的優化.它給AJAX（非同步JavaScript和XML,增加網頁交互的一種技術）提供了多種支持——從內置「零Javascript」的AJAX組件到有AJAX支持的JSF組件,再到定製的JavaScript庫,Seam為瀏覽器端的Javascript對象提供了直接訪問Seam伺服器組件的途徑.Seam提供了一個先進的併發模型,有效的管理來自同一用戶的多個AJAX請求.
對於AJAX應用,不斷增長的資料庫負載是一個巨大的挑戰.與一個非AJAX應用相比,一個AJAX應用要向伺服器發送的更頻繁的請求.一但資料庫必須響應這些AJAX請求,那麼資料庫就不堪重荷.Seam中的狀態持久上下文正如一個內存中的緩存,它能在會話始末保存信息,最終幫助減少資料庫交互.
Web2.0應用往往為其數據使用複雜關係模型（例如,一個網路交際站點所做的就是處理和顯示「用戶」之間的關係）,對於這些站點,延遲載入對於ORM層至關重要.否則,一個簡單的查詢就能級聯地載入整個資料庫.正如我們前面所討論過的,Seam是現今唯一一個正確支持Web應用延時載入的Web框架.
5.依賴雙向映射的Pojo服務
Seam是一個「輕量級」框架,它使用POJO（plain old Java objects）作為服務組件.在應用中,POJO沒有使用介面或抽象類來"鉤住"組件.當然,問題是如何使POJO交互來組成這個應用？它們如何與容器服務（例如,資料庫持久化服務）交互？
Seam通過使用一個流行的、被稱作依賴注入(DI)的設計模式聯結所有POJO組件.在這個模式下,Seam框架管理著所有組件的生命周期.當一個組件需要使用另外一個時,它通過註解（annotation）向Seam聲明此依賴.Seam依據應用當前狀態得到這個依賴組件,並將它注入到所需求的組件中.
通過拓展依賴注入概念,一個Seam組件A不但可以構造另外一個組件B,把此組件B「拋還」給Seam以備其他組件（例如組件C）以後使用.
這類雙向依賴管理甚至都廣泛的應用於簡單的Seam web應用中（例如第二章的hello world一例）.在Seam術語中,我們稱這個為「依賴雙向映射」.
6.非常規的配置
[譯者註：指以隱式映射為主題,以顯式映射為例外的配置方式] 使Seam易用的主要設計原則是「非常規的配置」.其思想是為這些組件提供一系列默認行為,開發者只需要在預期行為非默認的時候,顯示地配置組件.例如, 當Seam將組件A作為屬性注入到組件B時,默認地,組件A剛會以組件B被注入的屬性的名稱命名.Seam里還有很類似的細節.總的結果是Seam中配置元數據要比其他Java框架簡單的多.因此,大多數的Seam應用能通過一系列簡單的Java註解進行充分配置.開發者從減化的複雜度中受益匪淺,
,與其他Java框架相比,用更少的代碼實現同樣的功能.
7.避免濫用XML
或許你已經注意到,Java註解在表述和處理Seam配置元數據時扮演著重要的角色.通過這樣的設計使框架更易於操作.
在J2EE發展早期,XML曾經被看作配置管理的「聖杯」.框架設計者將所有的配置信息,包括Java類和方法名稱都統統丟進XML文檔,而不考慮對開發者所帶來的後果.反省后,發現這是個嚴重的錯誤.XML配置文檔太過重複.開發者必須重複代碼中已有的信息,從而將配置和代碼聯結起來.
這些重複使應用易於出錯（例如,一個拼寫錯誤的類名可能在運行時顯示為一個難於調試錯誤）.缺少合理的默認配置進一步使這一問題複雜化.事實上,在一些框架中,相當數量的樣板代碼偽裝為XML,可能相當於或者超過實際應用中JAVA代碼的數量.對於J2EE開發者,XML的濫用通常被稱為「XML地獄」.
Java社區認識到了XML的濫用問題,並且已經非常成功地用Java代碼中的註解取代了XML.EJB3是Java官方標準化機構促進Java企業組件中註解使用的一項成果.EJB3完全可選擇的使用XML文檔,它向正確方向邁出了積極的一步.Seam加入了EJB3的註解,為整個web應用拓展了基於註解的編程模型.
當然,XML對於配置數據並非完全不利.Seam設計者認識到XML適用於指定頁面流程或者定義業務流程的web應用.XML文檔使開發者集中地管理整個web應用的工作流程成為可能,同時也反對將配置信息分散於java源文件中.工作流程很少能與源代碼耦合,因此XML文檔中並不需要重複鍵入已存在於代碼中的信息.
8.為測試而設計
Seam為了易於測試而重新設計.所有的Seam組件都是註解過的POJO,它們易於進行單元測試.開發者僅僅通過利用常規的Java new關鍵詞來構造實例,然後在測試框架（例如JUnit 或者TestNG）中運行任何方法.如果需要測試多個Seam組件的交互,開發者則逐個實例化這些組件,然後手動建立它們的相互關係（也就是顯示地使用setter 方法,而不是依靠Seam依賴注入功能）.
集成測試整個Seam應用比較複雜,開發者必須在Seam容器中運行應用.Seam用嵌入的輕量級容器來幫助該類測試.在測試框架中,開發者能按步驟地載入Seam容器,然後運行測試.
希望以上介紹的八方面,能夠幫助到你.
