程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> J2EE >> Gavin King談JSR-299和Weld 1.0對Java EE與JBoss的影響

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

編輯:J2EE

        前不久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前端了。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved