1.classic框架: 设计时依赖
OSGI框架: 运行时依赖
2.OSGI柄承职责单一的原则,面向服务的组件模型设计,强制面向接口编程,支持热插拔.
OSGI提供一个强大的,严格规范的类加载模型,为每个模块提供各自ClassLoader提供动态协作模型(服务注册),模块隔离,版本加载,属性过滤. 即使Bundle已经stop,其Export的Packages依然可用.
Bundle ClassLoader:控制模块内业务类加载
System ClassLoader: 控制Bundle的生命周期
SOCM: 面向服务组件模型
3.OSGI框架的两个设计方向:
(1).将WEB容器内嵌到OSGI环境中;
(2).将OSGI以WAR的方式发布到独立的WEB容器中.
4.Bundle的生命周期(LifeCycle):
安装, 启动, 更新, 停止, 卸载. (其实一个Bundle就是一个含有元文件的jar)
5.OSGI的两种监听实现方式:
(1).BundelContext:自已主动监听事件的变化;
(2).DS(Declarative Service):服务动态变化时主动调用.
资源不主动调用容器来实现自身生命周期的管理,这是我们所希望的,所以,DS更可取.
6.Bundle生成工具:
Bnd.jar可以根据传统工程的虚拟路径生成符合R4的bundle,下边是BluyDavy关于该工具的介绍:
http://www.blogjava.net/BlueDavy/archive/2007/07/27/132809.html
7.Bundle的WEB操作界面:TPF(脚手架)
当TPF的Bundle启动后,完全接管Equniox控制的其它应用Bundle生命周期,可以监听远程的TPF,它是 一 个基于Eclipse-Equniox的插件框架:
http://www.blogjava.net/BlueDavy/archive/2006/08/18/64440.html
8.Bundle的默认WEB根目录:MODULE-INF
如:MODULE-INF/WEB-INF/page/index.jsp
Spring-OSGI默认配置文件路径:META-INF/spring,默认这个文件夹下的配置文件都会被加载,当然也可以更改路径;
9.Equniox把以java.开头的类包交给parent ClassLoader去加载,意味着没有必要在系统中提供对外export java开头的package.
10.我不想把别人的代码再弄来贴一遍,以下列出我所收集的OSGI参考实例及资料:
(3)OSGI中国官方网站
(9)罗明的博客
(11)OpenCore:基于OSGi开发纯插件体系结构的WEB应用程序
更多请关注:http://www.osgi.com.cn/