什麼是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容器，然後運行測試。
希望以上介紹的八方面，能夠幫助到你。
