创建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是如何开发并运行的。

//此方法负责处理由于鼠标选中或更改对树造成的变化，对树结构进行刷新   
public void propertyChange(PropertyChangeEvent evt)   
//树结点的图标   
protected Image getImage()   
//树结点的文本   
protected String getText()   
//该方法负责处理由于鼠标选中或其他事件激活某树结点该做的事情，如果为该树结点添加PropertyChangeListener。   
public void activate()   
//与上面的方法相反   
public void deactivate()   
//得到当前树结点的模型   
protected List getModelChildren()  

      补充资料：
      在Eclipse 里，当编辑器（Editor）被激活时，大纲视图自动通过这个编辑器的getAdapter()方法寻找它提供的大纲（大纲实现IcontentOutlinePage 接口）。GEF 提供了ContentOutlinePage 类用来实现大纲视图，我们要做的就是实现一个它的子类，并重点实现createControl()方法。ContentOutlinePage 是org.eclipse.ui.part.Page 的一个子类，大纲视图则是PageBookView 的子类，在大纲视图中有一个PageBook，包含了很多Page 并可以在它们之间切换，切换的依据就是当前活动的Editor。因此，我们在createControl()方法里要做的就是构造这个Page，简化后的代码如下所示：

private Control outline;   
public OutlinePage() {   
   super(new TreeViewer());   
}   
public void createControl(Composite parent) {   
    outline = getViewer().createControl(parent);   
    getSelectionSynchronizer().addViewer(getViewer());   
    getViewer().setEditDomain(getEditDomain());   
    getViewer().setEditPartFactory(new TreePartFactory());   
    getViewer().setContents(getDiagram());   
}  

     由于我们在构造方法里指定了使用树结构显示大纲，所以createControl()里的第一句就会使outline 变量得到一个Tree（见org.eclipse.gef.ui.parts.TreeViewer 的代码），第二句把TreeViewer 加到选择同步器中，从而让用户不论在大纲或编辑区域里选择EditPart 时，另一方都能自动做出同样的选择；最后三行的作用在以前的帖子里都有介绍，总体目的是把大纲视图的模型与编辑区域的模型联系在一起，这样，对于同一个模型我们就有了两个视图，体会到MVC 的好处了吧。
实现大纲视图最重要的工作基本就是这些，但还没有完，我们要在init()方法里绑定UNDO/REDO/DELETE 等命令到Eclipse 主窗口，否则当大纲视图处于活动状态时，主工具条上的这些命令就会变为不可用状态；在 getControl()方法里要返回我们的outline 成员变量，也就是指定让这个控件出现在大纲视图中；在dispose()方法里应该把这个TreeViewer 从选择同步器中移除；最后，必须在PracticeEditor 里覆盖getAdapter()方法，前面说过，这个方法是在Editor 激活时被大纲视图调用的，所以在这里必须把我们实现好的OutlinePage 返回给大纲视图使用，代码如下：

public Object getAdapter(Class type) {   
  if (type == IContentOutlinePage.class)   
  return new OutlinePage();   
  return super.getAdapter(type);   
}  

     要实现序列化，则必须实现serializable或Externalizable接口。后者继承自前者，两者的区别：实现前者的类可以采用默认的序列化方式。而实现后者的类则完全由自身来控制序列化的行为。
     在序列化和反序列化过程中需要特殊处理的类必须使用下列准确签名来实现特殊方法：

• ObjectOutputStream采用默认的序列化方式，对Customer对象的非transient的实例变量进行序列化。
• ObjectInputStream采用默认的反序列化方式，对Customer对象的非transient的实例变量进行反序列化。

• ObjectOutputStream会调用Customer类的writeObject(ObjectOutputStream out)方法来进行序列化。
• ObjectInputStream会调用Customer类的readObject(ObjectInputStream in)方法来进行反序列化。

     如果Customer类实现了Externalizable接口，那么Customer类必须实现readExternal
     (ObjectInput in)和writeExternal(ObjectOutput out)方法。在这种情况下，将按照以下方式序列化及反序列化Customer对象：

• ObjectOutputStream会调用Customer类的writeExternal(ObjectOutput out)方法来进行序列化。
•  ObjectInputStream先通过Customer类的不带参数的构造方法创建一个Customer对象，然后调用它的readExternal(ObjectInput int)方法来进行反序列化。

2.实现Serializable接口

       ObjectOutputStream只能对实现了Serializable接口的类的对象进行序列化。默认情况下，ObjectOutputStream按照默认方式序列化，这种序列化方式仅仅对对象的非transient的实例变量进行序列化，而不会序列化对象的transient的实例变量，也不会序列化静态变量。

      而当ObjectInputStream按照默认方式反序列化时，有以下特点：

• 如果在内在中对象所属的类还没有被加载，那么会先加载并初始化这个类。如果在classpath中不存在相应的类文件，那么会抛出ClassNotFoundException。
• 在反序列化时不会调用类的任何构造方法。

     被transient修饰符来修饰的实例变量是不会序列化的，一般用transient来修饰以下类型的的变量：

    １） 实例变量不代表对象的固有的内部数据，仅仅代表具有一定逻辑含义的临时数据。
    ２） 实例变量表示一些比较敏感的信息，如密码，出于安全方面的原因，不希望对其序列化。
    ３） 实例变量需要按照用户自定义的方式序列化，如经过加密后再序列化。这这种情况下可以将其用transient修饰，然后在writeObject()方法中对其序列化。   

２.１序列化对象图

    参见SerializableDemo中的Customer2及Order2类之间的关系。
    当通过ObjectOutputStream对象的writeObject(customer)方法序列化Customer2对象时，也会序列化与它关联的Order2对象。而当通过ObjectInputStream对象的readObject()方法反序列化Customer2对象时，实际上会对整个对象图反序列化。
    如果对象A持有对象B的引用（注意是A持有B的引用），以及间接持有其他对象的引用，则按照默认方式序列化对象A时，会将A以及A持有的以及间接持有的所有对象都序列化。反序列化也是如此。

２.２控制序列化的行为

    如果用户希望控制类的序列化方式，可以在可序列化类中提供以下形式的writeObject()方法和readObject()方法：

private void writeObject java.io.ObjectOutputStream out)throws IOException   
private void readObject java.io.ObjectInputStream in)throws IOException,ClassNotFoundException;  

    一般的做法是，在writeObject()方法中，选留骼ObjectOutputStream的defaultWriteObject()方法，使得对象输出流先执行默认的序列化操作。
    反序列化时，在readObject()方法中，先调用ObjectInputStream的defaultReadObject()方法。

２.３readResolve()方法在童便类中的运用

    如果一个类提供了readResolve()方法，那么在执行反序列化操作时，先按照默认方式或者用户自定义的方式进行反序列化，最后再调用readResolve()方法，该方法返回的对象为反序列化的最终结果。
    readResolve()方法应该能够被类本身、同一个包中的类，或者访问，因此readResolve()方法的访问权限可以是pirvate、默认或protected级别。
    readResolve()方法用来重新指定反序列化得到的对象，与此对应，Java序列化规范还允许在可序列化类中定义一个writeReplace()方法，用来重新指定被序列化的对象。writeReplace()方法返回一个Object类型的对象，这个返回对象才是真正要被序列化的对象。权限也可以为以上三种之一。  

３.实现Externalizalbe接口

       Externallizable接口继承自Serializable接口，如果一个类实现了Externalizable接口，那么将完全由这个类控制自身的序列化行为。Externalizable接口中声明了两个方法：

public void writeExternal(ObjectOutput out)throws IOException   
public void readExternal(ObjectInput in) throws IOException,ClassNotFoundException  

    writeExternal负责序列化操作，readExternal负责反序列化操作。在对实现了Externallizable接口的类的对象进行反序列化时，会先调用类的不带参数的构造方法，这是有别默认反序列化方式的（见２）。所以实现Externalizable接口的类必须要有不含参数的构造方法。

４.可序列化类的不同版本的序列化兼容性

    实例见SerializableDemo里的Customer5的两个版本。将Customer１.０和SimpleServer放在server端，将Customer2.0和SimpleClient放在Client端，直接运行，将发现抛出错误，显示不兼容，解决办法是手动将两个Customer的serialVersionUID设为同一个值，这样就能兼容。但是这种办法的能力很有限，当一个类的不同版本的serialVersionUID相同，仍然有可能出现序列化不兼容的情况。因为序列化兼容性不仅取决于serialVersionUID，还取决于类的不同版本的实现细节和序列化细节。

估计大家对finalize()都有个基本的认识，那就是作清理资源之用。比如在类的某个方法中打开了一个文件，那么你可能需要通过finalize()方法来释放该资源。但是话说回来，java世界里，一切皆对象，而任何一个学java的人都知道，java对象是不需要手动去清理的，因为java有强大的垃圾回收器，有人可能会有疑问，那既然如此，为什么还需要在finalize()中手动释放资源呢？当然，面对这一问题，有很好的理由去解释，因为资源是有限的，而我们又知道垃圾回收器的线程优先级非常低，在逼不得以的情况下，它才会工作，也就是说，只要内存足够，失效的对象就不会被清理，它所持有的资源也就得不到释放，而资源又是有限的，比如数据库连接，所以需要我们去手动释放。不过这一点，在JDK7里面似乎是有所发展，听说是会自动实现这一点，也就是说，sun可能为我们做了这个工作，以后的程序中可能不需要手动释放类似数据库资源的代码了。

如果的确如此，那是不是意味着finalize()就没用了呢？错。不过finalize()确实用到的时候不会很多，它主要用于一些本地方法调用过程中产生的资源清理。比如你通过Native method调用c语言的melloc方法分配了一些内存空间，而这部分内存是需要c语言的free()来进行释放的，如果不这样，就会产生内存泄漏，所以你需要在finalize()中用Native method方法调用free()将其释放。

不过话说回来，finalize()方法并不十分保险，因为finalize()只有在垃圾回收器工作的时候才会被调用，也就是说，通过它进行资源释放并不能确保马上被释放，甚至可能根本不会被释放（因为垃圾回收器可能不会工作），因此，资源释放尽量另想办法，别太相信finalize()和垃圾回收器了。

目前，关注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融合在一起的服务器。在以后的博文中将详细介绍这些内容。