@Rays 2018-06-28T17:07:23.000000Z 字数 8109 阅读 1827

MicroProfile社区对Jakarta EE的影响

语言开发 Java

摘要： 近期，James Roper荣升为Eclipse MicroProfile的提交者（Committer），他也因此成为Jakarta EE参与成员Lightbend的首位提交者。Roper是Lightbend的高级开发人员，也是Lagom微服务框架的创立者之一。Roper近期撰写博文分享了他成为提交者的经历，并介绍了MicroProfile社区对Jakarta EE项目的影响。InfoQ就此采访了Roger，并接触了一些供职于其它企业的MicroProfile提交者。

作者： Michael Redlich

正文：

近期，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中所起的作用持怀疑态度，这是可以理解的。我要说的包括如下几个方面：

Jakarta EE已脱离了JCP和Oracle，不会再犯同样的错误。我相信，Eclipse为Jakarta EE设立的管治模式，在大型软件厂商角色和以价值为依据的贡献者角色这两者间取得了很好的平衡。前者投入了大部分的时间和资源开发与维护构成Jakarta EE的规范、实现和TCK（技术兼容工具包，Technology Compatibility Kits），后者来自于创新并驱动规范推进的贡献者。Lightbend能够如此轻松地从MicroProfile和Jakarta EE社区的完全门外汉，转而成为MicroProfile项目的牵头开发者，这一事实正是对此问题的最好证明。

正是Jakarta EE和MicroProfile所推行的开放式协作流程，使得基于标准的框架和API独具价值。在我为期不长的贡献社区期间，我学到了很多，包括我们的行业，以及人们在做的各种事情、对人们重要的事情、人们如何解决问题，以及一些仅局限于Lightbend而可能无法学习到的事情。

因此，我相信正在制定的MicroProfile规范将会青出于蓝而胜于蓝，因为它从我们在Lagom的经验中吸取了大量的经验，而这种更广泛的经验正在融入到规范制定过程中。我期待参与整个过程，并在Lagom中提供这些规范的实现。所以，我相信未来几年中，Jakarta EE和MicroProfile标准要优于任何一家软件厂商所能给出的标准。

在企业在逐步拥抱云技术的过程中，我认为对企业一个非常重要的要求是，应比以往任何时候都要避免出现“供应商锁定”的情况。以前，供应商锁定意味着被锁定到特定的应用服务器和数据库，而企业仍然控制着硬件。

现在，供应商锁定不仅局限于应用服务器，而是包括整个部署架构，从服务器到网络、操作系统、编排，当然还包括应用服务器和数据库。越来越多的云服务供应商推出了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来说都是非常好的。我希望如此。

MicroProfile社区对Jakarta EE的影响

相关资源

内容目录