Spring Framework
Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークである。単に Spring とも呼ばれる。ロッド・ジョンソンが自著 Expert One-on-One J2EE Design and Development（Wrox Press、2002年10月）と共にリリースしたのが最初である。.NET Framework 向けの移植版もある[2]。2006年、Spring Framework 1.2.6 は Jolt productivity award を受賞した[3]。 Spring Framework は特定のプログラミングモデルを強制するものではないが、Javaコミュニティでは Enterprise JavaBeans (EJB) モデルの代替・置換・追加として広く認知されつつある。設計上、このフレームワークはJava開発者の自由度を高くしているが、ドキュメントが豊富であり、よくある状況に使える使いやすいソリューションを提供する。 Spring Framework の中核機能は任意のJavaアプリケーションで使えるが、Jakarta EE（従前のJava Platform, Enterprise Edition）上に Web ベースのアプリケーションを構築するための拡張や改善が豊富に用意されている。その用途で Spring を使うことが多く、注目されている[4]。 最初のリリースは、2003年6月で、Apache License 2.0 でライセンスされていた。1.0 がリリースされたのは2004年3月である。 概要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 とそのコンテナの方がより強力なプログラミングモデルだと主張している[5]。 アスペクト指向プログラミングフレームワーク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種類提供している。
Springチームは、新たなAOP関連用語を導入しないことを決めている。従って、Spring のドキュメントに出てくるAOP関連用語は、AspectJなどと同じものだけである。 データアクセスフレームワークSpring のデータアクセスフレームワークは、アプリケーションからデータベースを利用しようとしたときに開発者が直面する課題に対処する。Javaにおける主要なデータアクセスのフレームワークを全て提供している。すなわち、JDBC、iBATIS、Hibernate、JDO、JPA、Oracle en:TopLink、Apache en:Ojb[6]、en:Apache Cayenne[7] などである。 これらのフレームワークについて、Spring は以下の機能を提供する。
これらの機能は、Spring が各フレームワーク用に提供する Template クラスを使うことで利用可能になる。この Template は無用であり、（例えば）Hibernate API を直接使うのと比較して何の利点もないという批判もある[8]。それに応えて、Spring では Hibernate と JPA のAPIを直接使えるようにした。しかしその場合、上述の機能が提供されないため、アプリケーション側で全てを処理しなければならない。 Spring のトランザクション管理と共にデータアクセスフレームワークを使うことで、各種データアクセスフレームワークの柔軟な抽象化が可能になる。Spring Framework は共通のデータアクセスAPIは提供していない。その代わり、サポートしているAPIをほぼそのまま使えるようにしている。 トランザクション管理フレームワークSpring のトランザクション管理フレームワークは、Javaプラットフォームに抽象化機構をもたらす。以下のような抽象化が可能である。
JTAと比較すると、JTAは入れ子とグローバルのトランザクションのみをサポートしており、アプリケーションサーバが必須である（場合によっては、アプリケーションサーバへのアプリケーションの配備も必要）。 Spring Framework には、以下のようなトランザクション管理戦略のための PlatformTransactionManager がある。
抽象化機構以外にこのフレームワークは、アプリケーションにトランザクション管理機能を付与する2つの方法を提供する。 Spring のデータアクセスフレームワークと共に使うことで、JTAやEJBを使わずにトランザクションシステムのコンフィギュレーションによる設定が可能である。Java Message Service やキャッシュエンジンとも連携できる。 Model-View-Controller フレームワークSpring Framework には、当初の計画にはなかった、自前のMVCフレームワークがある。自前のWebフレームワークを作ることにしたのは、Apache Struts Webフレームワークに失望したためであり[9]、他のフレームワークでは不足だったためである。開発者らは特に、プレゼンテーション層と要求処理層の分離、要求処理層とモデルの分離が不十分と判断した[10]。 Strutsと同様、Spring MVC は要求ベースのフレームワークである。このフレームワークは、最近の要求ベースのフレームワークでは必須となっている全責務について Strategy インタフェースを定義している。各インタフェースの責務は十分単純明快なので、実装を作成するのは容易である。インタフェースは Servlet API と密に結合しており、そのAPIの能力をフルに発揮できる。この Servlet API との密結合があるため、Webアプリケーションの高度な抽象化ができないと指摘する者もいる。しかし、この結合があるおかげで Servlet API の機能をユーザーが使うことができ、同時に高度に抽象化されたフレームワークも提供している。 DispatcherServlet クラスは、フレームワークの en:Front Controller pattern[11] であり、HTTP要求の処理中に各種インタフェースに制御を委譲する。 Spring MVC の定義するインタフェースの中でも、以下のものが重要である。
各 strategy インタフェースには、フレームワーク全体の中での重要な責務がある。これらインタフェースが提供する抽象化はかなり強力で、実装では広範囲なバリエーションが可能である。Spring MVC にはこれらインタフェースの実装も含まれているが、開発者やベンダーが新たな実装を書くこともできる。Spring MVC はJavaの これらインタフェースの実装のテストを容易にできる点は 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 は以下のようなプロトコルおよび他の製品との接続をサポートしている。
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以上での動作となり、マルチプロセスにも対応した。 脚注
参考文献
外部リンク
他の IoC/DI フレームワークその他
|
Portal di Ensiklopedia Dunia
