领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
OSGi适合作为Java中间件的基础么？
作者 Jean-Jacques Dubray 译者 王丽娟 发布于 2010年11月29日
OSGi（JSR 8）工作组成立于1997年，主要关注嵌入式Java，以支持嵌入式软件的模块化升级。在成功解决了Eclipse插件不可避免的依赖关系之后，OSGi成为主流。大概在2005年，好几种方法都开始利用装配机制和定义良好的依赖关系在企业Java中引入更进一步的模块化，其中包括Spring和服务组件体系架构，而EJB却慢慢消失了。现在，大多数企业Java厂商都在OSGi的基础上重写了他们的中间件。
但OSGi技术也让很多人觉得懊恼，MuleSource的创始人Ross Mason前几天就在他的博客上毫不掩饰地对此发表了议论。
OSGi想要改变一切，依赖关系会完全隔离（不再受制于冲突的依赖关系版本），而且会严格要求Bundle彼此可见。和很多人一样，我就这样买了OSGi的账，让我们的工程人员改造Mule、让它支持OSGi。
我们的团队有好几个月都在Manifest上扯皮、打包自己的Bundle、无休止地摆弄构建，OSGi的优势在这之后变得越来越弱。我们认同“不劳无获”，但后来这却成了作茧自缚。
Ross的工程团队不知道如何向中间件开发人员隐藏OSGi的复杂性。他认为这个问题是由OSGi的起源——嵌入式——造成的。
OSGi对中间件厂商来说是个很棒的规范，……但OSGi绝不是为了应用开发人员的需求才创建的。它的起因是，在用户不干预的情况下远程更新部署在机顶盒里的软件。OSGi对这类软件的部署来说是个很好的规范，因为只有中间件厂商才需要处理Bundle的部署。
模块化和版本化是中间件项目的两个核心问题。服务实现经常会发生变化（有时每个季度就会改变一次），而大型组织过去也常把所有的服务部署在一个ear文件中，每过三个月，就算ear中的很多内容从未发生变化、也不依赖于新的或更新过的服务，消费者和服务提供者还是要进行一次大规模的同步，更别说还要一直测试所有的服务了。有人可能会说， 缺少模块化和版本化正是SOA失败的原因所在。Ross补充说：
OSGi承诺会对软件堆栈进行模块化，并让中间件基础设施即插即用。遗憾的是，有些Bundle就没有兑现这样的承诺，这些Bundle跨容器之后就不能以相同的方式正常运行了。
Ross认为OSGi背后的原则正好适用于永久异构的堆栈。但他说：
既然OSGi现在主要针对普通的应用开发，那就要重新思考一下它的用户交互部分。从实际情况来说，不用OSGi也可能在JVM上做到模块化和热部署，但OSGi日常开发的痛苦却比它具备的优势多多了。
Neil Bartlett对Ross作出了如下的回应：
bnd之类的工具已经对开发人员隐藏了OSGi的细节。我认为现在的问题是，基于OSGi进行开发的替代方法和工具过于泛滥。我仍然相信，不用OSGi进行日常JVM开发会比任何短期利益都要痛苦……你上次手工编写.class文件是什么时候呢？也许你永远没手工写过，只是编译Java源文件来生成。OSGi的MANIFEST也是类似的内容，它应该是类编译器工具的输出。
Joe Sampson从测试和构建的角度分享了他使用OSGi的经验，这些经验都是他发现不太容易使用的部分。Hani Suleiman指出：
OSGi在概念层次上是个很好的模型，只是被那些本身不支持它的语言给拖累了。大家不愿意使用不支持OSGi的语言，这就意味着OSGi永远都是个令人讨厌的笨拙的框架，没有人会真正喜欢用它（据我所知，如果你经常使用OSGi，那你的体验显然会不一样）。
Richard S. Hall也提出了一点儿忠告：
如果你开始使用OSGi，期望所有遗留的JAR包都能正常工作，还想尝到模块化的甜头，那你还不如不尝试。这跟二十世纪八十年从C切换到C++有几分相像，那时人们希望所有内容都能自动变成面向对象的。
WSO2的CTO Paul Fremantle在给Ross的回应中解释到，WSO2 Carbon不仅是基于OSGi构建的，还完全向开发人员隐藏了OSGi的细节。Paul承认这并不容易，但用自己的构建方式实现模块化、版本化和配置却要更难一些。
你对OSGi持什么看法？你有没有遇到什么困难？OSGi对你来说是透明的么？你的中间件是否充分模块化，且支持一流的版本控制策略？就像Hani所指出的，现代架构的核心问题往往是缺少语义、架构的语义与底层编程语言的语义不匹配，难道我们就要因此将这个架构打入地狱么？
查看英文原文：Is OSGi the Right Foundation for Java Middleware?
译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。
属于设计的问题，为什么指责OSGI？
发表人
叶 余
发表于
OSGi非常适合作为中间件基础
发表人
景 志刚
发表于
设计，还是设计
发表人
Zeng Abrams
发表于
-
OSGI中关系依赖、接口声明、包的导入导出本来就是在设计阶段就应该做好的，为什么职责OSGI？
我觉得OSGI挺好用的，在插件化开发、相互隔离上做的很棒，
在大项目的开发商简直是无往不利！ -
OSGi非常适合作为中间件基础。
但是，再将你已有的软件包转化为Bundle时，难点不在构建过程，而是需要重新思考现存的设计有哪些问题。一些常见的实现策略中，也存在被人们忽视的问题。那些大量使用类属静态方法实现应用级别功能、获取应用配置资源的代码，虽然在传统的开发中起到了简化、清晰代码的作用，但在转换为Bundle时后可能会引入混乱。 -
在用传统的方式进行设计时，就算不考虑太多关于接口、包隔离、模块隔离、依赖关系都可以做一个能运行良好的系统，把功能加上能跑就好。但OSGi却要强迫人们先拿出一个良好的设计再说，很多设计者缺乏这方面的经验，难受是自然的。
3 条回复
关注此讨论 回复