仲介
仲介（intermediation）は適切なタイミング、場面、順序で現れる2つの対象の間で重要になります。企業向けソフトウェアの開発において仲介は重要な概念です。仲介を用いると、伝統的なオブジェクト設計では容易に解決できない問題を扱えるようになるからです。そうした問題の一例がセキュリティです。すべてのシステム処理に対してポリシーが認証を要求するアプリケーションでは、認証情報を専用のオブジェクトにカプセル化するオブジェクト指向のアプローチをとるのが適切です。ただし、プログラマは新たなシステム処理を作成するたびにこのコンポーネントへの委譲を忘れずに行わなければなりません。別の方法として、フィルタやインターセプタ、または定評のあるアスペクト指向プログラミング（AOP）のような手法を使ってコードの外側にあるアプリケーションにこのポリシーを適用することもできます。先ほど言及したセキュリティのような問題は1つのアプリケーションの中で何度も出てくるため、複数の分野にわたる問題としてよく取り上げられています。仲介とは、こうした問題をモジュール化する手法だと言えます。
AOPはSpringのコアとなる特徴なので、Springがこの領域で豊富な機能を提供しているのはごく自然なことです。Springでは、いくつかの仕組みによってアプリケーションに動作を追加することが可能です。Spring 1.2では、このような動作を記述する際に、ポイントカット、アドバイス、アドバイザの定義と、1つのアプリケーションへのワイヤリングを行うXML設定ファイルを使っていました。Spring 2.0では、AspectJとの統合が緊密に行われており、注釈またはXMLによるアスペクトの定義が可能になっています。
AspectJは、アプリケーションのほとんどすべての側面を制御できる強力なAOPフレームワークです。AOPの実装の詳細については、Brett Schuchertの優れたWikiページを参照するとよいでしょう。
Springの成功に大きな影響を受けたEJB 3.0の仕様では、仲介のサポートに向けた最初の一歩としてメソッドインターセプションの概念を導入しています。インターセプタによって、EJBメソッドに関連したカスタムコードの実行が可能になります。インターセプタはEJBの特別なメソッドか、まったく別のクラスのどちらかです。また、インターセプタは注釈またはXMLによってメソッドにマッピングすることができます。SpringのAOP（特にAspectJとの結合時）ほどの堅牢性はないものの、インターセプタは非常に便利な機能を仕様に準拠した形で提供しています。
表4に、SpringとEJB 3.0がサポートする仲介の違いをまとめておきます。
| 機能 | Spring | EJB 3.0 |
| メソッドインターセプション | √ | √ |
| スコープ | 任意のオブジェクト | EJBのみ |
| ポイントカット | √ | -- |
| イントロダクション | √ | -- |
| 統合 | AspectJ | -- |
| 標準 | AOPアライアンス | JCP |
統合の方針
本稿で見てきたように、本質的に異なるものでありながら、SpringとEJB 3.0が対応している問題には同じものが数多くあります。予想していたとおり、両テクノロジはこうした問題を別々の方法で解決しており、それぞれに長所と短所があります。確かに、全面的にどちらか一方を採用したい場面もあるでしょうが、それぞれの長所を組み合わせることも検討する必要があります。
以下では、そのための方針をいくつか紹介します。
- SpringアプリケーションでJava Persistence APIを利用する
- SpringアプリケーションにEJB 3コンポーネントを注入する
- EJB 3コンポーネントにSpring Beanを注入する
- Pitchforkを利用してSpring内部でEJB 3を使えるようにする
この他に、状況によっては、ベンダ固有の機能によってEJBの欠点を補うというアプローチも考えられます。例えばJBossのアプリケーションサーバは、EJB 3.0実装の上で堅牢なAOPと依存性注入の機能を提供しています。
おわりに
EJB 3.0は、企業向けJavaアプリケーションの開発支援に役立つ多くのサービスを引き続き提供しつつ、企業向けコンポーネント開発の容易化という目標を達成しています。これに対しSpringフレームワークは、これまで説明してきたように、強力で順応性があって検証可能な企業向けアプリケーションの開発における柔軟性を大きく向上させながらも、EJB 3.0に匹敵するサービスを見事に提供しています。
シリーズ第1回の記事では、持続性、トランザクション管理、ステートフルネスという観点でSpringとEJB 3.0の比較を行い、この2つのフレームワーク間の特徴的な違いとして、ステートフルネス、柔軟性、設定容易性、標準化のサポートについて詳しく説明しました。第2回となった本稿では、メッセージング、リモート処理、依存性管理、仲介のサポートを取り上げました。
メッセージングについては、SpringとEJB 3.0がまったく対等なサポートを提供しています。メッセージ駆動Beanは、重要かつ実績のあるEJBの要素です。一方、メッセージ駆動POJOはSpringに新しく追加されたものです。しかし、Springではテンプレートおよびメッセージコンバータという形でJMSメッセージ送信のサポートが加えられています。
リモート処理のサポートという点では、EJB 3.0の方がSpringフレームワークよりも強力です。事実、Rod Johnsonの著書『J2EE Development without EJB』では、EJBにとって十分な効果を発揮できて明らかに最適な事例となる対象の1つとして分散アプリケーションが挙げられています。本シリーズの第1回では、EJBが自らを分散コンポーネントアーキテクチャと定義していると述べました。分散はEJBそのものにとって重要な要素なので、この領域でEJBが秀でているのは当然と言えます。リモート処理は多くのアプリケーションに不必要な複雑さをもたらしますが、リモート処理が重要な位置を占めるアプリケーションの開発には、EJBを強くお勧めします。
依存性管理と仲介は、Springフレームワークの強力な側面です。事実、Springの柔軟性と拡張性は、これら2つの領域でのSpringの強さによるところが大きいと考えられます。一方、依存性管理および仲介に対するEJB 3.0のサポートはSpringに比べると見劣りします。Springは依存性管理および仲介を強力にサポートしており、特にテストのしやすさと実行時の設定容易性に優れています。
そのうえSpringでは、さまざまな環境で実行できるようにするための設定がEJB 3.0よりも容易に行えます。例えば、EJB 3.0ではJava 5が必要になりますが、Springでは不要です。大企業の多くはまだJava 5に移行していないので、この点は重要な違いです。また、EJB 3.0にはEJBコンテナが必要です（このコンテナは組み込まれているかもしれません）が、SpringはJSE環境で実行できます。さらに、EJB 3.0にはSpringにはない追加パッケージや配備のための要件があります。このように、設定の容易さと柔軟性の面ではEJB 3.0よりもSpringの方が優れているのは間違いないのですが、Springを効果的に用いるには経験と専門的な知識が必要です。もちろん、企業向けのソフトウェア開発では常にスキルが求められます。この種のアプリケーションは、今日開発されている複雑で価値の高いアプリケーションの一部であるため、当然ながら高いスキルが求められます。
