重新诠释的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服务(进程内）进行通信

 

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