Java EE 6體繫結構的變革

【IT168 分析評論】又看到 Reza 同學為 Java EE 6 奔走呼告了。如同在浩浩蕩蕩的就業大軍中的一員，
Reza 帶著自己的最新“簡曆”—— Java EE 6
，向咱們開發人員展示耳目一新的感覺。但從本文的字裡行間中，隱隱約約還是能覺察到它的困惑和迷茫：“已經付出了這麼多， Java EE 6
能再次成功嗎?開發人員會採納它嗎?如果不是，我們還應該做什麼?......”。當年 EJB2.* 的垮台掀起了反對使用 EJB
的浪潮。實際上我接觸 JavaEE 比較晚 ( 大概在 2007 年初 ) ，沒有使用過 EJB2.* ，但也是不夠客觀的照著大家說的抨擊
EJB ，天天嘴邊掛著 Struts ， Spring ， Hibernate 。但隨著對 JavaEE
的不斷關注與瞭解，漸漸發現自己的盲從於無知。此次 Java EE 6
的特性預覽更有讓我渴望學習它的衝動。“技術選型的抉擇政治因素往往大於技術本身 。” Java EE 6
的推廣還應該要更多的成功實戰項目來贏得“政治因素”。但如同剛畢業的應屆生，沒有經驗也要面對就業，除實力本身外，靠的就是運氣了......

　　簡單回顧

　
　Java EE 5 是一個相當成熟，布署廣泛並且支援服務端友好開發的平台。 EJB 3.0 的引用已經顛覆了原有的業務組件開發模型，而原有
EJB2.x 的 Entiy Bean 模型由持久層的 JPA 來代替。 JSF 也被作為官方的標準展示層架構，當然還有咱們的 JAX-WS
2.0 代替了 JAX-RPC 作為新的 SOAP web services API 。 Java EE 5 的目標非常明確——通過引入
Annotation ， POJO 編程模型，零配置 (zero-configuration)
等一系列概念從而降低開發的複雜度，協助開發人員從 XML 地獄中解脫出來。儘管對 Java EE
持觀望態度的還是大有人在，但是也許要證明“實際上 Java EE 5
已經獲得成功”的最有利的證據就是由於上述提到的種種改變，使得很多傢伙第一次開口說他們已經考慮接受 Java EE 。還是這幫傢伙，在體驗
Java EE 編程模型後，不斷的向我們反饋他們的震驚。

　　大局觀

　　Java EE 6 又將是邁向理想中那簡潔，高效以及整合完好平台之旅的一大步。 Java EE 6 又有了一系列技術上的革新：有全新的 WebBeans1.0 和 JAX-RS 1.1 API ，也有更加成熟的老牌 API Servlet3.0 。

　　除少數相對較小的改變外 ( 比如說標準的全域 JDNI 命名，本文將不會談到 ) ，大多數 JSR 316 中的主題都是精挑細選出來的。現在咱們就一同來看看這些變化。想瞭解更多細節，我推薦你把公眾審議草案下載下來看看。這是連結地址： http://jcp.org/en/jsr/detail?id=316 .

　　砍掉沒用的 API

　
　Java EE 的第一版發佈於 1999 年。在競爭異常激烈的業界一直作為官方標準，那時間也不算很短了。但在這段時期裡， Java EE
只是一味的在成長，結果導致到現在平台變得臃腫不堪，充斥著一堆毫無用處的過時 API ，用起來不爽，布署起來也不方便。 Java EE 6
開始正兒八經的處理這些 API ，確保平台更加輕量級，同時也是為了騰出更多的空間，更利於 Java EE 的健康成長。表 1
顯示了那些被砍掉的 API ，當然原因我們也做出了說明：

被砍的 API	被砍原因
JAX-RPC	JAX-RPC 是早期通過 RPC 調用和 SOAP web services 進行互動的編程模型。由於 Web services 成熟後從 RPC 模型中分離出來，更加健壯，更多特性和流行 JAX-WS API 實際上已經代替了 JAX-RPC 。
EJB 2.x Entity Beans CMP	複雜，笨重，過度複雜的 EJB2.* 的 Entity Bean 模型已經被 Java EE 5 的基於 POJO 的流行輕量級 JPA 持久層模型所代替。
JAXR	JAXR 是 Java API 中少數幾個用於 UDDI 註冊服務的介面之一。遺憾的是，由於 UDDI 並沒有廣泛使用，現在 JAXR 已經幾乎沒有啥應用，而且供應商支援的也很少，難免遭到被砍命運。
Java EE Application Deployment (JSR-88)	JSR 88 是當初是用於 J2EE 應用程式在應用伺服器上進行的配置和部署的標準 API 。可是該 API 始終沒有得到眾供應商的支援，不得不砍掉。
Java EE Management (JSR-77)	和 JSR 88 有著相似的命運， JSR77 原本是用於為應用伺服器建立監控管理的 API 。可是各大供應商熱情仍然並不高漲，難逃被砍命運。

表 1 ： Java EE 6 被砍的 API

　　上述精簡 API 的原則上是，應用伺服器供應商不需要強制的去支援這些技術，但是不排除一些大型的供應商仍就會對這些被砍 API 繼續維持一段時期。

　　對於此次調整你有什麼看法?太過於激進了?還是仍然過於保守?你還用上述表格中看得到的 API 嗎?還有其它你認為也應該被砍掉的 API 嗎?

 

對於 Java EE 主要抨擊之一就是它太龐大了。確實啊，大多數中小型的 Java web 應用程式根本用不了所有 Java EE 技術
(full Java EE stack) 。你可以想像一下，如果要構建一個類似於 SOA 的應用程式，會用到訊息，事務，持久化以及 Web
Services ，但犯不著需要使用像 JSP 或 JSF 這類的展示層技術。

　　Profile 就是為解決這個問題而設計的。
Profiles 其實就是一個 Java EE API 的子集，對於特定的應用程式有著各自的解決方案。比如說，被提議到的 Java EE
Web Profile 僅僅只包含了一些最有可能大絕大多數 Java web 應用程式中使用的 API 。像 Profiles
這樣的理念已經在標準化的世界上取得的成功也是由來已久。也許你早就知道， Java ME 其實就支援 Profiles
——支援每種特定的裝置運行環境。類似的， Profiles 可用來更好的組織日益複雜的 web services 世界 ( 比如說 WS-I
Basic Security Profile 等等 ) 。

　　雖然 Java EE 6 通過 JSR 來定義了一些規則用於建立新的 Profiles ，但這一次僅僅只有一個 Profile 當選—— Web Profile 。表 2 列出了 Web Profile 與 Java EE 完整平台的比較情況：

API	Web Profile	Full Profile
Servlet 3.0
JSP 2.2
JSTL 1.2
EL 1.2
JSF 2.0		支援
WebBeans 1.0 (?)	支援	支援
EJB 3.1 (Lite)	支援	支援
EJB 3.1 (Full)		支援
JPA 2.0	支援	支援
JTA 1.1	支援	支援
JMS 1.1		支援
JavaMail 1.4		支援
JAX-WS 2.2		支援
JAX-RS 1.1		支援
JAXB 2.2		支援
JACC 1.0		支援
JCA 1.6		支援

表 2 ： Java EE 6 的 Web Profile

　
　WebBeans 為什麼也能入圍的原因曾經也是一個大大的問號，至今大家對是否應該在 Java EE 6 中加入 WebBeans
仍然各執一詞。圍繞 WebBeans 的爭論焦點是：它怎麼適合加入 Java EE 體系?還有是不是 JSR
所研究的技術就一定是對的呢?對於你是否也是這麼想的呢?也許你並不瞭解 WebBeans ，下面我會對此話題進行延伸。是否 WebBeans
應該納入到 Java EE 6 中呢?如果不這麼做，那 JSR 應該做出什麼樣的改變?同時還應留心一下 EJB Lite ，它是雖不是完整版的
EJB ，但此次也被加入到 Web Profile 中了。下面我也會簡要的再提到 EJB Lite 。

　　對於 Java EE 的 Profiles 思想，你又有何看法?符合 Profile 的輕量級的應用程式伺服器是
否對你有用?關於 Web Profile 所涉及到的技術你又怎麼看?是內容太少了，太多了，還是剛剛好?光有它就足夠了，還是需要在 Java
EE 6 中定義其它 Profile ?還是咱們應當考慮一下更簡化的“ Java EE Basic Profile ”?

 

現在我們來來看看 JSR316 專家組所做的工作，看看哪些技術加入到了 Java EE
平台上了。雖然這項工作非常重要並且我們也渴望聽到你對上文提到的內容提出建議。從這一章節開始，我們來快速看看 Java EE 6 API
的改變。我是極力推薦你自己去深度發掘下列所提到的每一項 API 。我認為你會喜歡接來的內容，所有的 API 都會因你時宜的反饋而更加精彩。

　　WebBeans 1.0

　
　在 Java EE 6 的裡程碑上， WebBeans 也許算得上是最具開創性的 API 了。 WebBeans 填補了 Java EE
的很多空白。儘管 WebBeans 由 Seam ， Google Guice 以及 Spring 所進化而來，但它並不是直接的複製。實際上，
WebBeans 本身就擁有許多獨一無二的創新。 WebBeans 由 JBoss/Red Hat 的 Gaving King 和
Google 的 Bob Lee 領導著。下面就對 WebBeans 的特點進行簡要概括說明：

　　WebBeans 將 JSF
， JPA 和 EJB3 等編程模型統一了起來，讓人感覺它們是一個整合完好的開發平台。這一切是通過將 EJB3 的 beans ， JPA 的
entity 以及普通 Java Bean 註冊為 WebBeans 的組件，然後通過使用 EL
運算式進行訪問。當然，它們之間也可以在進行“依賴注入”。實際上，如果你需要的話， WebBeans 完全可以讓你忽略 JSF 的
backing beans 。

　　通常在上下文中， WebBeans 隱式的管理著所有註冊組件的生命週期。除傳統的
request, session 和 application 等主要範圍外，它還添加了一些新範圍“ dependent ”和“
conversation ”。 dependent 顯式的“繼承”了調用者的範圍，而 conversation 則是一個全新的範圍，(
conversation 上下文與一個瀏覽器視窗(或頁卡)聯絡在一起，這個瀏覽器視窗(或頁卡)由隨每個請求提交的一個標誌來標識。
conversation 範圍使用 HTTP Session 的一個單獨的區段在頁面之間遷移資料 。 )從 EJB3.1
來看，它又填補了用戶端組件範圍 ( 包括 stateless ， stateful 和 shared) 與 Web 應用程式中心端的空白。

　　WebBeans 為大家引入一組成熟的依賴注入特性，提供了一個完整的以 Java 為中心的型別安全開發平台。這些特性包括：對任意非 EJB 的 Java 對象的整合，將非託管的對象注入到託管對象中去，使用對象工廠，指定組件化的布署環境並利用 stereotypes 去管理 annotations 。

　
　WebBeans 可以通過 Annotation 將攔截器 (interceptor) 綁定到目標對象上，增強了 Java EE
的攔截器模型。通過 Annotation 所綁定的攔截器會自動的作用於目標對象，這一點與現在的 Java EE 5 是不同的( Java EE
5 中目標對象與攔截器之間還是通過間接方式進行關聯，比如說 xml 設定檔)。

列出的這些令人印象深刻的特性還只是 WebBeans 的冰山一角。 WebBeans 增加了許多其它非常棒的特性來制定下一代 Java EE 的整合方案。想更近一步瞭解 WebBeans 嗎，請點擊下面連結去下載已經 公開草案吧： http://jcp.org/en/jsr/detail?id=299 .

      原文地址：http://www.javaeye.com/news/5547-translation-java-ee-6-architecture-changes