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