先週開催されたOSGiコミュニティイベントで、IBMのGraham Charters博士はモジュラリティ成熟モデルに向かってと題したプレゼンを行った。このモデルはモジュール化の度合いという視点からシステムの成熟度を特定するために必要な要件をまとめたものであり、現在もまだ作成中だ。目的は能力成熟度モデルと似ており、組織(プロジェクト)がモジュール化の道をどのように進んでいるのかを評価する方法を提供する。
下記の内容は、まだ作業中なので変更される可能性があることに注意してほしい。数字や説明も何度も変わるかもしれない。現時点でのモジュラリティ成熟モデルは下記のように示すことができる。
- レベル 1:アドホック。何もモジュールになっていない。すべてが、JARの塊。さらに悪いことにクラスが束になっているだけの場合もある。このような場合はたいてい、融通のきかない一枚岩のアプリケーションになる。
- レベル 2:モジュール。モジュールは正式なバージョンが付けられた識別子を持つ。依存性はモジュールそのものではなく、モジュールの識別子に付随する。Maven、Ivy、RPM、OSGiはこのレベルに分類される。
- レベル 3:モジュラリティ. モジュールがそのモジュールの明示的な識別子やバージョンではなく、契約によって宣言される。要件は抽象的(例えば、Declarative Serviceが使えること)かもしれないし、パッケージによって定義されている(例えば、org.osgi.framework)かもしれない。
- レベル 4:疎結合。実装はファクトリやコンストラクタを通じて得られない。代わりに、レジストリから動的に得られる。または、必要に応じて動的に注入される。
- レベル 5:移譲。作成物の所有がモジュラリティを意識したリポジトリへと移譲される。このリポジトリは必要に応じてリポジトリ内の資産へのアクセスの連携や管理をサポートする場合もある。
- レベル 6:ダイナミズム。モジュールが動的なライフサイクルに参加する。このサイクルではランタイム上で追加、更新、削除が行われる一方、システムの状態は保存される。
InfoQはGraham Charters博士になぜこの成熟モデルを作成したのか、話を聞いた。
Graham Charters: 幸運にも私は、ここ2、3年、多くの顧客と話をする機会に恵まれました。皆、OSGi導入の様々な段階にいる顧客です。大抵の場合、彼らは、事後的にモジュラリティを導入しています。つまり、何か既存のアプリケーションがあるか、もうメンテナンスができない、ビジネスの発展を阻害するアプリケーションを持っているのです。顧客はいつも、この地図も目的地もない旅に出陣するのは自分たちが初めてだと思います。この成熟モデルはこのモジュラリティ導入の旅の最も一般的で論理的なパターンを記録したものです。こはモジュラリティの技術にとらわれないモデルとして作りました。なぜなら、このモデルの最も低いレベルはOSGiを必要としないのです。私の考えでは、OSGiが最も優れたソリューションです。しかし、このモデルを使えば各レベルの特徴と利点を明確に説明できます。しかも、モジュール化を実現する特定技術の詳細に踏み込む必要はありません。
InfoQ: このモデルで考えるとプロジェクトはどのように区分けされると思うますか。
Graham Charters: 私はこのOSGiコミュニティイベントで調査を行いましたが、結果として、自分の考えに確信を持ちました。調査の結果、モデルで評価すると、この産業は平均してレベル 2、つまりモジュールくらいです。Eclipse Toolsプロジェクトについても質問しましたが、これはレベル 3、つまりモジュラリティでした。レベル 4(疎結合)できちんとOSGiサービスモデルを活用しているプロジェクトもあります。しかし、このようなプロジェクトは特定のOSGiに注力しています。例えば、Apache Aries、 Apache Felix、Eclipse Gemini、Eclipse Virgoなどです。移譲(レベル 5)と状態を維持するサービスの真のダイナミズム(レベル 6)はほとんどありません。私の望みは、間もなく発表されるOSGiバンドルリポジトリの仕様がレベル 5から始まることです。
InfoQ: このモデルに直線的に従って成熟する傾向はありますか。最後のふたつは(移譲/ダイナミズム)どうでしょうか。
Graham Charters: 一般的には、組織はこのレベルに直線的に従います。実現する技術があれば、基本的には、ほとんどの顧客がこの順番にほとんど論理的に従います。移譲とダイナミズムの順番は特別に強いわけではなく、私が会ったこのふたつのレベルに関心のある顧客の分布を反映していると思います。顧客がリポジトリの連携や管理を考えるのはとても一般的なことですが、ダイナミズムはとても特殊です。思うに、管理されていない/埋め込まれたOSGiの使い方とダイナミズムとの間には正当な高い相関があります。
このモデルには何度も変更される可能性がある領域が他にもあります。それはモジュラリティと疎結合の順番と区別です。モジュール間の疎結合、あるいは実装の独立性はモジュラリティの一部だと主張する人もいるでしょう。この意見はある程度は正しいと思います。要件と能力と観点から考えれば、実装の共有を説明することができるでしょう。しかし、多くの場合、顧客はモジュールかしていない環境でモジュールを実行し続けなければなりません。したがって、疎結合を導入するのは難しいです。このような状況では、マイクロサービス(別名、pojoSR)のようなツールが便利です。このような技術を使えば、顧客はモジュラリティと疎結合の適用順を交換することもできます。疎結合でいつも問題になるのは、モジュラリティ層への影響です。モジュールが他のサービスと協調して動作している場合、モジュール間のAPIをエラスことができます。実装クラスを共有する必要がないからです。
InfoQ: このモジュラリティのモデルに沿って進めば、コストを抑えることができますか。進めば徐々にコストが減るのでしょうか。
Graham Charters: はい。コストを抑えることができますし、抑えることをはっきりと示すのがこのモデルのゴールでもあります。私は各レイヤを概括し、組織が明示しなければならない特徴は何なのか、をはっきりさせたいと思っていました。例えば、モジュラリティの観点から繰り返し行うべきことや、それによってどのような利益があるのかについてです。モデルの上位のレベルへ進むのは、開発がそのレベルに適用しなければならないという点において、コストがかかります。しかし、利益もあるのです。私はこのような利益を結合度の低減という観点から考えます。結合度が低くなれば組織の素早さは増します。素早さが増せば、コストが低くなり、価値を提供するのに必要な時間も少なくなります。例えば、モジュールからモジュラリティへ移行する場合(つまり、レベル 2から3へ移行する場合)、組織はまず、モジュールの外部を記述し始め、開発やビルド、運用へ適用しなければなりません。しかし、こうすることの利点は大きく、システムの構造が本当にはっきりします。したがって、システムが腐敗してメンテナンスできなくなることが少なくなるのです。モジュールを変更した場合、システムへどのような影響があるかもすぐにわかります。モジュールのファクタリングにもとらわれません。モジュールの利用者はどのモジュールがどの機能を提供しているかを気にしないからです。そして、構造を壊してしまうような変更はすぐにわかります。満たされていない要求があるかどうかすぐにわかるからです。
組織がモジュールを中心にして協調して働く(モジュールに貢献したり、レビューしたり、議論したり)仕組みを作れたら、重複したモジュールを作ってしまうこともほとんどなくなります。こうなれば、コストは低くなりより再利用しやすくなります。再利用しやすくなれば、品質も上がります。開発者に必要なAPIやサービスを探させて、高品質なモジュールをプロジェクトに導入しようとするより、品質も不明なよくわからないものを見つけさせたり、必要なものをスクラッチでコーディングさせようとする組織などありません。
InfoQ: このモデルの評価はOSGi固有のものですか。それとも、他のモジュラリティフレームワークでも使えますか。
Graham Charters: モジュラリティの技術にとらわれない評価と利点を作ろうとしてきました。理由はふたつです。ひとつは、ある特定のレベルに達するのに何が必要なのかを、より幅広いグループに対して説明できるようにするためにです。例えば、組織がレベル 2で、彼らがOSGiを使っていないなら、インポートパッケージやエクスポートパッケージについて話しても意味がありません。しかし、モジュールの外部を定義することのを説くのに価値があるのは明らかです。ふたつ目の理由は、モジュラリティのフレームワークを評価するのに役に立つと思うからです。すべてのモジュラリティのフレームワークがド名時ように作られているわけではありません。したがって、このモデルを使えば、望ましい特徴や利点を見つけ、適切なフレームワークが使えるようになります。
InfoQ: OSGiや他の組織を通じて、このモデルを正式な標準文書のかたちで公開する予定はありますか。具体的なスケジュールはどうなっているのでしょうか。
Graham Charters: 正直に言って、私はこのモデルがどのように受け入れられるかわかりません。しかし、私は肯定的な反応に圧倒されています。私はこのモデルが好きでこのモデルの進化に協力してくれる人がいることを望んでいます。これが標準になる正当かどうかわかりませんが、OSGiアライアンスから発表されるセマンティックバージョニングがされているホワイトペーパーと同じような形式になると思います。現在のこのプロジェクトに対する関心を考えると、来月くらいには最初の版を発表できることを望んできます。
InfoQ: この成熟モデルから業界やOSGiコミュニティが学べることはありますか。
Graham Charters: OSGiコミュニティイベントで私が実施した、些か非科学的な調査によれば、ほとんどの組織やプロジェクトはレベル 2のモジュールに属してます。個人的には、レベル 5の移譲に達することで優れた品質と高い生産性を得ることができると思います。大規模に分散した開発チームや運用チームがある組織は特にそうです。レベル 5を私たちのゴールとすれば、より高いレベルの利点を売り込み、可能な限り簡単にレベルを挙げられるようにしなければなりません。例えば、レベル 3になるには、モジュールの外部を定義するための優れたツールや、継続的なビルドを実現するツール、潜在的な問題を見つけ、問題判別の役に立つ、モジュールやシステムの分析を行うツールが必要です。
The モジュラリティ成熟モデルはOSGiコミュニティウィキで利用可能。このモデルで評価した場合、あなたの組織やプロジェクトはどのレベルにあるだろうか。