新闻

该内容已经被标记书签！

标记书签错误，请重试！

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

作者 Scott Delap 译者宋玮发布于 2008年5月26日

领域: 运维 & 基础架构,; 语言 & 开发
主题: 应用服务器 ,; Java
标签: Spring框架

分享到

两周前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应用