我不知道您怎么样,我在听到 “自由” 这个词时,我还会想到 “选择的自由”。我怀疑我将一个词与另一个词联系了起来,因为在大学时(很久以前),我学习了经济学历史课。一位古典经济学家就是 John Stuart Mill,他是只有市场的支持者,而且常常在其经济论述中提到 “自由” 和 “选择自由”。显然,Mill 先生的著作给我留下了深刻印象,因为多年以后我还会回想起这个词,而且正是我的这方面背景引出了本文标题中提到的问题。(另外,为了避免误解,我与多年以前的 Mill 先生不是一个时代的 - 这是一门经济学历史课,而不是当代经济学课。这需要说明一下。)
不管怎样,IBM WebSphere Application Server Liberty Profile 于 2012 年中期推出后深受欢迎,而且 Liberty Profile 中越来越庞大的功能清单导致一些人反复向我寻求建议,以确定 Liberty Profile 是否是正确的选择。深入分析进行选择时应考虑的因素之前,有必要简要介绍一下 IBM WebSphere Application Server “完整” 配置文件和 Liberty Profile。
回页首
配置文件是在 IBM WebSphere Application Server V6.0 中引入的,提供来将 WebSphere Application Server 二进制程序与 WebSphere Application Server 运行时配置分开。提出配置文件的动机是消除针对部署管理器、节点代理和应用服务器进行多次单独安装的需要,多次单独安装会在一个物理服务器上产生多个二进制程序集。配置文件使您能够对二进制程序执行单次安装,然后使用 Profile Management Tool 或 manageProfiles(.bat/sh) 脚本创建一个或多个 “配置文件”,所有配置文件都使用一组相同的二进制程序。这消除了在每个服务器上安装和批处理多组二进制程序的需要,同时还节省了磁盘空间。WebSphere Application Server V6.0 上最初有 3 个配置文件:Deployment Manager、Application Server、Custom(没有预先构建的应用服务器的节点代理)。WebSphere Application Server V6.1 和 V7.0 中添加了更多的配置文件:Enterprise Proxy Server、Job Manager、Admin Agent、Secure (DMZ) Proxy Server。
随着逐年的发展,Java EE 6 引入了术语 “Web 配置文件”,该术语在 规范 中定义为 “Java Platform, Enterprise Edition 的一个专门针对 Web 应用程序的配置文件” (至少在我看来,这是一个循环定义;就我个人而言,我始终使用 “为 Web 应用程序采用的 Java EE Platform API 子集” 来更准确地定义 Java EE Web 配置文件,而不重用 “配置文件” 这个词来描述该配置文件)。
同样让人好奇的是(至少对我而言),事实上 Java EE Web Services API(JAX-WS、JAXB 等)不是 Java EE Web 配置文件的一部分,但 Web 配置文件规范确实指出它是 “Servlet 规范中新的可插拔特性,使应用程序能够使用库来通过极小的配置开销扩展 servlet 容器”,然后表明 JAX-RS 是一个未包含在 Web 配置文件中、“可插入到 Web 容器中” 的 Java EE API,所以可以推测 Web 服务将以类似的方式表述。
无论如何,Java EE Web 配置文件也是 Java EE 7 规范的一部分(或子集),所以似乎它会留在其中,至少在可预见的未来是如此。另一个值得注意的地方是,Java EE 7 Web 配置文件需要 JAX-WS;它不再是一个 “可插入” 选项,就像 Java EE 6 Web 配置文件中一样。
最后,在 WebSphere Application Server V8.5.0 中引入了 Liberty Profile,尽管 Liberty Profile 实现了二进制程序与配置的分离,但它基于一组不同的二进制程序采用了一种不同的配置模型。但不同于以前的配置文件,术语 “Liberty Profile” 同时包含配置和二进制程序。因此,向配置文件词典中添加了另一个术语,使用了短语 “完整配置文件” 来表示 Liberty Profile 推出以前的 WebSphere Application Server 运行时。
当然,因为 Liberty Profile 采用了一组与以前的 WebSphere Application Server 版本不同的二进制程序和不同的配置模型,所以可以说 Liberty Profile 完全不是配置文件,至少在习惯上的 WebSphere Application Server 定义中不是这样。但它已名声鹊起,我们只能希望 WebSphere 和 Java 社区会在未来需要时找到另一个名词。
事实上,当 WebSphere Application Server V8.5.5.0 中添加 Liberty Profile 的第二个配置选项时,没有提到 “配置文件”,这个基于 Liberty Profile 的管理流程称为集合控制器 (Collective Controller),最初的 Liberty 配置选项简单地称为 “服务器”。
最后,尽管同样是配置文件的主题,但 Liberty Profile 的不同且简化的配置模型支持通过向 Liberty Profile server.xml 文件添加一行来 “创建配置文件”,消除了 WebSphere Application Server 完整配置文件中对配置文件管理工具或脚本的需要。
回页首
自推出以来,Liberty Profile 一般被认为是一个开发运行时,这是由于它轻量的内存占用和快速的启动,二者都是需要在开发过程中频繁部署新应用程序版本的应用程序开发人员高度关注的。此外,推出时提供的容器服务和特性在很大程度上更适合开发用途。因此,人们常常会误认为 Liberty Profile 仅适合开发,而事实上 Liberty Profile 过去(和现在)也适合生产用途;事实上,在 Liberty Profile 推出几个月后就有一个客户将其引入到他们的生产环境中。
尽管许多人可能对此感到惊讶,但不应该惊讶。投资 Liberty Profile 的决定是客户的 系统管理和运营小组请求的结果,而不只是开发人员 - 回想十几年前的 WebSphere Application Server V4.0,它是一个仅能为从应用和操作角度讲需要的特性和功能配置的组件化的应用服务器运行时。
这些年来,这些请求的频率和紧急程度不断增加。WebSphere 开发团队在 WebSphere Application Server 6.0、6.1、7.0 和 8.0 版中投入了巨大的精力,通过删除各种容器服务之间的依赖性,仅在需要时启动容器服务,并添加其他一些优化,让完整配置文件变得 “更加轻量”。尽管取得了进步,针对完整配置文件的 Java EE 架构阻碍了这方面的进一步改进。WebSphere Application Server Liberty Profile 采用了一个新的基于 OSGi 的架构,其中每个容器服务和运行时特性实现为 OSGi 包,实现了一个针对开发和生产环境 “量身订造的” 运行时。OSGi 架构和将特性作为 OSGi 包提供,还有助于增量发布(通常称为持续交付)新特性和功能,无需像 WebSphere Application Server 完整配置文件仍然需要的那样等待主要版本。
当前对 Liberty Profile 的重点投资既反映了我们提供新特性而不等待新主要版本的能力,也反映了对目前只有完整配置文件中才有的更多特性的需求(例如,SAML、VMM/ 连锁存储库、证书分发、健康管理、应用程序版本管理等)。此需求来自我们的客户群,包括外部和内部客户;据最新统计,150 多款 IBM 产品嵌入了 Liberty Profile。
回页首
IBM WebSphere Application Server 完整配置文件仍然是 IBM Systems Middleware 产品组合的核心。IBM 继续在兔肉孜开发完整配置文件,以应对客户采用水平和基于传统 WebSphere Application Server 版本的基础架构投资。此外,我们继续在接受且优先考虑要求对完整配置文件进行更新和提供新功能的 RFE(增强请求)提交,即使完整配置文件架构中交付的新特性必须与主要(集成)版本绑定。
今年初的发展方向陈述给出了我们对 WebSphere Application Server 完整配置文件投资的证据(参见参考资料):
IBM 打算证明 WebSphere Application Server 与 Java EE 7 完整平台保持一致。WebSphere Application Server 通过持续交付模型在 WebSphere Liberty Repository 中提供 WebSphere Application Server Liberty Profile 特性,在此方向上取得了巨大进步。WebSphere Application Server Liberty Profile 的目的是使用此方法完善与 Java EE 7 完整平台的一致性。此外,证明 WebSphere Application Server 完整配置文件与 Java EE 7 完整平台保持一致仍然是 IBM 的目标。”
简言之,肯定没有暂停对 WebSphere Application Server 完整配置文件的投资或功能交付的计划。
回页首
一个容易与 Liberty Profile 混淆的产品是 Liberty Core。许多人错误地将 Liberty Profile 单独地与 Liberty Core 联系起来。尽管 Liberty Profile 随带了 Liberty Core 的表述是准确的,但一定要认识到 Liberty Profile(和完整配置文件)也包含在 WebSphere Application Server 中 – Express、WebSphere Application Server、WebSphere Application Server for Developers、WebSphere Application Server Network Deployment 和 WebSphere Application Server for z/OS。
这个包如图 1 所示。
图 1. WebSphere Application Server V8.5.5 配置文件产品
在该图中可以看到,现有的 WebSphere Application Server 用户在一个包中同时获得 Liberty Profile 和完整配置文件。只有购买 Liberty Core 的用户仅能获得 Liberty Profile 安装镜像。
上述每个产品中的 Liberty Profile 的区别:
图 2 中给出了与每个产品关联的特性。
图 2. 不同产品的 Liberty Profile Jave EE 6 特性
点击查看大图
关闭 [x]
回页首
阅读过我之前的文章的读者已知道我对此问题的回答:视情况而定。我将把不同部署和操作选项的更详细讨论推迟到以后,但现在会借此机会提供一些建议的起点。
由于 Liberty Profile 的轻量资源占用和快速启动时间,这可能是一个 “轻而易举的” 操作,这将是您的开发人员更高兴且更高效。在此场景中,在 Liberty Profile 容器与完整配置文件容器中之间提供的容器保真度保证,意味着两个配置文件上的容器从应用程序角度讲将具有相同的功能。开发人员可首先在其开发环境中使用 Liberty Profile,而正式的集成、测试和生产环境继续利用现有的 WebSphere Application Server 完整配置文件技能和基础架构。
因为 Liberty Profile 提供了完整配置文件中的部分 API,所以您需要回答问题 “这个应用程序能否在 Liberty Profile 中运行?”幸运的是,一些工具可以帮助完成此评估:
Liberty Profile 中最近提供的 Java EE 7 还意味着,开发人员可开始开发使用 Java EE 7 API 的应用程序,然后在完整配置文件上提供了 Java EE 7 时,可将新 Java EE 7 应用程序部署到完整配置文件上的生产环境。
辅助生命周期管理是 WebSphere Application Server Network Deployment V8.5 中引入的一个智能管理特性,它支持在 Network Deployment 单元中对中间件服务器(即非 WebSphere Application Server 完整配置文件服务器)进行操作控制和监视。使用此功能,您可以使用现有的 Network Deployment 完整配置文件技能和基础架构来获得 Liberty Profile 服务器的操作体验。Liberty Profile 服务器已添加到 Network Deployment完整配置文件单元中,它们支持从 Network Deployment 部署管理器来启动 / 停止、路由请求和监视。
还存在其他各种各样的选项,既包括单独管理每个 Liberty 服务器,也包括使用 Liberty 集合控制器作为单一管理点,但因为其他这些选项需要详细讨论 Liberty Profile 配置和管理架构,所以我们推迟到以后讨论它们。但是,正如宣传的那样,需要知道 Liberty Profile 不仅为开发人员提供了自由,还为管理员也提供了自由。
回页首
本文的目的是澄清一些有关 Liberty Profile 的常见误解,以便您可开始合理地评估它是否适合您的企业。希望我在这方面获得了成功。当然,还有许多因素要考虑,而且我很快会返回来讨论其他(生产)选项,基于您的应用程序和操作需求来进一步帮助您确定 Liberty Profile 是否是您所需要的。