(57)【特許請求の範囲】
【請求項１】
データベースへのデータ・アクセスを容易にするシステムであって、前記データベースにおいてストアード・プロシージャが格納されており、前記ストアード・プロシージャは、構造化照会言語（ＳＱＬ）で作成されており、操作を必要とする前記データベース内のデータに直接アクセスし、前記システムは、
データベースへのアプリケーション・プログラム・インターフェース（ＡＰＩ）を定義する宣言ファイルとして働く拡張可能マークアップ言語（ＸＭＬ）構成ファイル、および、データベース内の前記ストアード・プロシージャ、に基づいて、データベースとの通信を提供するためのデータ・アクセス・レイヤーを自動的に生成するデータ・アクセス・レイヤー生成手段であって、前記ＸＭＬ構成ファイルは、前記ＡＰＩに必要なストアード・プロシージャのリスト、および前記ストアード・プロシージャが扱うパラメータをトランザクションＳＱＬベースから．Ｎｅｔフレームワークに変換するコーディング規約を備え、前記データ・アクセス・レイヤーを自動的に生成することは、
前記ＸＭＬ構成ファイルを解析して、前記ＡＰＩに必要なストアード・プロシージャのリストを取り出すこと、
前記データベースから前記ストアード・プロシージャに関するパラメータの情報を取り出すこと、
前記コーディング規約に基づいて前記取り出されたパラメータの属性を、ＳＱＬ名から．Ｎｅｔ名にマッピングすることにより適切なパラメータに変換すること、および
前記変換された適切なパラメータを用いて前記ストアード・プロシージャを呼び出すように前記データ・アクセス・レイヤーを生成すること
を含む、データ・アクセス・レイヤー生成手段と、
前記データ・アクセス・レイヤー生成手段によって生成された前記データ・アクセス・レイヤーを使用して、前記データベースにアクセスする中間層と
を備えることを特徴とするシステム。
【請求項２】
前記取り出されたパラメータの属性をＳＱＬ名から．Ｎｅｔ名にマッピングすることは、Ｃ＃名にマッピングすることを含むことを特徴とする請求項１に記載のシステム。
【請求項３】
データベースにアクセスする方法であって、前記データベースにおいてストアード・プロシージャが格納されており、前記ストアード・プロシージャは、構造化照会言語（ＳＱＬ）で作成されており、操作を必要とする前記データベース内のデータに直接アクセスし、前記方法は、
データ・アクセス・レイヤー生成手段が、データベースへのアプリケーション・プログラム・インターフェース（ＡＰＩ）を定義する宣言ファイルとして働く拡張可能マークアップ言語（ＸＭＬ）構成ファイルを解析することであって、前記ＸＭＬ構成ファイルは、前記ＡＰＩに必要なストアード・プロシージャのリスト、および前記ストアード・プロシージャが扱うパラメータをトランザクションＳＱＬベースから．Ｎｅｔフレームワークに変換するコーディング規約を備える、こと、
前記データ・アクセス・レイヤー生成手段が、前記解析によって、前記ＡＰＩに必要なストアード・プロシージャのリストを取り出すこと、
前記データ・アクセス・レイヤー生成手段が、前記データベースから前記ストアード・プロシージャに関するパラメータの情報を取り出すこと、
前記データ・アクセス・レイヤー生成手段が、前記コーディング規約に基づいて前記取り出されたパラメータの属性を、ＳＱＬ名から．Ｎｅｔ名にマッピングすることにより適切なパラメータに変換すること、
前記データ・アクセス・レイヤー生成手段が、前記変換された適切なパラメータを用いて前記ストアード・プロシージャを呼び出すように前記データ・アクセス・レイヤーを生成すること、および
中間層が、前記生成されたデータ・アクセス・レイヤーを使用して、前記データベースにアクセスすること
を備えることを特徴とする方法。
【請求項４】
前記ストアード・プロシージャは、前記データベースからの結果セットを生成するストアード・プロシージャおよび結果セットを生成しないストアード・プロシージャのうちの１つであることを特徴とする請求項３に記載の方法。
【請求項５】
前記中間層が、前記ストアード・プロシージャから呼び出した出力パラメータに関連するパラメータを捕捉することをさらに備えることを特徴とする請求項３に記載の方法。
【請求項６】
前記中間層が、前記捕捉したパラメータを中間層の上位層であるクライアント層に渡すことをさらに備えることを特徴とする請求項５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、ストアード・プロシージャを有するデータベースからのデータ・アクセスに関し、より詳細には、このようなストアード・プロシージャを分析することによってデータ・アクセス・レイヤーを自動的に生成するシステムおよび方法に関する。
【背景技術】
【０００２】
コンピュータ技術における進歩（たとえば、マイクロ・プロセッサの速度、記憶容量、データ転送帯域幅、ソフトウェアの機能など）は、一般に、様々な産業におけるコンピュータの使用を増大させるのに貢献してきた。さらに強力なサーバ・システムが、しばしば複数のサーバからなるアレイとして構成され、たとえばワールド・ワイド・ウェブなどの外部ソースから来る要求に対応するために、一般に提供されている。
【０００３】
利用可能な電子データの量が増大するにつれて、ユーザ・フレンドリで迅速なデータの検索および取り出しを容易にする管理可能なやり方でこのようなデータを記憶することが、より重要になってくる。現在、一般的な手法は、１つまたは複数のデータベースに電子データを記憶することである。一般に、典型的なデータベースは、コンピュータ・プログラムが、たとえば所望のデータを迅速に検索し選択できるように構成されたデータを有する、編成された情報の集まりと言うことができる。従来、データベース内のデータは１つまたは複数の表を介して編成されており、それぞれの表は１組のレコードを含み、１つのレコードは１組のフィールドを含んでいる。これらのレコードは一般に表中の行（raw）として指標付けされ、レコードのフィールドは一般に列（column）として指標付けされ、行／列の指標対で表中の特定のデータを参照できるようになっている。
【０００４】
現在、世界のデータベースの大多数がリレーショナル・データ・モデルに基づくものであり、アクセスは、ＳＱＬ（構造化照会言語）標準の変形に従って行われることが非常に多い。ＳＱＬは、リレーショナル・データベース内のデータの問い合わせおよび処理を行うために使用することができる言語であり、多くの企業が組織、製品および顧客のデータをＳＱＬ互換データベースに保持している。このＳＱＬ互換データベースは、元々メインフレームに関連して使用するために開発されたものであり、ほとんどのデータベース管理システム（ＤＢＭＳ）は、現在は通常、ＳＱＬをサポートするクライアント／サーバ環境用に設計されている。
【０００５】
データベース管理システムの主な用途はもちろん、データの格納、整理、および取り出しを管理することであるが、管理システムに様々な機能を提供するために、ストアード・プロシージャまたは予め定義された機能を使用し、データベース管理システムがそれを使用してそれによって提供される機能を達成できるようにすることがしばしば望ましい。データベースの管理者はしばしば、照会検索（query searches）に対応するために、小さな部分（たとえば、パラメータ）のみが変更可能な組み込み照会（built-in queries）である「ストアード・プロシージャ」を使用する。ストアード・プロシージャは、たとえば、特定のｚｉｐコードの住所に営業拠点がある顧客を識別するように定義することができる。したがって、ユーザは、照会結果を得るためには、ｚｉｐコードの値を入力するだけでよい。言い換えれば、ユーザはストアード・プロシージャを呼出し、識別されたパラメータとして所望のｚｉｐコードを入力することになる。一般に、ストアード・プロシージャを使用することにはくつかの利点があり、それらには、機能のカプセル化、性能向上、クライアント／サーバ処理、および機密保護が含まれる。一般に、ストアード・プロシージャは、複数のパラメータを扱うことが可能であり、それらは、そのプロシージャ内部で定義される。ストアード・プロシージャはまた、１つまたは複数のデータベース内で情報を追加、更新、または除去することができる。
【０００６】
また、データベース・アプリケーションの開発中に、開発者は、通常、デーベース内にストアード・プロシージャを作成し、次いでそのアプリケーションの中間層（middle tier）のためにデータ・アクセス・レイヤーのコンポーネントをコード化する。開発者は、これを使用して、ストアード・プロシージャを呼出し、結果を収集することができ、次いでそれを中間層のより高いレイヤーの呼出し側に渡すことができる。このようなデータ・アクセス・レイヤーの作成プロセスは、すでにデータベースにある、コードの形の様々な情報を複製することを含む。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、一般的にこのような手法は、複製中に、エラーが導入される可能性があり、保守上の問題が発生する可能性があるので、不十分であり冗長である。
【０００８】
さらに、ストアード・プロシージャに対する変更が、データ・アクセス・レイヤーに対する類似の変更を伴わない場合、アプリケーションは適切に動作しない。さらに、ストアード・プロシージャにおいて何が変わったか正確に判定し、データ・アクセス・レイヤー・コードを更新することは、面倒で間違いが生じやすい。
【０００９】
したがって、従来のシステムおよび装置に関連付けられた上記の例示的な欠点を克服する必要がある。
【００１０】
本発明の１つまたは複数の態様の基本的な理解を提供するために、本発明の簡単な要約を以下に示す。この要約は、本発明の広範囲に亘る概要ではない。本発明の重要なあるいは不可欠な要素を特定するものでもなく、本発明の範囲を限定するものでもない。そうではなく、この要約の唯一の目的は、以下に述べるより詳細な説明に対する序文として、本発明のいくつかの概念を簡単な形態で示すことである。
【００１１】
本発明は、データ・アクセス・レイヤー・ジェネレータを介して、ストアード・プロシージャの定義から、リレーショナル・データベース・アプリケーションの中間層のためのデータ・アクセス・レイヤーを自動的に生成するシステムおよび方法を提供する。このような構成（arrangement）は、ストアード・プロシージャによるリレーショナル・データベース内でのデータ・アクセスを容易にする。したがって、データベースに関する情報を一か所に格納することができ、そのような情報が中間層に保持されている情報と同期が取れない状態になるリスクが軽減される。
【課題を解決するための手段】
【００１２】
本発明の方法によれば、一般にアクセス・レイヤーに露出（エクスポーズ）されるストアード・プロシージャを決定するために、データ・アクセス・レイヤー・クラス・ジェネレータは、拡張可能マークアップ言語拡張（ＸＭＬ）構成ファイル（configuration file）からのデータを使用することができる。その結果、ＸＭＬファイルは、データベースへのアプリケーション・プログラム・インターフェース（ＡＰＩ）を記述する宣言ファイルとして働くことができ、たとえば、ＡＰＩに露出（エクスポーズ）する必要のあるストアード・プロシージャのリストを提供することができる。さらに、このようなＸＭＬファイルは、ストアード・プロシージャが実際に結果セット（result sets）を返す場合に、このような結果セットの名称などのデータベースから一般に容易にアクセスできないこともある情報を提供することができる。この結果セットはまた、自動的にセットアップできるそれに関連する論理的一次キーを有することができる。
【００１３】
関連する態様において、ＸＭＬ構成ファイルはまた、パラメータをトランザクション構造化照会言語（ＳＱＬ）ベースから．ＮＥＴフレームワークに変換できるように、コーディング規約に関する情報を収容することもできる。したがって、生成されるコードが準拠するストアード・プロシージャが異なるプログラミング規約を使用していても、生成されるコードは中間層プログラミング言語によって使用されるプログラミング規約に適切に合致することができる。たとえば、ＳＱＬベースのストアード・プロシージャ用のパラメータに関するネーミング規約は、中間層プログラミング言語内で一般的に使用されるものとは異なるものでもよい。ＸＭＬ構成ファイルに基づいて、ＳＱＬベースのパラメータ名を中間層プログラミング言語に適したネーミング規約に自動的に変換することができる。たとえば本発明は、データ・アクセス・クラスを定義することができるＣ＃（商標）コードを生成することができ、動作可能なシステムを得るために、残りの中間ソース・ファイルを追加／編集（compile）およびサーバに配備（deploy）することができる。したがって、配備後、このシステムは、データベース、つまり、データ・アクセス・レイヤー・ジェネレータによって自動的に生成されるデータ・アクセス・レイヤーを有する中間層を含むことができる（このデータ・アクセス・レイヤーは、データベースとの通信を提供することができ、その際、中間層は、一般にＷｅｂサービスおよびＨＴＴＰサービス機能を提供できるインターネット情報サービス（ＩＩＳ）をサポート（ｂａｃｋ）する）。ユーザは次いでＷｅｂブラウザを使用して、（たとえば、アクティブ・サーバ・ページとして）サーバ側記述環境（server side scripting environment）を実行するＷｅｂサーバ（たとえば、ＩＩＳ）がホストするＷｅｂページをブラウズすることができ、データベース内のデータ・アクセス・レイヤーおよびストアード・プロシージャを呼び出す中間層ビジネス論理コンポーネントを呼び出すことができる。このようなストアード・プロシージャは、結果セットを返すことができ、かつ／またはその代わりに、どのような結果セットも通常は返さない代わりに、何らかの有用な副次的効果（たとえば、データの挿入、更新、あるいは削除）を実行することができる。
【００１４】
本発明の別の方法によれば、データ・アクセス・レイヤー・ジェネレータによってクラスがどのように生成されるのかを決定するために、最初にＸＭＬ構成ファイルを解析（parse）し相互に関係付けることができる。これには、たとえば、検査すべきデータベースの識別、結果を生成するための全体的仕様、データ・アクセス・レイヤーを介してアクセスできるストアード・プロシージャに関する情報、などを含むことができる。次に、データベースから情報を取り出すことができ、プリアンブル・コードを生成することができる。このプリアンブル・コードは、トランザクション・サポートのための典型的なコードおよびデータ・アクセス・レイヤー内のデータベースを開くためのコードを含むことができる。
【００１５】
１つまたは複数の結果セットがストアード・プロシージャから返された（たとえば、データが実際に返された）場合、このようなストアード・プロシージャに関するメタデータをデータベースから得ることができる。その後、これらのストアード・プロシージャ用のパラメータのタイプと合致するパラメータを、ストアード・プロシージャを呼び出すためのコマンド・オブジェクトを用いて、生成することができる。続いて、生成されたコードは、データ・セットおよびデータ・アダプタを作成することができる。このデータ・アダプタを使用してデータ・セットに、ストアード・プロシージャを呼び出した結果を記入することができる。次に、データ・セットを表す値を返すためにメソッド・ヘッダを生成することができる。
【００１６】
非結果セット（non-result set）を返す（言い換えれば、結果セットを返さない）ストアード・プロシージャの関連態様において、そのストアード・プロシージャに関するメタデータを最初にデータベースから得ることができ、次いで、前記ストアード・プロシージャ用のパラメータのタイプに合致するパラメータを用いてメソッドを生成することができる。次に、この生成されたメソッドの本体（body）がストアード・プロシージャを呼び出すためのコマンド・オブジェクトを生成することができ、パラメータが、データベースから得られたメタデータ情報に合致する、ストアード・プロシージャのために、作成される。
【００１７】
上記の目的および関連の目的を達成するために、本発明は、以下に詳しく説明する特徴を備える。以下の説明および添付の図面で、本発明のいくつかの例示的態様について詳細に説明する。しかし、これらの態様は、本発明の原理が利用される様々なやり方のほんのいくつかを示すにすぎない。本発明の他の態様、利点および新規な特徴は、本発明の以下の詳細な説明を前記図面と併せて考察すれば明らかになるであろう。
【発明を実施するための最良の形態】
【００１８】
最後に記載した付録Ａは、本発明の一態様による、ＸＭＬ構成ファイルに関するスキーマのある特定の例示的セットを提供する。この付録は本発明を記述する本明細書の一部とみなすべきである。
【００１９】
次に、図面を参照して本発明を説明する。図面全体を通じて同じ要素を参照するには同じ参照番号を使用する。以下の記述においては、説明のために、本発明が完全に理解されるようにするために数多くの具体的な詳細について述べる。しかし、本発明は、これらの具体的な詳細がなくても実施できることは明らかであろう。このこととは別に、周知の構造および装置については、本発明の記述を容易にするために構成図の形で示している。
【００２０】
本出願では、「構成要素」、「ハンドラ」、「モデル」、「システム」などの用語は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェアのいずれかのコンピュータ関連エンティティ、あるいは実行中のソフトウェアを指すものとする。たとえば、構成要素は、それだけには限らないが、プロセッサ上で実行中のプロセス、プロセッサ、オブジェクト、実行可能なもの（an executable）、実行スレッド（a thread of execution）、プログラム、および／またはコンピュータであってもよい。実際の例として、サーバ上で実行中のアプリケーションも、そのサーバも構成要素とすることができる。１個または複数の構成要素がプロセスおよび／または実行スレッド内に常駐してもよく、１つの構成要素が１台のコンピュータ上に局在してもよく、かつ／または２台以上のコンピュータ間に分散されていてもよい。また、これらの構成要素は、様々なデータ構造を格納している、様々なコンピュータ読み取り可能媒体から実行することができる。これらの構成要素は、１個または複数のデータ・パケット（たとえば、ローカル・システムおよび分散システムにある別の構成要素と、かつ／またはインターネットなどのネットワークを介して信号によって他のシステムと、対話している１つの構成要素からのデータ）を有する信号によるなど、ローカルおよび／またはリモート・プロセスを介して通信することができる。
【００２１】
本発明は、データ・アクセス・レイヤー・ジェネレータを介して、ストアード・プロシージャの定義から、リレーショナル・データベース・アプリケーションのデータ・アクセス・レイヤーを自動的に生成するシステムおよび方法を提供する。このような構成は、ストアード・プロシージャによるリレーショナル・データベース内でのデータ・アクセスを容易にする。さらに、データベースに関する情報は、このような情報が中間層に保持されている情報と同期が取れない状態になるリスクを軽減するために、一か所に格納することができる。言い換えれば、中間層内のデータ・アクセス・レイヤーを、本発明のデータ・アクセス・レイヤー・ジェネレータを介して、自動的に生成することができる。
【００２２】
図１は、本発明の一態様による、中間層１２５内にデータ・アクセス・レイヤー１３０を自動的に生成するデータ・アクセス・レイヤー・ジェネレータ１１０を備える多層クライアント・サーバ・アーキテクチャ１００を示す。３つの物理層構造（physical tiered structure）、すなわちクライアント層（client tier）、中間層（middle tier）、およびデータベース層（database tier）が提供され、クライアント層１０４は、ユーザのワークステーション、ＰＤＡ、およびＷｅｂブラウザをホストできるその他の装置に属する。サービス志向のソリューションでは、この層は、サービスを消費するコンピュータおよび装置に属する。一般的に、このような多層構成（multi-tiered arrangement）１００においては、クライアント・アプリケーション・プロセスは、コンピュータ・プラットフォーム上で走るアプリケーション・プログラムを表し、この場合、このコンピュータ・プラットフォームは、データベースのサーバと同じであっても、あるいは、通信ネットワークなどある種の通信媒体を介してサーバに接続されたリモート・コンピュータ・プラットフォームであってもよい。
【００２３】
中間層１２５は、一般的に、アプリケーションのビジネス構成要素を、Ｗｅｂアプリケーションの場合はＷｅｂサーバをも、ホストする責任を負うことになる。このような中間層１２５は、ビジネス論理レイヤー１２７を含むことができ、このビジネス論理レイヤー１２７は、それを介して両方向に渡されるデータ、およびデータ層１１５とクライアント層１０４の間を渡されるデータ、に対する操作を行う。層１２７は、データのビュー、またはデータの格納というよりも、主に論理に関係する。このような構成は、一般的に拡張容易性および耐障害性をサポートし、このような構成におけるアプリケーション層は、サーバ・ファームとして構成することができ、データベース層はサーバ・クラスタとして構成することができる。
【００２４】
クライアント層１０４は、様々なパラメータを用いてあるいは用いずにＷｅｂページを要求することによって、リレーショナル・データベース１１５と対話することができる。これらのＷｅｂページにアクセスすると、中間層内のビジネス論理構成要素が呼び出される。次いで、このようなビジネス論理要素がデータ・アクセス・レイヤー構成要素を呼出し、データ・アクセス・レイヤー構成要素がＳＱＬステートメントを発行し、ＳＱＬステートメントが、たとえば、リレーショナル・データベース１１５に伝達される。したがって、クライアント１０４は、プロシージャ呼出しを間接的に発行することができ、このプロシージャ呼出しは、予め定義された外部プロシージャのうちの１つを実行するようリレーショナル・データベース１１５に指令することができる。リレーショナル・データベース１１５では、データの大部分は、一般に、１つまたは複数のテーブル内に複数の行（rows）として格納される。データベース１１５には、複数のテーブルにわたって連想照会（associative queries）を行う機能を有する１つまたは複数のエンティティからアクセスすることができる。テーブルに格納されているエンティティのセットには、セット処理言語（たとえば構造化照会言語）を使用してアクセスすることができ、この言語は、１つまたは複数のテーブルをデータのソースとして指定し、所与の条件を満たす行があればそれのみを出力する。データ・アクセス・レイヤー・ジェネレータ１１０は、中間層１２５のデータ・アクセス・レイヤー１３０を自動的に作成することができる。このデータ・アクセス・レイヤー１３０を使用して、データベース１１５内のストアード・プロシージャを呼出し、結果があればそれを収集することができ、次いでこの結果が中間層１２５内のより高い層（higher layers）に渡される。
【００２５】
図２は、ＸＭＬ構成ファイルおよびデータベースのストアード・プロシージャを使用することによってデータ・アクセス・レイヤーを生成するデータ・アクセス・レイヤー・ジェネレータを示す。一般的に、ストアード・プロシージャ２０４、２０６（１〜ｍ、ただしｍは整数）は、データベース２１０内に物理的に格納されているプログラム（またはプロシージャ）である。このようなプログラムは、通常、専用データベース言語で書かれ、ユーザの要求に応じて、データベース・エンジンによって直接実行される。
【００２６】
ストアード・プロシージャ２０４、２０６は、操作を必要とするデータに直接アクセスし、一般的には結果をユーザに送り返すだけでよく、したがって、大量のデータをやりとりする際の通信のオーバーヘッドを軽減する。たとえば、ストアード・プロシージャ２０４、２０６の典型的な用途としては、データベース構造に組み込まれたデータ妥当性検査（この目的で使用されるストアード・プロシージャは、しばしばトリガーと呼ばれる）、あるいは、何か大きな、あるいは複雑な処理（大きなデータ・セットを操作して要約された結果を生成することなど）のカプセル化を含めることができる。ストアード・プロシージャ２０４、２０６はまた、データベース２１０を多くの外部プログラムから操作するときに使用することもできる。ストアード・プロシージャを使用してデータベース２１０にビジネス論理を組み込むことによって、データにアクセスするすべてのプログラムに同じ論理を組み込む必要性が軽減される。これによって、関係するプログラムの作成、とりわけ保守を簡略化することができる。
【００２７】
図２に示したように、データ・アクセス・レイヤー・ジェネレータ２１５は、ＸＭＬ構成ファイル２０５を用いて、データ・アクセス・レイヤー・クラスおよびメソッド定義２２０を自動的に作成することができる。データ・アクセス・レイヤー・クラス・ジェネレータ２１５によってクラスをどのように生成すべきかを決定するために、ＸＭＬ構成ファイル２０５を解析し相互に関係付けることができる。これには、たとえば、検査すべきデータベースの識別、結果を生成するための全体的仕様、データ・アクセス・レイヤー２２０などを介してアクセスできるストアード・プロシージャに関する情報などを含めることができる。次に、データベース２１０から情報を取り出すことができ、トランザクション・サポートのための典型的なコードおよびデータ・アクセス・レイヤー内のデータベースを開くためのコードを含めることができるプリアンブル・コードを生成することができる。ＸＭＬ構成ファイル２０５は、一般にアクセス・レイヤーに露出（エクスポーズ）されるストアード・プロシージャを決定することができる。したがって、このＸＭＬファイルは、データベースへのアプリケーション・プログラム・インターフェース（ＡＰＩ）を記述する宣言ファイルとして働くことができ、たとえば、ＡＰＩに露出（エクスポーズ）する必要のあるストアード・プロシージャのリストを提供することができる。さらに、このようなＸＭＬファイルは、データベースから一般に容易にアクセスできないこともある結果セットの名称（ストアード・プロシージャが実際にこのような結果セットを返す場合）などの情報を提供することができる。この結果セットはまた、自動的にセットアップできるそれに関連する論理的一次キーを有することができる。
【００２８】
構成ファイル２０５の一部とすることもできる例示的スキーマを、本文書の終わりに、付録Ａの一部として提示する。上記に説明したように、このような例示的スキーマは、たとえば、ＸＭＬスキーマ言語のスキーマ構文を使用しているＸＭＬドキュメントのクラスを定義し記述することができる拡張可能マークアップ言語（ＸＭＬ）の形をとることができる。これらのスキーマ構文は、ＸＭＬドキュメントに使用されている、データ・タイプ、要素およびその内容、属性（attributes）およびその値、エンティティ、コンテンツ、ならびに表記法についての意味、用途、および関係を限定し、文書化すること、に使用することができる。したがって、一般に、ＸＭＬスキーマにアクセスできるどのコンピュータ・システムも、ＸＭＬスキーマに従ってＸＭＬドキュメントを処理することができる。さらに、一般的に、ＸＭＬスキーマにアクセスできるどのコンピュータ・システムも、ＸＭＬドキュメントを、やはりそのＸＭＬスキーマにアクセスできる他のコンピュータ・システムが使用できるように、組み立てたりあるいは変更したりすることができる。スキーマは、データ構造を定義するために使用される、論理値、２進数、８進数、１０進数、１６進数、整数、浮動小数点、文字、文字列、ユーザ定義済みデータ・タイプ、およびこれらのデータ・タイプの組合せを含めて、事実上どんなデータ・タイプをも定義することができる。ＸＭＬ要素および属性は、スキーマによって定義されるデータ・タイプを表すように定義することができる。本発明の特定の一態様による例示的ＸＭＬスキーマを、付録Ａの一部として、最後に紹介する。
【００２９】
関係する態様において、ＸＭＬ構成ファイルは、パラメータをトランザクションＳＱＬベースから「．ＮＥＴ」フレームワークに変換できるように、コーディング規約に関する情報を収容することもできる。したがって、生成されるコードは、生成されるコードが基にしているストアード・プロシージャが異なるプログラミング規約を使用していても、生成されるコードは、中間層プログラミング言語によって使用されるプログラミング規約に適切に合致することができる。たとえば、ＳＱＬベースのストアード・プロシージャ用のパラメータに対する命名規約が、中間層プログラミング言語で一般的に使用されるものとは異なることも十分にあり得る。ＸＭＬ構成ファイルに基づいて、ＳＱＬベースのパラメータ名を、中間層プログラミング言語に適した命名規約に自動的に変換することができる。たとえば、本発明は、データ・アクセス・クラスを定義することができるＣ＃（商標）コードを生成することができ、動作可能なシステムを得るために、残りの中間ソース・ファイルを、追加／コンパイルして、サーバに配備することができる。
【００３０】
次に図３ａを参照すると、本発明の一態様による、データ・アクセス・レイヤー・クラス生成の例示的方法が示してある。この例示的方法は、本明細書中で、様々なイベントおよび／または動作（acts）を表す一連のブロックとして図示し記述してあるが、本発明は、そのようなブロックのここに示した順序によって制限されるものではない。たとえば、いくつかの動作またはイベントが、本発明に従って、ここに示した順序とは別に、異なる順序で、かつ／または他の動作またはイベントと同時に、生じてもよい。さらに、本発明による方法を実装するために、ここに示したブロック、イベントまたは動作がすべて必要なわけではない。さらに、本発明による例示的方法およびその他の方法が、本明細書中で図示し記述した方法に関連して、ならびに図示も記述もされていない他のシステムおよび装置に関連して、実装することもできることが理解されるであろう。最初に３１０でＸＭＬパラメータ・ファイルを読み取り、例によって残りの処理をドライブすることができる（パラメータ・ファイルは、スキーマに照らして読み取られ妥当性検査されるので、一般にそのようなスキーマに準拠していなければならない）。
【００３１】
たとえば、顧客またはユーザが提供しているＸＭＬをまず検証し、次いでＸＭＬファイルのコンテンツに基づいて、３２０でアプリケーション状態を初期化することができ、そこで情報をそのアプリケーションによって操作されるオブジェクトとして捕捉することができる。次に３３０で、たとえば、データベース内のストアード・プロシージャ、有益と思われるすべての関係情報タイプ、およびオブジェクト・モデル内のそのような情報の捕捉についての検査を含めて、タイプ情報をデータベースから取り出すことができる。続いて３４０で、トランザクション・サポートを含むことができるプリアンブル・コードが生成される。このプリアンブル・コードは、アクセス・レイヤー用の一定量の固定コードを含むことができ、トランザクション・サポートのためのコード、およびデータ・アクセス・レイヤー内のデータベースを開くためのプロトコルなど、一般的にどのデータベースが検査されるかに関係なく、生成される。ストアード・プロシージャが結果セットを作成できるか否かに応じて、本発明の方法は、２つの別々の方法ブランチに分かれることになる。
【００３２】
ストアード・プロシージャが１つまたは複数の結果セット（たとえば、ユーザに見せるカタログの検索結果）を返す場合は、図３ｂに進む。図３ｂの３６０に示したように、ストアード・プロシージャに関するパラメータ情報は、データベースから自動的に取り出すことができる。したがって、ストアード・プロシージャが正確に表記されている場合は、適切なパラメータ情報を自動的に収集することができる。次に３６２で、属性を、たとえばストアード・プロシージャ名からオブジェクト指向のプログラミング名（たとえばＣ＃（商標）名）にマップすることができる。続いて３６４で、あるクラスのストアード・プロシージャを呼び出す手順を文書化できるコメントが出力される。次いで３６６に進み、データ・セットを表すことができる戻り値を用いて、メソッド・ヘッダを生成することができる。次に３６８で、コードを生成して、適切なパラメータによって特定のストアード・プロシージャを呼び出すコマンドを作成することができる。言い換えれば、前にデータベースから取り出したタイプ情報をパラメータ・ファイルからの情報と組み合わせて、結果セットを返すその特定のストアード・プロシージャを呼び出すメソッドを生成することができる。
【００３３】
次いで３７０に進み、データベースからデータを取得するために、ストアード・プロシージャを呼び出した結果をデータ・セットに記入するコードを生成することができる。さらに、データベースに対する照会の実行からの出力に基づいて作成される論理テーブルに関連付けられた論理的一次キーがパラメータ・ファイル中に存在する場合、３７２で、それをサポートするコードを生成することができる。このようなコードは、中間層でのデータの保全性（integrity）の作成および／または保守を容易にすることができる。また、返された結果セットに加えて、返される出力パラメータのための何か特定の値がある場合は、３７４で、このような値を捕捉し返すためのコードを生成することができる。次いで図３ａの３５０に戻り、さらに生成すべき結果セット・ストアード・プロシージャがあるかどうか検査する。
【００３４】
そうではなくて、図３ａの３５６で、ストアード・プロシージャが結果セットを返さない（たとえば、顧客を作成する、または名前を挿入する）場合は、図３ｃに進む。図３ｃの３７１に示したように、ストアード・プロシージャに関するパラメータ情報は、データベースから自動的に取り出すことができる。次に３７３で、属性を、たとえばストアード・プロシージャ名からオブジェクト指向のプログラミング名（たとえばＣ＃（商標）名）にマップすることができる。続いて３７５で、あるクラスのストアード・プロシージャを呼び出すプロシージャを文書化できるコメントが出力される。次いで３７７に進み、戻り値が空なので、戻り値なしでメソッド・ヘッダを生成することができる。次に３７９で、コードを生成して、適切なパラメータによって特定のストアード・プロシージャを呼び出すコマンドを作成することができる。また、返される出力パラメータのための何か特定の値がある場合は、３８１で、このような値を捕捉し返すためのコードを生成することができる。次いで戻って、さらに生成すべき非結果セット・ストアード・プロシージャがまだあるかどうか検査することができる。
【００３５】
たとえば、ＳＱＬのデータベースを使用するバンキング・アプリケーションの場合、アカウントの作成および既存のアカウントに関する情報の更新のために、ストアード・プロシージャをＳＱＬで書くことができる。このようなデータベースは、一般的にテーブルおよび列（columns）に従って定義することができ、複数のテーブル間の関係がリレーショナル・データベースの論理構成要素を形成することができる。これらの論理要素は、データベースのセマンティクスを容易に表し、データベースを別のデータ・モデルにマッピングすること、などを容易にすることができる。また、データベース・テーブルをＸＭＬ文書に変換し、ＸＭＬツールをこれらの文書と共に使用して、さらにファイナンシャル・アプリケーションを処理することもできる。
【００３６】
このようなデータベース環境で、アカウントを作成または更新するためのストアード・プロシージャは、一般的に非結果セット・ストアード・プロシージャとみなされる。たとえば、アカウントを作成するためのストアード・プロシージャの場合、出力パラメータを顧客ＩＤと共にテーブル結果セットなしで返すことができ、この場合、データ・アクセス・レイヤー・クラス・ジェネレータは、ストアード・プロシージャを呼び出すことができる中間層のＣ＃（商標）ソースコード、などのコードまたは情報を再ドラフトする必要を未然に防ぐことができる。したがって、パラメータの順序、名前、タイプおよびサイズに関する情報がクラスのメソッド定義に埋め込まれ、ここでは、正確なサンプル情報もストアード・プロシージャ定義の一部になるはずである。
【００３７】
バンキング・アプリケーション変更のための必要条件として、オーバードラフト保護（貸越残高保護）アカウントを扱うアプリケーションが必要になることもあり、あるいは、アカウント作成およびアカウント更新ストアード・プロシージャは一般的に、オーバードラフト（当座貸越）限度など別のパラメータが組み込まれるように修正する必要がある。本発明は、ストアード・プロシージャと中間層コードの間のパラメータの数、タイプ、またはサイズの違いによってエラーが導入される恐れのある、データ・アクセス・レイヤーＣ＃（商標）コードを手動で更新する必要性、を未然に防ぐことまたは軽減することができる。したがって、本発明のデータ・アクセス・レイヤー・クラス・ジェネレータを使用することにより、変更を一般的に、ストアード・プロシージャの定義の一部として組み込むだけでよくなる。次いで、データ・アクセス・レイヤー・クラスが再生成され、それによって最新のストアード・プロシージャ定義と互換性のある構成要素の新バージョンが作成される。これによって、数百あるいは数千数のストアード・プロシージャを有するアプリケーションを更新するのに必要とされる労力が大幅に軽減される。
【００３８】
図４は本発明の一態様による、配備されたシステム（deployed system）を示し、システム４００は、データベース４１０と、データ・アクセス・レイヤー・ジェネレータによって自動的に生成されるデータ・アクセス・レイヤー４１５を有する中間層４２０とを含むことができる。このようなデータ・アクセス・レイヤー４１５は、データベース４１０との通信を提供することができ、中間層４２０は、Ｗｅｂサービスおよびサーバ側Ｗｅｂユーザ・インターフェース構成要素４３０、４４０を実装したインターネット情報サービス（ＩＩＳ）ベースのＷｅｂアプリケーションをサポートする。次いで、ユーザは、Ｗｅｂブラウザを使用して、Ｗｅｂサーバ（たとえばＩＩＳ）によって提供されるＷｅｂページをブラウズすることができ、このＷｅｂサーバは、中間層内のビジネス論理構成要素を呼び出すことができ、このビジネス論理構成要素は、データベース４１０内のストアード・プロシージャを呼び出すために、データ・アクセス・レイヤー４１５内の構成要素を呼び出すことができる。これらのストアード・プロシージャは、結果セットを返したり、かつ／または、その反対に結果セットを提供しなかったりすることがある。
【００３９】
次に、図５を参照すると、多層構造の一部としてのＷｅｂサーバと通信中のＷｅｂブラウザが示してあり、ここでは、上記に詳しく述べたようにデータ・アクセス・レイヤーが自動的に生成される。クライアント５２０上で実行しているのは、Ｗｅｂブラウザ５１０などのクライアント・プロセスであり同様に、サーバ５５０上で実行しているのは、対応するサーバ・プロセス、たとえばＷｅｂサーバ５６０である。さらに、Ｗｅｂブラウザ５１０に埋め込まれているのは、スクリプトまたはアプリケーション５３０とすることができ、クライアント・コンピュータ５２０のランタイム環境５５０内での実行には、本発明の様々な態様による、フォーマット済みデータ・パケットのパッケージ化およびアンパックを行うためのプロキシ５１５が存在することができる。サーバ５５０と通信するのはデータベース管理システム（ＤＢＭＳ）５８０であり、これは、データベース（図示せず）へのアクセスを管理する、いる。ＤＢＭＳ５８０およびデータベース（図示せず）は、サーバそれ自身に置いてもよく、あるいは、リモート側でリモート・データベース・サーバ（図示せず）上に置いてもよい。Ｗｅｂサーバ５６０上で実行するのは、ＤＢＭＳ５８０へのアクセスを提供するデータベース・インターフェースであるアプリケーション・プログラム・インターフェース（ＡＰＩ）５７０である。上記に説明したように、ＸＭＬ構成ファイルは、一般的にアクセス・レイヤーに露出（エクスポーズ）されるストアード・プロシージャを決定することができる。したがって、ＸＭＬファイルは、たとえば、データベースへのＡＰＩ５７０を定義する宣言ファイルとして働くことができ、ＡＰＩに露出（エクスポーズ）する必要があるストアード・プロシージャのリストを提供することができる。
【００４０】
クライアント・コンピュータ５２０およびサーバ・コンピュータ５５０は、ネットワーク５９０を介して互いに通信することができる。クライアント・プロセス、たとえばＷｅｂブラウザ５１０がデータベースにデータを要求すると、スクリプトまたはアプリケーション５３０が、クエリを発行し、それがネットワーク（たとえばインターネット）５９０を介してサーバ・コンピュータ５５０に送られ、次いで、サーバ・プロセス、たとえばＷｅｂサーバ５６０によって解釈される。サーバ５５０に対するクライアント５２０の要求は、複数のコマンドを含むことができ、サーバ５５０からの応答は、複数の結果セットを返すことができる。クライアントのコマンドに対して返される応答は、自己記述型でレコード指向でよい（たとえば、データストリームは、返される行の名前、タイプおよび任意選択の説明、を記述することができる）。また、生成されるコードが基づいているストアード・プロシージャが異なるプログラミング規約を使用していても、生成されるコードは中間層プログラミング言語によって使用されるプログラミング規約に適切に合致することができる。たとえば、ＳＱＬベースのストアード・プロシージャ用のパラメータの命名規約は、一般的に中間層プログラミング言語で使用されるものとは異なっていてもよい。ＸＭＬ構成ファイルに基づいて、ＳＱＬベースのパラメータ名を、中間層プログラミング言語に適した命名規約に自動的に変換することができる。本発明は、たとえば、データ・アクセス・クラスを定義することができるＣ＃（商標）コードを生成することができ、操作システムを得るために、残りの中間ソース・ファイルを追加／コンパイルし、サーバに配備することができる。
【００４１】
次に図６を参照すると、本発明の様々な態様を実施することができる適切なコンピューティング環境の簡単な一般的説明が示してある。上記では、１台および／または複数のコンピュータ上で実行するコンピュータ・プログラムのコンピュータ実行可能命令の一般的コンテキストで本発明を述べてきたが、本発明はまた、他のプログラム・モジュールと組み合わせて実施することもできることが当業者には理解されよう。一般に、プログラム・モジュールは、特定のタスクを実行し、かつ／または、特定の抽象データ・タイプを実施する、ルーチン、プログラム、構成要素、データ構造などを含む。さらに、本発明の方法は、単一プロセッサまたはマルチ・プロセッサ・コンピュータ・システム、ミニ・コンピュータ、汎用コンピュータ、ならびにパーソナル・コンピュータ、ハンドヘルド・コンピューティング装置、マイクロ・プロセッサ・ベースのあるいはプログラム可能なコンシューマ・エレクトロニクスなどを含めて、他のコンピュータ・システム構成でも実施できることも当業者には理解されよう。前に説明したように、図示した本発明の諸態様は、タスクを、通信ネットワークを介してリンクされているリモート処理装置によって実行する分散コンピューティング環境で実施することもできる。しかし、本発明のすべてではないとしても、一部の態様は、スタンドアロン・コンピュータ上で実施することができる。分散コンピューティング環境では、プログラム・モジュールは、ローカル、リモート両方のメモリ記憶装置内に置くことができる。この例示的環境は、処理ユニット６２１、システム・メモリ６２２、およびそのシステム・メモリを含む様々なシステム構成要素を前記処理ユニット６２１に結合するシステム・バス６２３を含む、コンピュータ６２０を含んでいる。処理ユニット６２１は、市販の様々なプロセッサのどれでもよい。デュアル・マイクロ・プロセッサおよびその他のマルチ・プロセッサ・アーキテクチャも、処理ユニット６２１として使用することができる。
【００４２】
システム・バスは、メモリ・バスまたはメモリ・コントローラ、ペリフェララル（周辺装置用）バス、および様々な市販のバス・アーキテクチャのうちのいずれかを使用するローカル・バスを含めて、いくつかのタイプのバス構造のうちのいずれでもよい。システム・メモリは、読み取り専用メモリ（ＲＯＭ）６２４およびランダム・アクセス・メモリ（ＲＡＭ）６２５を含むことができる。起動中などにコンピュータ６２０内の要素間で情報を転送する助けとなる、基本ルーチンを含む基本入／出力システム（ＢＩＯＳ）が、ＲＯＭ６２４に格納されている。
【００４３】
コンピュータ６２０は、ハードディスク・ドライブ６２７、たとえば取り外し可能ディスク６２９に対して読み書きするための磁気ディスク・ドライブ６２８、および、たとえばＣＤ−ＲＯＭディスク６３１に対して読み書きし、あるいは、他の光媒体に対して読み書きするための光ディスク・ドライブ６３０をさらに含む。ハードディスク・ドライブ６２７、磁気ディスク・ドライブ６２８、および光ディスク・ドライブ６３０は、それぞれハードディスク・ドライブ・インターフェース６３２、磁気ディスク・ドライブ・インターフェース６３３、および光ドライブ・インターフェース６３４によって、システム・バス６２３に接続されている。このドライブおよびその関連のコンピュータ読み取り可能媒体は、データ、データ構造、コンピュータ実行可能命令などの不揮発性記憶をコンピュータ６２０のために提供する。コンピュータ読も取り可能媒体についての上記の説明は、ハードディスク、取り外し可能磁気ディスクおよびＣＤに関するものであるが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジなどコンピュータによって読み取り可能な他のタイプの媒体も、例示の操作環境で使用できること、さらに、このような媒体はどれでも、本発明の方法を実施するためのコンピュータ実行可能命令を含むことができること、が当業者には理解されよう。
【００４４】
オペレーティング・システム６３５、１つまたは複数のアプリケーション・プログラム６３６、その他のプログラム・モジュール６３７、およびプログラム・データ６３８を含めて、いくつかのプログラム・モジュールを、各ドライブおよびＲＡＭ６２５に格納することができる。図示したコンピュータ内のオペレーティング・システム６３５は、市販の実質上どんなオペレーティング・システムであってもよい。
【００４５】
ユーザは、キーボート６４０、およびマウス６４２などのポインティング装置を介して、コンピュータ６２０にコマンドおよび情報を入力することができる。その他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどがある。これらおよびその他の入力装置は、システム・バスに結合されているシリアル・ポート・インターフェース６４６を介して、処理ユニット６２１に接続されることが多いが、パラレル・ポート、ゲーム・ポート、ユニバーサル・シリアル・バス（ＵＳＢ）などその他のインターフェースによって接続されてもよい。モニタ６４７またはその他のタイプの表示装置も、ビデオ・アダプタ６４８などのインターフェースを介してシステム・バス６２３に接続され、上記に詳しく述べたように、本発明の様々な態様を使用している。モニタのほかに、コンピュータは一般的に、スピーカおよびプリンタなどその他の周辺出力装置（図示せず）を備える。モニタの電力は、燃料電池および／またはそれに関連するバッテリを介して供給することができる。
【００４６】
コンピュータ６２０は、リモート・コンピュータ６４９など１台または複数のリモート・コンピュータへの論理接続を使用するネットワーク環境で動作することができる。リモート・コンピュータ６４９は、ワークステーション、サーバ・コンピュータ、ルータ、ピア装置またはその他の一般的ネットワーク・ノードでよく、メモリ記憶装置６５０だけを図６に示すが、一般的に、コンピュータ６２０に関して述べた要素の多くまたはすべてを含む。図６に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）６５１および広域ネットワーク（ＷＡＮ）６５２を含むことができる。このようなネットワーキング環境は、オフィス、事業体全体のコンピュータ・ネットワーク、イントラネット、およびインターネットでは普通のものである。
【００４７】
ＬＡＮネットワーキング環境で使用する場合、コンピュータ６２０は、ネットワーク・インターフェースまたはアダプタ６５３を介して、ローカル・ネットワーク６５１に接続することができる。ＷＡＮネットワーキング環境で使用する場合、コンピュータ６２０は、一般にモデム６５４を備えることができ、かつ／またはＬＡＮ上の通信サーバに接続され、かつ／またはインターネットなどの広域ネットワーク６５２を介して通信を確立する他の手段を有する。モデム６５４は、内部モデムでも外部モデムでもよく、シリアル・ポート・インターフェース６４６を介してシステム・バス６２３に接続することができる。コンピュータ６２０またはその一部に関して示したプログラム・モジュールは、ネットワーク環境ではリモート・メモリ記憶装置に格納してもよい。ここに示したネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立する他の手段を使用することもできることを理解されたい。
【００４８】
コンピュータ・プログラミングの分野における当業者の慣行に従って、本発明を、別段の指示がない限り、コンピュータ６２０などのコンピュータによって実行される動作（acts）、および、操作の記号表現に関して述べてきた。このような動作（acts）および操作（operation）は、コンピュータで実行される、と言われることもある。こうした動作、および記号で表現される操作は、結果として電気信号表現の変換または還元（reduction）を引き起こすデータ・ビットを表す電気信号についての処理ユニット６２１による操作（manipulation）と、（システム・メモリ６２２、ハード・ドライブ６２７、フロッピー（登録商標）ディスク６２８、およびＣＤ−ＲＯＭ６３１を含む）メモリ・システム内のメモリ・ロケーションでのデータ・ビットの保守を含み、それによって、コンピュータ・システムの操作ならびに信号のその他の処理を再構成し、またはその他の形で変更することが理解されよう。このようなデータ・ビットが保持されているメモリ・ロケーションは、データ・ビットに対応する特定の電気的、磁気的、または光学的特性を有する物理的ロケーションである。
【００４９】
次に図７を参照すると、クライアント側またはサーバ側の無線表示（wireless display）のために、本発明の様々な態様を使用することができる、クライアント／サーバ・システム７００が示してある。クライアント７２０は、ハードウェアおよび／またはソフトウェア（たとえばスレッド、プロセス、コンピューティング装置）でよい。システム７００はまた、１つまたは複数のサーバ７４０も含む。サーバ７４０はまた、ハードウェアおよび／またはソフトウェア（たとえばスレッド、プロセス、コンピューティング装置）でよい。クライアント７２０およびサーバ７４０は、本発明に従って伝送されるデータ・パケットの形で２つ以上のコンピュータ・プロセス間で通信することができる。この図に示すように、システム７００は、クライアント７２０とサーバ７４０の間の通信を容易にすることができる通信フレームワーク７８０、および／またはそれぞれの表示モニタを備えることができる。クライアント７２０は、クライアント７２０にとってローカルな情報を格納することができる１つまたは複数のクライアント・データ・ストア７１０に動作可能に接続される。さらに、クライアント７２０は、サーバ・プロセスを実行しているサーバ・コンピュータ７４０上に位置するデータベース７６０にアクセスしそれを更新することができる。本発明の一態様では、通信フレームワーク７８０は、インターネットでよく、この場合、クライアント・プロセスはＷｅｂブラウザであり、サーバ・プロセスはＷｅｂサーバである。
【００５０】
したがって、典型的なクライアント７２０は、中央処理ユニット（ＣＰＵ）、システム・メモリ、パーソナル・コンピュータをインターネットに接続するモデムまたはネットワークカード、およびディスプレイ、ならびにキーボード、マウスなどその他の構成要素を備える従来のパーソナル・コンピュータなど汎用のコンピュータでよい。同様に、典型的なサーバ７４０は、大学または企業のメインフレーム・コンピュータ、または専用ワークステーションなどでもよい。
【００５１】
本発明による構成ファイルの例を提供するサンプルＸＭＬスキーマを、付録Ａの一部として以下に提供するが、この付録は、本発明を記述する本明細書の一部とみなすべきである。
【００５２】
さらに、本発明は、例示したいくつかの態様に関して示し記述してきたが、同等の変更および修正は、本明細書および添付図面を読み理解すれば、当業者が考えつくであろうことを理解されたい。特に、上記の構成要素（アセンブリ、装置、回路、システムなど）によって実行される様々な機能に関して、このような構成要素を記述するために使用される用語（「手段」への言及を含めて）は、別段の指示がない限り、本明細書に示した本発明の例示的態様中の機能を実行する、開示した構造に構造的に同等でなくても、（たとえば機能的に同等である）記述した構成要素の指定された機能を実行する、どんな構成要素にも対応するものである。これに関して、本発明は、システムおよび本発明の様々な方法の動作および／またはイベントを実行するためのコンピュータ実行可能命令を有する、コンピュータ読取り可能媒体を含むことも理解されるであろう。さらに、用語「含む（includes)」、「含んでいる（including）」、「有する（has）」、「有している（having）」、およびその変形は、本明細書または特許請求の範囲のいずれかで使用される限り、これらの用語は、用語「備えている（comprising）」と同様に包括的であるものとする。
【００５３】
（付録  Ａ）  
<?xml version="1.0"?>  
<xs:schema targetNamespace="http://schemas.microsoft.com/SqlServer/DataAccessClass"  
xmlns:xs="http://www.w3.org/2001/XMLSchema"   
elementFormDefault="qualified" attributeFormDefault="unqualified">  
<xs:element name="parameters">  
<xs:complexType>  
<xs:sequence>  
<xs:element name="connectionString">  
<xs:complexType>  
<xs:attribute name="value" type="xs:string" use="required"/>  
</xs:complexType>  
</xs:element>  
<xs:element name="handcodedSprocs" minOccurs="0">  
<xs:complexType>  
<xs:attribute name="file" type="xs:string" use="required"/>  
</xs:complexType>  
</xs:element>  
<xs:element name="prefixToRemove" minOccurs="0">  
<xs:complexType>  
<xs:sequence>  
<xs:element name="sprocNamePrefix" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>  
<xs:element name="sprocArgPrefix" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>  
</xs:sequence>  
<xs:attribute name="isSprocArgInitialLowerCase" type="xs:boolean"/>  
</xs:complexType>  
</xs:element>  
<xs:element name="timeout">  
<xs:complexType>  
<xs:attribute name="command" type="xs:string" use="required"/>  
</xs:complexType>  
</xs:element>  
<xs:element name="output">  
<xs:complexType>  
<xs:sequence>  
<xs:element name="using" type="xs:string" maxOccurs="unbounded"/>  
</xs:sequence>  
<xs:attribute name="file" type="xs:string" use="required"/>  
<xs:attribute name="namespace" type="xs:string" use="required"/>  
<xs:attribute name="class" type="xs:string" use="required"/>  
</xs:complexType>  
</xs:element>  
<xs:choice minOccurs="0" maxOccurs="unbounded">  
<xs:element name="dsSproc">  
<xs:complexType>  
<xs:sequence>  
<xs:element name="table" maxOccurs="unbounded">  
<xs:complexType>  
<xs:sequence>  
<xs:element name="primaryKey" minOccurs= "0" maxOccurs="unbounded">  
<xs:complexType mixed="true">  
<xs:attribute name="fixupType" type="xs:string"/>  
</xs:complexType>  
</xs:element>  
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>  
</xs:complexType>  
</xs:element>  
</xs:sequence>  
<xs:attribute name="name" type="xs:string" use="required"/>  
<xs:attribute name="schema" type="xs:string" use="optional" default="dbo"/>  
</xs:complexType>  
</xs:element>  
<xs:element name="ndsSproc" minOccurs="0" maxOccurs="unbounded">  
<xs:complexType>  
<xs:attribute name="name" type="xs:string" use="required"/>  
<xs:attribute name="schema" type="xs:string" default="dbo"/>  
</xs:complexType>  
</xs:element>  
</xs:choice>  
</xs:sequence>  
</xs:complexType>  
</xs:element>  
</xs:schema>
【図面の簡単な説明】
【００５４】
【図１】本発明の一態様による、データ・アクセス・レイヤーを自動的に生成するデータ・アクセス・レイヤー・クラス・ジェネレータを示す図である。
【図２】本発明の一態様による、データ・アクセス・レイヤーを生成するためにＸＭＬ構成ファイルおよびデータベースのストアード・プロシージャを利用するデータ・アクセス・レイヤー・ジェネレータを示す図である。
【図３ａ】本発明の一態様による、データ・アクセス・レイヤー・クラスを生成する方法を示す図である。
【図３ｂ】本発明の一態様によるデータ・アクセス・レイヤー・クラスを生成する方法を示す図である。
【図３ｃ】本発明の一態様によるデータ・アクセス・レイヤー・クラスを生成する方法を示す図である。
【図４】本発明の一態様によるデータ・アクセス・レイヤー・クラス・ジェネレータを利用する、配備されたシステム（deployed system）を示す図である。
【図５】本発明の一態様によるデータ・アクセス・レイヤーが自動的に生成できる、多層構造の一部としてのＷｅｂサーバと通信するＷｅｂブラウザを示す図である。
【図６】本発明の様々な態様が実施できる適切なコンピューティング環境の簡単で全般的な記述を示す図である。
【図７】本発明によるデータ・アクセス・レイヤーを生成するために本発明の様々な態様を利用することができるクライアント／サーバ・システムを示す図である。
【符号の説明】
【００５５】
１００    多層クライアント・サーバ・アーキテクチャ
１０４    クライアント
１１０    データ・アクセス・レイヤー・クラス・ジェネレータ
１１５    データベース
１２５    中間層
１２７    ビジネス論理レイヤー
１３０    データ・アクセス・レイヤー
２０５    ＸＭＬ構成ファイル
２１０    データベース
２０４    ストアード・プロシージャ１
２０６    ストアード・プロシージャｍ
２１５    データ・アクセス・レイヤー・クラス・ジェネレータ
２２０    データ・アクセス・レイヤー・クラスおよびメソッドの定義
４００    システム
４１０    ストアード・プロシージャを有するデータベース
４１５    データ・アクセス・レイヤー
４２０    中間層
４３０    Ｗｅｂサーバ
４４０    ブラウザＨＴＭＬ
５１０    Ｗｅｂブラウザ
５１５    プロキシ
５２０    クライアント
５３０    スクリプト／アプリケーション
５５０    サーバ
５６０    Ｗｅｂサーバ
５７０    ＤＢインターフェースＡＰＩ
５８０    データベース管理システム
５９０    ネットワーク
６２０    コンピュータ
６２１    処理ユニット
６２２    システム・メモリ
６２７    ハード・ドライブ
６２８    フロッピー（登録商標）・ドライブ
６２９    ディスク
６３０    ＣＤ−ＲＯＭドライブ
６３１    ディスク
６３２    インターフェース
６３３    インターフェース
６３４    インターフェース
６３５    オペレーティング・システム
６３６    アプリケーション
６３７    モジュール
６３８    データ
６４０    キーボード
６４２    マウス
６４６    シリアル・ポート・インターフェース
６４７    モニタ
６４８    ビデオ・アダプタ
６４９    リモート・コンピュータ
６５０    メモリ記憶装置
６５３    ネットワークアダプタ
６５４    モデム
７００    クライアント／サーバ・システム
７１０    クライアント・データ・ストア
７２０    クライアント
７４０    サーバ
７６０    サーバ・データ・ストア
７８０    通信フレームワーク
【図１】
0004814628.tif 000002
【図２】
0004814628.tif 000003
【図３ａ】
0004814628.tif 000004
【図３ｂ】
0004814628.tif 000005
【図３ｃ】
0004814628.tif 000006
【図４】
0004814628.tif 000007
【図５】
0004814628.tif 000008
【図６】
0004814628.tif 000009
【図７】
0004814628.tif 000010