定义
这个框架实现了一个优雅、完整和动态地组价模型。应用程序（称为bundle）无序重新引导可以被远程安装、启动、升级和卸载。
为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。
OSGi联盟已经开发了例如像HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。
OSGi的主要职责就是为了让开发者能够创建动态化、模块化的Java系统。
OSGi 框架
OSGi框架从概念上可以分为三层：模块层、生命周期层和服务层。
- Module Layer：模块层主要涉及包及共享的代码；
- Lifecycle Layer：生命周期层主要涉及Bundle的运行时生命周期管理；
- Service Layer：服务层主要涉及模块之间的交互和通信。
模块层
模块层是 OSGi 框架中最基础的部分。
OSGi 的模块化，是通过为 Jar 包添加metadata 来定义哪些类该暴露，哪些类该隐藏，其控制单元叫做 Bundle（jar 包）。
Bundle
首先，必须先了解一个基本概念——什么是Bundle？
如何定义 Bundle
通常一个 MANIFEST.MF 文件的内容如下：
Bundle-ManifestVersion: 2
Bundle-Name: Util
Bundle-SymbolicName: com.ibm.director.la.util
Bundle-Version: 1.0.0
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Import-Package: org.osgi.framework;version="1.3.0"
Export-Package: com.ibm.director.la.util;uses:="org.osgi.framework"
Bundle-ClassPath: lib/junit.jar,
MANIFEST.MF 文件存储的实际上是 Bundle 的元数据。
元数据的内容可以精确的定义 Bundle 的各种特征，同时能更好的对 Bundle 进行标识同时帮助用户对Bundle进行理解。
生命周期层
生命周期层让你能够从外部管理应用或者建立能够自我管理的应用（或者两者的结合），并且给了应用本身很大的动态性。
前面已经了解了 Bundle 的概念和作用。但是要真正使用 Bundle，需要使用生命周期层的API，来和OSGi框架的生命周期层进行交互。
下图为 Bundle 生命周期的状态转移图：
重要接口
- BundleActivator：让你能够捕捉bundle的start和stop事件，并对这两个事件作出自定义的反应。
- BundleContext：一个bundle在框架中的执行时上下文，这个上下文提供了和框架进行交互的方法。
- Bundle：在逻辑上表示了一个bundle，OSGi环境中的一个物理bundle对应了一个bundle对象。该对象中包含了bundle的基本信息和bundle生命周期的控制接口。
服务层
一个OSGi 服务就是注册到 OSGi 框架中的一个 Java 对象。注册的时候可以设置这个 Service 的属性。而在获取 Service的时候可以根据属性进行过滤。
Bundle 可以通过 Bundle的上下文去注册Service或去查询Service。
一个提供服务的bundle可以发布POJO作为服务的实体；一个使用服务的bundle可以通过这个注册表找到和绑定服务。
发布服务
例
Dictionary metadata = new Properties();
metadata.setProperty(“name”, “LSE”);
metadata.setProperty(“currency”, Currency.getInstance(“GBP”));
metadata.setProperty(“country”, “GB”);
ServiceRegistration registration = bundleContext.registerService(interfaces, new LSE(), metadata);
也就是说，如果这个 Bundle 已经不在框架执行环境中存在，那么这个对象也不应该存在了，“皮之不存毛将焉附”就是这个道理。
试想如果这个 ServiceRegistration 共享给了其他的 bundle（具体的说就是其他bundle中存在对这个对象的引用），那么发布服务的那个bundle即使被移除了，由于其他bundle中的引用依然存在，那么垃圾处理机制不会抹去这个对象，这样不但于理不合，而且实际上这个对象也是不可用的，因为这个对象所依存的bundle已经不在了。
代码中的参数new LSE()是一个POJO，这个对象不需要实现任何OSGi类型或者使用标注，只要满足服务约定（这里就是接口）就可以了。
此外，如果在删除发布的服务之前bundle停止了，框架会帮助你删除这些服务。
发现和绑定服务
bundleContext.getServiceReference(StockListing. class.getName());
注意这里的reference是服务对象的间接引用，可是为什么要用间接引用而不直接返回那个实际的服务对象呢？
实际上是为了将服务的使用和服务的实现进行解耦，将服务注册表作为两者的中间人，达到跟踪和控制服务的目的，同时还可以在服务消失了以后通知使用者。
这个方法的返回类型是ServiceReference，它可以在bundle之间互享，因为它和使用服务的bundle的生命周期无关。
本文转自静默虚空博客园博客，原文链接：http://www.cnblogs.com/jingmoxukong/p/4546947.html，如需转载请自行联系原作者
