我们团队从2008年5月份开始设计一个App Store，目前已经实现了产品的原型，现在产品已经进入了完善阶段。该产品最开始是基于我在2005年开发的一个Common Form Framework，此后结合了CAB & SCSF设计了Common UI Platform，从2008年5月份开始正式确定了产品的RoadMap，当然中间还是有不少变更了。它类似Google App Engine和Sina App Engine，只不过市场策略和模式是完全不同的。对于构建一个企业级的App Store，我个人认为.NET平台自身的特性在这领域确实不如Java，不过，好在也不是有什么是不可解决的。在产品设计过程中，我时刻关注业内的各种App Engine、App Store和Plugin Framework，包括Equinox、SharpDevelop、Egeye、Mono.Addin、MAF、MEF、SCSF、Google/Sina App Engine、Discuz等。每出现一种类似的产品，我都有一种心惊肉跳的感觉，担心别人抢在我之前设计了更好的同质产品，当然，也好在目前还没有看到同质的产品。
今天我先介绍一下该Store的内核OSGi.NET，同时也谈一下我见过比较简陋的插件系统Discuz。
OSGi是一个开放服务规范，“开放”意味着基于该平台可以使得很多人来共同使用和协作，而“服务”则是实现协作的一个手段。该规范可以总结为：A 插件化支持规范； B 面向服务支持规范； C 插件扩展规范； D 安全性与隔离性规范； E 系统服务规范。插件化规范完整详细定义了插件的结构、插件依赖、插件类加载、L10N和I18N、宿主插件和片段插件；面向服务支持规范定义了模块间服务协作的支持，这个服务并不是传统意义的企业级Web Service，确切的讲，仅是“接口+实现”，并对实现的引用进行管理；插件扩展规范定义了一个插件如何对另一个插件进行扩展，这种扩展手段非常简单，在这里提出了扩展点概念；安全性与隔离性则要确保被内核加载的插件不会对内核和其它插件产生一些副作用，比如我们决不能允许一个非法的插件来停止另一个插件；系统服务规范则预定义了几个系统服务。OSGi规范是基于Java编写的，此前还没有一个针对.NET平台OSGi规范，原因在于.NET并不支持ava那样优雅的类加载机制，不过还在我们目前都找到了绕过这些固有缺陷的方法并设计了针对.NET的规范。
我们团队在设计OSGi.NET时候，把易用性放在首位，通过场景驱动来设计Usecase。从而，基于OSGi.NET开发一个插件和开发一个.NET项目方式基本一样（当然，我们并不认为目前已经做到最好了，易用性肯定还有很大的改进空间）。以下是一个Hello World的插件，开发人员应该可以在5分钟内开发一个Hello World插件的。
1 在OSGi.NET的Plugins目录下，创建一个Class Library Project，并创建一个MyActivator类。
2 using System.Collections.Generic;
3 using System.Text;
4 using UIShell.OSGi;
5
6 namespace UIShell.TestBundle
7 {
8 public class MyActivator : IBundleActivator
9 {
10 public void Start(IBundleContext context)
11 {
12 Console.WriteLine("Hello World！ Plugin is started.");
13 }
14 public void Stop(IBundleContext context)
15 {
16 Console.WriteLine("Plugin is stopped.");
17 }
18 }
19}
20
2 定义一个Manifest.xml文件
2 < Bundle Name ="TestBundle"
3 SymbolicName ="UIShell.TestBundle"
4 InitializedState ="Started" >
5 < Activator Type ="UIShell.TestBundle.MyActivator" />
6 < Runtime >
7 < Assembly Path ="bin/Debug/UIShell.TestBundle.dll" Share ="false" />
8 </ Runtime >
9 </ Bundle >
10
通过Console运行OSGi.NET后，这个插件便会被内核加载启动，然后Print出Hello World。
基于OSGi.NET插件开发，一般只需做的事情有：（1）定义插件要实现的功能；（2）判断插件是否需要引用其它插件的功能，如果有，则可以通过A）在Runtime声明一个Dependeny节点；B）在MyActivator.Start方法中使用context.GetService方法获取依赖的服务；（3）通过定义Extension来扩展其它插件功能，通过ExtensionPoint暴露扩展点。
对于Discuz的关注是始于我们在设计基于ASP.NET的Store的。在设计这个Store的时候，我想比较一下基于OSGi.NET的ASP.NET插件平台和其它插件平台。Discuz插件系统是我见过设计的最为简单也是最为简陋的插件系统了。我只看了一下反编译的结果，就没有深入研究它的欲望了。以下是通过反编译看到的插件定义。
它的插件系统是基于接口和实现类来设计了。这种简陋的设计从严格意义上来讲不是一个插件平台，对开放性的支持也就更弱了，注定不可能有太多的人参与到这个产品插件的设计与扩展了。此外，每次内核的升级都可能会导致原有的插件无法正常使用。不过，这也可能是因为Discuz在产品设计阶段并没有提出开放性目标。
本文转自道法自然博客园博客，原文链接：http://www.cnblogs.com/baihmpgy/archive/2010/05/05/1727626.html，如需转载请自行联系原作者
