BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Scott Delap 关注 0 他的粉丝 ,译者 宋玮 关注 0 他的粉丝 发布于 2008年5月27日. 估计阅读时间: 9 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。
两周前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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT