在网上看到这么一句话觉得总结的非常好：
从高内聚，低耦合到设计模式，从 Ioc 、 Spring 框架 到 SOA 我们一步一步的抽象着、分离着。很显然，我们需要一个灵活而不失严谨的架构，需要一个功能强进而不令人生畏的产品；
企业的应用软件发展还有着很大的空间和尺度，也大概明白为什么OSGI起源于1999年却近几年才进入软件行业，当时软件业确实还不发达，人们确实想不了这么多，做软件只为了能解决一些问题而做。而如今更多是要资源最大化共享，就想着怎么能把原来做过的软件集成起来，不用再做个新的，于是就有了SOA。随着Eclipse的成功，大家对它以OSGI为核心的插件体系无不赞叹，原来做软件可以像搭积木一样的拼装，多么美妙，人们也就认识到了OSGI的重要性和带来的好处，近两年OSGI正在飞速发展，相信以后会有更大的发展空间，网上有人预言说将来OSGI一定会装在60%的java虚拟机上，还有人说这么好的架构应该直接纳入JDK，这些都有点极端，但是可以看出它是多么的优秀。越来越多的软件开始支持OSGI。
OSGI的强项是它的动态加载和对Bundle之间的通信和管理及依赖关系，而更细粒度bundle内部则没有严格的管理体系，Spring可以对bundle内部进行更为细粒度的管理，Spring将在配置文件中增加直接支持OSGI的配置项。
他们的组合可以把底耦合的应用程序“模块化”。
运行期间多个版本的应用同时部署，动态选择，当然这是OSGI的特性，但是有Spring的配置将更好。
运行期间多模块(服务)的替换。
运行期间动态部署，更新或反部署模块。
应用Spring配置，装配模块。
用简单和熟悉的编程方式开发具有OSGI特征的程序。
Hibernate现在也可以集成到OSGI，为OSGI持久层又添了一笔，可以看出Spring+OSGI+hibernate前途无量。

对于OSGi，有人评论称OSGi是“Spring之后的下一个big thing”。不过该文的作者后来又觉得，OSGi也有不少的问题，其中之一就是它在把技术变得复杂化。作者是这样说的：
　　我对OSGi不怀疑并承认OSGi解决了许多问题，而且它支持一些出众的结构模型比如高模块化（high modularization）以及微服务（micro services）。然而从另外一个角度来说，在使用了OSGi几年之后，也体验了它在不同领域的表现（我是指开发领域）之后，我真的开始怀疑OSGi了。
　　这是我喜欢和讨厌的OSGi的一些方面：
　　它从几百个具有代表性的小bundle中创建出一个系统的概念非常棒。OSGi bundle很好的一点是它们定义了边界：不仅从依赖关系的意义上，而且从运行时间的意义上也是这样。每个bundle可以充当一个微应用，有自己的lifecycle和用户，每个bundle能够仔细地断定出哪个对象对外暴露。好好地使用它们，会带给系统以松耦合，并增加再使用的可能性。而与此同时，OSGi的lifecycle使life更加复杂。实际上，追踪服务和管理服务所引发的各个问题很讨厌（我曾看到过在它们的bundle activators使用大型的state machines来管理所有事情，这种样板化代码没有人愿意写）。幸运的是有Spring DM来帮我们管理这些。坦白说，如果没有Spring DM我绝不会动手开始OSGi项目。尽管Spring DM大大降低了bundle启动的复杂度，但仍然很麻烦。我仍然需要启动OSGi的运行时间、安装启动bundles，我还需要确保所有其他我所需要的bundles已经安装和启动。
　　我个人觉得，作为开发者，我们应当迫使自己执行系统的约束。我们不得不自动核对定义的限制，比如说，如果我们读取了一些我们并不想读取的类，构建程序就会失败。OSGi的版本概念，通过定义输入和输出包，将架构参数（architectural constraints）首次带入开发者的日常生活，并引入了一系列新的问题。OSGi是这样解决运行时间的版本问题的：它给每个bundle自己的class loader，并让class loader看起来像它所在的版本一样。这也带来一系列问题，因为它改变了你环境工作的方式。你的代码在所有你的单元测试中都可以通过，但一旦执行在OSGi的运行时间上，就会崩溃；Libraries崩溃因为这提升了运行时间中的类；Singletons被设计为静态对象不止一次地被创建，周而复始。当你在不断地调整你的模块构建说明时你会经常终止，而且绝对会在你的整个系统中传播反直观的依赖关系。Spring DM也是这个问题：通过在你的服务中添加一些指令并且不断地调整你的class loaders，你仍然需要调整和传送依赖关系。
　　尤其是类的导入更是带来很麻烦的问题。你很快会注意到，没有强大和自动集成的测试组件来配合OSGi，你无法继续下去。
　　现在说一下我的结论：
　　在考虑OSGi之前，我会切实核实是否在不关闭系统的情况下我能否在运行时间中转换bundles，即使在这种情况下，我也会再次查看这些需求，来看看是否我会把他们限制在一个角落里，在这里我可以使用其他技术在动态时间上来动态地加载模块。还有其他选择可以生成这种结构条例（比如使用一个IOC container，使用独立的container来执行模块依赖等等……）许多这些东西都很接近KISS原则，避免所有其他附件的样板化代码并构建配置，这因此让你更加敏捷。
　　回归到我的题目上，还有一种技术拥有这样的特点（我是指让技术更加复杂），那就是EJB。Spring是最流行的实例：技术更加复杂，开发周期更加困难。也许我们会在未来的几年内在OSGi中看到同样的境遇？我无法断定，时间将验证一切。

OSGi(Open Service Gateway Initiative)技术是面向Java的动态模型系统。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。
OSGi亦称做Java语言的动态模块系统，它为模块化应用的开发定义了一个基础架构。OSGi容器已有多家开源实现，比如Knoflerfish、Equinox和Apache的Felix。您可以通过这些容器，把您的应用程序劈分为多个模块单元，这样，您就可以更容易地管理这些模块单元之间的交叉依赖关系。
OSGi规范和Servlet规范及EJB规范类似，该规范定义了两种对象，一是容器对外提供的服务对象，另一个是容器和您的应用程序之间必须遵守的契约，其中，服务对象是容器要实现的。您如果想要在OSGi平台上进行开发，首先，您必须要使用OSGi API来创建您的应用，然后将之部署到OSGi容器中。从开发者的角度看，OSGi具有以下优点：
a) 您可以在不重启容器的情况下，动态地安装、卸载、启动和停止您的应用程序中的不同模块；
b) 对于您应用程序中的某一特定模块，容器可以同时运行该模块的多个版本；
c) OSGi为开发嵌入式应用、移动应用、富互联网应用(RIA)提供了非常优秀的基础架构
如果说您使用Servlet容器开发您的网络应用，使用EJB容器开发交易式应用，您可能会问，为什么我们还需要另外的容器呢？对这个问题的简短回答是，OSIG容器是专门为开发复杂的Java应用准备的，在这些应用的开发过程中，您非常需要将这些应用分割为一个个的模块。在本系列以后的文章中，我将针对这个问题进行展开并深入回答。
1. OSGi在企业开发中的应用
OSGi联盟(OSGiAlliance)于1999年3月开始着手制定OSGi规范，其主要目的就是要制定一套开放式标准，以便向局域网及其中的设备提供可管理的服务；其基本思路是，一旦您在网络设备（如服务器和嵌入式设备）上使用了OSGi服务平台，您就可以在网络上的任何地方管理这些设备上运行的软件组件的生命周期，可以在后台对这些组件进行安装、升级或卸载，但不需要打断该设备的正常运行。
近年来，OSGi技术在嵌入式系统及网络设备市场得到广泛应用。现在，由于Eclipse的成功，OSGi在企业开发中逐渐成为切实可行的、较有价值的一种技术。
1.1. 业界对OSGi的支持逐渐上升
2003年，Eclipse开发团队开始想办法提高Eclipse工具集的模块化，以便让它成为更加动态的富客户端平台。Eclipse团队最终选中OSGi框架作为其组件的运行时模型，2004年6月发布的Eclipse3.0就是第一个基于OSGi平台的版本。现在几乎所有的企业应用服务器都支持OSGi，Spring也通过一个叫“OSGi服务平台上的Spring动态模型(亦称之为OSGiSpring)”的项目来支持OSGi。该项目提供OSGi基础架构，以便我们在Spring的企业开发中更容易使用OSGi。
2. 开放源码的OSGi容器
从企业开发者的角度看，OSGi容器的要求很低，您可以很容易地把它嵌入到企业应用中，比如我们在开发Web应用时，我们可以把这个Web应用分为多个模块，一个模块负责视图层，另一个模块负责DAO层，第三个模块负责数据访问层，如果我们使用OSGi容器来管理这些模块之间的交叉依赖，我们就可以在不用重启该Web应用的前提下，将DAO层从速度较慢的升级到速度较快的DAO。
只要您的应用和OSGi规范兼容，您的应用就应该可以运行在任何OSGi容器中，现在比较流行的开放源码的OSGi容器有以下三种:
a) Equinox容器是参照OSGi规范第4版实现的，它构成了Eclipse IDE的核心—模块化的Java运行时；它实现了OSGi规范4中规定的必须强制实现的功能，同时，它也实现了OSGi规范中大部分的可选功能；
b) Knoflerfish是OSGi规范第3版和第4版的开源实现，它实现了OSGi规范规定的必须实现的功能及部分可选功能；
c) Apache的Felix是Apache软件基金会实现的OSGi开源容器，至本文截稿时为止，该容器还没有和OSGi规范完全兼容。