ヘッダーをスキップ
Oracle TopLink開発者ガイド
10gリリース3(10.1.3)
B28605-01
  目次
目次
索引
索引

戻る
戻る
次へ
次へ
 

3層アーキテクチャの概要

3層Webアプリケーション・アーキテクチャには、通常、JDBC接続を介したデータベースへのサーバー・サイドJavaアプリケーションの接続が含まれます(図2-3を参照)。このパターンでは、TopLinkは、いくつかのサーバー統合ポイントを所有できるJavaサーバー(J2EEサーバーまたはカスタム・サーバー)内に存在します。アプリケーションでは、サーブレット、Javaクライアント、汎用クライアントなどのWebクライアントを、XMLまたはCommon Object Request Broker Architecture(CORBA)を使用してサポートできます。

3層アプリケーションは、TopLinkがJavaサーバー(J2EEサーバーまたはカスタム・サーバーのいずれか)内に存在する、一般的なアーキテクチャです。このアーキテクチャでは、サーバー・セッションにより、JDBC接続および共有オブジェクト・キャッシュへの共有アクセスがクライアントに与えられます。単一のJVM上に存在するため、このアーキテクチャはシンプルで、簡単に拡張できます。このアーキテクチャにおけるTopLinkの永続エンティティは、通常、Javaオブジェクトです。

このアーキテクチャでは、多くの場合、Webベースのアプリケーションをサポートします。その場合のクライアント・アプリケーションはWebクライアント、Javaクライアントまたはサーバー・コンポーネントです。

図2-3 3層アーキテクチャ

図2-3の説明が続きます
「図2-3 3層アーキテクチャ」の説明

すべての3層アプリケーションがWebベースとはかぎりませんが、このアーキテクチャは分散Webアプリケーションに最適です。また、WebアプリケーションでEJBを使用することも一般的ですが、このTopLinkのアーキテクチャでは使用しません。

実装例

3層アーキテクチャの実装例には、次のものがあります。

  • Model-View-Controllerモデル2のアーキテクチャ設計パターン。J2EEコンテナで稼働し、TopLinkを使用してデータにアクセスするサーブレットおよびJSPがあり、EJBはありません。

  • SwingまたはAbstract Window Toolkit(AWT)クライアント。RMIを介してサーバー・サイドJavaアプリケーションに接続し、アプリケーション・サーバーまたはコンテナはありません。

長所と短所

3層Webアプリケーション・アーキテクチャには、次のような利点があります。

  • 高いパフォーマンスの軽量永続オブジェクト

  • デプロイ・プラットフォームおよび構成における高い柔軟性

このアーキテクチャの短所は、EJBほど標準的ではないことです。

リモート・セッションを使用するバリエーション

TopLinkには、リモート・セッションと呼ばれるセッション・タイプがあります。このセッションは、フル・セッションAPIを提供し、独自のキャッシュがありますが、TopLinkサーバーではなくクライアント・システム上に存在します。通信は、RMIまたはRMI-Internet Inter-Object Request Broker Protocol(IIOP)を使用するように構成できます。

リモート・セッション操作には、対応するクライアント・セッションがサーバー上に必要です。

これは、クライアント層からサーバー層へのアクセスを簡略化したい開発者にとっては優れたオプションですが、クライアント・セッションの使用に比べてスケーラビリティに欠け、サーバー側の動作を簡単に変更できません。

詳細は、「リモート・セッション」を参照してください。

技術的な問題

ステートレス・クライアントを使用した3層アプリケーションには、次のような技術的な問題がいくつかあります。

  • ステートレス環境でのトランザクション管理

    一般的な設計では、単一の作業ユニット(トランザクション・セッション)内でクライアント・リクエストを区切ります。ステートレス環境では、このことがプレゼンテーション層の設計方法に影響する場合があります。たとえば、クライアントがトランザクションの情報を収集するために複数のページを必要とする場合、プレゼンテーション層は、アプリケーションが変更またはリクエストの一式を収集するまで、情報をページ間で保有する必要があります。その時点で、プレゼンテーション層はデータベースを変更するために作業ユニットを起動します。

  • ステートレス環境でのオプティミスティック・ロック

    ステートレス環境では、期限切れの(失効した)データを処理しないよう、特に注意する必要があります。失効したデータを処理しないための一般的な方法は、オプティミスティック・ロックを実装し、オプティミスティック・ロックの値をオブジェクトに格納することです。

    この方法は、ステートレス・アプリケーションがオブジェクトをシリアライズする場合、またはオブジェクトの内容を代替形式でクライアントに送信する場合には、十分注意して行う必要があります。これらの場合、オプティミスティック・ロックの値を編集ページのHTTPコンテンツとしてクライアントに転送します。次に、任意の書込みトランザクションの戻り値を使用して、クライアントが処理を実行しているときに、データが変更されていないことを確認する必要があります。

    ロックの詳細は、「ロック・ポリシーの構成」を参照してください。

  • 外部JDBCプール

    デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です(「外部接続プーリングの構成」を参照)。

  • JTA/JTSの統合

    JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するためにJTA/JTSを使用するよう、TopLinkを構成する必要があります(「作業ユニットと外部トランザクション・サービスの統合」を参照)。

  • キャッシュ・コーディネーション

    複数のサーバーを使用してアプリケーションを拡張することを選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります(「キャッシュの概要」を参照)。