java ee技術

在過去的幾個月中，我們經歷了這個決策過程：為Java平臺上的企業開發選擇哪種技術堆棧？ 有多種選擇。 但是，我們深入討論的是：純Java EE 6堆棧與帶有Java EE的Spring。

以下博客文章總結了當您考慮這些技術堆棧選項之一時發現的有趣的關鍵問題。 我不會試圖說服某人選擇兩者之一。 這對我來說很重要，我想分享的是決策過程和關鍵論點。

什么是“標準”？ 在我們的討論中，“標準”一詞非常重要，特別是對于執行管理層而言。 我認為這使決策者對保護投資充滿熱情。 但是什么是標準，在Java生態系統中我們可以認為什么是標準？ Codecentric AG的創始人兼董事會成員Mirko Novakovic寫了一篇非常有趣的博客文章，名為：“ Java EE vs Spring。 或者：什么是標準？ ” Mirko指出以下內容：

• 對他來說，標準是建立，接受和主導的東西
• 遵循此定義，僅將某些Java EE API（例如Servlet規范）視為標準，因為它們已廣泛應用于Java生產技術領域
• 他過去曾說過，某些Java EE標準API幾乎沒有投資保護，例如EJB規范（過去十年中大量API發生了變化）
• 他還聲稱，JPA和JSF的1.0版本不足以滿足大型企業開發項目中的技術要求。
• 他將CDI視為另一個年輕的標準，它需要證明其長期穩定性，然后才能被視為Java企業應用程序中的標準IOC機制。
• 因此，他目前的結論是：Sping和Hibernate仍然是Java企業開發的“實際”標準。

Mirko描述了一個有效的觀點。 另一個有效的觀點是：在Java規范請求（JSR）中指定和發布的所有（唯一的）API都可以視為標準。 應用服務器供應商根據這些JSR構建產品。 因此，如果Java開發人員使用這些標準API，他們可以構建可在任何應用程序服務器平臺上運行的Web應用程序。 在Java EE 6中，他們可以構建企業級Web應用程序，而無需進一步依賴于第三個庫。 結果是一個非常輕便的Web應用程序（WAR或EAR文件），僅包含您開發的代碼。 那是Java EE的情況，也是有效和結論性的。 當您必須決定在編程模型中使用哪些API時，對您來說最重要的是什么？ 有很多決策參數，例如簡單性，API的完整性，改進的生產穩定性等等。 我們在研究中列出了一長串參數。 其中一些比其他一些更為重要，它們是：API的成熟度，供應商獨立性，生產就緒性，投資保護和共同判斷。 標準API的生命周期 我們的假設是，每個API進入Java EE標準時都會經歷理想的 生命周期 （我們在過去已經觀察到）。 這些階段是：Newby，Storm，Stabalize，Matural，Dead。 標準API的第一個（ Newby ）版本1.0幾乎沒有功能。 通常，僅僅滿足大型開發項目的功能和性能的技術要求是不夠的。 這是Mirko反對CDI或JPA 1.0的觀點。 有些人使用這些API，但他們還必須編程許多變通方法以獲取所需的全部功能（例如，JPA 1.0中的第二級緩存）。

這些階段的經驗教訓進入了后續的API版本，因此，API有時會變得不穩定。 增加了功能，減少了采用，簡化的API等。 如果客戶希望遵循該標準，那么這種動蕩且不確定的風暴階段會導致遷移成本增加。 即使2.0版本向下兼容，使用不錯的新功能代替許多變通辦法也意味著重構工作。 如果該API并非沒有問題，兼容的API更改會強制執行遷移工作，則別無選擇。 過了一會兒，但是API變得成熟，這些重構，成本下降，該API進入stabalization的階段。

一個成熟的 API始終具有較低的遷移和重構成本，因為未應用任何基本更改。 一段時間后，不再使用某種技術，因為它已被其他創新的API所取代。 技術已死了–這些API不再投資，社區 停止了該項目。 圖1顯示了理想的API生命周期。

圖1：理想的Java EE API生命周期

生命周期模型的關鍵假設是：您決定越早使用API??標準，則在后續版本中增強API時，可能要付出的重構成本就更多。 因此建議是：您必須判斷生命周期中（Java EE）API的狀態。 然后，您決定是否要使用成熟的API和更低的制罐成本。 還是您想成為利用技術束縛的先驅之一。 盡早采用的優勢之一可能是早日實現更高的開發效率，與其他標準API的更高集成度或開發咨詢知識。 我們已決定僅使用成熟的API，我們不希望與“ Newby”狀態API相關的遷移成本。 我們的信任度很低，因為我們在EJB時代遭受了很多苦難。 如果我們回顧一些Java EE標準的歷史，則與API穩定性相關的變化是巨大的。 因此，我們寧愿等到API成熟并且已成為生產中大型應用程序系統的成熟技術。 如果我們認為Java EE API已經成熟，則可以考慮使用它。 獨立性（開發，運營和OE供應商） 對我們而言，架構決策中的另一個重要因素是：我們希望為以后的架構，設計或實施決策提供最大的靈活性。 那是什么意思 例如，如果您選擇的技術堆棧是應用程序服務器的一部分，那么您的應用程序開發部門，基礎架構人員和原始設備（OE）供應商之間的關系將非常緊密。 為什么？ 因為新的應用程序服務器版本包含您在業務應用程序中使用的新API版本。 結果是，當您決定使用新版本的應用程序服務器時，可能必須更改現有代碼。 所有這些降低了靈活性。 另外，OE供應商可能會急著遷移您，因為“如果您想擁有我們應用程序服務器的此獨特監視或集成功能，則必須使用最新版本的XY Java EE服務器”。 OE供應商通常會對他們感興趣，因為他們希望您使用最新版本。 對于他們來說，支持更少的生產版本只是更便宜。 它為他們帶來更少的維護成本和更高的咨詢收入。 我們在生產中運行了50多個Java EE應用程序。 出于上述原因，保持獨立于運行時基礎結構對我們非常重要。 因此，我們通常更喜歡業務應用程序和應用程序服務器之間的“層”。 換句話說：我們通常不直接使用Newby API，我們通常有一個包裝它們的包裝器API（參見圖2）。

該包裝器用作構建業務應用程序的API。 包裝器API可以是Spring框架，也可以是您自己的一組自定義框架API。 這樣，當我們分別移動到新的應用程序服務器版本或Java EE版本時，進行所需的更改將更容易，更有效。 包裝器吸收了Java EE API的更改，使我們免去了更改50個應用程序的負擔。 相反，我們只在中央位置進行一次更改。 我們的開發小組不受應用程序服務器升級的影響。 OE供應商和Java Communication Process（JCP）不會影響我們的決定和努力。

基礎架構的生產就緒性（或：現在還是以后？） 您的應用服務器是否有生產就緒版本，可以實現新的Java EE 6標準？ 在我們的情況下（IBM WebSphere），Z系列上沒有任何Java EE 6版本。 因此，如果我們還不能在生產環境中運行應用程序，那么思考Java EE 6幾乎沒有任何意義。 您必須決定是現在還是以后使用某種技術。 例如，作為IOC機制的CDI（JSR 299/330）對于大型應用程序還不夠成熟。 因此，你可能要選擇像Spring框架或谷歌吉斯的替代品來完成這項工作，如果你想現在已經送到您的客戶端（效益分析）值。 投資保護（或：兼容性低下） 我已經在前面提到過：直接將Java EE API用于許多生產應用程序（可能是50或100），可能會降低設計和實現決策的靈活性。 在研究投資保護時，同樣的論點也適用。 對我而言，投資保護主要涉及在特定時期內較低的技術（重構）成本。 您想花費金錢來實現業務價值，您想專注于實現業務功能。 你不想花費在生活必需品技術的精力（例如，發布版本升級，平臺遷移，開發自定義的API）。 為了實現這一點，選擇正確的開發API至關重要。 根據我們的生命周期模型，一個不錯的選擇是在生命周期的長期成熟階段開始時選擇API。 這降低了重構成本，從而增加了投資保護。 我們已經解釋了Java EE不僅提供成熟的API。 例如，CDI在其JSR 299/330版本中還不成熟。 解決該難題的一種可能的方法是組合來自不同來源的API，您可以為業務應用程序配置自己的API集。 如果您使用自己的一組 真實的標準API，則可以保護您的投資。

我說的是您自己的一套，因為您可能會使用混合技術堆棧 （圖2）：一些成熟的Java EE API（例如Servlet，JPA 2.0），一些實際標準（例如Spring IOC）和一些專有的自定義API作為圍繞Newby Java EE API的包裝而開發的。 最重要的是，這些API支持生產應用程序的低兼容性 。 當您要移至新的Java EE 應用程序服務器版本 時，必須找到一組API，這些API可使您免于繁重的遷移工作 。

圖2：用于Java企業開發的混合技術堆棧

共同判斷 我做決定時要做的事情就是共同判斷。 其他專家怎么看？ 他們有什么意識形態？ 他們對一個或另一個建議有什么興趣？ 如果查看像Spring Framework這樣的大型Java企業開發框架，您會發現它們使用標準的Java EE API，但僅使用它們認為已經成熟的API。 對于我是否使用特定的API，這是一個很好的提示。 無論您是查看Spring還是觀察其他框架，都不會滿足。 關鍵是您可以對照其他資深（最好是獨立的）專家的意見來驗證您的意見。 摘要 當您決定使用哪種技術堆棧時，有一長串參數。 我在本文中描述的內容在我們的決策過程中非常重要。 我們的結論是，目前最好的方法是使用混合技術堆棧。 一些API是事實上的標準，一些是Java EE標準，其他是我們開發的自定義API。 我們的主要目標是隨著時間的推移以較低的重構成本保持靈活性。 關于標準的最后思考：您是否曾經問過自己，遵循標準是否真的很重要？ 有時，我的印象是，對某些人來說，使用標準是接近絕對真理的事情，是普遍要做的事情。 水是濕的，天空是藍色的，使用標準是正確的。 你知道我想說什么嗎？ 所有這些事實上的標準（例如Spring和Hibernate）如何成為標準？

答案是：因為有人有勇氣使用它，而其他人（包括Java EE）則緊隨其后。 “標準”是社區中很大一部分用來在生產中運行大型應用程序的工具。 標準不一定是Java EE標準。 過去，Java EE標準遵循事實上的標準框架（例如Hibernate，Spring）。 在開源框架中，任何新技術很可能首先達到一定的成熟度。 然后它們將成為Java EE標準。 這是因為至少在最近十年中，絕大多數Java技術創新都源于社區。

參考： Java EE 6與Spring Framework：我們JCG合作伙伴 Niklas的技術決策過程。

相關文章 ：

• 從Spring到Java EE 6
• Java EE6 CDI，命名組件和限定符
• Java EE6裝飾器：在注入時裝飾類
• Spring Data JPA的持久層
• Spring MVC3 Hibernate CRUD示例應用程序

翻譯自: https://www.javacodegeeks.com/2012/01/java-ee-6-vs-spring-framework.html

java ee技術

總結

以上是生活随笔為你收集整理的java ee技术_Java EE 6与Spring Framework：技术决策过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。