从新诠释的OSGi规范

　　上周五部门开会讨论新一代产品（基于.net Winform）的设计规范，从设计规范慢慢讨论到体系结构等架构存在的问题，诸如菜单、工具条、状态条、界面布局等不能实现配置化和自动化，子系统之间拥有强依赖，甚至产生强依赖等等，最后我提出经过OSGi 框架来解决界面和模块之间的问题，并立下军令状一周内把核心框架Beta搭建完毕，第二周进行一次培训。

      基于项目的特色，结合贞宝兄的OSGi.Net 和Mono.Addins 进行了从新诠释，在两天半的时间里经过Mono.Addins  和NLite 的依赖注入容器相结合实现了诠释后的OSGi规范，再这里首先感谢贞宝兄在OSGi规范的布道和推广工做，其次要感谢Mono.Addins 强大的扩展功能 ，起到了事半功倍的效果，若是没有它的存在我就不敢夸海口了，呵呵。在用Mono.Addins 框架来实现OSGi 规范时也遇到一些问题，发现Mono.Addins 的扩展过于强依赖，不能获取插件扩展的原始元数据再这一点贞宝兄的OSGi.net 实现的就好多了，彻底开放给使用者。有时间了自行实现一个，这是后话，其实在09年已经开发了Mbs 框架，里面其实包含了OSGI 的不少东东，可是不标准。

      下面是诠释后的OSGi 规范（备注该规范仅仅使用在公司项目中）概要介绍，里面有不少值得商榷的地方，欢迎指正。

1          插件(Bundle)

插件是一个提供特定功能的独立的子系统。

插件是独立的可部署单元

插件能够向其它插件提供扩展点，其它插件能够扩展该插件

插件不能够向其它插件提供服务。

插件提供的功能经过其类型空间来体现。

插件是由addin.xml清单文件、本地程序集(*)、资源和其它文件组成

插件具有独立性、 隔离性和彻底可复用的特性，并具备独立的类型空间。

2          插件运行时（BundleRuntime)

插件运行时是全部插件的运行容器。

BundleRuntime是一个单件的实例，当建立后，您能够经过BundleRuntime.Instance来获取这个实例。 主程序必须提供建立并启动插件运行时的功能

3          插件扩展机制

插件能够在启动时动态的实现对其它插件的扩展而且暴露出扩展点供其它插件来扩展，当插件中止时，这种扩展会动态的卸载。

插件间的扩展没有任何的耦合，即这种扩展机制能够确保插件间没有任何的依赖，达到绝对的复用。

插件的扩展机制是经过清单文件的ExtensionPoint节点和Extension节点来定义的。插件经过ExtensionPoint 节点向其它插件暴露扩展点。这个节点包含一个Path属性，即扩展点的标识。 插件经过Extension节点定义一个其它插件扩展点的扩展，它经过Path属性来指定对应的扩展点，并利用该节点下定义子节点，这些子节点就是一个扩展的详细信息。

插件的扩展机制经常用在菜单、工具条、状态条、UI界面的动态组合上，固然也能够用在其它场景中。

4          服务管理机制

服务由服务契约和具体实现组成。

服务是指轻量级服务，

服务契约是暴露方法的接口，

服务实现则是实现指定接口的类型。

服务引入，使得咱们可将接口与实现分离，并在须要的时候选择特定的实现。

服务的生命周期拥有两种类型：单利、瞬时，默认注册在服务容器中的服务是瞬时的

服务只能驻留在服务容器-IBundleContext.Container中

插件具备独立的服务容器，所以插件内的全部服务之间是能够通讯的，可是插件间的服务是不可以直接通讯的，除了根插件以外

面向服务的编程模型：“注册-发现-绑定-卸载”，经过服务容器-IBundleContext.Container对象来进行的中相关的方法来使用的

服务具备动态性，通常状况下，它在插件启动时注册到平台，在插件中止时从平台中卸载

5          插件依赖机制

一个进程只有一个根插件，全部的其它插件都依赖根插件，其它插件能够共享根插件中资源、类型空间、服务

一个插件能够依赖多个其它插件（根插件除外），其它插件只能依赖该插件的扩展点、资源、类型空间，不能依赖服务

6          插件间的通讯

任何插件均可以和根插件经过服务进行通讯，反之根插件和其它任何插件都不能经过服务进行通讯

插件间不能直接经过服务进行通讯

插件间能够经过轻量级的消息总线通讯（进程内消息总线）

插件间能够经过重量级的消息总系通讯（Socket）

插件间能够经过重量级分布式服务进行通讯（Remoting、WebService、WCF、REST)

插件间能够经过轻量级REST服务(进程内）进行通讯

 

    谢谢你们的阅读，麻烦大伙点一下推荐，再次谢谢你们。 ^_^