なんか、面白そうなプロジェクトが始まりそうです。昨日付けでApache ComposerというプロジェクトがApacheに提案されました（提案なので、この後、Incubatorを通ってから正式プロジェクトなので先は長い）。
Apache Composer is an embeddable Inversion of Control (IoC) container for general components (Java initially). Its characterizing elements are that it is small, favors Dependency Injection (over other IoC variants) and tries to remain agnostic when it comes to the need for its components to honor abstractions.It is the merger of two existing projects - PicoContainer and Plexus. Plexus was started in 2002, and PicoContainer in 2003. Both projects have committers who are experienced in open source software development, as well as existing Apache committers and members on board.
これだけでは、なんのことやらですが、ぱぱっと読むに、
1.IoCコンテナ（DIの要素は持つけど）
2.PicoContainerとPlexusの後継
3.Java initiallyってことは、Java以外の実装言語もサポートしたがっている
という感じ。僕としては萌え要素が多い。
IoC
まず、IoCという言葉がDIとは明確に使い分けられています。WikipediaのIoCから。
Thus, instead of the programmer specifying, by the means of function calls, a series of events to happen during the lifetime of a programme, they would rather register desired responses to particular happenings, and then let some external entities take over the control over the precise order and set of events to happen.Informally, it is expressed by the Hollywood Principle - "Don't call us, we'll call you".
A closely related concept and a direct application of IoC principle is event-driven programming.
簡単に言うとハリウッドの原則である「電話してくるな。必要になればこっちから電話する」。プログラマはプログラムのライフタイムにおけるイベントの発生に注目します。狭義ではイベントフドリブンのことです。だから、GUIアプリでは基本的な概念だし、ListenerとかCallbackみたいなものも含まれる。
DIというのはDependency Injection（依存性の注入）なので、依存性解決のためのルックアップ処理が反転しているだけ。だからIoCコンテナというと言葉が広すぎるということで、ファウラー氏も「IoCコンテナって言わずにDIコンテナって言おうよ」と書いたわけです。
PicoContainerとPlexusの後継
こうしたIoCの考え方を実装していたのが今はなきApache Avalon Frameworkでした。PlexusはAvalon が解散した後に後継として作られていたもの。有名(?)な利用プロダクトとしてはJAMESなどがあります。Avalonは非常によくできたアプリケーションフレームワークで、前述のとおりライフサイクル管理やイベントフックの仕組みがきちんと織り込まれていました。ただし、POJOではなかったので、若干使いにくかった記憶があります。
一方、PicoContainerは組み込み型のDIコンテナです。JIRAとかに入っています。小さいですが、細かいことがよくできていて複雑な依存性の解決やライフサイクルモデルをサポートしています。XMLを使わずにコードでコンポーネントをくみ上げます。
SpringやSeasarは、J2EEのアプリケーションフレームワークを結合することが重視されているのに対して、PicoContainerやPlexusは、あくまでもアプリケーション内で利用されることが前提になっています。GoogleのGuiceやTapestryのHiveMindも同じです。
余談ですが、Avalonはアプリケーションサーバを持っていたことも特徴でした。サーバアプリケーションというのはリクエスト/レスポンスモデルで起動停止のライフサイクルを持ちます。ですから、そうした要素をサーバが抽象化することでサーバアプリケーションが書きやすくなるのです。
HttpServletは、HTTPプロトコルのリクエストがあると処理が動くというモデルで、大きくとらえるとIoCに含まれます。サーバアプリケーションはクライアントの要望に答えるのが原則ですからIoCのモデルが似合うのです。J2EEアプリケーションサーバも同じですがJ2EEを含んでしまうのが重くなる原因。現在のGeronimoやJBossはJ2EEに縛られずサーバアプリケーションを書くことも可能になっています。
Java以外の実装言語サポート
これだけ聞くとSCA（Service Component Architecture）が思い浮かびます。SCAについては、この記事（SOAの技術仕様がついに完成! - SCAのいろはを学ぶ）がわかりやすいですが、
SCAが目指すものは、コンポーネントという単位で分けられた、様々な粒度のプログラム部品を適切に組み合わせることで巨大なシステムの構築を可能にすることである。また、「コンポーネントを組み合わせる」ことと「コンポーネントを実装する」ことをかなり厳密に区別しており、理論的には、どんな実装技術 (Java、C++、BPELなど)で作成されたコンポーネントもSCA仕様に則っていれば問題なく組み合わせることができる。
というもの。詳しくは記事をみてもらえばいいのですが、１つのコンポーネントをアセンブル（組み上げる）ための要素が分解されており、その書き方が仕様化されています。
SCAは、実装を多言語化できることよりも純粋に「組み合わせること」と「実装」が徹底的に分離されていることが面白い。そうすることで実装の再利用が可能になります。EJBの失敗は、EJBが想定する依存モデルが単純すぎたことにあります。エンティティを使いまわすには、コンテキスト（文脈）ごとに動きを変える必要性があるのです（いろんな意味で）。
Apache Composerとは
で、このApache Composerって何なのか。あえて「IoCコンテナ」と言っているということであれば、イマドキの実装モデルを利用したコンポーネント指向でイベントドリブンなコンテナになると思います。SCAのサブセットみたいな、でも、イベントやライフサイクルが強く意識されるはず。
これからのアプリケーション・アーキテクチャが「イベント指向」に向かう中で、試金石的なプロジェクトなればうれしーなーと思う次第です。
とはいえ、まったく情報ないので、どうなるかわからんのですが。
