OSGiはJavaミドルウェアにとっての正しい基盤なのだろうか？

作者 Jean-Jacques Dubray , 翻訳者 南 伸二 投稿日 2010年11月17日

セクション

エンタープライズ・アーキテクチャ,

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

Versioning ,

Java ,

バージョン管理 ,

言語 ,

Architecture ,

プログラミング ,

Mule ,

Service Component Architecture

共有 |

原文(投稿日：2010/11/11)へのリンク

OSGiワーキンググループは1997年にJSR 8として始まり、もっぱら組み込みソフトウェアに対するモジュール化された更新をサポートすることを目的として、組み込みJavaに焦点を当ててきた。Eclipseプラグインとの切り離せない依存関係を断ち切ったあとでOSGiはメインストリームに現れた。 ちょうど2005年頃、SpringやService Component Architectureといったいくつかの方法が、アセンブリ構造と適切に定義された依存関係を利用してエンタープライズJavaによりよいモジュール化を持ち込む方向に集約する一方で、EJBはゆっくりとフェードアウトしていった。今日、たいていのエンタープライズJavaベンダは自社のミドルウェアをOSGi基盤上で書き直し終えている。

それにもかかわらず、その技術に対する多くの不満がある。MuleSourceの創業者、Ross Mason氏は数日前に自身のブログでそのことについて次のように漏らした。 

OSGiはすべてを変えようとしていました。依存関係は完璧に分離され（もう依存関係のバージョンの衝突につまずかなくていい）、可視性は各‘バンドル’の間に厳密に定められていました。私は多くの人と同じようにOSGiの将来性を信じて、私たちのエンジニアリングチームがMuleをOSGi上で動くようにする作業に集中させました。

私たちのチームがマニフェストのことで口論し、独自のバンドルをパッケージ化し、ビルドを長々といじって数ヶ月が経った頃に、OSGiの恩恵はどんどん少なくなり始めました。‘痛みなくして得るものなし’と考えましたが、そのとき私たちは障害にぶち当たってしまったのです。

彼のエンジニアリングチームはOSGiの複雑さをミドルウェア開発者に対してどう隠蔽すればいいかわからなかったのだろう。彼はその問題がOSGiの組み込みというルーツから生まれたものだと理解している。

OSGiはミドルウェアベンダにとっては偉大な仕様です...[しかし]OSGiはアプリケーション開発者が利用するようには決して構築されていません。そのルーツはユーザの介入なしに遠隔操作でソフトウェアアップデートを配信する必要があるようなセットトップボックスにあります。そのベンダーはバンドルの配信を考える必要があるだけですから、このタイプのソフトウェア配信にとってはすばらしい仕様です。

モジュール化とバージョニングはミドルウェアプロジェクトの2つの主な課題である。サービス実装の変更は頻繁で（四半期ベースということもある）、かつては大きな組織がその全てのサービスを単一のearファイルで、3ヶ月毎に配布し、消費者とサービスプロバイダ間の大きな同期の問題を引き起こしていた。たとえそのearファイルの中の多くが変更されておらず、新規あるいは更新されたサービスとなんら関係がなくても、全てのサービスをつねにテストしていたことは言うまでもない。モジュール化が粗末なこととバージョニングの欠如はSOAが失敗だというたいていの主張と関係していると論じている人もいる。Ross氏はさらに付け加える。

[OSGi]はソフトウェアスタックのモジュール化とミドルウェアインフラをプラグアンドプレイ可能にすることを約束しまし。残念なことに、これらの約束があっても、異なるコンテナで同じように動くバンドルを簡単に提供することはないのです。

Ross氏はOSGiの背後にある原理は、つねに異種のスタックにとっても正しい原理であると見ている。しかし、彼にとっては：

いまやOSGiが一般のアプリケーション開発の対象にしてなりつつあるのだから、そのユーザインタラクション部について再考の必要がある。現状、JVM上でのモジュール化やホットデプロイはOSGiなしでも十分に可能であり、OSGiを使って行われる日々の開発の苦痛はその恩恵を打ち消して余りある。

Neil Bartlett氏はRoss氏に対して答えている。

bndのようなツールによってすでにOSGiは開発者がほとんど見なくてすむものになっています。現時点での問題は代替手段の問題であり、OSGi上での開発ツールが圧倒的であることだ、と強く思っています。OSGi"なし"での日々のJVM開発の苦痛はいかなる短期の恩恵にも勝っていると今でも信じています....クラスファイル（.classファイル）を最後に手書きしたのはいつですか？ おそらくそんなことをしたことはないでしょう、それはJavaソースからコンパイルしてできるものだからです。OSGiマニフェストはそれと同じようなものです。コンパイラのようなツールの出力であるべきなのです。 

Joe Sampson氏は、OSGiがテストやビルドの観点からは使いづらいことが分かった、という経験について話した。 Hani Suleiman氏は以下のように指摘している。

OSGiは概念レベルではよいモデルですが、言語のネイティブサポートがないことがともかくネックになっているように思います。これまで私たちが学んだことすべてを使ってやり直すことを躊躇するのは、誰も（私の知る限りです。もし皆さんがOSGiの恩恵だけを受けているのなら、明らかに皆さんの経験は異なるでしょうが）心の底からそれを使うことを楽しめていない、醜悪で不格好なフレームワークのままであり続けているからです。

Richard S. Hallは短い注意を加えた。

もしOSGiの世界にやってきて、全てのレガシーJARが完璧に動作し、さらにモジュール化の恩恵の全てを得られると期待するなら、試さない方がいいでしょう。それは、1980年代に戻ってCからC++に切り替えて全てが自動的にオブジェクト指向になることを期待するようなものです。

WSO2のCTO、Paul Fremantle氏はRoss氏に対して回答し、WSO2 CarbonはOSGi上に構築されているだけでなく開発者からOSGiを完全に隠蔽している、と説明した。彼はそうすること簡単なものではないと認めたが、モジュール化、バージョニング、プロビジョニングの独自手法を構築するよりは簡単だとも言った。

あなたはOSGiについてどのような意見を持っているだろうか？　苦労させられたことがある？ あなたにとっては透過的で意識しなくていい？　あなたのミドルウェアは十分にモジュール化されていて、一流のバージョニング戦略を持っている？　Hani氏が指摘したように、現代的アーキテクチャの主要な問題は、つねに基礎となるプログラミング言語の課題とのセマンティクスの欠如やミスマッチであるので、私たちはどうしてもアーキテクチャ上の行き止まりにぶつかってしまうのだろうか？