JP2004280821A - ソフトウェアビジネスプロセスモデル - Google Patents

Abstract

【課題】 ビジネスソフトウェアアプリケーションのオーサリングおよび実行をサポートするビジネスプロセスモデルを提供すること。
【解決手段】 ビジネスソフトウェアフレームワークに、プロセスモデルを有するアプリケーションフレームワークが含まれる。プロセスモデルによって、所望のサービスがビジネスコンポーネントに与えられ、オペレーションがアクティビティに編成され、エージェント／サービス配置も使用することができる。
【選択図】 図３

Description

本発明は、ビジネスソフトウェアソリューションに関し、より詳細には、ビジネスソフトウェアアプリケーションのオーサリング（ａｕｔｈｏｒｉｎｇ）および実行をサポートするビジネスプロセスモデルに関する。

統合ビジネスソリューションには、通常は、ビジネスセグメントをサポートし、企業のハブネットワークおよびスポークネットワークと対話する複数の機能を有する製品が含まれる。そのような製品には、財務情報、人事管理、カスタマリレーションシップマネジメント、プロフェッショナルサービスオートメーション、配布、サプライチェーンマネジメントなどを実行するソフトウェアアプリケーションが含まれる。

過去に、そのような統合ビジネスソリューションの達成は、非常に困難であった。以前のビジネスアプリケーションは、主に、内部およびバックオフィスの機能のビジネスプロセス自動化に焦点を合わせ、それに制限されていた。このタイプの内部の効率は重要であるが、会社の外部の、カスタマ、サプライヤ、パートナ、金融業者、および従業員である個人との関係には対処していない。

現在まで、最大級の組織だけが、その構成要素への企業の外部の広範なビジネスプロセス自動化を有する。これらのソリューションの実施のコストおよび複雑さは、単純に、特に中小規模の組織にとって極度に大きかった。

コストが非常に高いことの理由の１つは、コンピュータソフトウェア関連製品を設計し、マーケティングする手法の１つが、製品が大きい産業セグメントに広範囲に適用可能であり、多数の異なる国で適用可能になるように、水平機能性に焦点を合わせることである。そのようなシステムは、特定の垂直ターゲット市場および特定の会社の独自の必要を満たすためにアフターマーケットの販売を促進できることも望ましい。同様に、製品は、カスタマの個々の必要に合わせて製品を変更またはカスタマイズするカスタマの能力を促進できることが望ましい。そのような必要は、例えば、異なるベンダの製品であっても、異なるビジネス製品が統合化された形で動作するという要件とすることができる。これは、しばしば、アプリケーションを修正またはカスタマイズし、その結果、アプリケーションが互いに互換になることを必要とする。

カスタマの独自の必要に合うように製品を拡張できない場合には、本質的に、カスタマが、購入したソフトウェアに合わせて自分の仕事を変更することが必要になる。もちろん、このタイプのシステムは、業務活動の変更が高コストであり時間がかかるので、カスタマに抵抗される。

システムをカスタマイズできるようにするために従来から使用されてきた複数の異なる方法がある。そのような従来の方法に、例えば、ソースコード修正が含まれる。この方法には、製品のソースコードのコピーをカスタマに提供することが伴う。したがって、十分に訓練された実務家が、かなりの量の内容を変更できるようになり、これらの変更は、実際に修正されたソースコード製品の一部なので、製品の一部であるかのように見えるようにすることができる。

しかし、ソースコード修正は、大きな短所を伴う。例えば、ソースコード修正は、製品を使用する前にかなりの金額のコストを要する。というのは、ユーザまたはカスタマが、しばしば、製品の構成のニュアンスについて特にトレーニングされた高給のコンサルタントおよび開発者を雇わなければならないからである。次に、ユーザは、問題を推定するという危険に耐えなければならないが、これは、非常に困難で不正確な作業である。これらの問題を克服し、耐えることができる場合であっても、その結果は、修正されたソースコードである。元のソースコードの製造業者が、バグフィックス、アップデート、および新バージョンなどの追加ソフトウェアを出荷する時に、カスタマは、製造業者によって出荷された新しいソースコードに修正を合体させ、新たに修正されたソースコードで生じる問題を１つずつ解決するために、有能なエンジニアまたは開発者のいずれか（できれば元の修正を行ったのと同一人物）をもう一度雇うことを強制される。その代わりに、ユーザが、単純に、ユーザの仕事に役立つ可能性があるバグフィックスおよび新機能なしで済ませることができる。

さらに、ソースコード修正によって、複数の異なるベンダから「在庫の」アドオンモジュールを単純に購入することが、極端に困難になる。というのは、これらのベンダのそれぞれが、めいめいの在庫モジュールに対処するために、ソースコードも修正しなければならない可能性が高いからである。その結果、製造業者が基本製品のソースコードを出荷するだけではなく、各アドオンベンダも、ソースを出荷しなければならない。ユーザは、ソースコードのランダムな組から単一製品のある種のアドホックなマージプロセスまたは合成を行わなければならない。もちろん、これによって、アップグレードに関する問題またはベンダのいずれかがバグフィックスを出荷した時に問題を有することが事実上保証された、脆弱なコードの組がもたらされる。

ソースコード修正は、世界中で１つの組織（ソースコードを修正した特定の開発者またはエンジニア）だけが、修正されたソースコード製品を構築する方法を知っていることからも影響を受ける。したがって、規模の経済およびカスタマサイトで動作する製品のいずれかの製品サポートを達成することが、不可能ではないとしても困難である。

ソースコード修正に関する問題は、単一のカスタマであっても、必要とプリファレンスの別個の組を有するユーザの別個の組が存在する時に、かなり増加する。これらのユーザの１人が、その特定の必要に対処するためにソースコード修正戦略を介して製品を変更するたびに、これらのユーザを雇うカスタマが、実際に、新しいソースコードーベースで終わる。言い換えると、カスタマは、単一のカスタムコードベースを有するだけではなく、実際には、カスタマの特定のユーザまたは部署のいくつがコードベースを修正したかに応じて、多数のカスタムコードベースを有する可能性がある。やはり、バグフィックスがパブリッシュされるか、全ユーザに適用されるカスタマイゼーションに対する変更が行われるたびに、カスタマは、作られたソースのすべての他のコピーとのある種のマージプロセスを行わなければならない。

これは、ソースコード修正方法に関連する多数の問題のごく一部のリストである。これらの問題によって、統合されたビジネスソリューションを得る試みで、カスタマの管理および従業員自体の多数の問題がもたらされる可能性がある。

本発明は、このような問題に鑑みてなされたもので、その目的とするところは、ビジネスソフトウェアアプリケーションのオーサリング（ａｕｔｈｏｒｉｎｇ）および実行をサポートするビジネスプロセスモデルを提供することにある。

本発明は、ビジネスソフトウェアフレームワークに、プロセスモデルを有するアプリケーションフレームワークが含まれる。プロセスモデルによって、所望のサービスがビジネスコンポーネントに与えられる。プロセスモデルによって、オペレーションがアクティビティに編成される。プロセスモデルによって、エージェント／サービス配置も使用することができる。

以下、図面を参照して本発明の実施の態様について説明する。
本発明には、ビジネスアプリケーションをサポートするフレームワークが含まれる。しかし、本発明を詳細に説明する前に、本発明が存在することのできる１つの例示的なコンピューティング環境を説明する。

＜コンピューティング環境の概要＞
図１は、本発明を実施することができる適切なコンピューティングシステム環境の例を示す図である。コンピューティングシステム環境１００は、適切なコンピューティング環境の１つの例にすぎず、本発明の使用または機能性の範囲に関する制限を暗示することを意図されたものではない。また、コンピューティング環境１００を、例示的なコンピューティング環境１００に示された構成要素のいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。

本発明は、多数の他の汎用または特殊目的のコンピューティングシステムの環境または構成と共に動作する。本発明と共に使用するのに適切である可能性がある周知のコンピューティングシステム、環境、および／または構成には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セッとトップボックス、プログラマブル消費者電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限はされない。

本発明を、全般的に、プログラムモジュールなどの、コンピュータによって実行されるコンピュータ実行可能命令に関して説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルおよびリモートの両方のコンピュータ記憶メディアに配置することができる。

図１に関して、本発明を実施する例示的システムに、コンピュータ１１０の形の汎用コンピューティングデバイスが含まれる。コンピュータ１１０の構成要素に、処理ユニット１２０、システムメモリ１３０、および、システムメモリを含むさまざまなシステム構成要素を処理ユニット１２０に接続するシステムバス１２１を含めることができるが、これに制限はされない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。制限ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。

コンピュータ１１０には、通常は、さまざまなコンピュータ可読メディアが含まれる。コンピュータ可読メディアは、コンピュータ１１０によってアクセスできるすべての使用可能なメディアとすることができ、コンピュータ可読メディアには、揮発性メディアおよび不揮発性メディア、取外し可能メディアおよび取外し不能メディアの両方が含まれる。制限ではなく例として、コンピュータ可読メディアに、コンピュータ記憶メディアおよび通信メディアを含めることができる。コンピュータ記憶メディアには、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の保管の任意の方法または技術で実施される揮発性および不揮発性の両方の、取外し可能または取外し不能のメディアが含まれる。コンピュータ記憶メディアには、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を保管するのに使用でき、コンピュータ１１０によってアクセスできる他のメディアが含まれるが、これに制限はされない。通信メディアによって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが実施され、通信メディアには、すべての情報配信メディアが含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形で１つまたは複数の特性を設定または変更された信号を意味する。制限ではなく例として、通信メディアに、有線ネットワークまたは直接配線接続などの有線メディアと、音響、ＲＦ、赤外線、および他の無線メディアなどの無線メディアが含まれる。上記のいずれかの組合せも、コンピュータ可読メディアの範囲に含まれなければならない。

システムメモリ１３０には、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの、揮発性および／または不揮発性メモリの形のコンピュータ記憶メディアが含まれる。起動中などにコンピュータ１１０内の要素の間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３が、通常はＲＯＭ１３１に保管される。ＲＡＭ１３２には、通常は、処理ユニット１２０によって即座にアクセス可能および／または現在操作されつつあるデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０には、他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶メディアを含めることもできる。例としてのみ、図１に、取外し不能不揮発性磁気メディアから読み取り、これに書き込むハードディスクドライブ１４１、取外し可能不揮発性磁気ディスク１５２から読み取り、これに書き込む磁気ディスクドライブ１５１、およびＣＤ ＲＯＭまたは他の光学メディアなどの取外し可能不揮発性光ディスク１５６から読み取り、これに書き込む光学ディスクドライブ１５５が図示されている。この例示的オペレーティング環境で使用することができる他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶メディアには、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに制限はされない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの取外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光学ディスクドライブ１５５は、通常は、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。

上述した、図１に図示されたドライブおよびそれに関連するコンピュータ記憶メディアによって、コンピュータ１１０のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージが提供される。図１では、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一または異なるもののいずれかとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、最低限、これらが異なるコピーであることを示すために、本明細書では異なる符号を与えられている。

ユーザは、キーボード１６２、マイクロホン１６３、および、マウス、トラックボール、またはタッチパッドなどのポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）などの、他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタの他に、コンピュータに、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェース１９５を介して接続することができる他の周辺出力デバイスも含めることができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、リモートコンピュータ１８０には、通常は、コンピュータ１１０に関して上述した要素の多数またはすべてが含まれる。図１に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。

ＬＡＮネットワーキング環境で使用される場合に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合に、コンピュータ１１０には、通常は、インターネットなどのＷＡＮ１７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその諸部分を、リモートメモリストレージデバイスに保管することができる。制限ではなく例として、図１に、リモートコンピュータ１８０に常駐するリモートアプリケーションプログラム１８５を図示する。図示のネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用することができることを諒解されたい。

＜高水準ソフトウェア環境の概要＞
図２は、本発明が常駐することのできる、より高水準の環境のブロック図である。環境２００に、ツールおよびサーバプラットフォーム２０２、本発明が常駐するビジネスフレームワーク２０４、ビジネスコンポーネント２０６、およびビジネスソリューション２０８が示されている。ツールおよびサーバプラットフォーム２０２によって、例として、アプリケーションが広域ネットワークを介して通信でき、データを共有できるようにするサービスのプラットフォームが提供される。プラットフォーム２０２に、例えば、この機能性を可能にするツールおよびサーバシステムを含めることができる。ビジネスコンポーネント２０６に、例として、ビジネスフレームワーク２０４との開発者の対話に基づいて一緒にパッケージ化されたビジネスアプリケーションの機能性が含まれる。ビジネスコンポーネント２０６は、例えば、総勘定元帳アプリケーションおよび財務アプリケーションから、セールスフォースオートメーションサービスおよびカスタマリレーション管理アプリケーションの範囲に及ぶものとすることができる。フレームワーク２０４を使用してビジネスコンポーネント２０６を記述することによって、これらのコンポーネントが、拡張可能になり、これを使用して、どのレベルの機能性および複雑さが望まれるかに応じて、複数のユーザの必要をサービスすることができる。

各ビジネスソリューション２０８に、１つまたは複数のアプリケーションが含まれる。アプリケーションとは、ユーザインターフェースを介して提示され、個別に展開されるビジネスコンポーネントのグループである。

ビジネスフレームワーク２０４は、ビジネスコンポーネント２０６の開発者によって使用される。ビジネスフレームワークによって、生産的であり信頼性があり一貫性がある形のビジネスアプリケーションが可能になる。

＜ビジネスフレームワークの概要＞
図３は、ビジネスフレームワークの複数の基礎サブシステムを示す図である。図３に、複数のビジネスコンポーネント２１４、２１６、および２１８を含むアプリケーションレイヤ２１２をサポートするフレームワーク２１０を示す。ビジネスコンポーネントには、財務アプリケーション、プロジェクトアプリケーション、および流通アプリケーションが含まれる。フレームワーク２１０は、プラットフォーム２０２に常駐するものとして図示されている。

フレームワーク２１０自体には、１組のビジネスクラスライブラリ２２０、ツールサブシステム２２２、およびビジネスアプリケーションフレームワーク２２４が含まれる。ツールサブシステム２２２には、例として、コンポーネント、プロセス、レポート、およびエンドユーザインターフェースを設計する複数の設計サブシステムが含まれる。ツールサブシステム２２２には、例として、設計されたコンポーネントをテストするのに使用することができるテストサービス、ならびにコンポーネントをアプリケーションまたはソリューションにパッケージ化するのに使用されるアプリケーションパッケージャも含まれる。

ビジネスクラスライブラリ２２０には、共通エンティティ２２６、パターン２２８、およびデータ型２３０が含まれる。

２つのビジネスアプリケーションが、しばしば、統合を行えるようにするためにデータの共有される理解を必要とする。例えば、流通、財務、およびカスタマリレーション管理のすべてが、カスタマデータを扱う。したがって、ビジネスクラスライブラリ２２０によって、ほとんどのビジネスアプリケーションに重要なコアプロパティを含む複数の共通エンティティ２２６が提供される。フレームワーク２１０上で構築されるアプリケーションによって、カスタマイゼーション（下で説明する）を介して、シナリオ固有のプロパティおよび挙動を有するようにこれらのエンティティを拡張することができる。

表１は、ビジネスクラスライブラリ２２０の共通エンティティ２２６の一部の例示的なリストである。もちろん、多数の異なるまたは追加の共通エンティティを定義することもできる。

ビジネスアプリケーションの作成をはるかに効率的にすることができる多数の有用なデータ型もある。エンティティ２２６と異なって、データ型は、一意の識別を有しない。表２に、ビジネスクラスライブラリ２２０内でデータ型２３０として実装することができる複数の例示的なデータ型を示す。

共通エンティティによって、ビジネスアプリケーションのエンティティのわずかな部分だけが構成される。共通エンティティ２２６によって、ルールおよびプロセスの指定を回避することができるが、これらはアプリケーションによって異なるので、これらのルールの多くが、頻繁に見られるビジネスアプリケーションパターンに従う。ビジネスクラスライブラリ２２０によって、クラスライブラリ２２０にパターン２２８として共通のパターンの構造および挙動を取り込むことによって、エンティティ、プロセス、およびポリシの複数の共通のカテゴリの記述がサポートされる。表３に、クラスライブラリ２２０でパターン２２８として使用される複数の例示的なパターンのリストの１つを示す。

ビジネスアプリケーションフレームワーク２２４によって、アプリケーション作成に関するプログラミングモデルおよびサービスが提供される。一実施形態では、このフレームワークに、製品に固有のビジネスロジックが含まれず、したがって、このフレームワークは、ビジネスアプリケーションだけではなく、プロファイルに合うすべての他のアプリケーションのオーサリングに適切である。このフレームワークによって、広範囲のサポートを提供するアプリケーションサービスの組が提供される。このアプリケーションサービスは、レポート作成およびクエリサブシステム２３２、プロセス実行サブシステム２３４、ユーザインターフェースサブシステム２３６、コンポーネントプログラミングモデルサブシステム２３８、ロールベースセキュリティサブシステム２４０、カスタマイゼーションサブシステム２４２、デプロイメント（ｄｅｐｌｏｙｍｅｎｔ）および管理サブシステム２４４、データアクセスサブシステム２４６、メタデータサブシステム２４８、ビジネスメッセージングおよび統合サブシステム２５０、ならびにファウンデーション（ｆｏｕｎｄａｔｉｏｎ）サービスサブシステム２５２を含むサブシステムで実装される。

＜プログラミングモデルサブシステム２３８およびプロセス実行サブシステム２３４＞
上述したように、ビジネスフレームワーク２０４で構築されるアプリケーションの論理ビューは、そのデータ、プロセス、およびルールを表すクラスの組である。設計中に、これらがさらに洗練され、ビジネスコンポーネント２０６にグループ化される。設計は、プログラミングモデル２３８の複数の要素に従って構造化される。コンポーネントは、それに関して記述された、３つの主要な種類のタイプ、ビジネスエンティティ、アクティビティ、およびプロセスからなる。コンポーネントに、もちろん、列挙などのサポートするクラスおよび型の特定の実装である値型などの他のデータ型を含めることもできる。ビジネスアプリケーションを形成する、疎結合されたコンポーネントのグループが、このアーキテクチャの基礎の構成要素である。コンポーネントは、サブシステム２３４でのユーザインターフェース管理、サブシステム２３２および２４６を介するデータ永続性、およびサブシステム２３４を介するビジネスプロセス実行など、さまざまな役割を演じる。

アプリケーションフレームワーク２２４を使用して実装される時に、ビジネスコンポーネント２０６は、詳細なコンポーネントメタデータを介して自己記述的になる。メタデータは、メタデータサブシステム２４８内に、またはコンポーネントの実行可能部分を用いて保管される。この情報が、アプリケーションフレームワーク２２４によって使用されて、ビジネスコンポーネント２０６およびこれらのコンポーネントのコンシューマ（ｃｏｎｓｕｍｅｒ）にサービスが提供される。フレームワーク２０４によって、メタデータに関する挙動が提供され、その挙動を、コンポーネントの変更なしで追加することができる。もちろん、これは、機能性がハードコードされている場合には不可能である。

上述したビジネスエンティティによって、データが管理される。例として、コンポーネントは、１つの主エンティティを有し、この主エンティティが、コンポーネントの焦点である。コンポーネントの他のエンティティは、例として、主エンティティの子とすることができるが、そうである必要はない。エンティティのデータは、通常は、リレーショナルデータベースのデータベーステーブルに保管される。データへのアクセスは、下でサブシステム２３２および２４６に関して説明する。

ビジネスプロセスは、通常はある形でデータを変換する、ビジネスロジックステップの拡張可能なシーケンスである。ビジネスプロセスによって、データベーストランザクションも管理される。ビジネスプロセスは、ワークフローを介してまたは他の手段を使用して、コードで実行することができる。ビジネスプロセスの例に、ポスティング、文書承認、および価格計算が含まれる。ビジネスポリシは、ビジネスルールの置換可能な組であり、ビジネスルールは、データに対する制約（あるプロパティが有することのできる値、またはあるエンティティが他のエンティティに関して有しなければならない関係）または推論（例えば、ある述部が真である場合に、あるアクションを行わなければならない）である。ルールは、エンティティ、プロセス、およびポリシの一部であり、実際に、ビジネスロジックを、ビジネスルールの組として記述することができる。

コンポーネントへのインターフェースは、そのコンポーネント内のクラスのパブリックメンバである。コンポーネントのインターフェースの一部が、パブリック呼出しを介してアクセス可能である場合に、その部分はパブリッシュされる。パブリッシュされたメソッドによって、例として、セキュアな認可および認証が実施されることが保証される。

アプリケーションプログラマは、アプリケーションの構築を開始する時に、まず、必要な作業の論理単位を決定しなければならない。第２に、例として、アプリケーションプログラマは、作業の論理単位のそれぞれを、どのように組織化するかを決定し、最後に、カスタマイゼーションを許可するかどうかを決定する。

プロセス実行サブシステム２３４のプログラミングコンポーネント２３８によってサポートされるビジネスプロセスモデルによって、実行される作業が、３つの領域すなわち、ビジネスプロセス、ビジネスアクティビティ、およびビジネスオペレーションに分解される。ビジネスオペレーションは、単一の物理的トランザクションで実行される機能性の最小単位である。これの例が、通常のリレーショナルデータベーストランザクションなどのＡＣＩＤ（アトミック、一貫、分離、持続可能）である。オペレーションによって、他のオペレーションを呼び出すことができ、集合セットによって、同一の物理的トランザクションを共有することができる。

ビジネスアクティビティは、可能な場合に１つの物理的トランザクションで集合的に実行されるビジネスオペレーションの組を含むコード駆動のプロセスである。しかし、これらを単一のトランザクションで実行することが実用的でない場合がある。というのは、並列性（複数のユーザによる並列動作）が悪くなるか、トランザクションがタイムアウトする場合があるからである。例えば、販売注文をポストする時に、これは１トランザクションで完了でき、したがって単一のビジネスオペレーションによって表すことができるが、そうではなくアクティビティにグループ化することができる。こうするのは、注文のポストによって、データベースのデータがロックされ、したがって、同一のデータにアクセスすることを望む他者が、ロックが解放されるまで待たなければならないからである。このロックは、物理的トランザクションの持続期間中は保持され、ユーザは、そのトランザクションが完了するまでそのデータにアクセスできなくなる。したがって、注文のポスト全体の間でロックを保持することによって、システムのスループットが低下し、注文を複数のより小さい動作に分割することによって、システムスループットが向上する。同様に、そのような動作の大きいグループの実行には、トランザクションの通常のタイムアウト期間より長い時間を要する場合がある。したがって、数千個の勘定科目を有する注文が、単一の動作にグループ化される場合には、その動作が終了する前にタイムアウトが発生する可能性が高い。したがって、複数の動作（この場合にはポスト動作）のスコープを、アクティビティによって決定することができる。例えば、ある注文のポスト動作を、単一のアクティビティによってスコープを決定される複数の動作に副分割することができ、これによって、タイムアウトの可能性が減り、システムの並列性およびスループットの向上がもたらされる。

ビジネスプロセスは、メタデータを使用して記述され、ランタイムエンジンによって実行される、データ駆動プロセスである。したがって、開発者は、通常はインペラティブ（ｉｍｐｅｒａｔｉｖｅ）コード（Ｃ＃など）で記述されるオペレーションを構築する。これらのオペレーションは、グループ化され、アクティビティによってスコープを決定され、ビジネスプロセスは、アクティビティを呼び出して、所望のプロセスまたは作業の全体を実行する。

プロセス分類は、アプリケーション開発者のための作業の単位の階層的分解である。長時間動作する（または非同期の）トランザクションおよび短時間動作する（または同期式の）トランザクションならびにこれらのコンポーネントの再利用によって、ビジネスオペレーション、ビジネスアクティビティ、またはビジネスプロセスのどれを使用しなければならないかが決定される。表４に、作業の単位のそれぞれに適用される一般的なカテゴリの一部を示す。

表４には、プロセスおよびアクティビティについて停止点が使用可能であることが示されている。これは、プロセスまたはアクティビティが、ユーザまたは他のシステムなどの外部システムからのさらなる対話のために、その途中で停止する点を有することができることを意味する。しかし、オペレーションは、実行される作業の最小の単位なので、すべてが１回で実行され、停止点を許さない。

この表４には、プロセスが、メタデータによって定義され、アクティビティおよびオペレーションが、インペラティブコードによって定義されることも示されている。

この表４には、プロセスおよびアクティビティが、長いトランザクションであり、オペレーションが、短い（ＡＣＩＤ）トランザクションであることも示されている。長時間動作トランザクションは、複数の物理的（短時間動作）トランザクションからなる。したがって、ＡＣＩＤトランザクションの、分離（他のユーザからの）特性が、失われるが、他の特性は、まだ望まれる。これには、プロセスの途中での障害を扱う異なる手法も含まれる。というのは、トランザクションの完全なロールバックが、ほとんどの場合に不可能になるからである。

次に、この表４には、作業の単位中に障害が発生した時に何が起こるかが示されている。プロセスでは、例外または転送アーチ技法を使用することができる。チェックポインティングは、アクティビティで使用することができる。チェックポイントを用いると、後続の障害が発生した場合に、アクティビティを、最も最近に記録されたチェックポイントから再始動できるようになる。例えば、注文のバッチの一部が、アクティビティでポストされる場合に、各ポスト動作が完了した後にチェックポイントがセットされる。したがって、後続のポスト動作に障害が発生した場合に、このアクティビティを先頭から開始する必要はなく、最後に保存されたチェックポイントから始動するだけでよい。

次に、この表４には、作業の単位が、他のユーザによって実行される作業から分離されるかどうかが示されている。この表４には、オペレーション中に、データベースによって、用いられるデータがロックされ、その結果、他者がそのデータにアクセスできなくなることが示されている。アクティビティ中には、アプリケーションによって、用いられるデータが「使用中」としてマーク（「ロック」）される。この場合に、アプリケーションは、通常は、あるデータが修正されつつあることの表示をセットし、その結果、他のプロセスまたはアクティビティは、そのデータを見ることはできるが、それが現在変更中またはアクセス中であることの表示も有し、したがって、規定により、そのデータを修正しない。これは、ユーザのためにアプリケーションによって尊重される規定であって、物理的なロックではない。この表には、プロセスが、そのアクションからシステムの他の部分を分離するためには何もしないことも示されている。

次に、この表４には、所与の作業の単位が、他のどの作業の単位を呼び出せるかが示されている。プロセスは、別のプロセス、別のアクティビティ、およびおそらくはオペレーションを呼び出すことができる。アクティビティは、別のアクティビティまたはオペレーションを呼び出すことができ、オペレーションは、別のオペレーションを呼び出すことだけができる。

次に、この表４には、作業の単位のそれぞれをどのように呼び出せるかが示されている。プロセスおよびアクティビティは、例えば、Ｅｘｅｃｕｔｅメソッドを呼び出すことによって呼び出されるが、オペレーションは、外部コンポーネントによって直接に呼出し可能ではないが、アクティビティまたは別のオペレーション（およびおそらくはプロセス）によってのみ呼出し可能である。

この表４には、次に、作業の単位がどのようにカスタマイズされるかが示されている。プロセスは、アクティビティの追加、除去、または順序変更によってカスタマイズすることができる。プロセスは、イベントを処理する方法（オペレーションまたはアクティビティの完了時、中断、再開、または打切りなど）によってカスタマイズすることもできる。アクティビティは、Ｅｘｅｃｕｔｅメソッドが呼び出される前または完了した後にポストされるイベントに基づいてカスタマイズする、ポリシに基づいてカスタマイズする、あるいはアクティビティを置換することができる。オペレーションは、プリＥｘｅｃｕｔｅイベントまたはポストプリＥｘｅｃｕｔｅイベントにサブスクライブすることによって、またはポリシを実施することによってカスタマイズすることができる。

図４は、注文を作成し、指定された時刻にポストし、信用検査を実行するプロセスの配置を示す図である。図４には、プロセス分類を使用して、開発者が物理的におよび論理的にトランザクションおよびそれを取り囲むプロセスを定義できることが示されている。

図４の全体的な処理が、ブロック３００によって示される。プロセスを形成するアクティビティが、ブロック３００内に示されている。このアクティビティには、注文作成３０２、タイムアウト３０４、注文ポスト３０６、選択アクティビティ３０８、およびメッセージアクティビティ３１０が含まれる。プロセス３００には、別のプロセス（信用チェックプロセス３１２）をプロセス３００によって呼び出せることも示されている。

例の実施形態では、プロセス３００が、作成者によって、プロセス記述言語（メタデータ、テキスト言語などとすることができる）を使用してオーサリングされ、このプロセス記述言語は、ワークフローランタイムエンジンによって解釈される。プロセス記述言語でのオーサリングの利益は、変更が行われた場合であっても、プロセスをもう一度実行する前に記述を再コンパイルする必要がないことである。しかし、プロセスが、Ｃ＃などのプログラミング言語でオーサリングされた場合には、プロセスに対して変更を行うために、変更またはカスタマイゼーションが行われるたびにコードをコンパイルしなければならない。おそらくはより重要なことに、プロセス記述言語が正しく構造化される場合に、アップグレードカスタマイゼーションを、ユーザ介入なしで行うことができる。もちろん、個々のアクティビティまたはオペレーションのそれぞれを、例として、プログラミング言語でオーサリングすることができる。

プロセスの実行を開始するために、ユーザまたは別のシステムイベントによって、プロセスが前に進められる。図４に示された例では、ユーザが、画面３２０を介してデータ入力を実行することなどにより、新しい注文を作成する。これによって、注文作成アクティビティ３０２が開始される。注文作成アクティビティは、図示の実施形態では、複数のビジネスオペレーション３２２からなる。

注文作成アクティビティ３０２は、それ自体が複数のオペレーション３２２からなる。図４に示されたオペレーションには、文書番号の入手、文書への行の追加、および文書の再保存が含まれる。これが完了する時に、アクティビティ３０２によって、タイマ３２４を参照するタイムアウトアクティビティ３０４が呼び出される。タイムアウト３０４では、タイマ３２４からのタイムアウトイベントを待ち、その後、注文ポストアクティビティ３０６が呼び出される。

図４には、注文ポストアクティビティ３０６が、複数の追加のアクティビティ３２６から形成され、このアクティビティ３２６のそれぞれが、注文ポストアクティビティ３０６によって呼び出されることが示されている。アクティビティ３２６には、注文の検証、総勘定元帳への注文のポスト、および在庫目録への注文のポストが含まれる。これらのアクティビティ３２６のそれぞれが、複数のオペレーションから構成される。総勘定元帳への注文のポストおよび在庫目録へのポストのアクティビティに関する例示的オペレーションが、符号３２８および３３０によって示される。所望の作業を達成するために、任意の深さまでオペレーションまたはアクティビティを呼び出せることに留意されたい。また、チェックポインティングを使用すると、注文ポストアクティビティ３０６がある点で障害を発生する場合に、最初から再始動する必要はなく、もっとも最近に保存されたチェックポイントから再始動することができることに留意されたい。

注文ポストアクティビティ３０６が完了したならば、信用チェックサブプロセス３１２が呼び出される。信用チェックサブプロセス３１２をサブプロセスと呼ぶのは、プロセス３００内から呼び出されるからである。図４には、ユーザが手動で信用を承認するのを待つという点で、サブプロセス３１２にも停止点が含まれることが示されている。これは、一実施形態で、画面３３２を介してデータを入力することによって行うことができる。

サブプロセス３１２の結果に基づいて、信用の承認または拒否のいずれかが行われる。承認される場合に、サブプロセス３１２によって、選択アクティビティ３０８が呼び出され、選択アクティビティ３０８では、注文された製品が、配送のために選択される。選択アクティビティは、複数のオペレーション３３４から構成されるものとして図示されている。選択アクティビティ３０８には、データ入力画面３３６を介する、製品が成功裡に選択されたことのユーザによる表示を受け取るために待つなど、停止点も含まれる。

サブプロセス３１２によって、信用チェックが拒否されると判定された場合に、メッセージアクティビティ３１０が呼び出され、このメッセージアクティビティ３１０には、プロセス３００を開始したユーザに電子メールメッセージを送信し、信用チェックが拒否されたことを示すオペレーションが含まれる。

図４には、信用チェックプロセス３１２の後に分岐点が存在することが示されているが、もちろん、そのようなプロセス内で、任意の数の分岐を展開できることを諒解されたい。また、ユーザまたは開発者が、単純に、プロセスを記述するメタデータ（または他のプロセス記述言語）をカスタマイズすることによってプロセス３００内のアクティビティまたはサブプロセスを挿入または削除することによって、プロセスを修正またはカスタマイズできることに留意されたい。同様に、ユーザまたは開発者は、望みに応じて、既にプロセスに含まれるイベントにサブスクライブし、カスタムコードを用いてイベントを処理するか他の形によって、プロセスをカスタマイズすることができる。

図５から図７は、さらに、ビジネスプロセスを生成するプロセスを示す図である。まず、図５に関して、ユーザインターフェース３５０が、印刷チェック３５２などのビジネスアクティビティを直接に呼び出すように構成されると仮定する。印刷チェックビジネスアクティビティは、もちろん、所望の作業を達成するためにビジネスオペレーションを呼び出す。

ここで、後に、ベンダ、カスタマ、または他の開発者が、より大きいビジネスプロセスの一部として、同一の印刷チェックビジネスアクティビティ３５２を使用することを望むと仮定する。ユーザインターフェース３５０またはビジネスアクティビティ３５２自体のいずれのコードも一切変更せずに、プロセス記述言語（例えばメタデータ）を変更して、印刷チェックビジネスアクティビティ３５２が、図６に示されたビジネスプロセス３５４のコンテキスト内で実行されることを指定することができる。したがって、ビジネスプロセスは、印刷チェックビジネスアクティビティ３５２を成功裡に完了するための前提条件のすべてを検証する責任を負う。承認取得サブプロセス３５６の形の中間ステージが、印刷チェックビジネスアクティビティ３５２と同一のビジネスプロセス３５４の一部にされると仮定する。承認取得サブプロセス３５６は、ユーザインターフェース３５８からの手動介入を必要とする停止点も有する。プロセス３５４では、ユーザインターフェース３５０を介する印刷チェックビジネスアクティビティ３５２の呼出しを試みるすべてのものが、必要な前提条件（承認取得サブプロセス３５６）をまず完了しなければ、失敗する。

その後、誰かが図６に示されたプロセス３５４を手動で起動するのではなく、ユーザが、プロセス３５４が所定のスケジュールで（毎月１５日および３０日など）自動的に起動するようにプロセスをカスタマイズすることを望むと仮定する。さらに、承認取得サブプロセス３５６を、手動介入を必要とせずにビジネスルールを使用することによって自動化できると仮定する。単純に、今は完全に自動化された承認取得サブプロセス３５６を起動するタイマ３６０を含むようにプロセス記述言語（例えばメタデータ）を修正することによって、新しいプロセス３６２を作成することができる。もちろん、メタデータも調整され、その結果、承認取得サブプロセス３５６の出力が、印刷チェックビジネスアクティビティ３５２を開始するための唯一の前提条件になる。

上述した図４から図７から、説明されたビジネスプロセスが、完全にカスタマイズ可能であることがわかる。停止点は、プロセス内またはプロセスの外部のアクティビティ内のいずれかの任意の点に、後で追加することができる。同様に、開発者は、オペレーション、アクティビティ、またはプロセスによって生成されるイベントにサブスクライブでき、イベントに応答するカスタマイズされたコードを挿入することができる。さらに、プロセスが、インペラティブコードではなくプロセス基準言語によって記述されるので、カスタマイゼーションを、再コンパイルなしで行うことができる。

図８は、ビジネスアクティビティをどのように実施できるかを示す図である。一実施形態では、上述したように、ビジネスアクティビティ４００が、複数の個別のトランザクショナルステップ（ビジネスオペレーション）に分解される。

ビジネス機能性は、それが操作するデータの近くでそのユーザの近くに存在することが望ましい場合があり、ユーザは、そのデータに対して実行される機能性の結果を見なければならない。しかし、分散コンピューティング環境では、ユーザとデータが、しばしば、低から中程度の信頼性を示す、待ち時間の長いネットワークによって分離される。例えば、１つの一般的なシナリオでは、ユーザが、クライアントであり、データが、サーバに常駐する。

本発明の一実施形態によるビジネスオペレーションは、エージェント−サービスパターンに従う。ビジネスオペレーションエージェントは、プロセスのうちで、クライアントが直接に対話する唯一の部分である。ビジネスプロセスを実行する必要があるクライアントは、ビジネスオペレーションエージェントのインスタンスを作成し、それにプロパティを送って、必要な入力を供給する。エージェントは、対応するサービスクラスを突き止め（サービスファクトリ（ｓｅｒｖｉｃｅ ｆａｃｔｏｒｙ）を介して）、それをインスタンス化し、それを呼び出して、サービスを実施する作業を実際に実行する。

エージェント／サービスパターンを介して、プログラミングモデルによって、位置透明性が回避される。といのは、実行の位置を、分散アプリケーションを構築する時に考慮できるからである。エージェント／サービスパターンによって、クライアント／サーバシナリオおよび多数の他のシナリオをサポートするプログラミングモデル抽象化を提供することによって、高いデプロイメント柔軟性ももたらされる。

具体的に言うと、図８に、さらに、ビジネスアクティビティ４００が、３つのビジネスオペレーションすなわち、オペレーション１、２、および３を使用して実施されることが示されている。ビジネスオペレーション１は、エージェント４０２およびビジネスオペレーションサービスファクトリ４０４を有する。ビジネスオペレーション２も、エージェント４０６およびサービスファクトリ４０８を有する。ビジネスオペレーション３も、エージェント４１０およびビジネスオペレーションサービスファクトリ４１２を有する。

いくつかのビジネス機能性を与えられれば、エージェントは、望み通りにできる限り機能性のユーザの近くで動作し、サービスは、望み通りにできる限りデータの近くで動作する。「近さ」は、各デプロイメントシナリオおよびユーザの各種類によって異なる可能性がある。

エンティティクラスおよびビジネスプロセスクラスを、エージェント部分およびサービス部分に分割することができる（図８に示されたエージェントおよびサービスなど）。エージェント部分は、普通のクラスインスタンスであり、状態が保持されるが、サービス部分では、呼出しにまたがって状態が保持されない。必要な場合には、エージェントが、サービスを呼び出して、データ操作を実行し、ビジネスプロセスを実行する。機能性をエージェントとサービスの間で分割する方法の詳細は、望みに応じて変更することができる。

ビジネスコンポーネントを使用する開発者は、通常は、エージェントだけを扱う。エージェントによって、豊かなオブジェクト指向プログラミングモデルが提供され、このモデルでは、呼出しごとにデータを再指定する必要がある手続き型呼出しを用いてサービスに直接話しかけることに制限されるのではなく、呼出しにまたがってデータが保持される。サービスを呼び出す時には、開発者が要求を定式化するために内部状態を使用することを必要とするのではなく、エージェントによって、その内部状態を使用して要求が定式化される。これによって、開発者の経験が単純化される。

したがって、エージェント／サービスパターンによって、クライアントとサーバの両方のための単一のプログラミングモデルが提供される。エージェントは、クライアントマシンによって、またはサーバマシン上のサーバによってのいずれかで使用することができる。インターネット待ち時間コストも減る。というのは、状態が、１つのラウンドトリップで（従来のようにプロパティごとに１ラウンドトリップではなく）エンティティグラフからクライアントに移動されるからである。同様に、エージェントによって、ラウンドトリップを回避するクライアント側挙動がもたらされる。さらに、エージェント対サービス相互作用は、ステートレスであり、サーバのスケーラビリティおよび信頼性の助けになる。最後に、同一のコンポーネントによって複数の異なるデプロイメントシナリオを実装する能力が、非常に高くなる。

＜プロセスのカスタマイゼーション＞
プロセスをカスタマイズするために、エージェント自体が置換されることはない。クライアント（プロセスまたはアクティビティなど）によって、必ず同一のオリジナルビジネスオペレーションエージェントが作成され、呼び出される。これによって、クライアントは、安定したインターフェースを有するので、必ずエージェントを呼び出せることが保証される。ビジネスオペレーションエージェントに、追加のプロパティを追加できる拡張フィールドを関連付けることができる。これによって、オリジナルエージェントインターフェースコントラクト（ｃｏｎｔｒａｃｔ）を破らずに、エージェント拡張性が実現される。エージェントは、複数の異なる形で、実行すべき正しいサービスを突き止めることができる。

ビジネスプロセスは、そのプロセスが置換のために計画されたプロセスであるか、アドホックな基礎で置換されるプロセスであるかに応じてカスタマイズすることができる。置換のために計画されたものである場合には、呼出し側アプリケーション（またはクライアント）が、現在呼び出されているエージェントにサービスＩＤを渡す。サービスＩＤによって、アクティブにされるサービスが示される。したがって、呼出しによって、エージェント４０２（図８に図示）に特定のサービスＩＤが渡される場合に、エージェント４０２によって、サービスファクトリを介して、ビジネスオペレーションサービス４１４が識別され、インスタンス化され、オペレーションを実行するために呼び出される。単純に異なるサービスＩＤを渡すことによって、サービスを変更することができる。

アドホックな基礎で置換されるオペレーションについて、例としてビジネスオペレーションサービスの組込み選択をオーバーライドするために使用することができる２つの異なる方法がある。例えば、サービスＩＤが、ストア内のメタデータ構造４１７に保管される場合に、カスタマイザによって、単純に、メタデータのうちでオーバーライドされるビジネスオペレーションのサービスＩＤを保持する部分をカスタマイズすることができる。これは、使用されるビジネスオペレーションのサービスファクトリに渡され、これによって、新たに識別されたビジネスオペレーションサービスがインスタンス化され、呼び出される。もう１つの実施形態では、使用される特定のサービスファクトリ（例えばファクトリ４１２）によって、イベントが伝搬される。サービスオペレーションのカスタマイズを望むベンダは、このイベントにサブスクライブし、関連するイベントハンドラ４２２に、サービスＩＤの値を変更する論理を置くことができる。この方法では、ビジネスオペレーションのカスタマイズが可能になるだけではなく、ビジネスオペレーションエージェントに含まれるデータに基づく動的選択も可能になる。

＜カスタマイゼーションのためのコンテキスト＞
本発明の一実施形態によれば、カスタマイズされる必要がある可能性があるソフトウェアに、コンテンツの複数の基本クラスが含まれ、これには、ユーザインターフェースコンテンツ、データ、およびプロセスコンテンツが含まれる。ユーザインターフェースコンテンツには、ユーザが画面またはレポートで見るコンテンツが含まれる。これには、レイアウト情報、メッセージ、フィールドラベルなどが含まれる。データは、システムによって保管される情報を表す。例えば、データに、カスタマ、在庫品目、注文などが含まれる。プロセスコンテンツには、定義されたステップのセットを介して作業をルーティングするワークフロー指定ならびにあるデータに対して明瞭に定義されたアクションを実行する低水準処理論理が含まれる。プロセスコンテンツの例に、例えば、台帳に注文をポストするか在庫品目を予約する、ワークフローおよび低水準処理論理を含めることができる。これらのタイプならびに他のタイプのコンテンツを、本発明のさまざまな実施形態に従ってカスタマイズすることができる。

カスタマイズされるコンテンツのタイプに無関係に、カスタマイゼーションは、所与のコンテキストに関連することが望ましい場合がある。コンテキストによって、カスタマイゼーションが関連する時が左右される。すなわち、コンテキストという概念によって、あるカスタマイゼーションを特定のユーザだけに適用し、別のカスタマイゼーションを特定のグループに属するユーザの組全体に適用し、別のカスタマイゼーションを、ユーザに無関係に会社全体に適用することができる。これらは、コンテキストの３つの異なる例にすぎず、多数の他のコンテンツも使用することができる。

＜エンティティのカスタマイゼーション＞
カスタマイゼーションサブシステム２４２の動作をよりよく示すために、図９に関して説明を進める。この図９に、エンティティのカスタマイゼーションがよりよく示されている。これを、本明細書で「エンティティ拡張」とも称する。

図９は、カスタマイゼーション対応サブシステム内のエンティティが作成される時に作成されるデータ構造を示す図である。図１０は、図９に示されたデータ構造と、エンティティがカスタマイズされる時に作成されるか修正されるデータ構造を示す図である。

図９に、ビジネスアプリケーションのベースエンティティ４８０を示す。例示的なビジネスエンティティ４８０は、ビジネスアプリケーション内でカスタマを識別する「カスタマ」エンティティである。もちろん、図示された特定の例が、例示のみであり、本発明の概念が、他のエンティティにも適用されることを諒解されたい。ベースエンティティ４８０は、拡張される（またはカスタマイズされる）エンティティを表す。図９には、ベースエンティティ４８０が、ＥＲマップ内のカスタマＥＲマップエントリ４８２によってリレーショナルデータベース（図１３に関して後で詳細に説明する５１６など）にマッピングされることも示されている。ベースエンティティ４８０と他のエンティティの間の関係は、カスタマＥＡ（エンティティ関連）マップ４８４で識別される。図９には、さらに、リレーショナルデータベース５１６に、例として、カスタマエンティティ４８０に関連する、カスタマＩＤフィールド、名前フィールド、住所フィールド、およびカスタマの識別に望ましい他のすべてのフィールドを含むカスタマテーブル４８６が含まれることが示されている。

このカスタマイゼーションサブシステムは、エンティティをカスタマイズするのにソースコード修正を必要としないので、ベース拡張エンティティ４８８が、ベースエンティティ４８０の再コンパイルなしでベースエンティティに対する新しいエンティティ関係の動的追加を可能にするために設けられる。ベース拡張エンティティ４８８は、作成されるベースエンティティ４８０ごとに作成される。ベース拡張エンティティ４８８には、例として、この例ではベース拡張エンティティ４８８が「ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ」と命名されるように、ベースエンティティ４８０の名前が含まれる。ベース拡張エンティティ４８８は、当初は空であるが、やはり空である、カスタマ拡張Ｅ−Ｒマップ４９０およびカスタマ拡張ＥＡマップ４９２を含めることができる。ベースエンティティ４８０には、ベース拡張エンティティを識別するコンポジション（ｃｏｍｐｏｓｉｔｉｏｎ）フィールドが含まれる。例えば、ベースエンティティ４８０に、名前が「Ｅｘｔｅｎｓｉｏｎ」で型が「ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎ」であるコンポジションフィールドを含めることができる。Ｃｕｓｔｏｍｅｒエンティティ４８０のエンティティ関連メタデータによって、ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ４８８との関係が反映される。エンティティ４８０および４８８の両方が、例として、本発明による製品がインストールされる時に、ＤＬＬとして出荷され、展開される。その点で、カスタマイザによって、カスタマイザユーザインターフェースを介してＣｕｓｔｏｍｅｒエンティティ４８０に拡張プロパティを追加することができる。

図１０に、拡張プロパティを追加する方法を示す。カスタマイザインターフェースに、識別されたエンティティに追加される新しいプロパティのリストを用いてカスタマイゼーションサブシステム２４２を呼び出すユーザインターフェース（ＵＩ）が含まれる。追加される新しいプロパティの指定が、サブシステム２４２に渡される。カスタマイザによって、特定のカスタマイゼーションが適用される特定のコンテキストを識別することもできる。

これによって、サブシステム２４２によって、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙと称する新しいエンティティが作成される。図１０には、２つのＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１および４９３が示されている。各ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１および４９３に、それぞれ、カスタマイズされるプロパティを識別する少なくとも１つのＥｘｔｅｎｓｉｏｎプロパティ４９４および４９６が含まれる。図１０には、カスタマイゼーションがカスタマイザＸＹＺおよびカスタマイザＡＢＣという符号を付けられた２つの異なるカスタマによって行われた実施形態が示されている。したがって、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１は、例として、ＸＹＺ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎと命名され、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９３は、例として、ＡＢＣ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎと命名される。

例えば、カスタマイザＸＹＺによって、エンティティ４８０によって識別されるカスタマによって好まれる技師の識別を含めるようにカスタマエンティティ４８０をカスタマイズすることが望まれると仮定する。その場合に、ＸＹＺ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ４９０に、「ｐｒｅｆｅｒｒｅｄ ｔｅｃｈｎｉｃｉａｎ ｐｒｏｐｅｒｔｙ（好ましい技師プロパティ）」と称するＥｘｔｅｎｓｉｏｎプロパティ４９４が含まれる。同様に、カスタマイザＡＢＣによって、エンティティ４８０によって識別されるカスタマに関連する信用限度を含めるようにカスタマエンティティ４８０をカスタマイズすることが望まれると仮定する。その場合に、ＡＢＣ．ＣｕｓｔｏｍｅｒＥｘｔｅｎｓｉｏｎエンティティ４９３に、所与のカスタマに関連する「ｃｒｅｄｉｔ ｌｉｍｉｔ（信用限度）」を識別するＥｘｔｅｎｓｉｏｎプロパティ４９６が含まれる。

サブシステム２４２は、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１および４９３を、それに対応するＥｘｔｅｎｓｉｏｎプロパティ４９４および４９６と共に作成するだけではなく、例として、それぞれ、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１および４９３のそれぞれに対応するＥ−Ｒマップ５１１および５１３ならびにＥ−Ａマップ５１５および５１７も作成する。さらに、サブシステム２４２は、リレーショナルデータベース５１６のテーブル（ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１および４９３および他の関連するデータ構造に対応するデータアクセスシステム２４６を介するなど）を作成する。

最後に、ベースＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４８８が再コンパイルされ、そのＥ−Ｒマップが再生成されて、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙ４９１および４９３との新しい関係が反映される。同様に、Ｅ−Ａメタデータが生成されて、ＥｘｔｅｎｓｉｏｎＥｎｔｉｔｙとの新しい関係も反映される。

図１０には、一実施形態で、エンティティ拡張が図１０で５２１として示されたテーブルに保管されることも示されている。テーブル５２１に、カスタマエンティティ４８０に関連するデータが保管される元のテーブルが含まれることがわかる。元のテーブルは、単純に、エンティティ拡張に対応する複数の追加フィールド５２３および５２５を含むように拡張される。したがって、このテーブルの元の列にある列は、無修正である。拡張は、エンティティ拡張に対応する元の表に単純に追加される。

＜メタデータサブシステム２４８およびメタデータのカスタマイゼーション＞
図１１は、サブシステム２４８によってサポートされるメタデータ構造と、本明細書で「デルタベースのカスタマイゼーション」と称するメタデータカスタマイゼーションを示す図である。図１１のメタデータ構造は、メタデータ構造ツリー５００の一部によって示される。ツリー５００の図１１に示された部分が、例示的であるが、システムのメタデータを定義するはるかに大きいツリーの非常に小さい部分であることを諒解されたい。図１１に示された部分には、このメタデータに、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎ（カスタマ保守画面）をそれ自体に含むＦｏｒｍセクションが含まれることが示されている。Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎには、複数のＴａｂ（タブ）コントロールを有するフィールドが含まれる。Ｔａｂコントロール１は、Ｆｉｅｌｄ（フィールド）１を関連付けられている。Ｆｉｅｌｄ１は、フィールド名、フィールドの背景色、フィールドがイネーブルされているかディスエーブルされているか、フィードの長さ、およびフィールドのデータ型（この場合にはＭａｘＶａｌｕｅである）を含む、複数のプロパティを有する。もちろん、フィールドが、複数の追加プロパティも有することができる。メタデータ構造５００は、メタデータストアに保管される。

メタデータ構造５００をカスタマイズするために、カスタマイザによって、サブシステム２４２へのカスタマイザインターフェースを介してカスタマイゼーション仕様が入力される。

本発明の実施形態では、データ構造５００内のすべての型のメタデータのカスタマイゼーションが、デルタを使用して達成される。デルタは、メタデータ構造５００内での元の形からの変化を表す。カスタマイゼーションに、任意の数ｎ個のデルタを含めることができ、各デルタは、ベースターゲットの既知のインスタンスに対する特定の変化すなわち追加または削除を表す。

値の変更の例として、元のメタデータ構造５００内で、名前「ｆｏｏ」を有するフィールドの背景色が、黄色である。カスタマイザによって、背景色を青にすることが望まれると仮定する。その場合に、カスタマイザは、単一のデルタを含む単一のカスタマイゼーション行う。このカスタマイゼーションは、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１のフィールド「ｆｏｏ」に関する。カスタマイゼーションは、メタデータストアの別々の部分に、またはリレーショナルデータベース５１６にマッピングされるメタデータカスタマイゼーションエンティティ５０２に保管することができる。メタデータストアの一部を形成することができるリレーショナルデータベース５１６内のテーブルが、テーブル５０４によって示され、このテーブル５０４には、ＦｏｒｍｓのＣｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎ部分のフィールドのタブ１の下のフィールド１の背景プロパティを識別するメタデータＩＤが含まれる。テーブル５０４には、デルタを識別するデルタ情報も含まれ、このデルタ情報は、フィールドの背景色が青に変更されることである。したがって、デルタは、修正されるソースのコピーではない。そうではなく、デルタは、構造５００のどのデータを修正しなければならないかの指定のみである。デルタだけを追跡することによって、多数の修正を衝突なしで１つのターゲットに動的に適用することが可能になる。

デルタを適用するために、カスタマイゼーション対応サブシステムは、サブシステム２４２を呼び出し、このサブシステム２４２は、現在のコンテキストでカスタマイゼーションを適用する。例えば、カスタマイゼーション対応サブシステムが、Ｆｏｒｍをロードするサブシステムであると仮定する。さらに、ユーザが、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎを表示することを要求したと仮定する。もちろん、サブシステム２４２によって、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿Ｓｃｒｅｅｎという名前のフォームの現在のコンテキストに適用されるリレーショナルデータベース内のすべてのインスタンスが識別される。サブシステム２４２によって、識別されたインスタンスごとに、カスタマイゼーションが適用される。メタデータに適用されるカスタマイゼーションによって、Ｃｕｓｔｏｍｅｒ＿Ｍａｉｎｔｅｎａｎｃｅ＿ＳｃｒｅｅｎのＴａｂ１の下のＦｉｅｌｄ１の背景色を青に変更することが要求されることがわかる。サブシステム２４２内のコードによって、この変更が行われ、構造５００のカスタマイズされた部分が、画面のレンダリングに使用するために、カスタマイゼーション対応のフォームローダに渡される。

＜デプロイメントサブシステム２４４内の実行ティア（ｔｉｅｒ）＞
デプロイメント／管理サブシステム２４４によって、柔軟なデプロイメント機能が提供される。アプリケーションのコンポーネントを、単一のサイトに置く、外部サイトでホストする、オフラインで使用する、単一のマシンによって使用する、または複数のサーバのインストールで使用する、あるいはこれらの組合せを行うことができる。

実行アーキテクチャは、３つの論理ティアすなわち、レンダリングティア５０３、ワークスペースティア５０５、およびエンタープライズティア５０７に階層化される。３つのティアのすべてを同一のマシンで実行することができ、あるいは、各ティアを別々のマシンで実行することができる。例として、１つのティアをマシンの間で分割することはできない。この階層化によって、アプリケーションを、複数の構成で展開できるようになる。一実施形態によれば、エンタープライズティア５０７が必要であるが、他のすべてのティアは任意選択である。例えば、ユーザインターフェースがない場合にはレンダリングティア５０３がない。

３つの論理サービスによって、プレゼンテーション（またはＵＩ）５０９、エンタープライズプロキシ５１１、およびメッセージレシーバのシナリオを含む異なるシナリオについてこれらのティアがサポートされる。これらのサービスは、すべてのアプリケーションまたはシナリオに関する１つのサービスがないという点で論理サービスである。

レンダリングティア５０３は、ＨＴＭＬまたは他のレンダリングフォーマットを受け入れ、あるデバイスでユーザ用の画面表示を作る。クライアント側だけの実施形態では、製品のエンドユーザが、この層だけと対話する。その場合に、レンダリングティアは、ユーザイベントを受け取り、それらを処理するか、プレゼンテーションサービス５０９に渡す。プレゼンテーションサービス５０９は、レンダリングティア５０３をサポートし、したがって、ユーザインターフェースが存在する時に限って必要である。プレゼンテーションサービス５０９は、レンダリングティア５０３上、ワークスペースティア５０５上、またはこの両方で動作することができる。プレゼンテーションサービス５０９によって、エージェントとの対話が、ユーザに表示されるページにマッピングされる。プレゼンテーションサービス５０９は、ＨＴＭＬを作るか、あるいは、レンダリングエンジンとの異なるコントラクトを有することができる。

ワークスペースティア５０５によって、エンタープライズへの要求が作成され、サブミットされる。これは、コンシューマシステムまたは単一ユーザに関する実行環境である。ワークスペースティア５０５が、エンタープライズティア５０７からオフラインで動作するシナリオでは、エンタープライズプロキシ５１１によって、ローカルストアを含む有用な複数のサービスが提供される。エンタープライズプロキシ５１１は、同期化エンジンとして働き、ワークスペースティア５０５上で動作する。エンタープライズプロキシ５１１は、購入注文を作成する際に使用される製品カタログなど、正しい要求をサブミットするためにエンタープライズ５０７から入手される基準データを保持することができる。したがって、ワークスペースティア５０５によって、エンタープライズプロキシ５１１がエンタープライズであるかのように、エンタープライズプロキシ５１１への要求が行われる。プロキシ５１１は、可能であればそのローカルストアから要求をサービスする。同様に、エンティティを作成するか修正する、保留中の要求も、保管することができる。実際のエンタープライズティア５０７への再接続の際に、エンタープライズプロキシサービス５１１は、保留中のすべての要求をエンタープライズ５０７と一致させ、基準データをリフレッシュする。

エンタープライズティア５０７によって、アプリケーション機能性を実装するビジネスロジックが保持される。エンタープライズティア５０７は、そのデータベース５１３への直接アクセスを提供せず、すべての要求を検証する。エンタープライズティア５０７上のメッセージレシーバサービスが、クライアントから要求を受け取って、データを更新する。メッセージレシーバサービスは、サーバ内のデータ５１３の保全性を保護するために、これらの要求を受け取り、これらの要求に含まれるデータを検証する。クライアントが完全に信頼される場合には、メッセージレシーバサービスは不要である。このサービスは、エンタープライズティア５０７上で動作する。

＜データアクセスサブシステム２４６＞
図１３は、本発明によるデータストレージおよびアクセスシステム５１０の一実施形態を示すブロック図である。システム５１０に、データアクセスサブシステム（またはエンティティパーシスタンスシステム）２４６、リレーショナルデータストア機構５１４、リレーショナルデータベース５１６、およびクラス−テーブルマッピング５１８が含まれる。システム５１０は、例として、テーブルおよび列など、データベーススキームの要素ではなく、エンティティ（またはオブジェクト）およびそのプロパティに関して、保管されたデータを参照できる、オブジェクト−リレーショナル（Ｏ−Ｒ）データストレージシステムである。図１３に、これを行う機構の１つを示す。

図１３からわかるように、データを、エンティティ２２６に関して編成することができる。各エンティティに、例として、メタデータ部分５２２（メタデータサブシステム２４８内のメタデータストアに保管される）および残りの属性部分５２４が含まれる。メタデータ部分５２２によって、エンティティ２２６が記述され、残りの属性５２４によって、エンティティに保管されるデータなど、エンティティ２２６のさらなる属性が定義される。エンティティ２２６の属性のそれぞれが、対応するエンティティテーブル５２６および所与のエンティティテーブル５２６の特定の列５２８にマッピングされる。

データアクセスサブシステム２４６は、クエリ５３０など、検索されるエンティティまたはエンティティの一部あるいはエンティティのグループを指定する、さまざまな形の要求を受け取ることができる。クエリ５３０は、例として、テーブルおよび列に関するのではなく、オブジェクト（「エンティティ」）およびプロパティに関して表すことができる。

どの場合でも、データアクセスサブシステム２４６は、クエリ５３０を受け取り、クラス−テーブルマッピング５１８にアクセスする。この形で、データアクセスサブシステム２４６は、クエリ５３０によって識別されるエンティティのデータの位置を判定することができる。データアクセスサブシステム２４６には、クエリ５３０を、リレーショナルデータストア機構５１４への入力に適するリレーショナルデータベースクエリ５３２に変換するトランスレータ５１３が含まれる。例示的実施形態の１つで、リレーショナルデータストア機構５１４が、米国ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社から入手できるものなどの、リレーショナルデータベース５１６にアクセスするＳＱＬ ＳＥＲＶＥＲデータベースサーバである。したがって、データアクセスサブシステム２４６は、オブジェクトに関するクエリ５３０を受け取り、これらのクエリを、適当なリレーショナルデータベースクエリ５３２に変換し、このリレーショナルデータベースクエリ５３２が、データストア機構（またはサーバ）５１４に供給され、このデータストア機構５１４によって、実際にリレーショナルデータベース５１６内のデータがアクセスされる。

リレーショナルデータストア機構５１４によって、要求されたデータが検索され、リレーショナルデータベース結果５３４の形で返される。この結果は、データアクセスサブシステム２４６に返され、データアクセスサブシステム２４６は、リレーショナルデータベース結果５３４を、要求された結果セット５３６に定式化する。例示的実施形態の１つでは、結果セット５３６が、クエリ５３０で要求される。クエリ５３０は、結果を１つまたは複数のオブジェクトの形または単純にデータセットとして出力することの要求とすることができる。どの場合でも、データアクセスサブシステム２４６によって、リレーショナルデータベース結果５３４が、適当なフォーマットに編成され、結果セット５３６として出力される。

データアクセスサブシステム２４６によって、ユーザおよび開発者から物理的なデータストア（機構５１４およびデータベース５１６）が隠蔽され、ユーザおよび開発者が、データベース５１６のスキーマおよび特定のデータストア機構５１４の構文を知ることを必要とするのではなく、エンティティに関して作業できるようになる。

＜エンティティ２２６の包含階層（ｃｏｎｔａｉｎｍｅｎｔ ｈｉｅｒａｒｃｈｙ）＞
図１４は、オブジェクトまたはエンティティを含む例示的なアプリケーションの階層構造の例を示す図である。図１４からわかるように、エンティティを、メンバ６０２、６０４、および６０６に編成することができ、これらのメンバに、１つまたは複数のエンティティを含めることができる。本明細書で使用されるメンバは、共通の目的を達成するために一緒にグループ化された１つまたは複数のエンティティである。本発明を実施するモジュールに、メンバへの参照が含まれない場合があるが、開発者は、メンバを念頭においてアプリケーションを設計することを望む可能性がある。

例示的実施形態では、エンティティまたはオブジェクトが、親／子関係で編成される。メンバ６０２には、会社のＯｒｄｅｒ（注文）を構成するエンティティが含まれる。具体的に言うと、Ｏｒｄｅｒエンティティ６０８に、小計、税金、運送量、および総計というプロパティなどの情報が含まれる。Ａｄｄｒｅｓｓエンティティ６１０は、Ｏｒｄｅｒエンティティ６０８の子エンティティであり、これには、特定の注文に関する出荷先住所に関連する情報を含めることができる。同様に、Ｏｒｄｅｒエンティティ６０８に、複数のＯｒｄｅｒＬｉｎｅ（注文明細行）エンティティ６１２を含めることができ、各ＯｒｄｅｒＬｉｎｅエンティティ６１２に、さらなる情報を有する１つまたは複数のＯｒｄｅｒＳｅｒｉａｌエンティティ６１４を含めることができる。図１４の表記「ｎ」が、特定のエンティティに複数の同一の構造のエンティティを含めることができることを指すのに使用されることに留意されたい。例えば、上で示したように、１つまたは複数のＯｒｄｅｒＳｅｒｉａｌエンティティ６１４を、ＯｒｄｅｒＬｉｎｅエンティティ６１２の子エンティティ（菱形がついた線６１５によって識別される）とすることができる。

本明細書で示す例では、メンバ６０４が、一般に、Ｃｕｓｔｏｍｅｒ情報に関し、Ｃｕｓｔｏｍｅｒエンティティ６１６を含み、各Ｃｕｓｔｏｍｅｒエンティティ６１６に、１つまたは複数のＡｄｄｒｅｓｓエンティティ６１８を含めることができる。

Ｃｕｓｔｏｍｅｒエンティティ６１６およびＯｒｄｅｒエンティティ６０８は、それぞれ、Ｃｏｍｐａｎｙエンティティ６２０の子エンティティであり、Ｃｏｍｐａｎｙエンティティ６２０の組に、Ｅｎｔｅｒｐｒｉｓｅエンティティ６２２の子エンティティが含まれる。この例では１つまたは複数の通貨（Ｃｕｒｒｅｎｃｙ）エンティティ６２４を含むメンバ６０６も、Ｅｎｔｅｒｐｒｉｓｅエンティティ６２２の子である。

構造の親／子階層６００の他に、この例には、エンティティのクラスの間の一方向の関連も存在する。クラスは、類似する構造を有するエンティティの組である。上で示したように、Ｏｒｄｅｒエンティティ６０８のすべてが、Ｏｒｄｅｒクラスに含まれる。同様に、Ｃｕｓｔｏｍｅｒエンティティ６１６は、Ｃｕｓｔｏｍｅｒクラスに関係する。矢印６２８によって示される関連によって、クラスが別のクラスを知ることができることが示される。この例では、Ｏｒｄｅｒクラスが、Ｃｕｓｔｏｍｅｒクラスについて知るが、親／子関係の場合のようにＣｕｓｔｏｍｅｒクラスを組み込むか所有してはいない。

＜エンティティ２２６のエンティティキー＞
エンティティによって、データが管理される。エンティティによって、その内部データおよび他のエンティティとの関係の保全性が保持される。エンティティのデータは、プロパティを介してアクセスされる。各エンティティは、抽象化の１つの形である。エンティティの特性に、抽象クラス「ＥｎｔｉｔｙＫｅｙ」のサブクラスによって表される識別を有することが含まれる。階層全体の中で、構造６００内のデータを管理する各エンティティは、そのデータがどこに保管され、誰が所有するかを知らないという点で、位置独立である。しかし、ＥｎｔｉｔｙＫｅｙは、他のエンティティとの関係を定義するのに使用され、図１４の接続によって表されるものとみなすことができる。

エンティティのインスタンスを、別のエンティティのインスタンスに含めることができる。含まれるエンティティを子と呼び、コンテナを親と呼ぶ。子インスタンスは、親より長く存在することができず、１つの親だけを有しなければならない。あるアプリケーションのそのような関係すべての組が、その包含階層である。この種の階層は、多くのビジネスアプリケーションに似る。この階層をサポートすることによって、このシステムが、ビジネスアプリケーションを構築する際に開発者によりよく適するようになることがわかっている。

図１４は、アプリケーションの包含階層の例を示す図である。包含階層によって、エンティティの型およびそれに対応する親子関係が記述される。ここで「Ｅｎｔｅｒｐｒｉｓｅ」エンティティ６２２として図示された、包含階層のルートがある。ルートコンテナまたはルートエンティティによって、包含階層のサーバのアドレスが供給されるが、クラスまたはインスタンスを、他のサーバまたはコンピュータ可読メディアに配置することができる。一実施形態では、ルートエンティティによって、サーバのＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｍｏｔｅ Ｌｏｃａｔｏｒ）が供給される。この実施形態では、コンテナのもう１つの広義のクラスが、Ｃｏｍｐａｎｙエンティティ６２０である。

包含階層が、継承階層と同一でないことに留意されたい。継承階層は、最上位を除く各項目が、その上位の項目の特殊化された形である、関係の分類である。図１４に示した例では、Ｏｒｄｅｒクラス６０８およびＣｕｓｔｏｍｅｒクラス６１６は、Ｃｏｍｐａｎｙクラス６２０の特殊化された形ではない。そうではなく、Ｏｒｄｅｒクラス６０８およびＣｕｓｔｏｍｅｒクラス６１６は、異なる型の情報を保持する異なるクラスである。これは、包含階層に継承が存在することができないと言っているのではない。いくつかの実施形態で、継承階層が、任意のクラスについて存在することができる。したがって、例えば、Ｃｕｓｔｏｍｅｒクラス６１６の変形など、クラス内の変形を設けることができる。

アプリケーションには、３つの形のエンティティがある。この形には、コンポーネントコンテナ「Ｅｎｔｅｒｐｒｉｓｅ」６２２および「Ｃｏｍｐａｎｙ」６２０と、プライマリエンティティと、サポーティングエンティティが含まれる。プライマリエンティティまたはルートエンティティは、同一の名前のコンポーネントコンテナの焦点であり、サポーティングエンティティは、プライマリエントリの子またはそのピアのいずれかである。例えば、Ｏｒｄｅｒメンバ６０２は、Ｏｒｄｅｒルートエンティティ６０８からなり、Ａｄｄｒｅｓｓ６１０、ＯｒｄｅｒＬｉｎｅ６１２、およびＯｒｄｅｒＳｅｒｉａｌ６１４は、サポーティングエンティティである。エンティティのデータは、通常は、図１３に関して上で説明したものなどのデータベーステーブルに保管される。コンポーネントは、論理設計の単位であり、データベースと対話しない。

上述したように、あるエンティティのプロパティのそれぞれが、図１３に示された、対応するエンティティテーブルおよび所与のエンティティテーブルの特定の列にマッピングされる。各エンティティテーブルには、属性の列のほかに、特定のエンティティのすべての親を識別する１つまたは複数の列も含まれる。図１５を参照し、例としてＯｒｄｅｒＳｅｒｉａｌを使用すると、ＯｒｄｅｒＳｅｒｉａｌテーブル６５０に、識別子の列、具体的には、「Ｃｏｍｐａｎｙ＿ｉｄ」６５２、「Ｏｒｄｅｒ＿ｉｄ」６５４、ＯｒｄｅｒＬｉｎｅ＿ｉｄ６５６およびＳｅｒｉａｌ Ｎｕｍｂｅｒ６５８が含まれ、これらに、属性の１つを含めることができ、これらは、それ自体の識別子（ｉｄ）として機能することができる。

リレーショナルデータベースでは、特定のエンティティに関連するデータ、この例では特定のＯｒｄｅｒＳｅｒｉａｌエンティティ６１４に関連するデータを識別し、操作するために、テーブルとの対話で、識別子のそれぞれを指定することが必要になる。しかし、この情報は、包含関係の親から推論される。例えば、特定のＯｒｄｅｒＬｉｎｅエンティティ６１２を操作しており、あるＯｒｄｅｒＳｅｒｉａｌエンティティ６１４に関して尋ねるか、それに対するアクションを実行したい場合に、データアクセスサブシステム２４６によって、エンティティの親を再識別する必要なしに、ユーザが参照している１つまたは複数のＯｒｄｅｒＳｅｒｉａｌエンティティを確認することができる。本発明では、包含階層を用いると、テーブルの関係（すなわち識別子）、したがってエンティティの関係を、暗黙の背景情報にすることができる。言い換えると、エンティティの識別は、親／子関係から推論され、その結果、他の形で再記述するか管理する必要がなくなる。リレーショナルデータベースシステムでは、エンティティを識別するのに使用されるテーブル内の識別子を、主キーと呼び、ここで、その識別子の組合せは、一意である。しかし、通常、主キーは、列の集合にすぎず、豊富な挙動を付加されていない。さらに、ユーザが選択した識別子は、あるスコープ（単一のビジネス単位など）内でのみ一意であり、アプリケーションの範囲全体で一意でない場合がある。一般的にアプリケーションによって生成され、ユーザから隠蔽される代理キーは、一意である可能性があるが、識別子によって参照されるエンティティの親がどれであるかなどの階層は記述されない。

本発明のもう１つの態様が、これらの問題を解決するＥｎｔｉｔｙＫｅｙであり、具体的には、各エンティティに関連するＥｎｔｉｔｙＫｅｙによって、包含階層全体を通じて各エンティティを一意にすることができ、包含階層内のエンティティの位置から、親がどれであるかを推論することができる。エンティティは、エンティティキーまたは言い換えるとエンティティのキーによって識別されるオブジェクトである。ＥｎｔｉｔｙＫｅｙは、リレーショナルテーブルの主キーと同一の機能をサービスするが、リレーショナル主キーと異なって、アプリケーション空間全体を通じてユニバーサルに一意であり、階層的すなわち、階層内の位置がわかっている。このアーキテクチャでは、ＥｎｔｉｔｙＫｅｙは、エンティティとは別個の、定義されたクラスである。ＥｎｔｉｔｙＫｅｙクラスを、リレーショナルデータベーステーブルにマッピングすることができる。階層全体のすべてのエンティティが、唯一のＥｎｔｉｔｙＫｅｙ値を有する。エンティティのキーを与えられれば、それがローカルサーバ上にあっても、インターネットなどの広域ネットワークに配置されていても、そのエンティティを検索することができる。

各ＥｎｔｉｔｙＫｅｙには、この概念において、３つの情報すなわち、それが参照するエンティティの型またはクラス、それが参照するエンティティのＩＤ、およびそのエンティティの親のＥｎｔｉｔｙＫｅｙに関する情報が含まれる。図１６は、特定のＯｒｄｅｒＳｅｒｉａｌエンティティ６１４ＡのＥｎｔｉｔｙＫｅｙ（ここではＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙ）６８０Ａの絵図表現である。

階層内のエンティティは、その識別子と親の識別子によって完全に識別される。この形で、同一のローカル識別子を、空間全体の複数の位置で使用することができる。というのは、エンティティを一意に識別するのに異なる親が使用されるからである。これは、図１４のＥｎｔｅｒｐｒｉｓｅ空間を絵図的に表すことによってより簡単に諒解できる。図１７を参照すると、Ｅｎｔｅｒｐｒｉｓｅが、円７００によって示されている。Ｅｎｔｅｒｐｒｉｓｅ７００に、複数の会社、ここではＣｏｍｐａｎｙ Ａ７０２およびＣｏｍｐａｎｙ Ｂ７０４を含めることができる。しかし、各Ｃｏｍｐａｎｙ７０２および７０４は、両方が同一の識別子、ここでは「Ｏｒｄｅｒ １」７０６および「Ｏｒｄｅｒ ２」７０８を有する２つのＯｒｄｅｒを有することができる。それでも、Ｃｏｍｐａｎｙ Ａ７０２内のエンティティは、Ｏｒｄｅｒ １ ７０６およびＯｒｄｅｒ ２ ７０８の識別子が各Ｃｏｍｐａｎｙ内で使用されていても、Ｃｏｍｐａｎｙ Ｂ７０４のエンティティに関して一意に識別される。というのは、エンティティのそれぞれが、階層の親／子関係を有する関連するキーによって一意に識別されるからである。

多くのアプリケーションで、Ｃｏｍｐａｎｙ Ａのデータが、Ｃｏｍｐａｎｙ Ｂのデータと完全に異なるデータベースに保管されることに留意されたい。

本明細書でＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙとして識別される、ＯｒｄｅｒＳｅｒｉａｌ６１４に関連する別々の独立のクラスもある。一般に、ＥｎｔｉｔｙＫｅｙは、それが参照するクラスとは別のクラスである。エンティティ６８０Ａは、ＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙクラスのオブジェクトの例である。図１６を参照すると、ＯｒｄｅｒＳｅｒｉａｌエンティティ６１４Ａに、Ｏｒｄｅｒ Ｓｅｒｉａｌに関連するすべての属性７２０が含まれ、これは、任意の数の属性とすることができる。ＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙ６８０Ａには、ＯｒｄｅｒＳｅｒｉａｌエンティティ６１４Ａの１つまたは複数の属性のサブセットが含まれ、具体的には、ＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙに、識別子属性７２２が含まれる。したがって、ＯｒｄｅｒＳｅｒｉａｌエンティティ６１４Ａに、１０００個の属性が含まれるが、その属性のうちの２つによって、各ＯｒｄｅｒＳｅｒｉａｌエンティティが一意になる場合には、これらの属性がＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙにコピーされて、エンティティへの識別子が形成される。矢印７２４は、エンティティ６１４Ａとエンティティ６８０Ａの間の１つまたは複数の共通の識別子属性を表す。

ＯｒｄｅｒＳｅｒｉａｌの各エンティティを一意にする、ＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙの属性は、ＥｎｔｉｔｙＫｅｙの最初の要素であり、これによって、キーを特定のエンティティに関連付けられるようになる。

ＥｎｔｉｔｙＫｅｙの第２の要素は、それに対する識別子を有するエンティティの型７２６である。この例では、クラスの型はＯｒｄｅｒＳｅｒｉａｌである。

ＥｎｔｉｔｙＫｅｙの第３の要素は、エンティティの親のＥｎｔｉｔｙＫｅｙに関する情報である。この実施形態では、この情報が、矢印７３０によって示される、エンティティ６１４Ａの親に対応する親キー７４０への参照である。言い換えると、第３の要素を、別のキーへの参照とすることができる。この構造によって、ＥｎｔｉｔｙＫｅｙｓが再帰的に定義されるようになる。しかし、望まれる場合に、親キー情報の一部またはすべてを、ＥｎｔｉｔｙＫｅｙに直接に保管することができることに留意されたい。ＥｎｔｉｔｙＫｅｙ情報の保管およびアクセスに関するこの形および他の類似する形が、本明細書に含まれることが意図されていることを理解されたい。

図１８を参照すると、ＥｎｔｉｔｙＫｅｙｓが、Ｃｏｍｐａｎｙのエンティティ、Ｏｒｄｅｒのエンティティ、ＯｒｄｅｒＬｉｎｅのエンティティ、およびＯｒｄｅｒＳｅｒｉａｌのエンティティについて設けられる。この例では、ＩＤが、１フィールドからなり、型を、キーの名前から確かめることができる。例えば、型ＯｒｄｅｒＳｅｒｉａｌは、名前ＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙから得られる。親キーへの参照が、矢印によって示される。したがって、やはり、階層内のエンティティの位置は、関連するＥｎｔｉｔｙＫｅｙによって完全に定義される。

ＥｎｔｉｔｙＫｅｙ保管の再帰的な形では、各ＥｎｔｉｔｙＫｅｙに、それが関連する型またはクラス情報が含まれるが、各ＥｎｔｉｔｙＫｅｙは、その親の型またはクラスを知らないことに留意されたい。この情報は、それが参照する親キーの型情報を調べることによって見つかる。これは、包含階層を介してクラスを再利用できるようになるので、特に有利な特徴である。図１４を参照すると、Ｏｒｄｅｒクラス６０２が、Ａｄｄｒｅｓｓの子クラス６１０を有することが示されている。同様に、Ｃｕｓｔｏｍｅｒクラス６１６も、Ａｄｄｒｅｓｓの子クラス６１８を有する。Ａｄｄｒｅｓｓクラス６１０および６１８は、実際に概念的に同一であるが、インスタンスは、異なる親の下にあるのでばらばらである。しかし、これらのエンティティは、Ａｄｄｒｅｓｓクラスのそれぞれの形で一意に定義され、各Ａｄｄｒｅｓｓクラス６１０および６１８を、異なるデータベーステーブルに保管することができる。この形で、クラスを永久に強制的にその位置にとどめずに、包含階層内の位置を記述することができる。

上述したように、各ＥｎｔｉｔｙＫｅｙは、親キーへの参照などの情報を有するが、親がどの型であるかは知らない。親の型の判断は、クラスおよびテーブルの完全な組のマッピングによって、行われるか定義される。

ＥｎｔｉｔｙＫｅｙの図１６に示された識別子７２２の組は、そのエンティティのデータを保持するテーブルの主キー列に対応する。図１５を参照し、ＯｒｄｅｒＳｅｒｉａｌエンティティを保持するテーブルの主キーが、Ｃｏｍｐａｎｙ＿ＩＤ６５２、Ｏｒｄｅｒ＿ＩＤ６５４、ＯｒｄｅｒＬｉｎｅ＿ＩＤ６５６、およびＳｅｒｉａｌ Ｎｕｍｂｅｒ６５８であると仮定する。ＯｒｄｅｒＳｅｒｉａｌ．Ｋｅｙ６８０Ａ内の識別子属性７２２は、主キー列の最後に直接にマッピングされ、６８０Ａの親キーは、類似する形で列６５２、６５４、および６５６にマッピングされる。このＥｎｔｉｔｙＫｅｙとデータベースキーの対応は、外部キーにも拡張される。エンティティの間の単純な関連のすべてが、キーを使用して実施される。例えば、図１４で、Ｏｒｄｅｒ．Ｋｅｙは、ＯｒｄｅｒからＣｕｓｔｏｍｅｒへの関連を実施する、型Ｃｕｓｔｏｍｅｒ．Ｋｅｙの参照を有する。このキーを、ＯｒｄｅｒテーブルのＣｕｓｔｏｍｅｒ外部キーに簡単にマッピングすることができる。

テーブルが、インテリジェントキーではなく代理を用いて共通して設計されることにも留意されたい。インテリジェント主キーは、エンドユーザによって見られ、指定されるが、代理主キーは、アプリケーションによって生成され、ユーザから隠蔽される。代理キーは、しばしば、データベースに影響せずにテーブルの、ユーザに可視の識別子の名前を変更できるようにするか、主キーのサイズが非常に大きく、しばしば外部キーで参照される時にスペースを節約するのに使用される。代理キーが使用される時には、テーブルが、代理主キーおよびユーザに可視の識別子を有する代替キーを有する。

インテリジェントおよび代理の両方のＥｎｔｉｔｙＫｅｙｓがサポートされる。この実施形態では、代理ＥｎｔｉｔｙＫｅｙが使用される時に、そのＩＤプロパティがプライベートになり（それが生成されたキーであり、エンティティのコンシューマにとって意味がないので）、そうでない場合には、ＩＤプロパティはパブリックになる。

＜クラスキー＞
もう１つの関連する抽象化が、クラスキーである。所与のエンティティを、包含階層内の複数の場所で使用することができるので、階層内のどのノードが処理されるかを示す機構がある。クラスキーは、その機構であり、クラスキーには、２つの情報すなわち、それが参照するエンティティの型と、そのエンティティの親のクラスキーに関する情報が含まれる。ＥｎｔｉｔｙＫｅｙの定義に似ていることに留意されたい。実際に、ＥｎｔｉｔｙＫｅｙは、クラスキーの派生物であり、クラスキーから継承し、これによって、クラスキーが要求されるすべての場所でＥｎｔｉｔｙＫｅｙを供給できるようになっている。したがって、クラスキーも、階層的に定義される。図１８のＥｎｔｉｔｙＫｅｙの図を、単純にエンティティ識別子（ＩＤ）を除去することによって、クラスキーの図に変更することができる。

一般に、クラスキーを使用して、包含階層内のノードを参照することができる。というのは、クラスキーが、エンティティのクラスに関連し、特に階層内の各クラスの名前および階層内の位置を一意に記述するからである。対照的に、ＥｎｔｉｔｙＫｅｙは、包含階層内の各エンティティの一意の名前を提供し、階層内のその位置を記述する。

ＥｎｔｉｔｙＫｅｙおよびクラスキーは、ビジネスオブジェクトまたはエンティティに対する作成、読取、更新、および削除の動作が実行される時に使用される。例えば、エンティティを読み取る時に、コンポーネントコンテナを参照する親キーを供給しなければならない。これによって、読取のスコープが与えられ、開発者が階層内の複雑な位置を指定するのが簡単になる。

ＥｎｔｉｔｙＫｅｙおよびクラスキーのほかに、もう１つの形のキーが、これらのキーの間の混合物である。上述したように、ＥｎｔｉｔｙＫｅｙは、クラスキーの一形態であるが、特定のエンティティに対するさらなる情報（すなわち識別子属性）が含まれる。クラスキーのチェーンとそれに続くエンティティキーを単純に使用することによって、特定の親の下のすべてのエンティティを突き止めることができる。図１９に、混合されたキー８４４の例を示す。この例では、ＥｎｔｉｔｙＫｅｙが、Ｅｎｔｅｒｐｒｉｓｅ、Ｃｏｍｐａｎｙ、およびＯｒｄｅｒについて提供され、このＯｒｄｅｒによって、特定のＯｒｄｅｒエンティティが指定される。しかし、ＯｒｄｅｒＬｉｎｅ．ＫｅｙおよびＯｒｄｅｒＳｅｒｉａｌ．ＫｅｙにはＩＤが含まれないので、これらはクラスキーである。図１９の混合されたキー８４４を、データアクセスサブシステム２４６によって受け取って、データ保管機構に関するクエリを定式化して、特定の注文に関するすべての系列を、その行に無関係に検索することができる。

＜ファウンデーションサービス２５２＞
フレームワークに基づく型の作成（エンティティ、ファクトリ、キー、プロセス、およびサービスなど）は、フレームワーク内のアクティベーションシステムによって達成される。他のすべての型（値型など）は、他のオペレータを用いて作成される。エンティティの作成が、１つの位置で行われるので、複数の特徴を実施することができる。第１に、ファウンデーションサービスサブシステム２５２によって、ある型のインスタンスを作成する要求を与えられた場合に、正しいバージョンアセンブリを見つけることができる。さらに、エンティティ置換を用いると、既存のビジネスロジックに影響せずに、ある型のインスタンスが必要な時にその型のサブクラスを置換できるようにすることによって、開発者がクラスに新しい機能性を追加できるようになる。サブクラスがアクティベーションによって自動的に生成されるプロキシである、エンティティ置換のある形を使用することもできる。プロキシによって、インスタンスが変更された時のシステム呼出しトラッキング、およびあるクラスの読取専用アクセスの保証を含むさまざまな機能性を追加することができる。

診断および計装によって、ファウンデーションサービス２５２内のロギングサービス、トレースサービス、およびアカウンティングサービスが提供される。アプリケーションに、これらのサービスを実行するための診断への呼出しを設けることができる。アプリケーションフレームワークによって、ランタイム呼出しインターセプトを使用して、アプリケーション開発者の代わりに診断を呼び出すことができる。

＜ロールベースセキュリティサブシステム２４０＞
ロールベースセキュリティサブシステム２４０によって、さまざまなセキュリティ方式を作成するのに必要な基本プリミティブが提供される。例えば、ＵｓｅｒおよびＲｏｌｅは、セキュリティサブシステム２４０によって提供されるエンティティのクラスである。サブシステム２４０によって、任意の数の識別を単一のＵｓｅｒクラスにマッピングすることができ、複数の認証機構を使用できるようになる。セキュリティサブシステム２４０によって、ＵｓｅｒまたはＲｏｌｅとエンティティの間でカスタム許可（ｃｕｓｔｏｍ ｐｅｒｍｉｓｉｏｎ）を適用するフレームワークも提供される。例えば、ある照会ビューによって、どのＵｓｅｒまたはＲｏｌｅの読取、更新、またはクエリの実行を行えるかを示すクエリ定義にセキュリティを適用することができる。サブシステム２４０のアクセス許可の特徴は、カスタム許可を作成する一貫性のある機構を提供し、その実装の多くも提供する。

タスクは、セキュリティサブシステム２４０に関して説明したアクセス権フレームワークを使用して構築されるエンティティまたはアクティビティである。ＵｓｅｒクラスおよびＲｏｌｅクラスに、タスクを実行するためのアクセス権を与えることができる。タスクを使用するために、セキュリティまたは方法に、２つのステップが含まれる。まず、カスタム属性を使用して、タスクのＩＤ、名前、および記述を指定して、タスクを定義しなければならない。次に、インペラティブまたは宣言型のセキュリティ検査を、別の属性を有するタスクについて提供しなければならない。この「ＴａｓｋＰｅｒｍｉｓｓｉｏｎＡｔｔｒｉｂｕｔｅ」によって、セキュリティチェックが失敗する場合に例外が送出される。下の表５に、これらのステップを実行する擬似コードを示す。

表５

このコードでは、「ＴａｓｋＡｔｔｒｉｂｕｔｅ」を用いてタスクを定義し、「ＴａｓｋＰｅｒｍｉｓｓｉｏｎＡｔｔｒｉｂｕｔｅ」を用いて宣言型のセキュリティチェックを指定している。セキュリティチェックが失敗する場合に、例外が送出され、メソッドは実行されない。

データを、セキュリティサブシステム２４０を使用して保護することもできる。各アプリケーションは、データアクセスを制限する方法に関して異なる要件を有する可能性があり、したがって、単一のソリューションを提供するのではなく、セキュリティサブシステム２４０によって、データアクセスフレームワークを提供する。データアクセスサブシステム２４６へのインターフェースのそれぞれを実装し、データにアクセスする時の使用に対する動的ビューを指定する能力を追加するセキュアクラスラッパを提供することによって、基本的な機構によって、データアクセスサブシステム２４６へのすべてのデータアクセス要求がインターセプトされる。管理者は、動的ビューを作成して、ＵｓｅｒおよびＲｏｌｅのデータアクセス権を定義することができる。動的ビューによって、セキュリティデータアクセスポリシが、見、更新することができる、基礎になるエンティティのプロパティのリストと組み合わされる。その後、ＵｓｅｒおよびＲｏｌｅに、データにアクセスする時に特定の動的ビューを使用するためのアクセスが与えられる。セキュアデータアクセスポリシによって、データアクセスセキュリティポリシが定義され、開発者は、それから派生させ、カスタム論理を追加することによって、カスタムポリシを作成することができる。

セキュリティ方式の３つの例示的な例に、パススルーフィルタが含まれる。データアクセスサブシステム２４６に関する要求が行われる時に、このフィルタによって、判断基準の「ｗｈｅｒｅ」文節に制限が追加され、返されるエンティティが制限される。もう１つの手法が、エンティティごとのアクセス制御手法である。結合テーブルに、ＵｓｅｒまたはＲｏｌｅがアクセスできるエンティティのそれぞれがリストされる。もう１つの手法が、階層フィルタリング手法である。例えば、マネージャが、部下の情報を見ることができ、その逆を不可能にすることができる。これは、通常は、階層をフラットにして新しいエンティティにし、データアクセスサブシステム２４６について行われるアクセス要求の判断基準において、そのエンティティに結合を追加することによって実施される。

＜レポート作成およびクエリサブシステム２３２＞
図２０Ａ、図２０Ｂおよび図２０Ｃは、リレーショナルデータベースに保管されたユーザのデータのオブジェクトモデル記述からクエリ可能なエンティティ（ビジネスインテリジェンスエンティティまたはＢＩエンティティと称する）を生成するシステムを示す図である。

図２０Ａは、オブジェクトモデルからクエリ可能なＢＩ２６２を生成する一実施形態の単純化されたブロック図である。図２０Ａには、モデルサービスシステム９５０が示され、このモデルサービスシステム９５０は、入力として、焦点９５２、オブジェクト記述９５４、および１組の永続データストアマッピング９５６の指定をとる。システム９５０は、入力に基づいて次元モデル９５８を作る。図２０Ａには、エンティティジェネレータ９６０も示され、このエンティティジェネレータ９６０は、次元モデル９５８に基づいて、本明細書でビジネスインテリジェンスエンティティ（またはＢＩエンティティ）９６２と称する１組のオブジェクト（またはエンティティ）を生成する。

焦点９５２は、分析の焦点としてユーザによってマークされた、オブジェクトモデル内のあるデータを表す。焦点９５２は、例として、ＸＭＬ指定ファイルで指定することができる。

オブジェクト記述９５４は、オブジェクトの組に対応するメタデータの組のオブジェクト指向関係を記述する入力である。これは、例えば、ＵＭＬクラス図の形とすることができる。複数のビジネスエンティティ（Ｃｕｓｔｏｍｅｒ、Ｏｒｄｅｒ、およびＯｒｄｅｒＬｉｎｅ）に関するＵＭＬクラス図の１例を、図２０Ｂに示す。

永続データストアマッピング９５６によって、オブジェクトモデルによって参照されるデータが、永続データストア、１つの例示的実施形態では図１３に示されたリレーショナルデータベース５１６にマッピングされる。これは、例として、マップファイルの形でユーザによって作成される。

モデルサービスシステム９５０は、入力９５２、９５４、および９５６を受け取り、これらの入力に基づいて、次元モデル９５８を自動的に生成する。本発明の一実施形態によれば、次元モデル９５８は、ユーザによって供給される入力から推論され、モデル９５８を得るために開発者の第２の組がビジネスロジックの再作成にかかわる必要はない。一実施形態では、下で詳細に説明するように、モデルサービスシステム９５０によって、オブジェクトモデル記述９５４によって指定されるオブジェクトモデルの関連およびコンポジションが使用されて、次元モデル９５８内の外部キー関係が推論される。システム９５０によって、ファイル９５２でユーザによって定義された分析の焦点および永続データストアマッピング９５６も使用されて、次元モデル９５８が作成され、モデル９５８を介してデータがアクセスされる。

しかし、次元モデル９５８を自動的に生成するシステムでさえ、改良することができる。例えば、次元モデル９５８を介して情報を得ることは、まだ、ＭＤＸまたはある種の次元モデル照会言語をユーザが知っていることを必要とする。したがって、もう１つの実施形態によれば、エンティティジェネレータ９６０が設けられる。エンティティジェネレータ９６０は、次元モデル９５８のキューブおよび次元から、オブジェクトの形のビジネスインテリジェンスエンティティ９６２を作成する。以下に詳細に説明する。

図２０Ｃは、図２０Ａに示されたシステムを詳細に示す図である。図２０Ｃに示された例では、オブジェクトモデルが、オブジェクト記述９５４によって表され、マッピング９５６が、オブジェクトモデル表現９５４と、リレーショナルデータベース５１６を表すリレーショナルデータベース表現９６４との間に示されている。図２０Ｃには、次元モデル９５８も詳細に示されている。次元モデル９５８には、Ｆａｃｔテーブル９６６が、複数の次元９６８および９７０（Ｃｕｓｔｏｍｅｒ次元およびＯｒｄｅｒ次元）と共に含まれる。次元のそれぞれが、１つまたは複数のテーブルから形成される。Ｆａｃｔテーブル９６６に、外部キー参照としてＯｒｄｅｒｌｉｎｅＩＤおよびＣｕｓｔｏｍｅｒＩＤが含まれることも特筆に値する。

図２０Ｃには、１組のＢＩエンティティ９６２の一実施形態も示されている。図２０Ｃに示された例では、ＢＩエンティティ９６２に、ＢＩＯｒｄｅｒＦａｃｔエンティティ９７６、ＢＩＯｒｄｅｒエンティティ９７２、およびＢＩＣｕｓｔｏｍｅｒエンティティ９７４が含まれる。エンティティ９７２および９７４は、エンティティ９７６に関連する。

オブジェクトモデル記述９５４内のエンティティおよびその関係を調べることによって、この次元モデルが、次元モデル表現９５８に示されたものなどのスノーフレークスキーマ（ｓｎｏｗｆｌａｋｅ−ｓｃｈｅｍａ）を必要とすることがわかる。したがって、２つの次元、ＯｒｄｅｒおよびＣｕｓｔｏｍｅｒが作成されることを推論することができる。Ｏｒｄｅｒ次元は、ＯｒｄｅｒおよびＯｒｄｅｒＬｉｎｅという２つのレベルを有する。Ｆａｃｔテーブル９６６内の測定値（または数値）に、ＵｎｉｔＰｒｉｃｅおよびＱｕａｎｔｉｔｙが含まれ、これらは、ＯｒｄｅｒＬｉｎｅエンティティから来る。

レポート作成およびクエリサブシステム２３２には、他のクエリへのリンク機能を提供し、ユーザが、関連する情報のガイド付きナビゲーションを実行できるようにする、エンティティ関係に関する情報も保管される。例えば、図２１に、モデルの型と、サブシステム２３２がその情報をどのように使用するかが示されている。図２１に示されたモデルによって、Ｃｕｓｔｏｍｅｒが、０個以上のＯｒｄｅｒを有し、そのＡｄｄｒｅｓｓｅの親である（塗り潰された菱形によって示される）ことが示される。図２１の下部のウェブページに、カスタマリストが示されている。コンテキストメニューが、カスタマの１つの上で開かれ、そのカスタマの注文および住所へのナビゲーションが可能になっている。例えば、そのメニューから「ｏｒｄｅｒｓ」を選択すると、そのカスタマの注文のリストが表示される。

Ｃｕｓｔｏｍｅｒエンティティ、Ａｄｄｒｅｓｓエンティティ、およびＯｒｄｅｒエンティティを超えてこの機能を実行するために、コードは不要である。エンティティに関連するがその直接の部分ではないさまざまな情報がある。その情報には、他のエンティティへの関連のリスト、エンティティの有効なワークフロー状態遷移、エンティティに対して実行できるタスク、およびエンティティに関連するウェブサイトへのハイパーリンクが含まれる。図２１では、コンテキストメニューが、２つの関連するエンティティを有する。

図２２は、情報をユーザおよび開発者が拡張できるようにするために、エンティティに関連する情報の別個の部分に対する共通クエリインターフェースを提供する、サブシステム２３２に関連するハイパーメディアサブシステムを示す図である。このインターフェースは、ハイパースペースに基づき、このハイパースペースは、リンクによって接続されたノードのユニバースである。エンティティが、ノードの例であり、タスクまたは関連するエンティティがリンクの例である。

上述したように、アプリケーションを開発する時には、オブジェクトの組（ビジネスアプリケーションのビジネスオブジェクトまたはエンティティ）を定義することが一般的である。ビジネスアプリケーションのそのようなオブジェクトには、例えば、「Ｃｕｓｔｏｍｅｒ」オブジェクト、「ＳａｌｅｓＰｅｒｓｏｎ」オブジェクト、および「Ｏｒｄｅｒ」オブジェクトを含めることができる。これらのオブジェクト（エンティティ）は、異なる関連を介して相互に関係する。例えば、「Ｏｒｄｅｒ」は、「Ｃｕｓｔｏｍｅｒ」および「ＳａｌｅｓＰｅｒｓｏｎ」の両方を関連付けられる。これらの関連は、アプリケーションの問題領域内に存在するので、通常はエンドユーザが理解する関連である。したがって、エンドユーザがこれらの関連の間をナビゲーションできるようにすることが有益である可能性がある。

これらの関連を定義する情報は、アプリケーション開発時に、アプリケーションのメタモデル（またはオブジェクトモデル）に取り込まれる。この情報は、通常は、メタデータとして保管される。例えば、図２０Ｂに、「Ｏｒｄｅｒ」エンティティと「Ｃｕｓｔｏｍｅｒ」エンティティの間の、アプリケーション開発プロセス中にモデリングされる関係が示されている。

アプリケーションの開発中に生成されるオブジェクトモデルに対して実行することができる既知のツールがある。そのようなツールによって、モデルが関連メタデータにコンパイルされる。図示の実施形態によれば、これが行われ、関連メタデータが保管される。

図２２は、保管された関連メタデータを活用するハイパーメディアシステムの実施形態のブロック図である。ハイパーメディアシステム９０１には、クライアント９０３、ハイパーメディアサービス９０４、および複数のハイパーメディアプロバイダ９０８、９１０、および９１２が含まれる。図２２には、システム９０１に、メタデータストア９０２に接続されたメタデータハイパーメディアプロバイダ９００が含まれることが示されている。

アプリケーション開発プロセス中に開発されるメタデータ関連（「Ｏｒｄｅｒ」エンティティと「Ｃｕｓｔｏｍｅｒ」エンティティの間の関連を示す図２０Ｂに示された情報など）は、メタデータストア９０２に保管される。

メタデータハイパーメディアプロバイダ９００は、ハイパーメディアサービス（ＨＭＳ）９０４に正しく登録され、そのリンクおよびそれをリンクプロバイダとして識別する識別データが、プロバイダレジスタ９０６に常駐すると仮定する。クライアント９０３は、まず、クライアントが探すリンクのソースであるオブジェクトと、どのカテゴリのリンクを検索するかを指定するハイパーメディア要求（またはリンク要求）を生成する。この要求が、ＨＭＳ９０４によって受け取られる。ＨＭＳ９０４は、この要求を適当なプロバイダに転送する。プロバイダ９０８から９１２は、単純に、それが供給するように構成された、要求されたリンクを返す。リンク要求を、ＨＭＳ９０４によってメタデータハイパーメディアプロバイダ９００にも転送することができる。その場合に、プロバイダ９００は、メタデータストア９０２に含まれる関連情報を分析する。プロバイダ９００は、メタデータストア９０２内の、要求された関連のそれぞれを調べ、関連するエンティティにアクセスする権利をユーザが有するかどうかを判定する。プロバイダ９００は、セキュリティサブシステムにアクセスすることによるか他の適当な形で、関連するエンティティにアクセスする権利をユーザが有するかどうかを判定することができる。その後、プロバイダ９００は、ユーザがアクセスできる関連のそれぞれのリンクを作成し、関連情報をそのリンクに置く。プロバイダ９００は、（例えば、Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ（ＵＭＬ）によって定義された用語法を使用して）単純関連およびコンポジション関連を識別する；これらは、１対１、１対多、または多対多関係など、さまざまな濃度を有することができる。プロバイダ９００は、継承関連も識別する。プロバイダ９００によって突き止められた関連ごとに、プロバイダ９００は、ソースノードと関連ノードの間のリンクを作成する。

リンクが、プロバイダ９００からＨＭＳ９０４に返され、ＨＭＳ９０４によって、返されたすべてのリンクが集約され、クライアント９０２に転送される。一実施形態では、プロバイダ９００が、関連するノードを返すのではなく、実行された場合に関連するノードだけが結果に含まれることになるクエリを返す。

図２３は、クエリサービスがクライアントにレンダリングされる、サブシステム２３２に関連するクエリサービスシステムのもう１つの実施形態を示す図で、１つの例示的実施形態による、サブシステム２３２の一部を形成するクエリサービスシステム９２５のブロック図である。クエリサービスシステム９２５には、クライアント９０５が、クエリビルダ９０７、メタデータサブシステム２４８、ハイパーメディア検索／トラバーサルシステム９０１（図２２に図示）、クエリサービスサブシステム９１１（図１３に示されたデータアクセスおよびストレージシステム５１０に結合される）、およびエンティティフォルダシステム９１５に機能的に結合されることが示されている。クライアント９０５は、クエリウェブサービスコンポーネント９１７を介して機能リソース（クエリビルダ９０７以外）に接続される。

例示的実施形態の１つでは、クエリウェブサービスコンポーネント９１７が、クライアント９０５によって呼び出すことができるメソッドを有するインターフェースの組（アプリケーションプログラミングインターフェース−ＡＰＩなど）をエクスポーズするオブジェクトの組である。メソッドが呼び出される時（すなわち、クライアント９０５がＡＰＩに書き込む時）に、クライアント９０５は、それが接続されたシステムによって提供される機能を使用することができる。したがって、クエリウェブサービスコンポーネント９１７によって、システム２４８、５１０、９０１、９０７、９１１、および９１５の機能がラップされ、これらの機能がクライアント９０５に提供され、クライアント９０５が、クエリウェブサービスコンポーネント９１７のインターフェースを介してこれらの機能にアクセスできるようになる。

このシステムは、このシステムに関して下で説明するもの以外のさまざまな異なる機能または説明される機能に加えられる追加機能を実行することができる。

クエリビルダ９０７は、システム５１０など、データベースシステムに対するクエリを構築する任意のシステムとすることができる。したがって、ビルダ９０７の詳細な説明は、提供しない。クエリウェブサービスコンポーネント９１７が、複数の役に立つ機能を提供し、クライアント９０５からの入力に基づいてクエリを作成する際にビルダ９０７によってその機能を使用することができると言えば十分である。これらの機能について、以下に説明する。

エンティティフォルダシステム９１５は、クエリまたはクエリへの参照を階層ストレージシステム（フォルダシステムなど）に保管するシステムである。クエリフォルダシステム９１５の複数の態様を、以下に詳細に説明する。

クエリサービスコンポーネント９１１によって、クエリが定義される。クエリウェブサービスコンポーネント９１７は、コンポーネント９１１と対話して、クエリを定義し、クエリに対する作成、検索、更新、および削除（ＣＲＵＤ）動作を実行する。コンポーネント９１７は、コンポーネント９１１と対話して、クエリを実行する。クエリサービスコンポーネント９１１によって、定義されたクエリが、データアクセスおよびストレージシステム５１０（図１３に図示）に適切な形に変換され、システム５１０のとの必要な対話が実行されて、データベースに対してクエリが実行される。

メタデータサブシステム２４８には、システム内のオブジェクトに関するメタデータが保管される。メタデータによって、どのオブジェクトがクエリに使用可能であり、これらのオブジェクトのどのプロパティがクエリ可能であるかが示される。システム９１７およびシステム９１１の両方が、処理中にメタデータサブシステム２４８にアクセスする。

コンポーネント９１７によって、複数のメソッドを有するインターフェースがエクスポーズされる。一部のメソッドは、システムへのクエリウェブサービスコンポーネント９１７のインストールおよび除去のために設けられる。

追加のメソッドを呼び出して、フォルダシステム９１５からクエリをロードし、システム５１０内でクエリを実行し、処理要求（ハイパーメディア検索／トラバーサルシステム９０１でのハイパーメディアリンクのトラバースなど）を実行し、クエリフォルダシステム９１５に保管されたクエリを削除することができる。

一実施形態で、単一のメソッド（ＰｒｏｃｅｓｓＲｅｑｕｅｓｔメソッドなど）を使用して、すべてのクエリ関連動作（ロード、実行、作成、保存、削除、ハイパーリンクのトラバース、次への移動、前への移動など）を実行できることに留意されたい。さらなる他の機能が、クライアントがより簡単にこれらの動作を実行できるようにするヘルパ機能である。

さらに、メソッドを呼び出して、クエリフォルダシステム９１５内の操作を実行することができる。例えば、メソッドを呼び出して、フォルダをリストする、フォルダを作成する、フォルダシステムを介するパスを削除する、またはフォルダシステムを介してパスをコピーすることができる。

さらなるメソッドを呼び出して、メタデータサブシステム２４８からメタデータを検索して、クエリを作成する際にクライアント９０５を助けることができる。メタデータの諸部分を、クライアント９０５によって、クエリの定義に使用される新しいＸＭＬ要素に引き込むことができる（例えばＱｕｅｒｙＤｅｆｉｎｉｔｉｏｎ）。例えば、メソッドを使用して、システム内の基本的なビューを入手し、表示できるプロパティおよび関係を入手することができる。ビューを扱うメソッドを用いると、クライアントが、クエリの基礎として使用することができる使用可能なビューのリストを供給することによって、クエリを作成することができる。使用可能なプロパティのリストおよび関連するビューのリストなど、これらのビューに関するメタデータも、検索することができる。クライアントは、この情報を使用して、複数の結合されたビュー、システム変数およびユーザ供給のパラメータを有する複雑な制約、および複数のソートを有するクエリを作成することができる。したがって、メソッドを用いて、式の変数も検索することができる。

もう１つのメソッドを用いると、クライアント９０５が、出力が従い、入力が従わなければならないフォーマットを定義するのに使用されるスキーマの位置を得ることができる。クエリを定義し、クエリに対する作成、検索、更新、および削除（ＣＲＵＤ）動作を実行するのに使用されるクラスを定義するオブジェクトモデルの一実施形態によって、クライアントが有効なクエリを構築することだけを許容するメソッドが提供される。例えば、クライアントが、Ｃｕｓｔｏｍｅｒに対するクエリを構築している場合に、これらのメソッドを用いると、クライアントが、Ｃｕｓｔｏｍｅｒエンティティに対するプロパティを選択することだけができるようになる。

＜ユーザインターフェースサブシステム２３６＞
ユーザインターフェースサブシステム２３６によって、アプリケーションフレームワーク２２４のユーザインターフェースまたは「プレゼンテーション」部分が提供される。このサブシステムは、データを視覚化し、管理し、分析し、プロセスを開始する機能を提供することによって、ビジネスプロセスの自動化と、ビジネスデータの管理、視覚化、および分析というアプリケーションの目的をサポートする。

ビジネスアプリケーションの通常のデプロイメントに、数千個または数百万個のビジネスエンティティが含まれる場合がある。さらに、これらのビジネスエンティティは、相互関係の複雑な網を有する。所与のカスタマが、多数の注文を有する。所与の注文が、多数の勘定科目を有し、この勘定科目が、さらに、多数の在庫品目に関係する。在庫項目は、その項目を供給するベンダに関連する。

クエリサービスサブシステム２３２によって、ビジネスエンティティをフィルタリングし、その間でナビゲートすることによって、ビジネスエンティティを見つける能力が提供される。ユーザインターフェースサブシステム２３６によって、ビジネスデータに対する作成、読取、更新、および削除動作を実行することによって、ビジネスデータの管理が容易になる。サブシステム２３６によって管理されるビジネスエンティティの関連する組を、文書と呼ぶことができる。ビジネス文書の管理は、視覚化とは非常に異なる。というのは、視覚化が、読取のみのアクションであるが、管理が単一の文書内の修正アクションであるからである。

修正によって、ビジネスロジックが利用される。ビジネスロジックは、多数の形で、望ましいユーザ経験を提供するのに使用される。例えば、ユーザが、販売注文の作成のためにカスタマを指定し、ビジネスロジックによって、カスタマが存在することの検証が要求されると仮定する。この検証は、ユーザインターフェースサブシステム２３６によって提供され、その結果、ユーザは、参照保全性の欠如を識別することによってデータベースがこの問題にフラグを立てるまで、そのような問題について通知されるのを待つ必要がなくなる。

さらに、デフォルト設定によって、ビジネスアプリケーションユーザに、できる限り少ないキーストロークでユーザが文書を作成できるようにするインターフェースが与えられる。例えば、カスタマを注文に割り当てた後に、注文の通貨のデフォルトを、カスタマデフォルト通貨にすることができる。もちろん、多数の他のプロパティも、デフォルトを設定することができる。

さらに、文書相対計算が調整される。例えば、勘定科目が注文に追加される時に、注文の小計および総計を更新しなければならない。これは、単純であるように見えるが、すぐに複雑になる。というのは、勘定科目の追加が、税金の再計算を必要とし、これによって非常に複雑なビジネスロジックが用いられる可能性があるからである。

この例は、ユーザインターフェースサブシステム２３６でのビジネスロジックの使用の例示にすぎない。

ユーザインターフェースサブシステム２３６によって、ビジネス文書の処理も容易になる。上述したように、サブシステム２３２内のハイパーメディアサブシステムが、どのオペレーション（またはプロセス）をビジネス文書に対して実行できるかを記述した情報のリポジトリとして働くことができる。この使用可能なオペレーションのリストを、表示することができ、これは、ビジネス文書の視覚化または管理のいずれかの間にプロセスを開始できることを意味する。そのようなオペレーションの選択には、内部的に短時間動作または長時間動作とすることができるビジネスプロセスが含まれる。この区別は、ユーザインターフェースサブシステム２３６によって、ユーザから隠される。

本発明を、特定の実施形態に関して説明したが、当業者は、本発明の趣旨および範囲から逸脱せずに、形態および詳細において変更を行えることを認めるであろう。

本発明を使用することができる環境を示すブロック図である。 本発明を使用することができるソフトウェア環境を示すブロック図である。 本発明の一実施形態によるビジネスフレームワークを示すブロック図である。 ビジネスプロセスを示すブロック図である。 追加のビジネスプロセスを示すブロック図である。 追加のビジネスプロセスを示すブロック図である。 追加のビジネスプロセスを示すブロック図である。 ビジネスアクティビティをどのように実施できるかを示すより詳細なブロック図である。 エンティティのカスタマイゼーションの一実施形態を示す図である。 エンティティに追加される拡張プロパティを示す図である。 本発明の一実施形態によるメタデータサブシステムによってサポートされるメタデータ構造を示す図である。 論理ティアを示す図である。 データアクセスサブシステムを示すブロック図である。 エンティティの包含階層を示す図である。 エンティティの包含階層を示す図である。 エンティティの包含階層を示す図である。 エンティティの包含階層を示す図である。 キー構造を示す図である。 キー構造をさらに示す図である。 ビジネスインテリジェンスエンティティを作成するシステムを示すブロック図である。 複数のエンティティを示すＵＭＬクラス図である。 ビジネスインテリジェンスエンティティを作成するシステムを示す詳細なブロック図である。 ハイパーリンクを使用するナビゲーションを示す図である。 ハイパーリンクの操作を示すブロック図である。 クエリサービスサブシステムを示すブロック図である。

符号の説明

１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３１ 読取専用メモリ（ＲＯＭ）
１３２ ランダムアクセスメモリ（ＲＡＭ）
１３３ 基本入出力システム（ＢＩＯＳ）
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ インターフェース
１５１ 書き込む磁気ディスクドライブ
１５２ 取外し可能不揮発性磁気ディスク
１５５ 書き込む光学ディスクドライブ
１５６ 取外し可能不揮発性光ディスク
１６０ ユーザ入力インターフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロホン
１８０ リモートコンピュータ
１７０ ネットワークインターフェース
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域ネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
２０２ ツールおよびサーバプラットフォーム
２１０ フレームワーク
２１２ アプリケーションレイヤ
２１４ ビジネスコンポーネント
２１６ ビジネスコンポーネント
２１８ ビジネスコンポーネント
２２０ ビジネスクラスライブラリ
２２２ ツールサブシステム
２２４ ビジネスアプリケーションフレームワーク
２２６ 共通エンティティ
２２８ パターン
２３０ データ型
２３２ レポート作成およびクエリサブシステム
２３４ プロセス実行サブシステム
２３６ ユーザインターフェースサブシステム
２３８ コンポーネントプログラミングモデルサブシステム
２４０ ロールベースセキュリティサブシステム
２４２ カスタマイゼーションサブシステム
２４４ デプロイメントおよび管理サブシステム
２４６ データアクセスサブシステム
２４８ メタデータサブシステム
２５０ ビジネスメッセージングおよび統合サブシステム
２５２ ファウンデーションサービスサブシステム
５１０ データアクセスおよびストレージシステム
９０１ ハイパーメディア検索／トラバーサルシステム
９００ メタデータハイパーメディアプロバイダ
９０２ メタデータストア
９０３ クライアント
９０４ ＨＭＳ
９０５ クライアント
９０６ プロバイダレジスタ
９０７ クエリビルダ
９０８ ハイパーメディアプロバイダ
９１０ ハイパーメディアプロバイダ
９１２ ハイパーメディアプロバイダ
９１７ クエリウェブサービス
９１５ エンティティフォルダシステム
９１１ クエリサービス

Claims (29)

1. コンピュータを実行させるビジネスプロセス生成方法であって、
   複数のオペレーションを指定することであって、該オペレーションは、前記コンピュータによって実行される時に、作業の分離された粒状の部分を実行するように指定するステップと、
   複数のビジネスアクティビティを用いて前記複数のオペレーションのスコープを設定するステップであって、前記ビジネスアクティビティは、前記コンピュータによって実行される時に、関連する複数の前記オペレーションの実行を呼び出すようにスコープを設定するステップと、
   前記ビジネスプロセスを達成するために望まれる順序で前記複数のビジネスアクティビティを配置するステップと
   を有することを特徴とするビジネスプロセス生成方法。
2. 前記スコープを設定するステップは、
   前記ビジネスアクティビティに、該ビジネスアクティビティによって呼び出される複数のオペレーションを割り当てるステップであって、前記割り当てられるオペレーションのそれぞれは、作業の部分の期待されるタイムアウト期間内に実行可能であるように割り当てるステップを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
3. 前記オペレーションは、データの項目に対して実行され、実行される時に、他のオペレーションによるアクセスからデータの前記項目をロックし、前記スコープを設定するステップは、
   前記ビジネスアクティビティに、該ビジネスアクティビティによって呼び出される複数のオペレーションを割り当てるステップであって、前記作業の部分は、前記ビジネスアクティビティに割り当てられた各オペレーションがその間に実行される所望のロックアップ時間に基づいて前記オペレーションのそれぞれによって実行されるように割り当てるステップを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
4. 前記複数のビジネスアクティビティを配置するステップは、
   前記ビジネスプロセス内で少なくとも１つのビジネスサブプロセスを配置するステップを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
5. 前記少なくとも１つのビジネスサブプロセスを配置するステップは、
   前記ビジネスサブプロセスを開始するように前記複数のビジネスアクティビティの１つを構成するステップを有することを特徴とする請求項４に記載のビジネスプロセス生成方法。
6. 前記少なくとも１つのビジネスサブプロセスを配置するステップは、
   前記複数のビジネスアクティビティの第２の１つを開始するように前記ビジネスサブプロセスを構成するステップを有することを特徴とする請求項５に記載のビジネスプロセス生成方法。
7. 前記複数のビジネスアクティビティを配置するステップは、
   基本ビジネスアクティビティが、該基本ビジネスアクティビティを完了する前に実行すべき内部ビジネスアクティビティを開始するように構成されるように、ビジネスアクティビティをネスティングにするステップを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
8. 前記複数のビジネスアクティビティを配置するステップは、
   基本ビジネスサブプロセスが、該基本ビジネスサブプロセスを完了する前に実行すべき内部ビジネスアクティビティまたはビジネスサブプロセスの少なくとも１つを開始するように構成されるように、ビジネスサブプロセスをネスティングにするステップを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
9. 前記ビジネスプロセスの実行がその間に継続の前に外部入力を待って、前記ビジネスアクティビティに関する停止点を配置するステップを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
10. 前記複数のビジネスアクティビティは、
    該複数のビジネスアクティビティの選択された１つの中からイベントを伝搬させるステップと、前記イベントに基づいて追加のビジネスアクティビティを呼び出すステップと、前記追加のビジネスアクティビティの完了時に前記選択されたビジネスアクティビティにリターンするステップとを有することを特徴とする請求項１に記載のビジネスプロセス生成方法。
11. コンピュータを実行させるビジネスプロセス実行方法であって、
    非インペラティブプロセス記述言語で、オペレーションを含むビジネスアクティビティを記述するステップと、ビジネスサブプロセスおよび前記ビジネスプロセスを達成するために、前記ビジネスサブプロセスは実行されなければならない順序を記述することとによって前記ビジネスプロセスを記述するステップと、
    前記ビジネスプロセスをインスタンス化するために、前記記述されたビジネスアクティビティおよび前記記述された順序でのビジネスサブプロセスをインスタンス化するために前記プロセス記述言語を解釈するステップと、
    前記インスタンス化されたビジネスプロセスを開始するステップと
    を有することを特徴とするビジネスプロセス実行方法。
12. 前記インスタンス化されたビジネスプロセスを開始するステップは、
    プロセス開始入力を受け取るステップと、前記プロセス開始入力に基づいて前記インスタンス化されたビジネスプロセスを開始するステップとを有することを特徴とする請求項１１に記載のビジネスプロセス実行方法。
13. 前記プロセス開始入力を受け取るステップは、
    外部コンポーネントからの自動化された入力を受け取るステップを有することを特徴とする請求項１２に記載のビジネスプロセス実行方法。
14. 前記プロセス開始入力を受け取るステップは、
    ユーザ入力を受け取るステップを有することを特徴とする請求項１２に記載のビジネスプロセス実行方法。
15. 前記ビジネスプロセスを記述するステップは、
    メタデータストアに保管されるメタデータ構造内で前記ビジネスプロセスを記述するステップを有することを特徴とする請求項１１に記載のビジネスプロセス実行方法。
16. 前記ビジネスプロセスを記述するステップは、
    テキストファイル内で前記ビジネスプロセスを記述するステップを有することを特徴とする請求項１１に記載のビジネスプロセス実行方法。
17. 前記ビジネスプロセスを記述するステップは、
    複数のオペレーションを指定するステップであって、該オペレーションは、前記コンピュータによって実行される時に、作業の分離された粒状の部分を実行するように指定するステップを有することを特徴とする請求項１１に記載のビジネスプロセス実行方法。
18. 前記ビジネスプロセスを記述するステップは、
    複数のビジネスアクティビティを記述するステップであって、該ビジネスアクティビティは、前記コンピュータによって実行される時に、関連する複数の前記オペレーションの実行を呼び出すように記述するステップを有することを特徴とする請求項１７に記載のビジネスプロセス実行方法。
19. 前記ビジネスプロセスを記述するステップは、
    前記ビジネスプロセスを達成するために望まれる順序で前記複数のビジネスアクティビティの配置を記述するステップを有することを特徴とする請求項１７に記載のビジネスプロセス実行方法。
20. コンピュータ上におけるビジネスプロセスソフトウェアアプリケーションで使用されるビジネスプロセスモデルであって、
    複数のオペレーションであって、該オペレーションは、作業の分離された部分を実行するようなオペレーションと、
    複数のビジネスアクティビティであって、実行される時に、前記複数のオペレーションの関連する組の実行を呼び出すようなビジネスアクティビティと、
    非インペラティブ記述言語での、前記複数のビジネスアクティビティの記述機能であって、前記コンピュータによって解釈される時に、前記コンピュータに、前記記述されたビジネスアクティビティをインスタンス化させるような記述機能と
    を有することを特徴とするビジネスプロセスモデル。
21. コンピュータを実行させるビジネスプロセスを実施するために使用されるビジネスプロセスモデルであって、
    クライアントからプロセス要求を受け取るように構成されたメソッドを有するエージェントと、
    オペレーションを実行するためにサービスをインスタンス化し、呼び出すために前記エージェントによって呼び出されるように構成されたサービスファクトリと
    を有することを特徴とするビジネスプロセスモデル。
22. 前記エージェントは、前記プロセス要求に基づいて複数回前記サービスファクトリを呼び出すように構成されることを特徴とする請求項２１に記載のビジネスプロセスモデル。
23. 前記エージェントは、前記サービスファクトリが複数回呼び出される間に、前記サービスファクトリを介する前記サービスに関する状態を保持するように構成されることを特徴とする請求項２１に記載のビジネスプロセスモデル。
24. 前記サービスファクトリは、受け取ったサービス識別子に基づいて前記サービスをインスタンス化するように構成されることを特徴とする請求項２１に記載のビジネスプロセスモデル。
25. 前記エージェントは、前記クライアントから前記サービス識別子を受け取るように構成されたメソッドを有することを特徴とする請求項２４に記載のビジネスプロセスモデル。
26. 前記サービスファクトリは、前記エージェントから前記サービス識別子を受け取るように構成されることを特徴とする請求項２５に記載のビジネスプロセスモデル。
27. 前記サービスファクトリは、メタデータから前記サービス識別子を受け取るように構成されることを特徴とする請求項２４に記載のビジネスプロセスモデル。
28. 前記サービスファクトリは、前記エージェントによって呼び出されることに応答してイベントを伝搬させるように構成されることを特徴とする請求項２４に記載のビジネスプロセスモデル。
29. 前記サービスファクトリは、前記サービスファクトリによって伝搬される前記イベントに応答して呼び出されるイベントハンドラから前記サービス識別子を受け取るように構成されることを特徴とする請求項２８に記載のビジネスプロセスモデル。