Spring 2.0.1とBEA WebLogic Server 9.2の統合
Pages: 1, 2, 3, 4

それでは、これら2つのシステムの相乗効果を見てみましょう。

Java EEとSpringでのアプリケーション開発

Java EEとSpringの開発アプローチの違いを比較し対比するため、MedRecサンプルアプリケーションを取り上げ、Spring Framework 2.0を用いてそれを作成し直しました。このとき、Spring 2.0の多くの画期的な新機能を利用しました。次のセクションでは、MedRecの全体的アーキテクチャの概要を手短に述べた後、そのJava EE版の実装とSpring版の実装を順に見ていきます。

MedRec（医療記録管理）アプリケーション

Avitek MedRec（医療記録管理）アプリケーションは、Java EEプラットフォームのすべての側面を簡潔に紹介するWebLogic Serverサンプルアプリケーションスイートです。MedRecは、あらゆるレベルのJava EE開発者を対象とした教育ツールとして作成されたものです。各Java EEコンポーネントの使用方法を紹介し、コンポーネント間のやり取りとクライアント開発に利用できるデザインパターンを示します。MedRecはまた、WebLogic Serverでアプリケーションを開発およびデプロイする場合のベストプラクティスも示します。

MedRecの背後には、患者、医師、および管理者がさまざまなクライアントを使用して患者データを管理するためのフレームワークというコンセプトがあります。MedRecは、患者にとっては、医療記録の閲覧やプロファイルの維持管理を行うためのWebベースアプリケーションとなります。一方、管理者にとっては、入力される患者登録、医療記録のアップロード、アプリケーション監視全般を管理するためのWebベースアプリケーションとなります。MedRecにはまた、独立した医療機関と連携するためのリソースも用意されています。このコミュニケーションを実演するために、MedRecには、MedRecシステムにリクエストを出したりデータを提供する医師用アプリケーションが含まれています。

Java EE版MedRec - アーキテクチャの概要

Java EEおよびWebLogic Server版のMedRecは、クライアント、サーバ、およびデータストアが互いに独立した従来の3層アーキテクチャモデルにしたがって、以下のように設計および実装されています。

• プレゼンテーション層：この層はユーザとのあらゆるやり取りを担当し、時に「クライアント層」とも呼ばれます。
• サービス層：この層は、アプリケーションのビジネスロジックをカプセル化する中間層です。サービス層では、データストアをはじめとするさまざまなバックエンドシステムとインタフェースを取りながら、異種クライアントからのリクエストを処理します。この層は時に「サーバ層」とも呼ばれます。
• EIS（エンタープライズ情報システム）層：この層は、レガシーアプリケーションやデータベースなどの、データの提供や格納を行うシステムを表します。EIS層は時に「データストア」とも呼ばれます。

MedRecの患者用アプリケーションと管理者用アプリケーションのために、それぞれのユーザにサービスを公開するWebアプリケーション（webapps）を開発しました。webappsはModel-View-Controllerパターンにしたがっています。すなわち、JSP（Java Server Pages）でユーザへのビュー（View）を表示し、モデル（Model）でユーザとの間でやり取りされるデータをカプセル化し、そしてコントローラ（Controller）は、サービス層とのインタフェースのほかに、これらのコンポーネントのやり取りも管理するメカニズムになります。MedRecでは、Jakarta Strutsを用いて、このパターンを実現しています。

サービス層では、リクエストを発行するクライアントにサービスを提供すると共に、バックエンドのアプリケーションやリソースとのやり取りを管理します。MedRecのサービス層では、Session Facadeパターンを用いて、ビジネスロジックとビジネスデータをカプセル化しています。Session Facadeは、分散するサービスへのインタフェースを一本化することで、アプリケーションの複雑さを軽減します。MedRecでは、Session Facadeの主な責務はデータスループットを提供することです。Java EEおよびWebLogic Server版のMedRecでは、Session FacadeはステートレスセッションEJB（Enterprise JavaBeans）として作成され、データはエンティティEJBで管理されます。

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

図1は、Java EEおよびWebLogic Server版MedRecのアーキテクチャ概要図です。

図1：Java EE版MedRecのアーキテクチャ図

Springを用いたMedRecの再構築

SpringでWebLogic Serverのエンタープライズ機能を活用できることを確かめるために、MedRecを設計し直して、Java EEのコアコンポーネントをそれに対応する Springコンポーネントに置き換えました。Spring版のMedRec（MedRec-Spring）には、MedRecの元のバージョンと同じ機能を実装しました。

IoC

SpringのIoCを導入したことは、MedRec-Springに加わった特徴の中でも最も顕著なことです。IoCは、構成対象のコンポーネントに依存性を注入するコンテナを通じて適用される強力な原則です。IoCによって、アプリケーションのコードとアプリケーションのコンフィグレーションが切り離されます。例えば、オブジェクトは依存性には関わらないため、該当の担当タスクに集中することができます。MedRec- Springの場合には、データソース、JMSサービス、MBean接続、ピアサービスなどのエンタープライズリソースは、実行時にMedRec- Springのオブジェクトに提供されます。さらに、リソースのコンフィグレーションと参照をコンパイル対象コード以外の場所に移すことで、アプリケーションは開発固有のリソースから運用時のリソースおよび中間の環境への移行により対処しやすくなります。

IoCを適切に利用するには、アプリケーションのコードがより厳格なJavaプログラミング原則（特に、インタフェースに準拠したコーディング）に従う必要があることがわかりました。とりわけインタフェースでは、依存性が軽減され実装の変更が切り離されるため、より良いコラボレーションが促進されます。IoCの観点では、インタフェースによって、依存性注入のプラグイン可能という性質が可能になります。IoCを活用するために、MedRec- Springをリファクタリングして、ビジネスオブジェクトをインタフェースに照らし合わせてコーディングするようにしました。

POJO

MedRec-Springでは、ステートレスセッションEJBはPOJO（Plain Old Java Object）に置き換えられました。ステートレスセッションEJBの強みは、そのリモーティング機能とトランザクション管理です。MedRec- Springでは、SpringのHTTP Invokerアーキテクチャを通じてサービスBeanを公開することで、このリモーティング要件を満たすことができました。トランザクション管理機能はSpringのトランザクション抽象化レイヤで提供されます。Springのトランザクションマネージャは自らの責務をWebLogic ServerのJTAトランザクションマネージャに委託するように構成されているため、MedRec-Springのトランザクション管理は元のMedRecのトランザクション管理とそっくり同じものになっています。

メッセージング

MedRec-Springには、元のMedRecにあるメッセージング機能の大半が備わっています。今回の実装では、SpringのJMSパッケージを利用して、接続ファクトリや宛先ルックアップなどの一部のルーチンワークを簡略化しました。Springでは、プログラム的にキューのハンドルを取得するのではなく、メッセージングの宛先を表すオブジェクトが提供されます。SpringのすべてのBeanと同様に、これらのオブジェクト表現（JNDI名、接続ファクトリ関連など）はコンパイルされたコードの外部で構成されます。私たちは、次の3つの領域で、JMSメッセージのターゲットとしてもSpring 2.0のメッセージ駆動型POJO（MDP）機能を使用しました。

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

AOP

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

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

JPA

MedRec-Springでは、患者記録のアクセスと記述にJPAを使用しています。詳細については、「 Spring 2.0でのJPA（Java Persistence API）の利用」を参照してください。

アプリケーション管理

MedRec-Springには、アプリケーション管理機能が備わっています。これらの機能は、WebLogic Serverのドメインコンフィグレーションのほか、実行時ドメインともやり取りします。MedRec-SpringはWebLogic ServerのMBeanサーバにしたがって動作する必要があり、SpringではMBeanサーバへのアクセスを簡単にする接続管理機能を提供します。

Webサービス

最後に、MedRec-Springでは、Webサービスを使って自らのサービスをエクスポートします。Springでは、Webサービスのプロキシを生成するJAX-RPCファクトリを提供します。他のSpring Beanと同様に、このファクトリBeanもコンパイルされたコードの外部で構成されるため、アプリケーションの柔軟性が高まります。

図2は、Spring版MedRecのアーキテクチャ概要図です。

図2：Spring版MedRecのアーキテクチャ図

WebLogic ServerでのSpring利用のベストプラクティス

前のセクションでは、Java EE環境とSpring環境の双方で実装したMedRecのアーキテクチャを比較しました。ここでは、MedRec-Springアプリケーションを実装する過程で得られた有益な知見（ベストプラクティス）をいくつか以下に紹介します。

• 遅延初期化を用いる：IoCコンテナを実装するために、Springではアプリケーションコンテキストファイルを読み込み、構成された各Beanのインスタンスを生成してキャッシュします。Spring Beanで参照される各リソースはインスタンス化やルックアップの際に利用できるようになっていなければならないことを理解しておくことが大切です。例えば、SpringのJMXサポート機能では、WebLogic ServerのMBeanサーバに対する接続を提供します。デプロイ時にMBeanサーバがすべてアクティブになっているとは限らないので、ユーザは、リソースをデプロイする際には、Springの遅延初期化を用い、起動時にサービスをルックアップしなければなりません。
• Spring のコンフィグレーションを機能に基づいて分離する：これにより、アプリケーションコンポーネントは自らの担当タスクに関係のあるコンテキストだけを読み込むことができるようになります。また、このプラクティスに従うことで、テスト担当者は、アプリケーションコンテキスト（例えば、データソースのコンフィグレーションなど）をテスト環境に固有のコンテキストに置き換えることにより、アプリケーションの動作を変更することもできます。
• JndiObjectFactoryBeanによってJDBCデータソース接続プーリングをカプセル化する：これにより、データベースとのやり取りが必要なBeanは、WebLogic Serverのデータソースプーリング機能を利用する際にこのBeanを参照することができます。
• セッション EJB とメッセージ駆動型 EJB に Spring の org.springframework.ejb.support を使用する：Springのorg.springframework.ejb.supportには、EJB（Enterprise JavaBeans）が拡張できる抽象クラスが用意されています。これらの抽象EJBクラスには、EJBのライフサイクルメソッドの標準実装が含まれているため、開発の助けとなります。さらに重要なことには、これらのクラスは、複数のEJBやクライアント間でコンテキストを共有することでEJB初期化の重複やオーバーヘッドを減らすなど、Springのアプリケーションコンテキストを読み込むためのメカニズムを提供してくれます。
• ホットデプロイとWebLogic Serverの分割開発ディレクトリ環境を利用する：これにより、統合テスト時のSpringによる開発作業の効率は大幅に向上します。ホットデプロイを利用すれば、サーバを再起動せずにアプリケーションを再読み込みすることができます。分割開発ディレクトリ環境では、不要なファイルコピーが最小限に抑えられるので、開発とデプロイメントを促進することができます。分割開発ディレクトリのAntタスクを利用すれば、デプロイ可能なアーカイブファイルや展開アーカイブディレクトリを先に生成せずにアプリケーションの再コンパイルや再デプロイを迅速に行えるようになります。
• Springライブラリをアプリケーションライブラリ、オプションの拡張機能、あるいはサーバ拡張機能としてパッケージ化する：これにより、複数のSpringアプリケーションでSpring Frameworkを共有でき、アプリケーションのフットプリントを減らすことができます。この結果、メモリ使用量が少なくなるだけでなく、デプロイメント時間も改善されます。

WebLogic Server版Springキット

私たちは、WebLogic ServerにデプロイしたSpringアプリケーションを最大限に活用していただくために、Spring 2.0やSpring版MedRecアプリケーションをはじめ、役に立つものが多数収められたBEA認定の配布キットを作成しました。このキットは、BEAの配布用Webサイトから無料でダウンロードできます。

 

Pages: 1, 2, 3, 4

Next Page »