osgiOSGI的书籍

osgi框架与struts2框架区别

OSGi(Open Service Gateway Initiative)技术是面向Java的动态模型系统。

OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。

Java提供在多个平台支持产品的可移植性。

OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。

这些组件能够组装进一个应用和部署中。

而struts是一种web MVC框架。

两者不一样的东西。

OSGI是什么

今天在看公司的文档的时候，发现了好多不懂得名词。

特别是对OSGI这个词比较的感兴趣，就到网上去查了一下他的一些资料。

以我的技术水平，看了半天愣是没看明白。

尽管没有看明白，但还是要写下来，免得下次要找资料的时候还是要到处乱找。

OSGI(Open Service Gateway Initiative) 它可以被看做OSGi Alliance组织；也可以认为是该组织制定的一个基于Java a) 您可以在不重启容器的情况下，动态地安装、卸载、启动和停止您的应用程序中的不同模块； b) 对于您应用程序中的某一特定模块，容器可以同时运行该模块的多个版本； c) OSGi为开发嵌入式应用、移动应用、富互联网应用(RIA)提供了非常优秀的基础架构 个模块负责视图层，另一个模块负责DAO层，第三个模块负责数据访问层，如果我们使用OSGi容器来管理这些模块之间的交叉依赖，我们就可以在不用重启该 Web应用的前提下，将DAO层从速度较慢的升级到速度较快的DAO。

附：一些OSGI的资料你好,OSGI 这是一个OSGI的专题汇总。

里面的资料还是很不错的 OSGI Alliance 这个是OSGI的官方网站。

不过是英文的 ^_^

java程序员需要了解OSGi吗

在该框架之上，OSGi联盟定义了很多服务。

这些服务通过一个Java接口指定。

bundles能够实现这个接口，并在注册服务层注册该服务。

服务的客户端在注册库中找到它，或者当它出现或者消失时做出响应。

这个同SOA架构使用Web服务进行发布的方式相似。

两者主要不同是Web服务总是需要传输层，这个使它比采用直接方法调用的OSGi服务慢几千倍。

同时，OSGi组件能够对这些服务的出现和消失做出响应。

的信息可以从OSGi服务平台发行版本4手册或者PDF下载中找到。

需要注意的是每一种服务都是抽象定义的，与不同计算机服务商的实现相独立。

什么事OSGi？

OSGi服务平台提供在多种网络设备上无需重启的动态改变构造的功能。

为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。

OSGi联

OSGI

盟已经开发了为例如象HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能标准组件接口。

这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。

然而，服务接口能够基于专有权基础上开发。

　　因为OSGi技术为集成提供了预建立和预测试的组件子系统，所以OSGi技术使你从改善产品上市时间和降低开发成本上获益。

因为这些组件能够动态发布到设备上，所以OSGi技术也能降低维护成本和拥有独一无二的新的配件市场机会。

OSGi规范的核心组件是OSGi框架。

这个框架为应用程序（被叫做组件（bundle））提供了一个标准环境。

整个框架可以划分为一些层次：

OSGI

　　L0：运行环境

　　L1：模块

　　L2：生命周期管理

　　L3：服务注册

　　还有一个无处不在的安全系统渗透到所有层。

　　L0层执行环境是Java环境的规范。

Java2配置和子规范，象J2SE，CDC，CLDC，MIDP等等，都是有效的执行环境。

OSGi平台已经标准化了一个执行环境，它是基于基础轮廓和在一个执行环境上确定了最小需求的一个小一些的变种，该执行环境对OSGi组件是有用的。

　　L1模块层定义类的装载策略。

OSGi框架是一个强大的具有严格定义的类装载模型。

它基于Java之上，但是增加了模块化。

在Java中，正常情况下有一个包含所有类和资源的类路径。

OSGi模块层为一个模块增加了私有类同时有可控模块间链接。

模块曾同安全架构完全集成，可以选择部署到部署封闭系统，防御系统，或者由厂商决定的完全由用户管理的系统。

　　L2生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles。

这些bundles依赖于于具有类装载功能的模块层，但是增加了在运行时管理这些模块的API。

生命周期层引入了正常情况下不属于一个应用程序的动态性。

扩展依赖机制用于确保环境的操作正确。

生命周期操作在安全架构保护之下，使其不受到病毒的攻击。

　　L3层增加了服务注册。

服务注册提供了一个面向bundles的考虑到动态性的协作模型。

bundles能通过传统的类共享进行协作，但是类共享同动态安装和卸载代码不兼容。

服务注册提供了一个在bundles间分享对象的完整模型。

定义了大量的事件来处理服务的注册和删除。

这些服务仅仅是能代表任何事物的Java对象。

很多服务类似服务器对象，例如HTTP服务器，而另一些服务表示的是一个真实世界的对象，例如附近的一个蓝牙手机。

这个服务模块提供了完整安全保障。

该服务安全模块使用了一个很聪明的方式来保障bundles之间通信安全。

编辑本段安全协议

　　安全机制是建立在Java和Java2安全模型基础之上。

Java语言的设计对很多结构进行了限

制。

例如病毒中经常遇到的缓存溢出是不可能发生的。

Java语言中的访问控制符限制了代码可见性。

　　OSGi平台通过使用私有类（在Java中不能用标准方式使用的机制）扩展了该模型。

Java2安全模型提供了一个完整模块检查代码对于资源的可访问性。

OSGi增加了完全动态的权限管理，简化了操作者和系统管理员的工作。

　　OSGi联盟已经定义了很多协议服务，这些服务将外部协议映射为OSGi服务。

HTTP服务(HttpService)该HTTP服务是servlet运行器。

bundles提供servlets，这些服务端小程序基于HTTP协议成为可用的。

OSGi服务平台的动态更新功能使HTTP服务成为一个非常具有吸引力的Web服务器，它能伴随着新的servlet被更新，如果需要可以远程更新而无需重启。

　　UPnP服务(UPnPService)通用即插即用（UPnP）是一个正在形成中的消费电子标准。

OSGi中的UPnP服务在一个UPnP网络上将设备映射到服务注册中。

同样，它也可以将OSGi服务映射到UPnP网络。

这是发布版本3中的推荐规范。

　　DMT管理(DMTAdmin)开放移动联盟(OMA)基于设备管理树为移动设备管理提供了一个完整规定。

DMT管理服务定义该树如何被访问和/或者在OSGi服务平台中被扩充。

编辑本段标准服务

　　在该框架之上，OSGi联盟定义了很多服务。

这些服务通过一个Java接口指定。

bundles能够实

OSGI

现这个接口，并在注册服务层注册该服务。

服务的客户端在注册库中找到它，或者当它出现或者消失时做出响应。

这个同SOA架构使用Web服务进行发布的方式相似。

　　两者主要不同是Web服务总是需要传输层，这个使它比采用直接方法调用的OSGi服务慢几千倍。

同时，OSGi组件能够对这些服务的出现和消失做出响应。

更多的信息可以从OSGi服务平台发行版本4手册或者PDF下载中找到。

需要注意的是每一种服务都是抽象定义的，与不同计算机服务商的实现相独立。

编辑本段框架服务

　　OSGi框架提供一个权限管理服务，一个包管理服务和一个开始级别服务。

这些服务是一个可

OSGI

选部分，指示框架的操作。

框架服务如下：

　　权限管理(PermissionAdmin)目前或者将来的bundles的权限通过这种服务进行维护。

一旦设置了它们，权限服务立即激活。

　　包管理(PackageAdmin)bundles同类和资源分享包。

bundles的更新可能需要系统重新计算这些依赖。

这个包管理服务提供关于系统的实际包分享状态和能够刷新已经共享的包。

也就是，取消依赖和重新计算依赖。

　　启动级别(StartLevel)启动级别是一个bundles集合，它们应该同时运行或者应该在其它已经启动以前被初始化。

启动级别服务设置当前的启动级别，为每个bundle排一个启动级别和审核当前的设置。

　　URL处理者(URLHandler)Java环境为URL处理者支持一个提供者模型。

然而，这是一个单件，不可能在一个象OSGi可能有很多提供者的协作环境上使用它。

此服务规范使任何组件提供额外的URL处理者。

编辑本段系统服务

　　系统服务提供水平功能，它在每个系统是必须的。

日志服务，配置管理服务，设备访问

OSGI

服务，用户管理服务，IO连接器服务和参数服务都是系统服务的一个方面。

　　日志服务(LogService)日志信息，警告，调试或者错误信息通过日志服务来处理的。

它接受日志实体并分派这些实体到订阅了这个信息的其他bundles。

　　配置管理服务(ConfigurationAdminService)该服务提供一个设置和获取配置信息的灵活、动态模型。

　　设备访问服务(essService)设备访问是OSGi为一个新的设备匹配一个驱动，并自动下载一个实现该驱动的bundles的机制。

这个可用作即插即用方案。

　　用户管理服务(UserAdminService)该服务使用一个用于授权和验证目的的用户信息数据库。

　　IO连接器服务(IOConnectorService)该IO连接器服务实现了CDC/CLDCjavax.microedition.io包，并作为一个服务。

该服务允许bundles提供新的可交换协议模式。

　　参数服务(PreferencesService)该服务提供了参数层级数据库的可访问性，同Windows注册表或者Java参数类相似。

　　组件运行时服务(ComponentRuntime)服务的动态特性--它们能够在任何时间来去自由--使编写软件变得更难。

组建运行时规范通过提供一个基于依赖声明的XML文件来简化处理这些动态方面。

　　部署管理服务(DeploymentAdmin)OSGi的主要部署格式是bundle，它是一个JAR/ZIP文件。

部署管理提供第二种可选格式：部署包。

部署包能够将bundles和相应资源联接成可被安装和卸载的单个交付。

完整的资源处理器模型允许用户代码扩充资源类型。

　　事件管理服务(EventAdmin)很多OSGi事件有特定的类型化的接口，使其很难接收和过滤事件。

事件服务提供一个泛化的基于主题的事件机制。

这个规范包括为所有已存框架和服务事件的映射。

　　应用程序管理服务(ApplicationAdmin)OSGibundle模型不同于依赖于启动和关闭形式的典型的桌面或者移动电话应用程序模型。

该应用程序管理服务提供了传统应用程序模型和它所要求的管理设施。

编辑本段社会机构OSGI

　　OSGI是Open Service Gateway Initiative的简称，该组织建立于1999年，是一个非赢利机构，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准。

编辑本段规范介绍

　　OSGi规范为网络服务定义了一个标准的、面向组件的计算环境。

将OSGi服务平台添加到一个网络设备中，可以为其增加在网络的任何地方管理组件的生命周期的能力。

软件组件可以从运行中被安装、升级或者移除而不需要中断设备的操作。

软件组件可以动态的发现和使用其他库或者应用程序。

通过这个平台，软件组件可以作为商品在柜台中出售以及在家里开发。

OSGi联盟已经开发出很多标准组件接口，从普通的功能如：HTTP server、configuration、 logging、security、user administration、XML等等很多。

一致的插件机制可以使这些组件满足不同买主的不同需求。

　　软件组件架构致力于一个软件开发中越来越大的问题：大量的基础配置需要开发和维护。

标准化的OSGI组件架构显然可以简化这个配置过程。

第一章 引言

　　OSGi（Open Service Gateway Initiative）最初的目的就是为各种嵌入式设备提供通用的软件运行平台，即可以屏蔽设备操作系统与硬件区别的中间件平台。

PC基本上被 Wintel架构垄断，运行在PC上的应用程序完全可以在另一台PC上运行；但对于其他设备来说就不同，它们的硬件平台可能完全不同，其操作系统也是来自不同厂商，所以任何设备上的应用程序都需要定制，于是就产生了对中间件平台的需求。

　　OSGi并不是专为家庭网络而制定的，除了住宅网关，像车载电脑等其他移动嵌入式设备也都可以通过OSGi接入，获取不同的应用服务。

它为服务供应商、软件供应商、网关开发人员以及设备供应商提供了一个开放、通用的架构，使它们能互动地开发、部署和管理服务。

其软件环境基于Sun的 JAVA虚拟机，并不涉及具体的连接协议。

对于任何新设备，它都能够灵活地将其纳入现有网络。

可以使用OSGi的对象包括各种数字和模拟的机顶盒、服务网关、有线电视电缆调制解调器、消费类电子产品、PC、工业计算机、汽车等。

　　因为OSGi基于JAVA技术，而JAVA最大的好处就是平台无关性。

在不同类型的住宅网关设备上都可以实现OSGi软件。

而且OSGi规范可以与各种设备访问标准桥接（如图1所示），比如遵循OSGi的系统可以很好地部署和管理Jini服务，它可以提供Jini设备与服务提供商之间的交互。

对于像 HAVi、UPnP等基于非JAVA技术的标准和规范，OSGi也可以提供与它们沟通的桥梁。

第二章 OSGi规范介绍

　　2.1 OSGi规范的体系结构

　　在OSGi规范中提供了一个参考的体系架构[1]，也基本上体现了OSGi的设计初衷。

　　OSGi的体系架构是基于这样一个模型的：经营者管理着一个潜在的巨大的服务网络平台。

OSGi规范假设这个服务平台是完全被这个经营者控制，并且经营者使用该服务平台去运行来自不同服务提供者提供的服务。

然而这只是一个场景，还有其他模型，例如PC机的部署，工业应用（如，移动电话基站是一个管理中心完全控制着各个方面），中间件模型等。

OSGi最广泛的应用是在网络化的服务。

除了参考模型之外，规范之中还提到了其他的一些模型。

请参考OSGi 3.0规范[1]。

　　2.1.1 OSGi参考体系架构的特点

　　1． 商业驱动：经营者的观点驱动OSGi的体系架构。

　　2． 完美：体系架构必须是足够完善和详细的，以致允许开发商生产出健壮的产品。

　　3． 不受限的：由于经营者所操作的服务平台在性能和网络环境的变化是非常大的。

　　4． 开放：标准不是为一个具体的系统而设计的，OSGi参考体系架构必须考虑和支持许多不同的场景。

　　2.1.2 OSGi参考体系架构所涉及到实体

　　1. 服务平台：一个JAVA虚拟机的实例，一个OSGi框架结构，和运行着的服务包的集合。

　　2. 服务平台服务器(SPS)：驻留一个或多个服务平台的硬件。

　　3. 运营商：掌控许多服务平台的组织。

　　4. 服务应用：一套软件包，文档和支撑软件所组合起来的应用，这些应用向终端用户提供服务。

　　5. 服务用户：获取服务应用服务的用户。

　　6. 服务提供者：开发服务应用并且通过服务部署管理器部署到服务平台上。

　　7. 服务部署管理器：部署和部分管理一个或多个服务提供者提供的服务应用。

　　8. 服务运行支持：支撑软件和硬件，它们并不驻留在服务平台服务器上，但是在运行服务应用时需要它们。

　　9. 服务集成者：负责确保来自不同服务提供者的服务应用的集成。

　　10. 服务开发者：开发服务应用。

　　11. 制造商：制造服务平台服务器

　　12. 拥有者：服务平台服务器拥有者。

　　13. 收费提供者：接受帐户信息，并且提供统一的帐单给服务消费者。

　　14. 网络提供者：提供服务平台的网络链接。

　　15. 证书授权：管理证书的组织，这些证书被用来鉴别系统，个人和组织。

　　首先是制造商制造服务平台服务器，拥有者从制造商处购买服务平台服务器，网络提供商提供服务平台服务器和互联网的接入。

服务平台的运营商使用网路提供者的接入基础件接入服务平台服务器，同时服务平台经营者控制着一个或多个运行在服务平台服务器的服务平台。

另一方面，服务平台经营者许可服务部署管理器去部署服务应用到服务平台上。

　　其次服务开发者开发服务应用，一个服务应用可能包含多个服务包而这些服务包是真正运行在服务平台上的。

服务提供者从服务开发者处得到服务应用并且可能会委托服务运行支撑系统去支撑该服务应用在服务平台上的运行。

服务集成者将服务提供者获取的服务应用和支持系统集成起来由服务部署管理器部署到服务平台上。

　　最后服务消费者订阅服务提供者提供的服务。

　　更有意思的是这里还有一个服务用户实体，从图中可以看出服务消费者可以包含多个服务用户，服务用户是真正接受服务的实体。

也就是说服务消费者是一个虚的实体，多个服务用户可以消费同一个服务消费者订阅的服务。

这好比不同的人可以通过同一个电话打电话一样。

这无疑提高了OSGi规范灵活性。

OSGI的书籍

1.《深入理解OSGi:Equinox原理、应用与最佳实践》 作者：周志明 & 谢小明，出版时间：2013-2-1. 内容简介：本书共14章，分4个部分。

第一部分（第1章）：走近OSGi，主要介绍了什么是OSGi以及为什么要使用OSGi。

第二部分（第2～4章）：OSGi规范与原理，对最新的OSGi R5.0中的核心规范进行了全面的解读，首先讲解了OSGi模块的建立、描述、依赖关系的处理，然后讲解了Bundle的启动原理和调度管理，最后讲解了与本地及远程服务相关的内容。

第三部分：OSGi服务与Equinox应用实践（第5～11章），不仅详细讲解了OSGi服务纲要规范和企业级规范中最常用的几个子规范和服务的技术细节，还通过一个基于Equinox的BBS案例演示了Equinox的使用方法，最重要的是还通过源码分析了Equinox关键功能的实现机制和原理。

第四部分：最佳实践（第12～14章），总结了大量关于OSGi的最佳实践，包括从Bundle如何命名、模块划分、依赖关系处理到保持OSGi动态性、管理程序启动顺序、使用API基线管理模块版本等各方面的实践技巧，此外还介绍了Spring DM的原理以及如何在OSGi环节中进行程序测试。

2.《Eclipse RCP与Spring OSGi:技术详解与最佳实践》 作者：陆阳，出版时间：2013-1-1. 内容简介：全书共分3个部分：基础篇（第1~5章）详细介绍了与Eclipse RCP相关的一系列核心概念、Eclipse RCP开发环境的搭建，以及SWT、JFace、Forms、Nebula和WindowBuilder等Eclipse RCP开发所常用的界面编程技术；高级篇（第6~12章）系统讲解了Eclipse RCP应用开发的基础知识、Eclipse RCP软件产品各个组成部分的构建方法，以及Eclipse RCP扩展的使用和扩展点的开发，掌握这些技术知识的读者将能构建一个结构完整的Eclipse RCP软件，并解决软件开发过程中遇到的故障；实战篇（第13~15章）详细讲解了Eclipse RCP与Spring OSGi框架、Hibernate ORM框架、JPA规范、Maven工具的整合，以及它与Java的模块化设计。

3.osgi中文社区 简介：由北京大学软件工程国家工程研究中心“软件协同研发支撑技术”组维护的一个模块化动态化开发技术的公益社区。

初学者、进阶者和大牛都可以在这里分享技术和经验，自由的交流和学习，在贡献和收获中充实自己。

为更多的学生、研究者和从业者提供更广阔的交流平台。