Spring 2.0.1とBEA WebLogic Server 9.2の統合

Andy Piper、Eric Hsiao、Rod Johnson、Chris Wall著
2007年4月23日（翻訳記事2007年10月25日）

注記：この記事の発表後にSpring 2.0.2キットが公開されており、現在はダウンロードできるようになっています。

要約

1年以上前に、私たちは Spring 1.2.xとWebLogic Server 9.0の統合に関する記事を発表しました。その後、新しいバージョンのSpringとBEA WebLogic Serverの動作も認定してきましたが、現在ではWebLogic Server 9.2とSpring 2.0が最新の組み合わせになっています。この2つのバージョンはいずれも機能性、使いやすさ、パフォーマンスが大幅に向上しているため、それを反映するためにこの記事を更新することにしました。

BEA WebLogic Server 9.2は、Sun Microsystems社のJava EE 1.4プラットフォームを実装した最先端のサーバです。ただし、WebLogic Serverの価値提案の核心は、Java EE仕様ではカバーされない範囲、すなわち、管理機能の強化、使いやすさ、高可用性、スケーラビリティ、信頼性、性能といったことにあります。実際、WebLogic Serverの価値は特定のプログラミングモデルに限定されないため、WebLogic Serverは新しいタイプのJava EE以外のJavaプログラミングモデルとも自然にマッチします。これらのうち、近年登場した最も興味深いものは、Spring Frameworkが事実上標準として実装したIoC（Inversion of Control：制御の反転）に基づくモデルです。この記事では、Spring 2.0 Framework、WebLogic Serverの新機能、および双方の統合を紹介します。組み合わせることにより、相乗効果で、より大きなメリットが得られることがおわかりいただけるでしょう。

この記事の構成

最初の2つのセクションでは、SpringとWebLogic Serverの概要およびそれぞれの特徴について説明します。Spring Frameworkをよくご存知の場合は、第1セクションを飛ばしてもかまいません。また、WebLogic Serverをよくご存知の場合は、第2セクションを飛ばしても結構です。この記事は主にこれら2つのテクノロジの統合に関するものなので、残りのセクションでは、すべてこの統合について説明します。話を具体的なものにするために、まず、WebLogic Serverに付属しているサンプルアプリケーションであるMedRecについて、元のJava EE版のものと、Spring Frameworkを使って作り直したものを分析します。その後、特定の統合ポイントについて詳細に検証します。WebLogic Serverの上にSpringアプリケーションを開発しようとしている場合は、この詳細な説明がきっと役立つことでしょう。どういったことが可能なのかを知りたいだけなら、タイトルに目を通し、内容は後でご覧ください。最後に、今後の開発についての現在の考えを要約して紹介します。

Spring入門

このセクションでは、バージョン2.0の新機能も含め、Spring Frameworkの特徴を簡単にまとめて紹介します。

Springは階層型Java/Java EEアプリケーションフレームワークで、Rod Johnson氏の著書『 Expert One-on-One J2EE Design and Development』（2002年Wrox Press刊、邦訳『実践J2EEシステムデザイン』）で公開されたコードをベースにしたものです。Java EEはもっと使いやすいものでなければならず、プラットフォームの能力を犠牲にせずにJava EE開発を実現するよりシンプルなアプローチを確立することは可能である、と私たちは信じています。それゆえ、Springは存在するのです。

Springにより、アジャイル（俊敏な）Java EE開発が可能になると共に、 POJO（Plain Old Java Object）を使ってJava EEアプリケーションを開発できるようになります。

Springによる開発作業の向上

基本的にSpringでは、構成しやすい、XML駆動型のIoC（Inversion of Control：制御の反転）コンテナを提供します。IoCは、「そちらからは連絡しないでください。必要があればこちらから連絡しますから」という、いわゆる「ハリウッド」原則に基づいています。この枠組みでは、アプリケーション内のJavaオブジェクト間の関係は、直接プログラミングされるのではなく、コンテナによって注入されます。この注入にはコンストラクタ注入とセッター注入の2つの形式があり、そのいずれになるかは、生成したJavaオブジェクトにコンテナが情報を注入する際にオブジェクトのコンストラクタを使用するかミューテータメソッドを使用するかで決まります。

Springでは、注入されるプロパティ（または他のBeanへの参照）はXMLファイルで構成されるため、コンフィグレーションはほとんど瑣末な作業になります。これとさらに、トランザクションやセキュリティなどの属性を非侵襲的に（すなわち、他の情報に破壊的な影響を及ぼさずに）追加できるAOPフレームワークが組み合わされば、つまり、開発者はJava EEの開発やコンフィグレーションの複雑な作業に忙殺されるのではなく、ビジネス上の問題を解決するソリューションの開発に専念できることになります。また、コンテナは非侵襲的であるため、ベンダ固有（Springも含む）のアーティファクトでビジネスコードが悪影響を受けることがなく、安心でもあります。

Springアプリケーションのコンポーネント

すでに述べたように、Springは、コンフィグレーションとアプリケーションオブジェクトの関連付けを一元的かつ自動的に行える軽量コンテナを提供します。このコンテナは非侵襲的であり、IoCを通じて一貫性のある透過的な方法で一連の疎結合コンポーネント（POJO）から複雑なシステムを構築することができます。このコンテナにより、俊敏で活用性の高い開発が可能になるほか、ソフトウェアコンポーネントをまず開発し個別にテストした後でデプロイする環境（Java SEまたはJava EE）に合わせてスケールアップできるようになることで、アプリケーションのテスト容易性とスケーラビリティが向上します。さらにその他にも、Springには開発者にとって便利な機能が以下の通り多数用意されています。

  • トランザクション管理用の共通の抽象化レイヤ：トランザクションマネージャのプラグインが可能になると共に、低レベルな問題を扱わなくてもトランザクションのデマーケーション（境界設定）を容易に行えるようになります。JTAと単一JDBCデータソース向けの汎用戦略が組み込まれています。JTAやEJB CMT（コンテナ管理トランザクション）とは異なり、SpringのトランザクションサポートはJava EE環境に縛られたものではありません。トランザクションのセマンティクスはAOPを使用してPOJOに適用し、XMLまたはJava SE 5の注釈を使用して構成するため、柔軟性に優れ、完全に非侵襲的なソリューションを実現することができます。
  • JDBC 抽象化レイヤ：これにより、有用な例外階層が提供され（SQLExceptionからベンダ固有のエラーコードを取り出すことはもはや不要）、エラー処理が簡略化され、そして作成しなければならないコードの量が大幅に減少します。JDBCを再び使用する際にまたfinallyブロックを記述する必要はありません。JDBCの例外は、Springの汎用DAO例外階層に準拠しています。
  • 業界トップのオブジェクト／リレーショナルマッピングソリューションとの統合：リソース所有者の観点では、DAO実装のサポートとトランザクション戦略。多数のIoCコンビニエンス機能の本格サポートにより、O/Rマッピング統合に関する数々の典型的問題に対処。これらはすべて、Springの汎用トランザクションおよびDAO例外階層に準拠しています。また、Spring 2.0は、Java Persistence API（JPA）と完全に統合可能です。
  • AOP 機能：Springのコンフィグレーション管理に完全統合されています。Springで管理される任意のオブジェクトをAOP対応にでき、宣言的トランザクション管理などのアスペクトを追加することができます。Springを利用すれば、EJB抜きで宣言的トランザクション管理が可能です。JTAすら不要です。
  • 柔軟性のある MVC Web アプリケーションフレームワーク：Springのコア機能をベースに構築されています。このフレームワークは戦略用インタフェースを通じて完全に構成でき、JSP、Velocity、Tiles、iText、POIなどの複数の表示技術に対応しています。Springの中間層は、Struts、WebWork、Tapestryといった他のいかなるWeb MVCフレームワークに基づいたWeb層とも容易に組み合わせることができます。
  • ユーザが拡張可能なコンフィグレーション層：ユーザは、独自のカスタムXMLタグをVanilla Springのコンフィグレーションに取り込むことができます。この機能はSpring 2.0のコアライブラリ全体でも広範囲で採用されているため、一般的なSpring機能の構文と使いやすさが改善します。
  • 非同期プログラミング抽象化：フレームワークに依存しない、JMSプロバイダとのトランザクションの統合のためのメッセージ駆動型POJO（MDP）や、commonj、Java SE同時ユーティリティ、Quartzなどの非同期スケジューリングメカニズムとの統合、標準のイベントサポートが含まれます。

Springの機能はすべて、どのJava EEサーバでも利用でき、その大半は非管理対象の環境でも利用できます。Springの主眼は、特定のJava EEサービスに縛られていない再利用可能なビジネスオブジェクトおよびデータアクセスオブジェクトを実現することです。そのようなオブジェクトは、Java EE環境（WebやEJB）、スタンドアロンアプリケーション、およびテスト環境のいずれでも問題なく再利用することができます。

Springの階層化アーキテクチャにより、柔軟性が非常に高まります。Springの機能はすべて、下位レベルの機能をベースにしています。そのため、例えば、MVCフレームワークやAOPサポート機能を利用せずにJavaBeanのコンフィグレーション管理を利用することができます。しかし、Web MVCフレームワークやAOPサポート機能を利用すれば、それらがコンフィグレーションフレームワークをベースにしていることがわかるため、それについての知識をすぐに活かすことができます。

BEA WebLogic Server 9.2入門

このセクションでは、提供されるプログラミングモデルではなく、基盤となるインフラストラクチャに重点を置いて、BEA WebLogic Serverの機能を手短にまとめて説明します。

WebLogic Serverは、エンタープライズ向けのスケーラブルなJava EEアプリケーションサーバです。WebLogic Serverのインフラストラクチャでは、多様な分散アプリケーションのデプロイメントをサポートしており、どのような種類のアプリケーションにとっても理想的な構築基盤となります。

WebLogic Serverでは、Sun Microsystems社の Java EE 1.4仕様を実装しており、データベース、メッセージングサービス、外部エンタープライズシステムへの接続など、さまざまなサービスにアクセスできる分散Javaアプリケーションを構築するための標準のAPI群が用意されています。エンドユーザクライアントは、WebブラウザクライアントやJavaクライアントを使用して、これらのアプリケーションにアクセスします。Java EEは広く知られたテクノロジであるため、ここではこれ以上詳しい解説はしません。詳細については、WebLogic Serverのマニュアル（「プログラミングモデル」）を参照してください。

WebLogic Serverでは、Java EEが実装されているだけでなく、企業がミッションクリティカルなアプリケーションを堅牢性、安全性、および可用性が高くスケーラブルな環境にデプロイすることができます。これらの機能により、企業は、WebLogic Serverインスタンスのクラスタを構成して、負荷を分散したり、ハードウェアなどの障害が発生した場合に備えて処理能力に余裕を持たせることができます。新しく導入された診断ツールでは、システム管理者がデプロイ済みのアプリケーションやWebLogic Server環境自体のパフォーマンスを監視および調整することができます。また、人の手を煩わせずに自動的にアプリケーションのスループットを監視および調整するようにWebLogic Serverを構成することもできます。一方、幅広いセキュリティ機能により、サービスへのアクセスの保護、企業データの安全性の確保、そして悪意のある攻撃の防止が可能になります。

WebLogic Serverによるサービス品質の向上

他の多くのBEA製品と同様に、WebLogic Serverの表立った機能はほんの氷山の一角に過ぎません。WebLogic Serverには特に、可用性の高いスケーラブルなアプリケーションのデプロイメントをサポートする、以下のような数々の機能とツールが用意されています。

  • WebLogic Serverクラスタでは、作業負荷が複数のWebLogic Serverインスタンスに分散されるため、アプリケーションのスケーラビリティと信頼性がもたらされます。着信するリクエストを、処理中の作業量に応じて、クラスタ内のWebLogic Serverインスタンスにルーティングすることができます。ハードウェアなどの障害が発生した場合でも、他のクラスタノードでセッション状態を把握できるため、そのノードで障害発生ノードの作業を再開することができます。さらに、単一のマシンでサービスをホストするようにクラスタを実装することができ、障害発生時にサービスを別のノードに移行するオプションも設定可能です。
  • WebLogic Serverでは、単一クラスタ内の複数サーバにわたるHTTPセッション状態のレプリケートだけでなく、複数のクラスタにわたるHTTPセッション状態のレプリケートも可能なため、複数の地理的領域、電力供給網、インターネットサービスプロバイダにまで可用性と耐障害性が拡張されます。
  • ワークマネージャは、ユーザにより定義されたルールに基づいて作業の優先順位を決めるほか、実際の実行時パフォーマンスの統計データを監視します。こうした情報は、その後、アプリケーションのパフォーマンスを最適化するために使用されます。ワークマネージャは、WebLogic Serverドメイン全体にグローバルに適用することも、特定のアプリケーションコンポーネントに適用することもできます。
  • 過負荷保護機能により、過負荷状態の検出、回避、およびその状態からの回復が可能になります。
  • ネットワークチャネルでは、ネットワークトラフィックをその種類に応じてチャネルに分けることにより、ネットワークリソースの効果的利用を促進します。
  • WebLogic Server永続ストアは、永続性を必要とするWebLogic Serverのサブシステムやサービスで利用できる組み込み型の高性能なストレージソリューションです。例えば、永続JMSメッセージの格納や、ストアアンドフォワード機能を用いて送信されたメッセージの一時的な格納が可能です。この永続ストアでは、ファイルベースのストアやJDBC対応データベースに対する永続性をサポートします。
  • ストアアンドフォワードサービスを利用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。ネットワーク上の問題やシステム障害が原因で、メッセージ送信時にメッセージの宛先がアクセス不能になっている場合、メッセージはローカルのサーバインスタンスにいったん保存され、リモートの宛先がアクセス可能になった時点でそこに転送されます。
  • エンタープライズ向けデプロイメントツールを使用すると、アプリケーションのデプロイメントや、開発フェーズから運用環境へのアプリケーションの移行が容易になります。
  • プロダクション再デプロイメント（運用時再デプロイメント）を行うと、古いバージョンのエンタープライズアプリケーションで処理中の作業を中断せずに、そのアプリケーションの新しいバージョンをデプロイできます。

Pages: 1, 2, 3, 4

Next Page »