(57)【要約】      （修正有）【課題】データベースのインスタンスを要約するために各ノードにおいてデータの仮想化レイヤを実装を含む、共通データベースにアクセスするクラスタ化されたウェブ・サービス・ノードを構成する。【解決手段】各ノードで、アプリケーション開発（マスタ）エンティティＢｅａｎのすべての読み取りおよび書き込みオペレーションを有する第１のデータ仮想化エンティティＢｅａｎを作成するステップと、マスタ・エンティティＢｅａｎの読み取りオペレーションのみを担持し、レプリカ・インスタンスに対処する、第２のエンティティＢｅａｎを作成するステップと、第１のエンティティＢｅａｎでオペレーション要求を受け取るステップと、それぞれのデータベース・インスタンスにアクセスするために、要求されたオペレーションに応じてマスタ・エンティティＢｅａｎまたは第２のエンティティＢｅａｎのいずれかに要求をルーティングするステップと、が実行される。【選択図】  図２
2007234013.tif 000002
【特許請求の範囲】
【請求項１】
ウェブ・サービス・アプリケーションからのデータベースのインスタンスを要約するために、各ノードにおいてデータの仮想化レイヤを実装することを有する、共通データベースにアクセスするクラスタ化されたウェブ・サービス・ノードを構成するための方法。
【請求項２】
共通データベースにアクセスするノード・セット上でウェブ・サービス・オペレーションを実行する方法であって、前記データベースは、マスタ・エンティティＢｅａｎおよび少なくとも１つのレプリカ・インスタンスによって対処される、マスタ・インスタンスとして配置構成され、各前記ノードで実行される、
前記マスタ・エンティティＢｅａｎの読み取りおよび書き込みのすべてのオペレーションを有する第１のエンティティＢｅａｎを作成するステップと、
前記マスタ・エンティティＢｅａｎの読み取りオペレーションのみを担持し、前記レプリカ・インスタンスに対処する、第２のエンティティＢｅａｎを作成するステップと、
前記第１のエンティティＢｅａｎでオペレーション要求を受け取るステップと、
それぞれのデータベース・インスタンスにアクセスするために、前記要求されたオペレーションに応じて前記マスタ・エンティティＢｅａｎまたは前記第２のエンティティＢｅａｎのいずれかに前記要求をルーティングするステップと、
を有する、方法。
【請求項３】
前記要求において書き込みオペレーションが要求された場合、前記要求は前記マスタ・エンティティＢｅａｎにルーティングされる、請求項２に記載の方法。
【請求項４】
前記要求において読み取りオペレーションが要求された場合、（ｉ）書き込みオペレーションに関する前記要求が以前にない場合、または（ｉｉ）前記レプリカ・インスタンスが前記マスタ・インスタンスと同期する場合、前記要求は前記第２のエンティティＢｅａｎにルーティングされ、それ以外の場合、前記要求は前記マスタ・エンティティＢｅａｎにルーティングされる、請求項２に記載の方法。
【請求項５】
前記ノードのうちの１つに向けてオペレーション要求を送るステップをさらに有する、請求項２に記載の方法。
【請求項６】
共通データベースにアクセスするノード・セットによって形成されるウェブ・サービス・サーバであって、前記データベースは、マスタ・エンティティＢｅａｎおよび少なくとも１つのレプリカ・インスタンスによって対処される、マスタ・インスタンスとして配置構成され、各ノードが、
前記マスタ・エンティティＢｅａｎの読み取りおよび書き込みのすべてのオペレーションを有する第１のエンティティＢｅａｎを作成するため、
前記マスタ・エンティティＢｅａｎの読み取りオペレーションのみを担持し、前記レプリカ・インスタンスに対処する、第２のエンティティＢｅａｎを作成するため、
前記第１のエンティティＢｅａｎでオペレーション要求を受け取るため、および
それぞれのデータベース・インスタンスにアクセスするために、前記要求されたオペレーションに応じて前記マスタ・エンティティＢｅａｎまたは前記第２のエンティティＢｅａｎのいずれかに前記要求をルーティングするため、
のプロセッサを有する、サーバ。
【請求項７】
前記要求において書き込みオペレーションが要求された場合、前記要求は前記プロセッサによって前記マスタ・エンティティＢｅａｎにルーティングされる、請求項６に記載のサーバ。
【請求項８】
前記要求において読み取りオペレーションが要求された場合、（ｉ）書き込みオペレーションに関する前記要求が以前にない場合、または（ｉｉ）前記レプリカ・インスタンスが前記マスタ・インスタンスと同期する場合、前記要求は前記プロセッサによって前記第２のエンティティＢｅａｎにルーティングされ、それ以外の場合、前記要求は前記マスタ・エンティティＢｅａｎにルーティングされる、請求項６に記載のサーバ。
【請求項９】
前記ノードのうちの１つに向けてオペレーション要求を送るためのディスパッチャをさらに有する、請求項６に記載のサーバ。
【請求項１０】
コンピュータ読み取り可能プログラムを有するコンピュータ使用可能媒体を有するコンピュータ・プログラムであって、前記コンピュータ読み取り可能プログラムがコンピュータ上で実行された場合、前記コンピュータに、
マスタ・データベース・インスタンスに対処するマスタ・エンティティＢｅａｎの読み取りおよび書き込みのすべてのオペレーションを有する第１のエンティティＢｅａｎを作成するステップと、
前記マスタ・エンティティＢｅａｎの読み取りオペレーションのみを担持し、レプリカ・データベース・インスタンスに対処する、第２のエンティティＢｅａｎを作成するステップと、
前記第１のエンティティＢｅａｎでオペレーション要求を受け取るステップと、
それぞれのデータベース・インスタンスにアクセスするために、前記要求されたオペレーションに応じて前記マスタ・エンティティＢｅａｎまたは前記第２のエンティティＢｅａｎのいずれかに前記要求をルーティングするステップと、
を有する方法を実行させる、コンピュータ・プログラム。
【請求項１１】
前記コンピュータ読み取り可能プログラムが前記コンピュータ上で実行された場合、さらに前記コンピュータに、前記要求において書き込みオペレーションが要求された場合、前記要求を前記マスタ・エンティティＢｅａｎにルーティングさせる、請求項１０に記載のコンピュータ・プログラム。
【請求項１２】
前記コンピュータ読み取り可能プログラムが前記コンピュータ上で実行された場合、さらに前記コンピュータに、
（ｉ）書き込みオペレーションに関する前記要求が以前にない場合、または（ｉｉ）前記レプリカ・データ−ベース・インスタンスが前記マスタ・データ−ベース・インスタンスと同期する場合、前記要求を前記第２のエンティティＢｅａｎにルーティングさせ、それ以外の場合、前記要求を前記マスタ・エンティティＢｅａｎにルーティングさせる、請求項１０に記載のコンピュータ・プログラム。
【請求項１３】
共通データベースにアクセスするノード・セット上でウェブ・サービスを実行する方法であって、前記データベースは、別個の重複しない区画化インスタンスとして配置構成され、各前記ノードで実行される、
前記共通データベースに合致するスキーマを有する空のデータベース・インスタンスを実装するステップと、
前記空のデータベースを利用する照会において関連する区画化を識別するステップと、
前記照会をそれぞれの区画化データベース・インスタンスにルーティングするステップと、
を有する、方法。
【請求項１４】
前記それぞれの区画化データベース・インスタンスから結果セットを受け取るステップをさらに有する、請求項１３に記載の方法。
【請求項１５】
照会が複数の前記区画化データベース・インスタンスにわたる場合、前記関連する区画が識別され、前記結果セットがそれぞれの結果セットの結合として形成される、請求項１４に記載の方法。
【請求項１６】
前記照会を前記ノードのうちの１つに向けて送るステップをさらに有する、請求項１３に記載の方法。
【請求項１７】
共通データベースにアクセスするノード・セットによって形成されるウェブ・サービス・サーバであって、前記データベースは、別個の重複しない区画化インスタンスとして配置構成され、各前記ノードは、
前記共通データベースに合致するスキーマを有する空のデータベース・インスタンスを実装するため、
前記空のデータベースを利用する照会において関連する区画化を識別するため、および
前記照会をそれぞれの区画化データベース・インスタンスにルーティングするため、
のプロセッサを含む、サーバ。
【請求項１８】
コンピュータ読み取り可能プログラムを有するコンピュータ使用可能媒体を有するコンピュータ・プログラムであって、前記コンピュータ読み取り可能プログラムがコンピュータ上で実行された場合、前記コンピュータに、
共通データベースに合致するスキーマを有する空のデータベース・インスタンスを実装するステップと、
前記空のデータベースを利用する照会において関連する区画化を識別するステップと、
前記照会をそれぞれの区画化データベース・インスタンスにルーティングするステップと、
を有する方法を実行させる、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、実行可能電子商取引などの、データベース・クラスタを利用するウェブ・サービスに関する。
【背景技術】
【０００２】
電子商取引は、ますます毎日の生活の一部になりつつある。商品およびサービスに関する購入の照会および購入の注文は、電子ネットワークを介して、すなわちほとんどの場合は公衆インターネットを介して実行される。高容量電子商取引アプリケーションは、高可用性、保証サービス品質（ＱｏＳ）、ならびに高可用性のためのロード・バランシング、耐障害性、および安定性を備えた応答時間を要求する。こうしたシステムは、作業負荷を共有し、高可用性および改善された応答時間を提供するために、クラスタ・ノードがアプリケーション・サーバ（およびアプリケーション）およびデータベース・インスタンス（マスタ・データベース・インスタンスおよびレプリカ）をホストする、クラスタを介して配置（deploy）される。
【０００３】
電子商取引アプリケーションを実施するための既知の手法の１つがＪ２ＥＥ（Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃによって出版されたＪａｖａ（登録商標）  ２  Ｐｌａｔｆｏｒｍ，  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ）である。Ｊ２ＥＥは、仕様および実施例の統合セットであり、これらを合わせて、多層サーバ中心アプリケーションを開発、配置、および管理するためのソフトウェア・ソリューションを実行可能にする。Ｊ２ＥＥは、ウェブ・サービスを構築および使用するためのプラットフォームでもある。
【０００４】
Ｊ２ＥＥプラットフォームにおける主要な技術は、Ｊａｖａ（登録商標）ＡＰＩ  ｆｏｒ  ＸＭＬ−Ｂａｓｅｄ  ＲＰＣ（ＪＡＸ−ＲＰＣ）、Ｊａｖａ（登録商標）Ｓｅｒｖｅｒ  Ｐａｇｅｓ、Ｊａｖａ（登録商標）  Ｓｅｒｖｌｅｔｓ、Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）Ｂｅａｎｓコンポーネント、Ｊ２ＥＥ  Ｃｏｎｎｅｃｔｏｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ、Ｊ２ＥＥ  Ｍａｎａｇｅｍｅｎｔ  Ｍｏｄｅｌ、Ｊ２ＥＥ  Ｄｅｐｌｏｙｍｅｎｔ  ＡＰＩ、Ｊａｖａ（登録商標）  Ｍａｎａｇｅｍｅｎｔ  Ｅｘｔｅｎｓｉｏｎｓ（ＪＭＸ）、Ｊ２ＥＥ  Ａｕｓｈｏｒｉｚａｔｉｏｎ  Ｃｏｎｔｒａｃｔ  ｆｏｒ  Ｃｏｎｔａｉｎｅｒｓ、Ｊａｖａ（登録商標）  ＡＰＩ  ｆｏｒ  ＸＭＬ  Ｒｅｇｉｓｔｒｉｅｓ（ＪＡＸＲ）、Ｊａｖａ（登録商標）  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ（ＪＭＳ）、Ｊａｖａ（登録商標）  Ｎａｍｉｎｇ  ａｎｄ  Ｄｉｒｅｃｔｏｒｙ  Ｉｎｔｅｒｆａｃｅ（ＪＮＤＩ）、Ｊａｖａ（登録商標）  Ｔｒａｎｓａｃｔｉｏｎ  ＡＰＩ（ＪＴＡ）、ＣＯＲＢＡ、およびＪＤＢＣデータ・アクセスＡＰＩである。
【０００５】
既知の電子商取引アーキテクチャには、アプリケーション用の層状の開発および配置手法がある。電子商取引アプリケーションの異なる層は、（ｉ）ビューまたはユーザ・インターフェース層、（ｉｉ）コントローラまたはアプリケーション論理層、および（ｉｉｉ）モデルまたはアプリケーションの永続データ・モデル層である。これらの層はＭＶＣ（すなわち、モデル、ビュー、およびコントローラ）アーキテクチャと呼ばれ、それぞれウェブ、アプリケーション、およびデータベースのサーバを介して配置される。
【０００６】
図１に示されるように、ＭＶＣアーキテクチャ１０は、ウェブ・サービス・クライアント・コンピュータ１４と対話する人間のアクター１２を有する。クライアント・コンピュータ１４はブラウザ・アプリケーション（ウェブ・サービスを起動するＪ２ＥＥプログラムのクライアント）を実行し、好適な（すなわちｈｔｔｐ／ｈｔｔｐｓ）プロトコルを使用してインターネットなどの公衆網１６を介してアプリケーション・サーバと対話する。Ｊ２ＥＥアプリケーションを配置するアプリケーション・サーバ１８は、内部に複数のアプリケーションＪａｖａ（登録商標）サーブレット２２が常駐するサーブレット・コンテナ２０を有する。コンテナ２０はＪ２ＥＥサーブレット仕様を実装し、ランタイム時にサーブレット２２を実行する。サーブレット・コンテナ２０の出力２４は、Ｅｎｔｉｔｙ／Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）  Ｂｅａｎ（ＥＪＢ）コンテナ２６に渡されるＲＭＩ／ＩＩＯＰ（すなわちＩＩＯＰを介したＲＭＩ）起動である。ＥＪＢコンテナ２６は、複数のアプリケーションＥＪＢ  ２８を有する。ＥＪＢコンテナ２６からの出力３０は、データベース３２上で読み取り／書き込み呼び出しを実行する、ＪＤＢＣ  ＡＰＩである。
【０００７】
多層アーキテクチャを配置するための手法の１つが、ウェブ、アプリケーション、およびデータベース層をクラスタ化して、エンド・ツー・エンド・アプリケーションの性能を向上させることである。図２に示されるように、アーキテクチャ５０は、ネットワーク・ディスパッチャ・プログラム５２と通信するウェブ・サービス・クライアント１４を含む。ノード５４〜５８のクラスタは、複数のアプリケーション・サーバ５９〜６２およびデータベース・インスタンス６４〜６８をホストする。ディスパッチャ・プログラム５２は、ノード５４〜５８に要求を等しく分配する。データベース・インスタンス６４〜６８は、データベース障害の際に性能利点およびより高い可能性を得るために、いくつかのノードにわたって複製（replicate）される。ネットワーク・ディスパッチャ５２（または仮想ＩＰ）は、クラスタからのクライアント・アプリケーション１４を要約（abstract）し、ノード５４〜５８のクラスタと対話するために単一のインターフェースを提供する。
【０００８】
次に、アプリケーション・サーバ５９〜６２へと進む。アプリケーション・サーブレット２２は、上記と同じ機能を有する。アプリケーション論理８２は、それぞれが、アプリケーションがクライアントの要求を満たすために使用するビジネス論理を収容する、Ｊａｖａ（登録商標）クラスのセットである。ビジネス論理はどのようなものでも可能であり、たとえば、クライアント１２によって送信されたデータをデータベース７０内で持続させるためにその妥当性を検査する。アプリケーション・セッションＢｅａｎ８４は、前述のようなＥｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）  Ｂｅａｎｓ（ＥＪＢ）である。セッションＢｅａｎは、「ＡＣＩＤ」サポートを必要とするアプリケーション論理を収容するＪａｖａ（登録商標）コンポーネントである。ＡＣＩＤは、Ａｔｏｍｉｃｉｔｙ（アトミック性）、Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）、Ｉｓｏｌａｔｉｏｎ（独立性）、およびＤｕｒａｂｉｌｉｔｙ（永続性）の略である。Ｊ２ＥＥコンテナ（ＩＢＭ  ＷｅｂＳｐｈｅｒｅ  Ａｐｐｌｉｃａｔｉｏｎ  ＳｅｒｖｅｒおよびＢＥＡ  Ｗｅｂｌｏｇｉｃ  Ａｐｐｌｉｃａｔｉｏｎサーバなど）は、セッションＢｅａｎ８４にＡＣＩＤサポートを提供する。
【０００９】
データ・アクセス・レイヤ７２〜７６は、エンティティＢｅａｎを置き換えるため、およびデータベースに直接アクセスするために配置される。ネットワーク・ディスパッチャ７８は、ディスパッチャ５２を参照しながら上記で説明した原理と同じ原理で配置され、レプリカ・クラスタ６４〜６８内のデータベース・ノードのうちの１つにデータベース要求をルーティングする。
【００１０】
読み取りオペレーションはレプリカ・データベース・インスタンス６４〜６８にルーティングされ、更新、挿入および削除は、それぞれのデータ・アクセス・レイヤ７２〜７６およびネットワーク・ディスパッチャ７８によって、マスタ・データベース７０にルーティングされる。アプリケーションが即時書き込み後の読み取りを要求する場合、データ・アクセス・レイヤ７２〜７６は、こうした照会をマスタにルーティングするためのトランザクション間でステートフル（stateful）でなければならないか、または照会をレプリカにルーティングすることによって、アプリケーションに失効（stale）データを提供する。複製インフラストラクチャは、バックグラウンドで独立に動作し、複製ジョブを完了した旨を完了した時点で通知するために、データ・アクセス・レイヤとは一体化されない。このため、たとえデータがレプリカに複製されている場合であっても、挿入／削除／更新後にすべての照会をマスタ７０へ転送し続けるため、データ・アクセス・レイヤ７２〜７６の機能が低下し、これによってクラスタのリソースは十分活用されない。
【００１１】
非常に大規模なデータベースを有するアプリケーションに適した他の手法は、データベースをマスタおよび区画トポロジとして実施することである。図３に示されるように、ここでもアーキテクチャ１００はネットワーク・ディスパッチャ５２を有する。各アプリケーション・サーバ１０２〜１０６は、図２のサーバ５８〜６２と同様に、アプリケーション・サーブレット、アプリケーション論理、およびアプリケーション・セッションＢｅａｎを有する。しかしながら、データ・アクセス・レイヤ７２〜７６はアプリケーション・エンティティＢｅａｎレイヤ１０８〜１１２に置き換えられる。１次データベース・インスタンス１１４が存在し、それぞれのアプリケーション・エンティティＢｅａｎ１０８〜１１２からの読み取り／書き込み要求に応答する。さらに、１次データベース・インスタンス１１４は、別個の区画１１６として存在する。１次データベース・インスタンス１１４は、クラスタ内に区画化データベース・インスタンスの知識を有し、さらに、データをどのように区画化するか、および区画内のどのノードがデータのどの部分を担持（carry）するか、についての情報も維持する。この情報を使用して、１次ｄｂでインデックスが構築される。照会がサブミットされると、１次データベース１１４は以下のように実行する。
ｉ）照会を分析する
ｉｉ）データ区画に合うように照会を様々な部分に分割する
ｉｉｉ）個々の部分を区画化データベース・ノード１１６ｎにルーティングする
ｉｖ）照会の実行に関連する各区画から結果を収集する
ｖ）オペレーションがすべての区画からの結果の完全なビューを必要とする場合、下位の区画によって個々に実行できない結果のコレクションに対してデータベース・オペレーションを実行する
ｖｉ）最終結果セットを構成する
ｖｉｉ）クライアントの照会に回答する
【００１２】
区画済みデータベース１１６ｎは、データベース１１４の一部を担持するデータベース・インスタンスである。たとえば大規模テーブルＴを、第１のデータベースがそのテーブルの行（タプル）の第１の半分を担持し、第２のデータベースが第２の半分を担持するように、２つのデータベース・インスタンスに区画化することができる。データベースの区画化は、異なるテーブルを異なるデータベース・サーバに配置することによっても達成可能である。たとえばテーブルＴ１がサーバＳ１に、Ｔ２がサーバＳ２に配置される。
【００１３】
しかしながら、こうしたソリューションを介して分散システムを配置するには、以下の制限がある。
【００１４】
１．データ区画の配置は、データベースのベンダおよび製品に極めて特有のものである。データ区画配置および照会ルーティング論理は、業界標準ではなく、アプリケーションとデータベースの製品およびベンダとを緊密に結合させるものである。
【００１５】
２．ソリューションが標準データベース技術の拡張である場合、データ区画化を提供するデータベース製品は、特別なデータベース管理を必要とする場合がある。
【００１６】
３．区画化データセットへの１次インターフェースとして動作する単一のデータベース・インスタンスは、区画化データベース・インスタンスを要約するが、照会に関連するデータを担持する区画化ノードへ照会がルーティングされる前の中間照会停止ポイントとして動作する。これにより、アプリケーションは第１に１次データベース・インスタンスに接続され、次に、１次データベース・インスタンスが２次インスタンスに接続されることになり、本セクションで後述するように、状況によってはシステムの効率が低下する。
【００１７】
４．フォールト・トレランスを提供するために１次インスタンスおよび区画インスタンスを配置するスマートな技法が存在する。しかしながら、データベース・システムへの単一ポイントのインターフェースとして単一の１次インスタンスを有するようにソリューションが設計および配置された場合、１次インスタンスの単一ポイント障害により、データベース障害のリスクは増加する。
【００１８】
１次インスタンスは、照会を分析してどのデータ区画に照会を含めることができるかをチェックし、単一のデータ区画が存在する場合、１次インスタンスは全照会をその区画にルーティングする。照会を含めることに関連する区画が複数存在する場合、１次インスタンスは個々の区画にルーティング可能な複数の部分に照会を分割し、必要であれば、各区画からの結果をアプリケーションに返送する前にこの結果を処理する（結合オペレーションなどの）責務を負う。
【００１９】
データを区画化するための照会作業負荷およびデータが首尾良く分析された場合、照会が複数のデータ区画にわたるインスタンスはわずかになるはずである。ＯＬＴＰアプリケーションの場合、照会はより複雑でないため、ほとんどの場合単一区画によって応えられる。したがってこうしたアプリケーションにとっては、照会を１次インスタンスにルーティングした後にこれを区画にルーティングするのに比べて、照会を区画に直接ルーティングできる方が効率的である。しかしながら、こうした直接ルーティングを実行可能にするエンタープライズ・システムは、異なる区画に対して照会を分割すること、および、アプリケーションにトランスペアレントであり、エンタープライズ・システム・ベンダがソリューションをフレームワークに組み込めるようにするための業界標準として適合可能な方法で、それらの結果を再度結合することなどの、１次データベースの他の機能もサポートしている。前述の内容をサポートしていないＪ２ＥＥアプリケーションは、データベース・ベンダと緊密に結合されるか、または、アプリケーション層内にデータ区画論理を封入しなければならず、どちらもアプリケーションのポータビリティを複雑にする。これにより、Ｊ２ＥＥフレームワークなどのエンタープライズ・システムは、トランスペアレントかつ疎に結合された方法で、区画化データベースを介してアプリケーションを配置できるようにする必要が生じる。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
本発明は、これらの問題点のうちの１つまたは複数を克服するか、または少なくとも軽減することを対象とする。
【課題を解決するための手段】
【００２１】
本発明は、スケーラビリティ、性能、可用性、および信頼性を向上させること、ならびにデータベース・クラスタの配置において、とりわけ電子商取引アプリケーションにおいて、サービス品質を提供することを対象とする。したがって、ウェブ・サービス・アプリケーションからのデータベースのインスタンスを要約するために各ノードにおいてデータの仮想化レイヤを実装することを含む、共通データベースにアクセスするクラスタ化されたウェブ・サービス・ノードの構成が開示されている。
【００２２】
一実施形態では、共通データベースにアクセスするノード・セット上でウェブ・サービス・オペレーションが実行される。データベースは、マスタ・エンティティＢｅａｎおよび少なくとも１つのレプリカ・インスタンスによって対処される、マスタ・インスタンスとして配置構成される。各ノードで、マスタ・エンティティＢｅａｎのすべての読み取りおよび書き込みオペレーションを有する第１のデータ仮想化エンティティＢｅａｎを作成するステップと、マスタ・エンティティＢｅａｎの読み取りオペレーションのみを担持し、当該レプリカ・インスタンスに対処する、第２のエンティティＢｅａｎを作成するステップと、第１のエンティティＢｅａｎでオペレーション要求を受け取るステップと、それぞれのデータベース・インスタンスにアクセスするために、要求されたオペレーションに応じてマスタ・エンティティＢｅａｎまたは第２のエンティティＢｅａｎのいずれかに要求をルーティングするステップと、が実行される。
【００２３】
他の実施形態では、共通データベースにアクセスするノード・セット上でウェブ・サービスが実行される。データベースは、別個の重複しない区画化インスタンスとして配置構成される。各ノードで、当該共通データベースに合致するスキーマを有する空のデータベース・インスタンスを実装するステップと、空のデータベースを利用する照会において関連する区画化を識別するステップと、照会をそれぞれの区画化データベース・インスタンスにルーティングするステップと、が実行される。
【００２４】
対応するウェブ・サービスのサーバおよびコンピュータ・プログラムも開示される。
【発明を実施するための最良の形態】
【００２５】
概要
アプリケーションと共に物理データベース・インスタンスを要約するための、データ仮想化レイヤが開発される。仮想化レイヤは、データ管理および照会ルーティング論理を収容し、アプリケーション・コードからアプリケーションをホストするミドルウェア（アプリケーション・サーバなど）へとデータ・アクセス論理を移動させる。
【００２６】
ウェブ・アプリケーションの開発に使用される好ましいＪ２ＥＥ技術は、データベース・レイヤのスケーラブルな配置を提供するように拡張される。アプリケーション・サーバ（ＩＢＭ  ＷｅｂＳｐｈｅｒｅおよびＢＥＡ  Ｗｅｂｌｏｇｉｃ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒｓなど）に配置されたアプリケーション・レイヤは、ウェブ・トランザクションをロード・バランシングするようにクラスタ化されるが、データベース・レイヤは、既存のＪ２ＥＥ技術を使用してクラスタ化することはできない。Ｊ２ＥＥアーキテクチャ内に配置されたデータ・オブジェクトまたはエンティティＢｅａｎは、設計により、単一のデータベース・インスタンスに接続され、レプリカを作成するかまたはデータベース・クラスタを水平に区画化するかのいずれかによって、データベース・インスタンスをクラスタ化するためのわずかな選択肢が残されている。データ仮想化レイヤは、これを実行することができる。
【００２７】
アプリケーションのクラスに応じて、データの可用性、スケーラビリティ、および性能を向上させるために、「複製データベース」および「区画化データベース」のいずれかの手法が選択される。電子商取引アプリケーションには、ａ）データ読み取り集中（Intensive）、ｂ）データ読み取り／書き込み集中、およびｃ）データ書き込み集中などの、様々なクラスがある。「複製データベース」ソリューションは、データ読み取り集中アプリケーションをターゲットとし、「区画化データベース」ソリューションは、他の２つ、すなわち読み取り／書き込み集中および書き込み集中をターゲットとする。
【００２８】
以下、諸実施形態についての説明ではＪ２ＥＥの例が使用される。
【００２９】
複製データベース
複製データベース・ソリューションは、エンティティＢｅａｎの２つのクローンを作成することによって達成される。エンティティＢｅａｎはデータ（テーブル）のオブジェクト指向ビューであり、典型的にはテーブルから指示する単一のタプルを表す。その後、クローン化されたエンティティＢｅａｎは、クローン化されたＢｅａｎ（ＲＷＢｅａｎ）のうちの１つがデータ仮想化を提供し、アプリケーションからデータの物理ロケーションを要約するような方法で、配置される。他方のクローン化されたＢｅａｎ（ＲｅａｄＢｅａｎ）は、複製データベースに対抗して（against）配置される。オリジナルの（１次）エンティティＢｅａｎは、依然として１次データベースを指示し続ける。データ・バーチャライザ（virtualizer）エンティティＢｅａｎは、１次Ｂｅａｎの属性（ＪＮＤＩ名）を使用して配置されるため、アプリケーションは、１次エンティティＢｅａｎではなくデータ・バーチャライザ・エンティティＢｅａｎの起動をトランスペアレントに開始する。そのため、データ・バーチャライザ・エンティティＢｅａｎは、１次エンティティＢｅａｎまたはクローン化された（読み取り）エンティティＢｅａｎのいずれかに要求を委譲（delegate）することによって、１次データベースまたはそのレプリカのいずれかに照会をロード・バランシング（ルーティング）するための制御を有する。
【００３０】
次に図４を参照し、図２に示された配置構成と同じ整数については再度説明しないことに留意されたい。アーキテクチャ１３０では、図２のネットワーク・ディスパッチャ５２がＱｏＳ目標ベース・ルータ・サーブレット（ＱＲＳ）１３２に置き換えられる。ＱＲＳ  １３２は、ノード１４０〜１４４のクラスタへのエントリ・ポイントであり、所与のサービス・クラスについて各ノードの性能を監視する。ＱＲＳ  １３２は性能をバックグラウンドで記録し、その結果を使用し、それらのＱｏＳ目標および前の実行で観察された各ノードの性能に基づいて、後続の要求をルーティングする。ＱＲＳ  １３２は、ＣＥＢＲＷ（以下で説明）の支援でデータベース状態変更も監視し、データベース状態が変更されている場合、このデータベース状態変更をＳＳＳに通知するために、要求をＳＳＳ（以下を参照）に渡す際に追加の要求パラメータを設定する。ＳＳＳは、その下のすべての層をほぼ同じにできるように、スレッド名内のフラグを設定する。
【００３１】
新しいコンポーネント「セッション・シンクロナイザ・サーブレット」（ＳＳＳ）１３４〜１３８が、ウェブおよびアプリケーションの論理を収容するそれぞれのノード１４０〜１４４と共に配置される。各ＳＳＳ  １３４〜１３８は、クラスタ・ノード１４０〜１４４間でのユーザ・セッションを同期化する責務を負う。ユーザからの様々な要求をクラスタの様々なノードで処理できるため、要求のＱｏＳ目標およびクラスタ内のノードによって提供されるＱｏＳに応じて、ＳＳＳ  １３４〜１３８は、要求が同じ場所にルーティングされる場合に、ノードでのユーザ・セッションを同期化する。ＳＳＳ  １３４〜１３８は、要求がクラスタ内の選択されたノード１４０〜１４４に着信すると、ユーザ・セッションを更新する。ＳＳＳ  １３４〜１３８は、それぞれのノード１４０〜１４４上で要求を受け取るための第１のコンポーネントであり、アプリケーション・サーバのサーブレット・チェーン構成プロパティを使用して、第１のサーブレットとして構成される。ＳＳＳ  １３４〜１３８がユーザ・セッションを更新した後、要求は、サーブレット・コンテナによってそれぞれのアプリケーション・サーブレット２２に転送される。アプリケーション・サーバは、要求をアプリケーション・サーブレット２２に渡す前に、ＳＳＳ  １３４〜１３８を自動的に起動することになる。アプリケーション・サーブレット２２による処理が完了すると、ＳＳＳ  １３４〜１３８はユーザ・セッションを読み戻し、これをクラス他のすべてのノード１４０〜１４４上に配置されたすべてのＳＳＳ  １３４〜１３８がアクセス可能な共通（マスタ）データベース１５２で持続させる。ＱＲＳ  １３２によって各ユーザ・セッションに固有の識別子が割り当てられ、共通データベース１５２上でユーザ・セッションを持続させるために同じものが使用される。ユーザ・セッション識別子は、ＱＲＳ  １３２のセッション内で維持され、ＱＲＳ  １３２とＳＳＳ  １３４〜１３８との間の要求ＵＲＩの一部としてＳＳＳ  １３４〜１３８に渡される。要求が着信すると、ＳＳＳ  １３４〜１３８は共通データベース１５２からユーザ・セッションを読み取り、共通データベース１５２から読み取られたセッション・オブジェクトからの値を使用して、現在のセッション属性を設定する。
【００３２】
データ・オブジェクトまたはエンティティＢｅａｎの配置は、再設計（re-engineer）される。エンティティＢｅａｎは、データベースとのトランザクションおよび永続データの管理のために、読み取り（ｇｅｔＸＸＸ（））および書き込み（ｓｅｔＸＸＸ（））および削除（ｒｅｍｏｖｅ（））オペレーションを実行する。エンティティＢｅａｎは、アプリケーション・サーバの一部であるＪ２ＥＥコンテナ内に配置される。マスタおよびレプリカ・データベース・インスタンスとの統合を実行可能にするために、コンテナ・マネージャ・エンティティＢｅａｎの配置は、アプリケーションにトランスペアレントな方法で再設計される。これは、以下によって実行される。
【００３３】
（ａ）すべての読み取りおよび書き込みオペレーションならびにマスタ・エンティティＢｅａｎのホームおよびリモートの両方のインターフェースの実装によって、エンティティＢｅａｎ（ＣＥＢＲＷ）をクローン化すること。しかしながら、以下で説明するように、クローン化されたＢｅａｎの読み取りおよび書き込みオペレーションの論理はマスタ・エンティティＢｅａｎとは異なる。
【００３４】
（ｂ）マスタ・エンティティＢｅａｎの読み取りオペレーションのみを実行するそのホームおよびリモートのインターフェースによって、新しいエンティティＢｅａｎを作成すること。このＢｅａｎは、マスタ・エンティティＢｅａｎの読み取りおよび書き込みの両方のオペレーションのクローンであるＣＥＢＲＷとは異なり、マスタ・エンティティＢｅａｎの読み取りオペレーションのクローンであるため、ＣＥＢＲと呼ばれる。
【００３５】
ＣＥＢＲＷ  １６０〜１６４およびＣＥＢＲ  １７０〜１７４は、Ｊａｖａ（登録商標）反映ＡＰＩを使用して、コンパイル時（ｅｊｂｃまたは配置段階時）に容易に開発することができる。ＣＥＢＲＷ  １６０〜１６４およびＣＥＢＲ  １７０〜１７４用のコードを生成するための自動化ツールは、ＣＥＢＲＷの読み取りおよび書き込みオペレーション用のコードを生成することもできる。ＣＥＢＲＷ  １６０〜１６４は、「Ｂｅａｎ管理パーシスタンス」（ＢＭＰ）オプションおよびマスタ・エンティティＢｅａｎのＪＮＤＩ名と共に配置される。ＣＥＢＲ  １７０〜１７４は、「コンテナ管理パーシスタンス」（ＣＭＰ）オプションと共に、およびデータベース・レプリカに対抗して配置される。マスタ・エンティティＢｅａｎは、マスタ・データベースおよび新しいＪＮＤＩ名に対抗するＣＭＰとして配置される。ＣＥＢＲＷ  １６０〜１６４の書き込みオペレーション（ｓｅｔＸＸＸ（））は、マスタ・エンティティＢｅａｎの書き込みオペレーションに要求を委譲する。ＣＥＢＲＷ  １６０〜１６４の読み取りオペレーション（ｇｅｔＸＸＸ（））は、以下で説明する条件に応じて、ＣＥＢＲ  １７０〜１７４の読み取りオペレーションまたはマスタ・エンティティＢｅａｎの読み取りオペレーションのいずれかに要求を委譲する。
【００３６】
マスタ・エンティティＢｅａｎのＪＮＤＩ名を使用してＣＥＢＲＷ  １６０〜１６４が配置される場合、アプリケーション・セッションＢｅａｎは、マスタ・エンティティＢｅａｎではなくＣＥＢＲＷ  １６０〜１６４と対話する。これにより、ＣＥＢＲＷ  １６０〜１６４は、アプリケーションから発せられたすべてのデータベース要求をインターセプトし、それらをマスタ・データベース・インスタンス１５２およびレプリカ・データベース・インスタンス１８２〜１８４の間でルーティングすることができる。たとえば、ＣＥＢＲＷ  １６０〜１６４は、読み取り要求をＣＥＢＲ  １７０〜１７４に委譲することによって読み取りオペレーションをレプリカにルーティングし、書き込み要求をマスタ・エンティティＢｅａｎに委譲することによって書き込みオペレーションをマスタ・データベース１５２にルーティングすることができる。アプリケーション・セッションＢｅａｎが書き込みの直後に読み取り要求を実行するケースでは、マスタ・エンティティＢｅａｎがマスタ・データベースに対抗して配置されるため、ＣＥＢＲＷ  １６０〜１６４は、要求を（ＣＥＢＲ  １７０〜１７４の読み取りオペレーションではなく）マスタ・エンティティＢｅａｎの読み取りオペレーションに委譲して、最新のデータをアプリケーションに提供する。読み取り要求が書き込み要求の後であるかどうかを識別するために、ＣＥＢＲＷ  １６０〜１６４は、その書き込みオペレーションの実行中に、要求を実行している現在のスレッド名内にフラグを設定する。このフラグは、ＣＥＢＲＷ  １６０〜１６４の読み取りオペレーションでチェックされ、このフラグの値が設定されていることがわかれば、要求はマスタ・エンティティＢｅａｎの読み取りオペレーションに委譲される。データベース状態変更フラグも、アプリケーション処理が完了した時点でスレッド名を読み取ることにより、ＳＳＳ  １３４〜１３８によって読み取られる。ＳＳＳ  １３４〜１３８は、このフラグをアプリケーション応答に追加し、ＱＲＳ  １３２にデータベース状態変更に関して「通知」するために、この複合応答をＱＲＳ  １３２に渡す。ＱＲＳ  １３２は、アプリケーションがデータベースから最新のデータを取得できるように、後続の要求を、ユーザからクラスタ内のマスタ・データベース・インスタンスに関連付けられたマスタ・ノードへとスマートにルーティングするために、ＳＳＳ  １３４〜１３８からの応答内でこのフラグを常に探索する。ＣＥＢＲＷ  １６０〜１６４は、スレッド名内の書き込みオペレーションに関連付けられたタイム・スタンプも設定する。タイム・スタンプは、ＳＳＳ  １３４〜１３８によってもＱＲＳ  １３２へと渡され、ＱＲＳ  １３２のユーザ・セッションでキャッシュに入れられ、後にデータ複製タイム・スタンプと比較して、データがすべてのレプリカで複製されるまでの段階を識別するために使用される。
【００３７】
アプリケーションは、エンティティＢｅａｎのオリジナル・インターフェースとの対話を続行する場合、この方法を使用して、データ・パーシスタンスの詳細と共に要約される。ＤＢレプリケータ１８０は、マスタ・データベース１５２を増分的にレプリカに複製し、すべてのレプリカ・インスタンス１８２、１８４でデータが複製されるまでのタイム・スタンプをＱＲＳ  １３２に通知する。ＤＢレプリケータ１８０が達成する重要なタスクの１つが、すべて同じ状態のレプリカ・インスタンスおよびデータが複製されるまでのタイム・スタンプを提供することである。ＱＲＳ  １３２は複製タイム・スタンプを、所与のユーザの最新の更新用のタイム・スタンプと比較し、更新タイム・スタンプが複製タイム・スタンプに含まれていることがわかった場合、要求をマスタ・データベース・インスタンスのみで束縛（bind）されたマスタ・ノードにルーティングするのとは対照的に、クラスタの任意のノードに要求をルーティングすることによって、そのレプリカの使用を開始する。データの整合性を可能にするために、ＱＲＳ  １３２は更新タイム・スタンプをデータベース（図示せず）に格納する。
【００３８】
アプリケーションでステートフル・セッションＢｅａｎが使用され、同じものに関する参照がウェブ層ユーザ・セッションのキャッシュに入れられた場合、同じセッション内のユーザからの異なる要求がＱｏＳ目標に応じてノードを切り替えることができるため、１つのノード（たとえば１４０）に配置されたアプリケーション・プログラムが他のノード（たとえば１４２）上のステートフル・セッションＢｅａｎインスタンスを起動してしまう場合がある。これを避けるために、ステートフル・セッションＢｅａｎを開始および利用するユース（use）・ケース（またはＵＲＬパターン）で、ＱＲＳ  １３２を構成することができる。ユーザによってこうしたユース・ケースが起動された場合、ＱＲＳ  １３２は要求をルーティングするノード情報を（ＱＲＳ  １３２のユーザ・セッション内の）キャッシュに入れ、この情報を使用してユーザからの後続のすべての要求を同じノードにルーティングする。同様に、ＱＲＳ  １３２は、ステートフル・セッションＢｅａｎのセッションを終了するユース・ケースで構成することもできるため、結果としてＱＲＳ  １３２は、ステートフル・セッションＢｅａｎを終了する要求に続いて、任意のクラスタ・ノードへのユーザ要求のルーティングを開始することができる。
【００３９】
アプリケーション・シナリオに応じて、ＱＲＳ  １３２は、データベース状態変更に続き、ユーザ要求をクラスタ内のマスタ・ノードへルーティングするために、以下のオプションで構成することができる。
【００４０】
（ａ）ユーザ・ベースの区画化データ：アプリケーションが複数のユーザにまたがって区画化されたデータを担持し、特定のユーザによるデータベース状態変更がその人物の記録のみに影響を与える場合、ＱＲＳ  １３２は、データベース状態変更後のそのユーザからの要求に対してのみデータベース状態変更フラグを設定する。これにより、ＣＥＢＲＷ  １６０は、すべてのノードからのそのユーザに関するデータベース照会を、データベースのマスタ・インスタンスにルーティングできるようになる。たとえば、そのユーザからの「ＰａｙＵｔｉｌｉｔｙＢｉｌｌ」要求は、その人物の口座の残高を変更し、他のユーザの残高（または任意の他のデータ）には影響を与えないことになる。
【００４１】
（ｂ）非区画化データ：アプリケーション・データが複数のユーザにまたがって区画化されておらず、特定のユーザ要求によるデータベース状態変更がその人物の記録および他のユーザの記録に影響を与える場合、ＱＲＳ  １３２は、データベース状態変更後のすべてのユーザからのすべての要求に対してデータベース状態変更フラグを設定する。これにより、ＣＥＢＲＷ  １６０は、すべてのノードからのすべてのユーザに関するすべてのデータベース照会を、データベースのマスタ・インスタンスにルーティングできるようになる。たとえば、１人のユーザ口座から第２のユーザ口座へと資金を振り替えるための「ＩｎｔｅｒＡｃｃｏｕｎｔＴｒａｎｓｆｅｒ」要求は、トランザクションにおいて両方のユーザに関する残高を変更することになる。
【００４２】
ＱＲＳ  １３２は、ユース・ケース（またはＵＲＬパターン）および上記で定義されたオプションを使用してデータベース状態を更新する方法で構成することができる。
【００４３】
図４のアーキテクチャ１３０に関するステップ１〜２９の流れを示す完全なシーケンス図が、図５に示される。
【００４４】
アーキテクチャ１３０は、データベース・クラスタを配置するためのトランスペアレントなサポートを、アプリケーション外部の方法でアプリケーションに提供する。アプリケーションは、最も新しいデータとトランスペアレントに作業するようになり、アプリケーション・スペース内にいかなる論理も構築または組み込むことなしに、データの失効コピーを入手することはない。
【００４５】
アーキテクチャ１３０は、システムの使用可能なリソースを最適に利用するためにＱｏＳベースの要求ディスパッチャ１３２を提供する。
【００４６】
アーキテクチャ１３０は、所与のサービス・クラスについて各ノードの性能を監視し、この性能履歴を使用して所与の要求およびＱｏＳ目標に関するノードを選択する。アーキテクチャは、性能の低いノードおよびニーズ調整について、システム管理者に通知することもできる。
【００４７】
区画化データベース
区画化データベース・ソリューションは、ＩＢＭ  Ｃｌｏｕｄｓｃａｐｅ（商標）（参照により本明細書に組み込まれた、http://www-306.ibm.com/software/data/cloudscape）内の１次データベースと合致する仮想データベースを作成することによって達成される。Ｃｌｏｕｄｓｃａｐｅは、アプリケーション（ミドルウェア・サーバ）のＪＶＭに組み込むことが可能なＪａｖａ（登録商標）のリレーショナル・データベース・エンジン・ライブラリである。Ｃｌｏｕｄｓｃａｐｅ（商標）内の仮想データベースは、物理データベース内のテーブルとまったく同様のテーブル定義からなる。ここでの考え方は、アプリケーションからＣｌｏｕｄｓｃａｐｅ（商標）内のデータベースへと送られるすべての照会をインターセプトし、その照会を、照会に回答する必要のあるデータからなる正しい区画にルーティングすることである。
【００４８】
照会を正しい区画にルーティングできるようにするためには、データ区画を理解し、その情報を使用して照会を分解して、正しいデータソースにルーティングするように、Ｃｌｏｕｄｓｃａｐｅ（商標）データベース・ライブラリを拡張しなければならない。この機能は、ＪＤＢＣドライバを拡張することでは達成されず、それは、照会が複数のデータ区画からデータをフェッチする必要があり、その後、最終結果セットを構築するために結合、ソートなどの複雑なデータベース・オペレーションを必要とする場合がある可能性が非常に高いためである。Ｃｌｏｕｄｓｃａｐｅ（商標）データベース・エンジンは、複数のテーブルおよびデータベース・オペレーションを含む照会を照会グラフ・モデルに分解し、個々の部分を別々に実行して、最終的にデータを統合するための機能を有する。Ｃｌｏｕｄｓｃａｐｅ（商標）はＪａｖａ（登録商標）ライブラリであり、アプリケーションのＪＶＭで実行されるため、この特別なレイヤを導くことによってもたらされるオーバヘッドは大きくない。
【００４９】
次に図６を参照し、図３に示された配置構成と同じ整数については再度説明しないことに留意されたい。
【００５０】
Ｊ２ＥＥアプリケーションを区画化データベース・ノードに対抗して配置するために、Ｊ２ＥＥアプリケーションは、フレームワーク組み込みＲＤＭＢＳ（ＦＥ−ＲＤＢＭＳ）２０２〜２０６（たとえばＩＢＭ  Ｃｌｏｕｄｓｃａｐｅ（商標））に対抗するアーキテクチャ２００内に配置される。
【００５１】
Ｊ２ＥＥアプリケーションは、典型的には、ＩＢＭのＤＢ２（商標）およびＯｒａｃｌｅ（商標）などのリレーショナル・データベースに対抗して配置され、アプリケーション・データを収容し、同じものに対する照会を実行する。Ｊ２ＥＥアプリケーションのデータ・オブジェクトまたはエンティティＢｅａｎは、基礎となるデータベースとの通信チャネルを確立し、データベース・システムに対する照会を実行するためのドライバとして働く、データソース定義と結合される。典型的なＪ２ＥＥアプリケーションでは、データソースは、照会を実行するためのアプリケーションへのＪＤＢＣインターフェースを提供するために、ＤＢ２（商標）およびＯｒａｃｌｅ（商標）などのＲＤＢＭＳ用に定義される。データベースの物理ロケーションはデータソース定義内に封入され、開発および配置のポータビリティのためのアプリケーションから要約される。アプリケーション・エンティティＢｅａｎは、フレームワークがデータソース・インスタンスを取得し、これを関連付けられたエンティティＢｅａｎから送られるすべてのデータベース照会に使用するために、ランタイム時にＪＮＤＩルックアップを実行する際に使用する、（アプリケーション配置記述子内の）データソースＪＮＤＩ名で構成される。
【００５２】
こうしたアプリケーションを区画化データベース・ノード１０２〜１０６のクラスタに対抗して配置するために、アプリケーションから送られるすべてのデータベース照会がインターセプトされ、照会への回答／照会の実行が可能な区画ノードについて分析する。照会は、ＦＥ−ＲＤＢＭＳ  ２０２〜２０６を使用してインターセプトされる。説明した方法を使用すると、スキーマがアプリケーション・データベースのスキーマと合致するＦＥ−ＲＤＢＭＳ  ２０２〜２０６内の空のデータベース・インスタンスを動的に定義することによって、および、同じものに関するデータソース定義をアプリケーション・データベースのＪＮＤＩ名を使用して定義し、アプリケーション・データベースのＪＮＤＩ名を新しい固有の名前に変更することによって、アプリケーションを自動的かつトランスペアレントに修正し、それらをＦＥ−ＲＤＢＭＳ  ２０２〜２０６に対抗して配置することができる。これにより、ＦＥ−ＲＤＢＭＳ  ２０２〜２０６は、アプリケーション・コードを変更することなく、すべてのアプリケーション照会を「取得」し、照会の実行および照会への回答が可能なデータベース区画ノードへそれらをルーティングすることができる。アプリケーション配置の一部として、ＦＥ−ＲＤＢＭＳ  ２０２〜２０６はデータベース区画トポロジで構成され、同じものを使用して、ＦＥ−ＲＤＢＭＳ  ２０２〜２０６は、照会を区画化、再生成し、ＪＤＢＣインターフェースを使用して適切なデータベース区画ノードへとルーティングする。照会が複数のデータベース区画にわたる場合、ＦＥ−ＲＤＢＭＳ  ２０２〜２０６は各区画について照会フラグメントを生成し、アプリケーションの最終結果セットを構成するために各区画の結果に対して結合を実行する。区画化データベース・クラスタに対抗するＪ２ＥＥアプリケーション配置を実行可能にするための、アプリケーション・プロバイダからのコード、照会の生成、または配置のサポートは必要ない。
【００５３】
ＦＥ−ＲＤＢＭＳ  ２０２〜２０６は、照会を実行するための複数のデータベース区画ノードが含まれる場合は、照会フラグメントを分析、生成し、その結果を結合する。
【００５４】
アーキテクチャ２００は、区画化データを備えるデータベース・クラスタに対抗してＪ２ＥＥアプリケーションを配置するために、これらに対するトランスペアレントなサポートを提供する。フレームワークは、アプリケーション照会を、照会を実行できる適切なデータベース区画ノードへトランスペアレントにルーティングする。アプリケーションは、区画化データベース・クラスタと作業をするために、いかなる論理またはコードも担持する必要がない。
【００５５】
アーキテクチャ２００は、アプリケーションをデータベース区画に対抗して配置できるようにすることによって、アプリケーションおよびデータベースの性能を向上させる。
【００５６】
アーキテクチャ２００は、Ｊ２ＥＥアプリケーションがデータベース・ベンダおよび製品と疎に結合できるようにし、データベース区画を使用するためのサポートを自己提供する。
【００５７】
アーキテクチャ２００は、アプリケーション・サーバのクラスタ化配置に好適であり、照会を適切なデータベース区画ノードにルーティングするための単一ポイント障害はない。
【００５８】
照会ルーティング論理は、アプリケーションに対してローカルであり、「正しい」リモート・データベース区画へ照会を直接ルーティングする、ＦＥ−ＲＤＢＭＳ  ２０２〜２０６と共に配置される。Ｊ２ＥＥフレームワークが区画化データベース・クラスタに対抗してトランスペアレントにアプリケーションを配置できるようにすることに加えて、性能を向上させる、このアーキテクチャ２００では、照会を分析するために特別に停止することは回避される。
【００５９】
ソリューションの組み合わせ
この２つのソリューションを組み合わせて、区画化データソースとレプリカを有する各区画とからなるクラスタを達成することが可能である。これにより、２次（second degree）のロード・バランシング、可用性、および性能利点が提供されることになる。
【図面の簡単な説明】
【００６０】
【図１】ウェブ・アプリケーションを配置するための多層アーキテクチャを示す概略ブロック図である。
【図２】ウェブ・アプリケーションを配置するための複製データベースを有するクラスタ・アーキテクチャを示す概略ブロック図である。
【図３】ウェブ・アプリケーションを配置するための区画化データベースを有するクラスタ・アーキテクチャを示す概略ブロック図である。
【図４】本発明を具体化するウェブ・アプリケーションを配置するための複製データベースを有するクラスタ・アーキテクチャを示す概略ブロック図である。
【図５】図４の実施形態を関するシーケンスを示す図である。
【図６】本発明を具体化するウェブ・アプリケーションを配置するための区画化データベースを有するクラスタ・アーキテクチャを示す概略ブロック図である。
【符号の説明】
【００６１】
１４    ブラウザ／ウェブ・サービス・クライアント
２２    アプリケーション・サーブレット
５２    ネットワーク・ディスパッチャ
５４    ノード
５６    ノード
５８    ノード
５９    アプリケーション・サーバ
６０    アプリケーション・サーバ
６２    アプリケーション・サーバ
６４    レプリカ
６６    レプリカ
６８    レプリカ
７０    マスタ
７２    データ・アクセス・レイヤ
７４    データ・アクセス・レイヤ
７６    データ・アクセス・レイヤ
７８    ネットワーク・ディスパッチャ
８２    アプリケーション論理
８４    アプリケーション・セッションＢｅａｎ
【図１】
2007234013.tif 000003
【図２】
2007234013.tif 000004
【図３】
2007234013.tif 000005
【図４】
2007234013.tif 000006
【図５】
2007234013.tif 000007
【図６】
2007234013.tif 000008