OSGI好处体现在什么地方？代码组织工具？
锁定老帖子
主题：OSGI好处体现在什么地方？代码组织工具？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
- liusu
- 等级:
- 性别:
- 文章: 405
- 积分: 211
- 来自: 深圳
发表时间：2008-07-17
猎头职位:
北京: ITeye网站诚聘网站编辑
这几天看OSGI的specification，结合我们公司当前做的项目,发现OSGI更多的用于代码组织，原来一个项目分成很多个包，现在变成很多个bundle加很多个package，至于它声称的dynamic特性倒是没有发现被使用的很多。
我对它声称的东西还是很感兴趣的，最近有一个GUI的项目准备移植做成eclipse插件加feature的形式，需要使用OSGI的概念做一些改进。但是实在看不到除了在代码组织那一块，OSGI有更多的作用。 有点迷惑。
希望大家讨论讨论，如果有一些实际使用的例子最好，也欢迎给出好的学习文档和例子。
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
- drliujia
- 等级:
- 性别:
- 文章: 102
- 积分: 283
- 来自: 上海
发表时间：2008-07-18
插件可热插拔
- wolfbrood
- 等级: 初级会员
- 性别:
- 文章: 447
- 积分: 50
- 来自: 北京
发表时间：2008-07-18
liusu 写道
这几天看OSGI的specification，结合我们公司当前做的项目,发现OSGI更多的用于代码组织，原来一个项目分成很多个包，现在变成很多个bundle加很多个package，至于它声称的dynamic特性倒是没有发现被使用的很多。
我对它声称的东西还是很感兴趣的，最近有一个GUI的项目准备移植做成eclipse插件加feature的形式，需要使用OSGI的概念做一些改进。但是实在看不到除了在代码组织那一块，OSGI有更多的作用。 有点迷惑。
希望大家讨论讨论，如果有一些实际使用的例子最好，也欢迎给出好的学习文档和例子。
我对它声称的东西还是很感兴趣的，最近有一个GUI的项目准备移植做成eclipse插件加feature的形式，需要使用OSGI的概念做一些改进。但是实在看不到除了在代码组织那一块，OSGI有更多的作用。 有点迷惑。
希望大家讨论讨论，如果有一些实际使用的例子最好，也欢迎给出好的学习文档和例子。
关注osgi中，前段时间看了他的specification,不过没有细看。不过我感觉它所提倡的是，一个更好的模块组织方法，就是更加自由和方便。因为他们是按照规范写的组建。
- liusu
- 等级:
- 性别:
- 文章: 405
- 积分: 211
- 来自: 深圳
发表时间：2008-07-18
drliujia 写道
插件可热插拔
对“插件的热插拔”一直是OSGI声称的，但是以eclipse为例，每次安装插件的话都需要重启Eclipse，这跟热插拔的概念好像不是很符合吧。
另外，其实因为我最近一直都在做Eclipse插件方面的工作，可能视野有限。OSGI在服务端可能有更好的应用例子。
- wl95421
- 等级:
- 性别:
- 文章: 324
- 积分: 693
发表时间：2008-07-18
Eclipse的热插拨概念与OSGI不一致
因为Eclipse的底层不全是OSGI标准
Eclipse的Plugin与OSGI的Bundle并不等价，Plugin包括一个Bundle+extension
而且有一部分插件是可以热插拔的
因为Eclipse的底层不全是OSGI标准
Eclipse的Plugin与OSGI的Bundle并不等价，Plugin包括一个Bundle+extension
而且有一部分插件是可以热插拔的
- wl95421
- 等级:
- 性别:
- 文章: 324
- 积分: 693
发表时间：2008-07-18
我将所写的文章摘要出来:
自Eclipse3.0开始，Eclipse就引入了OSGi作为底层内核，许多人也可能就以为Eclipse中的Plugin与OSGi的 Bundle两者是等价的。事实上Eclipse从来都没有放弃自己开发的整套Plugin机制，这两者也并不等价，其实Plugin是对bundle的 包含和扩展。
OSGi的Bundle是一个非常好的规范，它突破了Java中默认以包为封闭单元的不足，同时也赋予了模块化，以及生命周期管理，所以它更像一 个黑盒模块的规范。因为它的优秀，Eclipse才会选择它作为Kernal，但是它同样存在一个比较大的问题，所以Eclipse才将它的Bundle 机制加以扩展，以满足自己的需要，这就是它的Plugin。
作为一个黑盒的模块，每一个Bundle只要被显式调用的时候，才会运行，而且在运行前会检查并启动各种相应的依赖，最终进入运行状态。作为一个 类似于黑盒设计的Kernal，这样无可以厚非。但是对于Eclipse这样一个平台，这种机制并不能满足需求，下面给出一个这样的例子。
假设存在三个Bundle，分别是BundleA和BundleB以及BundleC，其中BundleB对BundleA是有依赖关系的，而BundleC与另外两个Bundle都不存在关系。那么现在来分析一下，分别启动这三个Bundle会有什么样的效果。
启动BundleA，因为它没有依赖别的插件，那么会顺利启动，但此时BundleB和BundleC仍然处于非激活状态。
启动BundleB，因为它依赖了BundleA，所以在进行检查以后，OSGi会先启动BunldeA，待前者启动完成后，再启动BundleB，此时，只有BundleC处于非激活状态，而BundleA和BundleB都处于激活状态。
启动BundleC，因为它没有依赖别的插件，那么会顺利启动，但此时BundleA和BundleB仍然处于非激活状态。
从上面的例子我们可以看出，每一个Bundle作为一个黑盒，它不提供扩展功能，只有在显式启动的时候，才会被处理，就象BundleA的启动对 BundleB是没有任何作用的。因此从OSGi的设计，规范等方面来看，它是无法满足Eclipse平台的扩展性需要。大家可以想象一下，如果 Eclipse的底层也是这种机制，就不会有插件机制，也就从根本上没有了扩展性，那么Eclipse的魅力就会被抹杀大半。
所以Eclipse社区做了一件聪明的事情，它将Bundle作为一个模块的划分体，然后在上面再加上一件马甲，就象一个USB设备一样，你可以 只连接到USB口，也可以再在本体上提供额外的USB接口，进行扩展。穿了马甲以后的Bundle，就是Eclipse的Plugin，而且这个马甲是非 常的漂亮，所以无论是开发人员还是用户都没有拒绝的理由。
因此Plugin的引入更多是为了处理Bundle间的扩展关系，否则偏向黑盒的OSGi是无法实现功能扩展的。
自Eclipse3.0开始，Eclipse就引入了OSGi作为底层内核，许多人也可能就以为Eclipse中的Plugin与OSGi的 Bundle两者是等价的。事实上Eclipse从来都没有放弃自己开发的整套Plugin机制，这两者也并不等价，其实Plugin是对bundle的 包含和扩展。
OSGi的Bundle是一个非常好的规范，它突破了Java中默认以包为封闭单元的不足，同时也赋予了模块化，以及生命周期管理，所以它更像一 个黑盒模块的规范。因为它的优秀，Eclipse才会选择它作为Kernal，但是它同样存在一个比较大的问题，所以Eclipse才将它的Bundle 机制加以扩展，以满足自己的需要，这就是它的Plugin。
作为一个黑盒的模块，每一个Bundle只要被显式调用的时候，才会运行，而且在运行前会检查并启动各种相应的依赖，最终进入运行状态。作为一个 类似于黑盒设计的Kernal，这样无可以厚非。但是对于Eclipse这样一个平台，这种机制并不能满足需求，下面给出一个这样的例子。
假设存在三个Bundle，分别是BundleA和BundleB以及BundleC，其中BundleB对BundleA是有依赖关系的，而BundleC与另外两个Bundle都不存在关系。那么现在来分析一下，分别启动这三个Bundle会有什么样的效果。
启动BundleA，因为它没有依赖别的插件，那么会顺利启动，但此时BundleB和BundleC仍然处于非激活状态。
启动BundleB，因为它依赖了BundleA，所以在进行检查以后，OSGi会先启动BunldeA，待前者启动完成后，再启动BundleB，此时，只有BundleC处于非激活状态，而BundleA和BundleB都处于激活状态。
启动BundleC，因为它没有依赖别的插件，那么会顺利启动，但此时BundleA和BundleB仍然处于非激活状态。
从上面的例子我们可以看出，每一个Bundle作为一个黑盒，它不提供扩展功能，只有在显式启动的时候，才会被处理，就象BundleA的启动对 BundleB是没有任何作用的。因此从OSGi的设计，规范等方面来看，它是无法满足Eclipse平台的扩展性需要。大家可以想象一下，如果 Eclipse的底层也是这种机制，就不会有插件机制，也就从根本上没有了扩展性，那么Eclipse的魅力就会被抹杀大半。
所以Eclipse社区做了一件聪明的事情，它将Bundle作为一个模块的划分体，然后在上面再加上一件马甲，就象一个USB设备一样，你可以 只连接到USB口，也可以再在本体上提供额外的USB接口，进行扩展。穿了马甲以后的Bundle，就是Eclipse的Plugin，而且这个马甲是非 常的漂亮，所以无论是开发人员还是用户都没有拒绝的理由。
因此Plugin的引入更多是为了处理Bundle间的扩展关系，否则偏向黑盒的OSGi是无法实现功能扩展的。
- johnnylzb
- 等级:
- 性别:
- 文章: 71
- 积分: 199
- 来自: 广州
发表时间：2008-07-18
OSGi是一种概念，它首先告诉我们，写软件的时候要把职责划分清楚，这是合理划分接口、类、包甚至是服务，组件的基础。
OSGi还有一个比较有用的地方，就是可以控制访问范围，这方面Java本身控制得不够细，比如我某个类只希望供某些指定的类使用，Java是无法做到的（Proptected只能供同包和子类用）。
OSGi还有一个比较有用的地方，就是可以控制访问范围，这方面Java本身控制得不够细，比如我某个类只希望供某些指定的类使用，Java是无法做到的（Proptected只能供同包和子类用）。
- liusu
- 等级:
- 性别:
- 文章: 405
- 积分: 211
- 来自: 深圳
发表时间：2008-07-18
johnnylzb 写道
OSGi是一种概念，它首先告诉我们，写软件的时候要把职责划分清楚，这是合理划分接口、类、包甚至是服务，组件的基础。
OSGi还有一个比较有用的地方，就是可以控制访问范围，这方面Java本身控制得不够细，比如我某个类只希望供某些指定的类使用，Java是无法做到的（Proptected只能供同包和子类用）。
OSGi还有一个比较有用的地方，就是可以控制访问范围，这方面Java本身控制得不够细，比如我某个类只希望供某些指定的类使用，Java是无法做到的（Proptected只能供同包和子类用）。
对这些是肯定的。对于CLASS访问控制确实比纯粹的package机制以及java内建细节了一些，丰富了一些。这是OSGI的一个方面
我更希望有人可以说说OSGI动态的方面的好处和实际的例子