JP4594306B2 - 自己記述型ビジネスオブジェクト - Google Patents

Description

本発明は一般に、デジタルコンピュータによるデータ処理に関し、より詳細には、自己記述型ビジネスオブジェクトに関する。

大規模なビジネスソフトウェアアプリケーションは時として、データをユーザに提示し、ユーザからデータ入力を受け付けるためのグラフィカルユーザインターフェイス（ＧＵＩ）を含む「フロントエンドコンポーネント」に分類されることがある。こうしたフロントエンドコンポーネントは、特定の顧客に合わせてカスタマイズされる。こうしたソフトウェアアプリケーションのもう１つのコンポーネントは、時として、ビジネスデータを格納し、ビジネスロジックに従ってビジネスデータを処理する「バックエンドコンポーネント」と呼ばれることもある。バックエンドコンポーネントは、ビジネスデータを取り出し、生成し、維持する。バックエンドコンポーネントは、通常、データの一貫性および正確さの責任を負う。また、バックエンドコンポーネントは、様々なデータ間の関係を格納することもできる。一般のビジネスソフトウェアアプリケーションでは、フロントエンドコンポーネントは、バックエンドのデータを表示し、集約するアプリケーションコードを含み、バックエンドに対する更新操作の要求を生成する手助けをする。

バックエンドのデータは、リレーショナルデータベースの用語を使用して表すことができる。リレーショナルデータベースの用語では、エンティティはレコード、エンティティタイプは、一意の名前および一意の記述が割り当てられる共通の属性を有する１組のエンティティである。一般に、データベースは、各テーブルがエンティティタイプを表し、各テーブル内の各行がエンティティを表す複数の２次元テーブルを有する。属性とは、エンティティまたはエンティティタイプの特徴の記述である。一般に、属性は、データベーステーブル内のフィールドまたは列において指定される。また、エンティティタイプは、あるエンティティタイプの１つまたは複数のエンティティを別のエンティティタイプの別のエンティティにリンクできるようにする関係を有することもできる。このリンクは、第２のテーブルの主キーを指す１つまたは複数のフィールドを１つのテーブル内に持つことによって、外部キーを使用して行うことができる。これによって、あるテーブル内の１組のエンティティから別のテーブル内の関連するエンティティへのトラバースが可能になる。

リポジトリにおいてサーバからのサービスを表すことを含む、コンピュータプログラム製品を含む方法および装置を提供することであって、サービスは、１つまたは複数のコレクションの中のデータ要素に対する１組の操作を使用して、データ要素のコレクションと対話することを含み、リポジトリは、コレクションおよび各コレクションの共通の属性の記述を含み、リポジトリはメタモデルに従って編成されている。また、この方法は、ソフトウェアエンティティが、リポジトリにおいて表されるサービスを要求することができるようにすることを含み、サービスは、コレクションのうちの第１のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を表し、第１のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を実行する。

一態様では、本発明は、リポジトリにおいてサーバからのサービスを表すことを含む方法を特徴とし、サービスは、１つまたは複数のコレクションの中のデータ要素に対する１組の操作を使用して、データ要素の１つまたは複数のコレクションと対話することを含み、リポジトリは、コレクションおよび各コレクションの共通の属性の記述を含み、メタモデルに従って編成されている。また、この方法は、ソフトウェアエンティティがリポジトリにおいて表されるサービスを要求することを可能にすることを含み、サービスは、コレクションのうちの第１のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を表すことと、第１のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を実行することとを含む。

実施形態は、以下のうちの１つまたは複数を含み得る。リポジトリは、１つまたは複数のコレクションの中のデータ要素の１コレクションに対する専用のアクションの記述をさらに含む。専用のアクションの記述は、専用のアクションの名前、専用のアクションについての入力データのデータ構造の名前、およびデータ要素のコレクションの名前を含む。１組の操作は、サービスプロバイダクラスのメソッドに対応し、場合によっては、１組の操作は、選択、削除、関係による選択、および更新の操作を含む。リポジトリは、データ要素のコレクションの対の間の関係の記述をさらに含む。第１のコレクションはデータ要素の第２のコレクションと関係があり、関係の記述はリポジトリに格納され、この関係によって、ソフトウェアエンティティは、第１のコレクションのデータ要素を指定することによって第２のコレクションのデータ要素の取り出しを要求することができる。リポジトリはデータベースである。

第１の操作を実行することは、メモリストレージからデータ要素の第１のコレクションの属性のうちの１つまたは複数を読み取ること、および、ソフトウェアエンティティにその属性を送信することを含む。場合によっては、第１の操作を実行することは、データ要素のコレクションの属性のうちの１つまたは複数を計算すること、および、ソフトウェアエンティティにその属性を送信することをさらに含む。コレクションおよびコレクションの共通の属性の記述は、コレクションの名前、および属性を定義するデータ構造の記述を含む。

第１の操作はクエリであり、第１の操作を実行することは、第１のコレクションの中の個々のデータ要素を検索すること、および、個々のデータ要素を表すキーを戻すことをさらに含む。場合によっては、リポジトリは、クエリの検索パラメータ構造、およびデータのコレクションから１つまたは複数のデータをフィルタリングするために使用されるキーを定義する入力名を含むクエリの定義を含む。

また、実施形態は、ソフトウェアエンティティがリポジトリにおいて表されるサービスを要求することを可能にすることを含み、サービスは、コレクションのうちの第２のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を表すことと、第２のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を実行することとを含むことができる。

別の態様では、本発明は、クライアントプログラムを実行するように構成されている第１のコンピュータ、サーバプログラムを実行するように構成されている第２のコンピュータ、およびサーバプログラムが以下のことを実行するように構成されるように第１および第２のコンピュータをリンクするネットワークを含むシステムを特徴とする。リポジトリにおいてサーバプログラムからのサービスを表し、サービスは１つまたは複数のコレクションの中のデータ要素に対する１組の操作を使用してデータ要素のコレクションと対話することを含み、リポジトリは、コレクションおよび各コレクションの共通の属性の記述を含み、リポジトリは、メタモデルに従って編成されている。クライアントプログラムがリポジトリにおいて表されるサービスを要求できるようにし、サービスは、コレクションのうちの第１のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を表す。第１のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を実行する。

実施形態は、以下のうちの１つまたは複数を含み得る。リポジトリは、１つまたは複数のコレクションの中のデータ要素の１コレクションに対する専用のアクションの記述をさらに含む。場合によっては、専用のアクションの記述は、専用のアクションの名前、専用のアクションについての入力データのデータ構造の名前、データ要素のコレクションの名前を含む。１組の操作は、サービスプロバイダクラスのメソッドに対応する。場合によっては、１組の操作は、選択、削除、関係による選択、更新の操作を含む。

実施形態は、以下のうちの１つまたは複数を含み得る。リポジトリは、データ要素のコレクションの対の間の関係の記述をさらに含む。第１のコレクションはデータ要素の第２のコレクションと関係があり、関係の記述はリポジトリに格納され、この関係によって、クライアントプログラムは、第１のコレクションのデータ要素を指定することによって第２のコレクションのデータ要素の取り出しを要求することができる。リポジトリはデータベースである。第１の操作を実行することは、メモリストレージからデータ要素の第１のコレクションの属性のうちの１つまたは複数を読み取ること、および、クライアントプログラムにその属性を送信することを含む。場合によっては、第１の操作を実行することは、データ要素のコレクションの属性のうちの１つまたは複数を計算すること、および、ソフトウェアエンティティにその属性を送信することをさらに含む。

実施形態は、以下のうちの１つまたは複数を含み得る。コレクションおよびコレクションの共通の属性の記述は、コレクションの名前、および属性を定義するデータ構造の記述を含む。第１の操作はクエリであり、第１の操作を実行することは、第１のコレクションの中の個々のデータ要素を検索すること、および、個々のデータ要素を表すキーを戻すことをさらに含む。場合によっては、リポジトリは、クエリの検索パラメータ構造、およびデータのコレクションから１つまたは複数のデータをフィルタリングするために使用されるキーを定義する入力名を含むクエリの定義を含む。システムは、さらに、クライアントプログラムがリポジトリにおいて表されるサービスを要求することを可能にすることを含み、サービスは、コレクションのうちの第２のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を表すことと、第２のコレクションの中の１つまたは複数のデータ要素に対する第１の操作を実行することとを含む。

これらおよび他の実施形態は、以下の利点のうちの１つまたは複数を有し得る。サービスプロバイダおよびサービスの消費者の独立したソフトウェアライフサイクルがあり得る。サービスベースのソフトウェアアーキテクチャによって提供されたサービスは、様々な状況に再利用することができる。ソフトウェアアーキテクチャの汎用エンジンは、新しいアプリケーションのためのサービスを結合することができる。

本発明の１つまたは複数の実装形態の詳細を、添付の図面および以下の説明に記載する。さらに、本発明の特徴、実施形態、および利点は、説明、図面、および特許請求の範囲から明らかになる。

図１は、クライアント３、分離層５、リポジトリ７、およびバックエンドデータ９および９’を含むビジネスソフトウェアアーキテクチャ２の論理表現の概略を示している。クライアント３は、ユーザがバックエンドデータ９および／または９’と対話できるようにするユーザインターフェイス（ＵＩ）を提供する。バックエンド９および９’は、異なるバックエンドアプリケーションに関連付けることができ、かつ／または互いに異なるように整え、フォーマットすることができる。分離層５は、クライアント３によって提供されたフロントエンドユーザインターフェイスをバックエンドデータ９および９’から分離する。この分離によって、クライアント３は、バックエンドデータ９および９’間のフォーマットまたはアプリケーションに関連する差異に関係なく、一貫した同様の方法でバックエンドデータ９および９’と対話することができる。言い換えれば、クライアント３が分離層５と対話するように構成され、分離層５が変わった場合のみクライアント３を更新すれば良いように、分離層５は、バックエンドデータ９および９’への正規のインターフェイスを提供する。バックエンドデータ９および９’への変更は、クライアント３への更新を必要としない。さらに、分離層５は、拡張性があり、バックエンドデータ９および９’、およびさらに分離層５に接続される他の任意の異なるバックエンドデータおよびバックエンドサービスへの変更および増加に対応するように構成されている。

以下でより詳しく説明するように、分離層５は、バックエンドデータ（９および９’など）がどのように分離層５で表されるかを定義するメタモデルに基づいている。バックエンドデータ９および９’がどのようにメタモデル表現に適合するかを記述するメタデータがリポジトリ７に格納される。クライアント３は、分離層５によって定義される汎用のコマンドセットを使用してバックエンドデータ９および９’と対話する。以下でより詳しく説明するように、分離層５は、リポジトリ７内のメタデータを使用して、クライアント３からの汎用のコマンドを実行するサービスプロバイダにアクセスして、バックエンドデータ９および９’の要求された操作を行う。サービスプロバイダは、異なるサービスプロバイダを異なるバックエンドデータ９および９’に使用できるように構成可能である。分離層５は、対応するバックエンドデータ９および９’の特徴、並びに実装の粒度および配布（すなわちサービスプロバイダ）を隠すインターフェイス（サービスマネージャなど）を含む。

図２は、ビジネスソフトウェアアーキテクチャ２の実装例を示している。図２に示すように、ビジネスソフトウェアアーキテクチャ２は、第１のコンピュータ４および第２のコンピュータ６を含む。コンピュータ４および６はそれぞれ、プロセッサ（ＣＰＵ）バスによって結合されたプロセッサ、ランダムアクセスメモリ（ＲＡＭ）、プログラムメモリ（例えばフラッシュＲＯＭなどの書き込み可能読み取り専用メモリ（ＲＯＭ））、ハードドライブコントローラ、ビデオコントローラ、および入力／出力（Ｉ／Ｏ）コントローラを含み得る。コンピュータ４および６を、例えばＲＯＭ内で予めプログラミングしておくことができる。または、コンピュータ４、６は、プロセッサによって実行できるように、プログラムを別のソース（フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、別のコンピュータなど）からＲＡＭにロードすることによってプログラミング（または再プログラミング）することができる。ハードドライブコントローラは、本発明を具現するプログラムを含む、実行可能なコンピュータプログラムおよびデータを格納するのに適したハードディスクに結合される。入力／出力コントローラは、入力／出力バスによって入力／出力インターフェイスに結合される。入力／出力インターフェイスは、シリアルリンク、ローカルエリアネットワーク、無線リンク、またはパラレルリンクなどの通信リンクを介してアナログ形式またはデジタル形式でデータを送受信する。また、入力／出力バスには、ディスプレイおよびキーボードが結合される。あるいは、入力／出力インターフェイス、ディスプレイ、およびキーボードに個別の接続（個別のバス）を使用することができる。

ネットワーク２０は、コンピュータ４および６を接続する。ネットワーク２０は、例えば通信ネットワークなど、任意の形式または媒体のデジタルデータ通信である。通信ネットワーク２０の例には、ローカルエリアネットワーク（「ＬＡＮ」）および広域ネットワーク（「ＷＡＮ」）、例えばインターネットなどがある。

コンピュータ４は、フロントエンドアプリケーションプログラム１２の命令を実行する。アプリケーションプログラム１２は、ビジネスソフトウェアアーキテクチャ２のフロントエンドコンポーネントを表す。コンピュータ６上で稼働しているサービスマネージャ１６は、フロントエンドアプリケーションプログラム１２と１組のバックエンドサービスプロバイダ２６との間のサービス層である。サービスマネージャ１６は、サービスインターフェイスをフロントエンドアプリケーションプログラム１２に提供して、コンピュータ６上で稼働する１組のバックエンドサービスプロバイダ２６との間接的な対話を可能にする。このサービスインターフェイスは、フロントエンドアプリケーションプログラム１２および１組のバックエンドサービスプロバイダ２６のソフトウェア開発の部分的な分離を可能にする。

コンピュータ６は、１組のバックエンドサービスプロバイダ２６によって使用することができるデータを含むバックエンドデータベース２４を格納するデータ記憶装置２２を含む。また、コンピュータ６は、１組のバックエンドサービスプロバイダ２６によって提供されるサービスを定義し、記述する情報リポジトリ１８を含むデータ記憶装置８も含む。リポジトリ１８内のメタデータは、メタモデルに従って編成される。

一般に、メタモデルは、ある領域を記述することができる語彙である「概念」のコレクションである。メタモデルは一般に、ほとんどの場合ＥＲＡ（実体−関連−属性：entity-relationship-attribute）またはオブジェクト指向のモデリングから導出される厳格な１組のルールに従って構築される。フロントエンドアプリケーションプログラム１２は、サービスマネージャ１６を介してリポジトリ１８の中身にアクセス（し、厳格な１組のルールに従ってそれを解釈）することができる。これらのサービスは、アプリケーションプログラム１２の機能をサポートし、格納されているデータを修正することに加えて、データを取り出すこと、および、読み取ることを含む。サービスプロバイダ２６は、バックエンドデータベース２４内に格納されているデータにアクセスし、またはそれを修正して、サービスをフロントエンドアプリケーションプログラム１２に提供することができる。サービスを提供するために、１組のバックエンドサービスプロバイダ２６は、フロントエンドアプリケーションプログラム１２から要求があると、バックエンドデータベース２４内に格納されているデータにアクセスしたりデータを修正したりするか、または新しいデータを算出する。

リポジトリ１８は、１組のバックエンドサービスプロバイダ２６によって提供されるサービスを要求する構文を定義し、サービスを意味的に記述する。フロントエンドアプリケーションプログラム１２が実行されるとき、フロントエンドアプリケーションプログラム１２は、（サービスマネージャ１６を介してアクセスされる）リポジトリ１８からのこの構文および意味的記述を使用して、その要件を満たすために、フロントエンドアプリケーションプログラム１２がどのサービスを使用することができるかを決定する。格納されている、または算出されたバックエンドデータについての構文および意味的記述を、「メタデータ」と呼ぶことができる。この格納されている、または算出されたバックエンドデータは、ビジネスオブジェクトの点から見たオブジェクト指向用語を使用して、概念的に編成される。この場合、各ビジネスオブジェクトは、クラスまたはデータエンティティタイプのインスタンスである。一例では、ビジネスオブジェクトのクラスは、テーブル内のデータの各行が特定のビジネスオブジェクトのデータを表すリレーショナルデータベーステーブルを参照する。この例では、テーブル内の各フィールドは、ビジネスオブジェクトクラスの属性を表す。別の例では、テーブル内のフィールドの一部がビジネスオブジェクトクラスの属性を表し、他のフィールドが要求に応じて算出されるように、リレーショナルデータベースを部分的に参照するビジネスオブジェクトのクラスがある。

ビジネスソフトウェアアーキテクチャ２において、フロントエンドアプリケーションプログラム１２に提供されるサービスの焦点はデータに絞られているため（データ中心）、リポジトリ１８内のこれらのサービスの記述もデータ中心である。したがって、リポジトリ１８内のメタデータは、これらのビジネスオブジェクトのクラスの表現を核にして構築される。このメタデータは、アスペクト、すなわちビジネスオブジェクトクラスのこれらの表現の記述、およびサービスプロバイダ２６によって提供される選択、挿入、更新、削除、関係による選択、およびフィールドの更新など、アスペクトに対する使用可能な操作の記述を含む。これらのアスペクトの各記述は、データ属性、およびこれらのアスペクトのインスタンスにおいて１組のバックエンドサービスプロバイダ２６によって実行されるよう要求することができるアクションを含む。

データの分類、データクラス間の関係、データにアクセスするための予め構築されたクエリ、１組のバックエンドサービスプロバイダ２６によって提供されたデータのその他の記述は、リポジトリ１８によって表される。１組のバックエンドサービスプロバイダ２６によって提供された（例えばバックエンドデータベース２４に格納されている）データの表現、すなわちメタデータは、バックエンドデータベース２４内のデータの異なる抽象型またはクラス、および異なるデータクラスがどのように互いに関連するかを記述する。オブジェクトとは、これらの異なる抽象型のインスタンスである。メタデータとは、データの内容ではなく、データについての情報である。また、メタデータは、データベース２４内のデータに対して実行することができる予め構築された１組のクエリも定義する。

リポジトリ１８内の意味的記述によって、フロントエンドアプリケーションプログラム１２は、サービスマネージャ１６にどのサービスを要求すべきかを決定することができる。これらのサービスは、しばしば表示すべきデータを要求する形式を取る。フロントエンドアプリケーションプログラム１２は、リポジトリ１８内のメタデータを読み取り、メタデータによって指定された様々な方法で編成されたデータを柔軟に要求することができる。例えば、異なる２つのリポジトリ１８を備える２つのサービスマネージャ１６は、会社ＡおよびＢの本の価格を決定するサービスを扱う。ＡおよびＢでは、本の価格は、様々なアスペクトによって様々なデータフィールドで表される。フロントエンドアプリケーションプログラム１２は、Ａのリポジトリ１８を読み取り、Ａのサービスプロバイダ２６から特定の本に関する（価格を含む）データの記述を取得する。フロントエンドアプリケーションプログラム１２は、Ｂのリポジトリ１８を読み取り、Ｂのサービスプロバイダ２６から特定の本に関する（価格を含む）データの記述を取得する。フロントエンドアプリケーションプログラム１２は、本の価格情報をユーザに提示するために、Ａのサービスプロバイダ２６からの情報、およびＢのサービスプロバイダ２６からの異なって編成された情報を要求し、表示することができる。

リポジトリ１８内の意味的記述によって記述されたサービスを要求するために、サービスマネージャ１６は、バックエンド内のビジネスオブジェクトに対するサービスのための正規のインターフェイスを提供する。この正規のインターフェイスは、ビジネスオブジェクトに対する１組の標準操作を含む。ビジネスオブジェクトに対するこうした標準操作には、選択、挿入、更新、削除、関係による選択、およびフィールドの更新などがある。これらの標準操作は、理解しやすく、また使いやすくするためのものである。これらの標準操作の使用は、リポジトリ１８のメタモデルの厳格な１組のルールを介して理解される。さらに、リポジトリ１８は、操作の使用による副作用であるドキュメント化されたモデリング（documented modeling）も含む。ビジネスオブジェクトを格納した操作モデルの副作用は、メソッドを実行することによって影響を受ける。例えば、「削除」は通常、削除されたオブジェクトに関連する格納されている他のビジネスオブジェクトに副作用を及ぼす。他の標準操作は、より特化したタスクを実行し、フロントエンドアプリケーションプログラム１２とサービスマネージャ１６との間のトランザクションのための機能をサポートする（ロック操作など）。

サービスマネージャ１６によって提供される正規のインターフェイスは、ビジネスオブジェクトの特定のクラスのために定義される専用のアクション、およびビジネスオブジェクトのクラスのクラスタのために定義され得るクエリも含んでいる。クラスタは、メタデータ内のサービスモジュール（以下でさらに詳述する）としてモデリングされる。これらのアクションおよびクエリも、リポジトリ１８のメタデータ内で定義される。

実行中、フロントエンドアプリケーションプログラム１２は、サービスマネージャ１６にサービス要求を発行し、サービスマネージャ１６は、リポジトリ１８内のメタデータとの一致について要求をチェックし、次いでサービスマネージャ１６は、リポジトリデータベース１８内のメタデータに従って要求をバックエンドサービスプロバイダ２６に渡す。１組のバックエンドサービスプロバイダ２６およびデータベース２４内のデータを実施する方法は、バックエンドサービスプロバイダ２６およびデータベース２４内のデータがリポジトリ１８内のメタデータの定義および記述に準拠している状態で、アプリケーション１２から独立している。データベース２４は、リレーショナルデータベースとすることができる。しかし、バックエンドサービスプロバイダ２６およびデータベース２４内のデータがリポジトリ１８内のメタデータに準拠する場合、リレーショナルデータベース以外の異なるモードのデータ構成を使用するためにデータベース２４を変更することができ、フロントエンドアプリケーションプログラム１２を変更する必要はない。データベース２４のこうした異なるモードのデータ構成の１つは、オブジェクト指向データベースである。

フロントエンドアプリケーションプログラム１２は、モニタ１０に表示されるユーザインターフェイスを提供する。フロントエンドアプリケーションプログラム１２は、１組のバックエンドサービスプロバイダ２６から受信されたデータを表示し、集約するためのアプリケーションコードを提供する。フロントエンドアプリケーションプログラム１２は、サービスマネージャ１６を介して、より特化した操作に加えて、選択、挿入、更新、削除、および実行などの標準的な操作についての１組のバックエンドサービスプロバイダ２６に対する要求を生成する。フロントエンドアプリケーションプログラム１２は、対話中心であり、バックエンドサービスプロバイダ２６のデータを集約し、対話するステップを組み合わせて画面の流れおよびシンジケート化された画面要素にすることに焦点をおいている。

フロントエンドアプリケーションプログラム１２は、ユーザインターフェイス（ＵＩ）指向アプリケーションの画面遷移ロジック（screen-flow logic）を含んでおり、フロントエンドアプリケーションプログラム１２は、ＵＩをリポジトリ１８内のメタデータに結合する。フロントエンドアプリケーションプログラム１２は、リポジトリ１８のメタデータ内のサービスの記述を介して、バックエンドサービスプロバイダ２６によって、１組の特定のバックエンドサービスに間接的に結合することができる。フロントエンドアプリケーションプログラム１２は、バックエンドサービスプロバイダ２６への仲介物として働くサービスマネージャ１６によって高度に標準化されたサービス層への構成によって結合されただけの、様々な汎用の対話中心フロントエンド層から形成することもできる。

一部の実装形態では、サービスマネージャプロキシ１４は、フロントエンドアプリケーションプログラム１２に、サービスマネージャ１６によって提供されたサービスインターフェイスへの緩衝化したアクセスを提供する。サービスマネージャプロキシ１４は、フロントエンドアプリケーションプログラム１２とサービスマネージャ１６との間の仲介物として働くコンピュータ４のサーバであり、ビジネスソフトウェアアーキテクチャ２が、セキュリティ、管理制御（administrative control）、およびキャッシングサービスを確実にすることができるようにする。サービスマネージャ１６は、往復の無駄を無くすために、（結果的にサービスメソッドをもたらす）いくつかのサービス要求またはコマンドを単一のサービスメソッドキューにバンドルするためにフロントエンドアプリケーションプログラム１２によって使用されるキュー機能を提供する。サービスマネージャプロキシ１４によって、フロントエンドアプリケーションプログラム１２およびサービスマネージャ１６が異なるコンピュータ４、６に分かれるようにすることができる。さらに、サービスマネージャプロキシ１４の使用によって、サービスマネージャ１６および１組のバックエンドサービスプロバイダ２６を、複数のコンピュータにわたって分散させることができる。

一例では、サービスマネージャプロキシ１４は、ネットワーク２０を介してＳＯＡＰ（Simple Object Access Protocol）メッセージを使用してサービスマネージャ１６と通信する。ＳＯＡＰは、ある種類のオペレーティングシステム（ワシントン州レドモンド在のＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ（登録商標）ＸＰオペレーティングシステムなど）で稼働するプログラムが、ＷＷＷのＨＴＴＰ（ハイパーテキスト転送プロトコル）およびＸＭＬ（拡張可能なマークアップ言語）を情報交換の機構として使用することによって、同じまたは別の種類のオペレーティングシステム（Ｌｉｎｕｘ（登録商標）など）のプログラムと通信するための方法である。Ｗｅｂプロトコルが組み込まれており、すべての主なオペレーティングシステムプラットフォームによって使用可能であるため、ＨＴＴＰおよびＸＭＬは、あるネットワークにおいて様々なオペレーティングシステム下で稼働しているプログラムがどうやって互いに通信することができるかの問題の解決策を提供する。ＳＯＡＰは、あるコンピュータのプログラムが別のコンピュータのプログラムを呼び出し、それに情報を渡すことができるように、ＨＴＴＰヘッダおよびＸＭＬファイルをエンコードする方法を正確に指定する。また、ＳＯＡＰは、呼び出される側のプログラムがどうやって応答を戻すことができるかも指定する。

図３に示すように、サービスマネージャ１６は、１組のバックエンドサービスプロバイダ２６およびデータベース２４内のデータから対応するバックエンドサービスプロバイダの特徴を隠す（リポジトリ１８内のメタデータによって定義された）インターフェイスをフロントエンドアプリケーションプログラム１２に提供する。フロントエンドアプリケーション１２は、このインターフェイスを使用して、ユーザとの対話のためにグラフィカルユーザインターフェイス（ＧＵＩ）２８で表示するデータを、バックエンドデータベース２４から取り出す。

サービスマネージャ１６は、フロントエンドアプリケーションプログラム１２からバックエンドサービスプロバイダ２６への要求を受信し、それを実行することによって、インターフェイスをフロントエンドアプリケーションプログラム１２に提供する。サービスマネージャ１６は、要求の各受信の後、その要求を１つまたは複数のサービスプロバイダ３０、３２、３４、４０、４２、４４、および４６に委ねる。サービスプロバイダ３０は、ソフトウェアクラスのリポジトリサービスプロバイダのインスタンスである。サービスプロバイダ３２、３４、４０、４２、４４、および４６は、クエリサービスプロバイダクラス（３２）、アスペクトサービスプロバイダクラス（３４）、トランザクションサービスプロバイダクラス（４０）、ロッキングサービスプロバイダクラス（４２）、アクションサービスプロバイダクラス（４４）、およびクエリ関係サービスプロバイダクラス（４６）などのソフトウェアクラスのインスタンスを表す。サービスプロバイダのソフトウェアクラス３２、３４、４０、４２、４４、および４６は、ドイツ、Ｗａｌｌｄｏｒｆ在の本件特許出願人から入手可能なＡＢＡＰ（登録商標）（Advanced Business Application Programming）開発環境を使用するＡＢＡＰ（登録商標）クラスライブラリによって維持されるＡＢＡＰ（登録商標）グローバルクラスとして実装することができる。これらは、Ｌｉｎｕｘ（登録商標）でのＪａｖａ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）でのＣ＃など、他の任意のプラットフォームでの他の任意のプログラミング言語によっても実装することができる。

リポジトリサービスプロバイダ３０は、リポジトリ１８からメタデータを取得し、またはそれを変更する旨の要求を扱う。クエリサービスプロバイダ３２は、フロントエンドアプリケーションプログラム１２からのバックエンドデータベース２４内のデータに対するクエリを扱う。アスペクトサービスプロバイダ３４は、データへのアクセス、データの修正、関係のナビゲーション、およびアクションの呼び出しを扱う。アスペクトサービスプロバイダ３４は、サービスマネージャ１６から要求することができるアスペクトに対する、標準操作に対応する標準的な１組のメソッドを有する。こうした標準操作には、選択、挿入、更新、削除、関係による選択、およびフィールドの更新などがある。トランザクションサービスプロバイダ４０によって、ビジネスロジックは、フロントエンドアプリケーションプログラム１２とサービスプロバイダ２６との間のトランザクションの異なる状態に対して作用することができる。ロッキング（locking）サービスプロバイダ４２によって、バックエンドデータベース２４内のデータ型における同時アクセスの分離が可能になる。アクションサービスプロバイダ４４によって、アスペクトへのアクションの実行が可能になる。クエリ関係サービスプロバイダ４６は、ある関係のターゲットアスペクトについてのインターフェイスである。一部の例では、サービスマネージャ１６は、サービスを表すリポジトリ１８内の様々な要素についての、サービスプロバイダ３２、３４、４０、４２、４４、および４６の様々な複数のインスタンスを有することができる。リポジトリ１８内のある要素によって表されるサービスの要求を受信すると、サービスマネージャ１６は、リポジトリ１８内のその要素のメタデータ内で、サービスプロバイダ（３２、３４、４０、４２、４４、および４６など）の名前を調べることができる。例えば、リポジトリ１８内のあるアスペクトを記述するメタデータは、どのアスペクトサービスプロバイダ３４がそのアスペクトのサービスを扱うように設計されるかを定義する。サービスマネージャ１６は、メタデータ内のこの情報を使用して、要求をフロントエンドアプリケーションプログラム１２から適切なアスペクトサービスプロバイダ３４に送る。同様に、リポジトリ１８内のあるクエリを記述するメタデータは、どのクエリサービスプロバイダ３２がそのクエリのサービスを扱うように設計されるかを定義する。

サービスマネージャ１６によって提供されるインターフェイスは、要求またはコマンドをフロントエンドアプリケーションプログラム１２に提供する。上述したように、標準コマンドの選択、挿入、更新、削除、関係による選択、およびフィールドの更新は、リポジトリ１８内のアスペクトへの標準操作である。これらの標準操作は、アスペクトサービスプロバイダ３４によって提供され、フロントエンドアプリケーションプログラム１２への使用可能な要求またはコマンドの一部に対応する。「Ｓｅｌｅｃｔ」コマンドは、アスペクトサービスプロバイダ３４によって提供された（例えばデータベース２４に格納されている）データ型のインスタンスの識別子（またはキー）がわかっている場合、フロントエンドアプリケーションプログラム１２がこれらのインスタンスの属性を選択し、読み取ることができるような機能を提供する。「Ｉｎｓｅｒｔ」コマンドによって、フロントエンドアプリケーションプログラム１２は、アスペクトサービスプロバイダ３４によって提供された（例えばデータベース２４に格納されている）データ型の新しいインスタンスを追加することができる。「Ｓｅｌｅｃｔ Ｂｙ Ｒｅｌａｔｉｏｎ」コマンドは、データ型がわかっている場合、フロントエンドアプリケーションプログラム１２がリポジトリ１８で定義されているこのデータ型に関係がある他のデータ型を見つけることができる機能を提供する。「Ｕｐｄａｔｅ」コマンドは、アスペクトサービスプロバイダ３４によって提供された（例えばバックエンドデータベース２４に格納されている）データ型のインスタンスを修正する機能を提供する。「Ｄｅｌｅｔｅ」コマンドは、アスペクトサービスプロバイダ３４によって提供された（例えばバックエンドデータベース２４に格納されている）１つまたは複数のデータ型の１つまたは複数の選択されたインスタンスを削除する機能を提供する。

「Ｅｘｅｃｕｔｅ」アクションコマンドは、アスペクトサービスプロバイダ３４によって提供された（例えばデータベース２４に格納されている）１つまたは複数のデータ型の１つまたは複数のインスタンスへの、意味的に定義されたアクションを実行する機能を提供する。アスペクトサービスプロバイダ３４またはアクションサービスプロバイダ４４がＥｘｅｃｕｔｅアクションコマンドを実行する。「Ｑｕｅｒｙ」コマンドは、対象の特定のデータを検索し、見つける機能を提供する。Ｑｕｅｒｙコマンドは、一定の組の検索パラメータ、および構造が定義された結果セットを備えるメソッドである。特定のサービスモジュール、またはリポジトリ１８のメタデータ内のアスペクトのクラスタについてのクエリが定義される。クエリサービスプロバイダ３２がＱｕｅｒｙコマンドを実行する。

リポジトリ１８内のメタデータは、データ型またはクラスに分類される。リポジトリ１８内のデータ型の分類を表すメタモデルクラスの名前は、それらがそのメタモデルに属することを表し、サービスマネージャ１６によって使用されているランタイムクラスと区別するために、接尾辞「記述子」を有する。リポジトリ１８のメタデータのクラスの記述子、およびそのクラス関係は、図４の統一モデリング言語（ＵＭＬ）クラス図５０を使用して示されている。

メタデータを、リレーショナルデータベースの用語で記述されるデータと比較すると、リポジトリ１８内のアスペクトは、バックエンドデータベース２４に完全にまたは部分的に格納されているクラスまたはエンティティ型を表すことができ、アスペクト記述子５６は、エンティティ型についての他の情報に加えて、エンティティ型の属性を含む。また、リポジトリ１８内のメタデータは、データベース２４内に実装することができるアスペクト間の関係を、リレーショナルデータベースで外部キーを使用する関係として定義する関係記述子８４を含むこともできる。また、メタデータは、アスペクトの集合であり、データベース２４内のデータにアクセスするための予め定義されたクエリを有するサービスモジュールを表すサービスモジュール記述子５４を含むこともできる。

リポジトリ１８内で定義されたサービスモジュールは、特定の応用分野または業界のためのビジネスソフトウェアアーキテクチャ２における１組のアプリケーション（フロントエンドアプリケーションプログラム１２など）の基礎的要素である。サービスモジュールは、その実装およびビジネスロジックをカプセル化し、統一された正規の方法でデータおよび機能へのアクセスを提供する。リポジトリ１８内のサービスモジュールの例には、「ビジネスパートナー」、「従業員」、「販売注文」、または「企業活動」がある。サービスモジュール記述子５４は、リポジトリ１８のメタデータのデータモデル内のサービスモジュール、およびアプリケーションプログラム１２からのクエリによってサービスモジュールにどのようにアクセスできるかを記述する。

リポジトリ１８において、定義された各クエリは、サービスマネージャ１６を介してサービスプロバイダ２６によって提供された（アスペクトによって表される）データ型のインスタンスを検索するためのエントリポイントである。「キー」とは、サービスプロバイダ２６によって提供されたデータ型のインスタンスの識別子である。「アクション」とは、アスペクトの１つまたは複数のインスタンスに対する専用のメソッドである。「構造」とは、アスペクトのデータを表す属性の集合である。「関係」とは、ソースのオブジェクトとターゲットアスペクトとの間の関係である。サービスモジュールグループは、サービスモジュールに関連付けられており、アスペクト、関係、およびクエリの集合である。アスペクトグループは、アスペクトに関連付けられており、関係、アスペクトアクション、およびフィールド記述子８６の集合である。また、リポジトリ１８内のメタデータは、使用可能なバックエンド（バックエンドデータベース２４など）に含まれる各アスペクト、クエリ、キー、アクション、構造、関係、サービスモジュールグループ、およびアスペクトグループのテキストの記述も含む。そのため、リポジトリ１８内のメタデータの編成は、こうしたデータ型（例えばアスペクト、クエリ、キー、アクション、構造、関係、サービスモジュールグループ、およびアスペクトグループ）の観点から記述することができる。

アスペクト、クエリ、キー、およびアクションの属性についてのデータモデルは、構造記述子７４に基づく。一例では、各アスペクトは、アスペクトのデータ属性を定義する１つの構造記述子７４を有する。構造記述子７４は、リポジトリ１８内のデータ辞書を参照する。データ辞書は、プログラマ、および構造記述子を参照する必要がある人のための、データモデル内のデータオブジェクトまたは項目の記述子のコレクションである。構造記述子７４は、ＸＭＬスキーマ、またはリポジトリ１８内の１つまたは複数のデータベーステーブルで定義することができる。

一例では、リポジトリ１８で定義された構造記述子７４は、データベーステーブルのフラット構造を含む。フラット構造とは、実数、整数、文字列、ブール値などの単純な値型（simple value types）の属性名とフィールド記述子８６との対のシーケンスである。例えば、２次元のある点を定義する構造記述子７４は、リスト{Ｘ，ｒｅａｌ，Ｙ，ｒｅａｌ}とすることができ、この場合、ＸおよびＹは実数値を有する属性名である。

リポジトリ１８の別の例では、構造記述子７４は、他の構造記述子７４のネスティングおよびコレクションを含み得る。より大きいアスペクトの生成を可能にするために他の構造記述子７４またはサブ構造をネストすることは、より小さいアスペクトを定義するサブ構造についてのキーの使用がわからないときに有用である。

フロントエンドアプリケーションプログラム１２がサービスマネージャ１６を介してサービスプロバイダ２６からのデータ（バックエンドデータベース２４に格納されているデータなど）にアクセスするために、ビジネスオブジェクトクラスのインスタンスは、例えば注文番号や製品のＩＤなど、サービスモジュール内の一意のキーによって識別される。サービスモジュール内の様々なアスペクトについての様々なタイプのキーを区別するために、キー記述子６４は様々なタイプのキーを定義する。キー記述子６４は、複数のデータ属性を含むことができる構造記述子７４に関連付けられる。一例では、各キーは、文字列属性を有する。サービスモジュールを、様々なアスペクトについての様々なキー記述子６４に関連付けることができる。例えば、注文キーは、注文品目キーとして別のキー記述子６４を有していてもよい。

サービスモジュール記述子５４は、アスペクト記述子５６のコレクションを含む。アスペクト記述子５６は、１つの構造記述子７４および１つのキー記述子６４を参照する。構造記述子７４は、対応するキー記述子６４のすべてのキー属性を含む。キー記述子６４は、専用のアスペクト記述子５６である。あるキーのキー記述子６４の属性は、自己参照としてそれ自体を参照する。簡単な販売注文サービスモジュール内のアスペクト記述子５６の例は、Ｏｒｄｅｒ、Ｏｒｄｅｒ Ｄｅｔａｉｌ、Ｓｈｉｐｐｉｎｇ Ａｄｄｒｅｓｓ、Ｂｉｌｌｉｎｇ Ａｄｄｒｅｓｓ、Ｏｒｄｅｒ Ｉｔｅｍ、およびＯｒｄｅｒ ＩＤやＯｒｄｅｒ Ｉｔｅｍ Ｋｅｙなどのキーアスペクトの記述子を含み得る。サービスモジュール記述子５４は、サポートされているアスペクト記述子５６のコレクションを指定する。複数のサービスモジュール記述子５４は、同じアスペクト記述子５６に関連付けることができる。

アスペクト記述子５６は、関係記述子８４によって指定され、相互に関連する。関係記述子８４は、１つのソースアスペクト記述子５６および１つのターゲットアスペクト記述子５６を有する。この意味では、関係記述子８４は有向である。関係記述子８４は、オプションの基数（１．．．ｎなど）およびカテゴリも有する。サポートされているカテゴリは、例えば、親−子または子−親などである。

ソースアスペクトＡとターゲットアスペクトＢとの間の関係を定義する関係記述子８４は、アスペクトＡのインスタンスからアスペクトＢのインスタンスへのトラバースが可能であることを意味する。例えば、アスペクトＡとＢがリレーショナルデータベーステーブルとしてバックエンドデータベース２４に実装されていると仮定すると、これは、アスペクトＡに対応するテーブル内の１つまたは複数のフィールドが、アスペクトＢに対応するテーブルの主キーを指すことを意味する。ソースアスペクトＡおよびターゲットアスペクトＢから親−子関係を定義する関係記述子８４は、アスペクトＢがアスペクトＡの存在に依存することを意味する。例えば、アスペクトＡおよびＢがリレーショナルデータベーステーブルとしてバックエンドデータベース２４に実装されていると仮定すると、これは、アスペクトＢに対応するテーブルの主キーがアスペクトＡに対応するテーブルから導出されることを意味する。関係記述子８４は、例えば、販売注文サービスモジュール内の注文から届け先住所（基数１．．．１）または注文品目（基数１．．．ｎ）など、同じサービスモジュール内のあるアスペクトから別のアスペクトへの内部ナビゲーションを記述するために導入される。関係記述子８４は、サービスモジュールに依存しておらず、様々なサービスモジュールによって再利用することができる。バックエンドデータベース２４内のあるデータ型から別のデータ型への内部ナビゲーションまたはトラバースの場合、ソースアスペクト記述子５６の可視の（使用可能な）関係記述子は、サービスモジュール記述子５４によって定義され、サービスモジュール記述子は、サポートされている関係記述子８４のリストを有している。ナビゲーションは、サービスモジュール記述子５４によってもサポートされているターゲットアスペクト記述子５６を有する、サポートされている関係記述子８４について許容される。

バックエンドデータベース２４内のデータ型にアクセスし、それに作用する操作は、操作記述子７０において記述される。構造記述子７４は、操作記述子７０の入力パラメータを定義する。この構造記述子７４は、一括（ｍａｓｓ）およびフィルタ操作を可能にする入力キー記述子６４も含む。一括操作とは、バックエンドデータベース２４内のデータ型の複数のインスタンスに対する、フロントエンドアプリケーションプログラム１２によって指定された操作である。フィルタ操作は、入力キー記述子によって定義されるキーによって、クエリなどの操作の結果をフィルタ処理する。操作記述子７０の入力パラメータはオプションである。

操作記述子７０のタイプは３つある。すなわち、クエリ記述子１０４、アスペクトアクション記述子９２、およびアクション記述子９６である。上記のコマンド、ＱｕｅｒｙおよびＥｘｅｃｕｔｅのアクションは、操作記述子７０によって定義される。

クエリ記述子１０４は、サービスモジュール内のアスペクトのインスタンスについての検索を可能にするクエリメソッドを記述する。クエリ記述子１０４は、入力パラメータ、入力キー記述子６４、および結果アスペクト記述子５６を含む。入力パラメータは、クエリの検索パラメータ構造を定義する構造記述子７４である。入力キー記述子６４は、どのキーをフィルタリングに使用することができるかを定義する。例えば、クエリ記述子１０４によって定義されたクエリをフィルタリングキーで実行すると、第１の入力の基準を満たすキーのリストがもたらされる。キーのこのリストは、キーのリストの一部を戻すことができるように、入力キー記述子６４の１組のフィルタリングキーによってフィルタ処理される。クエリ記述子１０４についての結果アスペクト記述子５６は、クエリの結果のタイプを指定し、サービスモジュールに関連付けられている任意のアスペクト記述子５６とすることができる。

各サービスモジュール記述子５４は、１組のサポートされているクエリ記述子１０４を有する。クエリ記述子１０４は、１つのサービスモジュール記述子５４に属しているため、サービスモジュール記述子５４は、他のサービスモジュール記述子５４で定義されたクエリ記述子１０４を使用することができない。

アスペクトは、アスペクトアクション記述子９２によって記述されているアクションの形で、（標準操作の選択、挿入、更新、削除、関係による選択、フィールドの更新以外の）追加の操作を提供する。アスペクトアクション記述子９２は、アスペクトへの専用の操作記述子７０である。アスペクト記述子５６は、１組のサポートされているアスペクトアクション記述子９２を有することができる。アスペクト記述子５６についての入力パラメータは、アクションのパラメータ構造を定義する。入力キー記述子６４は、一括操作にどのキーを使用することができるかを指定する。例えば、電子メールアクションは、複数の電子メールを表すキーのリストを入力として有し得る。

アクション記述子９６は、Ｐｒｉｎｔ、Ｅｍａｉｌ、Ｆａｘ、Ａｐｐｒｏｖｅ、Ｃｌｅａｒ、Ｃｕｔ、Ｃｏｐｙ、Ｐａｓｔｅ、およびＣａｎｃｅｌなどの複数のアクションの動作を定義することができる。しかし、１つまたは２、３のアスペクトにしか使用できない、よりアスペクト固有のアクションもあり得る。アクション記述子９６は、再利用を実施するために導入される。各アスペクトアクション記述子９２は、名前および意味（テキストの記述）が定義されるアクション記述子９６に関連付けられている。

アクション記述子９６は、名前およびアクションの意味（テキストの記述）を指定する。アクション記述子は、パラメータを指定せず、操作の多様な挙動の記述には使用されない。これらは、分類のために使用することができる。

サービスモジュールグループ記述子５８は、アスペクト記述子５６、関係記述子８４、およびクエリ記述子１０４に関連付けることができる。アスペクトグループ記述子７８は、関係記述子８４、アスペクトアクション記述子９２、およびフィールド記述子８６に関連付けることができる。

アスペクトの複数のインスタンスをサービスモジュールの複数のインスタンスに関連付けることができるため、クラス図５０は、サービスモジュール記述子５４とアスペクト記述子５６との間のゼロ以上−ゼロ以上の関係（a zero or more to zero or more relationship）５２を含む。いくつかのアスペクトを１つのサービスモジュールグループ内にまとめることができるため、サービスモジュールグループ記述子５８は、アスペクト記述子５６へのゼロ以上−ゼロ以上の有向関係（directed relation）６０を有する。いくつかのサービスモジュールグループを１つのサービスモジュール内に集約することができるため、サービスモジュールグループ記述子５８は、サービスモジュール記述子５４とのゼロ以上−１の合成集約関係６２も有する。キー記述子６４は、アスペクト記述子５６の特殊化（specialization）として、アスペクト記述子５６との継承関係６６を有する。各アスペクトは、アスペクトのインスタンスを一意に識別するために、そのアスペクトに関連付けられたキーを有しているため、キー記述子６４は、アスペクト記述子５６との１−ゼロ以上の関係６８も有する。操作は入力キーを含むことができるため、操作記述子７０は、キー記述子６４とのゼロ以上−ゼロ以上の有向関係７２を有する。各アスペクト記述子５６はその属性を定義する構造記述子７４を有することができるため、アスペクト記述子５６は、構造記述子７４とのゼロ以上−１の関係７６を有する。アスペクトはアスペクトグループの集約とすることができるため、アスペクトグループ記述子７８は、アスペクト記述子５６とのゼロ以上−１の合成集約関係８０を有する。アスペクトグループは関係も含むため、アスペクトグループ記述子７８は、関係記述子８４とのゼロ以上−ゼロ以上の有向関係８２も有する。１つの構造は、それ自体を定義するために多くのデータフィールドを使用することができるため、構造記述子７４は、フィールド記述子８６との１−ゼロ以上の所有関係９０を有する。アスペクトグループ記述子７８は、フィールド記述子８６とのゼロ以上−ゼロ以上の関係８８も有する。

アスペクトはアスペクト上で実行することができるアクションを提供することができるため、アスペクトアクション記述子９２は、アスペクト記述子５６とのゼロ以上−１の集約関係１００を有する。アスペクトアクション記述子９２は、その上位クラスの操作記述子７０との継承関係１０２を有する。クエリ記述子１０４も、その上位クラスの操作記述子７０との継承関係１０６を有する。サービスモジュールはゼロ以上のクエリを含むことができるため、サービスモジュール記述子５４は、クエリ記述子１０４との１−ゼロ以上の関係１０８を有する。いくつかのクエリを１つのサービスモジュールグループ内にまとめることができるため、サービスモジュールグループ記述子５８は、クエリ記述子１０４とのゼロ以上−ゼロ以上の有向関係１１０を有する。

各操作は構造の形の入力パラメータを含むため、操作記述子７０は、構造記述子７４とのゼロ以上−ゼロまたは１の関係１１２を有する。クエリは結果として得られたアスペクトを含むため、クエリ記述子１０４は、アスペクト記述子５６とのゼロ以上−ゼロまたは１の関係１１４を有する。関係はソースおよびターゲットのアスペクトを有するため、関係記述子８４は、アスペクト記述５６とのゼロ以上−１の関係１１６および１１８を有する。

リポジトリ１８内のメタデータの編成を定義するこれらの記述子を例示するために、以下の例では、一定の組のリレーショナルデータベーステーブルを使用する。他の永続機構（persistence mechanism）（ＸＭＬなど）を使用することもできる。リレーショナルデータベーステーブルは、テーブル１〜６内で定義されており、テーブル１〜６の各行は、リレーショナルデータベーステーブルのフィールドまたは列を定義する。リポジトリ１８の主なデータ型はアスペクトである。アスペクトを記述するデータベーステーブルは、テーブル１、ＳＣＯＬ＿ＡＳＰＥＣＴ、およびテーブル２、ＳＣＯＬ＿ＡＳＰ＿ＡＣＴＩＯＮである。テーブル１は、アスペクトのプロパティの記述を含む。テーブル１、ＳＣＯＬ＿ＡＳＰＥＣＴのキーフィールドは、ＡＳＰＥＣＴ＿ＮＡＭＥフィールドである。というのは、アスペクトの名前はアスペクトに一意であるからである。ＡＳＰＥＣＴ＿ＣＡＴＥＧＯＲＹフィールドは、アスペクトが非キーアスペクトを表すか、キーアスペクトを表すかを示す。ＳＴＲＵＣＴＵＲＥフィールドは、アスペクトのデータ属性についてのデータ構造名を示す。ＫＥＹ＿ＡＳＰＥＣＴフィールド内にキーの名前を入れることによって、そのキーがアスペクトに関連付けられる。ＳＥＲＶＩＣＥ＿ＰＲＯＶＩＤＥＲフィールドは、アスペクトのアスペクトサービスプロバイダ３４を定義する。ＴＲＡＮＳＡＣ＿ＰＲＯＶＩＤＥＲフィールドは、アスペクトのトランザクションサービスプロバイダ４０を定義する。ＬＯＣＫＩＮＧ＿ＰＲＯＶＩＤＥＲフィールドは、アスペクトのロッキングサービスプロバイダ４２を定義する。また、リポジトリ１８は、アスペクトの記述についての対応するテーブルを有することができる。

アスペクトは、アスペクト上で実行できるアクションを提供することができる。アクションの記述は、テーブル２、ＳＣＯＬ＿ＡＳＰ＿ＡＣＴＩＯＮに格納される。アクションは、アスペクト名およびアクションの名前によって一意に示されるため、ＡＳＰＥＣＴ＿ＮＡＭＥフィールドおよびＡＣＴＩＯＮ＿ＮＡＭＥフィールドは、ＳＣＯＬ＿ＡＳＰ＿ＡＣＴＩＯＮテーブルのキーフィールドである。フィールドＰＡＲＡＭ＿ＳＴＲＵＣＴＵＲＥは、アクションの入力データパラメータを保持するデータ構造を示す。フィールドＩＮＰＵＴ＿ＫＥＹ＿ＡＳＰＥＣＴは、リポジトリ１８内のデータ型のどのインスタンスがアクションによって作用されるかを指定するために使用されるキーのタイプを定義するキーアスペクトの名前を示す。フィールドＰＲＯＶＩＤＥＲ＿ＣＬＡＳＳは、ＡＳＰＥＣＴ＿ＮＡＭＥフィールドで指定されたアスペクトを実装するサービスプロバイダからアクションを提供するアクションサービスプロバイダの名前を示す。

アスペクトは、互いに関連付けることができる。アスペクト間の関係の記述は、テーブル３、ＳＣＯＬ＿ＲＥＬＡＴＩＯＮに格納される。関係は、その名前によって一意に定義されるため、リレーションテーブルのキーは、フィールドＲＥＬＡＴＩＯＮ＿ＮＡＭＥで指定されるリレーション名である。関係ごとに、フィールドＳＯＵＲＣＥ＿ＡＳＰＥＣＴは、有向関係のソースであるアスペクトを定義し、フィールドＴＡＲＧＥＴ＿ＡＳＰＥＣＴは、有向関係のターゲットであるアスペクトを定義し、フィールドＴＡＲＧＥＴ＿ＰＲＯＶＩＤＥＲは、ターゲットアスペクトのクエリ関係サービスプロバイダを定義し、フィールドＲＥＬ＿ＰＡＲＡＭ＿ＴＹＰＥは、関係のタイプ（親−子または子−親）を定義し、フィールドＲＥＬ＿ＰＡＲＡＭＥＴＥＲは、関係の基数（cardinality）を定義する。また、リポジトリ１８は、関係の記述についての対応するテーブルを有することができる。

サービスモジュールのプロパティは、テーブル４、ＳＣＯＬ＿ＳＶＣ＿ＭＯＤＵＬＥに格納される。各サービスモジュールは、その名前によって一意に記述されるため、ＳＶＣ＿ＭＯＤＵＬＥ＿ＮＡＭＥフィールドは、ＳＣＯＬ＿ＳＶＣ＿ＭＯＤＵＬＥテーブルのキーフィールドである。サービスモジュールごとに、フィールドＴＲＡＮＳＡＣ＿ＰＲＯＶＩＤＥＲは、サービスモジュールのトランザクションプロバイダ４０の名前を指定する。また、リポジトリ１８は、サービスモジュールの記述についての対応するテーブルを有する。

すべてのサービスモジュールは、サービスモジュール内で使用できるアスペクトに関連付けられている。各サービスモジュール内で使用できるアスペクトの名前は、テーブル５、ＳＣＯＬ＿ＡＳＰＥＣＴ＿ＵＳＥに格納される。各アスペクト−サービスモジュールの使用は、サービスモジュールの名前およびアスペクトの名前によって一意に記述されるため、フィールドＳＶＣ＿ＭＯＤＵＬＥ＿ＮＡＭＥおよびＡＳＰＥＣＴ＿ＮＡＭＥは、ＳＣＯＬ＿ＡＳＰＥＣＴ＿ＵＳＥテーブルのキーである。

サービスモジュールは、データを取り出すためにクエリを提供することができる。サービスモジュールのクエリの記述は、以下のテーブル６に示したテーブルＳＣＯＬ＿ＱＵＥＲＹに格納される。データベーステーブルの構造は、テーブル６で定義される。各クエリは、サービスモジュールおよびクエリ名によって一意に定義されるため、フィールドＳＶＣ＿ＭＯＤＵＬＥ＿ＮＡＭＥおよびＱＵＥＲＹ＿ＮＡＭＥは、ＳＣＯＬ＿ＱＵＥＲＹテーブルのキーフィールドである。他のフィールドは、クエリによって戻されるデータ型を定義するアスペクトの名前を指定するＲＥＳＵＬＴ＿ＡＳＰＥＣＴ、およびクエリの入力パラメータを含むデータ構造を指定するＰＡＲＡＭ＿ＳＴＲＵＣＴＵＲＥを含む。例えば、サービスモジュールに関連付けられている（例えばフィールドＲＥＳＵＬＴ＿ＡＳＰＥＣＴで指定される）特定のアスペクトに対して行われるクエリは、特定のアスペクトのインスタンスの属性と一致する入力パラメータを含むことができ、一致するインスタンスがこうしたインスタンスを参照するキーのデータセットとして戻される。フィールドＩＮＰＵＴ＿ＫＥＹ＿ＡＳＰＥＣＴは、クエリのフィルタとして使用することができるキーを記述するキーアスペクトを定義するために使用される。ＰＲＯＶＩＤＥＲ＿ＣＬＡＳＳは、各クエリに関連付けられているクエリサービスプロバイダ３２の名前を指定する。また、リポジトリ１８は、クエリの記述についての対応するテーブルを有する。

上述したように、アーキテクチャ３８は、リポジトリサービスプロバイダクラス３０によって扱われるリポジトリ１８へのメタデータの要求以外に、フロントエンドアプリケーションプログラム１２からの要求を扱うための６つのサービスプロバイダクラス（すなわちトランザクション４０、クエリ３２、アスペクト３４、アクション４４、クエリ関係４６、およびロック４２）を含む。フロントエンドアプリケーションプログラム１２によって要求されると、サービスを提供するために、サービスマネージャ１６は、サービスプロバイダクラスのインスタンスを直接呼び出す。サービスプロバイダクラスのこれらのインスタンスは、サービスマネージャ１６と同じコンピュータ（例えば６）、または異なるコンピュータに配置することができる。

ロッキングサービスプロバイダ４２は、単一のアスペクトまたは１組のアスペクトについての汎用のロックマネージャを実施するために使用することができる。各ロッキングサービスプロバイダ４２は、アスペクトに登録する必要がある。ロッキングサービスプロバイダ４２の名前は、アスペクトごとにＳＣＯＬ＿ＡＳＰＥＣＴテーブルのＬＯＣＫＩＮＧ＿ＰＲＯＶＩＤＥＲフィールドで設定される。ロッキングサービスプロバイダクラスは、サービスマネージャ１６によって呼び出すことができる２つのメソッドを有する。これらは、ＬＯＣＫおよびＵＮＬＯＣＫである。ＬＯＣＫは、入力として、ロックすべきビジネスオブジェクトを表すキーのコレクション、ビジネスオブジェクトのクラスを表すアスペクトの名前、およびロックモードを取得する。ターゲットシステムのロッキング機能に応じて、様々なロックモードがある。ロックモードは、「Ｅ」、「Ｓ」、または「ＳＰ」を指定することができる。「Ｅ」は、排他的ロック、すなわち１つのクライアントのみがロックを得ることができることを意味する。「Ｓ」は、任意のクライアントがロックすることができ、１つのクライアントに専用のロックはできないことを示す共有ロックを意味する。「ＳＰ」は、「Ｓ」と同じであるが、排他的ロックへのその後のアップグレードが可能であることを意味する。

ＬＯＣＫメソッドは、要求が拒否されたかどうかを示すブール値を出力し、また戻りコードも出力する。ＵＮＬＯＣＫは、ロック解除すべきビジネスオブジェクトを表すキーのコレクション、およびロック解除すべきビジネスオブジェクトのクラスを表すアスペクトの名前を入力として取得する。ＵＮＬＯＣＫメソッドも、要求が拒否されたかどうかを示すブール値および戻りコードを出力する。トランザクションバッファがすでに「ダーティ」な状態にある場合、すなわち、最後のＣＬＥＡＮＵＰ呼び出し以降、任意の更新、挿入、削除操作、またはＣＯＬ＿ＡＦＦＥＣＴＳ＿ＮＯＴＨＩＮＧとしてマークされていないアクションが発行された場合、ＵＮＬＯＣＫへの呼び出しは拒否される。トランザクションサービスプロバイダクラスのＣＬＥＡＮＵＰメソッド（後述する）が「ＥＮＤ」の理由で呼び出される場合、すべてのロックが削除される。

トランザクションとは、情報交換および関連の作業（データベースの更新など）のシーケンスであり、フロントエンドアプリケーションプログラム１２からサービスマネージャ１６への要求を満たすため、またバックエンドデータベース２４の保全性を確実にするための一単位として扱われる。トランザクションを終了させ、データベース２４への変更を永続的にするために、トランザクションを全部完了させる必要がある。トランザクションが成功し、データベースが要求された変更のすべてを反映するように実際に変更される前に、トランザクションのすべてのステップが終了される。トランザクションが正常に終了する前に何か起こった場合、変更を元に戻すことができるように、バックエンドデータベース２４への任意の変更を追跡する必要がある。

トランザクションを扱うために、トランザクションサービスプロバイダ４０は、サービスマネージャ１６、別の非トランザクションサービスプロバイダ（３２、３４、４４、４６など）、およびフロントエンドアプリケーションプログラム１２（または場合によってはサービスマネージャプロキシ１４）の間のトランザクションの様々な状態に関する通知を受信する。この通知は、トランザクション中にサービスマネージャ１６によって呼び出される、トランザクションサービスプロバイダ４０のメソッドＢＥＦＯＲＥ＿ＳＡＶＥ、ＣＬＥＡＮＵＰ、およびＳＡＶＥである。

サービスマネージャ１６は、トランザクションバッファを保存することができるかどうかをチェックするために、トランザクションサービスプロバイダ４０のメソッドＢＥＦＯＲＥ＿ＳＡＶＥを呼び出す。これによって、非トランザクションサービスプロバイダの内部状態が保存の準備ができているかどうかをチェックすることができる。メソッドＢＥＦＯＲＥ＿ＳＡＶＥは、トランザクションバッファを保存することができない場合、ｆａｌｓｅを戻し、トランザクションの終了が中断される。したがって、ＢＥＦＯＲＥ＿ＳＡＶＥメソッドは、ＢＯＯＬＥＡＮ戻りパラメータを有する。ＢＥＦＯＲＥ＿ＳＡＶＥは、ブール値を入力パラメータＲＥＪＥＣＴＥＤとして取得する。トランザクションサービスプロバイダ１６は、ＲＥＪＥＣＴパラメータを非初期値、すなわち「ｔｒｕｅ」に設定することによって、次の保存操作およびコミット操作を防ぐことができる。メソッドＢＥＦＯＲＥ＿ＳＡＶＥは、フロントエンドアプリケーション１２のＳＡＶＥメソッドによってトリガされるサービスマネージャ１６の操作のシーケンス内に呼び出される。

ＳＡＶＥメソッドは、最終的にアプリケーションをトリガして、トランザクションバッファをデータベース２４に保存させる。ＳＡＶＥを呼び出すことによって、非トランザクションサービスプロバイダのすべての内部状態を、直接の更新、または更新タスクへの適切な呼び出しの作成のいずれかによって永続的にする。アーキテクチャ３８内のすべてのサービスプロバイダがＳＡＶＥ要求を受信した場合、サービスマネージャ１６は、トランザクションをコミットする。

ＣＬＥＡＮＵＰメソッドは、すべての非トランザクションサービスプロバイダに、すべてのトランザクションバッファ、およびエンキューベースのロックを解放するよう伝える。ＣＬＥＡＮＵＰメソッドの呼び出しは、アーキテクチャ３８内のすべてのサービスプロバイダがその内部状態をクリーンアップする必要があることを伝える。ＣＬＥＡＮＵＰは、ＲＥＡＳＯＮ文字列を入力パラメータとして取得する。ＲＥＡＳＯＮフィールドは、クリーンアップ操作の理由を示す。これは、ＳＡＶＥ操作のための「ＣＯＭＭＩＴ」、またはシステムがトランザクションを自動的に終了することによるトランザクションの「ＥＮＤ」のいずれかであり得る。障害状態下でＣＬＥＡＮＵＰが呼び出される保証はない。

アクションサービスプロバイダ４４は、アスペクトのアクションを実行するために、サービスマネージャ１６によって呼び出される。アクションサービスプロバイダ４４の名前は、ＳＣＯＬ＿ＡＳＰ＿ＡＣＴＩＯＮテーブルのＰＲＯＶＩＤＥＲ＿ＣＬＡＳＳフィールドのアクションに対応する行に設定される。アクションサービスプロバイダ４４は、１つのメソッドＥＸＥＣＵＴＥを有する。ＥＸＥＣＵＴＥメソッドは、アスペクト名（ＡＳＰＥＣＴ）、アスペクトのどのインスタンスがアクションによって作用されるかを指定する１組のキー（ＩＮＫＥＹＳ）、汎用入力パラメータ（ＩＮＰＡＲＡＭ）、実行すべきアクションの名前（ＡＣＴＩＯＮ）、関係に作用するアクションの１組のキー（ＲＥＬＡＴＩＯＮ＿ＩＮＫＥＹ）、および関係の名前（ＲＥＬＡＴＩＯＮ）を入力パラメータとして取得する。ＥＸＥＣＵＴＥメソッドは、アクションによって修正された、変更済みのまたは新しく作成されたオブジェクト（ＯＵＴＲＥＣＯＲＤＳ）を出力パラメータとして戻す。ＯＵＴＲＥＣＯＲＤＳパラメータによって戻されたオブジェクトは、アプリケーションプログラム１２に移送される。

アスペクトサービスプロバイダ３４は、サービスマネージャ１６によって呼び出され、１つまたは複数のアスペクトの内容を読み取り、変更するための機能を提供する。上述したように、アスペクトは、その名前（名前はリポジトリ内でグローバルに一意である）、関連のデータ構造、関連のキー（すなわち識別子）構造、１組の実施されたアクション、１組の外向きの関係（outgoing relation）、および１組の内向きの関係（incoming relation）によって記述される。アスペクトサービスプロバイダ３４は、メソッドＥＸＥＣＵＴＥ、ＳＥＬＥＣＴ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＳＥＬＥＣＴ＿ＢＹ＿ＲＥＬＡＴＩＯＮ、およびＵＰＤＡＴＥ＿ＦＩＥＬＤＳを有する。

メソッドＥＸＥＣＵＴＥは、アクションサービスプロバイダ４４から導出され、アクションの実行を可能にする。ＥＸＥＣＵＴＥは、アクションが実行されるアスペクトの名前（ＡＳＰＥＣＴ）、アクションが実行されるオブジェクトのキー（ＩＮＫＥＹＳ）、アクションのパラメータ（ＩＮＰＡＲＡＭ）、アクションの名前（ＡＣＴＩＯＮ）を入力パラメータとして有する。戻されたパラメータは、変更された、または作成されたアスペクト行（ＯＵＴＲＥＣＯＲＤＳ）、メソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

メソッドＳＥＬＥＣＴは、所与のアスペクトについて、入力キーに関連付けられているアスペクトデータを読み取る。ＳＥＬＥＣＴは、読み取るアスペクト行を記述するために関連のキー構造内でエンコードされたキーのリスト（ＩＮＫＥＹ）、およびアスペクトの名前（ＡＳＰＥＣＴ）を入力パラメータとして有する。ＳＥＬＥＣＴは、アスペクトデータ構造でエンコードされた結果（ＯＵＴＲＥＣＯＲＤＳ）、メソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を出力パラメータとして有する。

メソッドＩＮＳＥＲＴは、新しいデータをアスペクトに挿入する。アスペクトが行ごとの書き込み操作（ＩＮＲＥＣＯＲＤＳ）用に設計されている場合、ＩＮＳＥＲＴは、挿入すべきレコードを含むテーブルを入力パラメータとして含んでいる。このメソッドによって、アスペクトの記述に応じて（例えばパラメータＥｘｔｅｒｎａｌＫｅｙｓ＝ｔｒｕｅまたはｆａｌｓｅ）、挿入されたレコードは、キーフィールドを定義することもできる。入力パラメータは、アスペクトの名前（ＡＳＰＥＣＴ）、関係に作用するアクションの１組のキー（ＲＥＬＡＴＩＯＮ＿ＩＮＫＥＹ）、および関係の名前（ＲＥＬＡＴＩＯＮ）も含む。メソッドＩＮＳＥＲＴは、挿入されたレコードを表す１組のレコード（ＯＵＴＲＥＣＯＲＤＳ）を、そのキー、およびアスペクトサービスプロバイダ３４が挿入されたレコードにおいて行いたい他の可能な変更とともに戻す。例えば、変更の１つとして、その１組のレコードの算出されたフィールドを記入することが可能である。ＯＵＴＲＥＣＯＲＤＳ行の順序は、ＩＮＲＥＣＯＲＤＳ行の順序に対応していなければならない。他の出力パラメータは、ＳＥＬＥＣＴメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

ＵＰＤＡＴＥメソッドは、レコードごとまたはフィールドごとにアスペクトの既存のインスタンスを更新する。アスペクトが行ごとの書き込み操作用に設計されている場合、ＵＰＤＡＴＥメソッドの入力パラメータは、更新すべきインスタンスキーを含むテーブル（ＩＮＲＥＣＯＲＤＳ）を含む。入力パラメータは、アスペクトの名前（ＡＳＰＥＣＴ）も含む。ＵＰＤＡＴＥメソッドによって戻されたパラメータは、更新されたレコード（ＯＵＴＲＥＣＯＲＤＳ）を、そのキー、およびサービスプロバイダが行いたい他の可能な変更とともに含む。ＯＵＴＲＥＣＯＲＤＳ行の順序は、ＩＮＲＥＣＯＲＤＳ行の順序に対応させることができる。他の出力パラメータは、ＳＥＬＥＣＴメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

ＤＥＬＥＴＥメソッドは、（バックエンドデータベース２４など）バックエンド内のアスペクトの行またはインスタンスを削除する。ＤＥＬＥＴＥメソッドの入力パラメータは、削除すべきアスペクト行を記述するために関連のキー構造内でエンコードされたキーのリスト（ＩＮＫＥＹ）、およびアスペクトの名前（ＡＳＰＥＣＴ）である。ＤＥＬＥＴＥメソッドによって戻されたパラメータは、ＤＥＬＥＴＥメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

ＳＥＬＥＣＴ＿ＢＹ＿ＲＥＬＡＴＩＯＮメソッドは、関係のパラメータの記述に応じて、関係に従うか、または別のアスペクトに従うか、いずれかの属性を戻し、このソースアスペクトは、その別のアスペクトを指す関係を有する。ＳＥＬＥＣＴ＿ＢＹ＿ＲＥＬＡＴＩＯＮの入力パラメータは、従うべき関係の名前（ＲＥＬＡＴＩＯＮ）、ソースアスペクトのレコード（ＩＮＲＥＣＯＲＤＳ）、ソースアスペクトの名前（ＡＳＰＥＣＴ）、およびページングなどのクエリの様々なオプションを記述する構造（ＯＰＴＩＯＮＳ）である。ＳＥＬＥＣＴ＿ＢＹ＿ＲＥＬＡＴＩＯＮによって戻された出力パラメータは、ターゲットアスペクトデータ構造（ＯＵＴＲＥＣＯＲＤＳ）でエンコードされた結果、ＯＵＴＲＥＣＯＲＤＳパラメータのどの行がどのＩＮＲＥＣＯＲＤＳ行（ＩＮＤＥＸ）に属しているかを示すインデックステーブル、結果の記述（ＤＥＳＣＲＩＰＴＩＯＮ）、ＳＥＬＥＣＴ＿ＢＹ＿ＲＥＬＡＴＩＯＮメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

ＵＰＤＡＴＥ＿ＦＩＥＬＤＳメソッドは、アスペクトのインスタンスのフィールドを更新する。入力パラメータは、更新すべきアスペクトのインスタンスを記述するために関連のキー構造内でエンコードされたキーのリスト（ＩＮＲＥＣＯＲＤＳ）を含む。アスペクトが、フィールドごとの書き込み操作用に設計されている場合、入力パラメータは、１組のレコード内の更新すべきフィールドの名前および対応する値の対を含むテーブル（ＩＮＦＩＥＬＤＳ）も含む。アスペクトの複数のインスタンスを更新すべきである場合、追加のフィールドインデックスＩＮＫＥＹは、関連のキーレコードを指す。入力パラメータは、アスペクトの名前（ＡＳＰＥＣＴ）も含む。ＵＰＤＡＴＥ＿ＦＩＥＬＤＳによって戻されたパラメータは、アスペクトの作成されたまたは変更されたインスタンス（ＯＵＴＲＥＣＯＲＤＳ）を、そのキー、およびアスペクトサービスプロバイダ３４によって実行された他の可能な変更とともに含む。様々なＯＵＴＲＥＣＯＲＤＳ行のインデックスは、ＩＮＦＩＥＬＤＳテーブル内の行インデックスに関連付けられる必要がある。戻された他のパラメータは、ＵＰＤＡＴＥ＿ＦＩＥＬＤＳメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

クエリサービスプロバイダ３２は、クエリを実行する。リポジトリ１８内のクエリは、テーブルＳＣＯＬ＿ＱＵＥＲＹにおいて、フィールドＱＵＥＲＹ＿ＮＡＭＥのクエリ名、フィールドＰＡＲＡＭ＿ＳＴＲＵＣＴＵＲＥの関連のパラメータ構造、フィールドＲＥＳＵＬＴ＿ＡＳＰＥＣＴの関連の結果アスペクト、およびオプションで、フィールドＩＮＰＵＴ＿ＫＥＹ＿ＡＳＰＥＣＴのその一意のデータ構造を備える関連のアスペクトキーによって記述されている。クエリサービスプロバイダ３２は、１つまたは複数のアスペクトに対するクエリを実行する１つのＥＸＥＣＵＴＥメソッドを有する。入力パラメータは、クエリの名前（ＱＵＥＲＹ）、クエリのパラメータを含むデータ構造（ＩＮＰＡＲＡＭ）、およびクエリを制限すべきアスペクト行のキーを含むオプションのテーブル型パラメータ（ＩＮＫＥＹＳ）を含む。ＩＮＫＥＹＳは、ＥＸＥＣＵＴＥメソッドによって戻されるＯＵＴＲＥＣＯＲＤＳのキーで構成することはできるが、必須ではない。ＩＮＫＥＹＳは、任意のキーアスペクト構造のものとすることができる。どのキー構造がクエリに関連付けられるかは、リポジトリ１８内のテーブルＳＣＯＬ＿ＱＵＥＲＹ内のフィールドＩＮＰＵＴ＿ＫＥＹ＿ＡＳＰＥＣＴで指定される。オプションで、（ページングのためなど）クエリの様々なオプション（ＯＰＴＩＯＮＳ）およびＳＥＬＥＣＴＩＯＮＳを記述する構造を含めて、他の入力パラメータを指定することができる。

ＥＸＥＣＵＴＥメソッドによって戻されたパラメータは、クエリの記述（ＤＥＳＣＲＩＰＴＩＯＮ）、クエリ結果（ＯＵＴＲＥＣＯＲＤＳ）、およびＥＸＥＣＵＴＥメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）を含む。

ＥＸＥＣＵＴＥメソッドは、クエリパラメータによって指定された結果を戻す。ＩＮＫＥＹＳテーブルパラメータが空ではない場合、結果は、クエリパラメータを満たすオブジェクトに制限される。ＩＮＫＥＹＳおよびＩＮＰＡＲＡＭは、いずれもクエリを制限するが、様々な方法で使用される。例えば、まだ配送されていない注文のリストを戻すクエリを定義することができる。こうした例では、構造ＩＮＰＡＲＡＭは、Ａ〜Ｄの姓の付いた顧客からの注文のみを戻すように指定することができる。ＩＮＫＥＹＳは、まだ配送されていないすべての注文のテーブルである。ＯＵＴＲＥＣＯＲＤＳは、まだ配送されていない、この場合Ａ〜Ｄの姓を持つ関連の顧客からのすべての注文を含む。一例では、クエリのＯＵＴＲＥＣＯＲＤＳ結果は、切断された（disconnected）アスペクトであり、すなわちアスペクトは常に読み取り専用である。このアスペクトに対してそれ以上のバックエンド操作を実行することはできない。この例では、受信されたキーは、アスペクトサービスプロバイダ３４、および例えばそのＳＥＬＥＣＴメソッドを使用して、他のアスペクト行を選択するためのパラメータとして使用することができる。

クエリ関係サービスプロバイダ４６は、関係のターゲットであるアスペクトのサービスプロバイダ（アスペクトサービスプロバイダ３４など）においてルーチンを実施する。関係がＳＯＵＲＣＥ＿ＫＥＹＳまたはＡＴＴＲＩＢＵＴＥＳとマーク付けされている場合、クエリ関係サービスプロバイダ４６のメソッドは、ソースアスペクトのアスペクトサービスプロバイダ３４から間接的に呼び出される。

クエリ関係サービスプロバイダ４６は、ＳＥＬＥＣＴ＿ＴＡＲＧＥＴメソッドを有する。メソッドＳＥＬＥＣＴ＿ＴＡＲＧＥＴは、次のように入力パラメータを有する。入力パラメータは、ソースアスペクトの名前（ＳＯＵＲＣＥ＿ＡＳＰＥＣＴ）を含む。オプションで、メソッドは、ターゲットアスペクトのＳＥＬＥＣＴメソッドへのプロキシインターフェイス（ＴＡＲＧＥＴ）を定義する入力パラメータも含む。ＴＡＲＧＥＴパラメータを指定することによって、ターゲットアスペクトのアスペクトサービスプロバイダ３４を直接知ることなく、ターゲットアスペクトのアスペクトサービスプロバイダ３４のＳＥＬＥＣＴメソッドを呼び出すことができる。これによって、ターゲットアスペクトのアスペクトサービスプロバイダ３４の知識無しに、クエリ関係サービスプロバイダ４６をサービスモジュールに追加することができる。

ＳＥＬＥＣＴ＿ＴＡＲＧＥＴメソッドの別の入力パラメータは、関係（ＲＥＬＡＴＩＯＮ）である。別の入力パラメータは、関係を記述するためのフィールドのテーブル（ＩＮＰＡＲＡＭＳ）である。一括選択を可能にするために、ＩＮＰＡＲＡＭＳは、すべての行が単一の選択を記述するテーブルである。ＩＮＤＥＸパラメータは、ＩＮＰＡＲＡＭＳ構造の様々な行をＯＵＴＲＥＣＯＲＤＳ行に関連付けるために使用される。別のオプションの入力パラメータは、（ページングなど）クエリの様々なオプションを記述する構造（ＯＰＴＩＯＮＳ）である。

ＳＥＬＥＣＴ＿ＴＡＲＧＥＴメソッドは、ターゲットアスペクトの構造（ＯＵＴＲＥＣＯＲＤＳ）でエンコードされた結果、クエリ結果の記述（ＤＥＳＣＲＩＰＴＩＯＮ）、およびターゲットアスペクトＳＥＬＥＣＴメソッドへのプロキシインターフェイスを含む、パラメータを戻す。他の出力パラメータは、ＩＮＰＡＲＡＭＳレコードとＯＵＴＲＥＣＯＲＤＳパラメータとの間の関係を記述するインデックス（ＩＮＤＥＸ）、ＳＥＬＥＣＴ＿ＴＡＲＧＥＴメソッドの要求が拒否されたかどうかを示すブールフラグ（ＲＥＪＥＣＴＥＤ）、および戻りコード（ＲＥＴＵＲＮ＿ＣＯＤＥＳ）を含む。

サービスプロバイダ３２、３４、４０、４２、４４、および４６は、上述したように、アーキテクチャ３８の次のトランザクションモデルを実行可能にする。アスペクトサービスプロバイダ３４のメソッドＳＥＬＥＣＴを実行することによって、バックエンドデータベース２４から読み取る、またはバックエンドに格納されているトランザクションバッファから読み取る。アスペクトサービスプロバイダ３４は、マージデータがこのトランザクションにおいてそれまでに行われた更新を反映するように、一貫した方法で、両方のソース、つまりデータベースおよびそのトランザクションバッファからのデータをマージする。次に、アスペクトサービスプロバイダ３４のＵＰＤＡＴＥ、ＩＮＳＥＲＴ、ＭＯＤＩＦＹ、ＤＥＬＥＴＥのメソッドを実行することによって、トランザクションバッファが増加する。トランザクションバッファ内のデータを実際に変更する前に、サービスマネージャ１６は、データに対するトランザクションロックを取得し、ロックの保護下でデータを読み取る必要がある。上述したように、ロッキングサービスプロバイダ４２を使用して利用可能な排他的、共有、および共有プロモート可能（shared promotable）のロックモードがある。ロックには、ロックの保護下で、ロックされたデータを再度選択することが伴わなければならない。アプリケーションは、タイムスタンプが押されたデータ、またはそうでなければバージョン付きのデータを提供し、競合の場合にフロントエンドにおいて実際のデータと変更されたデータとをマージすることによって、楽観的ロックキング（optimistic locking）をサポートすることができる。

トランザクションサービスプロバイダ４０のＢＥＦＯＲＥ＿ＳＡＶＥメソッドによって、参加しているすべてのサービスプロバイダがトランザクションバッファを保存する用意ができているかどうかを宣言することができる。トランザクションサービスプロバイダ４０のＳＡＶＥメソッドは、最終的に、サービスマネージャ１６をトリガして、トランザクションバッファをバックエンドデータベース２４に保存させる。

トランザクションサービスプロバイダ４０のＣＬＥＡＮＵＰメソッドは、すべてのそのトランザクションバッファおよびエンキューベースのロックを解放することを、すべてのサービスプロバイダ（アスペクトサービスプロバイダ３４など）に通知する。ＣＬＥＡＮＵＰが「ＥＮＤ」の理由で呼び出された場合、すべてのロックは解放されなければならない。理由が「ＣＯＭＭＩＴ」に設定されている場合、各サービスプロバイダは、そのロックを維持することを選択することができる。アスペクトサービスプロバイダ３４は、ＣＯＭＭＩＴ ＷＯＲＫまたはＲＯＬＬＢＡＣＫ ＷＯＲＫをそれ自体で内部で呼び出してはならない。サービスマネージャ１６は、アスペクトサービスプロバイダ３４がトランザクションをコミットしようとしている場合、トランザクションを自動的に中断することによってこれを実施する。

サポートされているロッキングモデルおよびロックポリシーは、次の通りである。ポリシーＳを使用すると、多くの参加者が共有ロックを取得することができる。あるオブジェクトにおいて共有ロックが取得されると、非排他的ロックまたはＳＰロックを取得することができる。共有ロックは、読み取り操作中により大きいデータセットにおける一貫したビューを達成するために使用することができるだけである。ポリシーＥを使用すると、単一の参加者だけがロックを取得することができる。ポリシーＳＰ（共有プロモート可能）を使用すると、多くの参加者がロックを取得することができる。ＳＰロックが存在している場合、排他的ロックは、そのオブジェクトにすでにＳＰロックを有している参加者によって取得されるだけである。参加者のうちの１人だけが、ロックを排他的ロックにアップグレードすることができる。アップグレード前にロックを取得した他の参加者は、第１の参加者がそのロックを解放した場合でさえ、排他的にアップグレードすることはできない。

（図３の）アーキテクチャ３８は、新しい顧客を作成し、ＧＵＩ２８を介して１つまたは複数の製品の顧客の注文を受信し、その注文をビジネスプロセスに送信する簡単なタスクを実施する。この実施例をサポートするために、バックエンドデータベース２４は、顧客のリスト、住所、製品タイプ、バスケット、注文ごとのバスケット内の製品の位置（positions）、および注文を定義するために、上記のテーブル１〜６の定義に従って設計されたリレーショナルデータベースを使用して実施することができる。テーブル７〜１２では、キーフィールドの見出しをアスタリスクで示している。顧客テーブル７は、顧客を定義し、各顧客は、ＣｕｓｔｏｍｅｒＩｄフィールドによって一意に識別される。顧客テーブル７は、名前フィールド、および住所テーブル内の住所を顧客にリンクする外部キーフィールドＡｄｄｒｅｓｓＩｄも含んでいる。

住所テーブル８は、町および通りを有する住所を定義する。Ａｄｄｒｅｓｓ ｉｄ自体は、住所の有効な一意のキーであり、住所と顧客との間の接続は、顧客テーブル７（ＡｄｄｒｅｓｓＩＤフィールド）を介して行われる。

テーブル９は、製品を定義し、名前を有し、キーＰｒｏｄｕｃｔＩｄを備える。

テーブル１０は、ショッピングバスケットを定義し、顧客を有し、キーＢａｓｋｅｔＩｄを備える。

テーブル１１は、バスケット内の注文の位置を定義し、製品を有する。位置は、バスケットおよび注文の存在に依存するため、位置の主キーは、ＰｏｓｉｔｉｏｎＩｄ、ＢａｓｋｅｔＩｄ、およびＯｒｄｅｒＩｄの組み合わせである。

テーブル１２は、注文を定義し、顧客を有し、各注文が送信済みかどうかを示し、主キーＯｒｄｅｒＩｄを備える。

図５に示すように、プロセス１５０は、テーブル７〜１２を使用して、この簡単なタスクに必要なバックエンドデータベース２４へのデータベース操作を定義する。プロセス１５０は、フロントエンドアプリケーションプログラム１２が顧客の名前を受信すること（１５２）を含む。プロセス１５０は、ビジネスソフトウェアアプリケーションが、データベースの顧客テーブル（テーブル７）に対してＮＡＭＥフィールドの名前についてのクエリを行うこと（１５４）を含む。プロセス１５０は、顧客の名前が顧客テーブル（テーブル７）のある行に一致するかどうかをチェックすること（１５６）を含む。一致しない場合、プロセス１５０は、ビジネスソフトウェアアプリケーションが、顧客の住所を取得すること（１５８）、新しいＡｄｄｒｅｓｓＩＤおよび住所についての新しい行を住所テーブル（テーブル８）に挿入すること（１６０）、および新しいＣｕｓｔｏｍｅｒＩｄおよびＡｄｄｒｅｓｓＩＤについての新しい行を顧客テーブル（テーブル７）に挿入すること（１６２）を含む。一致する場合、プロセス１５０は、ビジネスソフトウェアが、その顧客の注文する製品名を取得すること（１６４）を含む。プロセス１５０は、ビジネスソフトウェアが製品テーブル（テーブル９）に対して製品名についてのクエリを行うこと（１６６）を含む。

プロセス１５０は、製品名が製品テーブル（テーブル９）のある行に一致するかどうかをチェックすること（１６８）を含む。一致する場合、プロセス１５０は、ビジネスソフトウェアが、顧客のＣｕｓｔｏｍｅｒＩｄについての新しい注文を注文テーブル（テーブル１２）に挿入すること（１７０）、および送信済みフィールドを「Ｆａｌｓｅ」に設定することを含む。そうでない場合、プロセス１５０は、注文する製品名を取得すること（１６４）に戻る。プロセス１５０は、ビジネスソフトウェアが、顧客のＣｕｓｔｏｍｅｒＩｄについての新しいバスケットをバスケットテーブル（テーブル１０）に挿入すること（１７２）を含む。

プロセス１５０は、ビジネスソフトウェアが、ＣｕｓｔｏｍｅｒＩｄ、ＢａｓｋｅｔＩｄ、およびＰｒｏｄｕｃｔＩｄについての新しい位置を位置テーブル（テーブル１１）に挿入すること（１７４）を含む。プロセス１５０は、ビジネスソフトウェアが注文を送信する旨の要求を受信すること（１７６）を含む。プロセス１５０は、ビジネスソフトウェアが、注文テーブル（テーブル１２）に対して顧客のＣｕｓｔｏｍｅｒＩｄでクエリを行うこと（１７８）を含み、このクエリは、顧客のＣｕｓｔｏｍｅｒＩｄに一致する注文を戻す。プロセス１５０は、ビジネスソフトウェアが、注文テーブル（テーブル１２）内で、顧客のＣｕｓｔｏｍｅｒＩｄについての注文に一致する注文を選択すること（１８０）を含む。プロセス１５０は、ビジネスソフトウェアが、注文テーブル（テーブル１２）内の選択された行の送信済みフィールドを「Ｔｒｕｅ」に設定すること（１８２）を含む。プロセス１５０は、ビジネスソフトウェアが、顧客テーブル７に対してＡｄｄｒｅｓｓＩｄについてのクエリを行い、次いで住所テーブル８に対して一致したＡｄｄｒｅｓｓＩｄについてのクエリを行うことによって、注文の配送のために、住所テーブル８から顧客の住所を取得すること（１８４）を含む。

テーブル１３〜１９は、テーブル７〜１２によって示したデータベース例のメタデータを表すリポジトリ１８の一実装形態でのテーブルを示している。テーブル１３〜１９は、上記のテーブル１〜６の定義に従い、テーブル１〜６の行の定義がテーブル１３〜１９の列またはフィールドに対応する。テーブル７〜１２と同様、テーブル１３〜１９のキーフィールドは、アスタリスクによってラベル付けされている。

テーブル１３は、（テーブル１で定義した）ＳＣＯＬ＿ＡＳＰＥＣＴテーブルの定義に従ってアスペクトＡ＿Ｃｕｓｔｏｍｅｒ、Ａ＿Ａｄｄｒｅｓｓ、Ａ＿Ｐｒｏｄｕｃｔ、Ａ＿Ｂａｓｋｅｔ、Ａ＿Ｐｏｓｉｔｉｏｎ、およびＡ＿ＯｒｄｅｒＨｅａｄｅｒを定義する。各アスペクトは、各インスタンスに一意のキーを定義する対応するキーアスペクトを有する。例えば、アスペクトＡ＿Ｃｕｓｔｏｍｅｒは、キーアスペクトＣｕｓｔｏｍｅｒ＿Ｋｅｙを有する。メタデータリポジトリ１８内のこのキーアスペクトは、バックエンドデータベース２４内のリレーショナルデータベーステーブルのキーに対応することができる。例えば、顧客テーブル（テーブル７）のキーは、ＣｕｓｔｏｍｅｒＩｄフィールドである。ＳＴＲＵＣＴＵＲＥフィールド内の行は、下記のテーブル１９のデータ辞書に対応する。例えば、テーブル１９は、文字列を示すタイプＣＨＡＲのＮＡＭＥフィールドを有するようにＣｕｓｔｏｍｅｒ＿Ｓｔｒｕｃｔｕｒｅを定義することができる。ＳＥＲＶＩＣＥ＿ＰＲＯＶＩＤＥＲフィールドの行は、アスペクトのサービスを扱う特定のアスペクトサービスプロバイダに対応する。テーブル１３において、アスペクトのすべては、Ｓ＿ｐｒｏｖｉｄｅｒアスペクトサービスプロバイダ（例えば図３を参照すると３４）に割り当てられる。ＴＲＡＮＳＡＣ＿ＰＲＯＶＩＤＥＲフィールドの行は、アスペクトのトランザクションを扱う特定のトランザクションサービスプロバイダ４０に対応する。テーブル１３において、アスペクトのすべては、Ｔ＿ｐｒｏｖｉｄｅｒトランザクションサービスプロバイダ（例えば図３を参照すると４０）に割り当てられる。ＬＯＣＫＩＮＧ＿ＰＲＯＶＩＤＥＲフィールドの行は、アスペクトのロックを扱う特定のロッキングサービスプロバイダに対応する。テーブル１３において、アスペクトのすべては、Ｌ＿ｐｒｏｖｉｄｅｒロックサービスプロバイダ（例えば図３を参照すると４２）に割り当てられる。

テーブル１４は、（テーブル２で定義した）ＳＣＯＬ＿ＡＳＰ＿ＡＳＰＥＣＴテーブルの定義に従ってアスペクトＡ＿ＯｒｄｅｒＨｅａｄｅｒのアクションＳｕｂｍｉｔを定義する。フィールドＩＮＰＵＴ＿ＫＥＹ＿ＡＳＰＥＣＴは、アスペクトＡ＿ＯｒｄｅｒＨｅａｄｅｒのどのインスタンスがそのアクションによって作用されるべきかを指定するアクションで、アプリケーション１４によって送信されるキーアスペクトを指定する。アクションＳｕｂｍｉｔは、バックエンドデータベース２４内のこうしたインスタンスの送信済みフィールドをＴｒｕｅに変更する。このアクションＳｕｂｍｉｔに追加のパラメータは必要ないため、テーブル１４のＰＡＲＡＭ＿ＳＴＲＵＣＴＵＲＥフィールドは空欄である。フィールドＰＲＯＶＩＤＥＲ＿ＣＬＡＳＳは、各アクションに割り当てられるアスペクトサービスプロバイダ３４（図３を参照）を指定する。テーブル１４において、アクションＳｕｂｍｉｔは、アスペクトサービスプロバイダＳ＿ｐｒｏｖｉｄｅｒ（例えば図３を参照すると３４）に割り当てられる。

テーブル１５は、（テーブル３で定義した）ＳＣＯＬ＿ＲＥＬＡＴＩＯＮテーブルの定義に従って、テーブル１３で定義されたアスペクト間の関係を定義する。この関係は、テーブル７〜１２の例によって示されるバックエンドデータベース２４のデータテーブル間の関係を反映する。図６には、アスペクトＡ＿Ｃｕｓｔｏｍｅｒ２０２、アスペクトＡ＿Ａｄｄｒｅｓｓ２０４、アスペクトＡ＿Ｐｒｏｄｕｃｔ２０６、アスペクトＡ＿Ｂａｓｋｅｔ２０８、アスペクトＡ＿Ｐｏｓｉｔｉｏｎ２１０、およびアスペクトＡ＿ＯｒｄｅｒＨｅａｄｅｒ２１２のアスペクト間の関係についても示されている。これらの関係は、Ｒ＿Ｃｕｓｔｏｍｅｒ＿Ｔｏ＿Ａｄｄｒｅｓｓ２１３、Ｒ＿Ｂａｓｋｅｔ＿Ｔｏ＿Ｃｕｓｔｏｍｅｒ２１４、Ｒ＿ＯｒｄｅｒＨｅａｄｅｒ＿Ｔｏ＿Ｃｕｓｔｏｍｅｒ２１６、Ｒ＿Ｐｏｓｉｔｉｏｎ＿Ｔｏ＿Ｐｒｏｄｕｃｔ２１８、Ｒ＿Ｐｏｓｉｔｉｏｎ＿Ｔｏ＿ＯｒｄｅｒＨｅａｄｅｒ２２０、およびＲ＿Ｐｏｓｉｔｉｏｎ＿Ｔｏ＿Ｂａｓｋｅｔ２２２を含む。

テーブル１６は、（テーブル４で定義した）ＳＣＯＬ＿ＳＶＣ＿ＭＯＤＵＬＥテーブルの定義に従って、テーブル７〜１２において提供されたバックエンドデータベース２４の定義例のサービスモジュール例を定義する。テーブル１６は、サービスモジュールＳ＿Ｃｕｓｔｏｍｅｒ、Ｓ＿Ｐｒｏｄｕｃｔ、Ｓ＿Ｂａｓｋｅｔ、およびＳ＿Ｏｒｄｅｒを定義する。フィールドＴＲＡＮＳＡＣ＿ＰＲＯＶＩＤＥＲは、各サービスモジュールに対するトランザクションサービスプロバイダ４０（図３を参照）を指定する。テーブル１６において、トランザクションサービスプロバイダＴ＿ｐｒｏｖｉｄｅｒ（例えば図３を参照すると４０）がサービスモジュールに割り当てられる。

テーブル１７は、（テーブル５で定義された）ＳＣＯＬ＿ＡＳＰＥＣＴ＿ＵＳＥテーブルの定義に従って、（テーブル１６によって提供された）サービスモジュールを（テーブル１３によって提供された）アスペクトに関連付ける。

テーブル１８は、（テーブル６で定義された）ＳＣＯＬ＿ＱＵＥＲＹテーブルの定義に従って、図５のビジネスプロセス１５０を容易にするように設計されたクエリを定義する。例えば、Ｓ＿Ｃｕｓｔｏｍｅｒサービスモジュールに関連付けられているＱｕｅｒｙＢｙＮａｍｅは、クエリの入力としてＣｕｓｔｏｍｅｒ＿Ｓｔｒｕｃｔｕｒｅ、およびどのキーをフィルタリングに使用することができるかを定義する１組の顧客キー（Ｃｕｓｔｏｍｅｒ＿Ｋｅｙ）を取得する。フィールドＰＲＯＶＩＤＥＲ＿ＣＬＡＳＳは、どのクエリサービスプロバイダ３２（図３を参照）が各サービスモジュールに関連付けられるかを指定する。テーブル１８において、クエリサービスプロバイダＱ＿ｐｒｏｖｉｄｅｒ（３２など）が各サービスモジュールに関連付けられている。

テーブル１９は、テーブル１３〜１８で定義されたリポジトリ１８の実装についてのデータ辞書を定義する。各行は、名前を有する構造、並びに複数のデータエントリおよびそのタイプを定義する。例えば、構造Ｃｕｓｔｏｍｅｒ＿Ｓｔｒｕｃｔｕｒｅは、「ＮＡＭＥ」という名称の１つのデータエントリ、および文字列を示すＣＨＡＲ型を有する。Ｃｕｓｔｏｍｅｒ＿Ｋｅｙ＿Ｔａｂｌｅ構造は、顧客ごとにＣｕｓｔｏｍｅｒＩｄキーを定義し、ＣＨＡＲ型も有する。

プロセス１５０についての上記のデータベース操作は、リポジトリ１８のこの実装において次のように定義される。プロセス１５０に含まれている、顧客データベーステーブル（テーブル７）のクエリを行うこと（１５４）は、メタデータリポジトリ１８において、テーブル１８のアスペクトサービスモジュールＳ＿Ｃｕｓｔｏｍｅｒに関連付けられているＱｕｅｒｙＢｙＮａｍｅクエリによって記述される。アスペクトサービスモジュールＳ＿Ｃｕｓｔｏｍｅｒに関連付けられているこのＱｕｅｒｙＢｙＮａｍｅクエリが選択される。というのは、フロントエンドアプリケーションプログラム１２は顧客名を取得し、サービスモジュールＳ＿Ｃｕｓｔｏｍｅｒは顧客名を備えるアスペクトを含んでいるからである。例えば、フロントエンドアプリケーションプログラム１２は、サービスモジュールＳ＿Ｃｕｓｔｏｍｅｒに関連付けられているクエリＱｕｅｒｙＢｙＮａｍｅを、ＮＡＭＥ＝「Ｊｏｈｎ Ｓｍｉｔｈ」で、またＣｕｓｔｏｍｅｒ＿Ｋｅｙのフィルタリング指定無しでサービスマネージャ１６に送信することができる。サービスマネージャ１６は、リポジトリ１８をチェックして、クエリが定義されていることを確認する。次いでサービスマネージャ１６は、データベース２４内の顧客データベーステーブル（テーブル７）に対してクエリを行うクエリをＱ＿ｐｒｏｖｉｄｅｒ（例えば３２）に送信し、フロントエンドアプリケーションプログラム１２に戻される出力は、ＣｕｓｔｏｍｅｒＩｄ＝｛１｝を含むレコードセットである。

プロセス１５０に含まれる、顧客の住所データベーステーブル（テーブル８）に挿入すること（１６０）、およびプロセス１５０に含まれている、顧客データベーステーブル（テーブル７）に挿入すること（１６２）は、それぞれメタデータリポジトリ１８内のアスペクトＡ＿ＡｄｄｒｅｓｓおよびＡ＿Ｃｕｓｔｏｍｅｒに対する標準的な挿入操作（上述）によって記述される。

プロセス１５０に含まれる、製品データベーステーブル（テーブル９）に対して製品名についてのクエリを行うこと（１６６）は、テーブル１８で定義されているサービスモジュールＳ＿ｐｒｏｄｕｃｔに関連付けられているＱｕｅｒｙＢｙＮａｍｅクエリによって記述される。例えば、アプリケーション１２は、サービスモジュールＳ＿Ｐｒｏｄｕｃｔに関連付けられているクエリＱｕｅｒｙＢｙＮａｍｅを、ＮＡＭＥ＝「レンチ」で、またＰｒｏｄｕｃｔ＿Ｋｅｙのフィルタリング指定無しでサービスマネージャ１６に送信することができる。サービスマネージャ１６は、リポジトリ１８をチェックして、クエリが定義されていることを確認する。次いでサービスマネージャ１６は、データベース２４に対してクエリを行うクエリをＱ＿ｐｒｏｖｉｄｅｒ（例えば３２）に送信し、アプリケーション１２に戻される出力はＰｒｏｄｕｃｔＩｄ＝｛３｝を含むレコードセットである。

プロセス１５０に含まれる挿入すること（１７０、１７２、および１７４）は、それぞれアスペクトＡ＿ＯｒｄｅｒＨｅａｄｅｒ、Ａ＿Ｂａｓｋｅｔ、Ａ＿Ｐｏｓｉｔｉｏｎに対する挿入操作によって定義される。

プロセス１５０に含まれる、注文データベーステーブル（テーブル１２）に対して顧客でクエリを行うこと（１７８）は、テーブル１８で定義されているサービスモジュールＳ＿Ｏｒｄｅｒに関連付けられているＱｕｅｒｙＢｙＣｕｓｔｏｍｅｒクエリによって記述される。例えばフロントエンドアプリケーションプログラム１２は、サービスモジュールＳ＿Ｏｒｄｅｒに関連付けられているクエリＱｕｅｒｙＢｙＣｕｓｔｏｍｅｒを、Ｃｕｓｔｏｍｅｒ＿Ｋｅｙ（ＣｕｓｔｏｍｅｒＩｄ）＝｛２｝で、またＯｒｄｅｒＨｅａｄｅｒ＿Ｋｅｙのフィルタリング無しで送信することができる。サービスマネージャ１６は、リポジトリ１８をチェックして、クエリが定義されていることを確認する。次いでサービスマネージャ１６は、データベース２４に対してクエリを行うクエリをＱ＿ｐｒｏｖｉｄｅｒ（例えば３２）に送信し、アプリケーション１２に戻される出力はＯｒｄｅｒＨｅａｄｅｒ＿Ｋｅｙ（ＯｒｄｅｒＩｄ）＝｛２，３｝を含むレコードセットである。

プロセス１５０に含まれる、注文データベーステーブル（テーブル１２）において注文操作を選択すること（１８０）、および選択された注文に関して送信済みフィールドをＴｒｕｅに設定すること（１８２）は、リポジトリ１８内のアスペクトＡ＿ＯｒｄｅｒＨｅａｄｅｒに対する（テーブル１４で定義した）Ｅｘｅｃｕｔｅ Ｓｕｂｍｉｔアクションによって定義される。例えば、フロントエンドアプリケーションプログラム１２は、アスペクトＡ＿ＯｒｄｅｒＨｅａｄｅｒにおけるＳｕｂｍｉｔアクションをＯｒｄｅｒＨｅａｄｅｒ＿Ｋｅｙ＝｛２，３｝でサービスマネージャ１６に送信する。次いでサービスマネージャ１６は、ＯｒｄｅｒＩｄ＝｛２，３｝に対応する選択された行について注文データベーステーブル（テーブル１２）内の送信済みフィールドを「Ｔｒｕｅ」に変更する送信操作をＳ＿ｐｒｏｖｉｄｅｒ（例えば３４）に送信する。

プロセス１５０に含まれる、住所データベーステーブル（テーブル８）から顧客の住所を取得すること（１８４）は、Ａ＿Ｃｕｓｔｏｍｅｒアスペクトに対する標準Ｓｅｌｅｃｔ Ｂｙ Ｒｅｌａｔｉｏｎアクションによって定義される。例えば、フロントエンドアプリケーションプログラム１２は、関係Ｒ＿Ｃｕｓｔｏｍｅｒ＿Ｔｏ＿ＡｄｄｒｅｓｓおよびＣｕｓｔｏｍｅｒ＿Ｋｅｙ＝｛２｝を指定し、Ａ＿Ｃｕｓｔｏｍｅｒアスペクトに対するＳｅｌｅｃｔ Ｂｙ Ｒｅｌａｔｉｏｎアクションをサービスマネージャ１６に送信する。サービスマネージャ１６は、要求をリポジトリ１８と照合し、ＣｕｓｔｏｍｅｒＩｄ＝｛２｝に一致する外部キーＡｄｄｒｅｓｓＩｄを調べ、住所テーブル８にナビゲートする要求をサービスプロバイダＳ＿ｐｒｏｖｉｄｅｒ（例えば３４）に渡す。Ｓ＿ｐｒｏｖｉｄｅｒ（例えば３４）は、住所データベーステーブル（テーブル８）からの｛Ｌｏｕｉｓｖｉｌｌｅ，Ｗｉｌｌｏｗ Ａｖｅｎｕｅ｝を含むレコードセットをサービスマネージャ１６を介してアプリケーション１２に戻す。

上述した技術は、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはその組み合わせで実施することができる。また、本技術は、コンピュータプログラム製品、すなわち、例えばプログラム可能プロセッサ、コンピュータ、または複数のコンピュータなどのデータ処理装置によって実行するために、またはその操作を制御するために、情報媒体、例えばマシン読取り可能記憶装置や伝搬信号に有形で組み込まれるコンピュータプログラムとして実装することができる。コンピュータプログラムは、コンパイル言語、インタプリタ言語を含めて、任意の形のプログラミング言語で書くことができ、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境での使用に適した他のユニットを含む任意の形で配置することができる。コンピュータプログラムは、１つのコンピュータ上で、または１つのサイトの複数のコンピュータ上で、または複数のサイトにわたって分散され、通信ネットワークで相互接続された複数のコンピュータ上で実行されるように配置することができる。

この技術の方法のステップは、入力データに作用し、出力を生成することによって本発明の機能を実行するためにコンピュータプログラムを実行する１つまたは複数のプログラム可能プロセッサによって実行することができる。方法のステップは、ＦＰＧＡ（field programmable gate array）またはＡＳＩＣ（application-specific integrated circuit）など、専用論理回路によって実行することもでき、また本発明の装置は、専用論理回路として実装することができる。この方法のステップは、上述したもの以外の他の順序（order）で実行してもよい。

コンピュータプログラムの実行に適したプロセッサは、一例として、汎用および専用マイクロプロセッサ、および任意の種類のデジタルコンピュータの任意の１つまたは複数のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリまたはランダムアクセスメモリ、あるいはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令を実行するプロセッサ、および命令およびデータを格納する１つまたは複数の記憶装置である。一般に、コンピュータは、磁気、光磁気ディスク、または光ディスクなど、データを格納する１つまたは複数の大容量記憶装置も備え、またはそれとの間でデータの送受信を行うように動作可能に結合される。コンピュータプログラム命令およびデータを組み込むのに適した情報媒体は、一例としてＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ装置などの半導体メモリ装置、内部ハードディスクや取外し可能なディスクなどの磁気ディスク、光磁気ディスク、およびＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクを含めて、すべての形の不揮発性メモリを含む。プロセッサおよびメモリは、専用論理回路によって補うことができ、またはそれに組み込むことができる。

この技術は、例えばデータサーバとしてバックエンドコンポーネントを含む、アプリケーションサーバなどのミドルウェアコンポーネントを含む、またはユーザがこの技術の実装と対話することができるグラフィカルユーザインターフェイスやＷｅｂブラウザを有するクライアントコンピュータなどのフロントエンドコンポーネントを含む、あるいはこうしたバックエンド、ミドルウェア、およびフロントエンドのコンポーネントの任意の組み合わせを含むコンピューティングシステムを使用して実施することができる。

本発明を、特定の実施形態に関して説明してきた。他の実施形態も、添付の特許請求の範囲内に含まれる。

ビジネスソフトウェアアプリケーションの論理表現例を示すブロック図である。 ビジネスソフトウェアアプリケーションのネットワーク構成を示す図である。 図１のビジネスソフトウェアアプリケーションを示すブロック図である。 メタモデルリポジトリの構造の統一モデリング言語（ＵＭＬ）表現を示す図である。 ビジネスプロセスを示すフロー図である。 ビジネスソフトウェアアプリケーションの様々な態様の間の関係を示す図である。

Claims (22)

1. クライアントプログラムを実行するように構成されている第１コンピュータと、
   サーバプログラムを実行するように構成されているデータ記憶装置を備えた第２コンピュータと、
   前記第１および第２コンピュータをリンクするネットワークと、
   を具備したシステムにおいて、ビジネスソフトウェアアーキテクチャを構成してサービスを提供するための情報をやりとりして提示する方法であって、
   前記第２コンピュータに接続されているデータ記憶装置に格納されているリポジトリにおいて、前記第２コンピュータ上で稼動するサービスプロバイダにより提供されるサービスを予めメタモデルに基づき定義および記述するステップと、
   前記第１コンピュータ上で実行されているフロントエンドアプリケーションプログラムが、前記第２コンピュータ上で実行されているサービスマネージャにサービス要求を発行し、該サービスマネージャは、前記リポジトリ内の前記メタデータとの一致をチェックし、該要求を前記サービスプロバイダに渡すことで、前記リポジトリにおいて定義および記述されているサービスを要求するステップと、
   前記データ記憶装置内のバックエンドデータベース内には複数のデータ要素の集まりであるコレクションが複数格納されており、前記サービスプロバイダが、前記要求に対応して複数のコレクションのうちの１つのコレクションにおけるデータ要素にアクセスし、または前記データ要素を修正する操作を実行するステップと、
   を具備し、
   前記サービスは、前記コレクションにおけるデータ要素に対する前記操作を実行し、該操作実行後のデータ要素を前記フロントエンドアプリケーションプログラムに提供することを含み、
   前記リポジトリは、メタモデルに従って構成されているデータベースであって、前記サービスの意味的記述と、各コレクションの共通の属性を含むメタデータと、を含むことを特徴とする方法。
2. 前記リポジトリには、前記メタデータ内で、前記複数のコレクションの内の１つのコレクションに対する専用のアクションがさらに定義されており、
   前記アクションとは、アスペクトの１つまたは複数のインスタンスに対する専用のメソッドであり、
   前記アスペクトとは、ビジネスオブジェクトクラスであることを特徴とする請求項１に記載の方法。
3. 前記操作は、構造の形の入力パラメータを含み、
   前記専用のアクションの記述は、
   前記専用のアクションの名前と、
   前記専用のアクションの入力パラメータデータのデータ構造の名前と、
   前記データ要素のコレクションの名前と、
   を含むことを特徴とする請求項２に記載の方法。
4. 前記操作は、前記サービスプロバイダのクラスのメソッドに対応することを特徴とする請求項１から３のいずれかに記載の方法。
5. 前記操作は、選択、削除、関係による選択、および、更新の操作を含み、
   前記関係による選択は、データ型がわかっている場合に、前記リポジトリで定義されている該データ型に関係がある他のデータ型を見つけることができる機能であることを特徴とする請求項４に記載の方法。
6. 前記複数のコレクションのうちの１つのコレクションは、前記複数のコレクションのうちの他のコレクションと関係付けられており、
   該関係の記述は、前記リポジトリ内に格納され、
   前記関係によって前記フロントエンドアプリケーションプログラムは、前記複数のコレクションのうちの１つのコレクションのデータ要素を指定することによって、前記他のコレクションのデータ要素の取り出しを要求することができることを特徴とする請求項１から５のいずれかに記載の方法。
7. 前記操作を実行するステップは、
   前記データ記憶装置から前記複数のコレクションのうちの１つのコレクションの前記属性を読み取るステップと、
   前記フロントエンドアプリケーションプログラムに前記属性を送信するステップと、
   を含むことを特徴とする請求項１から６のいずれかに記載の方法。
8. コレクションおよび前記コレクションの共通の属性の記述は、
   前記コレクションの名前と、
   前記属性を定義するデータ構造の記述と
   を含むことを特徴とする請求項１から７のいずれかに記載の方法。
9. 前記操作はクエリであり、前記操作を実行するステップは、
   前記複数のコレクションのうちの１つのコレクションの中の個々のデータ要素を検索するステップと、
   前記個々のデータ要素を表す識別子であるキーを返すステップと、
   をさらに含むことを特徴とする請求項１から８のいずれかに記載の方法。
10. 前記リポジトリは、前記クエリの定義を含み、
    前記クエリは、
    前記クエリの検索パラメータ構造と、
    前記データ要素のコレクションから１つまたは複数のデータをフィルタリングするために使用される入力キー記述子と、
    を含むことを特徴とする請求項９に記載の方法。
11. ソフトウェアエンティティが前記リポジトリにおいて定義および記述されている前記サービスを要求できるようにするステップと、
    前記複数のコレクションのうち１つのコレクションの中の前記１つまたは複数のデータ要素に対する前記操作を実行するステップと、
    をさらに含み、
    前記サービスは、前記複数のコレクションのうち１つのコレクションの中のデータ要素に対する前記操作を表していることを特徴とする請求項１から１０のいずれかに記載の方法。
12. クライアントプログラムを実行するように構成されている第１のコンピュータと、
    サーバプログラムを実行するように構成されているデータ記憶装置を備えた第２のコンピュータと、
    前記第１および第２のコンピュータをリンクするネットワークと、
    を具備したシステムにおいて、ビジネスソフトウェアアーキテクチャを構成してサービスを提供するための情報をやりとりして提示するシステムであって、
    前記第２コンピュータに接続されているデータ記憶装置に格納されているリポジトリにおいて、前記第２コンピュータ上で稼動するサービスプロバイダにより提供されるサービスを予めメタモデルに基づき定義および記述する手段と、
    前記第１コンピュータ上で実行されているフロントエンドアプリケーションプログラムが、前記第２コンピュータ上で実行されているサービスマネージャにサービス要求を発行し、該サービスマネージャは、前記リポジトリ内の前記メタデータとの一致をチェックし、該要求を前記サービスプロバイダに渡すことで、前記リポジトリにおいて定義および記述されているサービスを要求する手段と、
    前記データ記憶装置内のバックエンドデータベース内には複数のデータ要素の集まりであるコレクションが複数格納されており、前記サービスプロバイダが、前記要求に対応して複数のコレクションのうちの１つのコレクションにおけるデータ要素にアクセスし、または前記データ要素を修正する操作を実行する手段と、
    を具備し、
    前記サービスは、前記コレクションにおけるデータ要素に対する前記操作を実行し、該操作実行後のデータ要素を前記フロントエンドアプリケーションプログラムに提供することを含み、
    前記リポジトリは、メタモデルに従って構成されているデータベースであって、前記サービスの意味的記述と、各コレクションの共通の属性を含むメタデータと、
    を含むことを特徴とするシステム。
13. 前記リポジトリには、前記メタデータ内で、前記複数のコレクションの内の１つのコレクションに対する専用のアクションがさらに定義されており、
    前記アクションとは、アスペクトの１つまたは複数のインスタンスに対する専用のメソッドであり、
    前記アスペクトとは、ビジネスオブジェクトクラスであることを特徴とする請求項１２に記載のシステム。
14. 前記操作は、構造の形の入力パラメータを含み、
    前記専用のアクションの記述は、
    前記専用のアクションの名前と、
    前記専用のアクションの入力パラメータデータのデータ構造の名前と、
    データ要素の前記コレクションの名前と、
    を含むことを特徴とする請求項１３に記載のシステム。
15. 前記操作は、前記サービスプロバイダのクラスのメソッドに対応することを特徴とする請求項１２から１４のいずれかに記載のシステム。
16. 前記操作は、選択、削除、関係による選択、および、更新の操作を含み、
    前記関係による選択は、データ型がわかっている場合に、前記リポジトリで定義されている該データ型に関係がある他のデータ型を見つけることができる機能であることを特徴とする請求項１５に記載のシステム。
17. 前記複数のコレクションのうちの１つのコレクションは、前記複数のコレクションのうちの他のコレクションと関係付けられており、
    該関係の記述は、前記リポジトリ内に格納され、
    前記関係によって前記フロントエンドアプリケーションプログラムは、前記複数のコレクションのうちの１つのコレクションのデータ要素を指定することによって、前記他のコレクションのデータ要素の取り出しを要求することができることを特徴とする請求項１２から１６のいずれかに記載のシステム。
18. 前記操作を実行する手段は、
    前記データ記憶装置から前記複数のコレクションのうちの１つのコレクションの前記属性を読み取る手段と、
    前記フロントエンドアプリケーションプログラムに前記属性を送信する手段と、を含むことを特徴とする請求項１２から１７のいずれかに記載のシステム。
19. コレクションおよび前記コレクションの共通の属性の記述は、
    前記コレクションの名前と、
    前記属性を定義するデータ構造の記述と
    を含むことを特徴とする請求項１２から１８のいずれかに記載のシステム。
20. 前記操作はクエリであり、前記操作を実行する手段は、
    前記複数のコレクションのうちの１つのコレクションの中の個々のデータ要素を検索する手段と、
    前記個々のデータ要素を表す識別子であるキーを返す手段と、
    をさらに含むことを特徴とする請求項１２から１９のいずれかに記載のシステム。
21. 前記リポジトリは、前記クエリの定義を含み、
    前記クエリは、
    前記クエリの検索パラメータ構造と、
    前記データ要素のコレクションから１つまたは複数のデータをフィルタリングするために使用される入力キー記述子と、
    を含むことを特徴とする請求項２０に記載のシステム。
22. クライアントプログラムが前記リポジトリにおいて定義および記述されている前記サービスを要求できるようにする手段と、
    前記複数のコレクションのうち１つのコレクションの中の前記１つまたは複数のデータ要素に対する前記操作を実行する手段と、
    をさらに含み、
    前記サービスは、前記複数のコレクションのうち１つのコレクションの中のデータ要素に対する前記操作を表していることを特徴とする請求項１２から２１のいずれかに記載のシステム。

Images