arclamp.jp アークランプ

　ちょっと前からDIの次に来るものを考えていたのですが、ようやくパズルのピースが埋まりつつあります。コンセプトは「疎結合手法のリミックス」です。

第3世代DIコンテナ
　まずは第3世代DIコンテナという話から始まります。DIコンテナの第1世代はDIコンセプトを実装したPico Containerが有名です。すぐに登場した第2世代はDIの実践としてWebアプリケーションフレームワークに適用したSpringやSeasar2です。そして第3世代として感じていたのがApache GeronimoやHivemindです。

　第2世代と第3世代の違いは、コンポーネント同士の依存関係を管理する方法です。
　Apache Geronimoはサーバアプリケーション（JavaEEサーバ、メールサーバ、JMSサーバなど）のインフラと考えてよいです。JMXのアイデアを取り入れており、MBeanにあたるGBeanがインジェクトの対象となってGeronimo上にデプロイされます。各JavaEEコンポーネントは自分専用のGBeanを通じて互いに依存をしています。なおJavaEE標準APIを媒体とすることでポータビリティを高めています。

　一方のHiveMindはアプリケーションフレームワークですが、コントリビュートという機能を備えています。通常のDIコンテナの場合、依存管理は依存元Aが依存先Bを指定します。こんな感じ。

  <bean id="A"> //A
    <property name="hoge">
       <ref bean="B"> //aがbを参照

  <bean id="B"> //B

　HiveMindでは、これを逆にして依存先Bを依存元Aに投稿（コントリビュート）します。コントリビュートの対象をコンフィグレーション・ポイントと呼びます。こんな感じ。

  <service-point id="A" > //A
    <set-configuration 
        <configuration-id="hoge" 
             property="hoge"/> //Aへの投稿方法

　<hoge service="service:B"/> //BをAに投稿

  <service-point id="B" > //B

　これにより違ったアプリケーションの可能性が開けます。DIなんですけど方向が違うわけです。自分が依存するものを指定するのではなくて、依存したい人が指定するわけです。
　詳しくは「先進DIコンテナ「Apache Geronimo」、「HiveMind」を試す - アパッチが開発する2つの次世代DIコンテナの可能性を探る」を参照してください。

Web2.0とSOA。そしてServiceMix登場
　JavaOneでも講演させてもらいましたが、ちょっと前からWeb2.0とSOAがすごい近い概念じゃないかと考えていました。同じような技術要素を使っているし、どちらかというとSOAが本来目指すべき思想がWeb2.0にあるなと感じていました。その思いは正解で、実際にAjaxとJBIを結合するという実装にたどり着くことができました。
　もう1つ、あの講演にいれたのがSOAとDIの融合です。講演で発表した実装はServiceMix上に構築されていました。ServiceMixはJBIのオープンソース実装です。Spring上に構築されており、Spring上のコンポーネントをBC、SEとして捉え、それぞれのメッセージ交換を処理する機能を提供します。ようはPOJO用のNMRです（ちょっと語弊あるけど）。

　まさに今日、僕の気づいたのはServiceMixも第3世代DIコンテナだということです。ようはコンポーネント間の依存管理をメッセージ交換によって実現しているわけです。

　ここでわかったのは、僕が第3世代DIコンテナと呼んでいたものが「DI以外の方法でコンポーネントを統合する」事に注力している点です。DIは明確にインターフェースクラスを実装する必要性があり、その実装だけを隠蔽します。以前の密結合よりは緩い関係ですが、インターフェースクラスという明確な依存があります。

　第3世代DIコンテナ達は、それに加えて、コンテナ上のコンポーネントをJMX、コントリビュート、メッセージ交換と方法は違いますが、どうにかして統合しようとしているわけです。
　これで「第3世代DIコンテナ」の名称に意味がなくなりました。僕が考えていたのは、「コンテナ内のコンポーネントを、DIを含む様々な手法で統合していく」ということです。

BPEL、JBIからServiceMixへの飛躍
　今度は別の方向から考えます。統合といえばEAIやBPMの流れで考えば古い話です。例えばBPMの標準仕様であるBPELの発想はWebサービス同士の統合です。でも、ws-*が激重（げきおも）で、BPEL自体も気持ち悪くなるぐらいに複雑。それはBPELのLがLanguage（言語）であることから分かるように、BPELは統合パターンなどという甘っちょろいものではなくて、Webサービス用の言語なのです。でも、皆さんご存知の通り、何でも1つでやろうとすると膨張して大変なことになる事例は山のようにあるわけです。COLBA、UML、EJB2.0、ws-*などなど。

　そことまでしなくてもコンテナを前提にしたメッセージ交換ぐらいいいんじゃないの？って発想がJBIです。JBIはJavaと名が付くようにJava環境に依存します。ですから、コンテナ内と外の世界で依存関係の強さが違います。外とはWebサービスで自由に、中はNMRを通じてもう少し強くという感じです。JBIが規定しているのはメッセージ交換のパターンに過ぎません。
　でも実はJBIもws-*前提な部分があります。そして複雑なデプロイメント・ディスクリプタが必要です。やはりJBIも考えすぎなのです。

　ServiceMixはJBIの実装を名乗っていますが、そういった重そうな部分をばっさり切り落としています。そうしてJBIのよいところをうまくいかしているのです。

コンテナによる疎結合度の調整
　コミュニティが考えた密結合からDIによる疎結合と来た流れが、Geronimo、HiveMindを通ってServiceMixに至ります。逆にベンダーが考えた激重BEPL、JBIによる超疎結合のからきてServiceMixにいたります。この2つが融合しているだけでもすごいことです。さらに現実的な超疎結合であるWeb2.0に対応します。AjaxはXMLとHTTP使ってSerivceMixと統合できることはJavaOneで証明しました。

　このスケーラビリティのすごさがお分かりになるでしょうか。重さの象徴SOA（Webサービス）と、軽さの象徴DIが出会い、さらにエンタープライズでないWeb2.0すらも包含できるのです。これは疎結合度を調整する様々な手法を、自由に組み合わせられるようになったことを意味しています。

　これこそがDIを超える新しいアプリケーション・アーキテクチャではないでしょうか。名づけて「コンテナベース・サービス・インテグレーション」です（ほんまかいな）。

　ようはコンテナにコンポーネントを登録し、それらを統合/連携する様々な手法が用意されているわけです。しかもコンテナ同士の会話も可能ですし、コンテナを他のコンテナにコンポーネントとして登録することすら可能です。
　コンテナという単位が生まれることで、スコープが明確になり、BEPLやWebサービスのように1つの手法ですべてをやる必要性がなくなったのではないかと感じます。

　もっと、いろんな妄想が広がりますが、長くなったので今回はここまで。