1. 首页
  2. 博客
  3. 您的输入需要确定Jakarta EE / MicroProfile对齐的路径

您的输入需要确定Jakarta EE / MicroProfile对齐的路径

如您所知，Java EE已从Eclipse Foundation的Jakarta EE过渡到开源治理。作为针对微服务架构优化企业Java的一项独立计划，MicroProfile一直在向前发展。最近成立了Java原生云（CN4J）联盟，以促进Jakarta EE和MicroProfile之间的更好的一致性。

要解决的关键问题之一是Jakarta EE如何使用MicroProfile规范（例如MicroProfile配置）。关于如何做到这一点，有几种选择。下面是对每种方法的优缺点的简要分析，到目前为止，在CN4J社区中已有讨论。分析结束时，您需要进行一项调查。除了选择您认为最佳的选项外，提供注释以证明您的首选替代方案非常有价值。调查结果将与CN4J社区和主要决策者共享。

Jakarta EE和MicroProfile上下文

Jakarta EE和MicroProfile都产生了旨在用于云原生和微服务用例的规范。尤其是，MicroProfile特别关注满足云原生和微服务用例的需求。MicroProfile还产生相对较快的平台发布（大约每季度一次），而Jakarta EE的发布节奏则较慢（可能的长期目标大约为每年一次）。

Jakarta EE当前为所有规格的向后兼容性提供了相对有力的保证。MicroProfile当前不保证对所有规范的向后兼容性，但会生成已在现实世界中采用的可用于生产的规范。这一特性使MicroProfile可以专注于新兴领域的创新，而Jakarta EE则专注于最适合大型企业的更为保守的用例和稳定性。尽管MicroProfile规范有时需要打破向后兼容性，但在做出最终用户决定时要格外小心。

MicroProfile规范取决于一个或多个Jakarta EE规范，而Jakarta EE当前不依赖MicroProfile。

选项A1：无需更改名称空间即可将MicroProfile规范移至Jakarta EE（因此无需将名称空间从org.eclipse.microprofile。更改为jakarta。）。尽管如此，MicroProfile规范的Maven坐标将移至雅加达。雅加达EE工作组将进行进一步的发展。

优点：

  • 现有的MicroProfile用户无需切换名称空间。
  • 这使MicroProfile在将规范引入Jakarta EE中应有的功劳。
  • MicroProfile和Jakarta EE之间没有API重复。
  • MicroProfile和Jakarta EE之间仅存在单向依赖关系。

  • 一些用户可能希望将MicroProfile更好地集成到Jakarta EE中。该选项在某种程度上满足了这一愿望。 缺点：

  • Jakarta EE用户缺乏名称空间一致性，否则不使用MicroProfile。 一些用户可能会认为这意味着只有Jakarta EE才具有生产就绪规格。

  • 对于在同一应用程序中同时使用Jakarta EE和MicroProfile的临时用户来说，这并不是立即显而易见的，其中MicroProfile API属于MicroProfile工作组，而MicroProfile规范属于Jakarta EE工作组。这可能会导致某些用户感到品牌混乱，以及对诸如向后兼容性和发布节奏等特征的期望不匹配。 选项A2：将MicroProfile规范（包括名称空间）移至Jakarta EE。在这种情况下，名称空间将从org.eclipse.microprofile。更改为jakarta。。雅加达EE工作组将进行进一步的发展。一旦移动了规范，MicroProfile工作组将不再做进一步的工作以进一步完善该规范。

优点：

  • Jakarta EE用户的命名空间一致性，否则不使用MicroProfile。
  • MicroProfile和Jakarta EE之间没有API重复。
  • MicroProfile和Jakarta EE之间仅存在单向依赖关系。
  • 对于在同一应用程序中同时使用Jakarta EE和MicroProfile的用户来说，哪些规范属于MicroProfile工作组，哪些规范属于Jakarta EE工作组，对于用户而言，显而易见。这包括对特性的期望，例如向后兼容性和发布节奏。
  • 一些用户可能希望将MicroProfile更好地集成到Jakarta EE中。该选项在某种程度上满足了这一愿望。这可能包括对jakarta。*名称空间的可能偏好，该名称空间更为通用-与org.eclipse.microprofile名称空间相反，后者可能意味着关注微服务。

缺点：

  • 现有的MicroProfile用户将需要切换名称空间，以利用移动规范的更新版本。同样，实施者将需要努力进行迁移，包括至少在短期内可能维护两个单独的工作流。
  • 一些用户可能会认为这意味着只有Jakarta EE才具有生产就绪规格。

选项B：在Jakarta EE中参考MicroProfile规范，而不移动MicroProfile规范。Jakarta EE将不会重复任何引用的规范，并且MicroProfile规范只会在MicroProfile工作组下发展。

优点：

MicroProfile和Jakarta EE之间没有API重复。 Jakarta EE仍然可以使用该规范，而任何用户或实施者都无需进行任何迁移工作。 一些用户可能希望MicroProfile和Jakarta EE保持尽可能独立。该选项在某种程度上满足了这一愿望。 缺点：

  • Jakarta EE用户缺乏名称空间一致性，否则不使用MicroProfile。

  • 对于在同一应用程序中同时使用Jakarta EE和MicroProfile的用户而言，Jakarta EE引用了MicroProfile规范，而后者却没有（因此对诸如向后兼容性等特性抱有不同的期望），这对于用户来说并不太明显。

  • 引用的MicroProfile规范可能希望在其发展的某个时刻打破向后兼容性，而Jakarta EE则不希望。需要做出更多努力来解决这种不匹配问题。

  • 这在Jakarta EE和MicroProfile之间引入了循环依赖。这会使匹配的发布节奏，依赖性，功能和协作变得更加困难，包括最终用户可能遇到的意外挑战。以下是一个说明版本依赖性不匹配的可能示例：MicroProfile m2与Jakarta EE j1对齐，而Jakarta EE j1与MicroProfile m1对齐。MicroProfile m2中包含MicroProfile Configuration c2。Jakarta Persistence p1依赖MicroProfile m1中的MicroProfile配置c1，因为Jakarta EE j1在MicroProfile m2之前发布。一个应用程序希望同时使用Jakarta EE j1和MicroProfile m2。该应用程序最终将使用哪个MicroProfile Configuration版本？如果已加载MicroProfile m2中的MicroProfile Configuration c2，

  • 如果MicroProfile规范中需要对Jakarta EE集成进行特定的更改，则将需要在工作组之间及时进行有关依赖性，发布节奏和功能方面的协调。

选项C： 创建MicroProfile规范的Jakarta EE版本。在这种情况下，Jakarta EE和MicroProfile将并行开发相似的功能。

优点：

MicroProfile和Jakarta EE可以独立地开发最合适的功能。 最终用户可以根据自己的喜好混合搭配MicroProfile和Jakarta EE。实现可以做同样的事情。

缺点：

  • Jakarta EE和MicroProfile上的工作量和资源重复。重复工作也可能会扩展到实施中。
  • 最终用户将需要在Jakarta EE和MicroProfile中的等效功能之间进行选择。
  • MicroProfile和Jakarta EE很可能会被视为直接竞争的努力，从而导致进一步的混乱。

表达您的意见！

每种对准方法都有优点和缺点。尽管决策者可能会猜测对于最终用户和生态系统而言，正确的权衡是什么，但您可以在提供反馈时就最适合您的方面发挥作用。

原文链接：http://codingdict.com

热门标签