jakarta ee

自創建以來，MicroProfile贏得了廣泛的關注，并制定了各種規格。 最初，它的創建是為了在多個供應商的推動下，以更快的速度推進微服務世界的企業Java。 現在，隨著在Eclipse Foundation下將Java EE轉換為Jakarta EE，MicroProfile如何合理地適合Enterprise Java領域中的情況？

據我所知，MicroProfile背后的想法是在推進Java Enterprise方面創造更快，更有效的進步。 到目前為止，有各種各樣的規范，例如Config，Fault Tolerance或Metrics，旨在縮小Java EE API的差距以適應現代企業Java的需求。 同樣，MicroProfile旨在使為微服務部署設計小型運行時成為可能，在這種情況下，項目僅提供他們正在使用的規范。

長處

今天，我看到了MicroProfile在改進企業Java方面的最大優勢，即添加了Java EE 8當前缺少的內容。特別是諸如彈性，可觀察性或簡單的，獨立于供應商的配置之類的問題尚未被Java Enterprise標準涵蓋。 盡管在生產中運行企業應用程序時始終必須考慮這些問題，但對于基于微服務的系統而言，它們變得更加重要，因為基于微服務的系統分布更廣。 諸如Config，Fault Tolerance或Metrics之類的MicroProfile項目彌合了這些差距。

MicroProfile已經有效地充當了潛在的新規范的孵化器。 MicroProfile項目能夠定義Java Enterprise擴展，但是可以在規范級別上定義它，而不僅僅是單個實現或特定于供應商的解決方案。 這些項目可以作為新的Java Enterprise標準的基礎。 實際上， Config JSR將基于MicroProfile Config及其實際經驗。

除這些要點外，MicroProfile還允許開發人員通過僅包括他們所需的規范來分別配置其運行時。 按照這種方法，MicroProfile在其第一個版本中僅包括CDI，JAX-RS和JSON-P。

但是，對我而言，這僅是運行時優化。 我已經說過幾次了，我認為這些標準以及擁有瘦身部署工件的可能性更為重要。 我通常使用Java EE應用程序服務器，該服務器支持MicroProfile，允許精簡部署工件，并且仍附帶其他企業標準，例如JPA。 如果（且僅當）最小運行時大小成為問題時，我將使用空心WAR / JAR方法。

少了什么東西

在將MicroProfile項目與Java Enterprise標準進行比較時，開發人員會注意到，前者缺少某些規范的互操作性。 無需任何配置即可使用多種技術的能力是我聲稱Java Enterprise API包含非常有效的開發人員體驗的原因之一。 根據哪些項目將被視為MicroProfile的一部分，未來的規范可能會更多地集中在這一點上。

MicroProfile和Jakarta EE形成的當前狀況面臨著從組織角度和技術角度重新發明輪子的危險。 Jakarta EE傾向于類似地重復MicroProfile經歷并仍在進行的開源過程和開發。 尤其是，當兩種技術的方向和責任沒有完全弄清楚時，供應商和貢獻者就有兩次花費類似努力的風險。 技術責任也是如此。 盡管大多數MicroProfile項目在Java Enterprise世界的其余部分都可以很好地工作，例如，Rest Client與JAX-RS廣泛重疊，并且可以以二進制兼容的方式基于后者。

MicroProfile運行時的部署模型主要基于獨立的可執行文件。 除此以外，一些供應商還支持定義運行時包含的規范以及將精簡部署工件作為空心WAR / JAR工件進行運輸的組合。 后者提供了很好的折衷，在某種程度上是兩全其美。 但是，如前所述，我不認為最小的總運行時大小對于大多數企業項目至關重要。

提議的想法：Jakarta EE的孵化器

我對MicroProfile的未來及其在Jakarta EE時代在企業Java世界中的地位的建議是，作為將來Jakarta EE規范的孵化器。

MicroProfile將通過基于規范的擴展來推進企業Java，而不僅僅是基于單個實現或特定于供應商的功能。 與今天類似，MicroProfile項目將添加Java Enterprise中缺少的內容。

與當前的項目不同，孵化MicroProfile可以基于Jakarta EE的所有標準。 他們將共享相同的技術設計原則（請參閱我關于Jakarta EE設計原則的建議 ）。 同樣，MicroProfile可以確保Jakarta EE與MicroProfile規范之間的互操作性，類似于當今的Java EE標準。

這將大大提高開發人員的體驗。 開發人員可以將MicroProfile項目添加到Jakarta EE應用程序中，以填補該Jakarta EE版本中的空白。 這些項目將遵循相同的原則，具有相似的外觀，并與現有標準良好地協作。

與企業標準相比，MicroProfile允許更快的進度。 盡管Jakarta EE標準將花費大量的時間和精力，但是可以以輕量級的方式來組建和執行MicroProfile孵化項目，從而減少組織開銷。 盡管如此，孵化MicroProfile仍將遵循Jakarta EE背后的思想和原則。

對于沒有立即或最終添加到標準集中的擴展，孵化器流程始終是一個更安全的場所。 但是，需要孵化功能的項目可以在不更改其其余Jakarta EE應用程序的情況下將它們合并。

最終，一個正在孵化的MicroProfile項目一旦過渡到成為Jakarta EE標準，將剩下較少的工作。 雖然企業標準需要考慮更多方面，但是與創建兩個單獨的規范相比，所需的總體工作量和工作量將少得多。

下一步

通常，至關重要的是，Java Enterprise社區必須共享一個清晰的通用圖像，以表示MicroProfile在未來的地位。

遵循MicroProfile作為Jakarta EE孵化器的想法的下一步是定義并達成協議：

• Jakarta EE和MicroProfile的共享技術設計原則
• 孵化MicroProfile的命名，品牌和名稱空間
• 未來MicroProfile項目和孵化到Jakarta EE的通用流程

我對您的反饋意見很感興趣。 您對MicroProfile和Jakarta EE如何以及如何共存有何想法？

翻譯自: https://www.javacodegeeks.com/2018/08/microprofiles-role-jakarta-ee.html

jakarta ee

總結

以上是生活随笔為你收集整理的jakarta ee_MicroProfile在Jakarta EE时代的作用的全部內容，希望文章能夠幫你解決所遇到的問題。

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