创建4个bundle之后的工程目录如下图所示：

      通过该示例，将演示如何利用Spring DM发布和调用OSGi服务，同时还将演示OSGi的动态服务调用能力。

1.   bundle osgi.example.compute 
      compute bundle只提供一个接口——Compute，因此无需依赖更多的bundle，只需最基本的osgi即可。因为不涉及注册资源之类的，所以也无需Activator入口类。
Computer接口源代码如下所示：

package osgi.example.compute;   
  
public interface Compute {   
    public String computeNums(int x, int y);   
}  

        add bundle是对compute bundle的具体服务实现，在MANIFEST.MF文件需要引入osgi.example.compute包；当然也可以通过添加依赖bundle的形式，即不引入包，而直接在Required Plug-ins中添加compute bundle。如下图所示：

       通过引入osgi.example.compute包，osgi.example.compute  bundle被加到了add bundl的classpath当中，解决了开发时期的类型识别问题。
这样一来，在add bundle中就能使用compute bundle中的接口了，Computer接口的实现如下：

package osgi.example.compute.add;   
  
import osgi.example.compute.Compute;   
  
public class Add implements Compute {   
  
    public String computeNums(int x, int y) {   
        int s = x + y;   
        String result = "The Sum is---" + String.valueOf(s);   
        return result;   
    }   
}  

        Compute的实现已经实现了，那么如何将其发布出去呢？这个是由Spring DM负责，Spring DM利用OSGi命名空间下的<service>元素将bean导出为OSGi服务。最简单的形式为：

<beans:bean id="beanToPublish" class="com.xyz.imp.MessageServiceImp"/>   
<service ref="beanToPublish" interface="com.xyz.MessageService"/> 

        从示例中可以看出，beanToPublish被service元素声明导出。
另外，service结点还有一些高级属性，如depends-on、context-class-loader、ranking等待，详情请看spring dm reference。
        首先，需要在add bundle的工程根目录下的”META-INF”的文件夹下创建一个文件夹，取名”spring”，Spring DM能够自动解析该文件夹下所有的spring配置文件。spring配置文件的具体内容如下所示：

<?xml version="1.0" encoding="UTF-8"?>   
<beans xmlns="http://www.springframework.org/schema/beans"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    
    xmlns:osgi="http://www.springframework.org/schema/osgi"  
    xsi:schemaLocation="http://www.springframework.org/schema/beans                         http://www.springframework.org/schema/beans/spring-beans.xsd   
                        http://www.springframework.org/schema/osgi                          http://www.springframework.org/schema/osgi/spring-osgi.xsd">   
    <bean id="addOsgiService" class="osgi.example.compute.add.Add">   
    </bean>   
    <osgi:service id="addService" ref="addOsgiService"  
        interface="osgi.example.compute.Compute">   
    </osgi:service>   
</beans>  

该bundle和add bundle相似，在这就不赘述了。
4.    bundle osgi.example.compute.client

        顾名思义，该bundle将作为add 、multiply两个bundle的客户bundle，演示如何导入服务。
        OSGi的测试工作比较麻烦，这方面还没研究，在这里利用spring实例化bean的时期，从构造函数入手，对服务进行测试。Client类的实现很简单，如下所示：

package osgi.example.client;   
  
import osgi.example.compute.Compute;   
  
public class Client {   
    /** *//**  
     * 为了方便测试，采用Spring的构造注入方式，直接在构造函数中调用Compute服务  
     * @param compute  
     */  
    public Client(Compute compute){   
        System.out.println(compute.computeNums(5, 6));   
    }   
}  

      另外，因为client用到了其他几个bundle的类型，所以需要导入相应的包，步骤在上面已有讲到。
      spring dm靠<reference>元素来引入服务，最简单的形式如下所示：

<reference id="beanToPublish" interface="com.xyz.MessageService"/>  

      如果需要用到该服务，如某个bean包含一个com.xyz.MessageService属性，则配置该bean如下所示：

<bean id="referenceBean" class="com.nci.ReferenceBean">   
    <property name="messageService" ref="beanToPublish"/>   
</bean>  

<?xml version="1.0" encoding="UTF-8"?>   
<beans xmlns="http://www.springframework.org/schema/beans"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi"  
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd   
                      http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd">   
  
    <bean id="OSGiClient" class="osgi.example.client.Client">   
        <constructor-arg ref="ComputeService">   
        </constructor-arg>   
                </bean>   
                <osgi:reference id="ComputeService" interface="osgi.example.compute.Compute" cardinality="1..1">   
                </osgi:reference>   
</beans>   

       需要勾选中spring bundle版（2.5.6），spring dm的几个核心包：core、extender、io再点validate bundles按钮，校验是否已全部选中其依赖的bundle。然后即可点击运行了。
       运行之后，我们发现控制台输出结果：
The Sum is---11
通过ss命令，如下：
5 ACTIVE      osgi.example.compute.multiply_1.0.0
6 ACTIVE      osgi.example.compute.add_1.0.0
7 ACTIVE      osgi.example.compute.client_1.0.0
将6停掉:stop 6
然后再refresh 7，控制台输出如下结果：
The Multiply is---30
通过 ss 命令，如下：
5 ACTIVE      osgi.example.compute.multiply_1.0.0
6 RESOLVED    osgi.example.compute.add_1.0.0
7 ACTIVE      osgi.example.compute.client_1.0.0
现在multiply处于运行状态，而add已经被停止，所以client导入的服务实际是由multiply提供的。

6. 总结 

       通过该文档，我们已经清楚了，如何使用Spring DM导出、导入服务。Spring DM的一些高级特性请查阅spring dm reference。


附件：osgi.example.compute.rar

        现在的eclipse都已经包含了Equinox，无需单独下载。
2. 开发OSGi的HelloWorld应用程序

       在这一节，我们将开发一个OSGi bundle，演示如何利用Equinox进行OSGi bundle的开发、运行及调试，为之后的示例做准备。
       首先，新建一个Plug-in工程，如下图所示：

下一步，注意选择目标平台，默认为Eclipse version *，将其改成Equinox，如下图所示：

之后按默认下一步即可，到最后一步时，无需根据模板创建工程，去掉默认的勾，如下图：

点击完成，创建的工程目录如下图所示：

package helloworld;   
  
import org.osgi.framework.BundleActivator;   
import org.osgi.framework.BundleContext;   
  
public class Activator implements BundleActivator {   
  
    /**//*  
     * (non-Javadoc)  
     * @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)  
     */  
    public void start(BundleContext context) throws Exception {   
        System.out.println("Hello World!");   
    }   
  
    /**//*  
     * (non-Javadoc)  
     * @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)  
     */  
    public void stop(BundleContext context) throws Exception {   
    }   
  
}  

        在弹出的对话框中，新建一个OSGi Framework运行环境（双击OSGi Framework即可，这里为其取名Equinox），选中helloworld(1.0.0)，然后点击右边的Add Required Bundles按钮，eclipse将自动选中运行helloworld的依赖bundle，如果有必要，可以点击右下的Validate Bundles验证按钮，验证程序正常运行所需的bundle是否都被选中，最后点击运行，回到控制台：
osgi> Hello World!
        可以看到，之前在Activator的start方法中的输出语句已经被输出到控制台，我们可以通过命令ss查看Equinox的运行情况，可以看到一共运行了两个bundle，如下：
ss

Framework is launched.

id State       Bundle
0 ACTIVE      org.eclipse.osgi_3.4.3.R34x_v20081215-1030
1 ACTIVE      helloworld_1.0.0

        还记得之前讲到过的bundle的几种状态吧？helloworld已经运行起来了。
        那么Equinox具体支持哪些命令呢？下表列出了主要的一些命令，如需查看更详细的命令清单，则可以在控制台键入help。

        至此，我们已经成功的演示了helloworld，初步了解了OSGi的bundle是如何开发并运行的。

目前，关注OSGi的人变得越来越多，OSGi本身也早已从那个专注于嵌入式平台的“小”角色转变过来了，慢慢向企业级应用市场渗透。

从某种角度说，Eclipse可以说是OSGi在企业应用领域的试金石，2003年Eclipse3.0做了一次架构上的调整，继续延用插件的架构思想，但是从3.0版之后，是基于OSGi的实现。也就是这一次的调整，推动了Eclipse的迅猛发展。

这是在桌面应用的成功示例，而OSGi的目标远不止于此，以其优秀的类加载机制，可以说，只需对其进行扩展，那么就可以目标瞄准任何一个领域。谈到企业应用，无可避免的要涉及Web应用，相信大多数人都在从事该领域的开发。OSGi R4版已明确提出了对Web的支持方式——当然，这种方式还是很有限的，这一点将在后面的文章中详细说明。

鉴于此，很多开源框架都已经或正准备发布支持OSGi的版本，比如Spring DM、Struts1.8.1、CXF等等，基本上日常所用的开源框架都发布了基于OSGi版本。另外，有不少应用服务器也已经基于OSGi进行实现，比如WAS从6.1版就已经是基于OSGi的实现，而Spring也在2009年推出了Spring DM Server，可见OSGi的吸引力还是很大的。

那么这一切将会为以后的开发带来什么影响呢？本文试图从OSGi和构件化开发的角度认识一下该问题。

OSGi的类加载机制非常优秀，为每个运行于其中的bundle创建了独立的类加载器环境，而运行于同一个OSGi框架内部的bundle之间不像Web服务器中的Web应用那样绝缘，它们之间是可以进行包依赖的，当然OSGi也提供了服务注册等相关机制，确保bundle之间的相互协作能力。而且OSGi支持bundle动态部署。所以，系统无需停机重启，就可以实现其内部的动态更新。

构件化开发的概念已经提了很多年了，似乎一直缺乏一种有效的机制对其进行支持。构件化开发为系统开发带来了很多好处，整个系统的开发可以按照模块的方式进行划分，从而按模块进行开发；系统由各模块之间拼装而成，通过代码一级的依赖或者服务依赖的方式；对于某个模块进行更新，只要保持接口不变，则可以实现对外界无影响。

由于缺乏有效的底层支持，构件化开发方式一直没有推行起来。由其对于Web应用而言，想要实现构件化开发，似乎更是无从谈起。

OSGi的出现，让这一事情有所转机。传统的Web应用开发过程中，可能大多数人的做法就是将一个大的Web应用按功能模块进行划分，通过包切分来实现模块化开发，但是各模块之间并没有从物理上隔离，只是以一种组织方式上的约束，使其从表面看上去是分离的。对于这种方式，动态更新某个模块也就无从谈起了。

而如果将OSGi引入Web应用，每个模块都对应于一个bundle，那么模块与模块之间则从物理上进行了隔离，能有效的将模块内部实现对外隐藏。模块之间的交互，可以通过接口的导出与引用来实现，对于未经导出的部分，对于其他模块是不可见的。另外，由于OSGi支持bundle的热部署，那就意味着，在当前Web应用未停机的情况下，可以对某个或某些模块（对应OSGi中的bundle）进行动态更新，而不影响整个应用的正常运行。

这种从物理上的有效隔离的方式，为重用带来了新的方式。以前代码一级的重用，一般都通过Jar包的形式进行，而这种方式存在上述的一些缺点，即封装性不够。而通过基于OSGi的bundle的形式，则可以有效隐藏内部实现，从包一级进行隐藏（这一点个人觉得可以作为Java封装性的一种扩展，以前的封装只能做到类一级，不知道未来是否会被Java规范吸收）。

就这一点而言，OSGi对构件化开发进行了很好的支持，当然OSGi并不为此而生。

以上所说的构件依赖都是基于API一级的，那么当然，我们也可以将Web Service等类型服务封装至构件当中，再结合ESB，是不是对SOA的一种更好实现呢！ESB的关注点在于服务，这是一种细粒度的，它并不考虑服务的封装、重用等方面——这些方面都由设计人员去把握。而结合OSGi，当然还需要其他设施的支持，比如CXF已经发布了基于OSGi的实现，可以将服务封装至一个bundle，以bundle为单元，向外界提供服务，这种服务即变成了一种粗粒度的——构件的特点之一。

综上所述，我相信，OSGi的发展，将会为构件化的开发方式带来福音。

引出话题：OSGi和SCA在很多方面有着异曲同工这妙，并且SCA的实现框架——Tuscany也对OSGi做了支持。这两者有互补特性，有时间将对这两者做一个对比研究。

目前，OSGi规范的最新版本为R4.2，有关该规范的详细情况请阅读OSGi实战的第7节——深入OSGi。OSGi框架主要分为四部分：运行环境（executionenvironment）、模块（Modules）、生命周期管理（Life Cycle）、服务注册（Service Registry）。运行在OSGi环境中的是一个个的Bundle，也就是Modules的具体实现。

对于每个bundle，都有各自的ClassLoader，在这一点上和传统的Web应用有相似之处，在传统的Web应用开发完成之后，都会将其部署在Tomcat、Jboss等服务器上，这些Web应用都有着各自的ClassLoader环境，而两者之间的区别在于，传统的Web应用无法做到资源的共享，因为它们是完全独立、隔离的。OSGi框架为bundle之间的协作提供了底层支持，通过在bundle的MANIFEST.MF文件中Import-Package、Export-Package等项，bundle之间就能相互共享资源及服务，在以后的博文中，我将给出一个具体的示例。

由于OSGi具有良好的模块化结构，我个人认为这将为将来的软件开发方式带来很大的冲击，将更进一步推进模块化开发。目前Web应用的开发一般采用SSH框架，将整个应用大致分为Web（负责前台展现）、Service（负责业务逻辑处理）、DAO（负责数据持久化）、Domain（全局实体类）几个模块，而发布的时候，将被一起打成WAR包，部署至服务器上。如果采取bundle的形式，每个模块可以做为独立的bundle进行开发和部署，bundle之间的协作可以通过上述的方式进行，而这样带来的好处就是，一旦需要对某个模块进行更改，在保证依赖接口不变的前提下，就可以单独更改相应的bundle，再进行热部署即可，这样一来，好处是显而易见的，有效的分离了各个模块，减少了维护成本。

由于采用bundle的形式，也增强了模块的复用性。这也是得益于OSGi良好的模块化方式。

另外一个很重要的点就是OSGi具备热拔插特性，bundle的安装、启动、停止、卸载都可以在运行时指定，并且可以随时更改。这样一来，我们就可以做到无需重启整个应用，而只对需要更改的部分进行升级或打补丁即可。Bundl的状态图转换如下图所示：

图 1 OSGi bundle状态转换图

以上将OSGi的一些基本的，但也是很重要的东西大概介绍了一下，在以后的博文中逐步深入吧。以上都是关于OSGi原理性的东西，那么实现该规范的有哪些产品呢？最有名的应该要数Eclipse的Equinox框架了，在网上查资料见有人说过，Eclipse3.0的那一次升级把自身的构架做了一次非常大的调整，其主要原因就是采用了OSGi框架，更好的支持了Eclipse的插件体系。另外还有Felix、knopflerfish等。

不过话说回来，尽管OSGi有很多好处，但是现在主要还是应用在服务器端，如现在的应用服务器基本上都采用OSGi的框架，而真正的应用市场仍处理起步阶段，这和OSGi的生态环境还不成熟，可喜的是Spring推出了其Spring DM和SpringSource DM Server，前者能够很方便发布和引用服务，并且与Spring Framework平台相融合，将OSGi的bundle context与Spring applicationContext融合在一起，大大方便了OSGi的应用。后者是OSGi bundle的运行环境，是一个将Equinox和Tomcat融合在一起的服务器。在以后的博文中将详细介绍这些内容。