wordpress 4.5.9 漏洞wordpress tag链接优化
其实OSGi原本是为了解决家庭网络或者嵌入式设备由于本身的限制(CPU, 内存, 带宽等)而出的一个解决方案, 是一个轻量级的框架. 但现在OSGi已经远远的超过了它的原来的的功能. OSGi已经应用于移动通讯, 汽车, 电信, 嵌入设备, PC桌面和服务器等众多领域. 由于它的开放和简单的风格, 吸引越来越多的著名公司加入, 使OSGi也愈加强大和开放。
我不了解OSGi在其他领域的应用, 只是由于要使用Eclipse, 所以也只对OSGi在PC桌面方面的应用做了些熟悉和了解. 和OSGi一样, Eclipse也是个开放的平台, 它的基础就是OSGi服务平台(Services Platform), 架构在OSGi上的Eclipse具有融合其他应用和组件的能力, 使不同的组件能够运行在一个JVM(Java Virtual Machine)上, 使它们之间能够协同工作, 占用较少得内存和CPU时间, 而且能够由平台管理组件的全生命周期的活动, 可以说一切都在控制之中。
开放服务网关协议 (Open Services Gateway Initiative)，简称 OSGi,为网络服务定义了一个标准的、面向服务的计算环境，为用户提供了开放的、面向服务组件的、易于部署的编程模型，这个编程模型允许用户将定义好的接口规范绑定到 OSGi 运行环境中的特定Service，在构件 SOA 面向服务为中心的企业应用的过程中，OSGi 技术正发挥越来越重要的作用。在本文中，将介绍 OSGi 的概念和体系结构，并且利用 Eclipse 3.2 开发一个基于 OSGi 规范的服务应用 Bundle。通过学习本文，读者可以了解到如何开发和部署基于 OSGi 规范的 Bundle 应用。
OSGi 规范简介
OSGi 联盟建立于 1999 年，是一个非赢利机构，旨在建立一个开放的服务规范。OSGi 规范为网络服务定义了一个标准的、面向组件的计算环境，它最初的目的就是为各种嵌入式设备提供通用的软件运行平台，屏蔽设备操作系统与硬件区别的中间件平台，通过这个平台，可以对不同软件商提供的应用(OSGi 中称为 Bundle)进行组件的生命周期管理的能力，如应用组件可以从运行中被安装、升级或者移除而不需要中断设备的操作，应用组件可以动态的发现和使用其他库或者应用程序。由于 OSGi 技术具有服务组件模块化、动态加载应用等优点，正被越来越多的领域关注，如嵌入设备制造业、汽车制造业、企业应用等。目前，OSGi 联盟发布的最新的 OSGi 服务规范为 4.0，读者可以查阅参考资料了解详细信息。
  |
|
OSGi 体系结构
OSGi 的体系架构是基于插件式的软件结构，包括一个 OSGi 框架和一系列插件，在 OSGi中，插件称为 Bundle，其中，OSGi 框架规范是 OSGi 规范的核心部分，它提供了一个通用的、安全可管理的 Java 框架，通过这个框架，可以支持 Bundle 服务应用的部署和扩展。Bundle 之间可以通过 Import Package 和 Require-Bundle 来共享 Java 类，在 OSGi 服务平台中，用户通过开发 Bundle 来提供需要的功能，这些 Bundle 可以动态加载和卸载，或者根据需要远程下载和升级。OSGi 体系结构图如图 1 所示：
图示1 OSGi 体系结构
其中：
Execution Environment：
Bundle 应用所倚赖运行的 Java 执行环境，如 J2SE-1.4、CDC-1.0 等都是可用的执行环境。
Modules：
模块层定义了 Bundle 应用的加载策略。OSGi 框架是一个健壮并且严格定义的类加载模型。在大多数 Java 应用中，通常只有一个单独的 ClassPath，它包含了所有的 Java 类文件和资源文件，OSGi基于Java技术，对于每个实现了 BundleActivator 接口的 Bundle 应用，为它生成一个单独的 ClassLoader，使得 Bundle 应用的组织更加模块化。
Life Cycle：
生命周期层可以动态地对 Bundle 进行安装、启动、停止、升级和卸载等操作。该层基于模块层，提供了一组 API 来控制 Bundle 应用的运行时操作。
Service Registry 和 Services：
OSGi 服务层定义了一个集成在生命周期层中的动态协作模型，是一个发布、动态寻找、绑定的服务模型。一个服务通常是一个 Java 对象实现了特定的服务接口，并且通过服务注册，被绑定到 OSGi 的运行环境中。Bundle 应用可以注册发布服务，动态绑定服务，并且在服务注册状态改变时，可以接受到事件消息等。
Security：
OSGi 的安全管理是基于 Java2 安全体系的，贯穿在 OSGi 平台的所有层中，它能够对部署在 OSGi 运行环境中的 Bundle 应用进行详细的管理控制。
|
|
Bundle 生命周期的状态
在一个动态扩展的 OSGi 环境中，OSGi 框架管理 Bundle 的安装和更新，同时也管理 Bundle 和服务之间的依赖关系。一个 Bundle 可能处于以下六个状态，如图 2 所示：
图示 2 Bundle 状态图
INSTALLED：安装完成，本地资源成功加载。
RESOLVED：依赖关系满足，这个状态意味该Bundle要么已经准备好运行，要么是被停止了。
STARTING：Bundle正在被启动，BundleActivator的start()方法已经被调用但是还没有返回。
STOPPING：Bundle正在被停止，BundleActivator的stop()方法已经被调用但是还没有返回。
ACTIVE：Bundle 被成功启动并且在运行。
UNINSTALLED：bundle被卸载并且无法进入其他状态。
Bundle接口定义了getState()方法来返回Bundle的状态。
|
|
OSGi 标准服务
在 OSGi 平台之上，OSGi 联盟定义了很多服务。服务是由一个 Java Interface 来定义的，Bundle 可以实现这个接口并且把服务注册到服务注册表中去，用户可以从注册表中找到需要的服务来使用，并且可以响应特定服务的状态改变，如服务注册和服务取消。下面简单介绍一下 OSGi Release 4 的一些主要服务。OSGi 框架提供了权限管理服务，包管理服务和最初加载系统服务。这些服务是 OSGi 框架的一部分并且管理着 OSGi 框架的运作。
Permission Admin Service：权限管理是指 Bundle 是否许可其他的 Bundle 的代码。当前的或者其他的 Bundle 的权限可以通过这个服务来操作，一旦被设定权限，马上就生效。 Package Admin Service：Bundle 之间可以共享包内的 Java 类和资源，bundle 的更新可能需要 OSGi 框架重新解析 Bundle 之间的依赖关系，这个服务提供了 OSGi 服务平台中包的共享状态信息。
Start Level Service：Start Level是指一些在特定Bundle起动之前必须运行或者初始化的一系列 bundle。Start Lever Service 可以设置当前OSGi服务框架初始的Start Level，并且可以指定和查询特定Bundle的Start Level。
开放服务网关协议 (Open Services Gateway Initiative)，简称 OSGi,为网络服务定义了一个标准的、面向服务的计算环境，为用户提供了开放的、面向服务组件的、易于部署的编程模型，这个编程模型允许用户将定义好的接口规范绑定到 OSGi 运行环境中的特定Service，在构件 SOA 面向服务为中心的企业应用的过程中，OSGi 技术正发挥越来越重要的作用。在本文中，将介绍 OSGi 的概念和体系结构，并且利用 Eclipse 3.2 开发一个基于 OSGi 规范的服务应用 Bundle。通过学习本文，读者可以了解到如何开发和部署基于 OSGi 规范的 Bundle 应用。
OSGi 规范简介
OSGi 联盟建立于 1999 年，是一个非赢利机构，旨在建立一个开放的服务规范。OSGi 规范为网络服务定义了一个标准的、面向组件的计算环境，它最初的目的就是为各种嵌入式设备提供通用的软件运行平台，屏蔽设备操作系统与硬件区别的中间件平台，通过这个平台，可以对不同软件商提供的应用(OSGi 中称为 Bundle)进行组件的生命周期管理的能力，如应用组件可以从运行中被安装、升级或者移除而不需要中断设备的操作，应用组件可以动态的发现和使用其他库或者应用程序。由于 OSGi 技术具有服务组件模块化、动态加载应用等优点，正被越来越多的领域关注，如嵌入设备制造业、汽车制造业、企业应用等。目前，OSGi 联盟发布的最新的 OSGi 服务规范为 4.0，读者可以查阅参考资料了解详细信息。
|
|
OSGi 体系结构
OSGi 的体系架构是基于插件式的软件结构，包括一个 OSGi 框架和一系列插件，在 OSGi中，插件称为 Bundle，其中，OSGi 框架规范是 OSGi 规范的核心部分，它提供了一个通用的、安全可管理的 Java 框架，通过这个框架，可以支持 Bundle 服务应用的部署和扩展。Bundle 之间可以通过 Import Package 和 Require-Bundle 来共享 Java 类，在 OSGi 服务平台中，用户通过开发 Bundle 来提供需要的功能，这些 Bundle 可以动态加载和卸载，或者根据需要远程下载和升级。OSGi 体系结构图如图 1 所示：
图示1 OSGi 体系结构
其中：
Execution Environment：
Bundle 应用所倚赖运行的 Java 执行环境，如 J2SE-1.4、CDC-1.0 等都是可用的执行环境。
Modules：
模块层定义了 Bundle 应用的加载策略。OSGi 框架是一个健壮并且严格定义的类加载模型。在大多数 Java 应用中，通常只有一个单独的 ClassPath，它包含了所有的 Java 类文件和资源文件，OSGi基于Java技术，对于每个实现了 BundleActivator 接口的 Bundle 应用，为它生成一个单独的 ClassLoader，使得 Bundle 应用的组织更加模块化。
Life Cycle：
生命周期层可以动态地对 Bundle 进行安装、启动、停止、升级和卸载等操作。该层基于模块层，提供了一组 API 来控制 Bundle 应用的运行时操作。
Service Registry 和 Services：
OSGi 服务层定义了一个集成在生命周期层中的动态协作模型，是一个发布、动态寻找、绑定的服务模型。一个服务通常是一个 Java 对象实现了特定的服务接口，并且通过服务注册，被绑定到 OSGi 的运行环境中。Bundle 应用可以注册发布服务，动态绑定服务，并且在服务注册状态改变时，可以接受到事件消息等。
Security：
OSGi 的安全管理是基于 Java2 安全体系的，贯穿在 OSGi 平台的所有层中，它能够对部署在 OSGi 运行环境中的 Bundle 应用进行详细的管理控制。
|
|
Bundle 生命周期的状态
在一个动态扩展的 OSGi 环境中，OSGi 框架管理 Bundle 的安装和更新，同时也管理 Bundle 和服务之间的依赖关系。一个 Bundle 可能处于以下六个状态，如图 2 所示：
图示 2 Bundle 状态图
INSTALLED：安装完成，本地资源成功加载。
RESOLVED：依赖关系满足，这个状态意味该Bundle要么已经准备好运行，要么是被停止了。
STARTING：Bundle正在被启动，BundleActivator的start()方法已经被调用但是还没有返回。
STOPPING：Bundle正在被停止，BundleActivator的stop()方法已经被调用但是还没有返回。
ACTIVE：Bundle 被成功启动并且在运行。
UNINSTALLED：bundle被卸载并且无法进入其他状态。
Bundle接口定义了getState()方法来返回Bundle的状态。
|
|
OSGi 标准服务
在 OSGi 平台之上，OSGi 联盟定义了很多服务。服务是由一个 Java Interface 来定义的，Bundle 可以实现这个接口并且把服务注册到服务注册表中去，用户可以从注册表中找到需要的服务来使用，并且可以响应特定服务的状态改变，如服务注册和服务取消。下面简单介绍一下 OSGi Release 4 的一些主要服务。OSGi 框架提供了权限管理服务，包管理服务和最初加载系统服务。这些服务是 OSGi 框架的一部分并且管理着 OSGi 框架的运作。
Permission Admin Service：权限管理是指 Bundle 是否许可其他的 Bundle 的代码。当前的或者其他的 Bundle 的权限可以通过这个服务来操作，一旦被设定权限，马上就生效。 Package Admin Service：Bundle 之间可以共享包内的 Java 类和资源，bundle 的更新可能需要 OSGi 框架重新解析 Bundle 之间的依赖关系，这个服务提供了 OSGi 服务平台中包的共享状态信息。
Start Level Service：Start Level是指一些在特定Bundle起动之前必须运行或者初始化的一系列 bundle。Start Lever Service 可以设置当前OSGi服务框架初始的Start Level，并且可以指定和查询特定Bundle的Start Level。