OSGi的思想

正确的理解和认识OSGI技术

我们从外文资料上或者从翻译过来的资料上看到OSGi解释和定义，都是直译过来的，但是OSGI的真实意义未必是中文直译过来的意思。OSGI的解释就是Open Service Gateway Initiative，直译过来就是“开放的服务入口(网关)的初始化”，听起来非常费解，什么是服务入口初始化？

所以我们不去直译这个OSGI，我们换一种说法来描述OSGI技术。

我们来回到我们以前的某些开发场景中去，假设我们使用SSH(struts+spring+hibernate)框架来开发我们的Web项目，我们做产品设计和开发的时候都是分模块的，我们分模块的目的就是实现模块之间的“解耦”，更进一步的目的是方便对一个项目的控制和管理。
我们对一个项目进行模块化分解之后，我们就可以把不同模块交给不同的开发人员来完成开发，然后项目经理把大家完成的模块集中在一起，然后拼装成一个最终的产品。一般我们开发都是这样的基本情况。

那么我们开发的时候预计的是系统的功能，根据系统的功能来进行模块的划分，也就是说，这个产品的功能或客户的需求是划分的重要依据。

但是我们在开发过程中，我们模块之间还要彼此保持联系，比如A模块要从B模块拿到一些数据，而B模块可能要调用C模块中的一些方法(除了公共底层的工具类之外)。所以这些模块只是一种逻辑意义上的划分。

最重要的一点是，我们把最终的项目要去部署到tomcat或者jBoss的服务器中去部署。那么我们启动服务器的时候，能不能关闭项目的某个模块或功能呢？很明显是做不到的，一旦服务器启动，所有模块就要一起启动，都要占用服务器资源，所以关闭不了模块，假设能强制拿掉，就会影响其它的功能。

以上就是我们传统模块式开发的一些局限性。

我们做软件开发一直在追求一个境界，就是模块之间的真正“解耦”、“分离”，这样我们在软件的管理和开发上面就会更加的灵活，甚至包括给客户部署项目的时候都可以做到更加的灵活可控。但是我们以前使用SSH框架等架构模式进行产品开发的时候我们是达不到这种要求的。

所以我们“架构师”或顶尖的技术高手都在为模块化开发努力的摸索和尝试，然后我们的OSGI的技术规范就应运而生。

现在我们的OSGI技术就可以满足我们之前所说的境界:在不同的模块中做到彻底的分离，而不是逻辑意义上的分离，是物理上的分离，也就是说在运行部署之后都可以在不停止服务器的时候直接把某些模块拿下来，其他模块的功能也不受影响。

由此，OSGI技术将来会变得非常的重要，因为它在实现模块化解耦的路上，走得比现在大家经常所用的SSH框架走的更远。这个技术在未来大规模、高访问、高并发的Java模块化开发领域，或者是项目规范化管理中，会大大超过SSH等框架的地位。

现在主流的一些应用服务器，Oracle的weblogic服务器，IBM的WebSphere，JBoss，还有Sun公司的glassfish服务器，都对OSGI提供了强大的支持，都是在OSGI的技术基础上实现的。有那么多的大型厂商支持OSGI这门技术，我们既可以看到OSGI技术的重要性。所以将来OSGI是将来非常重要的技术。

但是OSGI仍然脱离不了框架的支持，因为OSGI本身也使用了很多spring等框架的基本控件(因为要实现AOP依赖注入等功能)，但是哪个项目又不去依赖第三方jar呢？

简单地说，OSGi就是一个服务平台（Service Platform），它采用容器的思想来组织组件：

• 了解其发展过程，发现最初它就是为了合理地组织模块开发应运而生；
• 随着SOA的兴起，OSGi利用已有的灵活的组件开发优势，新增了服务的概念­­­­­­——组件注册服务，同时引用其他服务。
• 在其核心的编程思想上，发现它充分利用了基于组件开发的优势；
• 同时为了扩大这种优势，采用容器来管理、部署组件，达到系统的灵活性、可扩展性等。

 

具体包括以下三方面。

1、  采用容器的架构思想　

利用容器来组织业务组件、对象，管理和协调组件之间的关系，这是很多框架的核心思想。容器是框架的核心，它提供了组件植入的规范机制，让组件具有生命，提供给组件呼吸的空气。OSGi容器，实现了OSGi Framework 规范的要求，它是OSGi项目的核心部分。一般采用逻辑分层描述其主要实现的功能如下：

L1——模块层：定义了组件的装载（Classloader）机制，管理组件之间的隔离、依赖与协作；它在Java的类装载机制上加入了模块化的概念。

L2——生命周期管理层：负责运行时组件的生命周期，包括动态安装、启动、停止、更新或卸载组件，同时容器提供了运行时管理组件的API。

L3——服务注册层：这其实是OSGi结合SOA思想发展起来的，它提供了一个让组件动态注册服务的模型，同时组件可以发现、使用服务。

基于容器机制，便于组件的统一组织和协调；同时让容器提供基础服务，组件只需要关注业务和实现。OSGi容器类似JBoss、Spring容器一样，提供了运行环境，同时让使用者有机可乘，通过API能扩展、监听容器的执行情况。

 

2、  基于组件的开发思想

OSGi框架的宗旨，就是鼓励基于组件、分模块开发的思想来实现应用项目，同时它也带有约束性地要求以组件的方式来规划、设计、实现项目。当然，OSGi框架还提供了很多基于组件开发的服务，让这些组件在其容器中能有机地结合，良好地运转。主要几方面如下：

(1)、基于OSGi框架开发，模块都必须以组件（Bundle）的方式来组织开发和部署。

(2)、模块可单独形成一个工程，工程之间可没有依赖关系，在运行时，可动态选择需要加载的模块（也即Bundle）。

(3)、模块可动态部署、更新和管理。项目运行期间，可动态卸载模块、更新模块。

(4)、每个模块对应一个Bundle，它采用的是独立的Classloader机制，这也就意味着不能采用传统的如引用其他Bundle的工程来实现Bundle间的协作了。

(5)、每个Bundle可提供BundleActivator去控制自己的生命周期，完成在Bundle启动、停止时所需要进行的工作，同时可发布或者监听整个框架的事件状态信息。

总之，采用OSGi框架，以组件的形式来开发项目，能更好地解决了模块之间的耦合性、消除循环依赖，提高了模块的稳定性，便于以增量的方式来完成项目。

 

3、  组件之间的服务思想

模块或者组件不能是孤立地，孤立地、无人问津的模块将失去其价值。只有模块不断地协调、相互支持才能形成具有实际意义的应用项目。那么，OSGi是如何组织它们的？在OSGi期初，主要是以包依赖的方式来实现，包括输出包到OSGi容器、引用容器里其他组件输出的包、引用容器里的其他组件；之后，OSGi 又推出声明服务（Declarative Services）的方式来更加灵活地组织应用系统，解耦组件之间的依赖关系。

采用声明服务（由Java接口定义）的方式，OSGi主要利用了面向服务（Service-Oriented）的思想，组件可以通过组件上下文注册对外提供的服务，同时也可以通过组件上下文来获得需要引用的其他服务。采用面向服务的方式可以使得对外提供的服务能够更加的封闭，不需要为了使用别的组件提供的服务而做环境依赖等的设置。

其次，在有些OSGi框架（主要指Equinox项目）中，还采用定义扩展点的思想来协调组件的依赖关系，组件里可定义扩展点，其他项目根据需要实现相应的扩展点，相当于模板方法模式里提供的挂钩，只不过在OSGi框架里通过配置来实现，具有更大的灵活性。这样倒置了高层模块和低层模块之间的依赖关系，而且有时候也可消除项目中的循环依赖。

总之，很多框架，学习之余，总能感受到其中些许奥妙的思想，提炼出来，一方面能够更好的分析和学习框架，例一方面如果能将其揉合到开发项目中何尝不是一桩美事。OSGi框架，带来更灵活的基于组件开发技术，也确实带来许多软件开发的新思想。