spring.html

ホーム
コンテンツにスキップ
検索にスキップ

サインインアカウント

Oracleアカウント

サインアウト

Oracleアカウント

アカウントを管理して、パーソナライズされたコンテンツにアクセスできます。
サインインアカウントを作成

クラウド・アカウント

クラウド・ダッシュボードへのアクセス、ご注文の管理など、さまざまな操作を行えます。
サインイン国を選択
- アカウント
- ヘルプ
国を選択
電話

Spring 2.5.xとOracle WebLogic Server 10.3の統合

Andy Piper、Eric Hsiao、Michael Chen、Rod Johnson、Chris Wall著
2008年7月28日

概要

オラクルは、2年以上前に Spring Framework 1.2.xとOracle WebLogic Server 9.2の統合を開始しました。 2007年には、 Spring Frame 2.0.2とOracle Weblogic Server 10.0で統合を更新しています。それ以来、SpringおよびOracle WebLogic Serverの後続バージョンを認定し、Oracle WebLogic Server 10.3とSpring 2.5.3の統合が実現しています。これらのバージョンはいずれも、機能、ユーザビリティ、およびパフォーマンスがさらに強化されているため、それらの情報を反映するためにこの記事を更新することにしました。

Oracle WebLogic Server 10.3は、Sun MicrosystemsのJava EE 5プラットフォームの主要な実装です。しかし、Oracle WebLogic Serverのコア・バリュー・プロポジションは、Java EE仕様（強化された管理、使いやすさ、高可用性、スケーラビリティ、信頼性、およびパフォーマンス）ではカバーされていない領域にあります。実際、Oracle WebLogic Serverのバリューは、特定のプログラミング・モデルに関連づけられていないため、新しい種類の非Java EE Javaプログラミング・モデルに自然に適合します。近年登場しているそのようなモデルの中でもっとも興味深いのは、Inversion of Control（IoC）に基づいているモデルで、Spring Frameworkは標準の実装となっています。この記事では、Spring 2.5.x FrameworkとOracle WebLogic Serverの新機能、およびこの2つの統合について説明します。ご覧いただければわかるとおり、この統合は、強力な相乗効果を生み出しています。

記事の構造

最初の2つの項では、Spring FrameworkとOracle WebLogic Serverの概要およびそれぞれの機能について説明します。 Spring Frameworkに精通している方は最初の項を、Oracle WebLogic Serverに精通している方は2つ目の項を、それぞれ読み飛ばしてください。この記事は、おもにこの2つのテクノロジーの統合に関するものであり、記事の残りの部分では統合について説明します。まず、新しいSpringのWLSコンポーネント用のDIおよびAOPの拡張機能について説明します。次に、いくつかのコンテキストを提供するために、Oracle WebLogic Serverに付属しているサンプル・アプリケーションのMedRecを、いずれもそのオリジナルのJava EE形式で検討し、Spring Frameworkを使用して作り直します。そのあと、統合の特定のポイントに関する詳細を説明します。 Oracle WebLogic ServerでSpringアプリケーションを開発する予定の場合は、役に立つ詳細な情報を見つけることができます。何ができるのかを知りたいだけであれば、タイトルだけを読み、内容はあとで読むこともできます。最後に、まとめを示し、検討している今後の開発の一部を紹介します。

注：SpringのMedRecサンプル・アプリケーションは、Oracle WebLogic Server 10.3リリースの間は変更されていません。 MedRecサンプル・アプリケーションは、近いうちに更新する予定です。この記事では、これまでにおこなった統合の強化点の一部について説明します。

Spring Frameworkの概要

この項では、Spring Framework 2.5.xの新機能の一部をはじめ、Spring Frameworkの機能の概要について説明します。

Spring Frameworkは、Rod Johnson（Wrox、2002年）が Expert One-on-One J2EE Design and Developmentで公開したコードに基づく、Java/Java EEアプリケーション・フレームワークで階層化されています。 Spring Frameworkが存在するのは、オラクルでは、Java EEは使いやすくする必要があり、Java EE開発へのアプローチは、プラットフォームの能力を犠牲にすることなく、よりシンプルにすることができると信じているからです。

Spring Frameworkを使用することで、Java EEでの開発を迅速におこなうことができ、一般的に POJOと呼ばれるPlain Old Java Objectを使用して、Java EEアプリケーションを開発できます。

強化されたSpring Frameworkでの開発経験

Spring Frameworkのコアとなるのは、構成の容易さ、XML駆動型、Inversion of Control（IoC）コンテナです。 IoCは、いわゆる"ハリウッド"の法則（"連絡しないでください。こちらから連絡します"）に基づいています。このスキームでは、アプリケーション内のJavaオブジェクト間のリレーションシップは、ユーザーが直接プログラミングするのではなく、コンテナによって 注入されます。この注入には、コンストラクタ注入とセッター注入の2つの形式があります。これは、コンテナが作成されたJavaオブジェクトに情報を注入する方法、つまりそのコンストラクタを介するか、ミューテータを介するかによって異なります。

Spring Frameでは、注入されたプロパティ、またはほかのBeanへの参照は、XMLファイルを使用して設定され、設定全体がほぼ簡略化されています。トランザクションやセキュリティなどの属性を非侵襲的に追加することが可能なAOPフレームワークと組み合わせることで、開発者は、Java EEでの開発または設定の複雑さに煩わされることなく、ビジネスの問題に対するソリューションの作成に集中できます。コンテナは非侵襲性であり、ビジネス・コードがベンダー固有の成果物（Spring Frameworkも含む）によって侵襲されないとわかっているので安心できます。

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

前述のとおり、Springには軽量のコンテナがあり、一元化された自動構成およびアプリケーション・オブジェクトの接続をおこないます。コンテナは、 非侵襲性で、IoCを介して、一連の疎結合コンポーネント(POJO)から複雑なシステムを一貫性のある透過的な方法で組み立てることができます。コンテナは、機敏性と活用可能性をもたらし、まずソフトウェア・コンポーネントを開発して単体でテストし、次に任意の環境（Java SEまたはJava EE）での開発に拡張できるようにすることで、アプリケーションのテスト容易性およびスケーラビリティを向上させます。さらに、Springには開発者が扱いやすい多くの機能があります。以下に列挙します。

トランザクション管理のための共通の抽象化レイヤー - プラガブルなトランザクション・マネージャを許可し、低レベルの問題に対処することなく、容易にトランザクションの境界を設定できるようにします。 JTAの汎用的な戦略および単一のJDBC DataSourceが含まれています。プレーンJTAまたはEJB CMTとは対照的に、Springのトランザクション・サポートは、Java EE環境とは関連づけられていません。トランザクション・セマンティックは、XMLまたはJava SE 5注釈を使用して設定されているAOPを使用してPOJOに適用され、柔軟性に優れた非侵襲性ソリューションを可能にします。
JDBC抽象化レイヤー - 意味のある例外階層（SQLExceptionからベンダー・コードを取り出さない）を提供し、エラー処理を簡素化し、ユーザーが記述する必要があるコード量を大幅に削減します。 JDBCを再使用するために、別のfinallyブロックを記述する必要はありません。 JDBC指向の例外は、Springの汎用DAO例外階層に準拠しています。
業界をリードするオブジェクト・リレーショナルなマッピング・ソリューションとの統合 - リソース・ホルダーの観点における、DAO実装のサポートおよびトランザクション戦略です。 IoCの多くの便利な機能を備えたファーストクラスのサポートを提供し、O-Rマッピング統合の一般的な問題の多くに対応します。これらはすべて、Springの汎用トランザクションおよびDAO例外階層に準拠しています。さらに、Spring 2.0.1は、Java Persistence API（JPA）との完全な統合を提供しています。
AOP機能 - Springの構成管理に完全に統合されています。 AOP対応の任意のオブジェクトをSpringで管理し、宣言的トランザクション管理などのアスペクトを追加できます。 Springを使用すると、EJBがなくても（JTAさえなくても）宣言的トランザクション管理をおこなえます。
柔軟なMVC Webアプリケーション・フレームワーク - Springのコア機能で構築されています。このフレームワークは、戦略インタフェースを使用することで設定可能度が増しており、JSP、Velocity、Tiles、iText、POIなどの複数のビュー・テクノロジーに対応しています。 Springの中間層は、Struts、WebWork、またはTapestryなどのほかのWeb MVCフレームワークに基づくWeb層と容易に組み合わせることができます。
ユーザーが拡張可能な構成レイヤー - ユーザーのカスタムXMLタグをVanilla Spring構成に組み込むことができます。この機能は、Spring 2.0.xコア・ライブラリ全体で広範に活用されており、共通のSpring機能の構文およびユーザビリティが強化されています。
非同期プログラミングの抽象化 - JMSプロバイダとのフレームワークに中立なトランザクション統合のためのMessage Driven POJO（MDP）、commonj、Java SE並列ユーティリティ、Quartzなどの非同期のスケジューリング・メカニズムとの統合、ネイティブなイベント・サポートが含まれます。

Springの機能はすべて、Java EEサーバーで使用でき、機能の大部分は、管理対象外の環境でも使用できます。 Springの主眼点は、特定のJava EEサービスに関連づけられていない再使用可能なビジネスおよびデータ・アクセス・オブジェクトを許可することにあります。それらのオブジェクトは、Java EE環境（WebまたはEJB）、スタンドアロン・アプリケーション、およびテスト環境で問題なく再使用できます。

Springの階層型アーキテクチャは、優れた柔軟性を備えています。その機能はすべて、低レベルで構築されています。そのため、たとえば、MVCフレームワークやAOPサポートを使用せずに、JavaBeans構成管理を使用できます。 Web MVCフレームワークやAOPサポートを使用する場合、それらは構成フレームワークで構築されているので、自分の知識をすぐに活かすことができます。

Oracle WebLogic Serverの概要

この項では、プログラミング・モデルではなく、基礎となるインフラストラクチャを中心にOracle WebLogic Serverで提供される機能を簡単に説明します。

Oracle WebLogic Serverは、スケーラブルな企業対応のJava EEアプリケーション・サーバーです。 Oracle WebLogic Serverのインフラストラクチャは、多くの種類の分散アプリケーションの配置をサポートしており、あらゆる種類のアプリケーションの構築に適した基盤です。

Oracle WebLogic Serverには、Sun Microsystemsの Java EE 5仕様が実装されており、さまざまなサービス（データベース、メッセージ・サービス、外部の企業システムへの接続など）にアクセスできるJavaの分散アプリケーションを作成するためのAPIの標準セットを提供します。エンド・ユーザーのクライアントは、Webブラウザ・クライアントまたはJavaクライアントを使用して、これらのアプリケーションにアクセスできます。 Java EEは広く知られているものなので、詳細の説明は省きます。詳細については、プログラミング・モデルにあるOracle WebLogic Serverのドキュメントを参照してください。

Java EEの実装に加え、Oracle WebLogic Serverでは、堅牢で安全、かつ可用性が高くスケーラブルな環境で、ミッション・クリティカルなアプリケーションを配置できます。これらの機能により、企業は、Oracle WebLogic Serverインスタンスのクラスタを設定して、負荷を分散し、ハードウェア障害やほかの障害が発生したときに追加の能力を提供できます。新しい診断ツールを使用することで、システム管理者は、配置済みのアプリケーションおよびOracle WebLogic Serverの環境自体を監視およびチューニングできます。 Oracle WebLogic Serverを設定して、人的介入なしにアプリケーションのスループットを自動的に監視およびチューニングすることもできます。豊富なセキュリティ機能により、サービスへのアクセスを保護し、企業のデータを安全に保持し、悪意のある攻撃を防ぐことができます。

Oracle WebLogic Serverで強化されたサービス品質

そのほかの多くの製品と同様に、Oracle WebLogic Serverには、目立たない多くの機能があります。とくに、Oracle WebLogic Serverには、可用性の高いスケーラブルなアプリケーションの配置をサポートする多数の機能とツールがあります。

Oracle WebLogic Serverのクラスタは、Oracle WebLogic Serverの複数のインスタンス間でワークロードを分散することで、アプリケーションのスケーラビリティおよび信頼性を提供します。着信要求は、処理されている作業量に基づき、クラスタ内のOracle WebLogic Serverインスタンスにルーティングできます。ハードウェア障害やほかの障害が発生した場合には、セッションの状態がほかのクラスタ・ノードで利用できるようになり、障害が発生したノードの作業を再開できます。さらに、障害時にサービスをほかのノードに移行できるオプションが設定されている単一のマシンでサービスがホストされるように、クラスタを実装できます。
1つのクラスタ内のサーバー間でHTTPセッションの状態をレプリケートするのに加え、Oracle WebLogic Serverでは、複数のクラスタ間でHTTPセッションの状態をレプリケートすることもでき、複数の地域、電力供給網、およびインターネット・サービス・プロバイダにおける可用性およびフォルト・トレランスを高めることができます。
Work Managersは、ユーザーが定義するルールに基づき作業に優先順位をつけ、実際のランタイム・パフォーマンスの統計情報を監視します。そのあと、この情報は、アプリケーションのパフォーマンスを最適化するために使用されます。 Work Managersは、Oracle WebLogic Serverのドメインに、または特定のアプリケーション・コンポーネントにグローバルに適用できます。
オーバーロードの保護機能により、Oracle WebLogic Serverは、オーバーロード状態の検出、回避、およびオーバーロード状態からのリカバリをおこなうことができます。
ネットワーク・チャネルは、ネットワーク・トラフィックをトラフィックのタイプに基づきチャネルに分離することで、ネットワーク・リソースの効率的な利用を促進します。
Oracle WebLogic Server永続ストアは、永続性が必要なOracle WebLogic Serverサブシステムおよびサービスのための組込み済みの高性能なストレージ・ソリューションです。たとえば、ストア・アンド・フォーワード機能を使用して送信された永続JMSメッセージまたは一時ストア・メッセージを格納できます。永続ストアは、ファイルベースのストアまたはJDBC対応のデータベースに対する永続性をサポートします。
ストア・アンド・フォーワード・サービスにより、Oracle WebLogic Serverは、Oracle WebLogic Serverインスタンス間に分散されているアプリケーション間で確実にメッセージを配信できます。メッセージの送信時に、ネットワークの問題またはシステム障害によってメッセージの宛先が利用できない場合、そのメッセージはローカル・サーバーのインスタンスに保存され、リモートの宛先が利用可能になったときに一度転送されます。
企業対応の配置ツールは、開発段階から本番環境へのアプリケーション配置および移行を促進します。
本番の再配置機能により、企業は、旧バージョンで進行中の作業を中断することなく、アプリケーションの新バージョンを配置できます。

それでは、この2つのシステム間のシナジーを見てみましょう。

Java EEおよびSpringでのアプリケーション開発

Java EEとSpring間の開発アプローチを比較し、相違点を対比するために、MedRecサンプル・アプリケーションをSpring 2.0.x Frameworkを使用して書き直し、Spring 2.0.xの多くの新しい革新的な機能を利用できるようにしました。次の項では、MedRecの一般的なアーキテクチャについて簡単に説明し、Java EE形式のMedRecと、Spring形式のMedRecについて説明します。

医療記録用アプリケーション

Avitek Medical Records（またはMedRec）は、Oracle WebLogic Serverのサンプル・アプリケーション・スイートであり、Java EEプラットフォームのすべての側面を簡潔に実証します。 MedRecは、あらゆるレベルのJava EE開発者向けの教育用ツールとして設計されています。各Java EEコンポーネントの使用方法を紹介し、コンポーネント・インタラクションおよびクライアント開発のための設計パターンを示します。 MedRecは、Oracle WebLogic Serverでのアプリケーションの開発および配置をおこなうためのベスト・プラクティスも示します。

MedRecの背景にある実社会の概念は、患者、医者、および管理者がさまざまな異なるクライアントを使用して患者データを管理するためのフレームワークです。患者に対して、MedRecはWebベースのアプリケーションを提供し、それぞれの医療記録の履歴を確認して、プロファイルを維持できるようにします。管理者に対して、MedRecはWebベースのアプリケーションを提供し、受信する登録情報の管理、医療記録のアップロード、一般的なアプリケーションの監視ができるようにします。 MedRecには、独立した医療機関とインタフェースをとるためのリソースもあります。この通信をおこなうために、MedRecは、MedRecのシステムにデータを要求したり、データを提供したりする医師のアプリケーションで構成されています。

Java EE形式のMedRecのアーキテクチャの概要

MedRecのJava EEおよびOracle WebLogic Serverバージョンは、クライアント、サーバー、およびデータ・ストアが互いに独立している従来型の三層アーキテクチャ・モデルに基づき設計され、実装されています。

プレゼンテーション層：この層は、すべてのユーザー・インタラクションを管理します。クライアント層と呼ばれることもあります。
サービス層：この層は中間層で、アプリケーションのビジネス・ロジックをカプセル化します。サービス層は、異機種のクライアントからの要求を処理し、データ・ストアをはじめとしたさまざまなバックエンド・システムとインタフェースをとります。この層は、サーバー層と呼ばれることもあります。
Enterprise Information System（EIS）層：この層は、レガシー・アプリケーションやデータベースなどのデータを提供および格納するシステムを表します。 EIS層は、データ・ストアと呼ばれることもあります。

MedRecの患者および管理用のアプリケーションとして、サービスをそれぞれのユーザーに公開するための Webアプリケーション（webapps）を開発しました。 webappsは、Model-View-Controllerパターンにしたがっています。このパターンでは、Java Server Pagesがユーザー向けのViewをレンダリングし、Modelがユーザーに提示またはユーザーから取得したデータをカプセル化し、 Controllerがサービス層とインタフェースをとるのに加え、これらのコンポーネントとのインタラクションを管理するメカニズムとなります。 MedRecは、Jakarta Strutsを採用してこのパターンを実現しています。

サービス層は、クライアントを要求し、バックエンド・アプリケーションおよびリソースとのインタラクションを管理するためのサービスを提供します。 MedRecのサービス層では、ビジネス・ロジックおよびビジネス・データをカプセル化するためにセッション・ファサード・パターンを採用しています。セッション・ファサードは、分散サービスへのインタフェースを提供することで、複雑なアプリケーションを簡素化します。 MedRecでは、セッション・ファサードのおもな役割は、データ・スループットを提供することにあります。 Java EEおよびOracle WebLogic ServerバージョンのMedRecでは、セッション・ファサードは、ステートレス・セッションEnterprise JavaBeansとして開発されており、データはエンティティEnterprise JavaBeansによって管理されます。

外部エンティティとインタフェースをとるために、MedRecはWebサービスを使用してアプリケーションの機能を公開します。これにより、一連のオープン・スタンダードを使用して異なるシステム間での動的なインタラクションが可能になります。 Webサービスを使用してサービスを公開することで、MedRecは、独立したパーティとデータをやり取りでき、医療記録の一元管理という主要な目的を実現できます。

図1は、Java EEおよびOracle WebLogic ServerバージョンのMedRecの高水準なアーキテクチャ図を示しています。

図1：Java EEバージョンのMedRecのアーキテクチャ図

実行中のSpring-再組立て後のMedRec

SpringでOracle WebLogic Serverのエンタープライズ機能の利点を活用できるようにするために、MedRecは再設計され、Java EEのコア・コンポーネントがSpringの該当コンポーネントで置き換えられています。オリジナル・バージョンのMedRecと同じ機能をMedRecのSpringベースのバージョン（MedRec-Spring）でレプリケートしています。

Inversion of Control

SpringのIoCの導入が、MedRec-Springのもっとも顕著な追加点です。 IoCは、コンテナを介して適用される強力な原則で、設定済みのコンポーネントに依存性を注入します。 IoCは、その構成からアプリケーション・コードを切り離します。たとえば、オブジェクトはそれらの依存性とは関係しないので、それぞれの役割に集中できます。 MedRec-Springのケースでは、DataSource、JMSサービス、MBean接続、ピア・サービスなどの企業リソースが、実行時に MedRec-Springのオブジェクトに提供されます。さらに、リソース構成を移行し、コンパイル・コードの外側を参照することで、アプリケーションで、開発に固有のリソースから中間にある本番リソースおよび環境へのシフトがより管理しやすくなります。

IoCを正しく導入するには、アプリケーションのコードは、Javaのプログラミング原理に厳密にしたがう必要があります。とくにインタフェースのコーディングにおいては重要です。インタフェースは依存性が軽減され、実装の変更が分離されるため、よりよいコラボレーションを促進します。 IoCの観点からすると、インタフェースにより依存性の注入のプラガブルな性質が許可されます。 IoCを活用することで、 MedRec-Springは、ビジネス・オブジェクトをインタフェースに対してコーディングができるようにリファクタリングされています。

POJO

MedRec-Springでは、ステートレス・セッションEJBはPlain Old Java Objects（POJO）で置き換えられています。ステートレス・セッションEJBの長所は、そのリモーティング機能とトランザクション管理にあります。 MedRec-Springでは、SpringのHTTP Invokerアーキテクチャを使用してサービスBeanを公開することで、リモーティングの要件を満たしています。トランザクション管理は、Springのトランザクション抽象化レイヤーでおこなわれます。 Springのトランザクション・マネージャは、Oracle WebLogic ServerのJTAトランザクション・マネージャにその役割を委任するように設計されていたため、トランザクション管理は、オリジナルのMedRecの管理を完全にミラー化したものです。

メッセージ

MedRec-Springには、オリジナルのMedRecのメッセージ機能の大部分が含まれています。 SpringのJMSパッケージを採用して、通常のタスクの一部（コネクション・ファクトリや宛先ルックアップなど）を簡素化しています。 Springでは、キューのハンドルをプログラム的に取得する代わりに、メッセージの宛先を表すオブジェクトを提供しています。すべてのSpring Beanと同様、これらのオブジェクトは、JNDI名、コネクション・ファクトリの関連づけなどを表し、コンパイル・コードの外側で設定されています。
Spring 2.0.xのMessage-Driven POJO（MDP）機能を、次の3つの領域でJMSメッセージのターゲットとして使用しています。

メール・メッセージの処理（患者へのメール配信の承認または拒否）
登録メッセージの処理（新規患者の登録プロセス）
医療記録のアップロード処理（XMLファイルからRDBMSへの医療記録のアップロード）

AOP

MedRec-Springでは、Spring AOPを次の2つの主要な目的のために使用しています。

宣言的なトランザクション管理
DAO実装の戻り値の後処理（JPA）

JPA

MedRec-Springでは、患者記録のアクセスおよび書込みにJPAを使用しています。

アプリケーション管理

MedRec-Springには、アプリケーション管理機能が含まれています。これらの機能は、Oracle WebLogic Serverのドメイン構成と、その実行時のドメインで相互に作用します。 MedRec-Springは、Oracle WebLogic ServerのMBeanサーバーで実行する必要があります。Springには、MBeanサーバーのアクセシビリティを簡素化する接続管理機能があります。

Webサービス

MedRec-Springは、Webサービスを使用してそのサービスをエクスポートします。 Springには、Webサービスのプロキシを生成するJAX-RPCファクトリがあります。ほかのSpring Beanと同様、ファクトリBeanは、コンパイル・コードの外部で構成されており、アプリケーションの柔軟性を高めています。

図2は、Springベース・バージョンのMedRecの高水準なアーキテクチャ図を示しています。

図2：Springベース・バージョンのMedRecのアーキテクチャ図

SpringでOracle WebLogic Serverを使用する場合のベスト・プラクティス

Java EEおよびSpring環境におけるMedRecのアーキテクチャの比較をしたので、MedRec-Springの実装時に得たいくつかのヒントについて説明します。

遅延初期化の使用。 IoCコンテナを実装するために、Springは アプリケーション・コンテキストファイルをロードして、各構成済みBeanのインスタンスを作成してキャッシュします。 Spring Beanで参照される各リソースは、インスタンス化またはルックアップで利用できるようにする必要がある点を理解してください。たとえば、SpringのJMXサポートは、Oracle WebLogic ServerのMBeanサーバーへの接続を提供します。すべてのMBeanサーバーが配置の間にアクティブになるわけではないので、リソースを配置する際は、起動時にSpringの遅延初期化およびルックアップ・サービスを使用する必要があります。
機能に基づくSpring構成の分割。この機能により、アプリケーション・コンポーネントでそれぞれの作業の役割に関係するコンテキストだけをロードできます。このプラクティスでは、テスターが、1アプリケーションのコンテキスト（DataSource構成など）をテスト環境に固有のコンテキストで置き換えることで、アプリケーションの動作を変更することもできます。
JndiObjectFactoryBean を介した JDBC DataSource接続プーリングのカプセル化 。データベースの相互作用を要求するBeanは、Oracle WebLogic ServerのDataSourceプーリング機能を利用するためにこのBeanを参照することがあります。
Springの org.springframework.ejb.support をセッションおよびMessage-Driven Enterprise JavaBeansで使用。 Springの org.springframework.ejb.supportには、Enterprise JavaBeans（EJB）で拡張可能な抽象クラスがあります。これらの抽象EJBクラスでは、EJBライフ・サイクル・メソッドの標準的な実装を含めることで開発を支援します。さらに、これらのクラスには、複数のEJBおよびクライアント間でのコンテキストの共有をはじめとした、Springのアプリケーション・コンテキストをロードするためのメカニズムがあり、EJBの初期化中の重複やオーバーヘッドの発生を削減できます。
ホット・デプロイメントおよびOracle WebLogic Serverの分割開発ディレクトリ環境の活用。 これにより、統合テスト中のSpring開発経験が大幅に向上します。ホット・デプロイメントにより、サーバーを再起動せずにアプリケーションを再ロードできます。分割開発ディレクトリ環境では、不必要なファイルのコピーを最小限に抑えることで、迅速な開発および配置が可能になります。分割開発ディレクトリAntタスクにより、配置可能なアーカイブ・ファイルまたは展開アーカイブ・ディレクトリを最初に生成することなく、アプリケーションの再コンパイルおよび再配置を迅速におこなうことができます。
Springライブラリのアプリケーション・ライブラリ、オプションの拡張機能またはサーバー拡張機能としてのパッケージ化 。これにより、複数のSpringアプリケーションでSpring Frameworkを共有して、アプリケーションのフットプリントを小さくできます。これはメモリの使用量を減らすだけではなく、配置時間も短くします。

Spring on Oracle WebLogic Serverキット

Oracle WebLogic Serverに配置されているSpringアプリケーションを最大限に活用するために、Spring 2.0.2、MedRec on Springアプリケーション、多くの機能を含む、オラクル認定のディストリビューションを統合しています。このキットは、オラクルのディストリビューションWebサイトから無料でダウンロードできます。

SpringのWLSコンポーネント用のDIおよびAOPの拡張機能

Java EE仕様に、WebおよびEJBコンテナへの依存性の注入（DI）、およびEJBコンテナへのインターセプタ（AOPの形式）が追加されています。 SpringコンテナはDIおよびAOPにおけるリーダーです。 Oracle WebLogic Server（WLS）は、ピッチフォークを使用してSpringとブリッジを構築し、DIおよびWLS Java EEコンテナへのインターセプタを提供します。統合は標準の仕様要件を満たすだけではなく、Spring FrameworkとしてのJavaEE5仕様に対する拡張の可能性も作り出し、DIおよびAOPの点から見て豊富な機能を提供します。

WLSはこれらの統合機能を利用して、標準のJavaEE5 DIおよびAOPへの拡張機能を提供しています。この拡張機能は、EJBインスタンスへのDIおよびAOP、サーブレット・リスナーとフィルタを含むWebコンポーネントを提供します。サーバー・コンプライアンスを維持するために、標準搭載のWLSのインストールでは、標準のJavaEE5 DIおよびAOPのみを提供しています。

この機能の設定手順については、『 Spring Integration Enhancements』を参照してください。

Enterprise Spring

Spring Frameworkの非侵襲性IoC開発モデルは、Java EEアプリケーション・サーバーで利用可能な機能セットに依存し、それらを補完するように設計されています。実際、要求の厳しい本番環境では、基底にあるアプリケーション・サーバーのインフラストラクチャで提供されているサービス品質が、Springアプリケーションの信頼性、可用性、およびパフォーマンスを継続して提供するためにきわめて重要になります。 Oracle WebLogic Server 10.0には、Springアプリケーションのすべての側面を強化できるエンタープライズ・クラスの機能が用意されています。この項では、それらの機能の詳細の一部、およびそれらの機能をSpringアプリケーションで活用する方法について説明します。

クラスタ管理と開発

Oracle WebLogic Serverのクラスタは、複数のOracle WebLogic Serverのサーバー・インスタンスで構成されており、それらが同時に稼動して互いに連動することで、スケーラビリティと信頼性が向上します。クラスタは、クライアントには単一のOracle WebLogic Serverのインスタンスとして表示されます。 1つのクラスタを構成する複数のサーバー・インスタンスは、同じマシンで実行することも、異なるマシンに配置することもできます。クラスタの能力は、既存のマシンにあるクラスタに追加のサーバー・インスタンスを追加することで高められます。増分のサーバー・インスタンスをホストするために、クラスタにマシンを追加することもできます。 Oracle WebLogic Serverのクラスタには、Springアプリケーション用のエンタープライズ・クラスの配置プラットフォームがあります。そのほかのテクノロジーでも同様の機能がサポートされていますが、Oracle WebLogic Serverより機能が豊富で、使いやすいものはありません。 Oracle WebLogic Serverのクラスタの構成および管理の詳細については、『 Understanding Cluster Configuration and Application Deployment』を参照してください。

一般的にSpringアプリケーションは、webappsとしてパッケージ化されており、このシナリオでは、 Oracle WebLogic Serverのクラスタリングを利用するためにアプリケーションを変更する必要はありません。アプリケーションをクラスタ内のサーバーに配置するだけで、強化されたスケーラビリティと可用性の恩恵を受けることができます。

Springのセッション・レプリケーション

Spring Webアプリケーションは、HTTPセッションにOrder IDやユーザー情報などの情報を常に格納します。クラスタ内のサーブレットやJSPの自動レプリケーションおよびフェイルオーバーをサポートするために、Oracle WebLogic Serverは、HTTPのセッション状態を保存するための複数のメカニズムをサポートしています。これらのメカニズムは、アプリケーションに適切な weblogic.xmlデプロイメント・ディスクリプタを提供することで、Spring Webアプリケーションで非侵襲的に使用できます。詳細については、Oracle WebLogic Server 10.3で提供されている『 configuring the various types of session persistence』を参照してください。

クラスタ化Springのリモーティング

Springは強力なリモーティングのサポートを提供しており、一貫したPOJOベースのプログラミング・モデルを活用しながら、リモート・サービスを簡単にエクスポートおよび使用できます。 Vanilla Springは、単一のRMIインタフェースから該当するSpring BeanへのPOJOコールのプロキシ化をサポートしています。ただし、このサポートは、JRMP（SunのRMI実装）または JndiRmiProxyFactoryBeanで特定のリモート・インタフェースを使用する場合に限定されています。 Oracle WebLogic Server 10.0におけるSpring 1.2.5の認証を使用して、 JndiRmiProxyFactoryBeanおよび関連するサービス・エクスポーターを拡張し、RMI-IIOPおよびT3を含む、すべてのJava EE RMI実装でPOJOのプロキシ化をサポートできるようにしました。このサポートには、プロキシRMIインタフェースでのクラスタ化を可能にするWebLogic RMIデプロイメント・ディスクリプタが含まれており、POJOコールをOracle WebLogic Serverのクラスタ間でロード・バランス化できます。このようなサポートをおこなうためのクライアント構成は、次のようになります。

applicationContext.xml

<bean id="proProxy"                             



  class="org.springframework.remoting.rmi.JndiRmiProxyFactoryBean">                             



   <property name="jndiName" value="t3://${serverName}:${rmiPort}/order"/>                             



   </property>                             



   <property name="jndiEnvironment">                             



      <props>                             



         <prop key="java.naming.factory.url.pkgs">                             



                   weblogic.jndi.factories                             



         </prop>                             



      </props>                             



   </property>                             



   <property name="serviceInterface"                             



        value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>                             



</bean>

サービス・エクスポーターは、次のようになります。

applicationContext.xml

<bean id="order-pro"   class="org.springframework.remoting.rmi.JndiRmiServiceExporter">                             



   <property name="service" ref="petStore"/>                             



   <property name="serviceInterface"                             



     value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>                             



   <property name="jndiName" value="order"/>                             



</bean>

クラスタ化ディスクリプタは、自動的に含まれます。ユーザーに求められるのは、適切なクラスタ構成、およびすべてのクラスタ・メンバーへのSpringアプリケーションの配置作業だけです。詳細については、『 failover support』を参照してください。

Springコンポーネントのコンソール・サポート

新しいSpringコンソールの拡張機能が、Oracle WebLogic Server 10.3のリリースで実装されています。このコンソールの拡張機能は、WLSインフラストラクチャを使用して登録されたRuntimeMBeansに基づいています。そのため、Springアプリケーションのクラスタ・ビュー、およびSpring Beanのさらなる管理機能を提供しています。また、WebまたはEJBアプリケーションと同等のSpringタブを作成し、WebLogic Console上のSpring Beanの構成情報をユーザーが確認できるようにします。

Springコンソールの拡張機能を有効にするためには、『 Spring Integration Enhancements』の手順にしたがい、weblogic-spring.jarをJavaEEのオプション・パッケージとして配置する必要があります。次に、アプリケーションのランタイムMBeanを生成するために、weblogic-spring.jarの WeblogicSpringApplicationListenerを、ルートSpringコンテキストにリスナーとして追加する必要があります。これは、次の2つの方法でおこなうことができます。最初の方法を推奨します。

web.xmlを編集して、Springコンテキスト・ローダー・リスナーをWebLogicのものに変更します。

web.xml

<listener-class>weblogic.spring.monitoring.WeblogicContextLoaderListener</listener-class>

WeblogicContextLoaderListenerは、Spring ContextLoaderListenerを拡張し、WeblogicSpringApplicationListenerを ApplicationListenerとして追加し、BeanFactoryPostProcessorをWebアプリケーション・コンテキストに追加します。

カスタマイズ済みのContextLoaderListenerがすでにある場合は、WebLogicのものは使用できません。代わりに、WeblogicSpringApplicationListenerをルートApplicationContextに対する Beanとして追加できます。 WebアプリケーションのSpring XML構成ファイルに、WeblogicSpringApplicationListenerを次のように追加します。

applicationContext.xml

<bean class="weblogic.spring.monitoring.WeblogicSpringApplicationListener"/>

Webサービスの有効化

Springのリモーティング機能のもう1つのファセットは、RPCスタイルのWebサービスのサポートです。 Oracle WebLogic Serverには、WebサービスのWSDL記述に基づくJAX-RPCスタブを生成するためのAntベースのツールがあります。 Webサービス・クライアントは、これらの生成されたスタブを使用して、サーバー側の操作を表すリモート・インタフェースを取得します。 Springでは、 JaxRpcPortProxyFactoryBeanを提供することで、このプロシージャを簡素化しています。

Oracle WebLogic Server環境で JaxRpcPortProxyFactoryBeanを正しく設定するには、少し工夫が必要です。そのため、時間の節約に役立つように、このスニペットでは、複雑なタイプを含むラップされたドキュメント・リテラルのWebサービスのプロキシ生成を設定する方法について説明します。

大部分の属性については、説明は不要でしょう。以下のいくつかの属性について説明します。

· serviceInterfaceは、Springのセッター注入の副生成物です。このクラスは、Webサービスの処理を表します。
· customPropertiesプロパティを指定すると、カスタムの Oracle WebLogic ServerのWebサービスのスタブ・プロパティを使用できます。
· jaxRpcService値は、Oracle WebLogic Serverの生成済みのJAX-RPC実装サービスに設定されます。 JAX-RPCサービスは、Webサービスの認証、および複雑なタイプ・マッピングのロードをおこないます。タイプ・マッピングのロードを可能にするためには、Oracle WebLogic ServerのJAX-RPCサービス実装は、Spring Beanとして設定する必要があります。これにより、タイプ・マッピング・ファイルがロードされるJAX-RPCサービス・コンストラクタの実行が可能になります。

JaxRpcPortProxyFactoryBeanで lookupServiceOnStartupを falseに設定すると、起動中にJAX-RPCサービスのルックアップが無効になります。代わりに、ルックアップは最初のアクセス時にフェッチされます。これは、Oracle WebLogic Serverの信頼性の高いリクエストとレスポンスWebサービスと通信するクライアントで必要になります。この場合、クライアントもWebサービスである必要があります。このようなケースでは多くの場合、送信元のクライアントは、Webサービス・クライアントとともに配置されます。 Webサービスのアクティブ化は、アプリケーションの配置が終了するまでおこなわれないので、Springコンテキストのロード時にクライアントWeb サービスを利用することはできません。

applicationContext-ws.xml

<!-- reliable asynchronous Web service for sending new medical records to MedRec -->                             



<bean id="reliableClientWebServicesPortType"                             



  class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean"                             



  lazy-init="true">                             



   <property name="wsdlDocumentUrl"                             



     value="http://${WS_HOST}:${WS_PORT}/ws_phys/PhysicianWebServices?WSDL"/>                             



   <property name="portName" value="PhysicianWebServicesPort"/>                             



   <property name="jaxRpcService">                             



      <ref bean="generatedReliableService"/>                             



   </property>                             



   <property name="serviceInterface"                             



     value="com.bea.physician.webservices.client.PhysicianWebServicesPortType"/>                             



   <property name="username" value="medrec_webservice_user"/>                             



   <property name="password" value="WebLogic"/>                             



   <property name="customProperties">                             



      <props>                             



         <prop key="weblogic.wsee.complex">true</prop>                             



      </props>                             



   </property>                             



</bean>                             





<!-- allows the jaxRpcService class to execute its constructor which loads in type mappings -->                             



<bean id="generatedReliableService"                             



  class="com.bea.physician.webservices.client.PhysicianWebServices_Impl">                             



</bean>

詳細については、Oracle WebLogic Serverの『 Overview of Invoking Web Services』および『 Remoting and Web Services Using Spring』を参照してください。

セキュリティ

Oracle WebLogic Serverのセキュリティ・システムは、Java EEのセキュリティ機能をサポートおよび拡張すると同時に、さまざまなセキュリティ・データベースまたはセキュリティ・ポリシーを扱うためにカスタマイズできる豊富なセキュリティ・プロバイダを提供します。標準のJava EEセキュリティを使用するのに加え、アプリケーション・プログラマは、アプリケーションとセキュリティ・システムを緊密に統合できる豊富な独自仕様の拡張機能を使用できます。 Oracle WebLogic Serverには、複数のセキュリティ・プロバイダが組み込まれており、よく知られているLDAPサーバー、Active Directory、ネイティブWindows、および組込み認証ソリューションをはじめとした認証データベースを選択できます。組込みプロバイダは、カスタム・プロバイダで補強して、ほぼすべての認証データベース、認可メカニズム、および資格証明マッピング・サービスと統合できます。 Springアプリケーションは、Java EEのセキュリティを活用するwebappsとして配置されているので、アプリケーションを変更することなくOracle WebLogic Serverのセキュリティの恩恵を受けられます。

Spring Security（acegi）は、Springアプリケーションにセキュリティを提供すると同時に、豊富なセキュリティ・プロバイダを提供します。

JavaEEおよびSpringのコンポーネントを使用するアプリケーションの場合、両方のセキュリティ・フレームワークでの認証の代わりに、WLSとSpring Securityを連動させることを求められます。 WLSセキュリティは、認証をおこない、WLSプリンシパルをマッパー・クラス経由でSpring GrantedAuthorityに変換します。 WLSセキュリティで認証されると、ユーザーは、Spring Securityに対して認証されます。そのあと、アプリケーション内のオブジェクトを保護する方法を決定できます。一般的な方法の1つとして、Java EEのリソースをWebLogicセキュリティで保護し、SpringのリソースをSpring Securityで保護する方法があります。この機能の設定手順については、『 Spring Integration Enhancements』を参照してください。

分散トランザクション

Springには、トランザクション管理のためのインフラストラクチャがあります。 Springは、さまざまなデーベース・ベンダーをサポートするとともに、Java EEベンダーのJTA実装を介して分散トランザクションもサポートします。 SpringのJTAマネージャは、 WebLogicJtaTransactionManagerを介してOracle WebLogic ServerのJTA実装とともに機能するように設定できます。

WebLogicJtaTransactionManagerは、その役割を Oracle WebLogic ServerのJavaトランザクションAPIに直接委任します。 Oracle WebLogic ServerのJTA TransactionManagerインタフェースは、JNDIを介してクライアントおよびBeanプロバイダで利用可能になります。Springはこのインタラクションを管理します。トランザクション・マネージャは、トランザクションの範囲も有効にします。トランザクションは、クラスタとドメイン内およびそれらの間で処理できます。

WebLogicJtaTransactionManagerのもっとも強力な機能は、分散トランザクションの管理機能、およびエンタープライズ・アプリケーションのための2フェーズのコミット・プロトコルです。 WebLogicJtaTransactionManagerを採用することで、アプリケーションでWebLogic Administration Consoleを使用してトランザクションを監視できます。 WebLogicJtaTransactionManagerは、複雑なトランザクション構成を可能にする、データベースごとの分離レベルも許可します。

applicationContext-service.xml

<bean id="serviceFacade" class="com.bea.medrec.web.service.ServiceFacadeImpl">                             



    <!-- .... -->                             



</bean>                             





<!-- spring's transaction manager delegates to WebLogic Server's transaction manager -->                             



<bean id="transactionManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">                             



    <property name="transactionManagerName" value="javax.transaction.TransactionManager"/>                             



</bean>                             





<aop:config>                             



    <aop:advisor advice-ref="txAdvice"                             



                 pointcut="execution(* com.bea.medrec.web.service.ServiceFacade.*(..))"/>                             



</aop:config>                             



<tx:advice id="txAdvice" transaction-manager="transactionManager">                             



    <tx:attributes>                             





        <tx:method name="activate*" propagation="REQUIRED"/>                             



        <tx:method name="deny*" propagation="REQUIRED"/>                             



        <tx:method name="update*" propagation="REQUIRED"/>                             





        <tx:method name="process*" propagation="REQUIRED"/>                             



        <tx:method name="get*" propagation="REQUIRED" read-only="true"/>                             





        <tx:method name="search*" propagation="REQUIRED" read-only="true"/>                             



        <tx:method name="saveRecord" propagation="REQUIRED" read-only="true"/>                             





        <!-- ... -->                             



    </tx:attributes>                             



</tx:advice>

詳細については、『 Overview of Transactions in WebLogic Server Applications』および『 Implementing Transaction Suspension in Spring』を参照してください。

Message-Driven POJO

Message-Driven POJO（MDP）は、Java EEのMessage-Driven Beans（MDB）に代わるものです。これらにはPOJOと同様、プラットフォームに固有のAPI拡張機能や足場を必要としないという利点があります。標準のJMS APIを実装するだけで使用できます。

RegistrationMessageListener.java

public class RegistrationMessageListener implements MessageListener {                             



    public void onMessage(Message message) {                             



        // Fetch Registration information from ObjectMessage.                             





        //                               Process new reg by invoking service (DI)                               



        // ...                               

    }                               



}

MDPコンテナの設定も、Springのほとんどの機能と同様にシンプルです。

applicationContext-jms.xml

<!-- JMS ConnectionFactory and Queue -->                             





<jndi:jndi-lookup id="jmsConnectionFactory" jndi-name="com.bea.medrec.messaging.MedRecQueueConnectionFactory"/>                             



<jndi:jndi-lookup id="registrationQueue" jndi-name="com.bea.medrec.messaging.RegistrationQueue"/>                             





<!-- MDP -->                             





<bean id="registrationMessageListener" class="com.bea.medrec.service.messaging.RegistrationMessageListener">                             



    <!-- ... properties... -->                             



</bean>                             





<!-- MDP container -->                             



<bean id="registrationMessageListenerContainer"                             





          class="org.springframework.jms.listener.DefaultMessageListenerContainer">                             



    <property name="connectionFactory" ref="jmsConnectionFactory"/>                             



    <property name="concurrentConsumers" value="5"/>                             





    <property name="destination" ref="registrationQueue"/>                             



    <property name="messageListener" ref="registrationMessageListener"/>                             



    <property name="transactionManager" ref="transactionManager"/>                             





</bean>

Oracle WebLogic ServerでのMDPの実装の詳細については、ここを参照してください。

JPAおよびAOPの構成

RMI、Spring HTTP Invoker、Hessian/Burlap、およびJAXPRC間でWebサービスの実装を簡単に切り換えられるようにするために、Webサービス層を定義しています。リモート・サービスを起動するときに、シリアライズ可能なメカニズムを使用してオブジェクトを転送する場合、オブジェクト自体もシリアライズ可能である必要があります。 OpenJPAの検索結果は、プライベートのList実装であり、Serializableはサポートしていません。そのため、これらのListを Java EEコレクション・ライブラリのArrayListやLinkedListなどのより適したものでラップする必要があります。このような作業は、Spring AOPを使用することで、アプリケーションのソース・コードを変更せずにおこなえます。

ReturningValuePostProcessorAspect.java

@Aspect                             



public class ReturningValuePostProcessorAspect {                             



    @Pointcut("execution(java.util.List com.bea.medrec.dao.PatientDao.*(..))")                             



    public void postProcessPatientDao() {                             



    }                             





    @Pointcut("execution(java.util.List com.bea.medrec.dao.RecordDao.*(..))")                             



    public void postProcessRecordDao() {                             



    }                             





    @Pointcut("execution(java.util.List com.bea.medrec.dao.UserDao.*(..))")                             



    public void postProcessUserDao() {                             



    }                             



}

ReturningValuePostProcessor.java

@Aspect                             



public class ReturningValuePostProcessor {                             



    public ReturningValuePostProcessor() {                             



    }                             





    @Around("com.bea.medrec.dao.jpa.ReturningValuePostProcessorAspect.postProcessPatientDao()")                             



    public Object postProcessPatientDao(ProceedingJoinPoint pjp) throws Throwable {                             



        return doPostProcess(pjp);                             



    }                             





    @Around("com.bea.medrec.dao.jpa.ReturningValuePostProcessorAspect.postProcessRecordDao()")                             



    public                               Object postProcessRecordDao(ProceedingJoinPoint pjp) throws Throwable {                               



        return doPostProcess(pjp);                               



    }                               





    @Around("com.bea.medrec.dao.jpa.ReturningValuePostProcessorAspect.postProcessUserDao()")                               



    public Object postProcessUserDao(ProceedingJoinPoint pjp) throws Throwable {                               



        return doPostProcess(pjp);                               



    }                               





    private                                 Object doPostProcess(ProceedingJoinPoint pjp) throws Throwable {                                 



        Object retVal = pjp.proceed();                                 

        if (retVal == null) {                                 



            return null;                                 



        }                                 



        if (!(retVal instanceof List)) {                                 



            return retVal;                                 



        } else {                                 



            //noinspection unchecked                                 





            return new ArrayList((List) retVal);                                 



        }                                 



    }                                 



}

applicationContext-jpa.xml

<bean id="patientDao" class="com.bea.medrec.dao.jpa.PatientDaoImpl"/>                             



<bean id="recordDao" class="com.bea.medrec.dao.jpa.RecordDaoImpl"/>                             



<!-- ... -->                             



<bean id="returningValuePostProcessor" class="com.bea.medrec.dao.jpa.ReturningValuePostProcessor"/>                             



<aop:aspectj-autoproxy/>

Java Management Extension

Java Management Extension（JMX）は、Javaアプリケーションを監視および管理するための仕様です。 JMXは、汎用的な管理システムによるアプリケーションの監視、アプリケーションを監視する必要が生じたときの通知の表示、および問題を解決するためのアプリケーション状態の変更を可能にします。 Springは、Oracle WebLogic ServerのMBeanServerをSpringの MBeanServerConnectionFactoryBeanを介して公開する機能をはじめとした広範なJMXサポートを提供しています。 MBeanServerConnectionFactoryBeanは、 Convenience Factoryで、この副生成物は、 MBeanServerConnectionです。アプリケーションの配置中に接続が確立され、参照するBeanによって、あとで処理されるようにキャッシュされます。

MBeanServerConnectionFactoryBeanは、 Oracle WebLogic ServerのRuntime MBean Serverを返すように設定できます。このサーバーは、特定のOracle WebLogic Serverのインスタンスの監視、ランタイム制御、およびアクティブな構成を公開します。これには、Oracle WebLogic ServerのDiagnostics Frameworkへのアクセスが含まれます。さらに、Runtime MBeanは、現在のサーバーのランタイムMBeanおよびアクティブな構成のMBeanへのアクセスを提供します。

>MBeanServerConnectionFactoryBeanは、 Oracle WebLogic ServerのDomain Runtime MBean Serverへの接続を取得するように設定することもできます。 Domain Runtime MBean Serverは、アプリケーションの配置、JMSサーバー、およびJDBCデータ・ソースなどのドメイン全体のサービスに対する許可をおこないます。このサーバーは、ドメイン内のすべてのサーバーに対する、すべてのランタイムMBeanおよびすべてのアクティブな構成のMBeanの階層にアクセスするためのシングル・ポイントでもあります。このMBean Serverは、管理対象サーバーに常駐しているMBeanにアクセスするためのシングル・ポイントとしても機能します。

さらに、 MBeanServerConnectionFactoryBeanは、 Oracle WebLogic ServerのEdit MBean Serverへの接続を取得するように設定できます。 Edit MBean Serverは、現在のOracle WebLogic Serverのドメイン構成を管理するためのエントリ・ポイントを提供します。

Oracle WebLogic ServerのDomain Runtime MBean Serverは、配置中はアクティブではありません。このため、Beanは、起動時にBeanをフェッチするSpringの遅延初期化を使用して設定する必要があります。

Springの MBeanServerConnectionFactoryBeanと WebLogicのMBean Serverの設定例を示します。

applicationContext.xml

<!-- expose WebLogic Server's runtime mbeanserver connection -->                             



<bean id="runtimeMbeanServerConnection"                             



  class="org.springframework.jmx.support.MBeanServerConnectionFactoryBean">                             



   <property name="serviceUrl"      value="service:jmx:t3://${WS_HOST}:${WS_PORT}/jndi/weblogic.management.mbeanservers.runtime"/>                             



   <property name="environment">                             



      <props>                             



         <prop key="java.naming.security.principal">                             



            ${WS_USERNAME}</prop>                             



         <prop key="java.naming.security.credentials">                             



            ${WS_PASSWORD}</prop>                             



         <prop key="jmx.remote.protocol.provider.pkgs">                             



            weblogic.management.remote</prop>                             



      </props>                             



   </property>                             



</bean>

詳細については、『 Understanding WebLogic Server MBeans』およびSpringの『 JMX Support』を参照してください。

サポート

Oracle WebLogic Server 9.0およびSpring 1.2.5以降、オラクルではOracle WebLogic ServerでのSpring Frameworkのサポートおよび認証を提供しています。このサポートは、Oracle WebLogic ServerでのSpringライブラリの単なる妥当性テストだけではなく、オラクルとSpring Frameworkの開発および保守をおこなっているInterface 21との真剣な努力とコラボレーションを伴うものです。上述のすべての機能と構成をSpring 2.0.2でテストしただけではなく、オラクルとSpringSourceのコラボレーションの結果として、いくつかの新機能をSpring 2.0.2に直接導入しています。

ダウンロード

Spring Open Source Framework Support 2.0.2のダウンロードには、Oracle WebLogic Server 10.0で認定済みのSpring 2.0.2、Spring-JMXのコンソール拡張機能、Spring 2.0.x Frameworkを使用して書き直したWebLogic Medical Recordsのサンプル・アプリケーションが含まれています。

今後の作業

今後は、Oracle WebLogic ServerとSpring Frameworkのさらなる統合をおこなう予定でいます。アイデアはいくつかありますが、もっとも興味深いものについて説明します。

· Springの配置ユニット：Springアプリケーションは、通常 webappsとして配置されますが、Springアプリケーションの専用配置ユニットを提供することも可能になります。

· Spring SecurityとOracle WebLogic Serverのセキュリティの統合：Spring Securityは、Springのセキュリティ・フレームワークです。オラクルでは、この機能とOracle WebLogic Serverのエンタープライズ・クラスのセキュリティ・フレームワークの統合を計画しています。

まとめ

この記事では、Spring、Oracle WebLogic Server、および2つのテクノロジーの統合について説明しました。ご覧いただいたように、Springは開発者の生産性を高め、Oracle WebLogic Serverはアプリケーションのサービス品質を高めます。いずれのテクノロジーもきわめて非侵襲的であるため、テクノロジー固有のAPIの複雑さに悩むことなく、アプリケーションのビジネス機能の開発に集中できます。

参考資料

Spring on WebLogicキットのダウンロード
Oracle WebLogic Server 10.3の製品ドキュメント
Oracle WebLogic Server Product Center
Supported Configurations for Products with Spring Framework
The Spring Framework
Implementing Transaction Suspension in Spring、Juergen Hoeller著（2005年7月）
Better J2EEing with Spring、Peter Braswell著（2005年7月）

E-mail this page

Oracleアカウント

Oracleアカウント

クラウド・アカウント

Spring 2.5.xとOracle WebLogic Server 10.3の統合

概要

記事の構造

Spring Frameworkの概要

強化されたSpring Frameworkでの開発経験

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

Oracle WebLogic Serverの概要

Oracle WebLogic Serverで強化されたサービス品質

Java EEおよびSpringでのアプリケーション開発

医療記録用アプリケーション

Java EE形式のMedRecのアーキテクチャの概要

実行中のSpring-再組立て後のMedRec

Inversion of Control

POJO

メッセージ

AOP

JPA

アプリケーション管理

Webサービス

SpringでOracle WebLogic Serverを使用する場合のベスト・プラクティス

Spring on Oracle WebLogic Serverキット

SpringのWLSコンポーネント用のDIおよびAOPの拡張機能

Enterprise Spring

クラスタ管理と開発

Springのセッション・レプリケーション

クラスタ化Springのリモーティング

Springコンポーネントのコンソール・サポート

Webサービスの有効化

セキュリティ

Spring Security（acegi）は、Springアプリケーションにセキュリティを提供すると同時に、豊富なセキュリティ・プロバイダを提供します。

分散トランザクション

Message-Driven POJO

JPAおよびAOPの構成

Java Management Extension

サポート

ダウンロード

今後の作業

まとめ

参考資料

お問い合わせ

日本オラクルについて

クラウド

イベント

おすすめコンテンツ

ニュース

主要トピック

Integrated Cloud Applications & Platform Services