図1は、クライアント3、分離層5、リポジトリ7、およびバックエンドデータ9および9’を含むビジネスソフトウェアアーキテクチャ2の論理表現の概略を示している。クライアント3は、ユーザがバックエンドデータ9および/または9’と対話できるようにするユーザインターフェイス(UI)を提供する。バックエンド9および9’は、異なるバックエンドアプリケーションに関連付けることができ、かつ/または互いに異なるように整え、フォーマットすることができる。分離層5は、クライアント3によって提供されたフロントエンドユーザインターフェイスをバックエンドデータ9および9’から分離する。この分離によって、クライアント3は、バックエンドデータ9および9’間のフォーマットまたはアプリケーションに関連する差異に関係なく、一貫した同様の方法でバックエンドデータ9および9’と対話することができる。言い換えれば、クライアント3が分離層5と対話するように構成され、分離層5が変わった場合のみクライアント3を更新すれば良いように、分離層5は、バックエンドデータ9および9’への正規のインターフェイスを提供する。バックエンドデータ9および9’への変更は、クライアント3への更新を必要としない。さらに、分離層5は、拡張性があり、バックエンドデータ9および9’、およびさらに分離層5に接続される他の任意の異なるバックエンドデータおよびバックエンドサービスへの変更および増加に対応するように構成されている。
以下でより詳しく説明するように、分離層5は、バックエンドデータ(9および9’など)がどのように分離層5で表されるかを定義するメタモデルに基づいている。バックエンドデータ9および9’がどのようにメタモデル表現に適合するかを記述するメタデータがリポジトリ7に格納される。クライアント3は、分離層5によって定義される汎用のコマンドセットを使用してバックエンドデータ9および9’と対話する。以下でより詳しく説明するように、分離層5は、リポジトリ7内のメタデータを使用して、クライアント3から汎用のコマンドを実行するサービスプロバイダにアクセスして、バックエンドデータ9および9’の要求された操作を行う。サービスプロバイダは、異なるサービスプロバイダを異なるバックエンドデータ9および9’に使用できるように構成可能である。分離層5は、対応するバックエンドデータ9および9’の特徴、並びに実装の粒度および配布(すなわちサービスプロバイダ)を隠すインターフェイス(サービスマネージャなど)を含む。
図2は、ビジネスソフトウェアアーキテクチャ2の実装例を示している。図2に示すように、ビジネスソフトウェアアーキテクチャ2は、第1のコンピュータ4および第2のコンピュータ6を含む。コンピュータ4および6はそれぞれ、プロセッサ(CPU)バスによって結合されたプロセッサ、ランダムアクセスメモリ(RAM)、プログラムメモリ(例えばフラッシュROMなどの書き込み可能読み取り専用メモリ(ROM))、ハードドライブコントローラ、ビデオコントローラ、および入力/出力(I/O)コントローラを含み得る。コンピュータ4および6を、例えばROM内で予めプログラミングしておくことができる。または、コンピュータ4、6は、プロセッサによって実行できるように、プログラムを別のソース(フロッピー(登録商標)ディスク、CD−ROM、別のコンピュータなど)からRAMにロードすることによってプログラミング(または再プログラミング)することができる。ハードドライブコントローラは、本発明を具現するプログラムを含む、実行可能なコンピュータプログラムおよびデータを格納するのに適したハードディスクに結合される。入力/出力コントローラは、入力/出力バスによって入力/出力インターフェイスに結合される。入力/出力インターフェイスは、シリアルリンク、ローカルエリアネットワーク、無線リンク、またはパラレルリンクなどの通信リンクを介してアナログ形式またはデジタル形式でデータを送受信する。また、入力/出力バスには、ディスプレイおよびキーボードが結合される。あるいは、入力/出力インターフェイス、ディスプレイ、およびキーボードに個別の接続(個別のバス)を使用することができる。
ネットワーク20は、コンピュータ4および6を接続する。ネットワーク20は、例えば通信ネットワークなど、任意の形式または媒体のデジタルデータ通信である。通信ネットワーク20の例には、ローカルエリアネットワーク(「LAN」)および広域ネットワーク(「WAN」)、例えばインターネットなどがある。
コンピュータ4は、フロントエンドアプリケーションプログラム12の命令を実行する。アプリケーションプログラム12は、ビジネスソフトウェアアーキテクチャ2のフロントエンドコンポーネントを表す。コンピュータ6上で稼働しているサービスマネージャ16は、フロントエンドアプリケーションプログラム12と1組のバックエンドサービスプロバイダ26との間のサービス層である。サービスマネージャ16は、サービスインターフェイスをフロントエンドアプリケーションプログラム12に提供して、コンピュータ6上で稼働する1組のバックエンドサービスプロバイダ26との間接的な対話を可能にする。このサービスインターフェイスは、フロントエンドアプリケーションプログラム12および1組のバックエンドサービスプロバイダ26のソフトウェア開発の部分的な分離を可能にする。
コンピュータ6は、1組のバックエンドサービスプロバイダ26によって使用することができるデータを含むバックエンドデータベース24を格納するデータ記憶装置22を含む。また、コンピュータ6は、1組のバックエンドサービスプロバイダ26によって提供されるサービスを定義し、記述する情報リポジトリ18を含むデータ記憶装置8も含む。リポジトリ18内のメタデータは、メタモデルに従って編成される。
一般に、メタモデルは、ある領域を記述することができる語彙である「概念」のコレクションである。メタモデルは一般に、ほとんどの場合ERA(実体−関連−属性:entity-relationship-attribute)またはオブジェクト指向のモデリングから導出される厳格な1組のルールに従って構築される。フロントエンドアプリケーションプログラム12は、サービスマネージャ16を介してリポジトリ18の中身にアクセス(し、厳格な1組のルールに従ってそれを解釈)することができる。これらのサービスは、アプリケーションプログラム12の機能をサポートし、格納されているデータを修正することに加えて、データを取り出すこと、および、読み取ることを含む。サービスプロバイダ26は、バックエンドデータベース24内に格納されているデータにアクセスし、またはそれを修正して、サービスをフロントエンドアプリケーションプログラム12に提供することができる。サービスを提供するために、1組のバックエンドサービスプロバイダ26は、フロントエンドアプリケーションプログラム12から要求があると、バックエンドデータベース24内に格納されているデータにアクセスしたりデータを修正したりするか、または新しいデータを算出する。
リポジトリ18は、1組のバックエンドサービスプロバイダ26によって提供されるサービスを要求する構文を定義し、サービスを意味的に記述する。フロントエンドアプリケーションプログラム12が実行されるとき、フロントエンドアプリケーションプログラム12は、(サービスマネージャ16を介してアクセスされる)リポジトリ18からのこの構文および意味的記述を使用して、その要件を満たすために、フロントエンドアプリケーションプログラム12がどのサービスを使用することができるかを決定する。格納されている、または算出されたバックエンドデータについての構文および意味的記述を、「メタデータ」と呼ぶことができる。この格納されている、または算出されたバックエンドデータは、ビジネスオブジェクトの点から見たオブジェクト指向用語を使用して、概念的に編成される。この場合、各ビジネスオブジェクトは、クラスまたはデータエンティティタイプのインスタンスである。一例では、ビジネスオブジェクトのクラスは、テーブル内のデータの各行が特定のビジネスオブジェクトのデータを表すリレーショナルデータベーステーブルを参照する。この例では、テーブル内の各フィールドは、ビジネスオブジェクトクラスの属性を表す。別の例では、テーブル内のフィールドの一部がビジネスオブジェクトクラスの属性を表し、他のフィールドが要求に応じて算出されるように、リレーショナルデータベースを部分的に参照するビジネスオブジェクトのクラスがある。
ビジネスソフトウェアアーキテクチャ2において、フロントエンドアプリケーションプログラム12に提供されるサービスの焦点はデータに絞られているため(データ中心)、リポジトリ18内のこれらのサービスの記述もデータ中心である。したがって、リポジトリ18内のメタデータは、これらのビジネスオブジェクトのクラスの表現を核にして構築される。このメタデータは、アスペクト、すなわちビジネスオブジェクトクラスのこれらの表現の記述、およびサービスプロバイダ26によって提供される選択、挿入、更新、削除、関係による選択、およびフィールドの更新など、アスペクトに対する使用可能な操作の記述を含む。これらのアスペクトの各記述は、データ属性、およびこれらのアスペクトのインスタンスにおいて1組のバックエンドサービスプロバイダ26によって実行されるよう要求することができるアクションを含む。
データの分類、データクラス間の関係、データにアクセスするための予め構築されたクエリ、1組のバックエンドサービスプロバイダ26によって提供されたデータのその他の記述は、リポジトリ18によって表される。1組のバックエンドサービスプロバイダ26によって提供された(例えばバックエンドデータベース24に格納されている)データの表現、すなわちメタデータは、バックエンドデータベース24内のデータの異なる抽象型またはクラス、および異なるデータクラスがどのように互いに関連するかを記述する。オブジェクトとは、これらの異なる抽象型のインスタンスである。メタデータとは、データの内容ではなく、データについての情報である。また、メタデータは、データベース24内のデータに対して実行することができる予め構築された1組のクエリも定義する。
リポジトリ18内の意味的記述によって、フロントエンドアプリケーションプログラム12は、サービスマネージャ16にどのサービスを要求すべきかを決定することができる。これらのサービスは、しばしば表示すべきデータを要求する形式を取る。フロントエンドアプリケーションプログラム12は、リポジトリ18内のメタデータを読み取り、メタデータによって指定された様々な方法で編成されたデータを柔軟に要求することができる。例えば、異なる2つのリポジトリ18を備える2つのサービスマネージャ16は、会社AおよびBの本の価格を決定するサービスを扱う。AおよびBでは、本の価格は、様々なアスペクトによって様々なデータフィールドで表される。フロントエンドアプリケーションプログラム12は、Aのリポジトリ18を読み取り、Aのサービスプロバイダ26から特定の本に関する(価格を含む)データの記述を取得する。フロントエンドアプリケーションプログラム12は、Bのリポジトリ18を読み取り、Bのサービスプロバイダ26から特定の本に関する(価格を含む)データの記述を取得する。フロントエンドアプリケーションプログラム12は、本の価格情報をユーザに提示するために、Aのサービスプロバイダ26からの情報、およびBのサービスプロバイダ26からの異なって編成された情報を要求し、表示することができる。
リポジトリ18内の意味的記述によって記述されたサービスを要求するために、サービスマネージャ16は、バックエンド内のビジネスオブジェクトに対するサービスのための正規のインターフェイスを提供する。この正規のインターフェイスは、ビジネスオブジェクトに対する1組の標準操作を含む。ビジネスオブジェクトに対するこうした標準操作には、選択、挿入、更新、削除、関係による選択、およびフィールドの更新などがある。これらの標準操作は、理解しやすく、また使いやすくするためのものである。これらの標準操作の使用は、リポジトリ18のメタモデルの厳格な1組のルールを介して理解される。さらに、リポジトリ18は、操作の使用による副作用であるドキュメント化されたモデリング(documented modeling)も含む。ビジネスオブジェクトを格納した操作モデルの副作用は、メソッドを実行することによって影響を受ける。例えば、「削除」は通常、削除されたオブジェクトに関連する格納されている他のビジネスオブジェクトに副作用を及ぼす。他の標準操作は、より特化したタスクを実行し、フロントエンドアプリケーションプログラム12とサービスマネージャ16との間のトランザクションのための機能をサポートする(ロック操作など)。
サービスマネージャ16によって提供される正規のインターフェイスは、ビジネスオブジェクトの特定のクラスのために定義される専用のアクション、およびビジネスオブジェクトのクラスのクラスタのために定義され得るクエリも含んでいる。クラスタは、メタデータ内のサービスモジュール(以下でさらに詳述する)としてモデリングされる。これらのアクションおよびクエリも、リポジトリ18のメタデータ内で定義される。
実行中、フロントエンドアプリケーションプログラム12は、サービスマネージャ16にサービス要求を発行し、サービスマネージャ16は、リポジトリ18内のメタデータとの一致について要求をチェックし、次いでサービスマネージャ16は、リポジトリデータベース18内のメタデータに従って要求をバックエンドサービスプロバイダ26に渡す。1組のバックエンドサービスプロバイダ26およびデータベース24内のデータを実施する方法は、バックエンドサービスプロバイダ26およびデータベース24内のデータがリポジトリ18内のメタデータの定義および記述に準拠している状態で、アプリケーション12から独立している。データベース24は、リレーショナルデータベースとすることができる。しかし、バックエンドサービスプロバイダ26およびデータベース24内のデータがリポジトリ18内のメタデータに準拠する場合、リレーショナルデータベース以外の異なるモードのデータ構成を使用するためにデータベース24を変更することができ、フロントエンドアプリケーションプログラム12を変更する必要はない。データベース24のこうした異なるモードのデータ構成の1つは、オブジェクト指向データベースである。
フロントエンドアプリケーションプログラム12は、モニタ10に表示されるユーザインターフェイスを提供する。フロントエンドアプリケーションプログラム12は、1組のバックエンドサービスプロバイダ26から受信されたデータを表示し、集約するためのアプリケーションコードを提供する。フロントエンドアプリケーションプログラム12は、サービスマネージャ16を介して、より特化した操作に加えて、選択、挿入、更新、削除、および実行などの標準的な操作についての1組のバックエンドサービスプロバイダ26に対する要求を生成する。フロントエンドアプリケーションプログラム12は、対話中心であり、バックエンドサービスプロバイダ26のデータを集約し、対話するステップを組み合わせて画面の流れおよびシンジケート化された画面要素にすることに焦点をおいている。
フロントエンドアプリケーションプログラム12は、ユーザインターフェイス(UI)指向アプリケーションの画面遷移ロジック(screen-flow logic)を含んでおり、フロントエンドアプリケーションプログラム12は、UIをリポジトリ18内のメタデータに結合する。フロントエンドアプリケーションプログラム12は、リポジトリ18のメタデータ内のサービスの記述を介して、バックエンドサービスプロバイダ26によって、1組の特定のバックエンドサービスに間接的に結合することができる。フロントエンドアプリケーションプログラム12は、バックエンドサービスプロバイダ26への仲介物として働くサービスマネージャ16によって高度に標準化されたサービス層への構成によって結合されただけの、様々な汎用の対話中心フロントエンド層から形成することもできる。
一部の実装形態では、サービスマネージャプロキシ14は、フロントエンドアプリケーションプログラム12に、サービスマネージャ16によって提供されたサービスインターフェイスへの緩衝化したアクセスを提供する。サービスマネージャプロキシ14は、フロントエンドアプリケーションプログラム12とサービスマネージャ16との間の仲介物として働くコンピュータ4のサーバであり、ビジネスソフトウェアアーキテクチャ2が、セキュリティ、管理制御(administrative control)、およびキャッシングサービスを確実にすることができるようにする。サービスマネージャ16は、往復の無駄を無くすために、(結果的にサービスメソッドをもたらす)いくつかのサービス要求またはコマンドを単一のサービスメソッドキューにバンドルするためにフロントエンドアプリケーションプログラム12によって使用されるキュー機能を提供する。サービスマネージャプロキシ14によって、フロントエンドアプリケーションプログラム12およびサービスマネージャ16が異なるコンピュータ4、6に分かれるようにすることができる。さらに、サービスマネージャプロキシ14の使用によって、サービスマネージャ16および1組のバックエンドサービスプロバイダ26を、複数のコンピュータにわたって分散させることができる。
一例では、サービスマネージャプロキシ14は、ネットワーク20を介してSOAP(Simple Object Access Protocol)メッセージを使用してサービスマネージャ16と通信する。SOAPは、ある種類のオペレーティングシステム(ワシントン州レドモンド在のMicrosoft Corporationから入手可能なWindows(登録商標)XPオペレーティングシステムなど)で稼働するプログラムが、WWWのHTTP(ハイパーテキスト転送プロトコル)およびXML(拡張可能なマークアップ言語)を情報交換の機構として使用することによって、同じまたは別の種類のオペレーティングシステム(Linux(登録商標)など)のプログラムと通信するための方法である。Webプロトコルが組み込まれており、すべての主なオペレーティングシステムプラットフォームによって使用可能であるため、HTTPおよびXMLは、あるネットワークにおいて様々なオペレーティングシステム下で稼働しているプログラムがどうやって互いに通信することができるかの問題の解決策を提供する。SOAPは、あるコンピュータのプログラムが別のコンピュータのプログラムを呼び出し、それに情報を渡すことができるように、HTTPヘッダおよびXMLファイルをエンコードする方法を正確に指定する。また、SOAPは、呼び出される側のプログラムがどうやって応答を戻すことができるかも指定する。
図3に示すように、サービスマネージャ16は、1組のバックエンドサービスプロバイダ26およびデータベース24内のデータから対応するバックエンドサービスプロバイダの特徴を隠す(リポジトリ18内のメタデータによって定義された)インターフェイスをフロントエンドアプリケーションプログラム12に提供する。フロントエンドアプリケーション12は、このインターフェイスを使用して、ユーザとの対話のためにグラフィカルユーザインターフェイス(GUI)28で表示するデータをバックエンドデータベース24から取り出す。
サービスマネージャ16は、フロントエンドアプリケーションプログラム12からバックエンドサービスプロバイダ26への要求を受信し、それを実行することによって、インターフェイスをフロントエンドアプリケーションプログラム12に提供する。サービスマネージャ16は、要求の各受信の後、その要求を1つまたは複数のサービスプロバイダ30、32、34、40、42、44、および46に委ねる。サービスプロバイダ30は、ソフトウェアクラスのリポジトリサービスプロバイダのインスタンスである。サービスプロバイダ32、34、40、42、44、および46は、クエリサービスプロバイダクラス(32)、アスペクトサービスプロバイダクラス(34)、トランザクションサービスプロバイダクラス(40)、ロッキングサービスプロバイダクラス(42)、アクションサービスプロバイダクラス(44)、およびクエリ関係サービスプロバイダクラス(46)などのソフトウェアクラスのインスタンスを表す。サービスプロバイダのソフトウェアクラス32、34、40、42、44、および46は、ドイツ、Walldorf在の本件特許出願人から入手可能なABAP(登録商標)(Advanced Business Application Programming)開発環境を使用するABAP(登録商標)クラスライブラリによって維持されるABAP(登録商標)グローバルクラスとして実装することができる。これらは、Linux(登録商標)でのJava(登録商標)、Windows(登録商標)でのC#など、他の任意のプラットフォームでの他の任意のプログラミング言語によっても実装することができる。
リポジトリサービスプロバイダ30は、リポジトリ18からメタデータを取得し、またはそれを変更する旨の要求を扱う。クエリサービスプロバイダ32は、フロントエンドアプリケーションプログラム12からのバックエンドデータベース24内のデータに対するクエリを扱う。アスペクトサービスプロバイダ34は、データへのアクセス、データの修正、関係のナビゲーション、およびアクションの呼び出しを扱う。アスペクトサービスプロバイダ34は、サービスマネージャ16から要求することができるアスペクトに対する、標準操作に対応する標準的な1組のメソッドを有する。こうした標準操作には、選択、挿入、更新、削除、関係による選択、およびフィールドの更新などがある。トランザクションサービスプロバイダ40によって、ビジネスロジックは、フロントエンドアプリケーションプログラム12とサービスプロバイダ26との間のトランザクションの異なる状態に対して作用することができる。ロッキング(locking)サービスプロバイダ42によって、バックエンドデータベース24内のデータ型における同時アクセスの分離が可能になる。アクションサービスプロバイダ44によって、アスペクトへのアクションの実行が可能になる。クエリ関係サービスプロバイダ46は、ある関係のターゲットアスペクトについてのインターフェイスである。一部の例では、サービスマネージャ16は、サービスを表すリポジトリ18内の様々な要素についての、サービスプロバイダ32、34、40、42、44、および46の様々な複数のインスタンスを有することができる。リポジトリ18内のある要素によって表されるサービスの要求を受信すると、サービスマネージャ16は、リポジトリ18内のその要素のメタデータ内で、サービスプロバイダ(32、34、40、42、44、および46など)の名前を調べることができる。例えば、リポジトリ18内のあるアスペクトを記述するメタデータは、どのアスペクトサービスプロバイダ34がそのアスペクトのサービスを扱うように設計されるかを定義する。サービスマネージャ16は、メタデータ内のこの情報を使用して、要求をフロントエンドアプリケーションプログラム12から適切なアスペクトサービスプロバイダ34に送る。同様に、リポジトリ18内のあるクエリを記述するメタデータは、どのクエリサービスプロバイダ32がそのクエリのサービスを扱うように設計されるかを定義する。
サービスマネージャ16によって提供されるインターフェイスは、要求またはコマンドをフロントエンドアプリケーションプログラム12に提供する。上述したように、標準コマンドの選択、挿入、更新、削除、関係による選択、およびフィールドの更新は、リポジトリ18内のアスペクトへの標準操作である。これらの標準操作は、アスペクトサービスプロバイダ34によって提供され、フロントエンドアプリケーションプログラム12への使用可能な要求またはコマンドの一部に対応する。「Select」コマンドは、アスペクトサービスプロバイダ34によって提供された(例えばデータベース24に格納されている)データ型のインスタンスの識別子(またはキー)がわかっている場合、フロントエンドアプリケーションプログラム12がこれらのインスタンスの属性を選択し、読み取ることができるような機能を提供する。「Insert」コマンドによって、フロントエンドアプリケーションプログラム12は、アスペクトサービスプロバイダ34によって提供された(例えばデータベース24に格納されている)データ型の新しいインスタンスを追加することができる。「Select By Relation」コマンドは、データ型がわかっている場合、フロントエンドアプリケーションプログラム12がリポジトリ18で定義されているこのデータ型に関係がある他のデータ型を見つけることができる機能を提供する。「Update」コマンドは、アスペクトサービスプロバイダ34によって提供された(例えばバックエンドデータベース24に格納されている)データ型のインスタンスを修正する機能を提供する。「Delete」コマンドは、アスペクトサービスプロバイダ34によって提供された(例えばバックエンドデータベース24に格納されている)1つまたは複数のデータ型の1つまたは複数の選択されたインスタンスを削除する機能を提供する。
「Execute」アクションコマンドは、アスペクトサービスプロバイダ34によって提供された(例えばデータベース24に格納されている)1つまたは複数のデータ型の1つまたは複数のインスタンスへの、意味的に定義されたアクションを実行する機能を提供する。アスペクトサービスプロバイダ34またはアクションサービスプロバイダ44がExecuteアクションコマンドを実行する。「Query」コマンドは、対象の特定のデータを検索し、見つける機能を提供する。Queryコマンドは、一定の組の検索パラメータ、および構造が定義された結果セットを備えるメソッドである。特定のサービスモジュール、またはリポジトリ18のメタデータ内のアスペクトのクラスタについてのクエリが定義される。クエリサービスプロバイダ32がQueryコマンドを実行する。
リポジトリ18内のメタデータは、データ型またはクラスに分類される。リポジトリ18内のデータ型の分類を表すメタモデルクラスの名前は、それらがそのメタモデルに属することを表し、サービスマネージャ16によって使用されているランタイムクラスと区別するために、接尾辞「記述子」を有する。リポジトリ18のメタデータのクラスの記述子、およびそのクラス関係は、図4の統一モデリング言語(UML)クラス図50を使用して示されている。
メタデータを、リレーショナルデータベースの用語で記述されるデータと比較すると、リポジトリ18内のアスペクトは、バックエンドデータベース24に完全にまたは部分的に格納されているクラスまたはエンティティ型を表すことができ、アスペクト記述子56は、エンティティ型についての他の情報に加えて、エンティティ型の属性を含む。また、リポジトリ18内のメタデータは、データベース24内に実装することができるアスペクト間の関係を、リレーショナルデータベースで外部キーを使用する関係として定義する関係記述子84を含むこともできる。また、メタデータは、アスペクトの集合であり、データベース24内のデータにアクセスするための予め定義されたクエリを有するサービスモジュールを表すサービスモジュール記述子54を含むこともできる。
リポジトリ18内で定義されたサービスモジュールは、特定の応用分野または業界のためのビジネスソフトウェアアーキテクチャ2における1組のアプリケーション(フロントエンドアプリケーションプログラム12など)の基礎的要素である。サービスモジュールは、その実装およびビジネスロジックをカプセル化し、統一された正規の方法でデータおよび機能へのアクセスを提供する。リポジトリ18内のサービスモジュールの例には、「ビジネスパートナー」、「従業員」、「販売注文」、または「企業活動」がある。サービスモジュール記述子54は、リポジトリ18のメタデータのデータモデル内のサービスモジュール、およびアプリケーションプログラム12からのクエリによってサービスモジュールにどのようにアクセスできるかを記述する。
リポジトリ18において、定義された各クエリは、サービスマネージャ16を介してサービスプロバイダ26によって提供された(アスペクトによって表される)データ型のインスタンスを検索するためのエントリポイントである。「キー」とは、サービスプロバイダ26によって提供されたデータ型のインスタンスの識別子である。「アクション」とは、アスペクトの1つまたは複数のインスタンスに対する専用のメソッドである。「構造」とは、アスペクトのデータを表す属性の集合である。「関係」とは、ソースのオブジェクトとターゲットアスペクトとの間の関係である。サービスモジュールグループは、サービスモジュールに関連付けられており、アスペクト、関係、およびクエリの集合である。アスペクトグループは、アスペクトに関連付けられており、関係、アスペクトアクション、およびフィールド記述子86の集合である。また、リポジトリ18内のメタデータは、使用可能なバックエンド(バックエンドデータベース24など)に含まれる各アスペクト、クエリ、キー、アクション、構造、関係、サービスモジュールグループ、およびアスペクトグループのテキストの記述も含む。そのため、リポジトリ18内のメタデータの編成は、こうしたデータ型(例えばアスペクト、クエリ、キー、アクション、構造、関係、サービスモジュールグループ、およびアスペクトグループ)の観点から記述することができる。
アスペクト、クエリ、キー、およびアクションの属性についてのデータモデルは、構造記述子74に基づく。一例では、各アスペクトは、アスペクトのデータ属性を定義する1つの構造記述子74を有する。構造記述子74は、リポジトリ18内のデータ辞書を参照する。データ辞書は、プログラマ、および構造記述子を参照する必要がある人のための、データモデル内のデータオブジェクトまたは項目の記述子のコレクションである。構造記述子74は、XMLスキーマ、またはリポジトリ18内の1つまたは複数のデータベーステーブルで定義することができる。
一例では、リポジトリ18で定義された構造記述子74は、データベーステーブルのフラット構造を含む。フラット構造とは、実数、整数、文字列、ブール値などの単純な値型(simple value types)の属性名とフィールド記述子86との対のシーケンスである。例えば、2次元のある点を定義する構造記述子74は、リスト{X,real,Y,real}とすることができ、この場合、XおよびYは実数値を有する属性名である。
リポジトリ18の別の例では、構造記述子74は、他の構造記述子74のネスティングおよびコレクションを含み得る。より大きいアスペクトの生成を可能にするために他の構造記述子74またはサブ構造をネストすることは、より小さいアスペクトを定義するサブ構造についてのキーの使用がわからないときに有用である。
フロントエンドアプリケーションプログラム12がサービスマネージャ16を介してサービスプロバイダ26からのデータ(バックエンドデータベース24に格納されているデータなど)にアクセスするために、ビジネスオブジェクトクラスのインスタンスは、例えば注文番号や製品のIDなど、サービスモジュール内の一意のキーによって識別される。サービスモジュール内の様々なアスペクトについての様々なタイプのキーを区別するために、キー記述子64は様々なタイプのキーを定義する。キー記述子64は、複数のデータ属性を含むことができる構造記述子74に関連付けられる。一例では、各キーは、文字列属性を有する。サービスモジュールを、様々なアスペクトについての様々なキー記述子64に関連付けることができる。例えば、注文キーは、注文品目キーとして別のキー記述子64を有していてもよい。
サービスモジュール記述子54は、アスペクト記述子56のコレクションを含む。アスペクト記述子56は、1つの構造記述子74および1つのキー記述子64を参照する。構造記述子74は、対応するキー記述子64のすべてのキー属性を含む。キー記述子64は、専用のアスペクト記述子56である。あるキーのキー記述子64の属性は、自己参照としてそれ自体を参照する。簡単な販売注文サービスモジュール内のアスペクト記述子56の例は、Order、Order Detail、Shipping Address、Billing Address、Order Item、およびOrder IDやOrder Item Keyなどのキーアスペクトの記述子を含み得る。サービスモジュール記述子54は、サポートされているアスペクト記述子56のコレクションを指定する。複数のサービスモジュール記述子54は、同じアスペクト記述子56に関連付けることができる。
アスペクト記述子56は、関係記述子84によって指定され、相互に関連する。関係記述子84は、1つのソースアスペクト記述子56および1つのターゲットアスペクト記述子56を有する。この意味では、関係記述子84は有向である。関係記述子84は、オプションの基数(1...nなど)およびカテゴリも有する。サポートされているカテゴリは、例えば、親−子または子−親などである。
ソースアスペクトAとターゲットアスペクトBとの間の関係を定義する関係記述子84は、アスペクトAのインスタンスからアスペクトBのインスタンスへのトラバースが可能であることを意味する。例えば、アスペクトAとBがリレーショナルデータベーステーブルとしてバックエンドデータベース24に実装されていると仮定すると、これは、アスペクトAに対応するテーブル内の1つまたは複数のフィールドが、アスペクトBに対応するテーブルの主キーを指すことを意味する。ソースアスペクトAおよびターゲットアスペクトBから親−子関係を定義する関係記述子84は、アスペクトBがアスペクトAの存在に依存することを意味する。例えば、アスペクトAおよびBがリレーショナルデータベーステーブルとしてバックエンドデータベース24に実装されていると仮定すると、これは、アスペクトBに対応するテーブルの主キーがアスペクトAに対応するテーブルから導出されることを意味する。関係記述子84は、例えば、販売注文サービスモジュール内の注文から届け先住所(基数1...1)または注文品目(基数1...n)など、同じサービスモジュール内のあるアスペクトから別のアスペクトへの内部ナビゲーションを記述するために導入される。関係記述子84は、サービスモジュールに依存しておらず、様々なサービスモジュールによって再利用することができる。バックエンドデータベース24内のあるデータ型から別のデータ型への内部ナビゲーションまたはトラバースの場合、ソースアスペクト記述子56の可視の(使用可能な)関係記述子は、サービスモジュール記述子54によって定義され、サービスモジュール記述子は、サポートされている関係記述子84のリストを有している。ナビゲーションは、サービスモジュール記述子54によってもサポートされているターゲットアスペクト記述子56を有する、サポートされている関係記述子84について許容される。
バックエンドデータベース24内のデータ型にアクセスし、それに作用する操作は、操作記述子70において記述される。構造記述子74は、操作記述子70の入力パラメータを定義する。この構造記述子74は、一括(mass)およびフィルタ操作を可能にする入力キー記述子64も含む。一括操作とは、バックエンドデータベース24内のデータ型の複数のインスタンスに対するフロントエンドアプリケーションプログラム12によって指定された操作である。フィルタ操作は、入力キー記述子によって定義されるキーによって、クエリなどの操作の結果をフィルタ処理する。操作記述子70の入力パラメータはオプションである。
操作記述子70のタイプは3つある。すなわち、クエリ記述子104、アスペクトアクション記述子92、およびアクション記述子96である。上記のコマンド、QueryおよびExecuteのアクションは、操作記述子70によって定義される。
クエリ記述子104は、サービスモジュール内のアスペクトのインスタンスについての検索を可能にするクエリメソッドを記述する。クエリ記述子104は、入力パラメータ、入力キー記述子64、および結果アスペクト記述子56を含む。入力パラメータは、クエリの検索パラメータ構造を定義する構造記述子74である。入力キー記述子64は、どのキーをフィルタリングに使用することができるかを定義する。例えば、クエリ記述子104によって定義されたクエリをフィルタリングキーで実行すると、第1の入力の基準を満たすキーのリストがもたらされる。キーのこのリストは、キーのリストの一部を戻すことができるように、入力キー記述子64の1組のフィルタリングキーによってフィルタ処理される。クエリ記述子104についての結果アスペクト記述子56は、クエリの結果のタイプを指定し、サービスモジュールに関連付けられている任意のアスペクト記述子56とすることができる。
各サービスモジュール記述子54は、1組のサポートされているクエリ記述子104を有する。クエリ記述子104は、1つのサービスモジュール記述子54に属しているため、サービスモジュール記述子54は、他のサービスモジュール記述子54で定義されたクエリ記述子104を使用することができない。
アスペクトは、アスペクトアクション記述子92によって記述されているアクションの形で、(標準操作の選択、挿入、更新、削除、関係による選択、フィールドの更新以外の)追加の操作を提供する。アスペクトアクション記述子92は、アスペクトへの専用の操作記述子70である。アスペクト記述子56は、1組のサポートされているアスペクトアクション記述子92を有することができる。アスペクト記述子56についての入力パラメータは、アクションのパラメータ構造を定義する。入力キー記述子64は、一括操作にどのキーを使用することができるかを指定する。例えば、電子メールアクションは、複数の電子メールを表すキーのリストを入力として有し得る。
アクション記述子96は、Print、Email、Fax、Approve、Clear、Cut、Copy、Paste、およびCancelなどの複数のアクションの動作を定義することができる。しかし、1つまたは2、3のアスペクトにしか使用できない、よりアスペクト固有のアクションもあり得る。アクション記述子96は、再利用を実施するために導入される。各アスペクトアクション記述子92は、名前および意味(テキストの記述)が定義されるアクション記述子96に関連付けられている。
アクション記述子96は、名前およびアクションの意味(テキストの記述)を指定する。アクション記述子は、パラメータを指定せず、操作の多様な挙動の記述には使用されない。これらは、分類のために使用することができる。
サービスモジュールグループ記述子58は、アスペクト記述子56、関係記述子84、およびクエリ記述子104に関連付けることができる。アスペクトグループ記述子78は、関係記述子84、アスペクトアクション記述子92、およびフィールド記述子86に関連付けることができる。
アスペクトの複数のインスタンスをサービスモジュールの複数のインスタンスに関連付けることができるため、クラス図50は、サービスモジュール記述子54とアスペクト記述子56との間のゼロ以上−ゼロ以上の関係(a zero or more to zero or more relationship)52を含む。いくつかのアスペクトを1つのサービスモジュールグループ内にまとめることができるため、サービスモジュールグループ記述子58は、アスペクト記述子56へのゼロ以上−ゼロ以上の有向関係(directed relation)60を有する。いくつかのサービスモジュールグループを1つのサービスモジュール内に集約することができるため、サービスモジュールグループ記述子58は、サービスモジュール記述子54とのゼロ以上−1の合成集約関係62も有する。キー記述子64は、アスペクト記述子56の特殊化(specialization)として、アスペクト記述子56との継承関係66を有する。各アスペクトは、アスペクトのインスタンスを一意に識別するために、そのアスペクトに関連付けられたキーを有しているため、キー記述子64は、アスペクト記述子56との1−ゼロ以上の関係68も有する。操作は入力キーを含むことができるため、操作記述子70は、キー記述子64とのゼロ以上−ゼロ以上の有向関係72を有する。各アスペクト記述子56はその属性を定義する構造記述子74を有することができるため、アスペクト記述子56は、構造記述子74とのゼロ以上−1の関係76を有する。アスペクトはアスペクトグループの集約とすることができるため、アスペクトグループ記述子78は、アスペクト記述子56とのゼロ以上−1の合成集約関係80を有する。アスペクトグループは関係も含むため、アスペクトグループ記述子78は、関係記述子84とのゼロ以上−ゼロ以上の有向関係82も有する。1つの構造は、それ自体を定義するために多くのデータフィールドを使用することができるため、構造記述子74は、フィールド記述子86との1−ゼロ以上の所有関係90を有する。アスペクトグループ記述子78は、フィールド記述子86とのゼロ以上−ゼロ以上の関係88も有する。
アスペクトはアスペクト上で実行することができるアクションを提供することができるため、アスペクトアクション記述子92は、アスペクト記述子56とのゼロ以上−1の集約関係100を有する。アスペクトアクション記述子92は、その上位クラスの操作記述子70との継承関係102を有する。クエリ記述子104も、その上位クラスの操作記述子70との継承関係106を有する。サービスモジュールはゼロ以上のクエリを含むことができるため、サービスモジュール記述子54は、クエリ記述子104との1−ゼロ以上の関係108を有する。いくつかのクエリを1つのサービスモジュールグループ内にまとめることができるため、サービスモジュールグループ記述子58は、クエリ記述子104とのゼロ以上−ゼロ以上の有向関係110を有する。
各操作は構造の形の入力パラメータを含むため、操作記述子70は、構造記述子74とのゼロ以上−ゼロまたは1の関係112を有する。クエリは結果として得られたアスペクトを含むため、クエリ記述子104は、アスペクト記述子56とのゼロ以上−ゼロまたは1の関係114を有する。関係はソースおよびターゲットのアスペクトを有するため、関係記述子84は、アスペクト記述56とのゼロ以上−1の関係116および118を有する。
リポジトリ18内のメタデータの編成を定義するこれらの記述子を例示するために、以下の例では、一定の組のリレーショナルデータベーステーブルを使用する。他の永続機構(persistence mechanism)(XMLなど)を使用することもできる。リレーショナルデータベーステーブルは、テーブル1〜6内で定義されており、テーブル1〜6の各行は、リレーショナルデータベーステーブルのフィールドまたは列を定義する。リポジトリ18の主なデータ型はアスペクトである。アスペクトを記述するデータベーステーブルは、テーブル1、SCOL_ASPECT、およびテーブル2、SCOL_ASP_ACTIONである。テーブル1は、アスペクトのプロパティの記述を含む。テーブル1、SCOL_ASPECTのキーフィールドは、ASPECT_NAMEフィールドである。というのは、アスペクトの名前はアスペクトに一意であるからである。ASPECT_CATEGORYフィールドは、アスペクトが非キーアスペクトを表すか、キーアスペクトを表すかを示す。STRUCTUREフィールドは、アスペクトのデータ属性についてのデータ構造名を示す。KEY_ASPECTフィールド内にキーの名前を入れることによって、そのキーがアスペクトに関連付けられる。SERVICE_PROVIDERフィールドは、アスペクトのアスペクトサービスプロバイダ34を定義する。TRANSAC_PROVIDERフィールドは、アスペクトのトランザクションサービスプロバイダ40を定義する。LOCKING_PROVIDERフィールドは、アスペクトのロッキングサービスプロバイダ42を定義する。また、リポジトリ18は、アスペクトの記述についての対応するテーブルを有することができる。
アスペクトは、アスペクト上で実行できるアクションを提供することができる。アクションの記述は、テーブル2、SCOL_ASP_ACTIONに格納される。アクションは、アスペクト名およびアクションの名前によって一意に示されるため、ASPECT_NAMEフィールドおよびACTION_NAMEフィールドは、SCOL_ASP_ACTIONテーブルのキーフィールドである。フィールドPARAM_STRUCTUREは、アクションの入力データパラメータを保持するデータ構造を示す。フィールドINPUT_KEY_ASPECTは、リポジトリ18内のデータ型のどのインスタンスがアクションによって作用されるかを指定するために使用されるキーのタイプを定義するキーアスペクトの名前を示す。フィールドPROVIDER_CLASSは、ASPECT_NAMEフィールドで指定されたアスペクトを実装するサービスプロバイダからアクションを提供するアクションサービスプロバイダの名前を示す。
アスペクトは、互いに関連付けることができる。アスペクト間の関係の記述は、テーブル3、SCOL_RELATIONに格納される。関係は、その名前によって一意に定義されるため、リレーションテーブルのキーは、フィールドRELATION_NAMEで指定されるリレーション名である。関係ごとに、フィールドSOURCE_ASPECTは、有向関係のソースであるアスペクトを定義し、フィールドTARGET_ASPECTは、有向関係のターゲットであるアスペクトを定義し、フィールドTARGET_PROVIDERは、ターゲットアスペクトのクエリ関係サービスプロバイダを定義し、フィールドREL_PARAM_TYPEは、関係のタイプ(親−子または子−親)を定義し、フィールドREL_PARAMETERは、関係の基数(cardinality)を定義する。また、リポジトリ18は、関係の記述についての対応するテーブルを有することができる。
サービスモジュールのプロパティは、テーブル4、SCOL_SVC_MODULEに格納される。各サービスモジュールは、その名前によって一意に記述されるため、SVC_MODULE_NAMEフィールドは、SCOL_SVC_MODULEテーブルのキーフィールドである。サービスモジュールごとに、フィールドTRANSAC_PROVIDERは、サービスモジュールのトランザクションプロバイダ40の名前を指定する。また、リポジトリ18は、サービスモジュールの記述についての対応するテーブルを有する。
すべてのサービスモジュールは、サービスモジュール内で使用できるアスペクトに関連付けられている。各サービスモジュール内で使用できるアスペクトの名前は、テーブル5、SCOL_ASPECT_USEに格納される。各アスペクト−サービスモジュールの使用は、サービスモジュールの名前およびアスペクトの名前によって一意に記述されるため、フィールドSVC_MODULE_NAMEおよびASPECT_NAMEは、SCOL_ASPECT_USEテーブルのキーである。
サービスモジュールは、データを取り出すためにクエリを提供することができる。サービスモジュールのクエリの記述は、以下のテーブル6に示したテーブルSCOL_QUERYに格納される。データベーステーブルの構造は、テーブル6で定義される。各クエリは、サービスモジュールおよびクエリ名によって一意に定義されるため、フィールドSVC_MODULE_NAMEおよびQUERY_NAMEは、SCOL_QUERYテーブルのキーフィールドである。他のフィールドは、クエリによって戻されるデータ型を定義するアスペクトの名前を指定するRESULT_ASPECT、およびクエリの入力パラメータを含むデータ構造を指定するPARAM_STRUCTUREを含む。例えば、サービスモジュールに関連付けられている(例えばフィールドRESULT_ASPECTで指定される)特定のアスペクトに対して行われるクエリは、特定のアスペクトのインスタンスの属性と一致する入力パラメータを含むことができ、一致するインスタンスがこうしたインスタンスを参照するキーのデータセットとして戻される。フィールドINPUT_KEY_ASPECTは、クエリのフィルタとして使用することができるキーを記述するキーアスペクトを定義するために使用される。PROVIDER_CLASSは、各クエリに関連付けられているクエリサービスプロバイダ32の名前を指定する。また、リポジトリ18は、クエリの記述についての対応するテーブルを有する。
上述したように、アーキテクチャ38は、リポジトリサービスプロバイダクラス30によって扱われるリポジトリ18へのメタデータの要求以外に、フロントエンドアプリケーションプログラム12からの要求を扱うための6つのサービスプロバイダクラス(すなわちトランザクション40、クエリ32、アスペクト34、アクション44、クエリ関係46、およびロック42)を含む。フロントエンドアプリケーションプログラム12によって要求されると、サービスを提供するために、サービスマネージャ16は、サービスプロバイダクラスのインスタンスを直接呼び出す。サービスプロバイダクラスのこれらのインスタンスは、サービスマネージャ16と同じコンピュータ(例えば6)、または異なるコンピュータに配置することができる。
ロッキングサービスプロバイダ42は、単一のアスペクトまたは1組のアスペクトについての汎用のロックマネージャを実施するために使用することができる。各ロッキングサービスプロバイダ42は、アスペクトに登録する必要がある。ロッキングサービスプロバイダ42の名前は、アスペクトごとにSCOL_ASPECTテーブルのLOCKING_PROVIDERフィールドで設定される。ロッキングサービスプロバイダクラスは、サービスマネージャ16によって呼び出すことができる2つのメソッドを有する。これらは、LOCKおよびUNLOCKである。LOCKは、入力として、ロックすべきビジネスオブジェクトを表すキーのコレクション、ビジネスオブジェクトのクラスを表すアスペクトの名前、およびロックモードを取得する。ターゲットシステムのロッキング機能に応じて、様々なロックモードがある。ロックモードは、「E」、「S」、または「SP」を指定することができる。「E」は、排他的ロック、すなわち1つのクライアントのみがロックを得ることができることを意味する。「S」は、任意のクライアントがロックすることができ、1つのクライアントに専用のロックはできないことを示す共有ロックを意味する。「SP」は、「S」と同じであるが、排他的ロックへのその後のアップグレードが可能であることを意味する。
LOCKメソッドは、要求が拒否されたかどうかを示すブール値を出力し、また戻りコードも出力する。UNLOCKは、ロック解除すべきビジネスオブジェクトを表すキーのコレクション、およびロック解除すべきビジネスオブジェクトのクラスを表すアスペクトの名前を入力として取得する。UNLOCKメソッドも、要求が拒否されたかどうかを示すブール値および戻りコードを出力する。トランザクションバッファがすでに「ダーティ」な状態にある場合、すなわち、最後のCLEANUP呼び出し以降、任意の更新、挿入、削除操作、またはCOL_AFFECTS_NOTHINGとしてマークされていないアクションが発行された場合、UNLOCKへの呼び出しは拒否される。トランザクションサービスプロバイダクラスのCLEANUPメソッド(後述する)が「END」の理由で呼び出される場合、すべてのロックが削除される。
トランザクションとは、情報交換および関連の作業(データベースの更新など)のシーケンスであり、フロントエンドアプリケーションプログラム12からサービスマネージャ16への要求を満たすため、またバックエンドデータベース24の保全性を確実にするための一単位として扱われる。トランザクションを終了させ、データベース24への変更を永続的にするために、トランザクションを全部完了させる必要がある。トランザクションが成功し、データベースが要求された変更のすべてを反映するように実際に変更される前に、トランザクションのすべてのステップが終了される。トランザクションが正常に終了する前に何か起こった場合、変更を元に戻すことができるように、バックエンドデータベース24への任意の変更を追跡する必要がある。
トランザクションを扱うために、トランザクションサービスプロバイダ40は、サービスマネージャ16、別の非トランザクションサービスプロバイダ(32、34、44、46など)、およびフロントエンドアプリケーションプログラム12(または場合によってはサービスマネージャプロキシ14)の間のトランザクションの様々な状態に関する通知を受信する。この通知は、トランザクション中にサービスマネージャ16によって呼び出される、トランザクションサービスプロバイダ40のメソッドBEFORE_SAVE、CLEANUP、およびSAVEである。
サービスマネージャ16は、トランザクションバッファを保存することができるかどうかをチェックするために、トランザクションサービスプロバイダ40のメソッドBEFORE_SAVEを呼び出す。これによって、非トランザクションサービスプロバイダの内部状態が保存の準備ができているかどうかをチェックすることができる。メソッドBEFORE_SAVEは、トランザクションバッファを保存することができない場合、falseを戻し、トランザクションの終了が中断される。したがって、BEFORE_SAVEメソッドは、BOOLEAN戻りパラメータを有する。BEFORE_SAVEは、ブール値を入力パラメータREJECTEDとして取得する。トランザクションサービスプロバイダ16は、REJECTパラメータを非初期値、すなわち「true」に設定することによって、次の保存操作およびコミット操作を防ぐことができる。メソッドBEFORE_SAVEは、フロントエンドアプリケーション12のSAVEメソッドによってトリガされるサービスマネージャ16の操作のシーケンス内に呼び出される。
SAVEメソッドは、最終的にアプリケーションをトリガして、トランザクションバッファをデータベース24に保存させる。SAVEを呼び出すことによって、非トランザクションサービスプロバイダのすべての内部状態を、直接の更新、または更新タスクへの適切な呼び出しの作成のいずれかによって永続的にする。アーキテクチャ38内のすべてのサービスプロバイダがSAVE要求を受信した場合、サービスマネージャ16は、トランザクションをコミットする。
CLEANUPメソッドは、すべての非トランザクションサービスプロバイダに、すべてのトランザクションバッファ、およびエンキューベースのロックを解放するよう伝える。CLEANUPメソッドの呼び出しは、アーキテクチャ38内のすべてのサービスプロバイダがその内部状態をクリーンアップする必要があることを伝える。CLEANUPは、REASON文字列を入力パラメータとして取得する。REASONフィールドは、クリーンアップ操作の理由を示す。これは、SAVE操作のための「COMMIT」、またはシステムがトランザクションを自動的に終了することによるトランザクションの「END」のいずれかであり得る。障害状態下でCLEANUPが呼び出される保証はない。
アクションサービスプロバイダ44は、アスペクトのアクションを実行するために、サービスマネージャ16によって呼び出される。アクションサービスプロバイダ44の名前は、SCOL_ASP_ACTIONテーブルのPROVIDER_CLASSフィールドのアクションに対応する行に設定される。アクションサービスプロバイダ44は、1つのメソッドEXECUTEを有する。EXECUTEメソッドは、アスペクト名(ASPECT)、アスペクトのどのインスタンスがアクションによって作用されるかを指定する1組のキー(INKEYS)、汎用入力パラメータ(INPARAM)、実行すべきアクションの名前(ACTION)、関係に作用するアクションの1組のキー(RELATION_INKEY)、および関係の名前(RELATION)を入力パラメータとして取得する。EXECUTEメソッドは、アクションによって修正された、変更済みのまたは新しく作成されたオブジェクト(OUTRECORDS)を出力パラメータとして戻す。OUTRECORDSパラメータによって戻されたオブジェクトは、クライアントフレームワークにおける呼び出し側のアスペクトオブジェクトに戻される。
アスペクトサービスプロバイダ34は、サービスマネージャ16によって呼び出され、1つまたは複数のアスペクトの内容を読み取り、変更するための機能を提供する。上述したように、アスペクトは、その名前(名前はリポジトリ内でグローバルに一意である)、関連のデータ構造、関連のキー(すなわち識別子)構造、1組の実施されたアクション、1組の外向きの関係(outgoing relation)、および1組の内向きの関係(incoming relation)によって記述される。アスペクトサービスプロバイダ34は、メソッドEXECUTE、SELECT、INSERT、UPDATE、DELETE、SELECT_BY_RELATION、およびUPDATE_FIELDSを有する。
メソッドEXECUTEは、アクションサービスプロバイダ44から導出され、アクションの実行を可能にする。EXECUTEは、アクションが実行されるアスペクトの名前(ASPECT)、アクションが実行されるオブジェクトのキー(INKEYS)、アクションのパラメータ(INPARAM)、アクションの名前(ACTION)を入力パラメータとして有する。戻されたパラメータは、変更された、または作成されたアスペクト行(OUTRECORDS)、メソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
メソッドSELECTは、所与のアスペクトについて、入力キーに関連付けられているアスペクトデータを読み取る。SELECTは、読み取るアスペクト行を記述するために関連のキー構造内でエンコードされたキーのリスト(INKEY)、およびアスペクトの名前(ASPECT)を入力パラメータとして有する。SELECTは、アスペクトデータ構造でエンコードされた結果(OUTRECORDS)、メソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を出力パラメータとして有する。
メソッドINSERTは、新しいデータをアスペクトに挿入する。アスペクトが行ごとの書き込み操作(INRECORDS)用に設計されている場合、INSERTは、挿入すべきレコードを含むテーブルを入力パラメータとして含んでいる。このメソッドによって、アスペクトの記述に応じて(例えばパラメータExternalKeys=trueまたはfalse)、挿入されたレコードは、キーフィールドを定義することもできる。入力パラメータは、アスペクトの名前(ASPECT)、関係に作用するアクションの1組のキー(RELATION_INKEY)、および関係の名前(RELATION)も含む。メソッドINSERTは、挿入されたレコードを表す1組のレコード(OUTRECORDS)を、そのキー、およびアスペクトサービスプロバイダ34が挿入されたレコードにおいて行いたい他の可能な変更とともに戻す。例えば、変更の1つとして、その1組のレコードの算出されたフィールドを記入することが可能である。OUTRECORDS行の順序は、INRECORDS行の順序に対応していなければならない。他の出力パラメータは、SELECTメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
UPDATEメソッドは、レコードごとまたはフィールドごとにアスペクトの既存のインスタンスを更新する。アスペクトが行ごとの書き込み操作用に設計されている場合、UPDATEメソッドの入力パラメータは、更新すべきインスタンスキーを含むテーブル(INRECORDS)を含む。入力パラメータは、アスペクトの名前(ASPECT)も含む。UPDATEメソッドによって戻されたパラメータは、更新されたレコード(OUTRECORDS)を、そのキー、およびサービスプロバイダが行いたい他の可能な変更とともに含む。OUTRECORDS行の順序は、INRECORDS行の順序に対応させることができる。他の出力パラメータは、SELECTメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
DELETEメソッドは、(バックエンドデータベース24など)バックエンド内のアスペクトの行またはインスタンスを削除する。DELETEメソッドの入力パラメータは、削除すべきアスペクト行を記述するために関連のキー構造内でエンコードされたキーのリスト(INKEY)、およびアスペクトの名前(ASPECT)である。DELETEメソッドによって戻されたパラメータは、DELETEメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
SELECT_BY_RELATIONメソッドは、関係のパラメータの記述に応じて、関係に従うか、または別のアスペクトに従うか、いずれかの属性を戻し、このソースアスペクトは、その別のアスペクトを指す関係を有する。SELECT_BY_RELATIONの入力パラメータは、従うべき関係の名前(RELATION)、ソースアスペクトのレコード(INRECORDS)、ソースアスペクトの名前(ASPECT)、およびページングなどのクエリの様々なオプションを記述する構造(OPTIONS)である。SELECT_BY_RELATIONによって戻された出力パラメータは、ターゲットアスペクトデータ構造(OUTRECORDS)でエンコードされた結果、OUTRECORDSパラメータのどの行がどのINRECORDS行(INDEX)に属しているかを示すインデックステーブル、結果の記述(DESCRIPTION)、SELECT_BY_RELATIONメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
UPDATE_FIELDSメソッドは、アスペクトのインスタンスのフィールドを更新する。入力パラメータは、更新すべきアスペクトのインスタンスを記述するために関連のキー構造内でエンコードされたキーのリスト(INRECORDS)を含む。アスペクトが、フィールドごとの書き込み操作用に設計されている場合、入力パラメータは、1組のレコード内の更新すべきフィールドの名前および対応する値の対を含むテーブル(INFIELDS)も含む。アスペクトの複数のインスタンスを更新すべきである場合、追加のフィールドインデックスINKEYは、関連のキーレコードを指す。入力パラメータは、アスペクトの名前(ASPECT)も含む。UPDATE_FIELDSによって戻されたパラメータは、アスペクトの作成されたまたは変更されたインスタンス(OUTRECORDS)を、そのキー、およびアスペクトサービスプロバイダ34によって実行された他の可能な変更とともに含む。様々なOUTRECORDS行のインデックスは、INFIELDSテーブル内の行インデックスに関連付けられる必要がある。戻された他のパラメータは、UPDATE_FIELDSメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
クエリサービスプロバイダ32は、クエリを実行する。リポジトリ18内のクエリは、テーブルSCOL_QUERYにおいて、フィールドQUERY_NAMEのクエリ名、フィールドPARAM_STRUCTUREの関連のパラメータ構造、フィールドRESULT_ASPECTの関連の結果アスペクト、およびオプションで、フィールドINPUT_KEY_ASPECTのその一意のデータ構造を備える関連のアスペクトキーによって記述されている。クエリサービスプロバイダ32は、1つまたは複数のアスペクトに対するクエリを実行する1つのEXECUTEメソッドを有する。入力パラメータは、クエリの名前(QUERY)、クエリのパラメータを含むデータ構造(INPARAM)、およびクエリを制限すべきアスペクト行のキーを含むオプションのテーブル型パラメータ(INKEYS)を含む。INKEYSは、EXECUTEメソッドによって戻されるOUTRECORDSのキーで構成することはできるが、必須ではない。INKEYSは、任意のキーアスペクト構造のものとすることができる。どのキー構造がクエリに関連付けられるかは、リポジトリ18内のテーブルSCOL_QUERY内のフィールドINPUT_KEY_ASPECTで指定される。オプションで、(ページングのためなど)クエリの様々なオプション(OPTIONS)およびSELECTIONSを記述する構造を含めて、他の入力パラメータを指定することができる。
EXECUTEメソッドによって戻されたパラメータは、クエリの記述(DESCRIPTION)、クエリ結果(OUTRECORDS)、およびEXECUTEメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)を含む。
EXECUTEメソッドは、クエリパラメータによって指定された結果を戻す。INKEYSテーブルパラメータが空ではない場合、結果は、クエリパラメータを満たすオブジェクトに制限される。INKEYSおよびINPARAMは、いずれもクエリを制限するが、様々な方法で使用される。例えば、まだ配送されていない注文のリストを戻すクエリを定義することができる。こうした例では、構造INPARAMは、A〜Dの姓の付いた顧客からの注文のみを戻すように指定することができる。INKEYSは、まだ配送されていないすべての注文のテーブルである。OUTRECORDSは、まだ配送されていない、この場合A〜Dの姓を持つ関連の顧客からのすべての注文を含む。一例では、クエリのOUTRECORDS結果は、切断された(disconnected)アスペクトであり、すなわちアスペクトは常に読み取り専用である。このアスペクトに対してそれ以上のバックエンド操作を実行することはできない。この例では、受信されたキーは、アスペクトサービスプロバイダ34、および例えばそのSELECTメソッドを使用して、他のアスペクト行を選択するためのパラメータとして使用することができる。
クエリ関係サービスプロバイダ46は、関係のターゲットであるアスペクトのサービスプロバイダ(アスペクトサービスプロバイダ34など)においてルーチンを実施する。関係がSOURCE_KEYSまたはATTRIBUTESとマーク付けされている場合、クエリ関係サービスプロバイダ46のメソッドは、ソースアスペクトのアスペクトサービスプロバイダ34から間接的に呼び出される。
クエリ関係サービスプロバイダ46は、SELECT_TARGETメソッドを有する。メソッドSELECT_TARGETは、次のように入力パラメータを有する。入力パラメータは、ソースアスペクトの名前(SOURCE_ASPECT)を含む。オプションで、メソッドは、ターゲットアスペクトのSELECTメソッドへのプロキシインターフェイス(TARGET)を定義する入力パラメータも含む。TARGETパラメータを指定することによって、ターゲットアスペクトのアスペクトサービスプロバイダ34を直接知ることなく、ターゲットアスペクトのアスペクトサービスプロバイダ34のSELECTメソッドを呼び出すことができる。これによって、ターゲットアスペクトのアスペクトサービスプロバイダ34の知識無しに、クエリ関係サービスプロバイダ46をサービスモジュールに追加することができる。
SELECT_TARGETメソッドの別の入力パラメータは、関係(RELATION)である。別の入力パラメータは、関係を記述するためのフィールドのテーブル(INPARAMS)である。一括選択を可能にするために、INPARAMSは、すべての行が単一の選択を記述するテーブルである。INDEXパラメータは、INPARAMS構造の様々な行をOUTRECORDS行に関連付けるために使用される。別のオプションの入力パラメータは、(ページングなど)クエリの様々なオプションを記述する構造(OPTIONS)である。
SELECT_TARGETメソッドは、ターゲットアスペクトの構造(OUTRECORDS)でエンコードされた結果、クエリ結果の記述(DESCRIPTION)、およびターゲットアスペクトSELECTメソッドへのプロキシインターフェイスを含む、パラメータを戻す。他の出力パラメータは、INPARAMSレコードとOUTRECORDSパラメータとの間の関係を記述するインデックス(INDEX)、SELECT_TARGETメソッドの要求が拒否されたかどうかを示すブールフラグ(REJECTED)、および戻りコード(RETURN_CODES)を含む。
サービスプロバイダ32、34、40、42、44、および46は、上述したように、アーキテクチャ38の次のトランザクションモデルを実行可能にする。アスペクトサービスプロバイダ34のメソッドSELECTを実行することによって、バックエンドデータベース24から読み取る、またはバックエンドに格納されているトランザクションバッファから読み取る。アスペクトサービスプロバイダ34は、マージデータがこのトランザクションにおいてそれまでに行われた更新を反映するように、一貫した方法で、両方のソース、つまりデータベースおよびそのトランザクションバッファからのデータをマージする。次に、アスペクトサービスプロバイダ34のUPDATE、INSERT、MODIFY、DELETEのメソッドを実行することによって、トランザクションバッファが増加する。トランザクションバッファ内のデータを実際に変更する前に、サービスマネージャ16は、データに対するトランザクションロックを取得し、ロックの保護下でデータを読み取る必要がある。上述したように、ロッキングサービスプロバイダ42を使用して利用可能な排他的、共有、および共有プロモート可能(shared promotable)のロックモードがある。ロックには、ロックの保護下で、ロックされたデータを再度選択することが伴わなければならない。アプリケーションは、タイムスタンプが押されたデータ、またはそうでなければバージョン付きのデータを提供し、競合の場合にフロントエンドにおいて実際のデータと変更されたデータとをマージすることによって、楽観的ロックキング(optimistic locking)をサポートすることができる。
トランザクションサービスプロバイダ40のBEFORE_SAVEメソッドによって、参加しているすべてのサービスプロバイダがトランザクションバッファを保存する用意ができているかどうかを宣言することができる。トランザクションサービスプロバイダ40のSAVEメソッドは、最終的に、サービスマネージャ16をトリガして、トランザクションバッファをバックエンドデータベース24に保存させる。
トランザクションサービスプロバイダ40のCLEANUPメソッドは、すべてのそのトランザクションバッファおよびエンキューベースのロックを解放することをすべてのサービスプロバイダ(アスペクトサービスプロバイダ34など)に通知する。CLEANUPが「END」の理由で呼び出された場合、すべてのロックは解放されなければならない。理由が「COMMIT」に設定されている場合、各サービスプロバイダは、そのロックを維持することを選択することができる。アスペクトサービスプロバイダ34は、COMMIT WORKまたはROLLBACK WORKをそれ自体で内部で呼び出してはならない。サービスマネージャ16は、アスペクトサービスプロバイダ34がトランザクションをコミットしようとしている場合、トランザクションを自動的に中断することによってこれを実施する。
サポートされているロッキングモデルおよびロックポリシーは、次の通りである。ポリシーSを使用すると、多くの参加者が共有ロックを取得することができる。あるオブジェクトにおいて共有ロックが取得されると、非排他的ロックまたはSPロックを取得することができる。共有ロックは、読み取り操作中により大きいデータセットにおける一貫したビューを達成するために使用することができるだけである。ポリシーEを使用すると、単一の参加者だけがロックを取得することができる。ポリシーSP(共有プロモート可能)を使用すると、多くの参加者がロックを取得することができる。SPロックが存在している場合、排他的ロックは、そのオブジェクトにすでにSPロックを有している参加者によって取得されるだけである。参加者のうちの1人だけが、ロックを排他的ロックにアップグレードすることができる。アップグレード前にロックを取得した他の参加者は、第1の参加者がそのロックを解放した場合でさえ、排他的にアップグレードすることはできない。
(図3の)アーキテクチャ38は、新しい顧客を作成し、GUI28を介して1つまたは複数の製品の顧客の注文を受信し、その注文をビジネスプロセスに送信する簡単なタスクを実施する。この実施例をサポートするために、バックエンドデータベース24は、顧客のリスト、住所、製品タイプ、バスケット、注文ごとのバスケット内の製品の位置(positions)、および注文を定義するために、上記のテーブル1〜6の定義に従って設計されたリレーショナルデータベースを使用して実施することができる。テーブル7〜12では、キーフィールドの見出しをアスタリスクで示している。顧客テーブル7は、顧客を定義し、各顧客は、CustomerIdフィールドによって一意に識別される。顧客テーブル7は、名前フィールド、および住所テーブル内の住所を顧客にリンクする外部キーフィールドAddressIdも含んでいる。
住所テーブル8は、町および通りを有する住所を定義する。Address id自体は、住所の有効な一意のキーであり、住所と顧客との間の接続は、顧客テーブル7(AddressIDフィールド)を介して行われる。
テーブル9は、製品を定義し、名前を有し、キーProductIdを備える。
テーブル10は、ショッピングバスケットを定義し、顧客を有し、キーBasketIdを備える。
テーブル11は、バスケット内の注文の位置を定義し、製品を有する。位置は、バスケットおよび注文の存在に依存するため、位置の主キーは、PositionId、BasketId、およびOrderIdの組み合わせである。
テーブル12は、注文を定義し、顧客を有し、各注文が送信済みかどうかを示し、主キーOrderIdを備える。
図5に示すように、プロセス150は、テーブル7〜12を使用して、この簡単なタスクに必要なバックエンドデータベース24へのデータベース操作を定義する。プロセス150は、フロントエンドアプリケーションプログラム12が顧客の名前を受信すること(152)を含む。プロセス150は、ビジネスソフトウェアアプリケーションが、データベースの顧客テーブル(テーブル7)に対してNAMEフィールドの名前についてのクエリを行うこと(154)を含む。プロセス150は、顧客の名前が顧客テーブル(テーブル7)のある行に一致するかどうかをチェックすること(156)を含む。一致しない場合、プロセス150は、ビジネスソフトウェアアプリケーションが、顧客の住所を取得すること(158)、新しいAddressIDおよび住所についての新しい行を住所テーブル(テーブル8)に挿入すること(160)、および新しいCustomerIdおよびAddressIDについての新しい行を顧客テーブル(テーブル7)に挿入すること(162)を含む。一致する場合、プロセス150は、ビジネスソフトウェアが、その顧客の注文する製品名を取得すること(164)を含む。プロセス150は、ビジネスソフトウェアが製品テーブル(テーブル9)に対して製品名についてのクエリを行うこと(166)を含む。
プロセス150は、製品名が製品テーブル(テーブル9)のある行に一致するかどうかをチェックすること(168)を含む。一致する場合、プロセス150は、ビジネスソフトウェアが、顧客のCustomerIdについての新しい注文を注文テーブル(テーブル12)に挿入すること(170)、および送信済みフィールドを「False」に設定することを含む。そうでない場合、プロセス150は、注文する製品名を取得すること(164)に戻る。プロセス150は、ビジネスソフトウェアが、顧客のCustomerIdについての新しいバスケットをバスケットテーブル(テーブル10)に挿入すること(172)を含む。
プロセス150は、ビジネスソフトウェアが、CustomerId、BasketId、およびProductIdについての新しい位置を位置テーブル(テーブル11)に挿入すること(174)を含む。プロセス150は、ビジネスソフトウェアが注文を送信する旨の要求を受信すること(176)を含む。プロセス150は、ビジネスソフトウェアが、注文テーブル(テーブル12)に対して顧客のCustomerIdでクエリを行うこと(178)を含み、このクエリは、顧客のCustomerIdに一致する注文を戻す。プロセス150は、ビジネスソフトウェアが、注文テーブル(テーブル12)内で、顧客のCustomerIdについての注文に一致する注文を選択すること(180)を含む。プロセス150は、ビジネスソフトウェアが、注文テーブル(テーブル12)内の選択された行の送信済みフィールドを「True」に設定すること(182)を含む。プロセス150は、ビジネスソフトウェアが、顧客テーブル7に対してAddressIdについてのクエリを行い、次いで住所テーブル8に対して一致したAddressIdについてのクエリを行うことによって、注文の配送のために、住所テーブル8から顧客の住所を取得すること(184)を含む。
テーブル13〜19は、テーブル7〜12によって示したデータベース例のメタデータを表すリポジトリ18の一実装形態でのテーブルを示している。テーブル13〜19は、上記のテーブル1〜6の定義に従い、テーブル1〜6の行の定義がテーブル13〜19の列またはフィールドに対応する。テーブル7〜12と同様、テーブル13〜19のキーフィールドは、アスタリスクによってラベル付けされている。
テーブル13は、(テーブル1で定義した)SCOL_ASPECTテーブルの定義に従ってアスペクトA_Customer、A_Address、A_Product、A_Basket、A_Position、およびA_OrderHeaderを定義する。各アスペクトは、各インスタンスに一意のキーを定義する対応するキーアスペクトを有する。例えば、アスペクトA_Customerは、キーアスペクトCustomer_Keyを有する。メタデータリポジトリ18内のこのキーアスペクトは、バックエンドデータベース24内のリレーショナルデータベーステーブルのキーに対応することができる。例えば、顧客テーブル(テーブル7)のキーは、CustomerIdフィールドである。STRUCTUREフィールド内の行は、下記のテーブル19のデータ辞書に対応する。例えば、テーブル19は、文字列を示すタイプCHARのNAMEフィールドを有するようにCustomer_Structureを定義することができる。SERVICE_PROVIDERフィールドの行は、アスペクトのサービスを扱う特定のアスペクトサービスプロバイダに対応する。テーブル13において、アスペクトのすべては、S_providerアスペクトサービスプロバイダ(例えば図3を参照すると34)に割り当てられる。TRANSAC_PROVIDERフィールドの行は、アスペクトのトランザクションを扱う特定のトランザクションサービスプロバイダ40に対応する。テーブル13において、アスペクトのすべては、T_providerトランザクションサービスプロバイダ(例えば図3を参照すると40)に割り当てられる。LOCKING_PROVIDERフィールドの行は、アスペクトのロックを扱う特定のロッキングサービスプロバイダに対応する。テーブル13において、アスペクトのすべては、L_providerロックサービスプロバイダ(例えば図3を参照すると42)に割り当てられる。
テーブル14は、(テーブル2で定義した)SCOL_ASP_ASPECTテーブルの定義に従ってアスペクトA_OrderHeaderのアクションSubmitを定義する。フィールドINPUT_KEY_ASPECTは、アスペクトA_OrderHeaderのどのインスタンスがそのアクションによって作用されるべきかを指定するアクションで、アプリケーション14によって送信されるキーアスペクトを指定する。アクションSubmitは、バックエンドデータベース24内のこうしたインスタンスの送信済みフィールドをTrueに変更する。このアクションSubmitに追加のパラメータは必要ないため、テーブル14のPARAM_STRUCTUREフィールドは空欄である。フィールドPROVIDER_CLASSは、各アクションに割り当てられるアスペクトサービスプロバイダ34(図3を参照)を指定する。テーブル14において、アクションSubmitは、アスペクトサービスプロバイダS_provider(例えば図3を参照すると34)に割り当てられる。
テーブル15は、(テーブル3で定義した)SCOL_RELATIONテーブルの定義に従って、テーブル13で定義されたアスペクト間の関係を定義する。この関係は、テーブル7〜12の例によって示されるバックエンドデータベース24のデータテーブル間の関係を反映する。図6には、アスペクトA_Customer202、アスペクトA_Address204、アスペクトA_Product206、アスペクトA_Basket208、アスペクトA_Position210、およびアスペクトA_OrderHeader212のアスペクト間の関係についても示されている。これらの関係は、R_Customer_To_Address213、R_Basket_To_Customer214、R_OrderHeader_To_Customer216、R_Position_To_Product218、R_Position_To_OrderHeader220、およびR_Position_To_Basket222を含む。
テーブル16は、(テーブル4で定義した)SCOL_SVC_MODULEテーブルの定義に従って、テーブル7〜12において提供されたバックエンドデータベース24の定義例のサービスモジュール例を定義する。テーブル16は、サービスモジュールS_Customer、S_Product、S_Basket、およびS_Orderを定義する。フィールドTRANSAC_PROVIDERは、各サービスモジュールに対するトランザクションサービスプロバイダ40(図3を参照)を指定する。テーブル16において、トランザクションサービスプロバイダT_provider(例えば図3を参照すると40)がサービスモジュールに割り当てられる。
テーブル17は、(テーブル5で定義された)SCOL_ASPECT_USEテーブルの定義に従って、(テーブル16によって提供された)サービスモジュールを(テーブル13によって提供された)アスペクトに関連付ける。
テーブル18は、(テーブル6で定義された)SCOL_QUERYテーブルの定義に従って、図5のビジネスプロセス150を容易にするように設計されたクエリを定義する。例えば、S_Customerサービスモジュールに関連付けられているQueryByNameは、クエリの入力としてCustomer_Structure、およびどのキーをフィルタリングに使用することができるかを定義する1組の顧客キー(Customer_Key)を取得する。フィールドPROVIDER_CLASSは、どのクエリサービスプロバイダ32(図3を参照)が各サービスモジュールに関連付けられるかを指定する。テーブル18において、クエリサービスプロバイダQ_provider(32など)が各サービスモジュールに関連付けられている。
テーブル19は、テーブル13〜18で定義されたリポジトリ18の実装についてのデータ辞書を定義する。各行は、名前を有する構造、並びに複数のデータエントリおよびそのタイプを定義する。例えば、構造Customer_Structureは、「NAME」という名称の1つのデータエントリ、および文字列を示すCHAR型を有する。Customer_Key_Table構造は、顧客ごとにCustomerIdキーを定義し、CHAR型も有する。
プロセス150についての上記のデータベース操作は、リポジトリ18のこの実装において次のように定義される。プロセス150に含まれている、顧客データベーステーブル(テーブル7)のクエリを行うこと(154)は、メタデータリポジトリ18において、テーブル18のアスペクトサービスモジュールS_Customerに関連付けられているQueryByNameクエリによって記述される。アスペクトサービスモジュールS_Customerに関連付けられているこのQueryByNameクエリが選択される。というのは、フロントエンドアプリケーションプログラム12は顧客名を取得し、サービスモジュールS_Customerは顧客名を備えるアスペクトを含んでいるからである。例えば、フロントエンドアプリケーションプログラム12は、サービスモジュールS_Customerに関連付けられているクエリQueryByNameを、NAME=「John Smith」で、またCustomer_Keyのフィルタリング指定無しでサービスマネージャ16に送信することができる。サービスマネージャ16は、リポジトリ18をチェックして、クエリが定義されていることを確認する。次いでサービスマネージャ16は、データベース24内の顧客データベーステーブル(テーブル7)に対してクエリを行うクエリをQ_provider(例えば32)に送信し、フロントエンドアプリケーションプログラム12に戻される出力は、CustomerId={1}を含むレコードセットである。
プロセス150に含まれる、顧客の住所データベーステーブル(テーブル8)に挿入すること(160)、およびプロセス150に含まれている、顧客データベーステーブル(テーブル7)に挿入すること(162)は、それぞれメタデータリポジトリ18内のアスペクトA_AddressおよびA_Customerに対する標準的な挿入操作(上述)によって記述される。
プロセス150に含まれる、製品データベーステーブル(テーブル9)に対して製品名についてのクエリを行うこと(166)は、テーブル18で定義されているサービスモジュールS_productに関連付けられているQueryByNameクエリによって記述される。例えば、アプリケーション12は、サービスモジュールS_Productに関連付けられているクエリQueryByNameを、NAME=「レンチ」で、またProduct_Keyのフィルタリング指定無しでサービスマネージャ16に送信することができる。サービスマネージャ16は、リポジトリ18をチェックして、クエリが定義されていることを確認する。次いでサービスマネージャ16は、データベース24に対してクエリを行うクエリをQ_provider(例えば32)に送信し、アプリケーション12に戻される出力はProductId={3}を含むレコードセットである。
プロセス150に含まれる挿入すること(170、172、および174)は、それぞれアスペクトA_OrderHeader、A_Basket、A_Positionに対する挿入操作によって定義される。
プロセス150に含まれる、注文データベーステーブル(テーブル12)に対して顧客でクエリを行うこと(178)は、テーブル18で定義されているサービスモジュールS_Orderに関連付けられているQueryByCustomerクエリによって記述される。例えばフロントエンドアプリケーションプログラム12は、サービスモジュールS_Orderに関連付けられているクエリQueryByCustomerを、Customer_Key(CustomerId)={2}で、またOrderHeader_Keyのフィルタリング無しで送信することができる。サービスマネージャ16は、リポジトリ18をチェックして、クエリが定義されていることを確認する。次いでサービスマネージャ16は、データベース24に対してクエリを行うクエリをQ_provider(例えば32)に送信し、アプリケーション12に戻される出力はOrderHeader_Key(OrderId)={2,3}を含むレコードセットである。
プロセス150に含まれる、注文データベーステーブル(テーブル12)において注文操作を選択すること(180)、および選択された注文に関して送信済みフィールドをTrueに設定すること(182)は、リポジトリ18内のアスペクトA_OrderHeaderに対する(テーブル14で定義した)Execute Submitアクションによって定義される。例えば、フロントエンドアプリケーションプログラム12は、アスペクトA_OrderHeaderにおけるSubmitアクションをOrderHeader_Key={2,3}でサービスマネージャ16に送信する。次いでサービスマネージャ16は、OrderId={2,3}に対応する選択された行について注文データベーステーブル(テーブル12)内の送信済みフィールドを「True」に変更する送信操作をS_provider(例えば34)に送信する。
プロセス150に含まれる、住所データベーステーブル(テーブル8)から顧客の住所を取得すること(184)は、A_Customerアスペクトに対する標準Select By Relationアクションによって定義される。例えば、フロントエンドアプリケーションプログラム12は、関係R_Customer_To_AddressおよびCustomer_Key={2}を指定し、A_Customerアスペクトに対するSelect By Relationアクションをサービスマネージャ16に送信する。サービスマネージャ16は、要求をリポジトリ18と照合し、CustomerId={2}に一致する外部キーAddressIdを調べ、住所テーブル8にナビゲートする要求をサービスプロバイダS_provider(例えば34)に渡す。S_provider(例えば34)は、住所データベーステーブル(テーブル8)からの{Louisville,Willow Avenue}を含むレコードセットをサービスマネージャ16を介してアプリケーション12に戻す。
上述した技術は、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはその組み合わせで実施することができる。また、本技術は、コンピュータプログラム製品、すなわち、例えばプログラム可能プロセッサ、コンピュータ、または複数のコンピュータなどのデータ処理装置によって実行するために、またはその操作を制御するために、情報媒体、例えばマシン読取り可能記憶装置や伝搬信号に有形で組み込まれるコンピュータプログラムとして実装することができる。コンピュータプログラムは、コンパイル言語、インタプリタ言語を含めて、任意の形のプログラミング言語で書くことができ、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境での使用に適した他のユニットを含む任意の形で配置することができる。コンピュータプログラムは、1つのコンピュータ上で、または1つのサイトの複数のコンピュータ上で、または複数のサイトにわたって分散され、通信ネットワークで相互接続された複数のコンピュータ上で実行されるように配置することができる。
この技術の方法のステップは、入力データに作用し、出力を生成することによって本発明の機能を実行するためにコンピュータプログラムを実行する1つまたは複数のプログラム可能プロセッサによって実行することができる。方法のステップは、FPGA(field programmable gate array)またはASIC(application-specific integrated circuit)など、専用論理回路によって実行することもでき、また本発明の装置は、専用論理回路として実装することができる。この方法のステップは、上述したもの以外の他の順序(order)で実行してもよい。
コンピュータプログラムの実行に適したプロセッサは、一例として、汎用および専用マイクロプロセッサ、および任意の種類のデジタルコンピュータの任意の1つまたは複数のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリまたはランダムアクセスメモリ、あるいはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令を実行するプロセッサ、および命令およびデータを格納する1つまたは複数の記憶装置である。一般に、コンピュータは、磁気、光磁気ディスク、または光ディスクなど、データを格納する1つまたは複数の大容量記憶装置も備え、またはそれとの間でデータの送受信を行うように動作可能に結合される。コンピュータプログラム命令およびデータを組み込むのに適した情報媒体は、一例としてEPROM、EEPROM、フラッシュメモリ装置などの半導体メモリ装置、内部ハードディスクや取外し可能なディスクなどの磁気ディスク、光磁気ディスク、およびCD−ROMおよびDVD−ROMディスクを含めて、すべての形の不揮発性メモリを含む。プロセッサおよびメモリは、専用論理回路によって補うことができ、またはそれに組み込むことができる。
この発明は、例えばデータサーバとしてバックエンドコンポーネントを含む、アプリケーションサーバなどのミドルウェアコンポーネントを含む、またはユーザが本発明の実装と対話することができるグラフィカルユーザインターフェイスやWebブラウザを有するクライアントコンピュータなどのフロントエンドコンポーネントを含む、あるいはこうしたバックエンド、ミドルウェア、およびフロントエンドのコンポーネントの任意の組み合わせを含むコンピューティングシステムにおいて実施することができる。
本発明を、特定の実施形態に関して説明してきた。他の実施形態も、添付の特許請求の範囲内に含まれる。