淺談OSGi.NET開放服務平臺和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類。

 1 using System;
 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檔案

 1 xml version="1.0" encoding="utf-8" ?>
 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在產品設計階段並沒有提出開放性目標。