概要
Spring Framework は、Javaプラットフォームに基づいたアプリケーションを作成しようとするJava開発者や組織が直面する課題に解決策を与える。Spring Framework は Jakarta EE だけと結びついているわけではなく、広範囲なインテグレーションが可能であり、それが広く採用されている重要な理由でもある。
Spring Framework は従来的なプログラミングモデルを使わずに、効率的に複雑なアプリケーションを作成するのに必要な機能を提供する。また、Javaプラットフォームにおいても目新しい機能をいち早く取り入れることでも知られている。
Spring Framework は、一貫したモデルを提供し、そのモデルをJavaプラットフォーム上で作成される様々なアプリケーションに適用可能にするフレームワークである。
モジュール
Spring Framework は、様々なサービスを提供する幾つかのモジュールから構成されている。
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 コンテナは一貫したアプリケーションのコンフィギュレーション機構を提供し、小さなアプリケーションから大きなものまで、ほとんど全ての環境で機能する。
Pitchfork プロジェクトの成果物を使えば、このコンテナを EJB3 コンテナに部分的に準拠させることができる。Spring Framework が標準に準拠していない点を批判する者もいる。しかし、SpringSource は EJB3 準拠を最終目標とは考えておらず、Spring Framework とそのコンテナの方がより強力なプログラミングモデルだと主張している。
アスペクト指向プログラミングフレームワーク
Spring Framework には自前のAOPフレームワークがあり、「アスペクト」におけるクラス間を横断するような機能（横断的関心事（英語版））のモジュール化を行う。独自のAOPフレームワークを作る動機は、設計においても実装においてもコンフィギュレーションにおいてもあまり複雑すぎない基本的AOP機能を提供できると考えたためである。Spring AOP フレームワークは Spring コンテナを最大限に利用している。
Spring AOP フレームワークは基本的に横取り方式であり、実行時にコンフィギュレーションされる。このため、コンパイル時やロード時に織り込む (weaving) 必要がない。一方、横取りではジョイントポイント（英語版）にあるオブジェクトの 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などと同じものだけである。
データアクセスフレームワーク
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をほぼそのまま使えるようにしている。
トランザクション管理フレームワーク
Spring のトランザクション管理フレームワークは、Javaプラットフォームに抽象化機構をもたらす。以下のような抽象化が可能である。
- ローカルなトランザクションとグローバルなトランザクションの抽象化（ローカルなトランザクションにはアプリケーションサーバは不要）
- 入れ子になったトランザクションの抽象化
- トランザクションのセーフポイントの抽象化
- ほとんど全てのJavaプラットフォーム環境での抽象化
JTAと比較すると、JTAは入れ子とグローバルのトランザクションのみをサポートしており、アプリケーションサーバが必須である（場合によっては、アプリケーションサーバへのアプリケーションの配備も必要）。
Spring Framework には、以下のようなトランザクション管理戦略のための PlatformTransactionManager がある。
抽象化機構以外にこのフレームワークは、アプリケーションにトランザクション管理機能を付与する2つの方法を提供する。
- プログラミング。Spring の TransactionTemplate を使う。
- コンフィギュレーション。XMLあるいは Java 5 の注釈のようなメタデータを使う。
Spring のデータアクセスフレームワークと共に使うことで、JTAやEJBを使わずにトランザクションシステムのコンフィギュレーションによる設定が可能である。Java Message Service やキャッシュエンジンとも連携できる。
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フィルタに似ているが同じではない（オプションであり、DispatcherServlet で制御されない）。
- 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 機能の利点をフルに活用できる。
リモートアクセスフレームワーク
Spring のリモートアクセスフレームワークは、Javaプラットフォーム上で利用可能なRPCベースの各種技術についての抽象化であり、クライアント接続とサーバ間のオブジェクトのエクスポートの両方で利用できる。その中でも最重要な機能は、Inversion of Control と AOP との組合せで、それら技術のコンフィギュレーションと利用を可能な限り容易にしている点である。
このフレームワークはまた、障害リカバリ（接続障害後の自動再接続）と、クライアント側での EJB 遠隔ステートレスセッション Bean のための最適化も提供している。
Spring は以下のようなプロトコルおよび他の製品との接続をサポートしている。
- HTTPベースのプロトコル
- Hessian: バイナリ方式のシリアライズプロトコル。オープンソース。
- RMI (1): RMI 基盤を使ってメソッド呼び出しする。ただし Spring 固有の方式。
- RMI (2): RMI を使ってメソッド呼び出しする。通常のRMIのインタフェースに準拠。
- RMI-IIOP (CORBA): RMI-IIOP/CORBA を使ったメソッド呼び出し。
- Enterprise JavaBeans クライアント接続
- ローカルなEJBステートレスセッション Bean の接続: ローカルなステートレスセッション Bean と接続する。
- リモートのステートレスセッション Bean の接続: リモートのステートレスセッション Bean と接続する。
- SOAP
XFire SOAPフレームワークは Spring Framework と連携し、サーバ上のオブジェクトをRPCスタイルでエクスポートする機能を提供する。
Spring のリモートアクセスフレームワークがサポートするRPCスタイルのプロトコルや製品について、クライアントもサーバも設定を Spring Core コンテナで行うことができる（Apache Axis は除く）。
代替のオープンソース実装として Cluster4Spring がある。これは一対一、一対多、動的サービス発見など、各種構成をサポートすることを意図したものである。
バッチ処理フレームワーク
2008年4月に正式版がリリースされたバッチ処理用のSpringフレームワークのモジュール群。
InfrastructureとCoreの2種類のモジュールから構成されて、大量データの一括処理を行うことができる。
Ver1.0は、Java1.4のシングルプロセス・マルチスレッドをターゲットとしていたが、Ver2.0からは、Java1.5以上での動作となり、マルチプロセスにも対応した。
