領先一步
VMware 提供培訓和認證,以加速您的進程。
了解更多今天發布了 Java EE 6 提案 (JSR 316)。我相信這將是該平台自近 10 年前發布以來最重要的修訂版本,並且應該受到該技術用戶的歡迎。Interface21 很樂意支持此 JSR,並且我期待為其做出貢獻。
Java EE(在其歷史的大部分時間裡被稱為 J2EE)在為 Java 中介軟體創造市場方面發揮了寶貴的作用。但是,在這 10 年中,該平台出現了一些重要的問題,例如
Java EE 6 是該平台的重要修訂版,它有潛力解決所有這些問題。
它也可能具有解決另一個問題的潛力:如果 EE 供應商需要針對其大多數客戶永遠不會使用的大量功能進行認證,這意味著他們很難跟上規範,很難進行穩定的升級,而且重要的是,Java EE 市場中出現新進入者的可能性為零。最後一點令人擔憂,因為 EE 伺服器成為現任者的舒適特許經營權並不符合使用者的利益。為了驗證進行新的平台發布的難度:據我所知,在這一點上,BEA 是市場領導者中唯一獲得 Java EE 認證的公司,儘管 Java EE 5 規範已經最終確定了幾個月。而且,Java EE 5 中最有價值的新部分(例如 JPA)早在最終發布的幾個月前就已在 WebLogic 中準備就緒,由於圍繞一些大多數 WebLogic 使用者可能永遠不會接觸的技術解決了問題,因此無法在 GA 產品中發布。
我的解釋就到此為止:讓我們直接轉到提案並聽取來自來源的資訊
在過去的 8 年中,Java EE 平台不斷發展和成熟,現在能夠滿足廣泛的企業和 Web 應用程式開發需求。此外,Java EE 平台還促進了一個充滿活力的社群和市場,用於與該平台一起使用的其他技術、框架和應用程式。其中一些提供了平台中缺少的功能。其他則提供了平台功能的替代方案。此版本的一個主要主題是將這些技術作為整個 Java EE 環境的一部分來擁抱和支持,同時繼續簡化平台以更好地針對更廣泛的開發人員。為此,我們為此版本提出了兩個目標 - 可擴展性 和 設定檔。
幾年前,這將是異端邪說。我當時是個異端分子,但我從未 想 成為異端分子。Java EE 最終考慮到了更大的圖景,而不是想像它會為所有使用者需求提供一個好的解決方案。透過 Java EE 6,EE 平台部分地被重新解釋為支撐一系列解決方案的中心協議:讓百花齊放的肥沃土壤。看到這種更大的圖景思維在 Sun 內部成長令人鼓舞:考慮他們對 JRuby 的擁抱,並認識到,與 EE 平台一樣,JVM 是一個生態系統的基礎,而不是與單一語言相關聯。
Java EE 平台如果無限制地成長以包含 Web 和企業應用程式開發人員所需的所有有趣且有用的技術,那將是不適當的。相反,我們認為使更多這些技術能夠乾淨地分層或插入到 Java EE 應用程式伺服器中是可取的。透過增加更多的可擴展性點和更多的服務提供者介面,這些其他技術可以乾淨有效地插入到平台實現中,並且 對於開發人員來說,使用起來就像平台中內建的功能一樣容易。再次,很棒的東西。平台隨附的技術比這些「有趣且有用的技術」與伺服器基礎架構「更好地整合」的謬論長期以來一直被伺服器供應商用來迷惑使用者並阻止創新。(幸運的是,幾乎所有供應商都早已停止這樣做:例如,考慮 IBM 在 WebSphere 上 Spring 認證 中扮演的角色)。
這裡的關鍵是創新。一些技術自然以不同的速度發展:值得注意的是,一方面,伺服器基礎架構和線路協定(它們變化相當緩慢並且受益於標準化);另一方面,位於其頂部的「有趣且有用」的技術,需要以 遠 更快的速度變化,並且標準化在這方面基本上已經失敗。
Java EE 平台的範圍變得如此廣泛,以至於它失去了一些原有的重點。為了將 Java EE 平台重新聚焦於特定類別的開發人員和應用程式,我們建議引入 Java EE 平台設定檔。設定檔將引用由 JCP 流程定義的 Java EE 平台,並且可以包括 Java EE 平台技術的子集、不屬於基本 Java EE 平台的其他 JCP 技術,或兩者兼有。除了定義基本 Java EE 平台之外,此規範還將定義在 Java EE 設定檔中引用 Java EE 平台技術的規則。
設定檔是向前邁出的一大步。最終,使用者將有權選擇他們想要的東西,而不是規格委員會在使用者開始構建應用程式前 2 年認為他們想要的東西。是時候用一些健康的競爭來取代蘇聯式的指令經濟了。為了接續我之前的觀點:鑑於在之前的修訂版中,EE 平台試圖像蘇聯五年計畫一樣規定您如何構建應用程式,在 EE 6 中,平台的角色更像是西方國家的法律框架,它確保人們可以自由競爭和作為個人自由行動,同時為了所有人的利益而同意遊戲規則。
顯然,企業 Java 技術的使用者已經確定了許多設定檔。例如,今天的 Web 應用程式、SOA 應用程式和金融中介軟體對伺服器基礎架構有截然不同的要求,儘管 Java EE 的不同部分可以為它們中的每一個提供價值。特別是,Java EE 迄今為止一直忽略了批次和無頭中介軟體使用者;最終,在 Java EE 6 的潛力中,他們看到了希望。
使用設定檔是解決 Java EE 平台不斷增長的規模的一種工具。同樣,Java EE 平台中包含的一些技術也不再像它們被引入平台時那樣相關。需要一種以謹慎有序的方式從平台中「修剪」這些技術的方法,以最大程度地減少對使用這些技術的開發人員的影響,同時允許平台變得更強大。我希望這能貫徹始終。假設您有一個 Java EE 5 伺服器(您的供應商可能能夠或無法在可接受的時間範圍內為您提供)。您是支持 EJB CMP 2.0 甚至 1.1 的產品的自豪擁有者。還記得 CMP 1.1 中的公共實例變數嗎?您仍然可以享受它們。這是醜陋的史前歷史,應該被遺忘,而不是膨脹今天的產品。如果還有任何應用程式仍然在這些東西上運行,它們可以在較舊的伺服器上苟延殘喘,直到有人將它們從苦難中解救出來。
很高興在提案中讀到「EJB CMP - 有效地被 Java Persistence 取代」。此版本的一個重要主題是使 EE 在 2007 年的世界中更具相關性,並且刪除舊的失敗或使其成為可選是這一聲明的有力證明,它為為其帶來產品的使用者和供應商帶來了真正的實際好處。
Interface21 期待與 Sun 以及 EE 6 umbrella 小組和相關專家小組中的其他公司和個人合作,使 EE 6 成為盡可能強大的平台。
正如我所說的,我從未想成為異端。基本上,沒有 EJB 的 J2EE (我與 Juergen Hoeller 合著) 的願景並非要拋棄 J2EE,而是要誠實地指出桶子裡的壞蘋果,並強調標準化需要受到創新的調節,從而幫助它蓬勃發展。Java EE 6 的提案似乎允許這種情況發生,我很高興能夠加入這個群體。讓我引用那本書中的一段話,大部分是在大約 4 年前寫的。請注意,重點不僅僅是批評 EJB,而是強調 J2EE 的全局才是真正重要的。
J2EE 仍然是一項相對年輕的技術。它不完美並不令人驚訝。現在是時候評估它在哪些方面發揮了作用,以及在哪些方面表現不佳,以便我們可以消除負面因素並享受正面因素。由於 J2EE 包含了很多內容,這本質上意味著識別 J2EE 中最有價值的子集,以及一些我們需要有效利用它的補充基礎架構。…你可能想知道,“沒有 EJB 的 J2EE 還剩下什麼?” 答案是:很多。J2EE 遠不止 EJB。許多 J2EE 開發人員不這麼認為,當他們在你的桌子上看到這本書時會告訴你,但對 EJB 的作用以及 J2EE 整體作用的冷靜分析表明,EJB 只是更大、更重要的全局的一部分。J2EE 本質上是關於標準化一系列企業服務,例如命名和目錄服務 (JNDI)、事務管理,提供可能跨越不同事務資源的標準 API (JTS 和 JTA)、連接到遺留系統 (JCA)、資源池和線程管理。J2EE 的真正力量在於這些服務,而這種標準化為業界做出了巨大的貢獻。
我相信,鑑於 Java EE 6 的目標,支持它與我在沒有 EJB 的 J2EE 和其他地方表達的關於 J2EE 的立場是一致的。例如,沒有 EJB 的 J2EE 的另一個中心主題是標準化應該扮演的角色,以及在哪些方面讓框架之間的競爭來促進創新會更好。
雖然開放(或至少部分開放)的規範流程是積極的,但我認為 J2EE 相對於 .NET 的最大優勢之一是 Java/J2EE 開源軟體的豐富性... 正如我們所看到的,關於 J2EE 架構的正統觀點與現實世界的經驗不符。一些 J2EE 規範在較小程度上也是如此。我認為我們正處於 J2EE 平台發展的一個重要十字路口。它顯然需要發展和創新才能生存和繁榮。然而,諸如 JTA、JAXB、JDBC 和 Java 語言本身等基本企業基礎架構的規範意味著有創新的空間,可以在不破壞對企業軟體最棘手、底層問題的一致、標準方法的好處的情況下,訪問該基礎架構。當我在 2003 年寫下這些話時,我沒有預料到 Java EE 專家組最終會使用“可擴展性”這個詞來概括同樣的想法。這是一個令人愉快的驚喜。
我相信企業 Java 社群應該歡迎 Java EE 6,並且應該歡迎 Sun 願意與時俱進,並做出將加強整個企業 Java 平台的選擇。J2EE/Java EE 中有很多優點,但一些問題掩蓋了它。Java EE 6 應該會改變這種情況!