MicroProfile 社区对 Jakarta EE 的影响

近期， James Roper 荣升为 Eclipse MicroProfile 的提交者（Committer），他也因此成为 Jakarta EE 参与成员 Lightbend 的首位提交者。Roper 是 Lightbend 的高级开发人员，也是 Lagom 微服务框架的创立者之一。

Roper 在近期发表的一篇博客帖子中提及，他荣任提交者的经历是与 MicroProfile 社区及社区对 Jakarta EE 的影响密切相关的。Roper 指出，MicroProfile 的四家主要贡献者分别是 IBM、Red Hat、Tomitribe 和 Payara：

IBM 和 RedHat 是两家在 Java EE 市场投资和份额上大体具有可比性的软件厂商。它们都是大型企业，推动了 MicroProfile 的大部分工作。相比而言， Payara and Tomitribe 是两家较为小型的企业，它们分别通过支持 Glassfish 和 TomEE 而推动企业业务的发展。它们积极参与社区讨论，自身做出了一些显著的贡献。

除了上述四家企业，还有其它一些软件厂商也实现了 MicroProfile，但是看上去在社区中并不活跃。也有一些个体积极参与了社区讨论，例如 Java Champions 和 Java EE Guardians 。所有这些都表明 MicroProfile 具有一个健康的社区，该社区由一些厂商和个人组成，其中部分更为活跃，部分稍为沉默，但大家共同致力于同一个目标。

据 MicroProfile 的提交者页面显示，相对于各自的企业规模，上述四家企业所具有的提交者数量分别表现为：

• IBM：21 位；
• Red Hat：17 位；
• Tomitribe：9 位；
• Payara：5 位。

Roper 评价了所有企业在 MicroProfile 社区中的合作情况：

更令人惊奇的是，这些合作良好的软件厂商实时上是激烈的竞争对手。企业的产品彼此直接竞争，而每家企业正在努力争取对方的市场份额。然而，这些企业仍然设法找到了一种可以互利共处的方式，而这种方式已被证明是具有生产力和创新性的。这就是为什么在我看来，MicroProfile 社区对于 Jakarta EE 是一件好事。

Roper 对 InfoQ 分享了自身的经历。

InfoQ：是什么促使你成为一名 MicroProfile 的提交者？

James Roper：我一直希望能致力于简化开发人员的工作，这正是 Lightbend 最初吸引我之处。Play Framework 所具有的热加载（hot reload）和推荐适用的默认配置（sensible opinionated defaults）特性，为开发者提供了 JVM 上梦幻般的体验。我希望自己也能参与到为开发人员提供这种体验之中。

MicroProfile 使我可以提升到一个新的层级，即让 Lightbend 的一些开源项目被更广泛的用户使用，尽管这些项目尚未接近 Java 标准所具有的业界渗透率，达到 MicroProfile 和 Jakarta EE 所建立和形成的标准。MicroProfile 为我们提供了一个机会，将 Lightbend 所创建的奇妙开发者体验带给更广泛的受众。

InfoQ：是什么推动 Lightbend 以成员方式参与 Jakarta EE？

Roper：在扩大社区方面，Lightbend 所面临的一个挑战是，我们的技术和方法常常被视为与业内其它同行的存在截然不同。这使得采用这些技术的风险很高，原因包括难以招聘到具有正确技能的开发人员，以及企业的开发人员难以在不理解这些技术和方法的情况下正确地使用它们。

参与 Jakarta EE 对我们解决这个问题是一把双刃剑。一方面，参与 Jakarta EE 使我们能够让自己的平台更接近于行业标准。并且通过帮助树立标准，可使我们的微服务和云原生系统方法兼容，进而我们也可以自己实现这些标准。

另一方面，参与 Jakarta EE 使我们能够影响行业标准，让标准更接近于我们所使用的方法。因为我们相信，我们给出的响应式微服务方法对于构建可扩展的弹性系统是至关重要的。我们认为这不仅对于我们企业自身，而且对于整个 Jakarta EE 生态系统都是有所裨益的。

InfoQ： 您打算如何向 MicroProfile 做出贡献？

Roper： 我个人的贡献，以及 Lightbend 所做出的更广泛的贡献，将主要围绕着建立新的响应式规范。我们完成的第一件事，是帮助大体上确立了一种编写 Reactive API 并在 MicroProfile 中采用响应式特性的方法。为使用这种方法，我们提出 MicroProfile 需要 Reactive Streams 操作 API，以支持 MicroProfile 开发人员与 Reactive Stream 的交互。

该API 规范正在完成中，进而引发了此后的“ MicroProfile Reactive Messaging ”规范。该规范支持消费、发布和处理基于 Reactive Streams 的服务间消息流。这是我们当前的主要关注焦点。

展望未来，一旦上述规范完成，我们将继续寻求一些可使 MicroProfile 从响应式中受益的方法，并有望在这些领域做出贡献。就在今天，MicroProfile 持久性问题得以提出。Lightbend 对于解决持久性难题具有丰富的经验，这些难题在使用单一数据库和 ACID 事务的单体应用中并不会发生。由此，我参与了相关讨论，并寻求在其中提供我们的经验。

InfoQ： 您是否希望 Lagom 的微服务能影响 MicroProfile？如果是这样，您认为 Lagom 会在哪些规范中做出贡献？是 Config、CDI、JSON-P、Fault Tolerance，或是其它？

Roper：说实话，目前为止 MicroProfile 所做的很多工作都一直是在追赶进度。以 JSON 支持为例，实际上 10 年前行业就在使用 JSON 做通信的标准化，而 Java EE 仅是在 2013 年才在 Java EE 7 中由 JSON-P 引入了 AST for JSON，至今仍没有发布具有将 Java 对象绑定到 JSON 的标准 API 的 Java EE 或 MicroProfile。JSON-B 是一个提供相关规定的规范，计划包含在即将发布的 MicroProfile 2.0 和 Java EE 8 版本中。

另一方面，在这些基本特性被认定为行业标准之前，Lagom 是基于一些已支持这些特性的技术构建。因此我不认为这些类型特性的最大价值是由 Lagom 给出的。例如，JSON 绑定具有大量很好的、成熟的解决方案，而显然 Lagom 支持 JSON 绑定，并且做得很好，但当前很多其它框架也都能做到如此。因此，我认为 Lagom 并不会对现有的 MicroProfile 规范产生显著的影响。

Lagom 具有独特价值之处，在于它支持构建响应式微服务。这实际上是为了解决云计算本身在令人难以置信的脆弱世界中随时随地可能出现故障的问题，Lagom 应用模式可确保开发人员集中精力于解决自身的业务问题，而非解决上述脆弱性问题。

业界在实施这些模式上非常缺乏经验，很少有基于新规范的产品，而更少有产品在行业中得到广泛应用。这些模式需要新的架构，因此需要新的 API，例如用于流式传输的 API、用于异步通信的 API、用于基于事件日志持久化的 API，等等。由此在这些新规范的制定和发展中，Lagom 将对 MicroProfile 产生最大的影响。

InfoQ： 对于 MicroProfile 和 Jakarta EE，您是否还有更多愿与我们读者分享的？

Roper：我认为很多人鉴于 Oracle 在整个 Java EE 生态系统中掉了链子，对于标准在架构和 API 中所起的作用持怀疑态度，这是可以理解的。我要说的包括如下几个方面：

1. Jakarta EE 已脱离了 JCP 和 Oracle，不会再犯同样的错误。我相信，Eclipse 为 Jakarta EE 设立的管治模式，在大型软件厂商角色和以价值为依据的贡献者角色这两者间取得了很好的平衡。前者投入了大部分的时间和资源开发与维护构成 Jakarta EE 的规范、实现和 TCK（技术兼容工具包，Technology Compatibility Kits），后者来自于创新并驱动规范推进的贡献者。Lightbend 能够如此轻松地从 MicroProfile 和 Jakarta EE 社区的完全门外汉，转而成为 MicroProfile 项目的牵头开发者，这一事实正是对此问题的最好证明。
2. 正是 Jakarta EE 和 MicroProfile 所推行的开放式协作流程，使得基于标准的框架和 API 独具价值。在我为期不长的贡献社区期间，我学到了很多，包括我们的行业，以及人们在做的各种事情、对人们重要的事情、人们如何解决问题，以及一些仅局限于 Lightbend 而可能无法学习到的事情。

因此，我相信正在制定的 MicroProfile 规范将会青出于蓝而胜于蓝，因为它从我们在 Lagom 的经验中吸取了大量的经验，而这种更广泛的经验正在融入到规范制定过程中。我期待参与整个过程，并在 Lagom 中提供这些规范的实现。所以，我相信未来几年中，Jakarta EE 和 MicroProfile 标准要优于任何一家软件厂商所能给出的标准。
3. 在企业在逐步拥抱云技术的过程中，我认为对企业一个非常重要的要求是，应比以往任何时候都要避免出现“供应商锁定”的情况。以前，供应商锁定意味着被锁定到特定的应用服务器和数据库，而企业仍然控制着硬件。

现在，供应商锁定不仅局限于应用服务器，而是包括整个部署架构，从服务器到网络、操作系统、编排，当然还包括应用服务器和数据库。越来越多的云服务供应商推出了 PaaS 功能，这是考虑到 PaaS 具有很好的黏性，能将用户锁定于企业的云服务。因此，供应商锁定的成本要比以往高出很多。

如果为避免出现以前曾发生的锁定情况，人们需要一种基于标准的框架。并且在将系统部署到云时更需要一种基于标准的框架。Jakarta EE 和 MicroProfile 提供了这种缓解锁定问题的方法，允许 PaaS 产品不再将用户绑定到特定的云供应商。这样，企业可以根据哪家供应商在给定时期内可提供最好的技术，做出自由的选择和切换。

InfoQ： 介绍一下您当前的职责吧？也就是说，您的日常工作情况。

Roper：我的主要职责，也是我花费了大部分时间在做的事情，就是牵头 MicroProfile Reactive 项目，以及创建 Reactive Messaging 和 Reactive Streams Support 规范。其中也包括一些编码工作（现在我着手实现 TCK for Reactive Messaging），以及利用邮件列表、GitHub 和每周环聊（Hangout）做大量的讨论。

此外，我还花了相当长的时间跟踪更广范围上的 MicroProfile 工作进展。其中包括，参加两周一次的 MicroProfile 社区聚会，以及积极参与邮件列表。近期我还参与了 CNCF CloudEvents 规范工作（参见 https://cloudevents.io/ ），因为它很可能将成为 MicroProfile Reactive Messaging 部分 API 的基础。我还参与了一些环聊活动、使用 GitHub 中的 PR 提交建议，以及在邮件列表和 GitHub 上开展大量的讨论。

InfoQ 还接触了 IBM，Red Hat，Tomitribe 和 Payara，征求它们在 MicroProfile 上成功开展合作的一些经验，尽管这些企业目前是竞争对手。

IBM WebSphere 和 Liberty 运行时架构师 Alasdair Nottingham 向 InfoQ 介绍：

对于 Liberty 开发团队来说，与竞争对手开展合作并非一件新鲜事。自从 20 年前首次发布 WebSphere（当初称为 Servlet Express）以来，合作一直是我们 DNA 的核心所在。当时，IBM 的 Java 软件总经理 Pat Sueltz 指出，“我们将在规范上开展合作，但会在具体实现上开展竞争”。这是我们从此以后一直在做的事情，无论是 J2EE、Java EE、CommonJ，还是现在的 Eclipse MicroProfile。

尽管我们一直在 API 和规范方面开展合作，但一直关注 Java 领域的人都知道，各个厂商间的竞争是非常激烈的，这对于业界和参与者而言是一件好事。如果没有竞争，那么现在就不会存在 Apache Tomcat、Spring Boot、Wildfly 和 Liberty，我们将会停留在 10 年前推出的一些重量级应用服务器上，Java 也不会成为当前云计算的强大平台。

对于那些不熟悉 Java EE（现在的 Jakarta EE）在过去 20 年中发展历程的人而言，所有这一切似乎很奇怪。但对我们而言，Eclipse MicroProfile 所带来的巨大差异并不在于我们是否应开展合作，而在于我们应如何开展合作。

在定义及实现 API 时采用开放开发模型，这使得我们可以快速地构建出适用于云原生 Java 的强大的新 API。我们并非总是能达成共识，但我们都具有一个共同的共同目标，即基于 Java EE 核心提供构建下一波应用的轻量级 API。

我认为，我们通过 Eclipse MicroProfile 所做的工作已表明，开放的 API 定义方法可以发挥非常有效的作用。Jakarta EE 项目正在以类似的开放方式推进。Jakarta EE 项目的形成方式，正受到 Eclipse MicroProfile 已实现工作的影响，此外还有其它一些考虑。

MicroProfile 开始加速对基于 Java EE 的通用云原生编程的采纳，这是对 Jakarta EE 的一种增值。Jakarta EE 必须在 Eclipse 基金会管理下对 Java EE 技术做重新调整，以成为一些开展中工作的起点。因此，Jakarta EE 的工作在继续，正在对我们已有的流程做现代化改造，并推进该平台。

在 Eclipse MicroProfile 继续定义新 API 的过程中，很多人对 MicroProfile 和 Jakarta EE 这两个项目的密切合作十分感兴趣，并充满期望。例如，将 Eclipse MicroProfile 作为 Jakarta EE 调用 API 的一个孵化器，或者只是作为两个相互独立但是互补的项目。我十分确信的是，Eclipse MicroProfile 和 Jakarta EE 不会发生冲突，两者的社区参与者之间具有太多的重叠。

Red Hat 高级中间件顾问 Mike Croft 告诉 InfoQ：

James 所说的 MicroProfile 的成功为 Jakarta EE 的运作方式提供了很好的指引，我认为这是完全正确的。事实上，尽管各家企业如 James 所指出的相互是竞争对手，但是来自各软件厂商的人都相互认识了很长时间，并且大家都明白在 Enterprise Java 上具有相同的成功目标。

MicroProfile 的核心是社区驱动。一切都是公开的，所以每个人都担当责任。在我看来，这一直是使 MicroProfile 取得成功的一个关键因素，也正是 Oracle 选择使用完全开放的方式来推进 Jakarta EE 命名和标识选择等工作的原因。

发布的策略，以及基于真实世界体验的更快速创新，这是 MicroProfile 能够产生巨大影响力之处。Java EE 通常采用多年发布一次主平台版本，而 MicroProfile 在提供每季度版本发布上取得了成功。版本发布的渐进式改进更容易适应市场，并尽快为开发人员提供新功能。Jakarta EE 将定义自己的发布策略，可借鉴 MicroProfile 在该领域的成功经验。

Tomitribe 的创始人兼 CEO David Blevins 告诉 InfoQ：

与 IBM、Red Hat 和 Payara 合作创建 MicroProfile，这一直是 Tomitribe 乃至我个人职业生涯历史中最令人自豪和最愉快的一个时刻。Oracle 通过提供大量出彩的和贡献的机会，持续支持着 Tomitribe。我们之间有着非常好的相互尊重，真诚希望彼此能够取得成功。作为一名 IBM 前员工，我也是 OpenLiberty 发布时发推文的欢呼者之一。当我们在 JavaOne 2011 上宣布 Apache TomEE 发布时，Red Hat 团队是首位参与我们庆祝的。

在我们这一行业中，竞争曾经不太友好。垃圾话、邮件战（flame war）和水军营销（astroturfing）曾比比皆是。我认为这在一个崭露头角的行业中十分常见，因为创新常被误认为是一种零和博弈（zero-sum game）。我们应该用时间去创新，而不是划分条条框框。真正的创新来自于将每个人所能提供的最好部分整合在一起。

Payara 创始人和企业管理者 Steve Millidge 告诉 InfoQ：

作为 MicroProfile 和 Jakarta EE 项目的一家小型挑战企业，令我感到惊讶的是大公司能与我们的团队平等共事。MicroProfile 和 Jakarta EE 工作在本质上涉及委员会、电话会议和取得共识。这可能会十分耗时，并且会令人沮丧。但所有企业的每个人都在共同努力，为将来能推出有用的、创新的和一致的 API。

Eclipse 基金会的工作，意味着其中具有良好的开源代码和参与规则，小公司和个人可以加入其中，并与大公司一样平等参与。对于那些对下一代基于标准的云原生 API 的发展感兴趣的企业或个人，我鼓励他们参与其中，并必将受到热烈欢迎。

InfoQ 也联系了著名的 Java 布道师 Reza Rahman ，他目前任 AxonIQ 的高级副总裁。InfoQ 希望他能从 Java EE Guardians 的角度分享个人经历。

实事求是地讲，Java EE 社区中一直存在着一种强烈合作的传统，至少自从我开始贡献 Java EE 5 和 Java EE 6 时代以来就是如此。就我所见，社区始终在维护专业氛围、建设性处理分歧、做出明智的妥协以及欢迎新加入者上做得很好。这些都是促成 Guardians 应运而生的因素。

现在最大的差异之处在于，Oracle（以及之前的 Sun）在所有权、路线图、功能和交付方面并不具有其多年来一直具有的畸形影响。MicroProfile 社区证明了中央驱动的影响实际上并不必要。参与 MicroProfile 的人也证明，厂商可以快速开展协作，并更快地交付功能。过去我们在 Java EE 中看到的拖沓情况，似乎的确是 Sun/Oracle 投资和承诺水平的一个表现。此外，显然 Jakarta EE 项目中的开放 TCK 是一个巨大的进步。

如果 Eclipse 基金会目前的模式能继续下去，那么所有这些事情对 Jakarta EE 来说都是非常好的。我希望如此。

相关资源

• James Roper ，“ Reactive Streams 对 Jakarta EE 有何影响？”，2018 年 2 月 6 日。
• Mark Brewer ，“支持 Jakarta EE 请求，加速云原生 Java ”，2018 年 4 月 24 日。
• Oliver White ，“ Lightbend 播客：Lightbend 为什么要加入 Eclipse 基金会的 Jakarta EE 工作组“，2018 年 5 月 7 日。
• InfoQ 新闻，“ EE4J 项目情况汇总，微软加入 Jakarta EE 工作组”，2018 年 5 月 15 日。
• Mike Milinkovich 的博客文章“ Jakarta EE 当前进展情况 by Mike Milinkovich ”，2018 年 5 月 24 日。
• Roxanne Joncas ，“ Jakarta EE 先睹为快 by Roxanne Joncas ”，2018 年 5 月 31 日。

查看英文原文： The MicroProfile Community Influence on Jakarta EE