10个问题教你如何抉择:是否为项目引入<mark>OSGi</mark>

OSGi的主要精力都集中在模块化,而且就目前来说(未来可能会改变)。你的应用分拆成一个个模块,是唯一可行的模块化方法。但是,它“仅仅”解决了技术问题的”唯一“,实际上也是比较容易的。在你想把OSGi引入到你的项目之前,请回答下列问题:

  • 模块(bundles)的版本控制方案是什么?是否关心主要版本、次要版本等信息?
  • 软件配置管理策略是什么——是否打算为模块的每个版本创建和维护一个代码分支?打算维护多少个代码分支?(是用svn 还是用什么?:-))
  • 产品中将会同时运行多少个版本化的模块?
  • 该系统将如何进行测试呢?这包括每个模块的单元测试和模块的集成测试。每一个版本都将显著增加测试的复杂性。
  • 发布管理策略是什么?是否真的打算提供可以让客户定制的模块组合吗?bug修复/补丁策略是什么(主干,分支还是其他什么方式)?
  • 是否需要系统在运行的时候可以对模块进行热插拔?如果它是一个服务器端的系统,在飞行事务(in-flight transaction)的情境下会出现什么情况?
  • 如果它是一个Eclipse富客户端应用程序——是否甚至允许将插件公开给终端用户?(在很多项目中的开发过程中都是禁用Update Manager的)。
  • 软件分发系统是什么——许多企业已经配置了一个软件分发系统。常常除了应用程序,连JVM都一起打包进一个二进制文件里并且完全安装,这种情况下增量更新往往是不可能的。
  • 究竟模块之间的具体协议是什么?仅仅是一组Java的接口?如果是这样的,如何处理JPA实体之间的直接关系?如果您不允许直接的JPA的关系,你可能会看到一个巨大的(包含所有域对象)“域”的包。您也不得不提供一种模块之间的“朋友”关系。
  • 是用maven 作为模块的规范表示形式,还是 OSGi,或者两者一起使用呢?最好只使用其中的一种。所以你需要确认Maven上的模块版本是否会反映在 OSGi bundle的版本里。

OSGi最大的挑战不在于技术,而是对模块和bundle的管理。这和SOA的问题是非常相似的。

对于大多数企业应用程序,你都只会做出一套业务逻辑,甚至只有一套UI。所以,你往往会在做出这些模块以后开发就结束了,然后这些模块再也不需要被替换(因为你只有也只需要有一套)。而且你很可能就整体测试一次就交付整个系统,因为OSGi的引入带了额外的复杂性。

如果你正在构建一个IDE,平台或服务器,其中的管理,模块化和版本控制将是你问题域需求和功能性需求的主要组成部分。届时你将不得不解决这个问题。比如就服务器而言,极有可能会有人需要给应用程序服务器安装新的驱动程序,甚至是在同一时间维护不同版本的驱动程序。而IDE一般来说也都是带有插件的,极少能见到不带插件的IDE。

此外,在商业应用程序中替换算法是也是相当少见 - 甚至往往是不允许的。如果在这种情况下你引进一个模块化的解决方案却发现不被允许不使用它,那不是很傻吗?


原文:http://www.adam-bien.com/roller/abien/entry/how_to_kill_an_osgi


wmz 2015-12-31 14:42

OSGi最成熟、最优秀的开源开发平台是JXADF,官网提供了大量案例演示,可访问:http://osgi.help

顶(0) 踩(0) 回复

最受欢迎的文章

最新评论