arclamp.jp アークランプ

　都内某所にてIBM様（こういうときだけ様をつける）によるSOA関連セミナーを受けました。その中でSCA（Service Componenet Architecture）に関する説明があり興味深かったです。

SCA記事（Google先生選）：
　BEA/IBM/Oracle/SAP/ZendなどSOAサービス統合簡素化技術SCA & SDO
　主要ベンダーがSOAプログラミング・モデルの新仕様「SCA」を共同発表
　SOA導入を簡単にする「SIerの知恵」、IBM、オラクルなど協力
　日本IBM、日本オラクルなど8社が共同でSOAの仕様策定

関連資料（IBMより）：
　次世代SOAアプリケーションのためのオープン仕様
　Service Component Architecture（v0.9の仕様書など）

　SCAをどう理解するのか、ということですが一般的なSOA視点というのは資料が増えてくると思うので、SCAをDIコンテナの発展系として考えてみようと思います。
　ある程度は予想どおりだったのですが、SOA対応の商用版DIコンテナという説明でも大丈夫ではないでしょうか。僕の中で勝手に第3世代DIコンテナと呼んでいるものに相当すると思います。

DIコンテナとSOAの共通点
　DIコンテナというのはオブジェクトの組み上げによりアプリケーション構築するために使われるものです。しかも、オブジェクト相互の依存性を排除できるため、旧来の手法にくらべて自由に分割･統合、そして単体テストが行えるのが特徴となります。
　なお組み上げる単位はクラスが基本となります。ようはクラスを組み上げてアプリケーションを構築するわけですね。

　一方、SOAというのはサービスを組み上げてアプリケーションを構築するというものです。ばっくり定義すればサービスというのは「ビジネス上意味のある粒度」というものです。

　ですから、粒度の差はあれどDIコンテナもSOAも"ある単位のモノを組み上げてアプリケーションを構築する"という点では同じようなものです。では、DIコンテナがSOAで使われるためには何が足りないのでしょうか？それは次の3つです。

スコープ管理によるモジュール単位のデプロイ
　これはEclipseを考えた方がわかりやすいです。Eclipseは多くのプラグインによって構成されているわけですが、それを可能にしているのがスコープ管理されたプラグイン機構です。例えば2つのプラグインがバージョンが違う同じJARファイルに依存しているとします。この場合、それぞれのプラグインが、それぞれに持っているJARファイルをロードしなくてはいけません。お互いのプラグインがもっているJARファイルに相互にアクセスされては困るのです。
　こうした問題が起きないようにEclipseのプラグイン機構では、プラグインのスコープの中でクラスローダが機能するようになっています。

　SOAのように、ある程度の大きな粒度を持ったコンポーネントを組み合わせようとすると、そのコンポーネントの中でスコープが限定されて機能した上で、それらを組み合わせるようにしないといけません。簡単に言えばサブシステム単位でJARファイルを管理したいと。SCAでは、この単位をモジュールと呼んでいます。

　ちょっとひねって考えるとDIコンテナの階層化ともいえます。DIコンテナの1つのコンポーネントが、じつはDIコンテナで組み上げられたアプリケーションで…という感じです。組み上げられた単位でインターフェースが定義されていれば十分に機能します。これはBPELやESBでも実現されている考え方ですね。

　ちなみにApache Geronimo（僕の第3世代DIコンテナ認定済）では、モジュール単位でデプロイをする仕組みが用意されています。また、次世代のSpringでも、こうした機能が開発される予定だと聞いています。

構成定義情報による実装への非依存
　さて、ここからはSCAの目指す理想である"実装技術への非依存"の話になります。どうするのか、というと話自体は難しくありません。DIコンテナの設定ファイルをじっと見ていると、

<bean id="hoge" class="foo.bar.Hoge" />

なんて記述があります。これ属性classがありますけど、これをこんな感じにしたイメージです（あくまで、イメージですからね！）。

<bean id="hoge" implement="java://foo.bar.Hoge" />
<bean id="hoge" implement="c++://foo.bar.Hoge" />
<bean id="hoge" implement="php://foo.bar.Hoge" />
<bean id="hoge" implement="webservice://foo.com/bar/hoge" />

　ようはDIコンテナだとクラスをロードしてくるだけなんですが、この対象がJavaなのか、C++なのか、PHPなのか（SCAにはZendも参加しています）、WebServiceなのか、どーでもいいと。
　実はSCAの仕様が策定しているのは、こうした設定ファイル（構成定義情報）の書き方だけなんです。ですから実装言語や環境に応じてSCA用のコンテナ（ModuleContext）を実装するという形になります。こうすることで実装技術に非依存にアプリケーションの構成定義を行うのです。
　そして、各コンポーネント同士をワイヤリングして組み上げていきます。これはDIコンテナのアイデアまんま。その結果、各コンポーネントは明確なインターフェースによって通信（メソッド呼び出し）されます。定義はWSDLでもいいですしJavaでも大丈夫です。ようは、これまでのプログラミング・テクニックと同じでOK。

バインドによるプロトコルの隠蔽
　さて、これでモジュールが「スコープ管理された状態で、実装非依存に複数のオブジェクト組み合わせたもの」だということが分かっていただけた方と思います。
　次に、このモジュールを組み合わせてアプリケーションを構築しなくてはいけません。モジュールの内と外をつなぐのがバインドの考え方です。外から内がEntryPoint、内から外がExternal Serviceと呼びます。このアイデアはESBのパクリですね（JBIで言うBinding Component）。
　つまり外のプロトコルから内のプロトコル、内のプロトコルから外のプロトコルに変換する役割を負った人がいるのです。例えばWebServiceのプロトコルとMapオブジェクトにするとか、その逆とか。
　ま、これは、そんなものを間に挟みこむことで、複数の既存プロトコルに対応するというぐらいに考えてください。

SCAへの期待と不安
　だいぶ長くなってきたので終わりにしますが、SCAをDIコンテナから考えていくと、「スコープ管理によるモジュール単位のデプロイ」「構成定義情報による実装への非依存」「バインドによるプロトコルの隠蔽」という3つのパーツを追加したものと考えてよいのではないでしょうか（って、言い切っていいのかは不安。間違っている場合は、各位でツッコミ願います）。

　期待は大いにあって、これは今後のDIコンテナの発展の方向と間違いなくあっています。どのDIコンテナも"コンポーネントのスコープ管理"と"依存性の解決手段を増やす"というのは間違いないでしょう。SCAはDIコンテナの流れから考えると非常に自然で現実的な拡張です（実装に非依存にするという挑戦そのものが無謀であるという点を除いてｗ）。

　ちなみにServiceMixはJBIのメッセージング仕様によって"依存性の解決手段を増やす"というトライを行っていると解釈できます。これが正解かは不明ですが。

　不安は構成定義情報が、ものすごく複雑になる点です。オーサリングツールの発達という期待感もあるのですが、なかなか開発コミュニティには受け入れられないでしょう。

　あと、どーでもいいのですがアノテーションは微妙ですね。アノテーションの最大の問題点は、せっかく外部の追い出した設定情報を、わざわざオブジェクトの中に戻すところで、これが設定情報を複数個所に分散させることで混乱を招く気がします。ま、これも今後の使い方次第かもしれませんが。

　というわけで、今日、1時間だけ話を聞いた範囲で感じたことをまとめてみました。当たらずとも遠からずだとは思うのですがいかがでしょうか。

　なおSCAについて3/17の第5回テーマ　丸山先生レクチャーでも取り上げられます。まだ申し込み可能ですので興味がある方はお早めに。