OSGi 和 C++

周昌鴻發表於2013-12-14
C++

2011年 9月我參加了OSGi社群在達姆施塔特的會議，並且有機會與其他與會者探討本機c++實現的OSGi規範的現狀。在這一事件之前我也一直想寫一篇部落格，來描述關於當前實現OSGi規範的現狀和努力——類似於C / c++實現的OSGI框架。最後,這篇文章會給出OSGi本機實現的概述。

 

簡介

我第一次瞭解OSGI元件模型是在7年前開發一個Eclipse RCP應用程式。我現在更多從事C++的開發工作，但是仍然關注JAVA和OSGI的發展趨勢。儘管C++有許多高質量的庫可以建立複雜的應用程式，但是針對面向元件（或服務）的設計和實現，C++相關的類庫和框架就顯得有些匱乏了。我試著總結一下現在正在開發的用C/C++實現OSGI應用程式介面的專案。一些複雜的中介軟體，比如：CORBA和SCA實現了一些面向服務的設計，不過都不是使用C++實現或者缺乏開發活躍度（Apache Tuscany C++專案最新的版本是2007年釋出的），這些專案就不在討論之列。

 

本地開發和OSGI的通用性

2007年釋出了RFP-89提案，該提案規範了一個通用OSGI的實現。在通用OSGI的郵件列表中有一些簡短的討論，Peter Kriens也釋出了一篇博文講述這個觀點。簡短地說，這個觀點是使得其他語言開發的（非JAVA）服務物件可以通過OSGI註冊項被訪問（後臺實現可能類似於IPC機制）。其核心管理服務單元仍然使用JAVA實現OSGI，但是允許管理本機開發的元件（bundles）.

原生OSGi似乎更經常被提及，將OSGi原則使用本機OSGi框架實現(例如C或c++)。本文將重點關注這些原生框架。當然，如果原生OSGI框架在實現通用OSGI的規範時能提供和JAVA的互操作性，那麼就會有更大的影響力（因為提供了一個更大的功能超集）。在這篇文章中，你可以找到一些關於《自2008年9月以來的通用OSGI狀態》。這裡提到的論文《物聯網軟體架構》是由Jan Rellermeyer寫的，描述了一個輕型JNI實現的本機C++和Java服務之間的互操作。不過，我沒有發現相關的本機程式碼（倒是找到了Java實現的遠端OSGI服務，見這裡）。

大家對本機實現OSGI的興趣並沒有消退(見 1, 2, 3, 和 4)，不過這樣做還不是主流，另一篇由Peter Kriens 在2010年10月釋出的部落格文章（連結）指出了通用OSGI的觀點和一個Apache基金會孵化的專案提供了C實現OSGI（celix）。我會在下一個章節詳細介紹當前受關注的原生OSGI實現專案。

 

C/C++專案

儘管原生OSGI並不指定特定的平臺或者本機開發語言，不過人們更關注C和C++的實現版本（前面的連線也提到了）。最早的一個專案是OSGI for C++,最初是在2007年7月在SourceForge上註冊的。不過這個專案沒有釋出任何原始碼和二進位制產品，看起來像是被遺棄了。我會彙總一下我所知道的當前正在開發的C或者C++實現的相關專案，盡力以這些專案釋出的時間順序排列（以我所知的）。

宣告:我是CTK外掛框架的主要開發者。我對於其他專案的瞭解是通過不同網際網路資源彙總而成的（我會提供相應的連結），不過可能存在不完善。不幸的是，我沒有足夠的時間和精力來測試和使用所有的專案。所以，我對於這些專案的瞭解大部分來自閱讀相關的文件和原始碼，如果你是下面提到的其中某個框架的開發者，請聯絡我詳細或修正相關資訊。

 

POCO OSP

2007年7月，POCO開放服務平臺作為第一個用C++開發的類OSGI專案釋出了。專案白皮書中的版權宣告似乎顯示專案是在2007年某個時間建立的。這個專案和其他C/C++專案有兩個地方不同，第一，這是一個商業專案，第二，它使用了和OSGI規範相似的API。Bundles和service registry的概念是從OSGI規範中提取的。

在POCO OSP API的文件中列舉了一系列服務（如：首選項和使用者管理），這些都和OSGI服務規範相似。它實現了OSGI框架的一個子集，並且提供了一個OSGI控制檯，一個基於Eclipse RCP的管理介面，支援遠端服務呼叫，允許通過命令列對bundles進行簽名並與框架進行互動。

 

SOF

面向服務框架（SOF）是在2008年早些時候在SourceForge上註冊的，這個專案是最早的可以使用的C++實現OSGI的開源專案。該專案實現了OSGI框架的一個子集，提供了一個OSGI控制檯，一個基於Eclipse RCP的管理介面，並且支援遠端服務。

SOF的遠端服務能力是基於MICO（一個C++ CORBA實現）實現的。

 

CTK 外掛框架

CTK外掛框架是第三個使用C++重寫類OSGI的元件框架，由德國癌症研究中心醫藥和生物資訊科技部門開發的。第一個版本是在2007/2008年期間開發的一個更大框架OpenCherry的一部分，主要是提供了基於Eclipse RCP的C++元件模型（類似於Equinox）。專案後來被命名為BlueBerry，成為MITK應用程式框架的基礎（Blueberry自身是一個真正的應用程式平臺，並不是針對特定應用的），Blueberry中OSGI相關的C++程式碼在2009年被重寫，並形成了現在的CTK外掛框架。

CTK外掛框架是基於QT core庫的，實現了幾乎完整的OSGI框架API。它使用了QT的外掛系統，資源系統和訊號、槽機制來支援所有的OSGI框架功能實現，此外，CTK也提供了一些OSGI可選服務的實現。

 

nOSGI

nOSGI是另一個C++實現的針對Posix系統的OSGI專案。根據這個部落格的評論顯示，該專案最早在2009年開發的。該專案的作者也寫了一份非常棒的論文，闡述了將OSGI轉換為一個原生系統（POSIX）的可行性。

nOSGI尤其專注於建模互相捆綁軟體包的依賴關係（見前面論文中C++軟體包的定義），使用了在執行時通過修補的DSO的ELF頭。同時，該專案也提供了一個OSGI的控制檯來和執行環境互動。

 

Celix

2010年，Celix作為Apache孵化器的一個專案被建立（提案）。最初是由Luminis用C開發的一個OSGI實現。Celix主要關注儘可能參照OSGI的API實現，並且實現JAVA OSGI 元件和使用Celix原生C元件的互操作性問題。

Celix同樣也提供了一個OSGI控制檯和一個日誌服務實現，另外，Celix專案團隊還試圖形成一個C\C++ OSGI開發社群，並號召開源社群來響應這些專案（見郵件列表）。

 

對比

我會提供上述專案的一個高層的比較。請注意，儘管我盡力收集準確的資料，不過仍然可能存在不準確和錯誤之處。這些資料來源於以下地方：

  • Poco OSP:官方 API 文件 (自 29/03/2012) 和評估軟體包 2011_2.
  • SOF: 原始碼 版本1.3 (revision 11090)和站點線上文件.
  • CTK: 原始碼(Git hash 233893) 和站點線上文件(from 29/03/2012).
  • nOSGi: 原始碼(SVN revision 8).

下面的表格列舉了各專案支援的平臺，許可證資訊，實現語言和建立日期（根據目前能確定的資訊）。

  • Supported Platforms

    License

    Language

    Created

    Poco OSP

    		 Linux, Windows, Mac OS, QNX Commercial C++ 2007 (?)1
    SOF Linux, Windows BSD (?)2 C++ 2008
    CTK Linux, Windows, Mac OS Apache License 2.0 C++ 2009
    nOSGi POSIX GPLv3 C++ 2009
    Celix Linux3 Apache License 2.0 C 2010
  • 1.      來自專案白皮書的最早版權宣告時間。
  • 2.      來自SourceForge專案的描述資訊，不過程式碼中沒有相應的許可證資訊。
  • 3.      該專案支援跨平臺，不過看起來主要面向linux.

這五個OSGI框架實現在很多方面存在差異，下面的表格會總結這些專案的下述方面特性：

  1. 服務查詢語言，查詢服務中元件上下文，並允許使用過濾表示式新增服務監聽（根據服務屬性）
  2. 服務/元件記錄器。提供使用類來跟蹤服務和元件的變更（基礎上說，提供了Tracker規範的實現）。
  3. 元件線上升級。允許在執行中升級元件
  4. 型別安全的服務。提供一種機制，允許將一個服務例項安全地轉換為一個實現的介面。
  5. 執行緒安全性。執行緒安全的OSGI框架API

Service Query Language

Service/Bundle Tracker

Bundle Updates

Type-safe Services

Thread-safe

Poco OSP

 Yes No/No Yes Yes Yes
SOF No Yes/No No Yes (Yes)1
CTK Yes (RFC1960) Yes/Yes Yes Yes Yes
nOSGi (Yes)2 (RFC1960) No/No Yes No No
Celix Yes (RFC1960) Yes/No Yes No Yes

1.執行緒安全性需要使用者提供一個定製的執行緒策略類作為啟動的一個模版引數傳遞進去。

2.僅僅支援註冊的服務監聽器

下面的是對OSGI規範的實現情況（可能是不完整的）。相同級別API實現和原始OSGI規範在不同的專案中差距會很大。

Implemented OSGi Specifications

Planned

Poco OSP

 (Preferences, User Admin, Http, Remote Services)1 ?
SOF Remote Services ?
CTK Event Admin, Configuration Admin, Metatype Service, Log Service Remote Services
nOSGi – ?
Celix Log Service, (Deployment Admin, Remote Services)2 ?

1 當Poco OSP 以服務services形式提供這些功能時, 似乎與OSGi規範不相容.
2 SVN上有一些程式碼和示例，但是站點上沒有相關文件，狀態未知

最後，最後一個表格總計了一些開源專案的程式碼規格，使用的程式碼是在章節前宣告的版本。開發成本是用sloccount基於基本COCOMO模型進行統計的。程式碼行統計使用了cloc工具。所有統計都是針對原始碼的（不包含示例，測試程式碼，服務實現生成程式碼等等），

Lines of Code

Lines of Comments

Costs

SOF

 3559 2801 $ 102k
CTK 8770 10024 $ 264k
nOSGi 2208 2284 $ 62k
Celix 8923 2450 $ 269k

總結

好訊息是現在已經有了原生OSGI解決方案，並且相應的開發正在進行。壞訊息是原生OSGI開發正在碎片化，工業界現在還沒有一個大的開發社群和有效的興趣點(我猜作者的意思是大家都關注的專案和社群)。我認為,當前針對嵌入式系統和大規模元件應用系統的C++復興趨勢中，一個原生的OSGI解決方案是非常有益的（想想每美元效能提高比例）。

從技術方面來說，我沒有討論關於OSGI實現上的許多細節以及當前專案的實現情況。我也許應該針對這些專案如何處理元件的後設資料、依賴性、版本控制、資源、動態載入和RTTI(資源初始化即獲取)問題進行更深一步的比較。

相關文章