Gavin King談JSR-299和Weld 1.0對Java EE與JBoss的影響

        前不久Red Hat的JBoss部門發布了Weld1.0.0——Java EE 6對JSR-299（Java EE的上下文與依賴注入，即Contexts and Dependency Injection for Java EE，後文簡稱為CDI）的參考實現。Sun GlassFish Application Server v3和即將發布的JBoss AS 5.2.0都使用了Weld實現，然而Weld並不需要完整的應用服務器。它可以運行在Servlet容器內如Jetty 6.1或是Tomcat 6，同時也能用於Java SE 5.0+。為了闡明後一點，Weld發布包中還帶有一個示例性的控制台應用及一個Swing應用示例。

        在JSR-299草案首次發布後，Google與SpringSource又聯合提交了JSR-330，旨在標准化“一個久經考驗、無可辯駁的注解集以使得注入類能夠跨越多個框架”，因此在我碰到CDI規范的領導者Gavin King時就迫不及待地詢問他JSR-330對CDI有何影響。

        CDI現在使用JSR-330所定義的注解來聲明注入點。這種影響是微乎其微的，因為330所使用的模型基本上與299大同小異。歸結起來，只是注解名有所區別罷了。

        要知道330並沒有定義完整的依賴注入方案。它只定義了帶有修飾符的注入點而已，其他的都沒有定義。

        InfoQ：CDI和EJB是如何處理EE 6所引入的Managed Bean模型的？

        新的Managed Bean規范是JSR-299的工作成果（在規范的早期草案中我們稱之為“簡單Web Bean”）。簡單Web Bean支持依賴注入、EL名字與攔截器，但卻沒有EJB那些編程約束。

        Managed Bean規范引起了很多爭議，Red Hat說我們確實需要支持普通Java類的注入，而其他EE涉眾則表示對299定義這樣一個新EE“組件”的行徑感到非常不爽。

        經過多次討論後，我們認為這種“簡單”組件的想法應該自成一個規范，以此構成所有其他EE組件編程模型的基礎，包括EJB等等。這是一個非常棒的願景，我們都很贊同這個觀點，但EE 6並沒有完全實現它。

        最後的結果是：CDI可以用在普通的Java類（現在叫做“Managed Bean”）以及EJB上。現在的EJB可以看作是一種特殊的Managed Bean，只不過有一些額外的編程約束和功能。這種編程模型能夠極大地降低新用戶學習EE的曲線。

        InfoQ：EJB還需要自己的組件模型麼？

        我認為EE平台的未來發展方向是逐漸將EJB特有的功能通用化，將其應用在所有的Managed Bean上。舉個例子，為何不是所有的Managed Bean都支持@TransactionAttribute和@RolesAllowed呢？簡直沒有道理嘛。

        然而EJB在為消息傳輸定義端點、遠程與異步方法調用、定時器等領域還是有一席之地的。在這些情況下，EJB生命周期模型還是非常有意義的。

        InfoQ：Seam為JSF 2和CDI創造了靈感。在JSF中修復這些問題要比在Seam中解決好在哪呢？

        在盡力透明化用戶體驗的過程中，我們從來都沒有真正滿意過。用戶總是注意到何時在使用JSF的特性，何時在使用本應放在JSF中的Seam特性。

        CDI來源於Red Hat的開源Seam框架，從廣義上來講，它將Seam的編程模型標准化為Java EE 6的編程模型。CDI實現了Java EE 6的3個主要目的。首先，它提供了聲明的方式來管理綁定到上下文組件的范圍、狀態與生命周期。其次，它為平台提供了標准化、注解驅動、類型安全的依賴注入框架，方式類似於Google Guice。最後，它為Java EE平台的擴展開發提供了Service Provider Interface（SPI）。

        CDI的Service Provider Interface已經成為Java EE可擴展性的一個關鍵組成部分，而可擴展性則是Java EE 6的一個中心議題。JSR-316規范說到：

        ...我們相信大家都很渴望將這些技術用於Java EE應用服務器之上，或是以插件的形式使用。通過增加更多的擴展點和服務供應商接口，其他技術就可以插件的形式用於平台實現了，這麼做既整潔又高效，對於開發者來說使用起來也是非常簡單的，就像是內置於平台上的設備一樣。

        這一點大家可以從下一版的Seam（也就是Seam 3）中看到，Seam 3將CDI作為其核心引擎並使用CDI Service Provider Interface提供了CDI中並沒有涵蓋的眾多特性，如BPM集成、Drools集成、PDF與Email模板支持以及Excel生成等等。這些擴展（也包括第三方廠商提供的其他擴展）可以運行在支持JSR-299的任何環境中，也包括任何Java EE 6環境。CDI規范說到：

        可移植的擴展可以通過如下方式與容器集成：

        • 提供自己的Bean、攔截器和裝飾器。

        • 通過依賴注入服務將依賴注入到自己的對象中。

        • 為客戶化的范圍（custom scope）提供一個上下文實現。

        • 通過外部注解增強或是提供基於注解的元數據。

        Gavin King說到：

        CDI和JSF 2的出現預示了Seam的新方向。

        在Seam 2中，我們花費了巨大的精力填補JSF的漏洞，結果造成了沒有時間集成那些非常吸引我們的表示層技術。JSF 2可以讓我們將精力放在其他領域中。

        最重要的是，CDI現在提供了一個核心“引擎”，可以在所有的EE 6應用服務器之間移植，甚至還可以用在Tomcat、Jetty和Resin上。該核心並不依賴於任何特定的表示層技術。其所擁有的僅僅是為可移植擴展開發者所提供的一套定義良好的SPI。該SPI作為整個生態系統的根基。如果你是一位框架開發者，那現在就會明確要想將框架與CDI及EE環境集成起來（通過擴展）需要做哪些事情。這也許是CDI最令人激動的特性了。

        Seam 3將成為一套CDI可移植擴展，可以用在任何應用服務器上並向CDI編程模型提供擴展，同時能與我們感興趣的其他技術進行集成。

        JBoss CTO Mark Little說CDI和Seam將是其所有項目和平台的未來發展方向：

        目前團隊正與這些項目和平台（如ESB和SOA-P）緊密合作以確保新版Seam能考慮到其特定的需求。重要的是，一些項目已經認為Seam是其正確的選擇，甚至都不用做任何修改，因此緊密與快速的集成要比想象的更容易一些。

        King也確認了這一點並說到：

        Red Hat已經成功將Seam應用到其所開發的一些項目當中了。CDI將Seam的核心功能放在了堅固的根基之上，而我們對CDI的實現Weld是個更加專注且測試良好的基礎設施。這意味著我們可以將Weld應用在Seam 2不適合的各種領域中，而這與構建Web站點無關。

        除了Red Hat外還有很多其他的CDI實現也即將破繭成蝶。Resin的創建者Caucho Technology擁有一個實現（CanDI），而Resin容器本身也在內部大量使用了CDI。apache也正致力於一個名為OpenWebBeans的實現，Granite DS也有一個實現，可以將CDI應用在Flex應用中，如下：

        我們認為JCDI非常適合於事件驅動架構的Flex RIA。JCDI應用非常整潔，盡管JBoss Seam提供了大量的特性，但他們沒必要再開發一個RIA前端了。