jakarta

自创建以来，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标准涵盖。 尽管在生产中运行企业应用程序时始终必须考虑这些问题，但是对于基于微服务的系统而言，它们变得更加重要，因为基于微服务的系统分布更广。 MicroProfile项目(例如Config，Fault Tolerance或Metrics)填补了这些空白。

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