BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース C++アプリケーションにOSGi APIを提供するC++ Micro Services

C++アプリケーションにOSGi APIを提供するC++ Micro Services

原文(投稿日:2013/10/29)へのリンク

EclipseCon Europeで今日,Sascha Zelzer氏がC++ MicroServicesというネイティブOSGiサービスレイヤを発表した。PojoSRプロジェクトと同じように,相互接続サービスを組み込んだアプリケーション開発のためのサービスレイヤ提供が目的だ。C++ MicroServicesもPojoSRも,ライブコードをスワップアウト可能なOSGi機能を完全には実装していない。どちらも同じメモリプロセス,あるいはクラスローダ内で動作する。

バンドル(モジュール)の動的な停止と再起動を実現するマルチクラスローダモデルが,OSGiの長所のひとつであるとすれば,このOSGi Liteには用途があるのだろうか? そう,PojoSRを始めとするネイティブアプローチ(別のOSGi CランタイムであるApache Celixも含めて)の開発者たちは,協調型サービスという観点でのアプリケーション構築を可能にするという意味で,マイクロサービスプログラムモデルにもメリットが存在する,と考えているのだ。これにより,グローバルなサービスカタログに有効なサービス一覧を保持しておいて,それらのサービスを必要なコンポーネントがサービスレジストリに問い合わせて適切な実装を探し出す,という汎用的な依存注入メカニズムが実現可能になるからだ。

モジュールが“OSGi Lite” 仕様ではなかったとしても,サービスをレジストリから動的に停止(あるいは削除)することはできる。あるいは実行中のコード置換が実現できなくても,一定レベルの動的処理を実現することは可能だ。また一方で,Javaプログラムやライブラリの抱えている問題は,何もフラットなクラスパスだけに限ったものではない。つまり "OSGi Lite" パターンは,典型的なスパゲッティモデルをサービス構造へとリファクタリングしていく,その移行期間を作り出すためのものなのだ。

C++ MicroServicesプロジェクトでは,今年始めにバージョン 1.0.0をリリースしている。使用方法を説明した詳細なチュートリアルと合わせて,GitHubあるいはプロジェクトのダウンロードライブラリから入手可能だ。ライブラリでは "us::" というネームスペース(マイクロサービスの省略形)を使用する。us::ModuleContext(OSGiのBundleContextと同種),us::GetServiceReference, us::GetServiceなどの他,LoadUnLoadメソッドを備えて,モジュールの起動あるいは停止時の状態初期化を行う基本クラスであるus::ModuleActivatorや,サービスのインストールやアンインストールを追跡するus::ServiceTrackerなどが提供されている。

InfoQではZelzer氏に連絡を取り,最初にC++ Micro Servicesプロジェクトについて質問した:

Zelzer: 私は医療画像用の大規模なC++コードベースの開発に従事しています。たくさんの学生がアルゴリズムの開発に利用しています。このようなコードベースと開発者(トレーニングを受けたソフトウェア技術者はほとんどいません)を管理するには,モジュール性と再利用性が特に重要です。これはOSGiの得意とするところなのです。当初私たちは,完全なC++ OSGiライクのフレームワークを導入しようと試みましたが,いくつかの問題に突き当たってしまいました。中でも重大だったのは,純粋なOSGiアーキテクチャを適用するには既存のコードベースが複雑すぎたこと,保守的なC++開発者たちが別の複雑なフレームワークの導入に消極的であったこと,この2つです。いずれにしても,私たちがもっとも重視したのはサービスレイヤです - 実行時のコードのホットスワッピングや,モジュール層でのフレキシブルな依存解決メカニズムといったものは,私たちのユースケースにはありませんでした。それがCppMicroServicesプロジェクトを始めた理由です。

InfoQ: サービスの起動や終了はどのように扱われるのでしょう – モジュールはロードされたままなのでしょうか?

Zelzer: 通常,モジュールはアンロードされません(可能であったとしても)。モジュールはコンパイル時のリンク依存を解決するために,起動時に動的リンカによってロードされます。独自のプログラムを用意して,実行時に動的ロードやアンロードを行うことも可能です(ただしアンロードを行うことはほとんどありません)。参照不能になったサービスは,サービスリスナによって処理されなければなりません。アンロードされたモジュールのサービスを他のモジュールが使用し続けると,プログラムエラーが発生します。

InfoQ: 同じバージョンのコードを使用する場合でも,モジュールのロードとアンロードを動的に行うことができるのですか?

Zelzer: 可能ですが,これはプログラム次第です。OSが提供している機能(dlopen(), LoadLibrary()など)を使えば,実行時に共有ライブラリを動的ロードすることもできます。

InfoQ: バンドルのロードはどのように動作するのでしょう – JARのように,バンドルを表現可能な標準フォーマットがあるのでしょうか?

Zelzer: CppMicroServicesが優れているのは,処理を完全にOSにまかせている点です。ですからLinuxでは,バンドルのフォーマットは “ELF Shared Object”(staticも可能です)であり,Windowsならば,例えば “PE”(Portable Executive, .dllや.exeファイルのフォーマット)が使用されます。ローディングはOSの動的リンカが実行します。

InfoQ: CPP Micro Servicesがサポートしているプラットフォームは何ですか?

Zelzer: 標準的なC++ 98で記述されていますから,それに準拠したC++コンパイラのあるプラットフォームならば,コンパイルは可能なはずです。テストはLinux, Windows, MacOS上で,さまざまなバージョンのコンパイラを使って行っています。

InfoQ: OSGi NativeプロポーザルやApache Celixとはどのような関係なのでしょう?

Zelzer: 私自身はCppMicroServicesプロジェクトを,サービスレイヤのネイティブC++ APIに関するフィールドテストだと思っています。ここでの経験は,私の参加しているNative OSGi APIの仕様策定プロセスでも役に立つはずです。

InfoQ: 現時点ではどこで,どのような利用をされているのですか?

Zelzer: Medical Imaging Interaction Toolkit (MITK) では広範に使用していますから,それを利用するプロジェクトでも間接的に使用されていることになります。商業的な例ではMint Medicalがあります。医療画像の分野でC++ソリューションを提供している会社です。航空電子や組み込みシステム,あるいはセーフティ・クリティカルなソフトウェアプロジェクトなどからも関心を持たれているようです。

ネイティブOSGiの領域への関心は高い。ネイティブライブラリにおけるOSGi API標準化への要件を議論する場として,RFP(Request For Proposal)156 が存在する理由もそこにある。読者はネイティブコードでのOSGi APIの利用に興味をお持ちだろうか?

この記事に星をつける

おすすめ度
スタイル

BT