反对OSGi：Spring抛弃 OSGi 转向 gradle http://www.csdn.net/article/2012-10-25/2811157-Spring-Abandons-OSGi-in-Move-to-Gradle
OSGi 的 Hello world 请看http://blog.csdn.net/xiaokui008/article/details/9662937
Spring框架的OSGi：Spring-DM介绍请看http://osgi.com.cn/article/7289459
J2EE高手眼里的OSGi
日期：2012-1-4作者：yonpad来源：websphere中国
OSGI（Open Service Gateway Initiative）联盟成立于1999年，它是一个非盈利的国际组织，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准，是开放业务网关的发起者。
OSGI联盟的初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台，对OSGI的最早设计也是针对嵌入式应用的，诸如机顶盒、服务网关、手机、汽车等都是其应用的主要环境。
由于OSGI的诸多优秀特性（可动态改变系统行为，热插拔的插件体系结构，高可复用性，高效性等等），它被应用于许多PC上的应用开发，因此逐步为开发者所知和钟爱。现在人们对OSGI的理解已经远远不是它字面和初衷所能解释的了，称其为一个轻巧的、松耦合的、面向服务的应用程序开发框架更为确切一些。
OSGI发展到今天已经得到了众多企业、厂商、开源组织的支持，主流的Java应用服务器（Oracle的Weblogic、IBM的Websphere及Sun的Glassfish等)都已经采用了OSGI。OSGi作为Java模块化标准已成为事实。
OSGI著名案例
Eclipse作为Java业界成功的IDEproject，在3.0以前的版本它采用的是自己设计的一套插件体系结构，而Eclipse的插件体系结构在整个业界都是非常知名的，也是被认为非常成功的一种设计，但Eclipse在3.0版本时却做了一个重大决度，就是推翻它自己以前的插件体系结构，采用OSGI作为其插件体系结构。Eclipse之所以要抛弃自己那套已经比较成熟的插件体系结构而转而采用OSGI，就是因为OSGI的规范性以及OSGI对于插件体系结构更为完整的定义，Eclipse采用OSGI作为其插件体系结构的成功是很明显的，在Eclipse 3.1版本以后大家可以明显的感觉到启动速度的提升，同时也使得可以在运行时对插件进行管理，更明显的提升是插件的开发更加的规范，从而可以使用很多已有的OSGI插件。
BMW汽车的应用控制系统采用OSGI作为其底层架构，很多人都认为基于java的系统低效，不可能用于汽车这样的应用控制系统上。这套系统主要用来控制汽车上的音箱、灯光等等设备，总共由1000多个Bundle构成，但BMW汽车的应用控制系统启动时间却只需要3.5秒，这也从很大程度上反应了采用OSGI的系统的效率并不会低。
OSGI优点
第一点，基于OSGI的应用程序可动态更改运行状态和行为。在OSGI框架中，每一个Bundle实际上都是可热插拔的，因此，对一个特定的Bundle进行修改不会影响到容器中的所有应用，运行的大部分应用还是可以照常工作。当你将修改后的Bundle再部署上去的时候，容器从来没有重新启过。这种可动态更改状态的特性在一些及时性很强的系统中尤其重要。
第二点，它是一个稳定高效的系统。OSGI是一个微核的系统，所谓微核是指其核心只有为数不多的几个jar包。基于OSGI框架的系统可分可合，其结构的优势性导致具体的Bundle不至于影响到全局，不会因为局部的错误导致全局系统的崩溃。
第三点，可复用性强。OSGI框架本身可复用性极强，很容易构建真正面向接口的程序架构，每一个Bundle都是一个独立可复用的单元。
OSGI缺点
管理端不够强大目前OSGI框架提供的管理端不够强大，现在的管理端中仅提供了基本的Bundle状态管理、日志查看等功能，像动态修改系统级别的配置(config.ini)、动态修改Bundle的配置(Manifest.mf)、启动级别等功能都尚未提供，而这些在实际的项目或产品中都是非常有必要的。
采用OSGI作为规范的模块开发、部署方式自然给现有开发人员提出了新的要求，需要学习新的基于OSGI的开发方式
什么是Bundle
在OSGI框架中是采用Bundle的方式来组织和部署系统的
Bundle其实就是一个jar文件，这个jar文件和普通的jar文件唯一不同的地方就是Meta-inf目录下的MANIFEST.MF文件的内容，关于Bundle的所有信息都在MANIFEST.MF中进行描述，可以称它为bundle的元数据，这些信息中包含有象Bundle的名称、描述、开发商、classpath、需要导入的包以及输出的包等等
Bundle是个独立的概念，在OSGI框架中对于每个Bundle采用的是独立的classloader机制，这也就意味着不能采用传统的如引用其他Bundle的工程来实现Bundle间的协作了，那么在OSGI框架中Bundle之间是怎么协作的呢，在OSGI框架中对于每个Bundle可以定义输出的包以及引用的包，这样在Bundle间就可以共享包中的类了，尽管这样也可以直接实现简单的Bundle的协作，但在OSGI框架中更加推荐的是采用Service的方式，Service-Oriented的概念(例如SOA)大家都接触多了，OSGI框架也同样是如此的，每个Bundle可以通过BundleContext注册对外提供的服务，同时也可以通过BundleContext来获得需要引用的服务，采用Service-Oriented的方式可以使得对外提供的服务能够更加的封闭，不需要为了使用别的Bundle提供的Service而做环境依赖等的设置，同时，Bundle还可以采用Require-Bundle的方式来直接引用其他的Bundle（相当于引用其他Bundle的工程或jar）。
主要的开源OSGI框架
（博主注：2013年最后一次更新）
最知名，也是更新最频繁的，由于Eclipse基金的支持，其功能越来越完善，实现了OSGi R4规范，并提供很多平台性质的服务，包括：常用功能模块、日志模块、Web服务器模块、Servlet模块、JSP解析模块等等。由于其与Eclipse的天然联系，使得开发基于Equinox的应用程序变得很简单。Eclipse 3.1之后的版本，Eclipse 本身就已经包含了Equinox。
遵循EPL (The Eclipse Public License)，任何扩展自Eclipse源码的代码也必须是开源的,商业软件可以使用，也可以修改代码，但要承担代码产生的侵权责任。
很早的，也很优秀的一个OSGI框架，也实现了OSGI R4标准。该项目的宗旨在于创建一个易于开发的OSGI平台，与Equinox不同之处在于它本身提供一些小应用实例，包括一个可视化控制台等，也提供基于Eclipse的插件。
遵循Knopflerfish License (BSD-esque) http://www.knopflerfish.org/license.html
商业软件可以使用，也可以修改使用BSD协议的代码
（博主注：2015年十月最后一次更新）
很新的一个OSGi框架，社区很活跃，更新频率高，是Apache的开源项目。该项目2007年8月才出1.0 版，也实现了OSGiR4规范，也提供相关的基础服务和扩展服务功能。
Felix也有了Eclipse集成支持，开发者可以在Eclipse IDE里运行Felix。
Felix组件按照Apache软件许可证2.0（Apache Software License Version 2.0）来发布许可。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。商业软件可以使用，也可以修改使用Apache协议的代码。
与流行框架的结合
Spring-DM指的是Spring Dynamic Modules。Spring-DM的主要目的是能够方便地将Spring框架和OSGi框架结合在一起，使得使用Spring的应用程序可以方便简单地部署在OSGi环境中，利用OSGi框架提供的服务，将应用变得更加模块化。
附录
BSD开源协议（Felix遵守的许可证协议）
BSD开源协议是一个给于使用者很大*的协议。可以*的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1. 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Apache Licence 2.0（knopflerfish遵守的许可证协议）
ApacheLicence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件：
1. 需要给代码的用户一份Apache Licence
2. 如果你修改了代码，需要再被修改的文件中说明。
3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4. 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
ApacheLicence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。