OSGI---目前我决定放弃使用她

OSGi是什么

    OSGi是一种服务运行平台。通过实现能够提供服务的符合OSGi规范的组件，用户可以将其组件发布到OSGi运行平台，供用户和其他组件使用。OSGi组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为Java接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

 

记录下传统和osgi方式的开发方式的特点：

传统方式的开发 ：
开发时，要引入整个依赖包。
整个系统为一个工程，里面包含了各个功能模块。（假如不使用像maven之类的工具管理模块依赖的话，在eclipse中开发确实是个比较头疼的问题）

osgi方式的开发 :
模块的依赖，只需要引入使用到的接口。不需要引入整个bundle。（基于eclipse 的插件开发就是这种类型）
只需要将bundle部署到服务器上，即可为系统增加相应的模块
支持热拔插（其实这个功能，虽然很好，但是对于企业级开发，感觉意义不大。对于嵌入式那就另当别论了）

osgi在很大的部分上也是对模块的管理，开发都是基于服务的，我觉得这样很好，不过目前来说，我觉得在企业级应用里面使用还是为时过早。目前使用的maven 加 soa的方式已经可应对大多问题了。

所以我最终决定目前放弃使用osgi： 

考察了osgi很久，最终决定放弃使用该技术作为zog平台的模块管理框架。还是使用目前使用得很多的maven + soa进行开发。主要有以下考虑：
1.osgi 目前不成熟。特别在B/S方面，因为大多数应用服务器都不支持osgi，这样让部署很困难，而且目前已有的解决方案也不好。osgi是底层的，我认为他应该在服务器级提供实现，或者jvm级实现。给应用层增加一层OSGI是不明智的。
2.maven管理模块的依赖目前还是很成熟了。maven的模块管理是传统意义的管理，即把包作为jar包导入引用工程。由于maven强大的包管理功能，使得包依赖问题得到了解决。光从开发这点上osgi没有明显的优势，因为在基于osgi开发中，要引用其他包，必须在eclipse中把这些作为一个个工程打开，其他工程才能引用它们（想想假如你有100个bundle的情况，就可想而知！）。
3.假如光把osgi作为zog平台级开发使用，而在开发具体项目时采用普通开发模式，咋样呢？依据我目前掌握的osgi知识来看，我不赞同这样。首先问题的原因也如同刚刚2所提到的，同时也考虑到zog平台打包的问题。你想想，bundle是按照功能来创建的，为了管理这些小东西，也会打开很多的模块工程。很麻烦。
4.以后等osgi成熟了，转换过程也很简单。不过前提是要对架构设计好才行。