(57)【要約】本発明は、共通オブジェクトフレームワーク（ＣＯＦ）を使用したアプリケーション開発に係る。より詳細には、本発明の態様は、ＣＯＦを、規格ベースサーバー側コンポーネントモデル及びリモードメソッド呼び出しプロトコルに実質的に適合させることに係る。本発明の付加的な態様は、データベースティアー上の中間のビジネスアプリケーションティアーにおけるデータベースの水平パーティショニングに係る。ステージング、変更経歴、及びオブジェクト内のフィールドの国際化を含む組合せは、本発明の更に別の態様である。本発明の特定の態様は、特許請求の範囲、明細書本文及び添付図面に示す。
2006504194.tif 000002
【特許請求の範囲】
【請求項１】
マルチティアードカプセル化ビジネスアプリケーションのためのアプリケーション開発コードを発生する方法において、
（１）オブジェクト及び関係を視覚的にモデリングしそしてオブジェクト指向のアプリケーション設計のオペレーションを指定するステップであって、前記オブジェクト、関係及び／又はオペレーションのプロパティが、
(a)モデリングされたオブジェクトへのインターフェイスを発生すべきかどうか指示する第１プロパティ、及び
(b)指定されたオペレーションへのローカル及び／又はリモートインターフェイスを発生すべきかどうか指示する第２プロパティ、を含むようなステップと、
（２）前記プロパティを含む、視覚的モデルに対応するマシン読み取り可能なデータを発生するステップと、
（３）前記マシン読み取り可能なデータを使用して、前記視覚的モデルをデータベースへマッピングするステップと、
（４）前記マッピング及びマシン読み取り可能なデータからアプリケーション開発コードを付加的に発生するステップであって、該コードが、
(a)前記データベース内の前記モデリングされたオブジェクトを持続させ且つそれにアクセスするためのコード、
(b)前記第１プロパティと一貫した、前記オブジェクトを持続させ且つそれにアクセスするためのコードへのインターフェイス、及び
(c)前記第２プロパティと一貫した、前記指定のオペレーションへのインターフェイス、を含むようなステップと、
を備えた方法。
【請求項２】
前記アプリケーション開発コードは、Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ(登録商標)Ｂｅａｎｓ（ＥＪＢ）規格２．０以降のものに実質的に適合する、請求項１に記載の方法。
【請求項３】
前記オブジェクトを持続させ且つそれにアクセスするためのコードは、「ビーン・マネージド・パーシステンス（ＢＭＰ）」プロトコルに実質的に適合する、請求項２に記載の方法。
【請求項４】
前記アプリケーション開発コードは、「．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ」仕様に実質的に適合する、請求項１に記載の方法。
【請求項５】
前記オブジェクト指向のアプリケーション設計は、「ユニファイドモデリング言語（ＵＭＬ）」規格に実質的に適合する、請求項１に記載の方法。
【請求項６】
前記プロパティは、更に、前記マッピングステップを制御する前記オブジェクト及び関係の複数の第３プロパティを含む、請求項１に記載の方法。
【請求項７】
前記マッピングステップを制御する前記第３プロパティは、前記モデリングされたオブジェクトの配備のステージングをサポートすべきかどうかを含む、請求項６に記載の方法。
【請求項８】
前記マッピングステップを制御する前記第３プロパティは、更に、前記モデリングされたオブジェクトの配備の変更経歴を記録すべきかどうかを含む、請求項７に記載の方法。
【請求項９】
前記オブジェクトのプロパティは、更に、フィールドを国際化するために前記モデリングされたオブジェクト内に１つ以上のフィールドを動的に配列すべきかどうか指示する１つ以上の第４プロパティを含む、請求項１に記載の方法。
【請求項１０】
前記オブジェクトを持続させ且つそれにアクセスするためのコードは、指定された言語に基づいて前記動的配列のどのエレメントを検索すべきか分析する、請求項９に記載の方法。
【請求項１１】
ユーザは、何を発生すべきか指定し、そして前記マシン読み取り可能なデータを発生し、マッピングしそして付加的に発生する前記ステップは、ユーザによる更なるアクションを必要とせずに行なわれる、請求項１に記載の方法。
【請求項１２】
前記データベースは関係データベースである、請求項１に記載の方法。
【請求項１３】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブルする方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させるメソッドのオブジェクト指向のフレームワークを設けるステップと、
規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合するオブジェクト指向のフレームワークのバージョンを付加的に設けるステップと、
前記オブジェクト指向のフレームワーク、及びそのオブジェクト指向のフレームワークの規格適合バージョンにより、１つ以上のデータベースに同時に向けられたトランザクション関連アクティビティを受け入れるステップと、
を備えた方法。
【請求項１４】
前記規格は、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）である、請求項１３に記載の方法。
【請求項１５】
前記規格は、「ディストリビューテッド・コモン・オブジェクト・モデル（ＤＣＯＭ）」である、請求項１３に記載の方法。
【請求項１６】
前記規格は、ＣＯＲＢＡである、請求項１３に記載の方法。
【請求項１７】
前記受け入れステップは、オブジェクトをバッファすることを含み、更に、トランザクションをコミットする指令の際に、トランザクションを処理するためのデータベースマネージャーを呼び出すことを含む、請求項１４に記載の方法。
【請求項１８】
前記受け入れステップは、オブジェクトをバッファすることを含み、更に、トランザクションをコミットする指令の際に、トランザクションを処理するためのデータベースマネージャーを呼び出すことを含む、請求項１５に記載の方法。
【請求項１９】
前記受け入れステップは、オブジェクトをバッファすることを含み、更に、トランザクションをコミットする指令の際に、トランザクションを処理するためのデータベースマネージャーを呼び出すことを含む、請求項１６に記載の方法。
【請求項２０】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブリング(assembling)する方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させるメソッドのオブジェクト指向のフレームワークを設けるステップと、
ＥＪＢ規格適合取り扱い及び呼び出しに適応されたオブジェクト指向のフレームワークのバージョンを付加的に設けるステップと、
前記オブジェクト指向のフレームワーク、及びそのオブジェクト指向のフレームワークのＥＪＢ規格適合バージョンにより、１つ以上のデータベースに同時に向けられたトランザクション関連アクティビティを受け入れるステップと、
を備えた方法。
【請求項２１】
前記受け入れステップは、オブジェクトをバッファすることを含み、更に、トランザクションをコミットする指令の際に、トランザクションを処理するためのデータベースマネージャーを呼び出すことを含む、請求項２０に記載の方法。
【請求項２２】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブルする方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させるメソッドのオブジェクト指向のフレームワークを設けるステップと、
ＤＣＯＭ仕様適合取り扱い及び呼び出しに適応されたオブジェクト指向のフレームワークのバージョンを付加的に設けるステップと、
前記オブジェクト指向のフレームワーク、及びそのオブジェクト指向のフレームワークのＤＣＯＭ仕様適合バージョンにより、１つ以上のデータベースに同時に向けられたトランザクション関連アクティビティを受け入れるステップと、
を備えた方法。
【請求項２３】
前記受け入れステップは、オブジェクトをバッファすることを含み、更に、トランザクションをコミットする指令の際に、トランザクションを処理するためのデータベースマネージャーを呼び出すことを含む、請求項２２に記載の方法。
【請求項２４】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブリング(assembling)する方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させるメソッドのオブジェクト指向のフレームワークを設けるステップと、
ＣＯＲＢＡ適合取り扱い及び呼び出しに適応されたオブジェクト指向のフレームワークのバージョンを付加的に設けるステップと、
前記オブジェクト指向のフレームワーク、及びそのオブジェクト指向のフレームワークのＣＯＲＢＡ適合バージョンにより、１つ以上のデータベースに同時に向けられたトランザクション関連アクティビティを受け入れるステップと、
を備えた方法。
【請求項２５】
前記受け入れステップは、オブジェクトをバッファすることを含み、更に、トランザクションをコミットする指令の際に、トランザクションを処理するためのデータベースマネージャーを呼び出すことを含む、請求項２４に記載の方法。
【請求項２６】
少なくとも１つのデータベースマネージャーにより処理されるデータを持続させる方法において、
前記データベースマネージャーによりデータにアクセスし且つそれを持続させるメソッドのオブジェクト指向のフレームワークを設けるステップと、
前記データベースマネージャーによりデータにアクセスし且つそれを持続させる前記メソッドへのＥＪＢ規格適合インターフェイスを設けるステップと、
前記オブジェクト指向のフレームワーク及び前記ＥＪＢ規格適合インターフェイスにより、１つ以上のデータベースに同時に向けられたオブジェクトアクセス及び持続要求を受け入れるステップと、
を備えた方法。
【請求項２７】
前記オブジェクト要求は、それらがオブジェクト指向のフレームワークを経てなされたか又はＥＪＢ規格適合インターフェイスを経てなされたかに関わらず、Ｊａｖａトランザクションサービスエンジンへ提出される、請求項２６に記載の方法。
【請求項２８】
前記オブジェクト指向のフレームワークは、前記ＥＪＢ規格適合インターフェイスを伴わずに、微粒状オブジェクトを持続させるように適応され、そして上記ＥＪＢ規格適合インターフェイスは、微粒状オブジェクトを持続させるように適応され、更に、上記ＥＪＢ規格適合インターフェイスは、２つ以上のデータベースへのトランザクションにおいてオブジェクトを持続させるように適応される、請求項２６に記載の方法。
【請求項２９】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブリング(assembling)する方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させると共に、テスト及び製造システムへの追加のためにオブジェクトをステージングもするメソッドのオブジェクト指向のフレームワークを設けるステップと、
規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合するオブジェクト指向のフレームワークのバージョンであって、オブジェクトのステージングを含むバージョンを付加的に設けるステップと、
を備えた方法。
【請求項３０】
前記規格は、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）である、請求項２９に記載の方法。
【請求項３１】
前記規格は、「ディストリビューテッド・コモン・オブジェクト・モデル（ＤＣＯＭ）」である、請求項２９に記載の方法。
【請求項３２】
前記規格は、ＣＯＲＢＡである、請求項２９に記載の方法。
【請求項３３】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブリング(assembling)する方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させると共に、製造システムにおけるオブジェクトの変更経歴を追跡もするメソッドのオブジェクト指向のフレームワークを設けるステップと、
規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合するオブジェクト指向のフレームワークのバージョンであって、前記変更経歴の追跡を含むバージョンを付加的に設けるステップと、
を備えた方法。
【請求項３４】
前記規格は、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）である、請求項３３に記載の方法。
【請求項３５】
前記規格は、「ディストリビューテッド・コモン・オブジェクト・モデル（ＤＣＯＭ）」である、請求項３３に記載の方法。
【請求項３６】
前記規格は、ＣＯＲＢＡである、請求項３３に記載の方法。
【請求項３７】
トランザクションの処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブリング(assembling)する方法において、
前記データベースマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させると共に、フィールドを国際化するためにオブジェクト内にフィールドを動的に配列もするメソッドのオブジェクト指向のフレームワークを設けるステップと、
規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合するオブジェクト指向のフレームワークのバージョンであって、フィールドを国際化するためにフィールドを動的に配列することを含むバージョンを付加的に設けるステップと、
を備えた方法。
【請求項３８】
前記規格は、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）である、請求項３３に記載の方法。
【請求項３９】
前記規格は、「ディストリビューテッド・コモン・オブジェクト・モデル（ＤＣＯＭ）」である、請求項３３に記載の方法。
【請求項４０】
前記規格は、ＣＯＲＢＡである、請求項３３に記載の方法。
【請求項４１】
水平にパーティショニングされるマルチティアードビジネスアプリケーション内でデータベースを発生する方法において、
オブジェクト及び関係をモデリングしそしてオブジェクト指向のアプリケーション設計のオペレーションを指定するステップであって、前記オブジェクトのプロパティが、多数のデータベースにわたりオブジェクトを水平にパーティショニングすべきかどうかを含むようなステップと、
前記プロパティを含む、モデルに対応するマシン読み取り可能なデータを発生するステップと、
前記マシン読み取り可能なデータを使用して、前記モデルを複数のデータベースへマッピングするステップと、
前記マッピング及びマシン読み取り可能なデータからアプリケーション開発コードを付加的に発生するステップであって、該コードは、前記複数のデータベースにわたり前記オブジェクトを持続させ且つそれにアクセスするためのコードを含み、更に、前記オブジェクトを持続させ且つそれにアクセスするための前記コードがデータベースティアーの上の中間プログラムティアーであるようなステップと、
を備えた方法。
【請求項４２】
前記オブジェクトをパーティショニングするところの複数のデータベースを宣言すると共に、前記複数のデータベースの間で前記オブジェクトを特定のデータベースへとパーティショニングするのに使用される前記オブジェクトの１つ以上のフィールドを宣言するステップを更に備えた、請求項４１に記載の方法。
【請求項４３】
少なくともデータベースティアー及び中間のビジネスアプリケーションティアーを含むマルチティアードビジネスアプリケーションにおいて多数の独立したデータベースにわたりオブジェクトの水平パーティショニングを実施する方法において、
特定のオブジェクトを特定のデータベースに指定するのに使用できる少なくとも１つの水平にパーティショニングされたオブジェクトにおいて１つ以上のフィールドを宣言するステップと、
前記水平にパーティショニングされたオブジェクトが属することのできる複数のデータベースとの接続を確立するステップと、
前記水平にパーティショニングされたオブジェクトを含む、探索又は形成すべき１つ以上のオブジェクトをバッファするステップと、
前記探索又は形成を進行させる指令の際に、前記オブジェクトが属する特定のデータベースを、前記宣言されたフィールドを使用して分析すると共に、前記データベースティアーにおいて前記特定のデータベースを呼び出して、前記探索又は形成を実行するステップと、
を備えた方法。
【請求項４４】
少なくともデータベースティアー及び中間のビジネスアプリケーションティアーを含むマルチティアードビジネスアプリケーションにおいて多数の独立したデータベースにわたりオブジェクトの水平パーティショニングを実施する方法において、
少なくとも１つの前記水平にパーティショニングされたオブジェクトが属することのできる複数のデータベースとの接続を確立するステップと、
前記水平にパーティショニングされたオブジェクトが属する特定のデータベースを設定するステップと、
前記設定ステップの前又は後に、前記水平にパーティショニングされたオブジェクトを含む、探索又は形成すべき１つ以上のオブジェクトをバッファするステップと、
前記探索又は形成を進行させる指令の際に、前記データベースティアーにおいて前記特定のデータベースを呼び出して、前記探索又は形成を実行するステップと、
を備えた方法。
【請求項４５】
前記複数のデータベースは、単一の論理名で集合的に参照され、更に、前記複数のデータベース間の特定のデータベースが１つ以上の付加的な属性へと論理的にマップされる、請求項４４に記載の方法。
【請求項４６】
前記付加的な属性は、前記水平にパーティショニングされたオブジェクトのフィールドである、請求項４５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共通オブジェクトフレームワーク（ＣＯＦ）を使用するアプリケーション開発に係る。より詳細には、本発明の態様は、ＣＯＦを、規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合させることに係る。本発明の付加的な態様は、データベースティアー(tier：層)上の中間のビジネスアプリケーションティアーにおけるデータベースの水平パーティショニングに係る。ステージング、変更経歴、及びオブジェクト内のフィールドの国際化を含む組合せは、本発明の更に別の態様である。本発明の特定の態様は、特許請求の範囲、以下の説明及び添付図面に示す。
【０００２】
（著作権について）
本特許文書の開示の一部分は、著作権保護を受ける資料を含んでいる。本著作権所有者は、任意の者が特許文書又は特許の開示を特許商標庁の特許ファイル又は記録に現われるように複写再現することに異議を唱えないが、その他の全ての著作権権利を留保するものとする。
【背景技術】
【０００３】
マルチティアード(multi-tiered)アプリケーションは、ビジネスロジックを、分散型の信頼性及び拡張性のあるやり方で配備するための一般的な解決策となってきている。マルチティアードシステムでは、システムサービスティアーがデータベース、トランザクション及び他のインフラストラクチャーを与える。中間ティアーは、ビジネスロジックへのアクセスを与える。クライアントティアーは、ビジネスロジックにアクセスする。クライアントティアーは、貧弱な又は精巧なクライアントをもつユーザでもよいし、或いはウェブサービスクライアントのようなプログラムでもよい。マルチティアードアプリケーションは、単一アプリケーションプラットフォームから多数のカスタマーをサポートするのに特に有用である。マルチティアードアプリケーションは、コードの再使用及び拡張を含む利点を伴い、多数のカスタマーに対して同様にフォーマットされたデータを取り扱うように適応させることができる。
【０００４】
Ｊ２ＥＥ及びＥｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）Ｂｅａｎｓ（ＥＪＢ）は、マルチティアード環境においてデータ管理メカニズムと一体化して、ビジネスロジックをカプセル化しそしてサービスするためのアーキテクチャーとして出現した。アプリケーションサーバーは、システムサービス及びインフラストラクチャーへのアクセスを与える。アプリケーションサーバーは、ビジネスロジック及びデータの両方をカプセル化するオブジェクトの記憶及び持続性を管理する。一般に、Ｓｕｎ、Ｓｉｍｐｌｉｆｉｅｄ Ｇｕｉｄｅ ｔｏ ｔｈｅ ＪａｖａTM ２ Ｐｌａｔｆｏｒｍ、Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（１９９９）を参照されたい。マイクロソフトの競合アーキテクチャーは、「．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ  ａｎｄ  ＤＣＯＭ．」、Ｍｏｎｓｏｎ−Ｈａｅｆｅｌ、Ｒｉｃｈａｒｄ、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ  ３ｄ  Ｅｄ、ｐ１７、Ｏ’Ｒｅｉｌｌｙ（２００１）として知られている。幾つかの同様の特性を有する古いフレームワークは、ＣＯＲＢＡとして知られている。
【０００５】
マルチティアードカプセル化ビジネスアプリケーションのライフサイクルは、初期の開発及びその後の保守の両方を含む。（この点について、ビジネスアプリケーションは、いわゆるビジネスロジックが存在する１つ以上の中間ティアーを含む商業的及び非商業的アプリケーションを含むように使用される。）マルチティアードカプセル化ビジネスアプリケーションの初期の開発は、視覚的オブジェクト指向の分析及びモデリングツールで始まり、オブジェクト対関係データベースマッピングプロセスを経て進行し、そしてマルチティアードカプセル化ビジネスアプリケーションとして配備される。保守は、更新されたビジネスアプリケーションコンポーネントのステージング及び配備を含んでもよい。配備は、製品名及び記述のような動的データの国際化（Ｉ１８Ｎ：「ｉ」及び「ｎ」とそれらの間の１８文字、として省略される）を必要とする。
【０００６】
初期の開発に使用されるツールは、ユニファイドモデリング言語（ＵＭＬ）に適合し、そしてそれが使用するアプリケーション及びデータのオブジェクト指向のモデルを発生する視覚的分析及びモデリングツールを含む。レーショナル・ローズ(Rational Rose)は、リーディング視覚的分析及びモデリングツールである。他の製品は、ＩＢＭのＶｉｓｕａｌＡｇｅ、ボーランドのＥｎｔｅｒｐｒｉｓｅＳｔｕｄｉｏ及びＮｅｕＶｉｓのＮｅｕＡｒｃｈｉｔｅｃｔを含む。視覚的分析及びモデリングには、Ｖｉｓｉｏ又はＦｌｏｗｃｈａｒｔｅｒのようなドラフティングツールが使用されてもよい。
【０００７】
また、ＯＲツールを開発に使用して、オブジェクト指向のモデルを関係データベースにマッピングすることもできる。ＴｏｐＬｉｎｋは、オブジェクト指向のモデルを関係データベースにマッピングするためのリーディングツールであった。競合ツールが、サンマイクロシステムズ、ＩＢＭ、ボーランド、オラクル、マイクロソフト、ソート・インク、及びチブコにより製造されている。あるＯＲマッピング能力を含むモデリングツールは、一般に非常に制約があり、ある範囲の使用可能なデータベースをサポートするように良好に適応されない。
【０００８】
マルチティアードカプセル化ビジネスアプリケーションのためのアプリケーションサーバーは、Ｊ２ＥＥ規格又は同様の規格に適合し得る。Ｊ２ＥＥ及びＥＪＢ２．０のためのアプリケーションサーバーは、サン、ＪＢｏｓｓ．ｏｒｇ、ボーランド、ＩＢＭ、ＢＥＡシステムズ、ワープソルーションズ、マイクロメディア、オラクル、及びその他多数により提供されている。アプリケーションサーバーは、オラクル、マイクロソフト、ＩＢＭ、シーベル、サイベース、その他により提供されるデータベースを含む種々の持続性のためのデータベースに依存し得る。
【０００９】
入手可能なツールの２つの欠点とは、保守及び配備に有用な特徴に対しその一体化に制約があることと、そしてそのサポート性に欠けることである。一体化に制約があるとは、視覚的分析及びモデリングツールで開発されてＯＲツールでマッピングされたアプリケーションが、マルチティアードカプセル化ビジネスアプリケーション配備のための競合規格の１つに適合するように、ユーザがデータを再入力するか又は詳細なプログラミングガイドラインに従う必要があることを意味する。開発者が既存のツールを使用して手動で行う必要がないようにサポートすることが有用な特徴には、ステージング、配備の経歴、及び動的データの国際化を含む。ステージングとは、新たなモジュールをライブデータに対してテストし、そしてそのテストされたモジュールを配備することを含む。経歴とは、配備を記録すると共に、任意であるが、新たなモジュールのステージング及び／又はテスティングを記録することを指す。動的データの国際化とは、付加的なフィールド及びテーブルの追加をサポートし、１つ以上のベース言語又は国々に追加されるべき言語又は国々を指定することで動的データの外国言語変換をサポートするものである。
【００１０】
現在のシステムで明らかでない望ましい特徴は、互いに独立した多数の物理的データベース、及びオラクルデータベースやＳＱＬサーバー２０００のような異なる売主のプラットホームに構築されたデータベース内でデータを探索できるように、中間ティアーにおいてデータを水平にパーティショニングすることである。以下、バージョン「２０００」を参照として使用するが、本発明の態様を実施するのに使用できるソフトウェアのバージョンに対して制約を示唆するものではない。データベースの売主により供給される既存の水平パーティショニング機構は、単一の厳密に管理されたシステム内の多数の物理的ボリュームを、全て売主のデータベースマネージャーの制御のもとで使用する。
【００１１】
水平パーティショニング技術の例については、クレイン氏の米国特許第６，４５３，３１３号、「Database Management System and Method for Dequeuing Rows Published to a Database Table」（１９９２年）；ローマン氏等の米国特許第６，１１２，１９８号、「Optimization of Data Repartitioning During Parallel Query Optimization」（２０００年）；バルー氏等の米国特許第５，９７０，４９５号、「Method and Apparatus for Achieving Uniform Data Distribution in a Parallel Database System」（１９９９年）を参照されたい。クレイン氏が説明するように、クラスターにおけるノード及び装置を横切って計算負荷をスケーリングしそして分配するのに、大きなデータベーステーブルの透過的（トランスペアレントな）水平パーティショニングが使用される。水平パーティショニングとは、テーブルを２つ以上のファイルに分割即ちパーティショニングし、各パーティションが、対応する範囲のキー値を有する記録（タプル）を記憶することを意味する。例えば、カスタマーテーブルの２つ以上のパーティションの各々は、対応する範囲の文字Ａ−Ｌで始まるカスタマー名に対応する記録に対して使用されてもよい。又、テーブルは、ハッシュ値に基づいてパーティショニングすることもできる。例えば、記録インデックスのハッシュ値を使用すると、Ｎ（例えば、４）個の値のいずれかをもつことができ、テーブルをＮ個のパーティションに分割することができ、ハッシュ関数を使用して、各テーブル行が記憶されるパーティションが決定される。更に、各パーティションは、システムにおける計算付加の分配を容易にするためにシステムの異なるノード又は物理的装置に記憶されてもよい。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
水平パーティショニングを、データベースマネージャーではなく、中間ティアーへ一体化することは、同じアプリケーションで多数のカスタマーをサポートするのに有用である。透過的（トランスペアレントな）水平パーティショニングサポートは、より多くのカスタマーが追加されるか又はデータベースが再パーティショニングされるときに、開発者がそれらのビジネスロジックに再びアクセスする(revisit)ことを解放する。
【００１３】
そこで、マルチティアードカプセル化ビジネスアプリケーションの配備及び保守により視覚的分析及びモデリングから種々のステージにおいて開発を良好にサポートしそして一体化するための機会が生じることになる。
【課題を解決するための手段】
【００１４】
本発明は、共通オブジェクトフレームワーク（ＣＯＦ）を使用するアプリケーション開発に係る。より詳細には、本発明の態様は、ＣＯＦを、規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合させることに係る。本発明の付加的な態様は、データベースティアー上の中間のビジネスアプリケーションティアーにおけるデータベースの水平パーティショニングに係る。ステージング、変更経歴、及びオブジェクト内のフィールドの国際化を含む組合せは、本発明の更に別の態様である。本発明の特定の態様は、特許請求の範囲、以下の説明及び添付図面に示す。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面を参照して、本発明を詳細に説明する。好ましい実施形態は、本発明を例示するものであって、特許請求の範囲に規定されたその範囲を限定するものではない。当業者であれば、以下の説明から、種々の同等の変更が理解されよう。
【００１６】
図１は、本発明の一実施形態において使用することのできる、サン(Sun)をスポンサーとするＪ２ＥＥ及びＥＪＢ規格を示している。ボドフ氏等の「The J2EE Tutorial」、第１０ページ、アディソン・ウェズリー（２００２年）を参照されたい。サンは、図１のブロックを次のように説明している。Ｊ２ＥＥサーバー１２０は、Ｊ２ＥＥ製品を実現したものである。Ｊ２ＥＥサーバーは、ＥＪＢ１２５及びＷｅｂ１２１コンテナを与え、そしてバックエンドデータベースレイヤー１３０へのアクセスを管理する。Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）コンテナ１２５は、Ｊ２ＥＥアプリケーションのためのエンタープライズビーンズの実行を管理する。エンタープライズビーンズ１２６、１２７及びそれらのコンテナ１２５は、Ｊ２ＥＥサーバー１２０において実行される。ウェブコンテナ１２１は、Ｊ２ＥＥアプリケーションのためのＪＳＰページ１２３及びサーブレット１２２コンポーネントの実行を管理する。ウェブコンポーネント１２２、１２３及びそれらのコンテナ１２１は、Ｊ２ＥＥサーバー１２０において実行される。アプリケーションクライアントコンテナ１１３は、アプリケーションクライアント１１２コンポーネントの実行を管理する。アプリケーションクライアント１１２及びそれらのコンテナ１１３は、クライアント１１０において実行される。アプレットコンテナは、アプレットの実行を管理する。これは、クライアント１１０において実行されるウェブブラウザ１１１及び１つ以上のＪａｖａプラグインを含む。
【００１７】
より一般的には、図１は、規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルを示す。マイクロソフト「．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ」及びＣＯＲＢＡは、同様のコンポーネントを含む。Ｍｏｎｓｏｎ−Ｈａｅｆｅｌ、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ、第５−１８ページ。本発明の態様は、ここに示すバージョン又はその後の時点或いは本出願の提出時点における規格のバージョン又はその派生したものに適合する際に、規格に適合するとみなす。完全な適合を必要とせず、実質的な適合であっても有用である。規格との完全な適合は、規格の特徴の実施を要求することが時としてあるが、これは、不必要であり、高価過ぎて流動的とみなされる。加えて、ある実施は、製品を改善するときに導入され得る私有的特徴であって、規格が発展しそしてカスタマーが旧型の支持を主張するときに非標準的となり得る私有的特徴を含むことになると考えられる。規格とは、ＥＪＢのような委員会が管理する仕様、及び「．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ」のような売主が管理する仕様の両方を網羅することを意味する。
【００１８】
図２は、ＥＪＢオンＪ２ＥＥサーバーを使用して共通オブジェクトフレームワークをいかに実施して中間ティアーを与えるかを示す。図のコンポーネントの多くは、図１のコンポーネントに一致し、適宜に番号が付けられている。図２において、ウェブコンテナのコンテンツ及びエンタープライズビーンズの１つを説明する。ウェブコンテナ１２１において、アプリケーションは、共通オブジェクトフレームワーク（ＣＯＦ）２４０Ａと、ロールアプリケーション２４１と、ウェブサービスエンジン２４２と、コラボレーティブプロセスマネージャー２４３とを備えている。ＣＯＦは、持続するオブジェクトをサポートし且つそこへのアクセスを与え、ロールアプリケーション２４１の開発者が持続、トランザクション管理、及び関連タスクを取り扱う必要性を低減する。ＣＯＦは、任意であるが、本出願及び参考として取り上げる出願に記述された方法を適用して、ステージング、変更経歴、国際化及び水平パーティショニングをサポートしてもよい。ウェブサービスエンジン２４２及びコラボレーティブプロセスマネージャーは、ウェブサービスを提供するためにコマース・ワン(Commerce One)により使用されるコンポーネントであり、ウェブコンテナ内のこれらアプリケーションの詳細は、本発明とって重要ではない。しかしながら、コラボレーティブプロセスマネージャー２４３をＣＯＦ２４０Ａに接続する実線矢印と、ＣＰＭ２４３をＣＯＦ２４０Ｂ及びＥＪＢ１２７へ接続する点線は、ＥＪＢコンテナ１２４により提供されるサービス及びデータサポートを、ウェブコンテナ１２１内のＣＯＦ２４０Ａから利用できるサービスに置き換えるオプションを示す。ウェブコンテナ１２１及びエンタープライズビーン１２６内のＣＯＦコードを２４０Ａ、２４０Ｂとして同様に表示することは、ＣＯＦコードをほとんど又は全く再書き込みせずに、ＣＯＦコードを、ＥＪＢ処理のために、ＥＪＢ適合インターフェイスでラップできることを指示する。図示されたように、ＣＯＦは、ウェブコンテナ又はＥＪＢコンテナの各々で利用することができる。アプリケーションは、両コンテナにおいてＣＯＦコンポーネントにアクセスすることができる。アプリケーションは、ＣＯＦコンポーネントの両セットと同時にアクティブなセッションをもつことができる。図２は、ＥＪＢ環境に関してこの実施を示しているが、当業者であれば、ＤＣＯＭのような別の規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに同じ解決策を適用できることが明らかであろう。
【００１９】
いわゆる共通オブジェクトフレームワークは、ビジネスオブジェクトの全ソフトウェアライフサイクルを管理するための基本的実施及びツールを与え、これは、ここに取り上げる出願に詳細に説明されている。これは、透過的（トランスペアレントな）国際化、ステージング、変更経歴、及びカスタム属性を含む設計、ＵＭＬモデル、完全コード及びデータベース世代を備えている。コード、データ、及びデータベース独立のスキーマを継続維持するためのツールが設けられる。共通オブジェクトフレームワークコンポーネントは、ユーティリティライブラリー、ビジネスオブジェクトフレームワーク及びシステム管理ツールを含むカテゴリーに入る。ユーティリティライブラリーコンポーネントは、エクセプション（国際化された）、ロギング、暗号化及びコンフィギュレーションアクセスのような共通コードレベルユーティリティを含む。又、これは、リソースマネージャー、日付、数字及びテキストのような国際化機能も含む。ビジネスオブジェクトフレームワークは、ビジネスオブジェクトの設計、持続性のためのコードの発生、国際化、データステージング、バージョン経歴、動的カスタム属性、及び全形成／読み取り／更新／削除（ＣＲＵＤ）機能のために使用される。フレームワークに含まれるのは、ビジネスオブジェクトの拡張性、多数のサービスにわたるキャッシュ同期、及びスケジューラーのサポートである。
【００２０】
システム管理ツールは、ビジネスオブジェクトフレームワークをベースとする。これらは、データベースを生成し、データをロードし、データベーススキーマをアップグレードし、そしてデータの解除変更をアップグレードするためのデータ管理ツールを含む。又、国際化及び局所化キットのためのエクストラクター及びインストーラーもある。
【００２１】
ＥＪＢ適合ＣＯＦ又は規格適合ＣＯＦは、種々のソフトウェアコンポーネントにより実施されそしてそれと相互作用することができる。オブジェクトモデルの設計及びコード又はメタデータ（マシン読み取り可能なデータ）の発生は、「レーショナル・ローズ(Rational Rose)２００１ａ」以上のもので実施することができる。これ以降、バージョン「２００１ａ」も参考として使用するだけで、本発明の態様を実施するのに使用できるソフトウェアのバージョンをこれに限定するものではない。「レーショナル・ローズ」を使用するときには、図４及び５に示して以下に説明する機能を与えるためにアドイン(add-in)がインストールされる。データベースは、ＴｏｐＬｉｎｋ３．６．１、ＳＱＬサーバー２０００、Ｏｒａｃｌｅ８．１．７、又はＤＢ２、及び適当なＪＤＢＣドライバ、例えば、Ｉ−ｎｅｔ  ＯＰＴＡ４．１５、Ｓｅｒｏｐｔ又はＩＤＳ  ＪＤＢＣ  Ｌｉｔｅ３．５．４を使用して、マップし、形成し、そしてアクセスすることができる。ＷｅｂＳｐｈｅｒｅ及びＷｅｂＬｏｇｉｃ７．０のようなＥＪＢを使用してもよい。
【００２２】
ＥＪＢ適合ＣＯＦの新規なそして改善されたモデルを多数の有用なやり方で組み合わせることができる。これらのモデルは、ＣＯＦオブジェクトにアクセスしてＥＪＢとして使用できるように、リモート及びローカルＥＪＢインターフェイスを発生する。それらは、ＴｏｐＬｉｎｋ４．０をＯＲマッピングツールとして使用してオブジェクトを見出すために問合せ言語としてＥＪＢ−ＱＬへのアクセスを与える。それらは、多数のデータベースへの同時アクセス及びデータの水平パーティショニングをサポートすることを含むデータベースサーバーセッションを管理する。データベースにわたる関係は、サポートすることができない。それらは、オブジェクトへのアプリケーションアクセスに対してクライアントセッションを与える。それらは、失われたデータベース接続に対する構成可能な再試みメカニズムを与える。それらは、ＥＪＢ  ＪＴＡベースのトランザクション、及びデータベースサーバーにわたって独特である独自の連結オブジェクトＩＤとの一体化をサポートし、データベース移動にわたりオブジェクトＩＤを保存すると共に、水平パーティショニングを実施する。
【００２３】
オブジェクト変更事象通知は、オブジェクト形成、更新及び削除のために構成可能な事象として発生される。後オブジェクト形成、前オブジェクト更新、後オブジェクトリフレッシュ、及び前オブジェクト削除のために、実施されたオブジェクトに対してコールバックが与えられる。レーショナル・ローズに対して設計及びコード発生ツールが設けられる。データベース形成ツールは、視覚的にモデリングされた設計に基づいてデータベース又はＤＤＬスクリプトを発生する。ツールは、発生されたＥＪＢに対するアプリケーションサーバー配備記述子を発生する。ＷｅｂＬｏｇｉｃ６．１ｓｐ２及びＷｅｂＳｐｈｅｒｅ５．０（ＥＪＢ２．０仕様のサポートを必要とする）に対するサポート。
【００２４】
図３は、視覚的にモデリングされた単純なショッピングカートアプリケーションのためのオブジェクト及び関係を示す。この図のモデルは、クラス図に対して独特のモデリング言語（ＵＭＬ）表示を使用して形成されたものである。この例では、ＣｍｓＣａｒｔオブジェクト３０１を使用して、多数の露呈されたメソッドが与えられる。ＣｍｏＣａｒｔオブジェクトに代わってＣｍｓＣａｒｔを使用することは、オブジェクトがあるセッション中存在するが、その後のセッション中には、持続するカスタマー及びオーダーとは対照的に、持続しないことを意味する。カート３０１は、オーダー３１１により、ＣｍｏＯｒｄｅｒオブジェクト３０３に関連付けられる。この例では、１つのオーダーオブジェクトがショッピングカートに関連付けられる。ＣｍｏＯｒｄｅｒオブジェクト３０３は、完了時に、ＣｍｏＣｕｓｔｏｍｅｒオブジェクト３０２を経てカスタマー３１３に関連しなければならない。関係の逆方向に沿って、持続カスタマー３０２は、２つ以上のオーダー３０３に関連してもよい（３１２）。オーダー３０３は、１つ以上のＣｍｏＰｒｏｄｕｃｔＬｉｎｅＩｔｅｍオブジェクト３０５を含む。関係アイテム３１４は、オーダー３０３をそのラインアイテム３０５に接続する。ラインアイテム３０５には製品３０４が充填され、これら製品は、製品３１５関係によりラインアイテムに接続される。
【００２５】
ＵＭＬでは、ショッピングカートのようなオブジェクトは、クラスとしてモデリングされてもよい。デフォールトにより、本発明の一実施形態における全てのトップレベル（即ち、非親クラス）持続オブジェクトは、図５について以下に述べるように、ＣｍｏＢａｓｅと称されるベースオブジェクトから継承する。或いは又、ＣｍｓＢａｓｅと称されるオブジェクトから、過渡的(transient)オブジェクトが継承されてもよい。ベースオブジェクトは、ＣＡＴ（又はユニット）ファイルに設けられてもよく、このファイルは、オブジェクトモデリングプログラムにロードされて、他のクラスで参照することができる。ベースクラスの目的は、共通のインターフェイス及び実施を介して全てのオブジェクトに対する基本的機能を与えることである。
【００２６】
オブジェクトモデリングプログラムでＵＭＬフォーマットにおいてクラスをモデリングすることは、次のステップを含む。先ず、クラスがどこに存在すべきか及びそれがどこで発生されるかのディレクトリ構造を指定するためにパッケージハイアラーキーが形成される。次いで、クラス名、クラスドキュメンテーション、及びクラスプロパティを指定することができる。サポートされるクラスプロパティは、次のものを含む。即ち、持続、過渡、抽象、発生コード、データベーステーブル名、イズ・ステージアブル(Is Stageable)、最大バージョン数(Max Num of Versions)、テーブルレベルデータベース制約（複合固有制約のような）、イズ・ディスプレイド・インＧＵＩ(Is Displayed in GUI)、ディスプレイ名、ディスプレイ記述、発生(Generate)、及びＧｅｎｅｒａｔｅＥＪＢ。これらは、図４に示して以下に説明するツールを使用する。
【００２７】
次いで、クラスの属性を指定することができる。属性名、形式、ドキュメンテーション、データベースカラム名、データベースカラム長さ、許容null値、及び属性が固有であるかどうかを指定することができる。更に、属性は、静的、最終的及び／又は過渡的である。属性は、サブクラス及び反射コードでそれらにアクセスできるように保護されて定義されてもよい。しかしながら、他のクラス及びアプリケーションは、ゲッター及びセッターメソッドによらなければ、それらにアクセスできない。次の属性形式がサポートされる。ｉｎｔ、ｂｏｏｌｅａｎ、ｆｌｏａｔ、ｌｏｎｇ、ｓｈｏｒｔ、ｄｏｕｂｌｅ、ｃｈａｒ、Ｓｔｒｉｎｇ、Ｄａｔｅ、Ｔｉｍｅ、Ｔｉｍｅｓｔａｍｐ、Ｉｎｔｅｇｅｒ、Ｂｏｏｌｅａｎ、Ｆｌｏａｔ、Ｌｏｎｇ、Ｓｈｏｒｔ、Ｄｏｕｂｌｅ、ＢｉｇＩｎｔｅｇｅｒ、ＢｉｇＤｅｃｉｍａｌ、Ｃｈａｒａｃｔｅｒ、Ｏｂｊｅｃｔ、ｂｙｔｅ、Ｂｙｔｅ、ｃｈａｒ、ｃｈａｒａｃｔｅｒ、ＥｎｃｒｙｐｔｅｄＳｔｒｉｎｇ、ＨａｓｈｅｄＳｔｒｉｎｇ、及びＴｒａｎｓｌａｔａｂｌｅＳｔｒｉｎｇ。
【００２８】
これらの形式は、Ｊａｖａベース形式に適切にマップされ、これらは、データベース特有の形式にマップされてもよい。Ｏｂｊｅｃｔ、ｂｙｔｅ及びＢｙｔｅは、バイトのストリームを記憶するために、データベースにおいてＢＬＯＢ形式へとマップされてもよい。ｃｈａｒ及びｃｈａｒａｃｔｅｒは、大きなキャラクタストリームを記憶するためにデータベースにおいてＣＬＯＢ形式へとマッピングされてもよい。ＥｎｃｒｙｐｔｅｄＳｔｒｉｎｇ及びＨａｓｈｅｄＳｔｒｉｎｇ形式は、特殊な形式で、単にストリングであるが、発生されるコードは、属性を設定する前に値を暗号化／ハッシュし、そしてゲッター及びセッターメソッドにより属性を返送するときに値を暗号解読するものである。ＴｒａｎｓｌａｔａｂｌｅＳｔｒｉｎｇ属性も、単なるストリングであるが、発生されるコードは、その属性の変換値を表わすためのカラムをもつ付加的なテーブルも発生する。これは、データベースに記憶されるオブジェクト値の局所化をサポートするためにその属性の多数の変換値が存在できることを示すように、あるクラスの特定の属性を指定できるようにする。
【００２９】
次いで、あるクラスの関係を指定することができる。ＵＭＬにおいて、あるオブジェクトから他のオブジェクトへの矢印をもつ線を使用して、関係(relationship)又は関連性(association)を指定する。この関連性の各側をロールと称する。ロール名は、関連性の「から(from)」側のクラスにおいて属性名と等価である。ロールは、保護された制御のものでなければならない（属性と同様に）。各ロールは、多数のものを指定できる。「０．．１」、「１」及び「０．．＊」がサポートされる。「０．．１」は、そのロール側におけるオブジェクトの０又は１のインスタンスがその関係になり得ることを指定する。同様に、「１」は、そのロール側におけるオブジェクトの厳密に１のインスタンスがその関係になければならないことを指定する（通常、その関係の「から」側におけるクラスの関連性を表わすカラムに対するnull以外の制約を意味する）。又、「０．．＊」は、オブジェクトの０以上のインスタンスがその関係になり得ることを指定する。これは、関連付けられたオブジェクトの集合を含む関係と同等である。
【００３０】
関係は、両方向性でもよい。これは、関連性の各側が他の側に対して可視性をもつことを意味する。上述した多数のものの順列は、両方向関係で存在し得る。更に、関係の片側を総計（関係の「から」側にオープンダイアモンドを使用して表わした）として示すことができる。総計関係は、「から」クラスが「へ(to)」クラスのインスタンス（１つ又は複数）をプライベートに所有することを指定する。従って、「へ」クラスのインスタンスを形成及び削除するのは、「から」クラスの責任である。
【００３１】
オブジェクトモデリングプログラムは、各個々のパッケージ、クラス、属性、関係及び関係ロールに対して設定することのできる付加的なプロパティを定義するのを許す。「ＣＢＯＦ」タブは、図３に示すように、オブジェクトモデリングプログラムと共に各形式のオブジェクトに対するプロパティに追加されてもよい。このタブは、各形式のオブジェクトに対して設定できる特定のプロパティをリストする。視覚的モデルに対応するメタデータ又はマシン読み取り可能なデータを発生するモデルは、いかなるオブジェクトのいかなるプロパティにもアクセスできる。それ故、プロパティを追加することにより、クラスの付加的なプロパティを、そのクラスに対するコード及び他のサポートのその後の発生をカスタマイズするように、設定することができる。
【００３２】
特に、「レーショナル・ローズ」オブジェクトモデリングプログラムは、種々のオブジェクトに対する付加的なプロパティ値を含む拡張を追加できるようにする。オブジェクトモデルが形成されるときには（クラス、属性、関連性等の特徴をもつ）これらオブジェクトモデルにおいてプロパティの集合を指定し及び／又は設定することができる。プロパティの集合は、カスタマイズの目的で拡張及び追加することができる。図４は、クラスプロパティを指定するためのポップアップウインドウに追加されたＣＢＯＦタブ４０１を示す。プロパティのセット又はサブセットを操作のために選択することができる（４０２）。モデルプロパティとして、プロパティ名４１１、値４１２及びソース４１３（デフォールト又はオーバーライドと表示された）は、全て、ユーザがプロパティを操作するのを制御する。非デフォールト値を有するプロパティは、太字、ハイライト又はその他で強調することができる。
【００３３】
以下の説明は、各形式のオブジェクトに対して追加できるプロパティと、クラスに対するコード及び他のサポートの発生を制御するのに使用できる１つ以上のやり方とをリストしたものである。
【００３４】
１．プロジェクトプロパティ：単一オブジェクトモデルは、「プロジェクト」と考えられる。それ故、全体的に対応するプロジェクトオブジェクトに対してグローバルな幾つかのプロパティを設定することができる。
ＣｏｐｙｒｉｇｈｔＮｏｔｉｃｅ−発生されたコードにおいて出力されるべき著作権通告をオーバーライドする。
ＰｒｏｊｅｃｔＮａｍｅ−発生されるであろうＯＲマッピングプロジェクトクラスのクラス名をオーバーライドする。
ＰｒｏｊｅｃｔＤｅｓｃｒｉｐｔｉｏｎ−発生されるＯＲマッピングオブジェクトクラスに静的変数として記憶されるであろう記述を設定する。
【００３５】
２．クラスプロパティ：クラスは、クラス図に基づいて形成される単一ＵＭＬクラスオブジェクトを含む。標準プロパティのセットをクリックすることにより、「Ｃｍｏ」と称される新たなタブに、次のものを含むプロパティを追加することができる。
Ｇｅｎｅｒａｔｅ−ドキュメンテーションの目的でのみ存在するあるクラスに対してコードの発生を回避するために「ノー」にセットされる。
ＧｅｎｅｒａｔｅＥＪＢ−クラスへの１つ以上のＥＪＢインターフェイスを発生するために「イエス」にセットされる。
ＴａｂｌｅＮａｍｅ−クラスに対してデフォールトテーブル名をオーバーライドする。デフォールトにより、大文字のクラス名の最初の２７キャラクタがテーブル名となる。
ＩｓＳｔａｇｅａｂｌｅ−以下に更に述べるように、この特定のクラスに対しステージング能力の発生を回避するために「偽」にセットされる。
ＭａｘＮｕｍＶｅｒｓｉｏｎ−過去の変更の数をセットして特定クラスインスタンスを持続するために０より大きくセットする。
ＲｅｐｌａｃｅＣｌａｓｓ−このクラス実施が取って代わる既存のクラスの全経路クラス名を指定する。
ＷｒａｐｐｅｒＰａｃｋａｇｅＮａｍｅ−ラッパー（ＩｍｐｌＣ）クラスが発生されるパッケージ名を指定する。
【００３６】
ＩｍｐｌＰａｃｋａｇｅＮａｍｅ−持続実施及びその一次ラッパー（Ｉｍｐｌ及びＩｍｐｌＷ）クラスが発生されるパッケージ名を指定する。
ＳｔａｇｅａｂｌｅＰａｃｋａｇｅＮａｍｅ−持続ステージング可能な実施（ＩｍｐｌＳ）が発生されるパッケージ名を指定する。
Ｃｏｎｓｔｒａｉｎｔ１ないしＣｏｎｓｔｒａｉｎｔ７−クラスに対するテーブルレベル制約を指定する。例えば、「ＵＮＩＱＵＥ（ｎａｍｅ、ＯｗｉｎｇＭｅｍｂｅｒ）」
ＩｓＤｉｓｐｌａｙｅｄ−所与のユーザインターフェイスにおいてクラス名をユーザに表示すべきかどうか指定する。
ＤｉｓｐｌａｙＮａｍｅ−クラスのデフォールト表示名をオーバーライドする。デフォールトにより、クラス名は、「Ｃｍｏ」プレフィックスを除去し、次いで、大文字の直後に小文字が続くところにスペースを追加することによりクラス名が発生される。
ＤｉｓｐｌａｙＤｅｓｃｒｉｐｔｉｏｎ−このクラスに対して表示すべき記述を設定する。
【００３７】
３．属性プロパティ：属性は、上述したベース形式属性に対し特定のクラスに追加することができる。属性は、「Ｃｍｏ」と称される新たなタブを、次のプロパティと共にもつことができる。
ＣｏｌｕｍｎＮａｍｅ−この属性のクラスに対しテーブルにおけるこの属性のデフォールトカラム名をオーバーライドする。デフォールトにより、大文字の属性名の最初の３０キャラクタと、ワード境界を分離するための「−」とが、カラム名となる。
Ｉ１８ＮＣｏｎｓｔｒａｉｎｔＮａｍｅ−（属性が唯一に設定される場合に）このカラムに対して追加される＿ＩＮテーブルに対しデフォールト制約名をオーバーライドする。
【００３８】
４．関連性プロパティ：２つの特定のクラス間に関連性を追加することができる。関連性は、ロールと称される２つの側を含むことができる。関連性それ自体は、「ＣＢＯＦ」と称される新たなタブを次のプロパティと共にもつことができる。
ＲｅｌａｔｉｏｎＴａｂｌｅＮａｍｅ−関連性が多数対多数又は単一方向のもの対多数の関係を表わす場合には、中間即ち「関係」テーブルを追加してもよい。関係テーブル名を指定するようにこのプロパティを設定する。デフォールトにより、関係テーブル名は、関係の両側のクラス名をとって、それらの間に「へ(TO)」を使用するよう試みる。この名前が大き過ぎる（２７キャラクタより大きい）場合には、クラス名のイニシャル（ワード境界の最初の文字）の後にクラス名のストリングハッシュコードを続けたものが使用される。
【００３９】
５．ロールプロパティ：ロールは、関連性の片側を表わす。関連性は、ロール側Ａ及びロール側Ｂを有する。それ故、プロパティがロールオブジェクトに追加される場合には、２つの付加的なテーブルを、次のプロパティと共に、関連性プロパティ即ち「ＣＢＯＦ  Ａ」及び「ＣＢＯＦ  Ｂ」に追加することができる。
ＣｏｌｕｍｎＮａｍｅ−この関連性のクラスに対するテーブルにおいてこの関連性のデフォールトカラム名をオーバーライドする。デフォールトにより、大文字のロール名の最初の３０キャラクタと、ワード境界を分離する「−」とが、カラム名となる。
ＧｅｎｅｒａｔｅＦｏｒｅｉｇｎＫｅｙＣｏｎｓｔｒａｉｎｔ−関連性のこの側で外来キー制約を発生すべきでない場合に、「偽」にセットされる。
ＦｏｒｅｉｇｎＫｅｙＣｏｎｓｔｒａｉｎｔＮａｍｅ−関連性のこの側でデフォールト外来キー制約名をオーバーライドする。
【００４０】
以下に述べるように、水平パーティショニングは、オブジェクトのグループを含むようにプロジェクトプロパティとして、又は関係オブジェクトを含むようにクラスプロパティとして割り当てることができる。全てのクラス、属性及び関係がモデリングされると、コードを発生することができる。
【００４１】
また図５に示すように、オペレーションを指定すると共に、オペレーションのプロパティを割り当てることができる。ＣＢＯＦアドインタブ５０１が示されている。ＥＪＢローカルインターフェイス及び／又はＥＪＢリモートインターフェイスを発生すべきかどうか指示する少なくとも２つのプロパティ５２１にアクセスすることができる。各々のプロパティに対して、名前５１１、値５１２及びソース５１３が指示される。より一般的には、ローカルインターフェイスは、同じウェブコンテナ１２１又は同じパッケージに存在する発呼及び被呼オブジェクトに適応された比較的オーバーヘッドの少ない第１プロトコルに従う。リモートインターフェイスは、リモートメソッド呼び出しに適応されたオーバーヘッドの大きい第２プロトコルに従う。リモートメソッド呼び出しプロトコルは、ＣＯＲＢＡ、Ｊａｖａ  ＲＭＩ、マイクロソフトトランザクションサーバー、マイクロソフトＣＯＭ／ＤＣＯＭ、マイクロソフト．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ及びＥｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）のような仕様及び製品に対して設けられる。ローカル及びリモートインターフェイスを発生する選択は、発呼オーバーヘッド及び／又はインターフェイスの露呈を制御する。
【００４２】
図６は、ＥＪＢラッピングに適応させることのできるＣＢＯＦモデルを示す。図６を参照すれば、本発明の一実施形態によるオブジェクトフレームワーク６１０のブロック図が示されている。別の実施形態では、オブジェクトフレームワーク６１０は、図６の実施形態に関連して説明するコンポーネントに加えて又はそれに代わって種々の他のコンポーネント又はコンフィギュレーションを容易に含むことができる。
【００４３】
ＣＯＦ／ＣＢＯＦ実施の有用な態様は、次の組合せを含むことができる。即ち、オブジェクトモデル設計に制約を伴うことなくオブジェクトをモデリングするためのレーショナル・ローズの使用。カスタムビジネスロジックメソッドに対するプレースホルダ又はスタブでのコード発生。レーショナル・ローズ逆転エンジニアリングを必要とせずにオブジェクトのランタイム形成、読み取り、更新及び削除（ＣＲＵＤ）をサポートするコードの発生。マッピングパラメータのユーザ宣言を越えるユーザの相互作用をほとんど又は全く伴わないオブジェクト対レーショナル（ＯＲ）マッピング。関係データベースへのビジネスオブジェクトを持続させる持続マッピング情報の発生。情報を使用してデータベースを形成及び／又は移動させるデータベーススキーマ及びツールを形成するのに必要な情報を含む関係データベース及び制約の定義及び形成。フレームワークにおいてビジネスオブジェクトを容易に形成、読み取り、更新及び削除するために標準ＡＰＩのセットを経てアクセスできるランタイム形成、読み取り、更新及び削除（ＣＲＵＤ）の単純なメソッド。データベースにおいて原子トランザクションを使用してオブジェクトのセットを形成、更新、及び削除するためのトランザクションパラダイムの使用。コミット時間及び楽観的ロックが使用されるまでデータベースが影響を受けないのでトランザクションを長く続けることができる。変更がテストされ、承認されそして配備されるまでオブジェクトのライブ生産バージョンに影響せずにビジネスオブジェクトへの変更をサポートするデータステージング。オブジェクトの基本的属性変更のオーデットトレイルを含むデータ変更経歴サポート。ビジネスオブジェクトの変換可能なストリング属性の透過的記憶及び検索に使用できるデータベーススキーマを形成するためのコード及び情報の発生。データベーススキーマに影響せずにランタイムにオブジェクトに動的に新たな属性を追加することをサポートする。オブジェクトの形成、更新又は削除の際に発生された事象をもつようにビジネスオブジェクトを構成するオプションを含むオブジェクト変更通知のサポートである。
【００４４】
これらの事象は、データベースに対して持続され、そして事象通知サーバーにより管理することができる。又、ビジネスオブジェクトそれ自体は、メモリに最初に構成された後（ｉｎｉｔ()）、データベースに挿入された後（ｐｏｓｔＩｎｓｅｒｔ()）、更新のためのトランザクションに追加された後（ｐｏｓｔＡｄｄＦｏｒＵｐｄａｔｅ()）、データベースへのトランザクションにおいて更新される前（ｐｒｅＣｏｍｍｉｔ()）、データベースからロード／リフレッシュされた後（ｐｏｓｔＲｅｆｒｅｓｈ()）、及び最後に、データベースから削除される前に（ｐｒｅＤｅｌｅｔｅ()）、あるアクションを実行するためのメソッドを実施することができる。
【００４５】
図６の実施形態において、５つのベースクラスのグループが水平軸６１４の上に示されており、好ましくは、ベースライブオブジェクトクラスＣｍｏＢａｓｅＩｍｐｌ６３０と、ベースインターフェイスクラスＣｍｏＢａｓｅ６３４と、ベースステージングクラスＣｍｏＢａｓｅＩｍｐｌＳ６３８と、ベース国際化クラスＣｍｏＢａｓｅＩ１８Ｎ６４２と、ベースラッパークラスＣｍｏＢａｓｅＩｍｐｌＷ６４４とを含むことができる。これらベースクラスの機能及び使用は、参考としてここに取り上げる特許出願に一般的に説明されている。
【００４６】
図６の実施形態において、ルートクラスのグループが水平軸６１４と水平軸６１８との間に示されており、好ましくは、前記の対応するベースクラスから継承する各ルートクラスを含むことができる。図６の実施形態において、ルートクラスは、好ましくは、ルートライブオブジェクトクラスＡｂｓｔｒａｃｔＸＩｍｐｌ６４６と、ルートインターフェイスクラスＡｂｓｔｒａｃｔＸ６５０と、ルートステージングクラスＡｂｓｔｒａｃｔＸＩｍｐｌＳ６５４と、ルート国際化クラスＡｂｓｔｒａｃｔＸＩ１８Ｎ６５８と、ルートラッパークラスＡｂｓｔｒａｃｔＸＩｍｐｌＷ６６２と、ルートカスタムクラスＡｂｓｔｒａｃｔＸＩｍｐｌＣ６６６とを含むことができる。
【００４７】
図６の実施形態において、サブクラスのグループが水平軸６１８の下に示されており、好ましくは、前記の対応するベースクラス及びルートクラスから継承する各サブクラスを含むことができる。図６の実施形態において、これらサブクラスは、好ましくは、サブライブオブジェクトクラスＸＩｍｐｌ６７０と、サブインターフェイスクラスＸ６７４と、サブステージングクラスＸＩｍｐｌＳ６７８と、サブ国際化クラスＸＩ１８Ｎ６８２と、サブラッパークラスＸＩｍｐｌＷ６８６と、サブカスタムクラスＸＩｍｐｌＣ６９０とを含む。
【００４８】
更に、図６において、上述した一連のインターフェイスクラスが垂直軸６２２の左に示されている。一連のラッパークラスが垂直軸６２２と垂直軸６２６との間に示されている。更に、データベース１２０に持続的に記憶されるクラスのグループが垂直軸６２６の右に示されている。インターフェイスは、システムのユーザに露呈されるパブリックＪａｖａインターフェイスである。これらのインターフェイスは、取得、設定、追加、除去及びカスタムビジネスロジックメソッドを定義する。また、インターフェイスは、ＡＰＩのｊａｖａｄｏｃを参照として含む。これらのインターフェイスが発生されると、手動で変更してはならない。というのは、手動で変更すると、その後のコード再生に生き残れないからである。
【００４９】
一実施形態では、これらクラスは、ソフトウェアコンポーネントとしてＴｏｐＬｉｎｋと相互作用する。以下の説明のあるものは、ＴｏｐＬｉｎｋに特有であるが、当業者であれば、同じ解決策を他のデータベースマッピング及び管理モジュールと共に適用できることが明らかであろう。持続クラスは、持続属性及び関係データベースへのマッピングを含むクラスとしてＴＯＰＬｉｎｋに対して述べた実施クラスである。３つの形式の持続クラスは、Ｉｍｐｌ、ＩｍｐｌＳ及びＩ１８Ｎを含む。Ｉｍｐｌクラスは、データベースにおけるオブジェクトの厳密なライブバージョンを表わす。ＩｍｐｌＳクラスは、データベースにおけるライブオブジェクトのシャドー又はステージングバージョンを表わす。インターフェイスクラスにおいて宣言された全ての取得／設定／追加／除去メソッドは、これらのクラスにおいて実施される。全てのビジネスロジックＡＰＩは、ＵｎｓｕｐｐｏｒｔｅｄＯｐｅｒａｔｉｏｎＥｘｃｅｐｔｉｏｎを投入する。Ｉ１８Ｎクラスは、変換可能なストリング属性及び変換の位置を含む。Ｉｍｐｌ及びＩｍｐｌＳクラスは、Ｉ１８Ｎクラスに対して１対多の関係を有する。変換可能なストリング属性の取得／設定メソッドがコールされたときには、Ｉ１８Ｎクラスの適当なインスタンスが、スレッドに設定された現在位置に基づいてアクセスされる。これらのクラスが発生されると、手動で変更してはならない。
【００５０】
ラッパークラスは、トランザクションサポート、ステージング、変更経歴、及びカスタムビジネスロジック機能を実施する。２つの形式のラッパークラス、ＩｍｐｌＷ及びＩｍｐｌＣがある。ＩｍｐｌＷクラスは、インターフェイスクラスから取得／設定／追加／除去メソッドだけを実施する抽象クラスである。これらのメソッドは、Ｉｍｐｌオブジェクト、ＩｍｐｌＳオブジェクト、又はそれらの適当なＴＯＰＬｉｎｋトランザクションクローンにおいて値を検索又は設定すべきかどうか適切にチェックする。設定／追加／除去メソッドは、トランザクションにおける更新に対してインスタンスが追加されなかった場合にＣｅＮｏｔＩｎＴｒａｎｓａｃｔｉｏｎＥｘｃｅｐｔｉｏｎを投入する。取得メソッドは、トランザクションの外部のクローンラッパーにアクセスする試みがなされた場合に「アクセスしたラッパー無効」のメッセージと共にＣｅＲｕｎｔｉｍｅＥｘｃｅｐｔｉｏｎを投入する。
【００５１】
ＩｍｐｌＣクラスは、持続オブジェクトがアクセスされるか又は形成されたときにインスタンス生成された具体的クラスである。このクラスは、それに対応するＩｍｐｌＷクラスから継承される。ＩｍｐｌＣクラスは、カスタムビジネスロジックメソッドの実施を含むように手で変更することができる。ＩｍｐｌＷクラスは、各再生で完全に発生される。ＩｍｐｌＣクラスは、通常、いったん発生されると、維持できる個々のファイルとしてソース制御に対してチェックされる。ＩｍｐｌＷ及びＩｍｐｌＣクラスの継承構造に注意されたい。ＩｍｐｌＷクラスは、そのスーパークラスのＩｍｐｌＣから継承される。ＩｍｐｌＣは、それに対応するＩｍｐｌＷクラスから継承される。又、ＩｍｐｌＷは、インターフェイスクラスにおいて宣言されたビジネスロジックＡＰＩを実施しないことにも注意されたい。これらは、ＩｍｐｌＣクラスにより実施される。あるクラスをモデルにおいて抽象と宣言することができ、これは、ＩｍｐｌＣクラスを抽象とする。
【００５２】
又、持続クラス及びそれに関連したＴＯＰＬｉｎｋトランザクションクローンは、それに対応するラッパーへの参照を有することにも注意されたい。ＴＯＰＬｉｎｋのキャッシュにおける持続インスタンスは、それらのラッパーのリードオンリーバージョンを指す。クローンは、それらラッパーの書き込み可能なバージョンを指す。クローンがコミットされて、ＴＯＰＬｉｎｋのキャッシュされたインスタンスへ合流されて戻されるときには、それに対応するラッパーが無効になる。クローンのラッパーは、それに対応するリードオンリーラッパーへの参照を有し、これは、ラッパーにおけるｇｅｔＲｅａｄＯｎｌｙＯｂｊｅｃｔ（）メソッドをコールすることにより得ることができる。
【００５３】
このファイルセットを説明するには、ベースクラスハイアラーキーが必要となる。図６は、このベースクラスハイアラーキーの一実施形態を示す。この図の最上部には、５つのベースクラス、ＣｍｏＢａｓｅＩｍｐｌ６３０、ＣｍｏＢａｓｅ６３４、ＣｍｏＢａｓｅＩｍｐｌＷ６４４、ＣｍｏＢａｓｅＩｍｐｌＳ６３８、及びＣｍｏＢａｓｅＩ１８Ｎ６４２がある。
【００５４】
ＣｍｏＢａｓｅ６３４は、全てのオブジェクト３３２が継承されて実施されるところのインターフェイスクラスである。このインターフェイスは、全てのオブジェクト３３２が実施しなければならない全てのベース属性及びオペレーションの宣言を含む。このオブジェクトフレームワーク６１０の種々の特徴は、全てのオブジェクトにわたって適用できるようにこのインターフェイスに追加される属性及びメソッドを含む。又、ＣｍｏＢａｓｅ６３４は、このフレームワークに設けられたメカニズムにより発生されるオブジェクト３３２をマークする方法としても働く。図７に示すように、別のＣｍｓＢａｓｅクラス７０２が、持続を必要としない過渡的オブジェクトとして設けられてもよい。
【００５５】
ＣｍｏＢａｓｅＩｍｐｌＷ６４４は、他の実施オブジェクト（ＣｍｏＢａｓｅＩｍｐｌ、ＣｍｏＢａｓｅＩｍｐｌＳ、及びＣｍｏＢａｓｅＩ１８Ｎ）へのアクセスをラップするための実施を含むラッパーオブジェクトを表わす。ＣｍｏＢａｓｅＩｍｐｌＷクラスは、ＣｍｏＢａｓｅインターフェイスを実施する。ＣｍｏＢａｓｅＩｍｐｌＷクラスの目的は、オペレーションを実行するためにＩｍｐｌ（ライブオブジェクトに対する）又はＩｍｐｌＳ（ステージングされたオブジェクトに対する）のいずれのインスタンスをコールすべきか決定することである。このクラスは、４つの重要な関係を有する。ｌｉｖｅＯｂｊｅｃｔは、データベースにおける一次ライブビジネスオブジェクトを表わすＣｍｏＢａｓｅＩｍｐｌオブジェクトのインスタンスを保持する。ｓｈａｄｏｗＯｂｊｅｃｔは、データベースにおけるライブビジネスオブジェクトのシャドー又はステージングされたバージョンを表わすＣｍｏＢａｓｅＩｍｐｌＳオブジェクトのインスタンスを保持する。ｃｌｏｎｅｄＯｂｊｅｃｔは、オブジェクトが形成又は更新トランザクションに入れられたときにｌｉｖｅＯｂｊｅｃｔ又はｓｈａｄｏｗＯｂｊｅｃｔのクローンコピーを保持する。ｌｉｖｅＣｌｏｎｅｄＯｂｊｅｃｔは、ｃｌｏｎｅｄＯｂｊｅｃｔがｓｈａｄｏｗＯｂｊｅｃｔのクローンコピーを含むときにｌｉｖｅＯｂｊｅｃｔのクローンコピーを保持する（これは、オブジェクトがトランザクションにおいて更新又は形成に対してステージングされたときに生じる）。
【００５６】
ｌｉｖｅＯｂｊｅｃｔには、リードオンリーラッパーが与えられる。ラッパーは、リードオンリーラッパーをトランザクションに追加し、これが、ｌｉｖｅＯｂｊｅｃｔにアクセスしている他のユーザに影響せずに変更できるｌｉｖｅＯｂｊｅｃｔのクローンを含む新たなラッパーを返送することにより、書き込み可能とされる。トランザクションがコミットされたときには、クローンを使用して、更新をデータベースへ送信すると共に、変更をｌｉｖｅＯｂｊｅｃｔへ合流させる。書き込み可能なラッパーがコミットされると、それはもはや有用ではなく、リードオンリーラッパーにアクセスしなければならない（これは、書き込み可能なラッパーがメモリを節約するためにごみ収集できるようにする）。このクラスのインスタンスは、アクション（形成、読み取り、アクセス関係及び更新）がとられたときにユーザに返送されるものである。
【００５７】
ＣｍｏＢａｓｅＩｍｐｌ６３０は、データベースにおけるライブ持続オブジェクトを表わす。このクラスは、オブジェクト対関係マッピングを制御するプロパティを含む。このような情報は、テーブル、カラム及び制約を含むスキーマの形成を許す。このクラスは、関係（そのオブジェクト形式との単一の関係又は収集形式を使用する多数の関係）を表わす属性を含むオブジェクトモデルで定義された属性を含む。このクラスは、ＣｍｏＢａｓｅインターフェイス６３４も実施する。属性及び関係に対するゲッター及びセッターは、関連属性又は関係にアクセスするために実施される。他のビジネスロジックメソッド（モデルにおいて宣言された）は、メソッドへの偶発的なアクセスを防止するためにＵｎｓｕｐｐｏｒｔｅｄＯｐｅｒａｔｉｏｎＥｘｃｅｐｔｉｏｎを投入する。ＩｍｐｌＷクラスだけがこのクラスにアクセスしなければならず、そしてＩｍｐｌクラスにおいていかなるビジネスロジックメソッドもコールしてはならない。
【００５８】
ＣｍｏＢａｓｅＩｍｐｌＳ６３８は、本質的に、ＣｍｏＢａｓｅＩｍｐｌｅクラスの厳密なコピーであるが、Ｉｍｐｌインスタンスのシャドー又は「ステージングされた」値を表わす。これらのステージングされた値は、個別のテーブルに記憶され、そして個別のインスタンスであり、従って、ステージングされたことを表わす個別のクラスが設けられて、個別のテーブルへマップされる。ＣｍｏＢａｓｅＩｍｐｌＳ６３８の利用については、参考として取り上げた特許出願に更に説明されている。
【００５９】
ＣｍｏＢａｓｅＩ１８Ｎ６４２は、国際化のサポートに使用されるベースクラスである。このクラスは、変換可能なストリング値を保持する全てのテーブルに必要とされるベース属性を保持する。オブジェクトのＩｍｐｌクラスが発生されると、ＣｍｏＢａｓｅＩ１８Ｎ６４２から継承される内部クラスも、そのクラスが変換可能なストリング属性を有する場合に発生される。ＣｍｏＢａｓｅＩ１８Ｎ６４２のインスタンスは、Ｉｍｐｌクラスの変換可能なストリング属性の言語変換に対応する。変換のステージングされた値について付加的なインスタンスが与えられる。変換のリストは、クラスハイアラーキーの各レベルに保持される。これは、ＣｍｏＢａｓｅＩ１８Ｎクラス及びテーブルのハイアラーキーを必要とせずに変換可能なストリング属性をいつでも追加／除去するのを許す。これらの特徴は、参考として取り上げた特許出願に詳細に説明されている。
【００６０】
オブジェクトが発生されると（例えば、ＡｂｓｔｒａｃｔＸ６４６）、発生されたクラスが適当なベースクラスを拡張する。図６に示すように、ＡｂｓｔｒａｃｔＸ６４６は、ＣｍｏＢａｓｅベースインターフェイスから継承されるインターフェイスである。ＡｂｓｔｒａｃｔＸＩｍｐｌＷ６６２は、ＣｍｏＢａｓｅＩｍｐｌＷ６６４から継承される。ＡｂｓｔｒａｃｔＸＩｍｐｌ６４６は、ＣｍｏＢａｓｅＩｍｐｌ６３０から継承される。ＡｂｓｔｒａｃｔＸＩｍｐｌＳ６５４は、ＣｍｏＢａｓｅＩｍｐｌＳ６３８から継承される。更に、ＡｂｓｔｒａｃｔＸの変換可能なストリング属性があるので、ＡｂｓｔｒａｃｔＸＩ１８Ｎ６５８は、ＣｍｏＢａｓｅＩ１８Ｎ６４２から継承される。
【００６１】
又、ＡｂｓｔｒａｃｔＸＩｍｐｌＷ６６２から継承されたＡｂｓｔｒａｃｔＸＩｍｐｌＣ６６６と称される別のカスタムクラスもある。ＩｍｐｌＣクラスは、モデルにおけるインターフェイスに追加されたビジネスロジックメソッドのためのユーザ特有のビジネスロジックコードを含む。ＩｍｐｌＣクラスは、コード発生される他のインターフェイス又は実施を含まない。これは、ＩｍｐｌＣを一度だけ発生するのを許し、次いで、ビジネスロジックコードを追加、変更又は除去する必要があるときだけ更新される。他のクラス形式（インターフェイス、ＩｍｐｌＷ、Ｉｍｐｌ、ＩｍｐｌＳ、Ｉ１８Ｎ）は、モデルに変更が生じるたびに、オブジェクトモデル３２０から常に再生される。これは、発生されたコードが、モデルへの逆転エンジニアリングを必要とする手動でのカスタム変更を要求するという問題を解消し、しかも、時間と共に変化し得るビジネスロジック実施の書き込みを許す。発生されたコードは、ＩｍｐｌＣに書き込まれるべきコードを必要とせずに使用できる。ＩｍｐｌＣは、実施されるべきユーザ特有のビジネスロジックメソッドの場所を与える。
【００６２】
更に、図６は、Ｘと称される別のクラスがいかにＡｂｓｔｒａｃｔＸクラスを更に拡張できるか示す。各発生されたクラス形式Ｘは、ＡｂｓｔｒａｃｔＸの適当なクラス形式から継承される。しかしながら、ＸＩｍｐｌＷ６８６は、ＡｂｓｔｒａｃｔＸＩｍｐｌＣ６６６から継承され、従って、ＸＩｍｐｌＣ６８６の実施は、ＡｂｓｔｒａｃｔＸクラスのビジネスロジックメソッドを、それが直接的サブクラスであったかのようにオーバーライドすることができる。本発明の１つの態様は、継承構造及びコードの複雑さを自動的に取り扱い、これらクラス間の関係を管理することである。直観的に、ユーザは、ＩｍｐｌＣにおける視覚的にモデリングされたオブジェクト及びビジネスロジックコードの実施について取り組むだけでよい。
【００６３】
図７は、ＥＪＢ及びＪ２ＥＥをサポートするように適応されるクラスＣｍｏＢａｓｅ７０１、ＣｍｓＢａｓｅ７０２及びＣｍｏＡｔｔｒｉｂｕｔｅ７０３の態様を示すクラス図である。持続的なユーザ変更可能なオブジェクトは、ＣｍｏＢａｓｅ７０１から継承される。しかしながら、多数の属性は、過渡的で、ユーザ変更可能でなく、従って、メモリに形成されたオブジェクトの作用コピーにそれらの静的な値を割り当てることができる。これらの過渡的な属性は、過渡状態に適応されたプロパティ及び属性を有するＣｍｓＢａｓｅ７０２から継承されてもよい。属性レベルにおける持続的なユーザ変更可能なオブジェクトは、例えば、名前、記述、最大バージョン数、ｎｏｔｉｆｙＡｃｔｉｏｎを含む。ＣｍｏＢａｓｅクラス７０１は、自動的に発生される一次キー「ｉｄ」を含む。ＩＤは、ＤＢ内の行及び形式にとって独特である。従って、完全に且つ普遍的に独特のＩＤは、データベース識別子、形式及びＩＤフィールドを連結する。この連結された独特の識別子は、独特なＩＤの現在のＥＪＢ２．０要求を満足する。又、連結された独特の識別子は、以下に述べる水平パーティショニングにも有用である。というのは、ＣｍｏＢａｓｅ７０１におけるＩＤが、データベース及び形式内で独特であることだけを保証するからである。ＣｍｏＢａｓｅ７０１の付加的な属性は、図示された状態、バージョニング及びステージング属性を含む。以下の図１０に示すように、クラスＣｍｏＢａｓｅＬｏｃａｌ及びＣｍｏＢａｓｅＲｅｍｏｔｅは、ＣｍｏＢａｓｅから継承され又はそれに対応するように構成される。ＣｍｏＡｔｔｒｉｂｕｔｅ７０３は、参考として取り上げる特許出願に更に説明されたように、オブジェクトに対するカスタム属性をサポートする。
【００６４】
ＣＯＦツール及びモデルの、ＥＪＢ及びＪ２ＥＥサポートへの適応が図８から１０に示されている。好ましくは、システムにおけるビジネスオブジェクトインターフェイスは、図１０におけるｊａｖａｘ．ｅｊｂ．ＥＪＢＬｏｃａｌＯｂｊｅｃｔ１０１３から拡張されねばならない。この拡張パターンは、リモートアクセスに関連したオーバーヘッドをこうむることなく、同じＪａｖａ仮想マシン（ＪＶＭ）で実行されるＥＪＢオブジェクトにおける呼び出しメソッドコールへのアクセスを与える。リモートアクセスされる必要のある各ビジネスオブジェクトは、ローカルインターフェイスと同じ名前をもち且つ「ｅｊｂ」パッケージのもとに配置された個別のインターフェイスを必要とする。リモートインターフェイスは、ｊａｖａｘ．ｅｊｂ．ＥＪＢＯｂｊｅｃｔ１０１２を拡張し、そしてリモートアクセスできるメソッドのみを含む。ローカル及びリモートインターフェイスに加えて、ｅｊｂ仕様は、図９に示すように、ｅｊｂオブジェクトを形成して見出すためのホームインターフェイスを必要とする。各ビジネスオブジェクトは、ｊａｖａｘ．ｅｊｂ．ＥＪＢＬｏｃａｌＨｏｍｅ９１１を拡張するローカルホームインターフェイス９１２と、ｊａｖａｘ．ｅｊｂ．ＥＪＢＨｏｍｅ９０１を拡張するリモートホームインターフェイス９０２とを有する。
【００６５】
ビジネスロジックを実施するコードを含むビーンクラスは、通常、インターフェイス名にサフィックス「ＩｍｐｌＣ」を設けることで命名される。例えば、図８では、ＰｅｒｓｏｎＩｍｐｌＣ８４２及びＥｍｐｌｏｙｅｅＩｍｐｌＣ８６２は、Ｐｅｒｓｏｎ（個人）及びＥｍｐｌｏｙｅｅ（従業員）インターフェイス８２１及び８４１に対応するビジネスロジックを含むように意図されたオブジェクトである。「ＩｍｐｌＣ」における全てのビジネスメソッドにリモートアクセスできるのではない。ローカルメソッドのパラメータと、ＥＪＢに適合するために必要に応じて「シリアライザブル(Serializable)」に設定された復帰値とを有するリモートメソッドを実施することができる。これをイネーブルするために、フレームワークは、付加的なリモートビジネスメソッドを実施できる充分な「ビーン(Bean)」（例えば、ＰｅｒｓｏｎＢｅａｎ）をもつクラスを発生する。ビジネスロジック実施を与えるのに加えて、多数のＥＪＢ特有のコールバックが実施される。これらコールバックは、ＣｍｏＢａｓｅＩｍｐｌＷクラス（図６の６４４）においてｊａｖａｘ．ｅｊｂ．ＥｎｔｉｔｙＢｅａｎインターフェイス１０１１を実施することにより持続的オブジェクトに対して与えられる。
【００６６】
ＥＪＢ機能を与えるために実施されるコールバックは、ｅｊｂＣｒｅａｔｅ（）、ｅｊｂＰｏｓｔＣｒｅａｔｅ（）、ｅｊｂＦｉｎｄＢｙＰｒｉｍａｒｙＫｅｙ（ＰｒｉｍａｒｙＫｅｙｋｅｙ）、ｅｊｂＬｏａｄ（）、ｅｊｂＳｔｏｒｅ（）、ｅｊｂＲｅｍｏｖｅ（）、ｅｊｂＡｃｔｉｖａｔｅ（）、ｅｊｂＰａｓｓｉｖａｔｅ（）、ｓｅｔＥｎｔｉｔｙＣｏｎｔｅｘｔ（ＥｎｔｉｔｙＣｏｎｔｅｘｔ  ｃｔｘ）及びｕｎｓｅｔＥｎｔｉｔｙＣｏｎｔｅｘｔ（）を含む。これらのコールバックの中で、クライアントがホームインターフェイスにおけるｃｒｅａｔｅ（）メソッドをコールしたときに、ｅｊｂＣｒｅａｔｅ（）メソッドがコールされる。ｅｊｂコンテナは、ビーン（ＩｍｐｌＣクラス）のインスタンスを形成し、そしてビーンにおけるｅｊｂＣｒｅａｔｅ（）メソッドをコールする。実施は、ＣｍｏＴｒａｎｓａｃｔｉｏｎを取得又は形成し、このビーンをトランザクションに追加し、ラッパーオブジェクトｐｒｅＡｌｌｏｃａｔｅｏｂｊｅｃｔＩｄを初期化し、トランザクションをコミットし、そしてＰｒｉｍａｒｙＫｅｙＯｂｊｅｃｔを返送するメソッドを与えねばならない。このメソッドは、オブジェクトを初期化するのに必要な非ナルデータベース制約パラメータを通過させるために多数のケースにおいてオーバーロードされる必要がある。
【００６７】
ｅｊｂＰｏｓｔＣｒｅａｔｅ（）メソッドは、ｅｊｂＣｒｅａｔｅ（）メソッドコールの直後にコンテナによりコールされる。このメソッドは、ｅｊｂＣｒｅａｔｅ（）と同じ数のアーギュメントを有すると共に、付加的な初期化を与え且つそのライフスパン中に必要とされるリソースを割り当てねばならない。
【００６８】
ｅｊｂＦｉｎｄＢｙＰｒｉｍａｒｙＫｅｙ（ＰｒｉｍａｒｙＫｅｙｋｅｙ）メソッドは、クライアントがホームインターフェイスにおけるｆｉｎｄＢｙＰｒｉｍａｒｙＫｅｙ（）を呼び出したときにコールされる。実施は、トランザクションが必要とされないことを指示し、オブジェクトｉｄに基づいてデータベースのオブジェクトを見出し（ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎ．ｆｉｎｄＢｙＩｄ（）メソッドを使用）、そしてＰｒｉｍａｒｙＫｅｙオブジェクトを返送するメソッドを与えねばならない。このメソッドは、カスタム問合せに対してオーバーロードされる必要がある。
【００６９】
ｅｊｂＬｏａｄ（）コールバックメソッドは、エンティティビーンの「読み取り」機能にほぼ対応する。本発明の態様を実施する１つの実施形態では、ビーンは、通常、ｃｒｅａｔｅ（）又はｆｉｎｄ（）メソッド中にＴＯＰＬｉｎｋＯＲマッピングを使用して初期化され、従って、このメソッドは、ある後処理オペレーションに対して使用できる。
【００７０】
ｅｊｂＳｔｏｒｅ（）コールバックメソッドは、エンティティビーンの「更新」機能にほぼ対応する。この機能は、ＣｍｏＴｒａｎｓａｃｔｉｏｎをスタートする必要があり且つ更新のためにトランザクションにオブジェクトが追加される以外は、本発明のＣｍｏＴｒａｎｓａｃｔｉｏｎに既にカプセル化されている。
【００７１】
ｅｊｂＲｅｍｏｖｅ（）コールバックメソッドは、データストアからオブジェクトを除去する。ＣｍｏＴｒａｎｓａｃｔｉｏｎがスタートされ、削除のためのオブジェクトを追加する。
【００７２】
アクチベーションプロセス中に、ビーンインスタンスにおけるｅｊｂＡｃｔｉｖａｔｅ（）メソッドがコールされた後に、ｅｊｂＬｏａｄ（）メソッドがコールされる。ビーンがアクチベートされ、そしてその状態がその基礎となるデータベース記録に適切に同期されると、ビジネスメソッドが進められる。ビジネスメソッドへのその後のコールは、ビーンインスタンスへ直接デリゲートされる。
【００７３】
ｅｊｂＰａｓｓｉｖａｔｅ（）は、パッシベーション中に使用される。パッシベーションプロセス中に、コンテナは、ビーンインスタンスにおけるｅｊｂＳｔｏｒｅ（）メソッドを呼び出す。ビーンインスタンスは、データベースを更新する役割を果たす。データベースの更新後に、コンテナは、ビーンインスタンスにおけるｅｊｂＰａｓｓｉｖａｔｅ（）メソッドを呼び出し、ビーンがパッシベーションされる前に以前に割り当てられていたリソースを解放する機会をそれ自身与える。
【００７４】
ｓｅｔＥｎｔｉｔｙＣｏｎｔｅｘｔ（ＥｎｔｉｔｙＣｏｎｔｅｘｔ  ｃｔｘ）メソッドは、ビーン初期化中にビーンのコンテクストでコールされる。コンテクストは、将来の使用のためにセーブされる。ｕｎｓｅｔＥｎｔｉｔｙＣｏｎｔｅｘｔ（）は、コンテクスト設定を実行する。コンテナは、ビーンにより使用されたリソースを解放することが判断された場合に、プールされたビーンのごみ収集を行うことができ、この場合に、存在しない状態へ戻る移行が実行される。この移行時間中に、コンテナはこのメソッドをコールする。このメソッドは、このビーンにより使用されるリソースを割当て解除する。
【００７５】
図８は、ＥＪＢ適合ＣＢＯＦオブジェクトモデルを、ローカル及びリモートの両アクセス及びインターフェイスと共に、個人（１人及び複数）及び従業員（１人及び複数）のための簡単なオブジェクトに適用するところを示す。個人８２１、８２４及び従業員８４１、８３４のオブジェクトは、ＥＪＢＬｏｃａｌＯｂｊｅｃｔ８１１及びＥＪＢＯｂｊｅｃｔ８１４から実施される。ローカルオブジェクトの実施は、ローカルの減少オーバーヘッドアクセスをサポートする。ＥＪＢＯｂｊｅｃｔの実施は、リモートオブジェクトアクセスをサポートする。ローカルオブジェクトの標準プロパティは、上述したように、ＣｍｏＢａｓｅ８１２から継承される。図８全体にわたり、サフィックスＩｍｐｌＷ及びＩｍｐｌＣが、ラッパー及び具体的実施のために使用される。ＥｎｔｉｔｙＢｅａｎ８１３は、ＣｍｏＢａｓｅＩｍｐｌＷ８２２により実施される。個人８２１及び従業員８４１のオブジェクトの実施は、ＣｍｏＢａｓｅＩｍｐｌＷ８２２から継承される。これらの実施は、ＰｅｒｓｏｎＩｍｐｌＷ８３２、ＰｅｒｓｏｎＩｍｐｌＣ８４２、ＥｍｐｌｏｙｅｅＩｍｐｌＷ８５２及びＥｍｐｌｏｙｅｅＩｍｐｌＣ８６２を含む。図９について説明するように、２つのホームオブジェクトＥＪＢＬｏｃａｌＨｏｍｅ８５３及びＥＪＢＨｏｍｅ８３３がローカル及びリモートインターフェイスに対して設けられている。これらホームオブジェクトの実施は、ＰｅｒｓｏｎＬｏｃａｌＨｏｍｅ８６３、ＰｅｒｓｏｎＨｏｍｅ８４３、ＥｍｐｌｏｙｅｅＬｏｃａｌＨｏｍｅ８６４、及びＥｍｐｌｏｙｅｅＨｏｍｅ８４４を含む。
【００７６】
図９は、図８の一部分を一般化したもので、オブジェクトに対してホームを必要とするＥＪＢ規定に適合するものを示す。ホームは、両リモート及びローカルオブジェクト並びにインターフェイス９０１及び９１１に対して各々設けられる。各ビジネスオブジェクトは、ｊａｖａｘ．ｅｊｂ．ＥＪＢＨｏｍｅ９０１を拡張するリモートホームインターフェイス９０２と、ｊａｖａｘ．ｅｊｂ．ＥＪＢＬｏｃａｌＨｏｍｅ９１１を拡張するローカルホームインターフェイス９１２とを有する。リモート及びローカルホームインターフェイス９０２、９１２は、更に、ＣｍｏＡｐｐｌｉｃａｔｉｏｎＣｏｎｆｉｇＲｅｍｏｔｅＨｏｍｅ９０３及びＣｍｏＡｐｐｌｉｃａｔｉｏｎＣｏｎｆｉｇＬｏｃａｌＨｏｍｅ９１３により拡張される。
【００７７】
図１０も図８の一部分を一般化したもので、ＥＪＢをサポートするための付加的なメカニズムを示す。オブジェクトｊａｖａｘ．ｅｊｂ．ＥＪＢＯｂｊｅｃｔ１０１２及びｊａｖａｘ．ｅｊｂ．ＥＪＢＬｏｃａｌＯｂｊｅｃｔ１０１３がＣｍｏＢａｓｅＲｅｍｏｔｅ１０２２及びＣｍｏＢａｓｅＬｏｃａｌ１０２３へ拡張される。
【００７８】
ＥＪＢ２．０仕様は、ＥＪＢエンティティ間の関係をサポートする。３つの基本的関係主要素（１対１、１対多数、及び多数対多数）が全てサポートされる。更に、これらの関係は、ＥＪＢ２．０仕様の新たな問合せ言語を使用してナビゲーションすることができる。関係は、抽象アクセッサーメソッドを介して管理される。関連付けられたオブジェクトの多様性が多数である関係の場合には、抽象アクセッサーのパラメータ又は返送値形式が、その関係を表わす収集クラスである。この収集クラスは、ｊａｖａ．ｕｔｉｌ．Ｃｏｌｌｅｃｔｉｏｎ又はｊａｖａ．ｕｔｉｌ．Ｓｅｔインターフェイスを実施する。任意であるが、仕様は、ｊａｖａ．ｕｔｉｌ．Ｍａｐ及びｊａｖａ．ｕｔｉｌ．Ｌｉｓｔを返送形式として追加してもよい。収集クラスの多様性が１である関係の場合には、抽象アクセッサーのパラメータ又は返送値形式が、その関連オブジェクトの単一インスタンスである。
【００７９】
ＣＯＦにおける関係アクセッサーは、それに対応するオブジェクトの配列としてパラメータ又は返送値形式を有する。それらを、リモートインターフェイスを経てｅｊｂアクセス可能にするために、それらの関係に対する付加的なメソッドをリモートインターフェイスにおいて与えて、ＩｍｐｌＷにおいて実施しなければならない。例えば、「従業員とアドレスの関係」は、非常に多数で且つ両方向のものである。例えば、「従業員とアドレスの関係」のような関係を横断するローカル及びリモートメソッドを実施することができる。
【００８０】
例えば、ローカルメソッドは、ｐｕｂｌｉｃ  Ａｄｄｒｅｓｓ［］ｇｅｔＡｄｄｒｅｓｓ（）；ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＡｄｄｒｅｓｓ（Ａｄｄｒｅｓｓ［］ａｄｄｒｅｓｓ）；ｐｕｂｌｉｃ  ｖｏｉｄ  ａｄｄＡｄｄｒｅｓｓＥｌｅｍｅｎｔ（Ａｄｄｒｅｓｓ  ａｄｄｒｅｓｓ）；及びｐｕｂｌｉｃ  ｂｏｏｌｅａｎ  ｒｅｍｏｖｅＡｄｄｒｅｓｓＥｌｅｍｅｎｔ（Ａｄｄｒｅｓｓ  ａｄｄｒｅｓｓ）を含むことができる。リモートメソッドは、ｐｕｂｌｉｃ  Ｃｏｌｌｅｃｔｉｏｎ  ｇｅｔＡｄｄｒｅｓｓＲｅｍｏｔｅ（）；ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＡｄｄｒｅｓｓＲｅｍｏｔｅ（Ｃｏｌｌｅｃｔｉｏｎ  ａｄｄｒｅｓｓ）；ｐｕｂｌｉｃ  ｖｏｉｄ  ａｄｄＡｄｄｒｅｓｓＥｌｅｍｅｎｔＲｅｍｏｔｅ（Ａｄｄｒｅｓｓ  ａｄｄｒｅｓｓ）；及びｐｕｂｌｉｃ  ｂｏｏｌｅａｎ  ｒｅｍｏｖｅＡｄｄｒｅｓｓＥｌｅｍｅｎｔＲｅｍｏｔｅ（Ａｄｄｒｅｓｓ  ａｄｄｒｅｓｓ）を含むことができる。
【００８１】
ｇｅｔＡｄｄｒｅｓｓＲｅｍｏｔｅ（）メソッドは、従業員オブジェクトに関連した全てのアドレスオブジェクトに対してｏｂｊｅｃｔＩｄのリストの取得をサポートする。いずれのアドレスオブジェクトもキャッシュする必要がないので、これに対してＣｍｏＱｕｅｒｙＣｕｒｓｏｒメカニズムを使用することができる。従って、ＣｍｏＱｕｅｒｙＣｕｒｓｏｒから拡張するＣｍｏＯｂｊｅｃｔＣｕｒｓｏｒと称される新たなクラスを形成して、ＥＪＢインスタンスのリモートカーソル作用をサポートする。このメソッドは、リモートホームインターフェイスを使用して対応ｅｊｂオブジェクトを見出すか又は形成し、そしてそれらをコレクションに記憶することをサポートする。これは、ｅｊｂオブジェクトのコレクションを返送する。ｓｅｔＡｄｄｒｅｓｓＲｅｍｏｔｅ（Ｃｏｌｌｅｃｔｉｏｎ  ａｄｄｒｅｓｓ）メソッドは、ローカルホームインターフェイスを使用して対応ｅｊｂオブジェクトを形成し又は見出すのをサポートする。これは、オブジェクトを配列体に記憶する。これは、更新すべき対応ローカルメソッドをコールする。
【００８２】
トランザクションサポートは、Ｊ２ＥＥプラットホームによりオファーされる重要なインフラストラクチャーサービスである。仕様は、ＪａｖａトランザクションＡＰＩ（ＪＴＡ）について規定する。ＪＴＡは、基礎となるトランザクションマネージャーへのアクセスを与えるインターフェイスである。主要インターフェイスの幾つかは、ｊａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ及びｊａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒを含む。ＵｓｅｒＴｒａｎｓａｃｔｉｏｎは、アプリケーションコンポーネントに露出され、一方、Ｊ２ＥＥサーバーとＪＴＡ  ＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒとの間の基礎的相互作用は、アプリケーションコンポーネントに対して透過的である。ＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒ実施は、（コンテナ−画定された）トランザクション境界のサーバー制御をサポートする。ＪＴＡ  ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ及びＪＤＢＣのトランザクションサポートは、両方とも、Ｊ２ＥＥアプリケーションコンポーネントに使用できる。Ｊ２ＥＥプラットホームは、２つのトランザクション管理パラダイン、即ち宣言的トランザクション画定及びプログラム的トランザクション確定をサポートする。
【００８３】
宣言的画定においては、コンテナは、トランザクションをスタートし、コミットしそしてロールバックする役割を果たす。コンテナは、クライアントによるビーン上の各オペレーションに対してトランザクションをスタートする。クライアントは、ＪＴＡトランザクションを取得して多数のオペレーションを１つのトランザクションにおいて実行する能力を有する。これは、オペレーションとオペレーションとの間に依存性を有するあるビジネスロジックを実施する融通性を与える。トランザクション属性は、宣言的トランザクション画定をサポートし、そしてそれに関連するＥＪＢコンポーネントのメソッドの意図されたトランザクション振舞いをコンテナへ渡される。
【００８４】
コンテナ管理トランザクション画定に対して、Ｒｅｑｕｉｒｅｄ、ＲｅｑｕｉｒｅｓＮｅｗ、ＮｏｔＳｕｐｐｏｒｔｅｄ、Ｓｕｐｐｏｒｔｓ、Ｍａｎｄａｔｏｒｙ及びＮｅｖｅｒの６つのトランザクション属性がサポートされる。Ｒｅｑｕｉｒｅｄトランザクション属性を伴うメソッドが、ＪＴＡトランザクション内で実行され、即ち環境に基づいて、新たなトランザクションコンテクストが形成されたり、されなかったりする。発呼コンポーネントがＪＴＡトランザクションに既に関連している場合には、コンテナは、前記トランザクションのコンテクストにおいてメソッドを呼び出す。トランザクションが発呼コンポーネントに関連していない場合には、コンテナは、新たなトランザクションコンテクストを自動的に形成し、そしてメソッドが完了したときにトランザクションをコミットするように試みる。
【００８５】
ＲｅｑｕｉｒｅｓＮｅｗトランザクション属性をもつメソッドが新たなトランザクションのコンテクストにおいて実行される。発呼コンポーネントがトランザクションコンテクストに既に関連している場合には、そのトランザクションが保留され、新たなトランザクションコンテクストが形成され、そしてその新たなトランザクションのコンテクストにおいてメソッドが実行され、その完了後に、発呼コンポーネントのトランザクションが再開される。ＮｏｔＳｕｐｐｏｒｔｅｄトランザクション属性をもつメソッドは、トランザクションの一部であると意図されない。発呼コンポーネントがトランザクションコンテクストに既に関連している場合には、コンテナがそのトランザクションを保留し、トランザクションに関連していないメソッドを呼び出し、そしてそのメソッドが完了すると、発呼コンポーネントのトランザクションを再開する。
【００８６】
Ｓｕｐｐｏｒｔｓトランザクション属性をもつメソッドは、発呼コンポーネントのトランザクション状態をサポートする。発呼コンポーネントがいかなるトランザクションコンポーネントももたない場合には、コンテナは、そのトランザクション属性がＮｏｔＳｕｐｐｏｒｔｅｄであったかのように、メソッドを実行する。発呼コンポーネントがトランザクションコンテクストに既に関連している場合には、コンテナは、そのトランザクション属性がＲｅｑｕｉｒｅｄであったかのように、メソッドを実行する。Ｍａｎｄａｔｏｒｙトランザクション属性をもつメソッドは、発呼コンポーネントのトランザクションコンテクストからコールされる。さもなければ、コンテナは、ｊａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＴｒａｎｓａｃｔｉｏｎＲｅｑｕｉｒｅｄＥｘｃｅｐｔｉｏｎを投入する。Ｎｅｖｅｒトランザクション属性をもつメソッドは、発呼コンポーネントのトランザクションコンテクストからコールされてはならない。
【００８７】
プログラム的トランザクション画定は、アプリケーションコード内のトランザクション管理のハードコード化である。プログラム的トランザクション画定は、セッションＥＪＢ、サーブレット、及びＪＳＰコンポーネントに対する重要なオプションである。プログラム的トランザクションは、ＪＤＢＣ又はＪＴＡのいずれかのトランザクションでよい。コンテナ管理セッションＥＪＢについては、全く勧められないが、ＪＤＢＣ及びＪＴＡトランザクションを混合することもできる。
【００８８】
本発明の１つの態様は、生産データをステージングする能力である。データベースにわたって複写しない問題を解決するために、１つの実施形態は、データのステージングされた値を、ライブ生産値と同じデータベースに記憶する。しかしながら、このようなステージングされた値は、ライブ生産値と同じテーブルに存在してはならない。ステージングされたデータが同じテーブルに存在する場合には、テーブルの性能及びサイズが影響を受ける。それ故、ステージング能力を必要とする各オブジェクトに対して、データベースに２つのテーブルが存在してもよい。付加的なテーブルが必要とされるので、ＯＲマッピングツールは、別のＪａｖａクラスがそのテーブルを表わすことを必要とする。ステージング可能なＩｍｐｌクラスについては、それに対応するＩｍｐｌＳクラスがある。クラス構造及びＯＲマッピングは、テーブルスキーマ形成と共に自動的に取り扱われるので、付加的なテーブル及び／又はクラスを追加するのに必要な努力が実質的に低減される。
【００８９】
既存のオブジェクトの属性を新たなオブジェクトにコピーすることは、一般的に簡単である。しかしながら、ステージングは、オブジェクト間の関係の変化をサポートしてもよい。全ての種々のステージング特徴をサポートするために、多数のルールを定義することができる。
【００９０】
１．ライブ生産オブジェクトインスタンスは、そのステージングされたインスタンスへの参照を有する。オブジェクトは、一度に一回しかステージングすることができない（換言すれば、そのステージングされたインスタンスに対して１対１の両方向性のプライベート所有関係を有する）。
【００９１】
２．オブジェクトがステージングされると、そのライブインスタンスを変更することができない。ライブインスタンスを変更できる場合には、ステージングされた値においてなされた変更とライブ値との合体を行なうことが必要になる。これは、不必要に複雑になる。典型的に、変更は、ライブオブジェクトにおいて直接的にステージング又は変更することが必要であるが、その両方が必要となることはない。
【００９２】
３．関係は、ステージングされたインスタンスではなく、ライブインスタンスでなければならない。さもなければ、多数の関係マッピングを管理しなければならない（ライブ対ステージング、ライブ対ライブ、ステージング対ライブ、及びステージング対ステージング）。更に、オブジェクトがステージングからライブへ又はそれとは逆に変化するときには、それを指す関係がその変化を管理することが必要となる。このルールは、これらの問題を簡単化する。更に、参照されているライブインスタンスは、ステージングすることができると共に、そのステージングされたインスタンスへの参照を有し、従って、本質的に、種々の関係を、直接的ではないが、依然サポートすることができる。
【００９３】
４．ステージング変化は、ステージング可能なオブジェクトの一部分でなければならない。ステージング変化のセットを管理する１つの方法は、それらをあるコンテナに結合することである。ステージング可能なオブジェクトは、ステージングされた全てのオブジェクトを追跡する。このオブジェクトは、次いで、配備することができ、テストのために配備することができ、又はキャンセルすることができる。
【００９４】
５．オブジェクトは、一度に一回しかステージングできず、一度に単一のステージング可能なオブジェクトの一部分であるに過ぎない。この場合も、管理の合体は、一般的に必要とされない。
【００９５】
１対１の関係をサポートすることは、ステージングされたテーブルでは、前記ルール＃３により容易である。全ての関係は、ライブインスタンスを指し、従って、別のオブジェクトを指すステージングされたテーブルのカラムは、該他のテーブルのライブインスタンスを指すだけでよい。１対多数の関係は、たとえその関係が両方向性であっても、中間関係テーブルを使用しなければならない。これは、ライブオブジェクトテーブルが、ステージングされたインスタンスに対する関係を知らねばならないことを防止する。
【００９６】
多数対多数の関係も、ステージングされたインスタンスをライブインスタンスにリンクする中間関係テーブルを有する。これらの中間関係テーブルは、既存のライブオブジェクト関係テーブルとは異なるものでなければならない。多数対多数の関係が両方向性である場合には、各方向に１つづつ、２つの中間関係テーブルを形成することが必要である。というのは、関係は、その関係の各側からステージングすることができ、そして異なる値をもつことができるからである。付加的な関係テーブルが自動的に且つ効果的に発生される。
【００９７】
本発明の更に別の態様は、いわゆるバックオフィスデータベースティアーではなく、中間ティアーにおける水平パーティショニングである。図１１は、水平パーティショニングを一般に示す。この例では、オブジェクトモデルは、コンポーネント１（１１０１）からｎ（１１０２）と、アカウント１１０３と、ＢＩ１１０４とを含む。コンポーネント１は、単一データベースであるメイン１１１１データベースへマップされる。コンポーネントｎは、メイン１１１１及びメイン１１１２データベースの両方にマップされ、データベースにわたって水平にパーティショニングされる。コンポーネントｎは、単一オブジェクトでもよいし、オブジェクトのグループでもよい。水平にパーティショニングされるオブジェクトのグループをグループ編成して指定するファシリティが有用となる。プロジェクトプロパティを設定するこのようなファシリティは、上述したが、レーショナル・ローズのユーザに馴染み易いものとなろう。或いは又、１つのグループ又は複数のグループにオブジェクトを割り当て、次いで、オーバーライドされることのないグループデフォールトプロパティ又はグループ巾のプロパティを設定するためのファシリティを設けることができる。いずれの実施形態でも、単一設定の結果として水平パーティショニングを受ける（又は受けない）オブジェクトのグループをもつことが有用である。この例では、コンポーネント１．．ｎのマッピングは、データベースの宣言により構成されてもよい。ユーザ完成テーブル又はユーザ読み取り可能な（例えば、ＸＭＬ）構成ファイルのような宣言解決策を使用して、データベースの論理的な前を指定し、及び／又はデータベースの論理的名前をオブジェクト及びオブジェクトのグループに接続することができる。この例では、アカウント及びＢＩは、各々、セキュア１１１３及びＢＩ１１１４データベースにマップされている。
【００９８】
中間ティアーにおける水平パーティショニングをサポートするクラスは、データベース又はデータベースインフラストラクチャーへのインターフェイス、このインスタンスではＴｏｐＬｉｎｋ、に適応される。図１２は、中間ティアーにおける水平パーティショニングを実施するのに使用できるクラスを示す。この図は、ＣｍｏＳｅｒｖｅｒＳｅｓｓｉｏｎ１２２１をもつ左上から始めて最も容易に理解される。このオブジェクトは、インフラストラクチャーにより必要とされるデータベース接続及び情報を保持する。データベースの論理的識別は静的であるから、このオブジェクトは、静的データ及び静的メソッドをもつことができると共に、多数のユーザにより分担することができる。
【００９９】
ＣｍｏＳｙｓｔｅｍＳｅｓｓｉｏｎ１２３１は、サーバーセッション１２２１から得ることができる。サーバーに対して単一のシステムセッションオブジェクトを形成するだけでよい。ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクト１２４１は、サーバーの各ユーザに対してコンテクスト及び状態情報を保持する。これは、ユーザの位置及びログインのようなユーザ特有の情報を保持する。ＨＴＴＰセッションに対して維持される状態情報と同様の状態情報が維持される。コンテクスト情報を設定するためにメソッドｇｅｔＤｂ及びｓｅｔＤｂが使用される。クライアントセッションは、多数のデータベースを含んでもよい。クライアントセッション１２４１と、アクティブなデータベースセッション１２４２との間の関係＃ｄｂＣｌｉｅｎｔＳｅｓｓｉｏｎは、０．．＊関係である。クライアントセッションが得られたときに、アクティブなデータベースクライアントセッションはない。クライアントセッションの寿命中に、多数のデータベースクライアントセッションがアクティブになり得る。
【０１００】
この図におけるオブジェクトＣｍｏＴｒａｎｓａｃｔｉｏｎ１２５１は、水平にパーティショニングされるべきデータをバッファする。このＣｍｏＴｒａｎｓａｃｔｉｏｎのロールは、トランザクションが読み取られてコミットされるまで、長寿命のトランザクションを含むトランザクションの状態を維持することである。トランザクションがアッセンブルされるときに、新たな又は変更されたオブジェクトが属するデータベースの分析を許す情報が収集される。トランザクションをコミットする準備ができると、ＣｍｏＤａｔａｂａｓｅＴｒａｎｓａｃｔｉｏｎ１２５２の１つ以上のインスタンスにより１つ以上のデータベースにおいてそれをコミットすることができる。
【０１０１】
中間カラムオブジェクト１２１２、１２２２、１２３２、１２４２及び１２５２を含む水平パーティショニングサポートを、インフラストラクチャーインターフェイス１２２３、１２４３及び１２５３と、露呈されたセッション１２２１、１２４１及び１２５１との既存の構成に追加することができ、しかも、セッションが露呈されるやり方や、それらが露呈される動作ビジネスロジックを変更することはない。例えば、水平パーティショニングを使用して、２つの自動車製造者Ｆ及びＧが同じコード及びソフトウェアを使用するのをサポートすることができる。Ｆに対する全てのデータが、例えば、オラクルデータベースへとパーティショニングされ、そしてＧに対する全てのデータが、ＳＱＬデータベースへとパーティショニングされる。コンテクストＦ又はＧが、例えば、ユーザのログインにおいて設定されると、データのパーティショニングがシステムに透過的となる。Ｆのデータに対する全てのコールは、オラクルデータベースに対して実行され、そしてＧのデータに対する全てのコールは、ＳＱＬデータベースに対して実行される。データサービスがＦに与えられたかＧに与えられたかに関わらず、同じロジックを適用することができる。
【０１０２】
ビジネスロジックを実施するコードは、分担することもできる。というのは、コンテクストの設定だけがＦ及びＧのデータを識別又は区別するからである。このレベルでのパーティショニングは、カスタマーのデータを分離する。小さいデータベースほど、より効率的に取り扱われる。Ｆによるサーチは、バックオフィスデータベースサーバーレベルにおいても、Ｇのデータを見つけることがない。ＳＱＬ、ＱＬ又は他のデータベース問合せコードにおける混合は、２つ以上のデータベースからのデータを返信することができず、これは、１人のカスタマーが別のカスタマーのデータに再びアクセスできる機会を減少する。これは、原告及び被告の弁護士がデータベースのあるコンポーネントを共有するがそれらの仕事の成果を厳密に分離して保持することを希望するとき、又は競合者が同じ付加価値サービスを利用し且つサービス売主が両カスタマー（競合者）にそれらのデータが安全であることを保証するときのような、競合する状態において特に有用である。カスタマーのデータが他のカスタマーから安全に保持される間に、多数のカスタマーコンテクストにわたって繰り返すシステム管理者により定期的な保守機能を達成することができる。
【０１０３】
中間カラムオブジェクト１２１２、１２２２、１２３２、１２４２及び１２５２は、コンテクストに基づいて多数のデータベースへのサクセスをサポートする一方、多数のデータベースは、同じオブジェクトの水平にパーティショニングされたインスタンスを記憶する。ＣｍｏＤａｔａｂａｓｅＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト１２２２は、サーバーにおいてアクティブな各データベースに対して存在する。データベースは、オブジェクトのキー型属性ｄｂＮａｍｅとして維持することのできる論理的な名前により、ＣｍｏＤａｔａｂａｓｅＳｅｒｖｅｒＳｅｓｓｉｏｎオブジェクト１２２２に対して論理的に識別される。
【０１０４】
ｇｅｔＡｌｌＶｅｒｓｉｏｎｓメソッドは、バージョンの管理をサポートする。このメソッドは、データベースにおけるオブジェクトのバージョン又はスキーマのバージョンを返送することができる。データベースにアクセスするコード又はデータベースへのアクセスを許可するコードは、バージョンが非適合でないことをチェックしなければならない。ＣｏｍＣｌａｓｓＣｏｎｆｉｇｕｒａｔｉｏｎオブジェクト１２１２は、オブジェクトをデータベースに接続する。１つのＣｏｍＣｌａｓｓＣｏｎｆｉｇｕｒａｔｉｏｎオブジェクト１２１２は、データベースにおいてアクセス可能なオブジェクトを表わす。ＣｕＤａｔａｂａｓｅＣｏｎｇｉｇ１２３２は、論理的データベース名に対応する物理的データベース構成情報を保持する。この情報を使用して、多数の物理的データベースを、コンテクストセットに基づいて単一の論理名に接続することができる。ＣｍｏＤａｔａｂａｓｅＳｅｒｖｅｒＳｅｓｓｉｏｎ１２２２は、＃ｓｅｒｖｅｒＳｅｓｓｉｏｎ関係によりインフラストラクチャーオブジェクトＳｅｒｖｅｒＳｅｓｓｉｏｎ１２２３に接続される。ＣｏｍＤａｔａｂａｓｅＣｌｉｅｎｔＳｅｓｓｉｏｎ１２４２は、クライアントのコンテクスト（前記例におけるＦ又はＧ）を考慮して、インフラストラクチャーオブジェクトＣｌｉｅｎｔＳｅｓｓｉｏｎ１２４３と共にクライアントセッションを管理する。
【０１０５】
ＣｍｏＴｒａｎｓａｃｔｉｏｎ１２５１のオペレーションに戻ると、トランザクションをコミットする用意ができたときに、ＣｍｏＴｒａｎｓａｃｔｉｏｎは、適切なコンテクストセットを伴うＣｍｏＤａｔａｂａｓｅＴｒａｎｓａｃｔｉｏｎ１２５２を呼び出す。このＣｍｏＤａｔａｂａｓｅＴｒａｎｓａｃｔｉｏｎ１２５２は、オブジェクトの１段階又は２段階コミットを取り扱うために、インフラストラクチャーオブジェクト１２５３、例えば、ＴｏｐＬｉｎｋのＵｎｉｔＯｆＷｏｒｋに接続される。
【０１０６】
２段階コミットは、原子的形態で多数の物理的データベースにわたり変化をコミットするトランザクションプロトコルである。一実施形態において、２段階コミットをサポートするソフトウェアコンポーネントは、ＪＴＳベースのアプリケーションサーバー（いずれかのＪ２ＥＥ  １．３適合ＡｐｐＳｅｒｖｅｒ）と、ＪＤＢＣドライバにおける分散型トランザクションサポート（例えば、Ｏｐｔａ２０００及びＳｅｒｏｐｔｏ）と、データベースにおける分散型トランザクションサポート（例えば、ＳＱＬサーバー及びオラクル）とを含む。ＣＯＦ及びＣＯＦ／ＥＪＢは、ＴｏｐＬｉｎｋを使用して、ＪＴＳベース（Ｊａｖａトランザクションサービス）トランザクションマネージャー（通常、Ｊ２ＥＥアプリケーションサーバーにより与えられる）とのトランザクション一体化をサポートする。２段階コミットの使用は、任意である。２段階コミットは、非常に高価であり、従って、必要なときしか使用されない。多数のオブジェクトに影響しそして多数の物理的データベースに及ぶユーザトランザクションは、通常、２段階コミットトランザクションを使用する。ＥＪＢオブジェクト及びＣＯＦオブジェクトを単一のトランザクションにおいてコミットする必要があるときには、２段階コミットが適当である。このプロトコルは、ＣＯＦオブジェクト、水平にパーティショニングされるオブジェクト、及びＥＪＢオブジェクトの組合せで使用することができる。
【０１０７】
水平パーティショニングは、ＣＯＦ又は別のプロトコルが直接使用されるか、或いはＥＪＢ又は別のリモートメソッド呼び出しカプセル化においてカプセル化されるかに依存しない。中間ティアーカプセル化は、データベースマネージャーに依存せずに、独立したデータベースにわたる水平パーティショニングを取り扱う。これは、独立したデータベースが、異なるデータベース売主からの非適合のデータベースでもよいので、緩く結合された水平パーティショニングとも称される。
【０１０８】
この場合も、水平パーティショニングを使用するために変更する必要のあるビジネスロジック又はシステムコードは、比較的わずかである。幾つかの基本的なルールを以下に列挙する。
【０１０９】
１．構成ファイルにおいて１つのデータベースしか使用されない場合には（これは、プロパティ「ｄａｔａｂａｓｅ．ｐｒｏｊｅｃｔｓ」の値が単一であることを意味する）、このデータベースが常に使用される。
【０１１０】
２．構成ファイルに２つ以上のデータベースが存在する場合には、オペレーションを実行するときにデータベース情報が明確に又は暗示的に分析される。明確な分析とは、ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎオブジェクト及び／又はＣｍｏＴｒａｎｓａｃｔｉｏｎオブジェクトにおいて「ｓｅｔＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ）」がコールされることを意味する。このＣｕＤａｔａｂａｓｅＣｏｎｆｉｇオブジェクトは、通常、システム設定時間中に形成される。「ＣｍｏＳｅｒｖｅｒＳｅｓｓｉｏｎ．ｇｅｔＡｖａｉｌａｂｌｅＤｂＯｂｊｅｃｔｓ（）」は、全システムに対して使用できるデータベースオブジェクトのリストを得るために使用される。特定のクラスに対して、「ＣｍｏＳｅｒｖｅｒＳｅｓｓｉｏｎ．ｇｅｔＤｂＯｂｊｅｃｔｓＦｏｒＣｌａｓｓ（Ｃｌａｓｓ  ａＣｌａｓｓ）」及び「ＣｍｏＳｅｒｖｅｒＳｅｓｓｉｏｎ．ｇｅｔＤｂＯｂｊｅｃｔｓＦｏｒＣｌａｓｓ（Ｓｔｒｉｎｇ  ａＣｌａｓｓＮａｍｅ）」は、「クラス」が存在するＣｕＤａｔａｂａｓｅＣｏｎｆｉｇオブジェクトのリストを返送する。暗示的分析とは、ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎ及び／又はＣｍｏＴｒａｎｓａｃｔｉｏｎオブジェクトが、以下に述べるように、特にアプリケーションコードにおいて「ｓｅｔＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ）」をコールせずに、どのデータベースが作用するかインテリジェントに見つけられることを意味する。
【０１１１】
３．ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎ及びＣｍｏＴｒａｎｓａｃｔｉｏｎオブジェクトにおいてデータベース情報を明確に分析できないときには、セッションオブジェクトは、呼び出された全てのオブジェクトを使用することによりこれを分析するように試みる。呼び出されたいずれかのオブジェクトが、あるデータベース情報（nullではない）を有する場合には、この情報が、セッションオブジェクトに関連したデータベース情報と比較される。セッションオブジェクトに対するデータベース情報がnullである場合には、それが、オブジェクトからのデータベース情報にセットされ、又は、情報が同じでない場合には、例外が投入される。このロジックは、呼び出された全てのオブジェクトに対して続けられる。オペレーション及び／又はトランザクションに対してデータベース情報の識別を助けるために、ＣＯＦは、新たなインターフェイス「ＣｍｏＤｂＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅｒ」を導入した。ＣｍｏＤｂＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅｒオブジェクトは、１つのオブジェクトに対して構成される。これは、キーがｄａｔａｂａｓｅ．ｃｏｎｆｌｉｃｔｒｅｓｏｌｖｅｒ．｛オブジェクトの全クラス名｝＝｛ＣｍｏＤｂＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅｒインターフェイスを実施する全クラス名｝であるような構成において行うことができる。
【０１１２】
４．リゾルバー（分析体）は、考えられる最後の瞬間にコールされる。オブジェクトが形成されることを意味するときには、オブジェクトのコミットが試みられるまでコールされない。これは、リゾルバーが、オブジェクトの全属性が形成についてセットされたことを予想でき、そしてそれらを使用して、オブジェクトがどのデータベースに属するべきか決定できることを意味する。
【０１１３】
ここに見られるケースでは、問合わされている属性に基づいてどのデータベースに問合せるべきかリゾルバーが決定できるように、表現又は属性問合せ或いは属性マップ問合せがパスされる。単一の問い合わせにおいてデータベースを横切る問合せをサポートすることはできない。この場合も、これは、ｓｅｔＤｂがｃｌｉｅｎｔＳｅｓｓｉｏｎにおいてまだコールされておらず且つ問合せされているオブジェクトが２つ以上のデータベースに存在するように構成された場合にしか必要とされない。
【０１１４】
ＣｍｏＤｂＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅｒを実施できる方法は、ある構成情報を使用するか或いはおそらく他の何らかの動的なデータを使用して、特定の物理的データベースへのあるオブジェクト属性値のマッピングをそれに通知することである。これは、できるだけ簡単に保持されねばならない。例えば、オブジェクトの組織ｉｄを使用して、どのデータベースか決定し、そしておそらく、データベースがｏｒｇＩｄに基づいて命名され、簡単なマッピングとされる。これらのデータベース名は、データベースに名前を与え、ひいては、それがどこに位置するか等の構成情報を与えるために、構成／設置時間に決定される「論理的」名前である。従って、ここで使用する名前は、論理的な名前で、アクセスすべきデータベース構成の名前を表わし、データベースシステムにおける実際の物理的なデータベース名を表わすものではない。
【０１１５】
クライアントセッションでは、データベース情報を制御するために４つの機能を使用することができる。それらは、ｓｅｔＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ）、ｇｅｔＤｂ（）、ｏｖｅｒｒｉｄｅＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ）、及びｒｅｓｔＤｂ（）である。ｇｅｔＤｂ（）は、クライアントセッションオブジェクトにおいてセットされた現在データベースを単に返送し、ｏｖｅｒｒｉｄｅＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ  ａＮｅｗｄｂ）及びｒｅｓｅｔＤｂ（）は、スタックメカニズムを使用して、クライアントセッションにおけるｄｂ  ｉｎｆｏの変化を追跡する。ｏｖｅｒｒｉｄｅＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ  ａＮｅｗｄｂ）は、現在ｄｂをスタックへプッシュし、そして現在ｄｂを、パスされた「ａＮｅｗＤｂ」にセットする。ｒｅｓｅｔＤｂ（）は、現在ｄｂを、スタックが空でない場合にスタックの最上位エレメントにセットし、さもなければ、ひっそりとして何も行なわない。ｓｅｔＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ  ａＮｅｗＤｂ２）は、現在ｄｂを「ａＮｅｗＤｂ２」にセットし、そしてスタックをクリアする。従って、スタックが何らかの情報をもつときにｓｅｔＤｂ（）がコールされた場合には、スタックが単にクリアされる。特殊なクライアントセッションであるシステムクライアントセッションオブジェクトは、これら４つの機能をスレッドベースで使用する。従って、１つのスレッドに対するデータベース情報は、別のスレッドとで行なうべきものを何ももたない。
【０１１６】
ｏｖｅｒｒｉｄｅＤｂ（ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇ  ａＤｂＣｏｎｆｉｇ）及びｒｅｓｅｔＤｂ（）機能は、ＣｍｏＴｒａｎｓａｃｔｉｏｎにおいてコールすることができないが、ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎのサブクラスである。
【０１１７】
ＣｍｏＤｂＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅｒ  ＡＰＩは、ｐｕｂｌｉｃ  ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇｒｅｓｏｖｌｅＣｒｅａｔｅ（ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏ  ａＤｂＲｅｓｏｌｖｅｒＩｎｆｏ）ｔｈｒｏｗｓＣｅＤｂＮａｍｅＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅＥｘｃｅｐｔｉｏｎ；ｐｕｂｌｉｃ  ＣｕＤａｔａｂａｓｅＣｏｎｆｉｇｒｅｓｏｖｌｅＦｉｎｄ（ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏ  ａＤｂＲｅｓｏｌｖｅｒＩｎｆｏ）ｔｈｒｏｗｓＣｅＤｂＮａｍｅＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅＥｘｃｅｐｔｉｏｎを含む。ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏ  ＡＰＩは、ｐｕｂｌｉｃ  ＣｍｏＣｌｉｅｎｔＳｅｓｓｉｏｎ  ｇｅｔＣｌｉｅｎｔＳｅｓｓｉｏｎ（）；ｐｕｂｌｉｃ  Ｃｌａｓｓ  ｇｅｔＭａｉｎＣｌａｓｓ（）；ｐｕｂｌｉｃ  ＨａｓｈＭａｐ  ｇｅｔＡｔｔＶａｌｕｅＰａｉｒｓ（）；ｐｕｂｌｉｃ  ＣｍｏＦｉｎｄＯｂｊｅｃｔ  ｇｅｔＦｉｎｄＯｂｊｅｃｔ（）；及びｐｕｂｌｉｃ  ＣｍｏＳａｓｅ  ｇｅｔＮｅｗｌｙＣｒｅａｔｅｄＯｂｊｅｃｔ（）を含む。
【０１１８】
ＣｍｏＤｂＣｏｎｆｌｉｃｔＲｅｓｏｌｖｅｒインターフェイスを実施するクラスが開発されると、ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏにおけるｇｅｔＮｅｗｌｙＣｒｅａｔｅｄＯｂｊｅｃｔ（）を使用して、ｒｅｓｏｌｖｅｒＣｒｅａｔｅ（ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏ）の実施を助けることができ、同様に、ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏにおけるｇｅｔＡｔｔＶａｌｕｅＰａｉｒｓ（）及び／又はｇｅｔＦｉｎｄＯｂｊｅｃｔ（）は、ｒｅｓｏｌｖｅＦｉｎｄ（ＣｍｏＤｂＲｅｓｏｌｖｅｒＩｎｆｏ）の実施において有用である。
【０１１９】
以上の説明から、当業者であれば、本発明の態様及び要素から種々様々なシステム及び方法を構成できることが明らかとなろう。本発明の一実施形態は、アプリケーション開発コードを発生する方法を含む。或いは又、この方法は、この方法のステップを実行するシステム又は装置として実施されてもよい。このシステム又は装置は、方法のステップ、態様、オプション及び別の実施例を含む多数の実施形態を包含してもよい。又、この方法は、この方法のステップを実行するプログラムが刻印された磁気媒体として実施されてもよい。このプログラムは、この方法のステップ、態様、オプション及び別の実施例を結合する多数の実施形態を包含してもよい。開発コードの発生は、マルチティアードカプセル化ビジネスアプリケーション環境に特に適用することができる。この方法は、オブジェクト指向のアプリケーション設計のオブジェクト、関係及びオペレーションのモデルをベースとする。これらオブジェクト、関係及びオペレーションのモデリングは、グラフィックツールを使用して、視覚的に実施されてもよい。オブジェクト、関係及び／又はオペレーションに割り当てられたプロパティは、モデリングされたオブジェクトへのインターフェイスを発生すべきかどうかを指示する第１プロパティを含んでもよい。これは、指定されたオペレーションへのローカル及び／又はリモートインターフェイスを発生すべきかどうか指示する第２プロパティを含んでもよい。このモデルから、モデル及びそのプロパティに対応するマシン読み取り可能なデータが発生される。このデータは、内部モデル又はエクスポートされたモデルにおいて実施されてもよい。このモデルは、マシンでしか読み取れないものでもよいし、又は人間が読み取れるものでもよい。マシン読み取り可能なデータは、モデルをデータベースにマップするのに使用される。
【０１２０】
一実施形態において、データベースは、関係データベースである。マッピング及びマシン読み取り可能なデータを使用してアプリケーション開発コードが発生される。発生されたアプリケーションコードは、データベースにおいてオブジェクトを持続させ且つそれにアクセスするためのコードを含むことができる。これは、更に、第１プロパティと一貫した、前記オブジェクトを持続させ且つそれにアクセスするためのコードへのインターフェイスを含むことができる。これは、更に、第２プロパティと一貫した、前記指定のオペレーションへのインターフェイスを含むことができる。コード及び指定のオペレーションへのインターフェイスは、規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合し得る。或いは又、アプリケーション開発コードは、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎ（ＥＪＢ）規格２．０以降のものに実質的に適合してもよい。ＥＪＢオブジェクトを持続させ且つそれにアクセスするためのコードは、「ビーン・マネージド・パーシステンス（ＢＭＰ）」プロトコルに実質的に適合してもよい。或いは又、アプリケーション開発コードは、マイクロソフトのＤＣＯＭ仕様に実質的に適合してもよい。本発明の別の態様において、オブジェクト指向のアプリケーション設計は、「ユニファイドモデリング言語（ＵＭＬ）」規格に実質的に適合してもよい。
【０１２１】
アプリケーション開発コード方法の１つの態様は、カスタムビジネスロジックを追加すべきスタブの発生メソッドを含む。本発明のこの態様の実施において、システムのオブジェクト指向のモデルが変更されるときに再生されるコードは、カスタムビジネスロジックを含むコードから分離され、オブジェクト指向のモデルが変更されるときにオーバーライト又は再生されてはならない。
【０１２２】
本発明の別の態様は、更に、オブジェクト及び関係の複数の第３プロパティを含み、これら第３プロパティは、マッピングステップを制御する。これらプロパティは、オブジェクト及び関係を、関係データベースのような基礎的なデータベースにマップするのに使用される。これら第３プロパティは、モデリングされたオブジェクトの配備のステージングをサポートすべきかどうかを含んでもよい。それらは、モデリングされたオブジェクトの配備の変更経歴を記録すべきかどうかを含んでもよい。更に、モデリングされたオブジェクト内に１つ以上のフィールドを動的に配列してこれらのフィールドを国際化すべきかどうかを含んでもよい。フィールドを動的に配列することを含む本発明の態様に関連して、モデリングされたオブジェクトを持続させ且つそれにアクセスするためのコードは、指定された言語に基づいて動的配列のどの要素を検索すべきか分析することができる。この言語は、取り扱われるオブジェクトに存在するデータにより暗示的に指定されてもよいし、又は言語により明確に指定されてもよい。
【０１２３】
本発明の更に別の態様は、どんなアプリケーションコードを発生するかユーザが指定できると共に、マシン読み取り可能なデータを発生し、マッピングしそして付加的に発生する方法ステップを、ユーザによる更なるアクションを必要とせずに進められることである。
【０１２４】
本発明の更に別の実施形態は、トランザクション処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブルする方法にある。或いは又、この方法は、その方法のステップを実行するシステム又は装置として実施されてもよい。このシステム又は装置は、方法のステップ、態様、オプション及び別の実施例を含む多数の実施形態を包含してもよい。又、この方法は、この方法のステップを実行するプログラムが刻印された磁気媒体として実施されてもよい。この方法は、データベースマネージャーのトランザクション処理サポートにより、データにアクセスし且つそれを持続するメソッドのオブジェクト指向のフレームワークを設けることを含んでもよい。更に、規格ベースのサーバー側コンポーネントモデル及びリモート呼び出しプロトコルに実質的に適合するオブジェクト指向のフレームワークのバージョンを設けることも含む。規格ベースのサーバー側コンポーネントモデル及びリモート呼び出しプロトコルは、例えば、Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ（ＥＪＢ）、分散型共通オブジェクトモデル（ＤＣＯＭ）、及びＣＯＢＲＡを含む。
【０１２５】
トランザクションをアッセンブルする方法は、更に、１つ以上のデータベースに向けられるトランザクション関連アクティビティを受け入れ又はバッファすることを含んでもよい。この受け入れ又はバッファすることは、オブジェクト指向のフレームワーク、及びオブジェクト指向のフレームワークの規格適合バージョンにより同時に行うことができる。この実施形態の１つの態様は、受け入れステップが、オブジェクトをバッファすることを含み、そしてトランザクションをコミットする指令の際に、この方法は、更に、データベースマネージャーを呼び出してトランザクションを処理することを含む。この態様は、データベースマネージャー以外のメカニズムによりトランザクション関連アクティビティを受け入れることを含む。本発明のこの態様は、ＥＪＢ、ＤＣＯＭ及びＣＯＢＲＡを含む上述したいずれかの規格で実施されてもよい。
【０１２６】
本発明の付加的な実施形態は、トランザクション処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブルする方法にある。上述したように、この方法は、この方法を実施するプログラムを含むメソッド、装置又は磁気媒体として実施されてもよい。この実施形態の別の方法は、上述したアッセンブル方法における厳密な変形である。１つの変形は、データベースマネージャーのトランザクション処理サポートにより、データにアクセスし且つそれを持続させる方法のオブジェクト指向のフレームワークを与えることを含む。この方法は、更に、ＥＪＢ規格適用取り扱い及び呼び出しに適応されたオブジェクト指向のフレームワークのバージョンを設けることを含む。更に、１つ以上のデータベースに向けられたトランザクション関連アクティビティを、オブジェクト指向のフレームワーク、及びオブジェクト指向のフレームワークのＥＪＢ規格適合バージョンにより同時に受け入れることも含む。この実施形態の他の２つの変形において、オブジェクト指向のフレームワークは、ＤＣＯＭ仕様又はＣＯＢＲＡに適合するようにされる。これら変形のいずれにおいても、受け入れスタッフは、オブジェクトをバッファし、そしてトランザクションをコミットする指令の際に、データベースマネージャーを呼び出して、トランザクションを処理することを含んでもよい。
【０１２７】
別の実施形態は、少なくとも１つのデータベースマネージャーで処理されたデータを持続させる方法にある。上述したように、この方法も、これを実施するプログラムを含むメソッド、装置又は磁気媒体として実施されてもよい。データを持続させるこの方法は、データベースマネージャーによりデータにアクセスし且つそれを持続させるメソッドのオブジェクト指向のフレームワークを与えることを含む。更に、データベースマネージャーによりデータにアクセスし且つそれを持続させるメソッドへの規格適合インターフェイスを与えることも含む。これらの規格適合インターフェイスは、ＥＪＢ、ＤＣＯＭ又はＣＯＢＲＡに適合するものでよい。この方法は、更に、オブジェクト指向のフレームワーク及び規格適合インターフェイスを経て同時に１つ以上のデータベースに向けられたオブジェクトアクセス及び持続要求を受け入れることも含む。規格がＥＪＢであるときには、オブジェクト要求は、オブジェクト指向のフレームワーク及びＥＪＢ規格適合インターフェイスの両方によりＪａｖａトランザクションサービスエンジンへ提出されてもよい。
【０１２８】
以上の実施形態のいずれにも適用できる本発明の態様は、オブジェクト指向のフレームワークが、データベースへの微粒状オブジェクトを持続させるよう適応されることである。ＥＪＢ規格適合インターフェイスを含む規格適合インターフェイスは、２つ以上のデータベースへのトランザクションにおいてオブジェクトを持続させるよう適応される。
【０１２９】
本発明の更に別の実施形態は、トランザクション処理をサポートする少なくとも１つのデータベースマネージャーにより処理されるべきトランザクションをアッセンブルする方法にある。上述したように、この方法も、これを実施するプログラムを含むメソッド、装置又は磁気媒体として実施されてもよい。この方法は、データマネージャーのトランザクション処理サポートによりデータにアクセスし且つそれを持続させると共に付加的な機能も実行するメソッドのオブジェクト指向のフレームワークを与えることを含む。この付加的な機能は、生産システムへの追加及びテストのためにオブジェクトをステージングすることでよい。又、生産システムにおけるオブジェクトの変更経歴を追跡してもよい。或いは、オブジェクト内にフィールドを動的に配列して、フィールドを国際化してもよい。これらの付加的な機能は、対として又は全体的に結合されてもよい。トランザクションをアッセンブルする方法は、更に、規格ベースのサーバー側コンポーネントモデル及びリモートメソッド呼び出しプロトコルに実質的に適合するオブジェクト指向のフレームワークのバージョンを付加的に与えることを含み、このバージョンは、上述した付加的な機能の１つ以上も含む。別の実施形態は、付加的な機能の各々を個々に含み、付加的な機能の対の組合せを含み、且つ３つ全部の付加的な機能を含む。トランザクションをアッセンブルするこの方法が適合する規格は、ＥＪＢ、ＤＣＯＭ又はＣＯＢＲＡでよい。
【０１３０】
本発明の異なる実施形態は、データベース及び水平にパーティショニングされるマルチティアービジネスアプリケーションを発生する方法にある。上述したように、この方法も、これを実施するプログラムを含むメソッド、装置又は磁気媒体として実施されてもよい。この方法は、オブジェクト及び関係をモデリングしそしてオブジェクト指向のアプリケーション設計のオペレーションを指定することを含み、ここで、オブジェクトのプロパティは、多数のデータベースにわたりオブジェクトを水平にパーティショニングすべきかどうかを含む。この解決策は、オブジェクト又はオブジェクトのグループのいずれに適用されてもよい。オブジェクトのグループは、単一の論理名で表わされてもよい。この方法は、更に、プロパティを含む、モデルに対応するマシン読み取り可能なデータを発生することを含む。このマシン読み取り可能なデータは、マシンでしか読み取れないものでもよいし、又はＸＭＬ仕様の場合のように、人間が読み取れるものでもよい。この方法は、更に、マシン読み取り可能なデータを使用して複数のデータベースへモデルをマッピングし、そしてこのマッピング及びマシン読み取り可能なデータからアプリケーション開発コードを付加的に発生することを含む。アプリケーション開発コードは、複数のデータベースにわたりオブジェクトを持続させ且つそれにアクセスするためのコードを含む。オブジェクトを持続させ且つそれにアクセスするためのコードは、データベースティアーの上の中間のプログラムティアーの一部分である。本発明の更に別の態様は、オブジェクトを持続させ且つそれにアクセスするためのコードが複数の独立したデータベースを呼び出せることである。これらの独立したデータベースは、異なるデータベース売主により供給されてもよいし、或いは単一のデータベース売主により供給されて独立して動作してもよい。この実施形態の更に別の態様は、オブジェクトがパーティショニングされるところの複数のデータベースを宣言し、そしてオブジェクト又はオブジェクトのグループを特定のデータベースにパーティショニングするために使用される１つ以上のフィールドを宣言することを含んでもよい。
【０１３１】
本発明の更に別の実施形態は、少なくともデータベースティアー及び中間のビジネスアプリケーションティアーを含むマルチティアービジネスアプリケーションにおいて、多数の独立したデータベースにわたりオブジェクトの水平パーティショニングを実施する方法にある。上述したように、この方法も、これを実施するプログラムを含むメソッド、装置又は磁気媒体として実施されてもよい。この実施形態は、特定のオブジェクトを特定のデータベースに割り当てるのに使用できる少なくとも１つの水平にパーティショニングされたオブジェクトにおいて１つ以上のフィールドを宣言することを含む。又、水平にパーティショニングされたオブジェクトが属する全てのデータベースとの接続を確立する必要はないが、水平にパーティショニングされたオブジェクトが属する複数のデータベースとの接続を確立することを含む。接続を確立する前又は後に、この方法は、水平にパーティショニングされたオブジェクトを含む１つ以上のオブジェクトを、探索、形成、或いは探索又は形成するためにバッファすることを含む。探索又は形成を進めるための指令の際に、オブジェクトが属する特定のデータベースを、宣言されたフィールドを使用して分析し、そしてデータベースティアーにおいて特定のデータベースを呼び出して、探索又は形成を実行することを含む。同様の実施形態は、多数の独立したデータベースにわたりオブジェクトの水平パーティショニングを実施する方法であって、少なくとも１つの水平にパーティショニングされたオブジェクトが属する複数のデータベースとの接続を確立することを含む方法にある。更に、水平にパーティショニングされたオブジェクトが属する特定のデータベースを設定し又は識別することも含む。この設定ステップの前又は後に、水平にパーティショニングされたオブジェクトを含む１つ以上のオブジェクトを、探索、形成、或いは探索又は形成するためにバッファすることを含む。探索又は形成を進めるための指令の際に、データベースティアーにおいて特定のデータベースを呼び出して、探索又は形成を実行することを含む。水平にパーティショニングされたオブジェクトが属する複数のデータベースを、単一の論理名で集合的に参照することができる。水平にパーティショニングされたオブジェクトの１つ以上の属性を使用して、複数のデータベースの中の特定のデータベースが論理的にマップされる。これらの属性は、水平パーティションオブジェクトのフィールドでよい。
【０１３２】
本発明は、上述した好ましい実施形態及び実施例を参照して開示したが、これは、本発明を単に例示するもので、何ら限定するものではない。前記実施形態ではコンピュータ援助による処理が暗示された。したがって、本発明は、コンピュータ援助による処理のための方法、この方法を実施するロジックを含むシステム、この方法を実施するロジックが刻印された媒体、この方法を実施するロジックが刻印されたデータストリーム、或いはコンピュータアクセス可能な処理サービスにおいて実施されてもよい。又、当業者であれば、特許請求の範囲に規定する本発明の精神及び範囲から逸脱せずに多数の変更や組合せが明らかとなろう。
【図面の簡単な説明】
【０１３３】
【図１】マルチティアードアプリケーションの高レベルブロック図である。
【図２】ＥＪＢオンＪ２ＥＥサーバーを使用して共通オブジェクトフレームワークをいかに実施して中間ティアーを与えるかを示す図である。
【図３】視覚的にモデリングされた単純なショッピングカートアプリケーションのためのオブジェクト及び関係を示す図である。
【図４】クラスプロパティを指定するためのポップアップウインドウに追加されたＣＢＯＦタブ４０１を示す図である。
【図５】オペレーションプロパティを指定するためのポップアップウインドウに追加されたＣＢＯＦタブ４０１を示す図である。
【図６】ＥＪＢラッピングに適応させることのできるＣＢＯＦモデルを示す図である。
【図７】ＥＪＢ及びＪ２ＥＥをサポートするように適応されるクラスＣｍｏＢａｓｅ７０１、ＣｍｓＢａｓｅ７０２及びＣｍｏＡｔｔｒｉｂｕｔｅ７０３の態様を示すクラス図である。
【図８】ＥＪＢ及びＪ２ＥＥサポートへのＣＯＦツール及びモデルの適応を示す図である。
【図９】ＥＪＢ及びＪ２ＥＥサポートへのＣＯＦツール及びモデルの適応を示す図である。
【図１０】ＥＪＢ及びＪ２ＥＥサポートへのＣＯＦツール及びモデルの適応を示す図である。
【図１１】水平パーティショニングを一般的に示す図である。
【図１２】ＴｏｐＬｉｎｋ環境において中間ティアーで水平パーティショニングを実施するように使用できるクラスを示す図である。
【図１】
2006504194.tif 000003
【図２】
2006504194.tif 000004
【図３】
2006504194.tif 000005
【図４】
2006504194.tif 000006
【図５】
2006504194.tif 000007
【図６】
2006504194.tif 000008
【図７】
2006504194.tif 000009
【図８】
2006504194.tif 000010
【図９】
2006504194.tif 000011
【図１０】
2006504194.tif 000012
【図１１】
2006504194.tif 000013
【図１２】
2006504194.tif 000014
【国際調査報告】
2006504194.tif 000015
2006504194.tif 000016
2006504194.tif 000017