前言
OSGI的精髓就是通过一个个的模块构建起整个应用系统，相对于普通开发模式而已，OSGI会强制开发人员对系统进行模块划分。因此如何对系统进行模块化的划分就显得很重要了，基本原则就是高内聚低耦合（在bundle内部高内聚，在bundle之间低耦合），每个团队负责指定的模块开发。指定好每个bundle的边界和职责，然后分别进行开发实现，这种方式非常有利于并行开发，提高工作效率。
传统的MVC开发模式一般会把系统分为Controller层、Service层、Dao层等等，每层一般会打成一个jar包。而OSGI的模块化概念一般建议以具体的业务功能进行模块划分，比如：登陆模块、a业务模块、b业务模块、数据操作模块（类似于Dao层）等待，各个模块之间有依赖关系，并且这些模块是可以独立更新的（热更新）。
OSGI的模块层规范，主要就是对如何进行模块化指定了相关规范，简单的理解就是如果配置模块的元数据文件MANIFEST.MF。
MANIFEST.MF配置详解
元数据文件MANIFEST.MF的配置信息分为三类：描述信息配置、唯一识别配置、可见性配置。描述信息配置：主要作用就是让使用者了解这个bundle，OGGI框架不会直接使用这些配置信息；唯一识别配置：这类配置信息主要作用就是用于在OSGI框架中唯一确定一个bundle；可见性配置：OSGI的模块化分为物理模块化和逻辑模块化，物理模块化的理解很简单就是把那些类放到bundle对应的jar包中，逻辑模块化就是bundle对内对外的可见边界，可见性配置的主要作用就是如何实现bundle的逻辑模块化。
描述信息配置
这部分是可选的，主要提供一些描述信息，方便使用者查阅。OGGI框架不会直接使用这些配置信息，也没有太多注意事项，根据业务需要选择性的使用即可：
Bundle-Name: my osgi test //根据自己的喜好随便写
Bundle-Description: do some test //描述信息，该模块是做什么的
Bundle-DocURL:http://www.xxxx.com //帮助文档地址
Bundle-Category: test //Bundle分类，随便写
Bundle-Vender：sky //Bundle供应商，是谁开发的
Bundle-ContactAddress: //供应商 联系地址
Bundle-Copyright: xxxx //供应商版权信息
唯一识别配置
是识别bundle的必须配置的信息。一共三个配置项：
Bundle-SymbolicName: com.sky.osgi.test
Bundle-Version: 1.0.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName
Bundle-SymbolicName是Bundle唯一标识符，一般与java包的命名规则类似（域名反转），也可以选择其它命名方式，主要保证名字的唯一性即可。
Bundle-Version定义了Bundle的版本号，理论上Bundle-SymbolicName和Bundle-Version一起才可以保证在同一个OSGI运行框架下的唯一性。配置值 一般采用x.x.x的方式，其中x是一个数字，数字越大说明版本越新，另外也可以是采用1.1.1.beta表示版本号。
Bundle-ManifestVersion与OSGI规范的版本有关，不用过多解读，只需要记住是强制配置，并且值为2即可。
可见性配置
实现对bundle模块化的边界控制，是OSGI实现模块化的核心配置。主要用于描述类是Bundle内部可见，哪些类需要导出提供给其他Bundle使用。元数据的可见性配置包含下列三项：
Bundle-ClassPath：.,xxxx.jar
Import-Package：com.sky.osgi.client; version=”[1.0.0,2.00)”
Export-Package：com.sky.osgi.server; version=”1.0.0”
内部类路径
Bundle-ClassPath定义了Bundle的类路径，在OSGI框架里运行的每个Bundle都会使用一个独立的类加载器进行类加载，java是按需加载的 也就是在执行过程中用到了哪个类，就会到ClassPath下去找相应的class文件加载到方法区。Bundle-ClassPath配置的路径就是该Bundle对应的ClassLoader加载class文件的路径。
Bundle-ClassPath的默认路径是”.”，表示只加载当前jar包内的class文件。同时可以配置多个路径 并用“，”号间隔，这些路径都是相对于当即jar包位置的相对路径，ClassLoader查找顺序就是按照这个顺序进行。注意内嵌的jar包，是不能被直接加载的，需要配置到Bundle-ClassPath中才能被ClassLoader查找到。
导出内部代码
Export-Package配置项的作用是到出内部代码给其他Bundle使用，如果不配置该项 表示该Bundle不公开任何代码，只公开Export-Package配置值中配置的包路径下的类（不包含包下的类）。比如：Export-Package：com.sky.osgi.server; version=”1.0.0”，这个配置表明这个Bundle值公开了com.sky.osgi.server包下的类，其它即便是定义为Public的类 都是不公开的。
Export-Package可以导出多个包，其它Bundle可以通过Import-Package来导入自己需要的包。
导入外部代码
Import-Package配置项的作用是根据自己的需要导入其他Bundle公开的包，注意与Bundle-ClassPath的区别：Import-Package指定的包，不是自己的类加载器加载的，而是导出这个包的Bundle的ClassLoader加载的；而Bundle-ClassPath指定的路径是该Bundle自己的ClassLoader指定的路径。
同样的Import-Package也可以导入多个包。
另外 DynamicImport-Package: *，可以一次动态的导入多个需要的包，但由于存在相互依赖等问题不建议使用。
关于包的版本
在Export-Package和Import-Package一个包时，指定version版本号。在Export-Package导出时，可以指定一个特定的版本号；在Import-Package导入时可以指定一个特定的版本，也可以指定一个版本的区间，“[]”表示闭区间，“()”表示开区间，同时也可以是半开半闭。
比如：
Import-Package：com.sky.osgi.client; version=”1.0.0” //表示指定版本为大于等于1.0.0
Import-Package：com.sky.osgi.client; version=”[1.0.0,2.0.0)” //表示大于等于1.0.0，小于2.0.0
如果指定一个特定的版本，适配的区间为大于等于这个版本，如果不指定版本默认是0.0.0，也就是大于等于0.0.0，本质上也是一个区间。另外注意区分 包的版本与Bundle版本，前面讲的Bundle-Version是指定Bundle的版本。
Bundle内部加载顺序
在Bundle执行需要一个类时，会按照下列顺序进行查找：
1、如果类的包名是以java.开头的（也就是jdk中rt.jar中的类），会交给当前类加载器的父类加载器去查找并加载这个类。这种方法的好处是，对于JDK的公共API不需要多次加载。如果没有找到就抛出异常。
2、如果这个类的包路径在Import-Package配置的路径下，OSGI框架会委托给导出这个包的Bundle对应的类加载器查找并加载该类。如果没有找到直接抛出异常。
3、如果这个类的包路径在Bundle-ClassPath配置的路径下，会直接使用该Bundle自己的类加载器查找并加载该类。如果没有找到就抛出异常。
通过这3步查找顺序可以确定一个类在Bundle内部的一致性。
Bundle之间的一致性
目的：OSGI框架必须保证在多个Bundle中使用同一个版本的导出包。
由于Import-Package导入可能会遇到多个版本，那当前Bundle该如何选择呢？自动安装Bundle时 需要满足的原则是：
1、已解析的Bundle具有最高优先级，如果匹配到多个已解析的Bundle，按照先版本号后安装顺序进行匹配。
2、如果都未解析，同样是先版本号后安装顺序进行匹配。
所谓解析就是把给定Bundle的导入包与其它Bundle的导出包进行匹配的过程。解析依赖具有传递性：BundleA依赖BundleB，BundleA依赖BundleC，在解析BundleA时之前，必须先依次对BundleC、BundleB进行解析。
上述原则OSGI框架加载时自动遵守的。但也有特例，在动态加入Bundle时（在首次启动OSGI框架之后加入Bundle），有可能出现由于传递依赖导致的冲突，为了解决这个冲突在Export导出时，需要使用uses指令。例如：Export-Package: com.sky.server;uses:="com.sky.client"; version="2.0.0" 。这种场景不是很多，在具体用到时可以再查阅。
本文内容部分参考自《OSGI实战》