J2EE高手眼里的OSGi
原文链接:[url]http://www.searchsoa.com.cn/showcontent_57045.htm[/url]
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框架
Equinox
最知名，也是更新最频繁的，由于Eclipse基金的支持，其功能越来越完善，实现了OSGi R4规范，并提供很多平台性质的服务，包括：常用功能模块、日志模块、Web服务器模块、Servlet模块、JSP解析模块等等。由于其与Eclipse的天然联系，使得开发基于Equinox的应用程序变得很简单。Eclipse 3.1之后的版本，Eclipse 本身就已经包含了Equinox。 遵循EPL (The Eclipse Public License)，任何扩展自Eclipse源码的代码也必须是开源的,商业软件可以使用，也可以修改代码，但要承担代码产生的侵权责任。
Knopflerfish
很早的，也很优秀的一个OSGI框架，也实现了OSGI R4标准。该项目的宗旨在于创建一个易于开发的OSGI平台，与Equinox不同之处在于它本身提供一些小应用实例，包括一个可视化控制台等，也提供基于Eclipse的插件。 遵循Knopflerfish License (BSD-esque) http://www.knopflerfish.org/license.html 商业软件可以使用，也可以修改使用BSD协议的代码
Felix
很新的一个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也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
其他理解:
OSGi的主要职责就是为了让开发者能够建动态化、模块化的Java系统。
OSGi（Open Service Gateway Initiative）有双重含义。一方面它指OSGi Alliance组织；另一方面指该组织制定的一个基于Java语言的服务（业务）规范——OSGi服务平台（Service Platform）。
OSGi Alliance是一个由Sun Microsystems、IBM、爱立信等于1999年3月成立的开放的标准化组织， 最初名为Connected Alliance。该组织及其标准原本主要目的在于使服务提供商通过住宅网关，为各种家庭智能设备提供各种服务。目前该平台逐渐成为一个为室内、交通工具、移动电话和其他环境下的所有类型的网络设备的应用程序和服务进行传递和远程管理的开放式服务平台。
该规范和核心部分是一个框架 ，其中定义了应用程序的生命周期模式和服务注册。基于这个框架定义了大量的OSGi服务：日志、配置管理、偏好，HTTP（运行servlet）、XML分析、设备访问、软件包管理、许可管理、星级、用户管理、IO连接、连线管理、Jini和 UPnP。
这个框架实现了一个优雅、完整和动态的组件模型。应用程序（称为bundle）无需重新引导可以被远程安装、启动、升级和卸载（其中Java包／类的管理被详细定义）。API中还定义了运行远程下载管理政策的生命周期管理。服务注册允许bundles去检测新服务和取消的服务，然后相应配合。
OSGi原先关注于服务网关，其实可用于多个方面。现在OSGi规范已经用于从移动电话到开源的Eclipse（其中包括了与IBM的OSGi框架SMF兼容的开源版本）。 OSGi服务平台的应用包括：服务网关、 汽车、移动电话、 工业自动化、建筑物自动化、PDA 网格计算、娱乐（如iPronto）、和 IDE。
OSGi规范是由成员通过公开的程序开发，对公众免费而且没有许可证限制。但是OSGi Alliance的兼容性程序只对成员开放，目前有12个兼容的实现。
2003年Eclipse选择OSGi作为其插件的底层运行时架构。Equinox project对该理念进行了实验，2004年6月在Eclipse3 R3中发布。ProSyst是面向OSGi开发者的Eclipse插件。
2003年10月， 诺基亚、摩托罗拉，ProSyst 和其他OSGi成员组建了Mobile Expert Group (MEG)为下一代智能手机规范业务平台，做为对 MIDP 和CDC的补充。
OSGi的主要职责就是为了让开发者能够建动态化、模块化的Java系统。
OSGI(Open Service Gateway Initiative) 它可以被看做OSGi Alliance组织；也可以认为是该组织制定的一个基于基于Java语言的服务（业务）规范——OSGi服务平台（Service Platform）
a) 您可以在不重启容器的情况下，动态地安装、卸载、启动和停止您的应用程序中的不同模块；
b) 对于您应用程序中的某一特定模块，容器可以同时运行该模块的多个版本；
c) OSGi为开发嵌入式应用、移动应用、富互联网应用(RIA)提供了非常优秀的基础架构
个模块负责视图层，另一个模块负责DAO层，第三个模块负责数据访问层，如果我们使用OSGi容器来管理这些模块之间的交叉依赖，我们就可以在不用重启该
Web应用的前提下，将DAO层从速度较慢的升级到速度较快的DAO。
附：一些OSGI的资料你好,OSGI
这是一个OSGI的专题汇总。里面的资料还是很不错的
1 对于技术本身分的前景还是很看好的，现在各大服务器厂商都在使用OSGI重构自己的服务器。
2.对于国内的开发者而言，前景不好说。由于国内大部分的开发者跟服务器开发和IDE开发关系不大。似乎更重视应用程序的可用性，至于扩展性、可维护性关注都不是特别高。所以OSGI方面的需求人员不是很大
再说说应用场景
1. 关于OSGI的历史。OSGI前期主要是设计于嵌入式应用程序。由一个平台支撑可热插拔的应用程序模块。现在OSGI企业级规范已经发布，意味着OSGI也可以应用到企业级开发过程中。
2. 由于OSGI本身提供的便利的模块化的功能，个人觉得主要应用于需求经常变化的应用中。这里不只有嵌入式、桌面程序也包括企业级开发的应用场景。由于需求的不断变化导致各个模块需要升级的需求，可以在动态的更新和良好的扩展性OSGI框架下有很好的支持。
顺便说下，OSGI下的设计是非常有深度的。稍微有别于一般的应用程序设计。动态的更新和良好的扩展性，这个主要是OSGI框架为开发提供支持。但是并非说使用了OSGI就有动态的更新和良好的扩展性。我现在看过的OSGI上的设计，除了一些eclipse插件方面设计非常出色，但更多见到过的软件被设计的非常难于扩展和升级维护。