|
随着开源文化的日益普及参与开源似乎也变成了一种时尚一时间似乎大家都乐于把自己的代码拿出来分享了就在新年前夕我的一位老朋友一位向来对开源嗤之以鼻的JEE架构师竟然也发布了一个开源的JEE应用框架（姑且称之为X框架）不得不令我惊歎开源文化的影响力之强大 可惜开源并非免费的午餐把源码公开就意味着要承受众目睽睽的审视仅仅几天之后国内几位资深的JEE架构师就得出一个结论细看之下X框架不管从哪个角度都只能算一个失败的开源项目究竟是什么原因让一个良好的愿望最终只能得到一个失败的结果？本文便以X框架为例点评初涉开源的项目领导者常犯的一些错误指出投身开源应当遵循的一些原则为后来的开源爱好者扫清些许障碍 成熟度 打开X框架在SourceForge的项目站点我们立刻可以看到在Development Status一栏赫然写着 ? Production/Stable也就是说作者认为X框架已经成熟稳定可以交付用户使用那么现在对其进行评估便不应该有为时过早之嫌可是X框架真的已经做好准备了吗？ 打开从SourceForge下载的X框架的源码包笔者不禁大吃一惊压缩包里真的只有源码??编译运行整个项目所需的库文件全都不在其中从作者自己的论坛得知该项目需要依赖JBossJDOMCastorHibernate等诸多开源项目笔者只好自己动手下载了这些项目好一番折腾总算是在Eclipse中成功编译了整个项目 不需要对开源文化有多么深刻的了解只要曾经用过一些主流的开源产品你就应该知道一个开源软件至少应该同时提供源码发布包和二进制发布包源码包中至少应该有所有必需的依赖库文件（或者把依赖库单独打包发布）完整的单元测试用例（对于Java项目通常是Junit测试套件）以及执行编译构建的脚本（对于Java项目通常是Ant脚本或者Maven脚本）但这些内容在X框架的发布包中全都不见蹤影用户如果想要使用这个框架就必须像笔者一样手工下载所有的依赖库然后手工完成编译和构建而且构建完成之后也无从知晓其中是否有错误存在（因为没有单元测试）这样的发布形式算得上是Production/Stable吗？ 开源必读便捷构建 开源软件应该提供最便捷的构建方式让用户可以只输入一条命令就完成整个项目的编译构建和测试并得到可运行的二进制程序对于Java项目这通常意味着提供完整的JUnit测试套件和Ant脚本你的潜在用户可能会在一天之内试用所有类似的开源软件如果一个软件需要他用半天时间才能完成构建而且还无从验证正确性无从着手编写他自己的测试用例这个软件很可能在第一时间被扔到墙角 从SourceForge的项目页面可以看到X框架的授权协议是Apache License V（APL）然而在它的发布包中笔者没有看到任何形式的正式授权协议文本众所周知SourceForge的项目描述是可以随时修改的（X框架本身的授权协议就曾经是GPL）如果发布包中没有一份正式的授权协议文本一旦作者修改了SourceForge的项目描述用户又该到哪里去寻找证据支持自己的合法使用呢？ 在X框架的源码中大部分源文件在开始处加上了APL的授权声明但有一部分源码很是令人担心例如UtilCache这个类开始处没有任何授权声明而JavaDoc中则这样声明作者信息 @author <a mailto:>David E Jones</a> 也就是说这个类的源码来自另一个开源项目Ofbiz值得一提的是Ofbiz一直是商业开源的倡导者它的授权协议相当严格凡是使用Ofbiz源码必须将它的授权协议一并全文复制像X框架这样复制Ofbiz源码却删掉了授权协议的行为实际上已经构成了对Ofbiz的侵权 另外作者打包用的压缩格式是RAR而这个压缩格式对于商业用户是收费的对于一个希望在商业项目中应用的框架项目来说选择这样一个压缩格式实在算不得明智而且笔者在源码包中还看到了好几个jbx文件这是JBuilder的项目描述文件把这些JBuilder专用的文件放在源码包中又怎能让那些买不起或是不想买JBuilder的用户放心呢？更何况出于朋友的关心笔者还不得不担心X框架的作者是否会收到Borland公司的律师信呢 开源必读授权先行 在启动一个开源项目时第一件大事就是要确定自己的授权协议并在最醒目的地方用最正式的方式向所有人声明??当然在此之前你必须首先了解各种开源授权协议譬如说GPL（Linux采用的授权协议）要求在软件之上的扩展和衍生也必须继承GPL因此这种协议对软件的商业化应用很不友好相反APL则允许用户将软件的扩展产物私有化便于商业应用却不利于开发者社群的发展作为一个开源项目的领导者对于各种授权协议的利弊是不可不知的 除了源码本身的授权协议之外软件需要使用的类库IDE解压工具等等都需要考虑授权问题开源绝对不仅仅意味着免费使用开源社群的人们有着更加强烈的版权意识和法律意识如果你的开源软件会给用户带来潜在的法律麻烦它离着被抛弃的命运也就不远了 可以看到不管从法律的角度还是从发布形式的角度X框架都远够不上Production/Stable的水准??说实在的以它的成熟度顶多只能算是一个尚未计划周全的开源项目虽然作者在自己的网站上大肆宣传但作为一个潜在的用户我不得不冷静地说即便X框架的技术真的能够吸引我但它远未成熟的项目形态决定了它根本无法在任何有实际意义的项目中运用要让商业用户对它产生兴趣作者需要做的工作还很多 我刚才说即便X框架的技术真的能够吸引我这算得上是一个合理的假设吗？下面就让我们进入这个被作者寄予厚望的框架内部看看它的技术水平吧 整体架构 在X框架的宣传页面上我们看到了这样的宣传词 X框架解决了以往JEE开发存在的诸多问题EJB难用JEE层次复杂DTO太乱Struts绕人缓存难做性能低等X框架是Aop/Ico[注应为IoC此处疑似笔误]的实现优异的缓存性能是其优点 下面是X框架的整体架构图 educitycn/img_///jpg >可以看到在作者推荐的架构中EJB被作为业务逻辑实现的场所而POJO被用于实现Fa?ade这是一个好的技术架构吗？笔者曾在一篇Blog中这样评价它[] 让我们先回想一下使用EJB的理由是什么？常见的答案有可分布的业务对象声明性的基础设施服务（例如事务管理）那么如果在EJB的上面再加上一 层POJO的Fa?ade显然你不能再使用EJB的基础设施了因为完整的业务操作（也就是事务边界）将位于POJO Fa?ade的方法这里所以你必须重新??以声明性的方式??实现事务管理安全性管理remoting缓存等基础设施服务换句话说你失去了 session bean的一半好处另一方面可分布的业务对象也不复存在因为POJO本身是不能??像EJB那样??分布的这样你又失去了session bean的另一半好处 继续回想使用基于POJO的轻量级架构的理由是什么？常见的答案有易于测试便于移植开发发布周期短而如果仅仅把POJO作为一层Fa?ade把业务逻辑放在下面的EJB那么你仍然无法轻易地测试业务逻辑移植自然也无从谈起了并且每次修改EJB之后必须忍受漫长的发布周期 即便是仅仅把EJB作为O/R mapping而不是业务逻辑的居所你最多只能通过DAO封装获得比较好的业务可测性但修改发布的周期仍然很长因为仍然有entity bean存在也就是说即使是往最好的方面来说这个架构至少损失了轻量级架构的一半优点 作为一个总结X框架即便是在使用得最恰当的情况下它仍然不具备轻量级架构的全部优点至少会对小步前进的敏捷开发造成损害（因为EJB的存在）并且没有Spring框架已经实现的基础设施（例如事务管理remoting 等）必须重新发明这些轮子另一方面它也不具备EJB的任何优点EJB的声明性基础设施可分布业务对象等能力它全都不能利用因此可以简单地总结说X框架是一个这样的架构它结合了EJB和轻量级架构两者各自的短处却抛弃了两者各自的长处 在不得不使用EJB的时候一种常见的架构模式是用session bean作为Fa?ade用POJO实现可移植可测试的业务逻辑这种模式可以结合EJB和POJO两者的长处而X框架推荐的架构模式虽然乍看起来也是依葫芦画瓢效果却恰恰相反正可谓是取其糟粕去其精华 开源必读架构必须正确 在开源软件的初始阶段功能可以不完善代码可以不漂亮但架构思路必须是正确的即使你没有完美的实现参与开源的其他人可以帮助你但如果架构思路有严重失误谁都帮不了你从近两年容器项目的更迭就可以看出端倪PicoContainer本身只有个类数百行代码但它有清晰而优雅的架构因此有很多人为它贡献外围的功能Avalon容器尽管提供了完备的功能但架构的落伍迫使Apache基金会只能将其全盘废弃 所以如果你有志于启动一个开源项目（尤其是框架性的项目）务必先把架构思路拿出来给整个社群讨论只要大家都认可你的架构你就有机会得到很多的帮助反之恐怕你就只能得到无尽的嘲讽了 技术细节 既然整体架构已经无甚可取之处那么X框架的实现是否又像它所宣称的那样能够解决诸多问题呢？既然X框架号称是AOP/IoC的实现我们就选中这两项技术看看它们在X框架中的实现和应用情况 IoC X框架宣称自己是一个 |
