Spring Framework

Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークである。単に Spring とも呼ばれる。ロッド・ジョンソンが自著 [1]と共にリリースしたのが最初である。.NET Framework 向けの移植版もある。2006年、Spring Framework 1.2.6 は Jolt productivity award を受賞した。

Spring Framework は特定のプログラミングモデルを強制するものではないが、Javaコミュニティでは Enterprise JavaBeans  モデルの代替・置換・追加として広く認知されつつある。設計上、このフレームワークはJava開発者の自由度を高くしているが、ドキュメントが豊富であり、よくある状況に使える使いやすいソリューションを提供する。

Spring Framework の中核機能は任意のJavaアプリケーションで使えるが、Jakarta EE上に Web ベースのアプリケーションを構築するための拡張や改善が豊富に用意されている。その用途で Spring を使うことが多く、注目されている。

最初のリリースは、2003年6月で、Apache License 2.0 でライセンスされていた。1.0 がリリースされたのは2004年3月である。

1. 概要
-----

Spring Framework は、Javaプラットフォームに基づいたアプリケーションを作成しようとするJava開発者や組織が直面する課題に解決策を与える。Spring Framework は Jakarta EE だけと結びついているわけではなく、広範囲なインテグレーションが可能であり、それが広く採用されている重要な理由でもある。

Spring Framework は従来的なプログラミングモデルを使わずに、効率的に複雑なアプリケーションを作成するのに必要な機能を提供する。また、Javaプラットフォームにおいても目新しい機能をいち早く取り入れることでも知られている。

Spring Framework は、一貫したモデルを提供し、そのモデルをJavaプラットフォーム上で作成される様々なアプリケーションに適用可能にするフレームワークである。

1.1. モジュール
----------

Spring Framework は、様々なサービスを提供する幾つかのモジュールから構成されている。

制御の反転コンテナ: 主に依存性の注入によって、アプリケーションのコンポーネント配置とJavaオブジェクトのライフサイクルを管理
アスペクト指向プログラミング: クラス横断的な処理の実装を可能とする
データアクセス: JDBCとオブジェクト関係マッピングツールを用い、Javaプラットフォーム上でRDBアクセス機能を提供。また、NoSQL系データベースもサポート
トランザクション管理: 各種トランザクション制御APIを統合し、Javaオブジェクトのトランザクション管理を提供
Model View Controller: HTTPとServletベースのフレームワークで、WebアプリやREST準拠Webサービスの拡張とカスタマイズのためのフックを多数提供している。
リモートアクセスフレームワーク: 利用者の定義に従い、遠隔手続き呼出し  の形態でJavaオブジェクトをネットワーク上でインポートまたはエクスポートする。サポートする通信プロトコルとしては RMI、CORBA、Webサービスを含むHTTPベースのプロトコル  などがある。
設定より規約: :en:Spring Roo モジュールによって、Spring ベース業務アプリケーションのRADソリューションを提供
バッチ処理: 大量データ処理向けのフレームワークとして次のような機能を提供：ログ取得、トランザクション管理、統計情報取得、ジョブの再起動や起動抑止、資源管理
認証・認可フレームワーク: :en:Spring Securityサブプロジェクトの成果物を用い、利用者定義に従った認証・認可機能を提供。各種標準、プロトコル、ツール、手法をサポート
リモート管理フレームワーク: JMXを使ったローカルおよびリモートのJavaオブジェクトの構成管理。
メッセージフレームワーク: 標準的なJMSのAPIに対する機能拡張。利用者定義に従い、JMSのメッセージキューから透過的にメッセージ受信するためのリスナーオブジェクトを登録可能とする
テスト機能: 単体テストと結合テストを書くためのクラス群を提供

1.2. Inversion of Control コンテナ
------------------------------

Spring Framework の中核は Inversion of Control コンテナであり、コールバックを使ってJavaオブジェクトのコンフィギュレーションおよび管理の一貫した手段を提供する。このコンテナは //BeanFactory//、//ApplicationContext//、//Core container// などとも呼ばれる。

このコンテナは多くの責務と拡張ポイントを持っており、それらが全て Inversion of Control を形成すると見ることができる。例えば、オブジェクト生成、オブジェクトのコンフィギュレーション、初期化メソッド呼び出し、登録されたコールバックオブジェクトにオブジェクトを渡すこと、などである。コンテナの機能の多くがオブジェクトのライフサイクル形成に関わり、それがコンテナの提供する最重要機能の1つとなっている。

このコンテナが生成するオブジェクトを //Managed Objects// または //Beans// と呼ぶ。通常、//Bean definitions// を含むXMLファイルをロードすることでコンテナがコンフィギュレーションを行う。これらファイルにはオブジェクト生成に必要な全ての情報がある。オブジェクトが生成され、コンフィギュレーション時にエラーが発生しなかった場合、利用可能状態になる。

オブジェクトを取得するには、「依存性の参照」または「依存性の注入」を行う。「依存性の参照」とは、呼び出し側がコンテナオブジェクトに対して名前や型を指定してオブジェクトについて問い合わせるパターンである。「依存性の注入」とは、コンテナがコンストラクタまたはプロパティまたは Factory メソッドを使って、他のオブジェクトに名前でオブジェクトを渡すパターンである。

多くの場合、このコンテナを使わずに Spring Framework の他のパーツだけを使うことは可能だが、このコンテナを使うことでアプリケーションのコンフィギュレーションとカスタマイズが容易になる。Spring コンテナは一貫したアプリケーションのコンフィギュレーション機構を提供し、小さなアプリケーションから大きなものまで、ほとんど全ての環境で機能する。

[2] プロジェクトの成果物を使えば、このコンテナを EJB3 コンテナに部分的に準拠させることができる。Spring Framework が標準に準拠していない点を批判する者もいる。しかし、[3] は EJB3 準拠を最終目標とは考えておらず、Spring Framework とそのコンテナの方がより強力なプログラミングモデルだと主張している。

1.3. アスペクト指向プログラミングフレームワーク
--------------------------

Spring Framework には自前のAOPフレームワークがあり、「アスペクト」におけるクラス間を横断するような機能のモジュール化を行う。独自のAOPフレームワークを作る動機は、設計においても実装においてもコンフィギュレーションにおいてもあまり複雑すぎない基本的AOP機能を提供できると考えたためである。Spring AOP フレームワークは Spring コンテナを最大限に利用している。

Spring AOP フレームワークは基本的に横取り方式であり、実行時にコンフィギュレーションされる。このため、コンパイル時やロード時に織り込む  必要がない。一方、横取りではジョイントポイントにあるオブジェクトの public または protected のメソッドしか対象にできない。

AspectJ と比較すると、Spring AOP は非力だが単純である。Spring 1.2 では AspectJ のアスペクトをコンテナ内で構成できる。Spring 2.0 ではさらに AspectJ との連携を強化し、例えば :en:Pointcut 言語が流用されている。

Spring AOP は Spring Framework 自体の横断的関心事に対しても機能する。コンテナを使って生成されコンフィギュレーションされた任意のオブジェクトに Spring AOP を使って質を向上させることができる。

Spring Framework はトランザクション管理、セキュリティ、リモートアクセス、JMX などの部分に Spring AOP を使っている。

バージョン2.0以降、Spring は AOP のコンフィギュレーション方法を2種類提供している。

スキーマベースの手法
@AspectJベースの注釈スタイルSpringチームは、新たなAOP関連用語を導入しないことを決めている。従って、Spring のドキュメントに出てくるAOP関連用語は、AspectJなどと同じものだけである。

1.4. データアクセスフレームワーク
-------------------

Spring のデータアクセスフレームワークは、アプリケーションからデータベースを利用しようとしたときに開発者が直面する課題に対処する。Javaにおける主要なデータアクセスのフレームワークを全て提供している。すなわち、JDBC、iBATIS、Hibernate、JDO、JPA、Oracle :en:TopLink、Apache :en:Ojb、:en:Apache Cayenne などである。

これらのフレームワークについて、Spring は以下の機能を提供する。

リソース管理 - データベースのリソースの自動的な獲得・解放
例外処理 - データアクセス時の例外を Spring のデータアクセス階層に変換
トランザクション参加 - 実行中トランザクションへのトランザクション参加
リソース・アンラッピング - コネクションプール・ラッパーからデータベースオブジェクトを取り出す。
BLOBおよびCLOB処理のための抽象化これらの機能は、Spring が各フレームワーク用に提供する //Template// クラスを使うことで利用可能になる。この //Template// は無用であり、Hibernate API を直接使うのと比較して何の利点もないという批判もある。それに応えて、Spring では Hibernate と JPA のAPIを直接使えるようにした。しかしその場合、上述の機能が提供されないため、アプリケーション側で全てを処理しなければならない。

Spring のトランザクション管理と共にデータアクセスフレームワークを使うことで、各種データアクセスフレームワークの柔軟な抽象化が可能になる。Spring Framework は共通のデータアクセスAPIは提供していない。その代わり、サポートしているAPIをほぼそのまま使えるようにしている。

1.5. トランザクション管理フレームワーク
----------------------

Spring のトランザクション管理フレームワークは、Javaプラットフォームに抽象化機構をもたらす。以下のような抽象化が可能である。

ローカルなトランザクションとグローバルなトランザクションの抽象化
入れ子になったトランザクションの抽象化
トランザクションのセーフポイントの抽象化
ほとんど全てのJavaプラットフォーム環境での抽象化JTAと比較すると、JTAは入れ子とグローバルのトランザクションのみをサポートしており、アプリケーションサーバが必須である。

Spring Framework には、以下のようなトランザクション管理戦略のための //PlatformTransactionManager// がある。

JDBCの //Connection//
オブジェクト関係マッピングの //Units of Work//
JTAの //TransactionManager// と //UserTransaction//
その他抽象化機構以外にこのフレームワークは、アプリケーションにトランザクション管理機能を付与する2つの方法を提供する。

プログラミング。Spring の //TransactionTemplate// を使う。
コンフィギュレーション。XMLあるいは Java 5 の注釈のようなメタデータを使う。Spring のデータアクセスフレームワークと共に使うことで、JTAやEJBを使わずにトランザクションシステムのコンフィギュレーションによる設定が可能である。Java Message Service やキャッシュエンジンとも連携できる。

1.6. Model-View-Controller フレームワーク
----------------------------------

Spring Framework には、当初の計画にはなかった、自前のMVCフレームワークがある。自前のWebフレームワークを作ることにしたのは、Apache Struts Webフレームワークに失望したためであり、他のフレームワークでは不足だったためである。開発者らは特に、プレゼンテーション層と要求処理層の分離、要求処理層とモデルの分離が不十分と判断した。

Strutsと同様、Spring MVC は要求ベースのフレームワークである。このフレームワークは、最近の要求ベースのフレームワークでは必須となっている全責務について Strategy インタフェースを定義している。各インタフェースの責務は十分単純明快なので、実装を作成するのは容易である。インタフェースは Servlet API と密に結合しており、そのAPIの能力をフルに発揮できる。この Servlet API との密結合があるため、Webアプリケーションの高度な抽象化ができないと指摘する者もいる。しかし、この結合があるおかげで Servlet API の機能をユーザーが使うことができ、同時に高度に抽象化されたフレームワークも提供している。

//DispatcherServlet// クラスは、フレームワークの :en:Front Controller pattern であり、HTTP要求の処理中に各種インタフェースに制御を委譲する。

Spring MVC の定義するインタフェースの中でも、以下のものが重要である。

HandlerMapping: 何らかの属性や条件に従って、入ってきた要求を処理するオブジェクトを選択する。
HandlerAdapter: 入ってきた要求を処理するオブジェクトを実行する。
Controller: Model と View の間にあって、入ってきた要求を管理し、適切な応答へリダイレクトする。
View: クライアントに応答を返す。
ViewResolver: ビューの論理名に基づいて View を選択する。
HandlerInterceptor: 入ってきた要求を横取りする。Servletフィルタに似ているが同じではない。
LocaleResolver: 個々のユーザーのロケールを解決し、オプションでセーブもする。
MultipartResolver: 入ってきた要求をラッピングすることで、ファイルアップロードを容易にする。各 strategy インタフェースには、フレームワーク全体の中での重要な責務がある。これらインタフェースが提供する抽象化はかなり強力で、実装では広範囲なバリエーションが可能である。Spring MVC にはこれらインタフェースの実装も含まれているが、開発者やベンダーが新たな実装を書くこともできる。Spring MVC はJavaの java.util.Map インタフェースを //Model// のためのデータ指向抽象化として使っており、キーは文字列値でなければならない。

これらインタフェースの実装のテストを容易にできる点は Spring MVC による高度な抽象化の重要な利点のひとつである。//DispatcherServlet// は Spring Inversion of Control コンテナと密に結合されており、アプリケーションのWeb層のコンフィギュレーションが可能である。しかし、Spring Framework の他の部分を使ったアプリケーションで Spring MVC を使わないという選択も可能である。

Spring MVC は Spring コンテナをコンフィギュレーションと組み立てに使っているため、Webベースのアプリケーションで Inversion of Control 機能の利点をフルに活用できる。

1.7. リモートアクセスフレームワーク
--------------------

Spring のリモートアクセスフレームワークは、Javaプラットフォーム上で利用可能なRPCベースの各種技術についての抽象化であり、クライアント接続とサーバ間のオブジェクトのエクスポートの両方で利用できる。その中でも最重要な機能は、Inversion of Control と AOP との組合せで、それら技術のコンフィギュレーションと利用を可能な限り容易にしている点である。

このフレームワークはまた、障害リカバリと、クライアント側での EJB 遠隔ステートレスセッション Bean のための最適化も提供している。

Spring は以下のようなプロトコルおよび他の製品との接続をサポートしている。

HTTPベースのプロトコル
[4]: バイナリ方式のシリアライズプロトコル。オープンソース。
RMI : RMI 基盤を使ってメソッド呼び出しする。ただし Spring 固有の方式。
RMI : RMI を使ってメソッド呼び出しする。通常のRMIのインタフェースに準拠。
RMI-IIOP : RMI-IIOP/CORBA を使ったメソッド呼び出し。
Enterprise JavaBeans クライアント接続
ローカルなEJBステートレスセッション Bean の接続: ローカルなステートレスセッション Bean と接続する。
リモートのステートレスセッション Bean の接続: リモートのステートレスセッション Bean と接続する。
SOAP
Apache Axis Webサービスフレームワークとの連携。[5] SOAPフレームワークは Spring Framework と連携し、サーバ上のオブジェクトをRPCスタイルでエクスポートする機能を提供する。

Spring のリモートアクセスフレームワークがサポートするRPCスタイルのプロトコルや製品について、クライアントもサーバも設定を Spring Core コンテナで行うことができる。

代替のオープンソース実装として [6] がある。これは一対一、一対多、動的サービス発見など、各種構成をサポートすることを意図したものである。

1.8. バッチ処理フレームワーク
-----------------

2008年4月に正式版がリリースされたバッチ処理用のSpringフレームワークのモジュール群。 InfrastructureとCoreの2種類のモジュールから構成されて、大量データの一括処理を行うことができる。 Ver1.0は、Java1.4のシングルプロセス・マルチスレッドをターゲットとしていたが、Ver2.0からは、Java1.5以上での動作となり、マルチプロセスにも対応した。

2. 脚注
-----

3. 参考文献
-------

4. 外部リンク
--------

[7]
[8]
[9]
[10]
[11]
[12]

4.1. 他の IoC/DI フレームワーク
----------------------

Google Guice
[13]
[14]
[15]

4.2. その他
--------

[16]