OSGi 和 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(資源初始化即獲取)問題進行更深一步的比較。