针对许可证、OSGi、以及 SpringSource 应用平台技术现状的反应

两周前 InfoQ率先报道了SpringSource 应用平台beta 版的发布。我们的报道引发了剧烈的讨论，在 The Server Side 上的报道同样也引发了众多讨论。在过去的两周里，开发者及业界权威的评论焦点集中在两个方面：许可证 / 一般战略以及 OSGi/ 技术的实现。

许可证及一般策略

在如此之多的评论中，人们既可以找到赞同的声音也可以找到反对的意见。Impala 项目（该项目提出了一个类似于 Spring-DM 的解决方案，采用的是 Apache License 2.0 许可证）的 Phil Zoio 在博文中这样写道：

……本质上是 Spring OSGi 的强大集成。我已经表明了我的关切：与应用服务器厂商相比，普通开发者能在多大程度上接受 OSGi。一直以来，总是有人说服我说：普通的 Java 开发者都将对 OSGi 特质表现出极大的热情……有一个许可证的问题。第一次，SpringSource 推出的主要产品使用了非 Apache V2.0 的许可，取而代之，其使用了 GPL 许可证。这种主要变化反映了该公司对自己在市场定位方面的改变……最终，在我脑海中盘旋的一个问题是 Spring 框架本身如何适应这种变化。我一直认为 Spring 框架是出自 Rod Johnson 的旗舰产品……但是对于 Spring 应用框架，他们下了重注……

相反，Per Olesen 看上去对这一产品和许可证表现出极大的热情：

……我已经把 spring 框架作为我使用的主要引擎，而且在 POJO ORM 道路上走了很长时间了。远早于 JEE5 和 JPA。而且我喜欢这种方式。在新产品上，我甚至放弃了 JEE5 EJB，因为我发现在许多方面 spring 模型更胜一筹。至于说它正在走向非公开化，这个平台使用的是 GPLv3 许可，我很喜欢。在我眼里，GPL 许可正好适合这类产品。它既确保了开放性，又能被他人所利用……

IBM 的 Billy Newport 从应用服务器厂商的视角提出一些意见：

……这看起来像是我和他人准备在下几年计划 / 希望要做的事情。我们大都在寻找一个具有商业友好许可的（EPL、BSD 或 Apache）基于 OSGi 的分布式平台……总之，我不认为这个平台有价值。我认为它是件商品而已。我认为 profile 和监控 profile 是有价值的东西，我更愿意看到一个具有商业友好许可的 OSGi 分布式运行环境，将它作为厂商构建中间件 /profile 的新的 JVM。假如 Spring DM 是 Apache 许可的，我就会认为在 Spring 服务器上所作的额外工作是纯净的，很快就可于以 EPL 或 Apache 许可证使用，而这将会限制出售 SpringSource 服务器的价值……我并不想贬低 SpringSource 所做的一切，它确实很好也是必须的，但是假定它的大部分组件是 Apache2.0 或 EPL 的许可，那么最终的隔阂比构建一个 Java EE 或 BPEL 流程引擎要简单的多，就这些。

IBM 的 Jerry Cuomo也作出了评论：

……InfoQ 上的一篇文章带来了这则消息之后，我的收件箱里就充满了邮件。标题行这样写道——“SpringSource 向 WebSphere 宣战”。真的吗？我不这么认为。我是一个 Spring 迷，我认为 OSGi 基础和 Spring 框架这样的技术是基于 Java 应用服务的未来形式。适用于所有服务器的那种放之四海而皆准的方式已经逐步进化为针对特定类型工作负载构建专门的服务器……现在，我觉得 SpringSource 变质并在 GPL 许可下做这件事是可耻的。业界将从 Apache 许可的“参考”应用平台中获益……因此，进化为合适大小、能满足多种个性需求的平台的趋势并不会引发混乱，更不是 SpringSource 和 WebSphere 之间的一场决战——这只是业界进化的方式——或许 Java 社区可以像以前那样齐心协力，制造公平的竞争机会。我们的客户十分赞赏这一点……

最终，Marc Fleury（JBoss 创始人）的深思对众多的反应进行了总结：

事实是，我有点关心但是又不太关心。在我看来这是风险投资驱使的结果。作为一个开发框架，Spring 是一个天生的顾问，但是他们在运转过程中一直与他们的销售不断奋斗。瞧，我们现在有一个画在 OSGi 核心周围的方框……最后，我不知道这会对它与其它应用服务器的关系产生怎样的影响。他们不再中立……大伙瞧瞧，应用服务器大战曾经打响并在 2005 年结束了。现在是 2008 年了，到处都是 POJO 编程，EE 编程模型被淡化了。

OSGi 和技术现状

在对所期待的战略进行说明的同时，SpringSource 应用平台宣布也对来自众多活跃在 OSGi 社区的开发者进行了回应。 Neil Bartlett 给出了许多积极的评价，包括：OSGi 的常规使用、已宣布的 bundle 库、以及 SAP 解决了在哪里启动 OSGi 的问题。可是，他也关注新的 bundle header：

……现在，这儿有些让我紧张的事情……有两个新的 bundle headers：Import-Bundle 和 Import-Library。在我看来，Import-Bundle 与 Require-Bundle 存在同样的问题。这一新的 header 只是提供了间接引用（例如，你提供一个逻辑 bundle 名，而不是真实的 Bundle- 符号名——Bundle-SymbolicName）。这并没有修正关于绑定到一套 package 周围的 wrapper 上而不是 package 本身这个问题。Import-Library 看起来更糟，它会在整套 bundle 上立即执行 Import-Bundle！……

Peter Kriens 有着类似的想法：

……总而言之，bundle 仓库非常好。……这个 bundle 仓库必须要做一个艰难的工作。名誉！……然而，SpringSource 应用平台是一种冲击。从文档中，我发现了很多感觉像是 OSGi 的 headers，但是我并不承认，包括：Import-Library、Import-Bundle、应用等等。看起来 SpringSource 已经全面“改良”了 OSGi……

SpringSource 团队也发表了几篇博文，详细描述了应用程序平台的不同方面：

使用 SpringSource 应用平台在 OSGi 上运行 Spring 应用

• 装载时编织（Load Time Weaving）
• Classpath 扫描
• 线程上下文类装载器管理

SpringSource 应用平台开发选项

• 原始（Raw）OSGi Bundles
• Java EE WAR
• Web 模块（Modules）
• 平台存到文件 (PAR)

SpringSource 应用平台 Manifest Headers

• Import-Bundle
• Import-Library

使用 SpringSource 应用平台的供应库（provisioning repository）

• 运行时供应（Runtime provisioning）
• 给供应库中增加项目
• 在不同安装之间共享供应库

SpringSource 应用程序框架的一个主要好处是，它有按需供应依赖能力。这个好处有两方面作用：它确保了平台内存占用尽量小；不需要把所有依赖都封装到一个部署个体中（例如，一个 WAR 文件）就可以部署。为了利用这些能力，你将需要理解平台的供应库和本博文将要提供的信息……

查看英文原文： Reactions to Licensing, OSGi, and Technical Aspects of the SpringSource Application Platform