OSGi與SpringDM框架技术分享专题.docVIP

OSGi与SpringDM框架技术分享专题 OSGi基础 什么是OSGi？ OSGi（Open Service Gateway Initiative），最初的目的是为各种嵌入式设备提供通用的软件运行平台。后来经过10年的发展和壮大，OSGi已经不只是在嵌入式设备中应用，而是被推广到各种其他的应用行业中，比如其中最成功的Eclipse IDE。目前在企业级应用开发中也开始大量使用OSGi技术，尤其是在应用服务器领域，各大主要厂商相继宣布推出支持OSGi规范的中间件产品，例如Websphere、glassfish等。而从我们应用开发人员的角度来说，OSGi应该理解为“OSGi service platform”，它是一个开放并且提供统一接口标准的体系框架，基于这个体系框架，服务提供商，程序开发人员，软件提供商，服务网管运营商，设备提供商能够协调地联合起来开发，部署以及管理向用户提供的各种服务。目前OSGi service规范的最新版本是4.2，可以从 HYPERLINK 官网上获取更详细的信息。 OSGi能带来什么好处，能解决什么样的问题？ 作为一名实用主义者，新技术或新产品除了能给我们带来短暂的新鲜感外，最关心的莫过于它能给我们的实际工作带来什么好处，能帮助我们解决什么样的问题。OSGi与所谓的“云计算”相比并不算新技术，它已经存在了10年，所以它是成熟的、可靠的、经过验证的，比起“云计算”更靠谱。只是多年来应用的行业领域不同，不为我们所了解。以下是我眼中的OSGi给我带来的好处以及能够帮助我解决的问题，但不仅限于此，更有待您的发掘。 首先，OSGi改变了我们设计系统的传统思维模式。模块化的系统设计理念并非新事物，早在面向对象的设计思想诞生之前就已经出现。在面向过程的程序开发中，模块化是非常重要的工具，它可以提高程序的内聚性，降低程序的耦合度，并且在大规模协同开发中得到了真正的考验。当然OSGi对模块化又做了更进一步的发展，提出了服务平台(service platform)的概念，在网络环境下的模块化，从此我们从面向对象的时代步入面向服务的时代。我们不再把关注重点放在如何高度抽象出优美的对象模型上，而是更加注重根据实际的业务需求划分各种服务接口的边界以及各服务接口之间的依赖关系上。当然，组成服务内部的构件仍然基于面向对象的思想，只不过不再成为我们唯一的关注重点。在当今SaaS(软件即服务)的大趋势下，能提供何种质量的服务将被作为评判企业级管理软件优劣的重要标准，因为服务是用户唯一可见的交互渠道，系统内部的对象模型设计的再如何优雅对用户就是一个黑盒子。而OSGi正好能用来解决如何更好的抽象服务，封装复杂业务逻辑等的相关问题。 其次，OSGi使我们可以更好的控制每个模块(jar文件)之间的约束和依赖。先来回顾一个曾经让我倍感疑惑的回忆，经过3个月的努力，系统终于开发完成，并通过了所有的测试，可以正式上线了。当部署完成并启动应用服务器时却出现了一大堆的异常。每个开发人员都很疑惑，也很沮丧。不是通过了测试了吗，这么会出现异常呢？经过大家通宵的努力，终于找到了问题的所在，原来系统依赖的一个第三方jar包与应用服务器自带的一个jar包发生了版本冲突。为了便捷开发和测试环境用的是Tomcat，而Tomcat并没有自带这个冲突的jar包，但是线上环境的WebSphere则正好自带了这个jar包，并且当我们的系统调用这个jar包时，由于Classloader的加载顺序问题导致先找到了应用服务器自带的那个jar包，所以发生了异常。虽然问题终于解决了，但是这样的问题仍然在后续的项目中不断重演……。OSGi成为了解决此问题的最佳方案，它可以让我们明确定义各模块(其实就是jar包)的运行时环境、导入包、导出包、依赖包并由OSGi框架进行整个依赖关系有向图的验证，当出现jar包版本冲突，依赖丢失等错误时，OSGi可以明确的给出提示信息，帮助我们尽快的定位问题、解决问题。有些时候，我们并不希望暴露某些模块的package，这时，我们只需要在定义文件中不导出这些package就可以了，实现了包的隐藏控制机制。 再次，OSGi可以解决企业级应用系统启动速度慢的问题。随着企业业务的快速增长，员工对企业级应用系统的依赖程度也就越来越高，各种新的功能不断的被加入到原来的系统中，使得系统越来越臃肿。而系统中的有些功能并非被经常使用，却需要经历非常复杂的初始化过程，为了启动这个不被经常使用的功能，整个企业级应用系统的启动时间被整整拖延了数分钟……。通过OSGi，我们可以将各个功能划分为模块，并对模块启动顺序进行规划，即那些模块需要第一时间启动，那些模块可以延迟加载，最后通过模块定义文件进行明确的启动策略定义。只有当正真需要这个模块时，OSGi框架才会去加载它。这样