基于OSGI做真正面向接口的开发-转自BlueDavy之技术Blog
2010-06-01 15:05
344 查看
是否能够真正做面向接口的开发,和系统所采用的容器或框架具有很大的关系,面向接口的开发最重要的就是解决系统的依赖问题,在这点上目前最成熟的解决方案莫过于IoC,IoC容器而言最成功的莫过于Spring,那么基于OSGI的话是不是会带来不同的视角呢,来看看这几个方面的例子:
1、A类希望能够执行系统中实现了B接口的类
在OSGI中实现这种是多么的简单,可以看看:
ServiceReference[] serviceRefs=context.getServiceReference(B.class.getName());
for(int i=0;i<serviceRefs.length;i++){
B b=(B)context.getService(serviceRefs[i]);
b.execute();
}
用习惯了IoC的人都会去说上面的方法还需要通过context主动获取这么的烂,那么在OSGI中你同样可以用下面的这样一种方式去调用:
public void setService(B b){
b.execute();
}
这样的方式满意了吧,在这样的情况只需要将这个类对于B的引用配置为cardinality="0..n",那么OSGI框架就会自动的去完成调用实现了B接口的类的execute方法。
ps: 可以想象基于这样的方式要实现COR Pattern是多么的容易....
2、A类引用了Log接口,但无所谓系统中有否Log接口的实现此类都需要正常运行
在OSGI中要做到这个同样是非常的容易:
public void setLog(Log log){
this.log=log;
}
只需要将这个类对于Log的引用配置为:cardinality="0..1"
3、A类希望根据某种条件来决定到底调用哪个实现接口的类
在OSGI中可以通过象属性过滤、版本过滤等多种方式来动态的决定调用相应的实现接口的类,可以想象有这种来实现类似的业务逻辑的处理是不是更加的简单和方便呢。
4、动态性
这个自然是因为OSGI 带来的特性,在基于OSGI构建的这样的系统中,我们完全可以先定义好接口,然后启动整个系统,当完成了某个接口的实现后,部署到OSGI框架中,再使用此接口的功能后自然就可以直接使用了,整个系统完全无需进行重启等麻烦的操作。
从以上简单的几个例子可以看出,基于OSGI做真正的面向接口的开发变得非常的容易和灵活,而动态性特征更是使得可以完全以接口的方式先搭建好系统,这对于迭代式的开发模型来说非常的重要。
为什么说这样的方式才是真正的面向接口的开发呢,可以看到在传统的开发方式中,无论怎么样,都仍然是要先有实现了接口的类后系统才可运行,而在基于OSGI的开发中完全不需要,在基于OSGI的系统中开发人员可以确定当需要的接口的实现都提供了后,功能自然就是实现了的,而无需管系统中是否具体有接口的实现,更为重要的一点是由于传统的开发方式多是在运行前定义好依赖关系,而在基于OSGI的系统很容易实现运行期才决定依赖关系,这对于提升系统的灵活性的效果不言而喻。
ps:我知道很多spring高手在看了上面的例子后会告诉我基于spring也可以去实现上面的这些例子,但是不是要做出更多的增强呢,spring本身并没有classloader的完整机制,所以要基于它去实现这些动态的特征的时候会变得很复杂,而既然现在OSGI已经提供了这些,为什么一定要基于spring去增强来达到这些已经在OSGI中达到的目标呢?
1、A类希望能够执行系统中实现了B接口的类
在OSGI中实现这种是多么的简单,可以看看:
ServiceReference[] serviceRefs=context.getServiceReference(B.class.getName());
for(int i=0;i<serviceRefs.length;i++){
B b=(B)context.getService(serviceRefs[i]);
b.execute();
}
用习惯了IoC的人都会去说上面的方法还需要通过context主动获取这么的烂,那么在OSGI中你同样可以用下面的这样一种方式去调用:
public void setService(B b){
b.execute();
}
这样的方式满意了吧,在这样的情况只需要将这个类对于B的引用配置为cardinality="0..n",那么OSGI框架就会自动的去完成调用实现了B接口的类的execute方法。
ps: 可以想象基于这样的方式要实现COR Pattern是多么的容易....
2、A类引用了Log接口,但无所谓系统中有否Log接口的实现此类都需要正常运行
在OSGI中要做到这个同样是非常的容易:
public void setLog(Log log){
this.log=log;
}
只需要将这个类对于Log的引用配置为:cardinality="0..1"
3、A类希望根据某种条件来决定到底调用哪个实现接口的类
在OSGI中可以通过象属性过滤、版本过滤等多种方式来动态的决定调用相应的实现接口的类,可以想象有这种来实现类似的业务逻辑的处理是不是更加的简单和方便呢。
4、动态性
这个自然是因为OSGI 带来的特性,在基于OSGI构建的这样的系统中,我们完全可以先定义好接口,然后启动整个系统,当完成了某个接口的实现后,部署到OSGI框架中,再使用此接口的功能后自然就可以直接使用了,整个系统完全无需进行重启等麻烦的操作。
从以上简单的几个例子可以看出,基于OSGI做真正的面向接口的开发变得非常的容易和灵活,而动态性特征更是使得可以完全以接口的方式先搭建好系统,这对于迭代式的开发模型来说非常的重要。
为什么说这样的方式才是真正的面向接口的开发呢,可以看到在传统的开发方式中,无论怎么样,都仍然是要先有实现了接口的类后系统才可运行,而在基于OSGI的开发中完全不需要,在基于OSGI的系统中开发人员可以确定当需要的接口的实现都提供了后,功能自然就是实现了的,而无需管系统中是否具体有接口的实现,更为重要的一点是由于传统的开发方式多是在运行前定义好依赖关系,而在基于OSGI的系统很容易实现运行期才决定依赖关系,这对于提升系统的灵活性的效果不言而喻。
ps:我知道很多spring高手在看了上面的例子后会告诉我基于spring也可以去实现上面的这些例子,但是不是要做出更多的增强呢,spring本身并没有classloader的完整机制,所以要基于它去实现这些动态的特征的时候会变得很复杂,而既然现在OSGI已经提供了这些,为什么一定要基于spring去增强来达到这些已经在OSGI中达到的目标呢?
相关文章推荐
- 基于OSGI的面向接口开发
- 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - 插件接口IModule扩展
- 基于DotNet构件技术的企业级敏捷软件开发平台 AgileEAS.NET - 插件接口IModule
- 真正的创新必然是基于对市场的了解,对客户反馈的观察,开发出来的产品一定要适应市场,提出的模式一定要能解决现实的问题。而在这其中,技术只是一种实现手段。
- 权限设计-之学习篇--来源于BlueDavy之技术Blog
- 基于ASP.NET AJAX低级动画技术开发Web 2.0应用程序
- 面向未来的跨界开发技术(上)
- 基于java技术的软件开发架构总结
- 后台接口平台 基于Laravel 开发 快速开发数据接口
- 面向Java的动态模型系统OSGi技术
- 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - 文章汇总及学习指南
- 基于CXF框架下的SOAP Webservice服务端接口开发
- 面向Java开发人员的Ajax技术
- 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET平台开发指南 - 分布式应用
- 基于ASP.NET WPF技术及MVP模式实战太平人寿客户管理项目开发(Repository模式)
- 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET平台开发指南 - 应用部署
- 【Python】djangorestframework 基于django框架的接口开发
- 基于ASP.NET MVC+Linq等技术下的企业级通用OA系统全程开发
- 基于 OSGi 和 Spring 开发 Web 应用
- 基于接口开发的令牌