JP2011501854A - モデル・ベースのコンポジット・アプリケーション・プラットフォーム - Google Patents

Abstract

諸実施形態では、コンポジット型の、自律的なアプリケーションおよびサービスを構築しデプロイできるようにするアーキテクチャを提供する。さらに、分散型のアプリケーションとサービスの間での通信を可能とするインフラが提供される。１つまたは複数の実施形態では、例示的なアーキテクチャが、接続性サービス、プロセス・サービス、アイデンティティ・サービス、ライフサイクル・サービス、およびツールを含む５つの論理モジュールを備えるかまたは利用する。

Description

データ駆動型のコンポジット・アプリケーション、すなわち、複数のモジュールを組み合わせることによって構築されるアプリケーションを開発しデプロイすることは、特に分散環境でのデプロイメントを考える場合は、困難な作業である可能性がある。

今日まで、具体的な低レベルのプログラミングを知る必要があることが、データ駆動のコンポジット・アプリケーションの開発とデプロイメントに対する厄介な障壁となってきた。

本要約は、抽出した概念を簡潔な形で導入するために提供する。その概念は、後ほど「発明を実施するための形態」でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定しようとするものではなく、クレーム主題の範囲を限定するために使用しようとするものでもない。

諸実施形態では、自律的なコンポジット・アプリケーションおよびサービスを構築およびデプロイできるようにするアーキテクチャが提供される。さらに、分散アプリケーションとサービスの間の通信を可能にするためのインフラが提供される。

１つまたは複数の実施形態では、例示的なアーキテクチャが、接続性サービス、プロセス・サービス、アイデンティティ・サービス、ライフサイクル・サービス、およびツールを含む５つの論理モジュールを備えるかまたは利用する。

図面全体に渡って同じ番号を使用して同様の機能を参照する。

１つまたは複数の実施形態に従うアーキテクチャまたはプラットフォームの高レベルなビューの例を示す図である。 １つまたは複数の実施形態に従うサービス・バスの例の態様を示す図である。 １つまたは複数の実施形態に従って連合名前空間コンポーネントが動作できる環境を示す図である。 １つまたは複数の実施形態に従うセキュリティ・アーキテクチャの例を示す図である。 １つまたは複数の実施形態に従うトランザクション・サービス環境の例を示す図である。 １つまたは複数の実施形態に従うメッセージング・サービス・ノードの例を示す図である。 １つまたは複数の実施形態に従うメッセージング・サービス相互接続の例を示す図である。 １つまたは複数の実施形態に従うプロセス・サービス・コンポーネントの例を示す図である。 １つまたは複数の実施形態に従うプロセス・サービス環境の例を示す図である。 １つまたは複数の実施形態に従うディレクトリ・サービス環境の例を示す図である。 １つまたは複数の実施形態に従うアクセス・サービス環境の例を示す図である。 １つまたは複数の実施形態に従う統合サービス環境の例を示す図である。 １つまたは複数の実施形態に従うアプリケーション・ライフサイクル・サービス環境の例を示す図である。 １つまたは複数の実施形態に従うリポジトリの例を示す図である。 １つまたは複数の実施形態に従う実行コンポーネントの例を示す図である。 １つまたは複数の実施形態に従う分析サービス環境の例を示す図である。 １つまたは複数の実施形態の実装に利用できるシステムの例を示す図である。

概要
上述のように、複数のモジュールを組み合わせることによって構築されたアプリケーションを「コンポジット・アプリケーション」と称する。コンポジット・アプリケーションの様々な部分（例えば、クライアント部、ビジネス処理部、データ記憶部、等）を全く異なる環境（例えば、ＡＳＰ．ＮＥＴ、ＢｉｚＴａｌｋ、ＳＱＬ Ｓｅｒｖｅｒ）で実行することができ、このことが、アプリケーションを全体的に扱うことを非常に難しくしている。さらに、コンポジット・アプリケーションのライフサイクルの様々な場面はしばしば、仮に自動化されていても、その自動化は貧弱である。今日まで、コンポジット・アプリケーションのインフラは現在その要望に追いついていない。例えば、リッチなコンポジット・アプリケーションの作成者が、インフラのコードを書くことに自身の９０パーセントを超えるリソースを費やしていると報告するのも、稀なことではない。分散処理および帯域幅がますますありふれたものになると、企業その他は、自身が心に描くことと、自身が構築し、デプロイし、管理する余裕があるものとの間の歯痒いギャップに直面する。

コンポジット・アプリケーションのモデルの開発により、非伝統的なプログラミングのコミュニティが重要なアプリケーションの構築に参加できるようになるはずである。これは、人々が必ずしもスクリプトまたはコードを書かずにアプリケーションに取り組むことができるようにすることで可能となる。ルールまたはワークフロー（後述）のような関数抽象は、コードやインストール・スクリプトよりも人々が実際にシステムについて考える方法の方に幾分近いものである。

以下の議論では、プラットフォームまたはアーキテクチャの概念を導入する。プラットフォームは、統一された対象を宣言型プログラミングのエクスペリエンスとドメイン固有言語に提供することができる。宣言型のエクスペリエンスをアプリケーションのライフサイクルに渡って提供することができるので、プログラミングを行うエンド・ユーザは、コードまたはスクリプトではなく宣言型の抽象概念の観点から自身の特定のシステムを扱える。後述するように、アプリケーション、ツール、サービスで共有される共通なリポジトリを利用し、アプリケーションのライフサイクルに関与する様々な記憶域の数を減らすことによって開発および管理を簡略化する。このリポジトリのさらなる価値は、このリポジトリがモデルの形でスキーマおよびコンテンツを含むことである。リポジトリを継続的に使用することで、アプリケーションの書き手にモデルの観点から考えることを教えることができる。アプリケーションの態様がますますリポジトリ内のコンテンツのように見えると、各部分間の新しい相乗効果が、以前は決して可能でなかった形で明らかとなり、利用可能となる。

今日では、コンポジット・アプリケーションの管理および分析には、アプリケーションの部分ごとに全く異なるエクスペリエンスが関与する。後述の実施形態によれば、コンポジット・アプリケーションを、別々の部分としてではなく、全体として管理および分析することができる。少なくとも幾つかの実施形態では、アプリケーションを単一のインタフェースを介してエンティティ全体としてデプロイし、管理し、分析することが可能である。さらに、これらのアプリケーションの個々の部分を、記述するアプリケーションを用いて漸進的にバージョン管理することができる。１つまたは複数の実施形態では、観測モデルをアプリケーション全体の視点から確立することができ、その結果、コンポジット・アプリケーションの実行を、アプリケーションの様々な部分を介して、分析者に適した、統一されたメタファの観点から理解することができる。

後述の実施形態では、１つのアーキテクチャを説明する。そのアーキテクチャにより、自律的なコンポジット・アプリケーションおよびサービスを構築し、デプロイし、管理することができる。このアーキテクチャにより、様々な種類のコンポジット・アプリケーションをモデルの観点から説明することができる。コンポジット・アプリケーションは、データ変更イベントによって駆動されるアプリケーションである。コンポジット・アプリケーションは、一般的に、どのような種類のデータ変更が興味深いか厳密に規定するルールと、データが変化したときに引き起こされる動作との観点から規定される。例えば、メッセージ駆動型のコンポジット・アプリケーションは、メッセージの交換によって駆動されるアプリケーションである。このグループは、ｎ層式の（要求応答型の）コンポジット・アプリケーション、待ち行列型のコンポジット・アプリケーション、パブサブ（ｐｕｂ−Ｓｕｂ）型またはイベント駆動型のコンポジット・アプリケーションに分解される。スケジュール型のコンポジット・アプリケーションは、スケジューラによって駆動されるアプリケーションである。スケジューラは、モジュールを介した制御フローを記述するモデルによってプログラムされる。ワークフロー・アプリケーションは、この種のアプリケーションの良い例である。これらの種類のアプリケーションごとに、対応する通信インフラ、より厳密には、対応する通信インフラの利用パターンがある。

さらに、分散アプリケーションとサービスの間の通信を可能とするためのインフラが提供される。このアーキテクチャは、「プラットフォーム」とも称するが、開発者がリッチで自律的なコンポジット・アプリケーションとサービスを構築できるようにする機構を提供する。コンポジット・アプリケーションはデータによりモデルの形で記述され、そのモデルは、アプリケーションのコンポーネントを分散的に構築およびデプロイするために使用される。説明したプラットフォームまたはアーキテクチャを使用して、１組のマシンもしくはコンピューティング装置、およびそれらの上で動作する１組のアプリケーションを管理することができる。

１つまたは複数の実施形態では、例示的なアーキテクチャが、接続性サービス、プロセス・サービス、アイデンティティ・サービス、ライフサイクル・サービス、およびツールを含む５つの論理モジュールを備えるかまたは利用するが、これらのモジュールによって具現化される機能を必ずしもこの特定のアーキテクチャによって表す必要はない。むしろ、クレーム主題の趣旨および範囲を逸脱しない他のアーキテクチャを利用することができる。

以下の議論では、「コンポジット・アプリケーション」というタイトルのセクションを提供し、コンポジット・アプリケーションの概念と、「コンポジット・アプリケーション」が意味するところとを論ずる。これに続いて、「例示的なアーキテクチャまたはプラットフォーム」というタイトルのセクションを提供し、１つまたは複数の実施形態に従って、コンポジット・アプリケーションの開発およびデプロイメントを可能とするために利用できるアーキテクチャまたはプラットフォームの１例を説明する。このセクションでは、アーキテクチャの様々な態様を説明するために幾つかのサブセクションを提供する。最後に、「システムの例」というタイトルのセクションを提供し、説明した実施形態の１つまたは複数の態様の実装に利用できるコンピューティング装置の例を説明する。

コンポジット・アプリケーション
上述のように、コンポジット・アプリケーションは、モデルによって記述されるアプリケーションである。次に、モデルを使用してアプリケーションの構成部分を選択し、対応するアプリケーションのインスタンスを構築し、アプリケーションのインスタンスを適切な環境にデプロイすることができる。したがって、プラットフォームの１つの目標は、コンポジット・アプリケーションをモデルで記述し、これらのアプリケーションをプラットフォーム上で設計、開発、デプロイ、および管理できるようにすることである。

具体的には、少なくとも幾つかの実施形態では、接続されたアプリケーションの全体構造が分散モデルの観点から説明される。このモデルでは、限定ではなく例として、メッセージ駆動型モデル、データ駆動型モデル、スケジュール型（またはワークフロー）モデル、等のような数種のモデルのうち１つまたは複数のモデルを想定することができる。或る粒度レベルにあるアプリケーションの各コンポーネントは、次の粒度レベルでは、接続されたアプリケーション全体であることができる。より詳細に見ようとすると、アプリケーションの部分を記述するためのモデルの種類が非常に劇的に変化することがある。従って、例えば、或るレベルには、ウェブ・ページ、何らかのビジネス・ロジック、およびデータベースからなるメッセージ駆動型または呼出し駆動型のアプリケーションがあるかもしれない。このアプリケーションは、或る種のモデルによって記述されるはずである。アプリケーションのビジネス・ロジックの態様を詳細に見ると、この態様が、ルールと宣言型ワークフローから構成される第２の種類のモデルによって記述されることに気付くかもしれない。少なくとも幾つかの実施形態においては、アプリケーションをルールおよび宣言型ワークフローの観点から表現することによって、より高いレベルの抽象概念が開発者に提供され、その結果、開発者は低レベルのプログラミングの細部を必ずしも理解しなくてもよい。従って、低レベルのプログラミング言語の知識を必ずしももたない者にも開発プロセスを開放することによって、柔軟性が高まる。

幾つかの実施形態では、アプリケーション・シェル（または、後述するツールのような他の何らかのツール）がユーザ・インタフェースの形で提供され、これにより、開発者はアプリケーションを開発することができる。アプリケーション・シェルを介して、開発者は自身のアプリケーションを宣言的に記述したものを提供することができ、コマンド、文書、視覚化、ジョブまたはタスク、通信規約、アイデンティティ、等のようなものを定義することができる。従って、シェルは、開発者がそれによって自身のアプリケーションを開発しプラグインできる機構を提供することができる。そうすると、アプリケーション・シェルは実行時に低レベルのアーキテクチャを使用するための機構を有することになる。これらの低レベルの機構は開発者に対して透過的であることができる。

コンポジット・アプリケーションの一般的な概念を論じたので、次に、係るアプリケーションを開発しデプロイできるアーキテクチャまたはプラットフォームの例を論ずる。

アーキテクチャまたはプラットフォームの例
以下の議論では、アーキテクチャまたはプラットフォームの例を説明する。説明したアーキテクチャまたはプラットフォームは本明細書で説明する機能を説明する１つの方法を構成するにすぎないことは理解されよう。従って、クレーム主題の趣旨と範囲を逸脱しない他のアーキテクチャまたはプラットフォームを利用することができる。

図１は、１つまたは複数の実施形態に従うアーキテクチャまたはプラットフォームの高レベルなビューの例を一般的に１００で示す。本例では、アーキテクチャ１００は５つの論理コンポーネント、すなわち、接続性サービス・コンポーネント１０２、プロセス・サービス・コンポーネント１０４、アイデンティティ・サービス・コンポーネント１０６、ライフサイクル・サービス・コンポーネント１０８、およびツール・コンポーネント１１０を備える。これらの各アーキテクチャ・コンポーネントは独自のサブコンポーネントを有し、その各々を、後述の対応するサブセクションで説明する。

簡潔に述べると、本例では、接続性サービス・コンポーネント１０２は、サービス・バス・コンポーネント１１２、トランザクション・サービス・コンポーネント１１４、およびメッセージング・サービス・コンポーネント１１６を備える。プロセス・サービス・コンポーネント１０４は、ワークフロー／ルール・コンポーネント１１８を備える。アイデンティティ・サービス・コンポーネント１０６は、ディレクトリ・サービス・コンポーネント１２０とアクセス・サービス・コンポーネント１２２を備える。ライフサイクル・サービス・コンポーネント１０８は、リポジトリ・コンポーネント１２４、統合コンポーネント１２６、実行コンポーネント１２８、および分析コンポーネント１３０を備える。ツール・コンポーネント１１０は、（Ｖｉｓｕａｌ Ｓｔｕｄｉｏのような）コード・ベース・コンポーネント１３２、（Ｑｕａｄｒａｎｔのような）モデル・ベース・コンポーネント１３４、および（システム・センタ・コンポーネントのような）エンタープライズ管理ツール１３６を備える。

以下で明らかになるように、アーキテクチャ１００とその構成部分により集合的に、コンポジット・アプリケーションを開発しデプロイすることができる。

接続性サービス・コンポーネント
１つまたは複数の実施形態において、本例では、接続性サービス・コンポーネント１０２は、サービス・バス・コンポーネント１１２、トランザクション・サービス・コンポーネント１１４、およびメッセージング・サービス・コンポーネント１１６を備える。

サービス・バス・コンポーネント
１つまたは複数の実施形態では、サービス・バス・コンポーネント１１２（またはより単純に、「サービス・バス」）は、アプリケーションとサービスが互いと通信できるようにするインフラを提供する。この点で、サービス・バスをサービスとアプリケーションの間の接続回路とみなすことができる。

機能的な観点からは、サービス・バスは、多様な「エンドポイント」間の転送、発見、同期を仮想化するために利用される。少なくとも幾つかの実施形態では、サービス・バスはまた、変換、フィルタリング、アセンブリおよびディスアセンブリ、ならびにプロトコル／トランスポート・ブリッジングをエンドポイント側で提供することに特に留意されたい。

エンドポイントは、その例を後で提供するが、説明したアーキテクチャ上で構築されるかまたは説明したアーキテクチャを利用するアプリケーションを備えることができる。サービス・バスは階層型のデータ・モデル上で構築され、名前ベースの探索および発見機能および予測ベースの探索および発見機能、ならびに後述する所謂クレーム・ベースのセキュリティを提供する。本例では、エンドポイントの特徴（すなわち、監視作業を行う場所の特徴）を、階層型の拡張可能なメタデータ・スタックを介してモデル化する。サービス・バスは、その作業を達成するために、様々なプラグ可能なエンティティを利用するか、またはそのエンティティを提供することができる。例えば、プラグ可能トランスポート（ｐｌｕｇｇａｂｌｅ ｔｒａｎｓｐｏｒｔ）を利用して、エンドポイントの動作には依存しないでメッセージ転送を仮想化することができる。プラグ可能エンコーダを利用して、ローカルのデータ・モデルには依存しないでメッセージ表現を仮想化することができる。さらに、プラグ可能アダプタを使用してメタデータとメッセージを１組のエンドポイントからバスへブリッジすることができる。

実際には、アプリケーションはサービス・バスを利用してサービスまたは他のアプリケーションと通信する。サービスとアプリケーションに関して、以下の類似性を考察する。サービスは、オブジェクトがローカル・アプリケーションのコンポーネントであるのと同様に、コンポジット・アプリケーションのコンポーネントである。オブジェクト指向アプリケーションを書いている場合、アプリケーション全体はオブジェクトであり、そうするとそのオブジェクトは他のオブジェクトの観点から書かれる。全く同様に、サービス指向アプリケーションを書いている場合、アプリケーションがサービスであることがあり、そうするとこのサービスは他のサービスの観点から書かれるはずである。最終的に、サービスはローカルの実装を有し、サービスはオブジェクトを用いて書かれる。別のアプリケーションまたはサービスと通信する前に、アプリケーションは、幾つかの実施形態では、通信が望まれる特定のエンティティを探して見つける。この目的で、サービス・バスは、アプリケーションが通信したいアプリケーションまたはサービスを（例えば、ネットワーク・アドレスを介して）発見することを可能とする、検索および発見コンポーネントを提供する。代替または追加として、通信パターンをモデル化することができ、通信したいエンティティを特定のモデルにおいて発見することができる。さらに、サービス・バスは、サービス・バスを介して通信するエンティティ間のデータが同期されることを保証するように機能する同期機能を備える。すなわち、サービス・バスは、幾つかの実施形態において、メッセージ・ベースの通信パターンとデータ・ベースの通信パターンの両方を提供することができる。メッセージ・ベースの通信パターンでは、例えば、ＡがメッセージをＢに送信すること、またはＡがメッセージをＢ１、Ｂ２、Ｂ３、Ｂ４、等にマルチキャストすることを規定できるかもしれない。他方、データ・ベースの通信パターンでは、Ａがデータを変更した場合、そのデータに対する変更に関心がある全ての関係者がトリガされる。その後、関心がある任意の関係者はデータを任意の時点で読むかまたは修正することができる。この情報またはデータを通信するために使用されるプロトコルは構成可能かつ拡張可能である。

１つまたは複数の実施形態では、サービス・バスはさらに、アプリケーション、リソース、等が一貫して名付けられることを保証する連合ネーミング・コンポーネントを備えることができる。メッセージング・アダプタおよびメッセージング・フレームワークが、異なるソースから来るデータが情報の同じ論理的な部分であるかもしれないという概念を扱う。しかし、サービス・バスにいる者が認識できるように、データを変換する必要があるかもしれない。従って、メッセージング・アダプタおよびメッセージング・フレームワークは、クロス・プラットフォームでのデータの一貫性と互換性を保証するためのデータ変換を扱う。例えば、少なくとも幾つかの実施形態では、アプリケーションは、そのアプリケーションによって使用される１組の名前を生成することができる。次いで、名前はメタデータに関連付けられ、アプリケーションはそのメタデータに関して問い合わせることによって名前を検索することができる。アプリケーションはメッセージを名前に直接送信することができ、名前空間をクレーム・ベースの機構によって保護することができる。サービス・バスは送信者と受信者の概念を抽象化する。従って、受信者はデータがどこから生ずるかを気にすることなくデータに基づいて行動することができる。マルチキャスト版のサービス・バスでは、送信者は名前に送信し、受信者が名前で監視することができる。従って、少なくとも幾つかの実施形態では、送信者は「０人」または「Ｎ人」が監視していたかどうかが分からず、受信者は誰が特定のメッセージを送信したかが分からない。

さらに、少なくとも幾つかの実施形態では、サービス・バスのエンドポイントは、メッセージを送信者の形式からそのエンドポイントでアプリケーションが期待する形式に変換するために利用される、様々な機能をサポートすることができる。これらの機能は、限定ではなく例として、生の変換、フィルタリング、集約および分解（しばしば「バッチング」とも呼ばれる。例えば、単一のメッセージから多くのメッセージを引き出すこと、または多数のメッセージを単一のメッセージへと構築すること）、そして（エンドポイントに到着したメッセージをサービス・バスの異なるインスタンスに再送信する）プロトコル・ブリッジングを含むことができる。

サービス・バスはまた、サービス・バスを利用する様々なエンティティ間の通信を保護することに関するメッセージング機能およびチャネル・セキュリティ機能を備える。例えば、メッセージ交換とサービス・バスのリソース（例えば、構成、名前空間）へのアクセスとの両方を保護することができる。機能に対するセキュリティは、限定ではなく例として、認証（すなわち、その人は、その人が言っている本人であるか？）および認可（すなわち、その人は、その人が要求していることをできるよう許可されているか？）を含むことができる。さらに、セキュリティ機能はまた、個々のメッセージおよび／またはメッセージ部分に対する暗号化および他のＤＲＭ（ｄｉｇｉｔａｌ ｒｉｇｈｔｓ ｍａｎａｇｅｍｅｎｔ）を提供することができる。

１つまたは複数の実施形態に従うサービス・バスの１例にすぎないが、図２を考察する。図２では、サービス・バス・コンポーネントの例が一般的に２００で示されている。本例では、サービス・バス・コンポーネント２００は、エンコーダ層２０２、チャネル層２０４、ならびに上述および後述の機能を提供する他の様々な高レベルのコンポーネントを備える。具体的には、本例では、サービス・バス・コンポーネント２００は、発見コンポーネント２０６、連合名前空間コンポーネント２０８、連合アイデンティティ・コンポーネント２１０、および中継コンポーネント２１２を備える。中継コンポーネントをサービス・バスに統合する場合は、ファイアウォールで分離されているかまたは相互にアドレス不可能であるエンドポイント間でサービス・バスの参加者が通信することが可能である。当業者に明らかなように、この目的を達成するために、中継機能を高度なネットワーキング機能と両方のエンドポイントに可視である中間装置との組合せを用いて実装することができる。

本例では、エンコーダ層２０２とチャネル層２０４は、ポイント・ツー・ポイント通信を可能とする機能を提供する。この点で、エンコーダ層２０２は幾つかの異なるエンコーディング標準、例えば、ＳＯＡＰ、ＸＢＩＮ、ＰＯＸ／ＲＳＳ、等ならびに文字セットをサポートする。チャネル層２０４は、ポイント・ツー・ポイント通信を促進する様々なコンポーネントを備える。限定ではなく例として、これらのコンポーネントには、リスナ・コンポーネント、トランスポート・コンポーネント、アダプタ・コンポーネント、および機能コンポーネントが含まれる。

１つまたは複数の実施形態では、リスナ・コンポーネントは、通信システムを監視し、メッセージがシステム上で利用可能になったときにイベントを発行する責任を負う。リスナ・コンポーネントは、ホスト・システムにおける起動のような事柄をトリガするために使用される。

トランスポート・コンポーネントは、或るエンドポイントと別のエンドポイントの間でメッセージを移動させる役割を果たす。定義によれば、トランスポート・コンポーネントは、ＴＣＰまたはＨＴＴＰのような生のトランスポート・システムを使用する。トランスポート・コンポーネントを、対応するリスナ・コンポーネントと直接に接続することができる。例えば、リスナ・コンポーネントは「接続利用可能」イベントを発行することができ、そうするとアプリケーションはそのイベントに対するトランスポート・チャネルを作成することができる。次いで、アプリケーションは、リスナ・コンポーネントによってその存在が伝えられた新しいメッセージをその接続上で読むことができる。

アダプタ・コンポーネントは、そのユーザにはトランスポート・コンポーネントのように見えることができる。アダプタ・コンポーネントはメッセージのソースまたはシンクをラップし、それらをトランスポート・コンポーネントのように見えるようにする。少なくとも幾つかの実施形態では、様々な種類のアダプタ・コンポーネントが存在しうる。例えば、ＬＯＢ（ｌｉｎｅ ｏｆ ｂｕｓｉｎｅｓｓ）アダプタ・コンポーネントはＳＡＰまたはＰｅｏｐｌｅｓｏｆｔのような業務システムのシリーズをラップする。メッセージング・アダプタ・コンポーネントは、ＤＣＯＭ、ＭＳＭＱ、ＭＱ、またはＴｉｂＣｏのようなメッセージング・インフラまたは中間装置をラップする。

機能コンポーネントは、エンコーダでもトランスポートでもない、エンドポイントにある機能を実装するコンポーネントである。機能コンポーネントは、ＷＳ−ＳｅｃｕｒｉｔｙまたはＷＳ−ＲＭのようなプロトコル・コンポーネント、ＢｉｚＴａｌｋパイプラインにあるような変換コンポーネントおよびフィルタリング・コンポーネント、ならびにプロトコル・ブリッジング・コンポーネントを含む。

当業者に理解されるように、１つまたは複数の実施形態では、メッセージを受け取るかまたは取得する同じソフトウェア・アーキテクチャを使用してアプリケーションを他のアプリケーション、メッセージング・インフラ、等に接続できるように、各アダプタをトランスポート・チャネルとして書くことができる。

エンコーダ層２０２とチャネル層２０４は、集合的に、データをプラットフォームによって送信されるかまたはプラットフォームに受信されるメッセージの形で送信し、受信し、処理するメッセージ・バスと考えることができる。メッセージ・バスは、メッセージを処理し、様々な形のメッセージ、例えばインフォセット表現もしくはバイナリ表現のメッセージの変換を実施し、かつ／またはメッセージ内容をプラットフォームの他のコンポーネントに利用可能とすることができる。

メッセージ処理に加えて、および低レベルのポイント・ツー・ポイント転送サービスとしての役割に加えて、サービス・バス・コンポーネント２００はまた、図示した発見コンポーネント２０６、連合名前空間コンポーネント２０８、連合アイデンティティ・コンポーネント２１０、および中継コンポーネント２１２のような、高レベルのコンポーネントを備える。

図示および説明した実施形態において、発見コンポーネント２０６は、サービス・バスへの独立した問合せを可能とし、それらの問合せにマッチする結果を返す機能を備える。例えば、アプリケーションはプリンタを見つけるための問合せ、購入注文を扱うサービスを見つけるための問合せ、等を発行することができる。発見コンポーネントにより、係る問合せと関連する結果とを、問い合わせた関係者に返すことができる。従って、発見コンポーネント２０６は、接続されたアプリケーション内のモジュール間のインダイレクションをサポートする。例えば、前の議論では、名前付けの概念を論じた。少なくとも幾つかの実施形態では、ここで２種類の名前を考えることが適当である。第１に、エンドポイントは名前を有することができる。従って、サービス・バスに、通信したい名前を提供することができる。他のエンティティと通信したいエンティティは、具体的なアドレスではなく関連する名前を使用する。第２に、サービス・バスのインフラはそれ自体の内部に名前、例えば、どの特定のエンドポイントよりも寿命の長いリソースの名前を有する。これらの名前は、限定ではなく例として、（単一の読み手と単一の書き手を伴う名前である）問合せの名前であることができ、かつ／または（複数の読み手および／または複数の書き手を伴う名前である）トピックの名前であることができる。これらの名前に「メタデータ」を関連付けることができる。「メタデータ」は、名付けられたものを記述する構造化されたデータを意味する。発見は、発見コンポーネントによって実装され、サービス・バス内の名前を、（既知であれば）名前によって直接的に、または（例えば、「購入注文を処理する」人が必要であることが分かっていれば）メタデータを問い合わせることにより間接的に見つける業務に関する。

発見を、独自の修飾された名前をもつインフラをラップするアダプタを扱う場合には、メッセージング・インフラによって実装することができる。軽量トランスポート（ＨＴＴＰ）を用いるサービスが名前をサービス・バスに登録したい場合には、発見を発見サーバによって実装することもできる。図３は、１つまたは複数の実施形態に従って連合名前空間コンポーネントが動作できる環境を一般的に３００で示す。ここで、連合名前空間コンポーネントは２つの層、すなわち、合流層３０２（ｒｅｎｄｅｚｅｖｏｕｓ ｌａｙｅｒ）と名前空間層３０４を備える。これらの層は、（図２のメッセージ・バスのチャネル層２０４に対応し、ポイント・ツー・ポイント通信に使用される）チャネル層３０６と名前空間層３０４の上に構築できる幾つかの機能との間に論理的に挟まれるとして示されている。これらの追加の機能は３０８で論理的に表され、限定ではなく例として、発見サービス、通知サービス、ディレクトリ・サービスおよびメッセージ・サーバ・サービスを含む。これらのサービスの全ては名前空間層３０４を利用して、本質的に、プラットフォームに「プラグインする」ことができ、名前空間の機能を使用してリッチな機能群を提供することができる。図示し説明した実施形態では、合流層３０２は広域近接性認識型のルーティング（ｗｉｄｅ−ａｒｅａ ｐｒｏｘｉｍｉｔｙ−ａｗａｒｅ ｒｏｕｔｉｎｇ）を実装する。図示し説明した実施形態では、合流層３０２は連合アドレス空間を提供する。マシンまたは装置は特定のアドレス空間に、そのマシンまたは装置が実際にそのアドレス空間において他のマシンまたは装置に「見える」かどうかに関わらず、参加することができる。例えば、マシンまたは装置はファイアウォールによって分離され、外部からアドレス可能でない企業のサブネットに配置されることがある、等である。マシンまたは装置は、連合アドレス空間上の特定のマシンまたは装置にアドレスで送信することができ、そのアドレス空間内の全てのマシンまたは装置にマルチキャストすることができる。従って、幾つかの事例では、ＴＣＰサブネットの機能が提供される。但し、それらの機能は動的に構築および破棄されることがあり、それらの機能を同じ場所に配置する必要はない。

名前空間層３０４は合流層３０２の上に論理的に配置され、連合アドレス空間における特定のアドレスまたはアドレス群に関する名前をサポートする。複数のサービスが同じ名前を監視することができ、名前にメタデータを関連付けることができる。名前を、そのメタデータに基づいて検索することができる。連合アドレス空間を使用する場合に、名前により或るレベルのインダイレクション（関節性）がユーザに与えられる。名前を動的かつアプリケーションごとに作成および破棄することができる。

３０８で一般的に示す追加の機能は、このインフラまたはその上に構築されたサービスの何れかの使用に相当する。例えば、「発見」はしばしば、或る種のメタデータに関連付けられた名前を見つけるためにアドレス空間の上にある名前を調べる能力を指す。「発見」はまた、メタデータまたはアドレスの関連を追跡し続け、その情報をＵＤＤＩ、ＷＳ−Ｄｉｓｃｏｖｅｒｙ、等のような標準発見プロトコルを介して提供する、このインフラの頂上にあるサービスを指すことができる。「通知」は、通知の宛先である名前のところにサービスを登録するための能力を指す。「ディレクトリ」は、１組のリポジトリの管理サービス（例えば、アクセス制御、複製制御、等）を提供するアプリケーションを指す。「メッセージ・サーバ」はコンポーネント内またはそのコンポーネント上に存在するサービスを指し、そのサービスは、信頼性および／または耐久性をそのコンポーネントのユーザに提供する。

１つまたは複数の実施形態では、連合アイデンティティ・コンポーネント２１０（図２）はセキュリティのアーキテクチャとパラダイムをプラットフォームに提供する。セキュリティ・アーキテクチャの１例として図４を考察する。図４では、セキュリティ・アーキテクチャまたはセキュリティ・システムの例が一般的に４００で示されている。ここで、システム４００は、トークンを管理する１つまたは複数のサーバ技術サービス・コンポーネント４０２、ポリシ・マネージャ４０４、カード・スペース・システム４０６、カード・スペース・エージェント４０８、セキュリティ・トークン・マネージャ４１０、４１８、クライアント４１２、サービス４１４、およびサービス認証マネージャ４１６を備える。

動作に際して、１つまたは複数の実施形態によれば、セキュリティ・アーキテクチャ４００は以下のように動作する。メッセージング・スタックにおいて、クライアント４１２がサービス４１４を使用したい場合、クライアント４１２はクレーム、例えば鍵、を利用することによってそれを行う。クレームは、基本的なレベルにおいて、何らかの事実の主張を構成するデータとみなすことができる。クレームの整合性と秘匿性は、セキュリティ技法によって保護される。従って、本例では、クライアント４１２はセキュリティ・トークン・マネージャ４１０と通信して、サービス４１４を利用するためにクライアント４１２が使用できるサービス４１４に関連付けられたクレームまたは鍵が存在するかどうかを確かめる。サービス４１４に関連付けられたポリシにより、サービス４１４にアクセスするのに必要なクレームが特定され、または、セキュリティ・プロトコルを使用して、どのようなクレームが必要とされているかをサービス４１４に問い合わせることができる。クライアント４１２は、自身がもつクレームと、自身が必要とするそのクレームに関する情報とをクライアント４１２のセキュリティ・トークン・マネージャ４１０に渡す。セキュリティ・トークン・マネージャは、通信において使用するためにどのようなクレームをクライアント４１２に提供できるかを確かめるために、（カード・スペース・システム４０６および／またはポリシ・マネージャ４０４のような）様々なクレーム・ポリシ記憶域を参照する。この時点で、クライアント４１２は、クライアント４１２によって提供されたクレームをとるサービス４１４と通信する。サービス４１４は、同様なクレーム解決プロセスを、サービス認証マネージャ４１６を用いて行う。再度、クライアント４１２によって提供された１組のクレームを、サーバのポリシ記憶域内のクライアントのクレームに関連付けられたクレームにより、サーバ側で補うことができる。やがてこのプロセスは完了し、最終的なクライアントのクレーム・セットが計算される。クレーム・セットが、サービス４１４と通信するために必要なクレームを含む場合、アクセスが許可される。

少なくとも幾つかの実施形態では、サービス４１４は別のレベルの再帰を行うことができ、その再帰の中で、クライアントは、クレームを取得するために使用できる中間クレーム・サーバを指すことができる。中間クレーム・サーバは、さらに別のクレーム・サーバ等にリダイレクトすることができる。最終的に、再帰は、実施すべきステップがもうないときまたは要求されたクレームが取得されたときに停止する。

従って、或る意味では、サービス側の機構はクライアント側の機構と同じである。すなわち、サービス４１４はクレームで開始し、そのクレームをポリシ記憶域（例えば、ポリシ・マネージャ４０４）に提供し、クレームを補う。ポリシ記憶域は別のポリシ記憶域にリダイレクトすることができる、等である。

トランザクション・サービス・コンポーネント
トランザクション・サービス・コンポーネント１１４（図１）は、分散アプリケーション内のモジュールの、そのモジュールのうち１つまたは複数において期待される状態と期待されない状態との両方に対する応答を調整する。遭遇しうる１つの基本パターンは以下の通りである。１組のリソース・マネージャが、トランザクションを介して調整することを決定する。これらのリソース・マネージャは自身の状態を、その状態をトランザクション結果に集約するトランザクション・マネージャに送信し、その結果がリソース・マネージャに送信し戻される。より実行時間が長いステートフルなビジネス・プロセスまたはサービス指向アプリケーションの文脈では、このパターンを以下のように一般化することができる。分散アプリケーション・モデルからの情報を使用して、トランザクションに関与する１組のリソース・マネージャを特定することができる。ステートフルなアプリケーション・モジュールは、論理的なリソース・マネージャとして振る舞う必要がある。リソース・マネージャとトランザクションの間のプロトコルはリッチでアプリケーション固有である必要があり、ローカル状態をトランザクション状態に集約することは一般的でポリシ駆動型である必要がある。

トランザクション・サービス・プロセスの１例にすぎないが、図５に関連して以下を考察する。図５では、トランザクション・サービス環境を一般的に５００で示す。本例では、環境５００はプログラミング・モデル５０２、トランザクション・スタック５０４およびリソース５０６を備える。これらの各々は、個々の構成部分またはプロセスを有する。

具体的には、プログラミング・モデルはマネージ・コード５０８とネイティブ・コード５１０の両方を含むことができる。トランザクション・スタック５０４は、システム・トランザクションＡＰＩ５１２、分散トランザクション・コーディネータ（ＤＴＣ）５１４、および図示するようにカーネル・モードＫＴＭコンポーネント５１８と通信するＫＴＭＲＭコンポーネント５１６を備える。リソース５０６は、データベース・リソース５２０、ＭＤＡＣリソース５２２、ローカルおよびリモートの分散トランザクション・コーディネータ５２４、ＨＩＳリソース５２６、ＴＭ／ＲＭとの相互運用機能５２８、リモートＴＭ５３０、ＴｘＦ５３２、およびＴｘＲ５３４のような、幾つかの異なる種類のリソースを含むことができる。

動作に際して、プログラミング・モデル５０２が他のソフトウェアと協調したい場合、プログラミング・モデル５０２はシステム・トランザクションＡＰＩ５１２を利用する。システム・トランザクションＡＰＩ５１２は、システムと対話するために使用できるローカルなＡＰＩまたはフレームワークである。このケースでは、ＡＰＩ５１２は分散トランザクション・コーディネータ５１４に対するフロント・エンドの役割を果たす。従って、例えば、プログラミング・モデル５０２はこのＡＰＩを使用してエラーを調整するためのドメインを確立する。ＡＰＩ５１２は、調整ドメインの名前を返す。次いで、調整ドメインはプログラミング・モデル５０２が通信する他のエンティティに回される。次いで、これらの他のエンティティは図示したように分散トランザクション・コーディネータ５１４と通信し、この特定のドメイン内で動作していることを示す。次いで、分散トランザクション・コーディネータ５１４は、データベース・リソース５２０等のような他のリソースと通信してエラーを調整することができる。

図示および説明した実施形態では、ＤＴＣ５１４は、例えば、トランザクションを生成し、トランザクションの一部である全てのリソースを追跡し続け、トランザクション上の投票を処理し、リソースに投票の結果を通知することによってトランザクションを調整する。トランザクションは、ＤＴＣ５１４によって作成された「トランザクションＩＤ」を有する。トランザクションＩＤは、個々のトランザクションと、それを作成したトランザクション・コーディネータの両方を一意に特定する。

図示した実施形態では、様々なトランザクション・マネージャまたはトランザクション・コーディネータとの５つの異なる対話パターンの例が示されている。本例では、ＫＴＭ５１８は、カーネル・コードに対するトランザクション・マネージャであり、主にファイルおよびレジストリと関連して使用される。ＫＴＭ５１８はＤＴＣ５１８と連携することができ、ＤＴＣ５１４を介して他のリモート・トランザクション・マネージャ（すなわち、ローカルおよびリモートのＤＴＣ５２４、ＨＩＳ５２６、ＴＭ／ＲＭとの相互運用機能５２８、リモートＴＭ５３０）と連携することができる。ＫＴＭ５１８はファイルおよびレジストリ設定に対する変更を可能とすることができる。図示した例では、他のトランザクション・コーディネータ（例えば、Ｏｌｅ ＴＸ、ＬＵ６．２、等）と通信するために使用される機構と通信が行われるトランザクション・コーディネータの種類の両方が示されている。トランザクション・コーディネータは或る種のマスタ・スレーブ戦略を使用し、作成者がマスタであって他のコーディネータがスレーブである。

データベース５２０とＭＤＡＣ５２２は、状態の変化がＤＴＣ５１４によって調整されるリソースの例である。他のリモート・トランザクション・コーディネータは他のリソース・マネージャを扱う。リソース・マネージャにトランザクション「の中の」状態を変更するように問い合わせると、リソース・マネージャは必ず、同じトランザクションをもたらす全ての者にその変更が行われたかのように、その状態のビューを提示しなければならない。さらに、トランザクション・マネージャは他の任意のエンティティに対してその状態へのアクセスをロックする。これを行い、次いでその状態への変更に従うことで、良好な状態の条件が保たれる。

トランザクションの寿命の例として、以下を考察する。最初に、トランザクションが作成され、その作成者がトランザクションを関与する全てのリソース・マネージャに回す。各リソース・マネージャは、トランザクションの約束事項を履行するか、または不良な状態に入る。最後に、トランザクションを作成したコードは、トランザクションが完了したことを通知する。次いで、各リソース・マネージャは自身の変更を一度に行うことができる。何らかの理由で、リソース・マネージャが自身の状態を変更することを選択しなかった場合は、障害が存在し、変更は行われない。

プログラミング・モデル５０２は、このプロセスをプログラマから抽象する。プログラミング・モデルは、トランザクションの存続期間（作成と完了）におけるトランザクション・マネージャとの交渉を扱い、リソース・マネージャがトランザクションを利用できるようにする。プログラミング・モデルはまた、いつトランザクションが終わるかを知っている。ローカルにエラーが発生しなかった場合は、プログラミング・モデルは適切な投票をトランザクション・マネージャに送信し戻す。

メッセージング・サービス・コンポーネント
１つまたは複数の実施形態では、メッセージング・サービス・コンポーネント１１６（図１）は、耐久性およびスタンディング・クエリ（ｓｔａｎｄｉｎｇ ｑｕｅｒｙ）のような高レベルのメッセージ仲介サービスを提供する。メッセージング・サービス・コンポーネントを、スタンドアロン・モードで、幾つかのサービスが直接通信する「クラスタ」モードで、またはサービスをクライアント上、エンタープライズ・サーバ上、および／もしくはインターネットのようなネットワークによってホストされたサーバ上で実行できる「分散」モードで動作できる、ホストされたサービスとして実装することができる。１つまたは複数の実施形態では、メッセージング・サービス・コンポーネントは、待ち行列およびパブリケーション／サブスクリプション（「パブサブ」とも呼ばれる）のような共通のメッセージング・パターン、ならびにコンテンツ・ベースのルーティングおよびイベント相関分析のようなよりリッチな機能を実装する。図示し説明した実施形態では、メッセージング・サービスに（上述の）メッセージ・バスのチャネルの抽象化を介してアクセスする。この抽象化では、プロトコルおよび統合に関する限り、標準ＡＰＩと柔軟性の両方が提供される。以下の議論では、メッセージ・ノードの例が図６に関連して最初に説明されている。これに従うと、説明したアーキテクチャが提供する柔軟性と堅牢な相互接続性を示すために、どのようにメッセージ・ノードを接続できるかの例が提供されている。

すぐ上で説明した機能を実装するために利用できるアーキテクチャの１例にすぎないが、図６を考える。図６では、システム６００は所謂個々のメッセージ・ノード６０２を備える。本例では、メッセージ・ノード６０２は、幾つかのコンポーネントまたはコンポーネント部分を備える。具体的には、ノードの第１層はサブスクリプション管理コンポーネント６０４、キャプチャ・コンポーネント６０６、および配送コンポーネント６０８を備え、それらの各々はその機能を実装するための１組の柔軟なＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）を公開する。この層は、主に、ノードに入りノードから出て行くメッセージの処理を扱う。

具体的には、本例では、サブスクリプション管理コンポーネント６０４は、サブスクリプション・エンドポイントを表し、メッセージおよび他のイベントの登録を管理する責任を負う。例えば、メッセージ・ノードは、図示したようにメッセージまたはイベントを１つまたは複数の異なるアプリケーションから登録することができる。キャプチャ・コンポーネント６０６は、ノードに与えられたメッセージを受け取る責任を負うキャプチャ・エンドポイントを表す。配送コンポーネント６０８は、メッセージをメッセージ・ノードから送信または配送する責任を負う配送エンドポイントを表す。

ノードの第２層は、メッセージおよびイベントを待ち行列に入れ、メッセージおよびイベントを正しいエンティティに送る責任を負う、待ち行列およびルーティング層６１０を備える。パブサブをこの層で行うこともできる。さらに、少なくとも幾つかの実施形態では、フィルタリングおよび変換のような機能をこの層で実装することもできる。フィルタリングは、メッセージをスタンディング・クエリと比較し、メッセージがそのクエリを満たす場合にのみ送達コンポーネントを介してメッセージを渡すものである。変換は、入ってくるメッセージを、送達モジュールを介して送信する前に変換するマップを登録するものである。変換は、単一のメッセージに作用する（すなわち、全ての文字列を特定の形式に変換する）か、メッセージのグループに作用する（例えば、誰かが、無数のメッセージ・グループに対してメッセージに含まれる整数の平均を問い合わせることができる）ことがある。

さらに、１つまたは複数の実施形態では、個々の待ち行列とパブサブのトピックにチャネルのアドレスの観点から名前を付けることができる。チャネル・スタック内のフィルタ・チャネルおよび変換チャネルはフィルタおよび変換をローカル・スタック内のメッセージ・プロパティに取り付けることができる。次いで、このメッセージ・プロパティをメッセージ・サービスのトランスポート・チャネルによってメッセージ・サービスのノードに送信することができる。メッセージが配送された場合、トランスポートは、チャネル・スタックのフィルタおよび／または変換が適用された場合は、メッセージ内のフラグに印を付ける。フィルタおよび／または変換チャネルは、トランスポートが出力メッセージに作用しなかった場合は、その出力メッセージに作用するだけでよい。

ノード６０２の第３または最下層の層は、他のノードと接続するために使用できる様々なコンポーネントを備える。例えば、転送コンポーネント６１２を使用して、他のノードとポイント・ツー・ポイント式に接続することができる。追加または代替として、転送コンポーネント６１２を使用して、サービス・バスに対して実行される合流ネットワーク（ｒｅｎｄｅｚｖｏｕｓ ｎｅｔｗｏｒｋ）に接続することができる。さらに、転送コンポーネント６１２は、それを様々な他の方式で接続するために使用できる点で拡張可能である。

１つまたは複数の実施形態では、第３層が、コンテンツ・ベースのルーティングを実装できるコンテンツ・ベースのルーティング・モジュール６１４を備える。当業者に理解されるように、コンテンツ・ベースのルーティングは、特定のコンテンツに基づいてコンテンツを他のノードに送信する概念に関する。これにより、ノードにおいて、大規模な分散待ち行列システムに対する処理を簡素化することができる。例えば、メッセージがパブサブ・システムに送信されそのメッセージがニューヨーク州の天気に関する場合、カリフォルニア州にいる人がそのメッセージを気にする可能性は低い。従って、コンテンツ・ベースのルーティングは次いでそのメッセージをニューヨーク州のみにあるコンピューティング装置に送信することができる。

１つまたは複数の実施形態では、第３層はイベント相関分析サービス・コンポーネント６１６を備える。コンポーネント６１６は、長期にわたってメッセージを保持し、メッセージに対して動作を行い、特定のイベントに応答してメッセージを送出するといった、１組のリッチなサービスを可能とすることができる。例えば、１つまたは複数の実施形態では、各メッセージ・サービス・ノードは、メッセージ・ストリームが流れている間にそのメッセージ・ストリームに或る特定の方法で作用するようにプログラムできる、イベント相関分析サービス・コンポーネントを有する。「ストリーム」部分に関して、以下を考える。１つまたは複数の実施形態では、イベント相関分析サービス・コンポーネントはシステム内の待ち行列と対話し、従って、個々のメッセージだけでなく過去の一連のメッセージに作用することができる。イベント相関分析サービス・コンポーネントがメッセージまたはメッセージ・ストリームに適用できる機能には、あまり具体的でないケースで上述した変換およびフィルタリングが含まれる。

さらに、１つまたは複数の実施形態では、イベント相関分析サービス・コンポーネントは比較的分かりやすい抽象的な要求（例えば、「メッセージ呼出しに対する平均応答時間を測定せよ」）をとって、その要求を１組の分散されたイベント相関分析サービス・モジュール上で実行される動作に変換することができる。これは、或る意味では、計算を「上流へ」もっていくものである。例えば、呼出しが大量のマシン上で行われている場合は、各マシン上のイベント相関分析サービス・ノードは、自身のマシン上の平均呼出し回数を計算し、そのノードでの平均呼出し数と呼出し回数を含む定期的なメッセージを下流へ送信することができる。これにより、下流のコール・バックごとにメッセージを「内外に」送出するものである、あまり分散化されていない代替手段と比較した場合に、ネットワーク負荷を劇的に削減することができる。

メッセージ・ノードの概念を説明したので、次に、図７に関連してメッセージ・ノードを接続できる様々な方法を考える。図７では、接続性環境７００が一般的に７００で示されている。環境７００は、１つまたは複数の実施形態に従う幾つかの異なる接続性パラダイムを含む。ここで、幾つかのホスト、すなわち、ホスト１〜８があり、その各々がメッセージ・サービス・ノード６０２（図６）を実行している。

本例では、図の右上方から開始すると、ホスト３がメッセージ・ノードを実行しており、このノードに関連付けられたインタフェースが分散インタフェースであるのでホスト４は、単純にメッセージをホスト３上のノードに直接送ることによって、メッセージ・ノード・システムを使用することができる。

ホスト２および３は、転送コンポーネント６１２（図６）を用いて２つのノードを直接に接続できることを示す。従って、ホスト２で捕捉されるかもしれないメッセージをシステムに挿入することができる。メッセージがホスト３上のサブスクリプションを満たす場合、メッセージを単純にホスト３に送信することができる。

多数の異なる人が協調できるＳＯＡＰシナリオのような、広範囲の協調シナリオを、ホスト１、２、５、８の間に示すもののような接続によってサポートすることができる。この接続は、合流環（ｒｅｎｄｅｚｖｏｕｓ ｃｉｒｃｌｅ）を構成し、メッセージ・ノードがサービス・バスにプラグインされサービス・バスの上に構築される例である。いったんプラグインされると、ノードの１つがメッセージを捕捉した場合に、そのノードはそのメッセージを、その環に参加している他のノードの全てにマルチキャストすることができる。従って、多数の異なるサービスを接続することができ、それらのサービスがブロードキャスト・メッセージを受け取ることができる。この特定の配置構成では、メッセージを環のメンバに非常に迅速に送ることができ、この場合、メンバ・ノードは、効率的かつ簡潔な方法で、メッセージを受け取り、処理し、必要ならば他のメンバに送ることができる。

従って、上の例では、ホスト３と２の間の関係により、どのように小規模に直接接続を利用できるかを示す。他方、環は、どのようにメッセージ・サービス・ノードをより広いシナリオで利用できるかを示す。

ホスト５、７、８は他のシナリオを示す。例えば、ホスト５は、他のパブサブ・システム、ここではＢｉｚＴａｌｋ Ｓｅｒｖｅｒと通信するためにどのように専用プロトコルを利用できるかを示す。ホスト７は、メッセージ・サービス・ノードと、やはりたまたま相互運用可能プロトコルを理解する他の何らかの異なる待ち行列サービスとの間で通信するために、ＷＳ−＊相互運用プロトコルのような他の相互運用プロトコルをどのように使用できるかを示す。上記の他の何らかの異なる待ち行列サービスは、次いで、メッセージを任意の形で自身のアプリケーションに配送することができる。

ホスト８は、たとえメッセージ・サービス・ノードが独自のキャプチャおよびサブスクライブのプロセスを有していても、ＲＳＳフィードまたはＲＥＳＴ接続を介してのような一般に標準的な方法で通信するためにどう接続できるかを示す。

接続性サービス・コンポーネント１０２（図１）を論じたので、次に、プロセス・サービス・コンポーネント１０４（図１）を考える。

プロセス・サービス・コンポーネント
１つまたは複数の実施形態では、プロセス・サービス・コンポーネント１０４は、ワークフローまたはルール・セットのような、寿命が長いステートフルな動作を実行するために使用する機能を含んだホストとしての役割を果たす。プロセス・サービス・コンポーネントは、ワークフローまたはルール・セットを実行できるワークフロー／ルール・ランタイム１１８を備える。従って、プロセス・サービス・コンポーネントは、プログラムが実行されるランタイム環境を提供する、統合されたフレームワークおよびサービスの集合を提供する。ランタイム環境は、限定ではなく例として、起動、スケジューリング、エラー処理、状態管理、環境とのインタフェース、等を含む。１つまたは複数の実施形態では、この定義によれば、全てのプログラムがランタイム環境において実行される。例えばＷｉｎ３２アプリケーションを実行できる非マネージ型のランタイム環境が存在する。さらに、ＣＬＲ（ｃｏｍｍｏｎ ｌａｎｇｕａｇｅ ｒｕｎｔｉｍｅ）アプリケーションを実行できるマネージ型のランタイム環境が存在する。本例では、ランタイム環境はコード・サービスを実行できるが、モデル（例えば、ワークフロー、ルール・セット、等）を実行するようにカスタマイズされている。

プロセス・サービス・コンポーネントの例として図８を考える。図８は、１つまたは複数の実施形態に従う、プロセス・サービス・コンポーネントが動作できる実行環境を一般的に８００で示す。本例では、環境８００はプロセス・サーバ・コンポーネント８０２、（上述の）サービス・バス８０４、（後述の）リポジトリ８０６、およびインスタンス・データ記憶域８０８を備える。

本例では、プロセス・サーバ・コンポーネント８０２は、アプリケーション、ネイティブ・コード、またはルールもしくはワークフローを実行するように使用される。すなわち、１つまたは複数の実施形態では、プロセス・サーバ・コンポーネントは宣言型のコード（例えば、グラフィカルなワークフロー、等）および命令型のコード（例えば、Ｃ＃）を実行することができる。プロセス・サーバ・コンポーネントは、寿命が１回の起動と等価な「ステートレスな」プロセスを実行することができ、寿命の長いプロセス、すなわち、渚在的に間隔が長い多数の起動に渡って生存するプロセスを実行することができる。

プロセス・サーバ・コンポーネントの構成部分には、限定ではなく例として、起動サービス８１０、インスタンス／セッション相関分析コンポーネント８１２、共通言語ランタイム・コンポーネント８１４を備えるランタイム環境、（状態の変化を条件としてアクティビティを実行する）ルール・エンジン８１６、（ルール・エンジンによって実行される、単一のアクティビティまたはアクティビティのグループの何れかの規定を可能とする）ワークフロー・エンジン８１８、および（予め定義されたまたは予め構成されたアクティビティを構成する）アクティビティ・ライブラリ８２０が含まれる。プロセス・サーバはまた、ドメイン固有言語プログラム８２２を含む。

動作に際して、本例では、プロセス・サーバ・コンポーネントでの作業を引き起こすために到着するメッセージの全ては、メッセージまたはサービス・バス８０４から到着する。インスタンス／セッション相関分析コンポーネント８１２は、受信メッセージを調べ、そのメッセージをランタイムの既存のインスタンスとユーザ・アプリケーション・モジュールとに送ることができるかどうかを判定する。これらのインスタンスはメモリ内にあるかもしれず、またはディスク上にあるかもしれない。起動サービス８１０はまた、入ってくるメッセージ・ストリームの要求に応じて、ランタイムの新しいインスタンスとユーザ・プログラムを作成する（すなわち、既存のインスタンスがまだ適切でない場合に、新しいインスタンスが作成される）。プロセス・サーバは、宣言型プログラム（ワークフロー、ルール）、マネージ型の命令型プログラム（Ｃ＃、ＶＢ．ＮＥＴ）、および非マネージ型の命令型プログラム（Ｃ＋＋、Ｃ）に適したランタイムを有する。さらに、プロセス・サーバは実際のプログラム（ＤＳＬであることもあればＤＳＬでないこともある）を有する。

メッセージがサービス・バスから到着すると、インスタンス／セッション相関分析コンポーネント８１２は、実行しているランタイムインスタンスを受け入れることができるかどうか、または新しいランタイムインスタンスが適当かどうかを判定する。起動サービスの責任は、メッセージの送信対象であるプロセスを実行するために使用できる新しい環境を必要に応じて提供することである。起動サービスはリポジトリ８０６と通信可能にリンクされ、リポジトリ８０６には、アプリケーション、モデル、ルール、ワークフローの全てが存在する。メッセージが到着し、自身が新しいアプリケーションを起動する必要があることを起動サービスが分かっている場合は、アプリケーションをリポジトリ８０６から取り出す。

１つまたは複数の実施形態では、プロセスが非常に長い時間実行されている可能性があり、このため、メッセージが到着すると、インスタンス／セッション相関分析コンポーネント８１２は入ってくるメッセージを処理し、実行されているかもしれないプロセスにそのメッセージを関連付けることを試みる。インスタンス／セッション相関分析コンポーネント８１２が適切なプロセスを発見すると、コンポーネント８１２はそのプロセスの最新の状態をインスタンス・データ記憶域８０８から取り出し、そのプロセスをロードし、ワークフローの次の部分を実行する。

リッチなリソース集合を用いてプロセスを構築することができる。具体的には、プロセスを、ＣＬＲ（ｃｏｍｍｏｎ ｌａｎｇｕａｇｅ ｒｕｎｔｉｍｅ）コンポーネント８１４を用いて構築することができる。ルール・エンジン８１６はワークフロー基盤を提供し、ルール・エンジン８１６をルールのみを用いてプロセスを実行するように拡張することができる。従って、ルールのみを用いてプログラムを構築することができる。ワークフロー・エンジン８１８をルールの上に構築することができ、ワークフロー・エンジン８１８の上に、開発者がコードを書かずにプログラムを書けるようにするのに十分なアクティビティ・ライブラリを構築することができ、これにより、少なくとも幾つかの事例において、パッケージ化されたコンポーネントとモデルを備えるプログラムが提供される。このプログラムは実行可能なモデルである。このモデルを、グラフィカルに、テキスト言語として、またはリポジトリ内で、表すことができる。図示および説明した実施形態では、ＣＬＲは、．ＮＥＴのコアを構築する共通言語ランタイムである。ＣＬＲは、Ｃ＃およびＶＢ．ＮＥＴのコードをコンパイルした論理的な命令コードを一体となって実行できる、仮想マシンおよびランタイムである。ルールは、条件とアクティビティの対である。条件はデータに結び付けられ、このデータは固定データである場合もあればルールに提供されるデータである場合もある。アクティビティは、ルールがそのデータとマッチするときに起動する。

ＣＬＲとこの特定のシステムの間の関連は、アクティビティを構成するものを考えると最も良く理解される。具体的には、アクティビティは、良く知られたインスタンスに対して実装されるコード（すなわち、ルールが満たされた場合に起動されるコード）の一部か、またはあたかもコードの集合であるかのように動作するルール／アクティビティのグラフである。アクティビティ・ライブラリ８２０は、．ＮＥＴに同梱される基本クラス・ライブラリまたは他の任意のソフトウェア環境に同梱されるライブラリ、すなわち、別個に作成する必要のない共通ライブラリと、或る意味で等価である。

ＤＳＬ（ｄｏｍａｉｎ ｓｐｅｃｉｆｉｃ ｌａｎｇｕａｇｅ）プログラムは、タスクの特定のサブセットに対して定義および利用される言語に関する。従って、或る種のプロセスの構築を便利にするルールまたはアクティビティのサブセットを構築するＤＳＬプログラムを作成することができる。原則として、ＤＳＬは、特定の種類のアプリケーションの構築を容易にするより一般的なシステムの限定またはサブセットである、特定のプリパッケージ型のアクティビティおよびルールである。

プロセス・サーバ・コンポーネントの一般的な概念を論じたので、次に、プロセス・サーバ・コンポーネントを図９と関連してどのように使用できるかを考える。図９は、図８のシステムを複数の異なるマシンにどのように拡張できるかを示す。図９のシステムによって解決される問題の１つは、マシン障害のためインスタンスがリサイクルされたかまたは紛失した可能性があるシステムのコンテクストにおいて、現在たまたまインスタンスを管理している場所にメッセージを届ける方法に関する。

図９では、環境の例が一般的に９００で示されている。動作に際して、メッセージは、ルータ９０４に関連付けられた所謂ポート９０２を介してサービス・バスから到着する。従って、メッセージはポートからルータに流れる。ポートは、サービス・バスに関連付けられたエンドポイントであり、図２で説明したチャネル・スタックに対応する。ルータは、本実施形態では、図８のインスタンス・マネージャと非常に類似した、分散された世界における機能を有する。ルータは、インスタンスが既にプロセス・サーバの１つに存在するかどうか、またはインスタンスが新しいインスタンスかどうかを解明する。メッセージが既存のインスタンスに関するものである場合は、ルータはメッセージを、そのインスタンスを保持しているプロセス・サーバに送信する。メッセージが新しいインスタンスに関するもの（または、特定のプロセス・サーバに現在固定されていないインスタンスに関するもの）である場合は、ルータはプロセス・サーバを選択し、そのメッセージを転送する。プロセス・サーバのインスタンス部はルータにマップされる。

少なくとも幾つかの実施形態では、長く実行されているプロセスのインスタンスにメッセージを関連付けるためのプロトコルを使用することができる。図示および説明した実施形態では、このプロトコルが動作できる幾つかの方法がある。例えば、メッセージは、特定のインスタンス化プロトコルに関するヘッダを含むことがある。これにより、インスタンスと場所に関するロジックを扱うことが容易になる。他方、メッセージがインスタンス化プロトコルのヘッダを含まない場合、マッピング機能が、インスタンスを一意に特定するメッセージ内の情報（例えば、購入注文）に基づいて、プロトコル内にあるはずである情報を作成する。マッピング機能は、これを、識別プロパティ９０６のデータベースを利用することによって行うことができる。このプロパティは、ポート内での変換を介してメッセージがどのようにインスタンスにマップされるかを定義することができる。続いて、メッセージがポートに入り、ルータ９０４に送信される。ルータは、どのプロセス・サーバが実行しているかを、プロセス・サーバ・データベース９０８を介して確かめる。本例では、これは、実行中のプロセス・サーバを追跡するテーブルを用いて行われる。インスタンス・マッピング・データベースまたはインスタンス・マッピング記憶域９１０は、プロセス・サーバの１つに関連付けられたインスタンスを追跡し続ける。ルータは、どのプロセス・サーバにメッセージが送られるかを確かめる。これは、プロセス・インスタンスのプロセス・サーバへのマッピングを維持するインスタンス・マッピング記憶域９１０を介して行われる。次いで、ルータはメッセージを正しいプロセス・サーバに送ることができる。次いで、そのプロセス・サーバはメッセージを正しいインスタンスに送ることができる。既存のインスタンスに対して、ルータ９０４は、ルータ９０４がメッセージを正しいプロセス・サーバ９１２、９１４、９１６に送信できるように、インスタンスがどこで実行されているかを確かめる。インスタンスが新しいかインスタンスが現在プロセス・サーバにマップされていない場合は、ルータ９０４は実行中のプロセス・サーバからプロセス・サーバを選択する。追加または代替として、メッセージが特定のインスタンスに到着してから長時間（例えば、３週間）経過している場合があるかもしれない。このケースでは、特定のインスタンスはインスタンス状態記憶域９１８に戻されているかもしれない。その場合は、その時点の状態を取り出し、適切なプロセス・サーバのメモリに入れる。

識別プロパティ記憶域９０６とインスタンス状態記憶域９１８の間のリンクを維持して、識別プロパティ記憶域が、実行中の個々のインスタンスのマッピングを有することができるようにする。

アイデンティティ・サービス・コンポーネント
１つまたは複数の実施形態では、アイデンティティ・サービス・コンポーネント１０６（図１）は、本例では、ディレクトリ・サービス・コンポーネント１２０とアクセス・サービス・コンポーネント１２２を備える。アイデンティティ・サービス・コンポーネントは、比較的複雑なアイデンティティの操作を実施するために使用できるサービスを提供する。

ディレクトリ・サービス・コンポーネントの１例にすぎないが、システムの例を一般的に１００で示す図１０を考える。本例では、ディレクトリ・サービス・コンポーネントは、アクセス層１００２およびディレクトリ・スタック１００４とみなすことができるものを備える。アクセス層１００２は１つまたは複数のコンポーネントを備え、それらのコンポーネントを介してディレクトリ・スタックを公開することができる。図示および説明した実施形態では、これらのコンポーネントにはＡＰＩコンポーネント１００６、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ ＡＰＩ）コンポーネント１００８、ＫＤＣコンポーネント１０１０および／またはサービス・バス・コンポーネント１０１２が含まれる。

ＡＰＩコンポーネント１００６を、場合によってはディレクトリ・スタックにアクセスするために使用できるレガシーＡＰＩまたは標準ＡＰＩとみなすことができる。ここで、ＡＰＩコンポーネントのＡＰＩは、より具体的には、ディレクトリ・スタック内で利用可能なデータにリンクされている。

ＭＡＰＩコンポーネント１００８は、ＭＡＰＩサブシステムによって、クライアント・アプリケーションの作成者によって、およびサービス・プロバイダの作成者によって使用されるプログラミング・インタフェースを指す。主要なプログラミング・インタフェースは、ＭＡＰＩプログラミング・インタフェースとして知られるオブジェクト・ベースのインタフェースである。当業者に理解されるように、ＯＬＥコンポーネント・オブジェクト・モデルに基づいて、ＭＡＰＩプログラミング・インタフェースは、ＭＡＰＩサブシステムによって、ＣまたはＣ＋＋で書かれたメッセージング・ベースのクライアント・アプリケーションによって、使用される。

ＫＤＣコンポーネント１０１０は、ディレクトリ内のアイデンティティと特定の個人に対して発行できるセキュリティ鍵との間でマップするポリシを含む鍵配信局である。個人がディレクトリにアプローチするときは、一般にその個人は鍵を求める。ポリシは個人に対して実行され、そのポリシに応じて鍵を返しても返さなくてもよい。

サービス・バス・コンポーネント１０１２を利用してディレクトリ・スタック１００４にアクセスすることができる。ここで、サービス・バス・コンポーネントは、多種多様なエンティティと通信できるようにする１組のより汎用化されたＡＰＩを備える。汎用化されたＡＰＩは、ディレクトリ・スタック内のデータまたはディレクトリ・スタックを介してアクセス可能なデータを作成し、読取り、更新し、削除する機能を提供する。

図示および説明した実施形態では、ディレクトリ・スタック１００４は種々のコンポーネントを備え、そのコンポーネントには、複製コンポーネント１０１６を含むディレクトリ・サービス・エージェント１０１４、データ・アクセス・コンポーネント１０１８、およびコア・セキュリティ・モジュール１０２０が含まれる。さらに、ディレクトリ・スタックはまた、リポジトリ１０２２および記憶域１０２４を備える。本例では、リポジトリは、本明細書で説明したプラットフォームによって利用できる形でデータを記憶するエンティティである。従って、リポジトリを、データを「新しい形式」で記憶するための記憶域としての役割を果たすとみなすことができる。同様に、記憶域１０２４は、レガシー・データまたはレガシー形式で存在するデータと見なすことができるものに対する記憶域の役割を果たす。この特定の例では、コア・セキュリティ・モジュール１０２０は、それがデータ・アクセス・コンポーネント１０１８に正しく提供できるように、セキュリティ層を記憶域１０２４に提供する。

ディレクトリ・サービス・エージェント１０１４を、様々なアクセスＡＰＩの全てがデータベース・システムとインタフェースするために使用する一般的な層とみなすことができる。このソフトウェア層は、システム内の他のデータ記憶域の位置を理解する。従って、このソフトウェア層は、（例えば、ＡＰＩが、ローカルな記憶域では利用できない何らかの情報を得ようとしている場合は）データ・アクセス用にこの知識を使用し、また、複製（例えば、データを、それが必要とされる場所から効率的にアクセスできるように、ネットワーク周りの戦略的な位置に置くこと）用にこの情報を使用する。この分散アクセスの動作は、様々なディレクトリ・サービス・エージェント（例えば、図中の「他のＤＳＡ」）の間で行われる。この情報がたまたまこの層で利用可能であるので、マシン名、ＩＰアドレス、サブネット、等を追跡し続けるためにドメイン情報もディレクトリ・サービス・エージェントからＤＮＳシステムへ提供される。

本例では、データ・アクセス・コンポーネント１０１８を利用して、当初はアクセスするように設計されていなかったデータにＡＰＩコンポーネント１００６（すなわち、レガシーＡＰＩ）がアクセスできるようにするだけでなく、サービス・バス・コンポーネント１０１２がレガシー・データにアクセスできるようにもする。

アクセス・サービスは、アクセス・サービス・コンポーネント１２２（図１）を介して、分散アプリケーション内のアイデンティティの管理と使用に対するリッチなサポートを提供する。図示および説明した実施形態では、このアプローチは、クレーム、すなわち、エンティティに関するクレーム、リソースに関するクレーム、リソース上のエンティティが行うアクションに関するクレーム、およびこれらのアクションがその中で行われうる環境に関するクレームを対象とする。ルールまたはポリシをこれらのクレーム上で表現することができる。次いで、これらのルールを様々なコンテクストで、すなわち、リソースに対する権限チェック（そのエンティティは所与の環境内のリソースを見ることができるか？）を行う方法として、またはより一般的には、ビジネス・ルール（エンティティの管理者が所与の量の購入注文を許可したか？）として、評価することができる。これらのルールをローカルに完全に処理することができるか、またはこれらのルールが、将来の分析用に何らかの連合処理機関に渡される部分的な結果をもたらすかもしれない。

１つまたは複数の実施形態では、アクセス・サービス・コンポーネントは、上述および後述の目的のためにプロセス・サーバの能力を使用する、図４のシステムを拡張したものを構成する。この点で、以下の議論では図４の一般的なアーキテクチャの具体的な応用例を説明する。

アクセス・サービス・アーキテクチャの例として、システムを一般的に１１００で示す図１１を考える。ここで、システム１１００はリポジトリ１１０２、サービス・バス１１０４、およびリポジトリとサービス・バスの間に論理的に挟みこんだサーバ技術サービス１１０６を備える。ここで、サービス１１０６はアクセス・ポリシ・コンポーネント１１０８とプロセス・サーバ１１１０を備える。プロセス・サーバ１１００はワークフロー・コンポーネント１１１２とルール・コンポーネント１１１４を備える。ここで、アクセス・ポリシ・コンポーネント１１０８は、リソースにアクセスするための関連するポリシを含む。ワークフロー・コンポーネント１１１２とルール・コンポーネント１１１４はアクセス関係を定義するかまたは記述する。これらのコンポーネントは、リソースへのアクセスを提供するサーバ技術サービスを実装するためにサーバ内で実行される。具体的には、１つまたは複数の実施形態では、アクセス・サービスは、アクセス・サービス・アーキテクチャによって実装され、図４のアーキテクチャにプラグインするための適切なインタフェースを伴う特定のプログラムを実行するプロセス・サーバを備える。

ライフサイクル・サービス・コンポーネント
１つまたは複数の実施形態では、ライフサイクル・サービス・コンポーネント１０８（図１）は、リポジトリ・コンポーネント１２４、統合コンポーネント１２６、実行コンポーネント１２８、分析コンポーネント１３０を備える。図示および説明した実施形態では、これらのコンポーネントは協調的に動作して、分散型の不均一なアプリケーションを実行できる環境を提供する。

先ず、統合コンポーネントを図１２に関連して考える。図１２では、システム１２００が統合コンポーネントを、リポジトリ１２０４、メタバース・コンポーネント１２０６、複数のデータ・ソース１２０８の間に論理的に挟みこんだ統合サーバ１２０２の形で備える。統合コンポーネントの試みの１つは、企業内の様々な記憶域に存在しうるデータの調整を可能とすることである。これを行うために、後述するように、統合コンポーネントを、企業にわたって使用されうる様々なデータ記憶域の全てに「引っ掛ける」ことができる。さらに、統合コンポーネント内で実行されている特定の種類の宣言的プログラムの目的は、潜在的な衝突を扱うための、企業が使用するポリシを実装することである。さらに、統合コンポーネントの別の試みは、アプリケーションに対する統一されたまたは単一のビューを、様々なデータベース、様々なＬＯＢアプリケーション、等のような様々な場所に存在するデータの上に構築することである。従って、この試みにおいては、アプリケーションはデータの動作ビューを定義および確立し、アプリケーションのビューと基礎となるデータ記憶域との間のマッピングを特定し、次いでデータ記憶域内の変更をアプリケーションのビュー内の変更と調整するためのポリシを確立する。これらのポリシは一般にアプリケーション・ロジック内に存在する。

この点で、説明しようとしている統合サーバは、少なくとも幾つかの実施形態において、図８に示すプロセス・サーバの修正形を構成する。

本例では、統合サーバ１２０２は同期ポリシ・コンポーネント１２１０、ならびにワークフロー・コンポーネント１２１４およびルール・コンポーネント１２１６を備えるプロセス・サーバ１２１２を備える。

動作に際して、特定のコンポジット・アプリケーションによって利用されるデータは多数の場所に存在することができ、それらの場所のうち幾つかがデータ・ソース１２０８によって示されている。しかし、一般に、プログラムはデータが、ローカルのコンピューティング装置のような１つの場所に見つかることを期待する。図示および説明した実施形態では、データに幾つかの異なる場所（すなわち、データ・ソース１２０８）からアクセスすることができ、メタバース１２０６と称する中心位置に対する同期ポリシ・コンポーネント１２１０を介してデータを処理することができる。メタバースは、アプリケーションが見ることを期待するデータのビューを構成し、同期ポリシ・コンポーネント１２１０は様々なソースからのデータを処理しそのデータをアプリケーションが見ることを期待する形式で置く責任をもつ。適切な形式になると、その構成部分がリポジトリ１２０４内に存在するアプリケーションは、メタバース１２０６内のデータに対して動作することができる。

アプリケーションがメタバース内のデータに対して動作すると、そのデータをその適切なデータ・ソースに送り戻すことができる。同期ポリシ・コンポーネント１２１０は、そのプロセス・サーバ１２１２ならびに関連するワークフロー・コンポーネント１２１４およびルール・コンポーネント１２１６とともに、データが同期されデータが同期されたままであることを保証するように動作する。データが同期されると、データをその適切なデータ・ソース（複数可）に戻すことができる。メタバース・コンポーネント１２０６に関して、以下を考える。上の調整シナリオ（すなわち、述べた試みのうち最初のもの）において、メタバースは、調整されている全てのシステム内にある全てのデータの組合せであるデータ・ビューを構成する。調整ポリシは、通常、メタバース・スキーマと元のソースの観点から扱われる。統一されたビューのシナリオ（すなわち、述べた試みのうち第２のもの）では、メタバースは、アプリケーションが関心をもつビュー、すなわち、特定のアプリケーションに関連する周囲の記憶域全ての中にあるデータの特定のサブセットを構成する。

１つまたは複数の実施形態では、実行されるプログラムの一部は、プロセス・サーバのようなコンピューティング装置によって実行される部分と、所謂ピープル・レディ・プロセスを用いて個人が実行する部分を含むことができる。ピープル・レディ・プロセスの例を、ビジネスで一般に実装できるプロセスと考えることができる。このシナリオでは、ピープル・レディ・プロセスの一部を、ユーザ・インタフェース・プロセスを介して、個人が作業の一部を実施できるようにする特定のユーザ・インタフェースに提示することができる。例えば、特定のプロセスに３つのステップ、すなわち完全に自動化されたプロセスでＡ→Ｂ→Ｃが関与する場合、ＡとＢとＣはコード、ルールまたはワークフローによって規定されるはずである。ピープル・レディ・プロセスでは、恐らく、Ｂがメールをレポートのコピーを求める人に送信し、Ｃは管理者がレポートを読んで承認することを求めるタスクをＯｕｔｌｏｏｋ「登録商標」に挿入する。図１３は、アプリケーション・ライフサイクル・サービス環境の例を一般的に１３００で示す。ここで、環境１３００は実行コンポーネント１３０２、リポジトリ１３０４、分析コンポーネント１３０６、およびアプリケーション１３０８、およびリポジトリに流れ込む様々なオーサリング・ツールまたは開発ツール１３０８を備える。

ここで、コード・モジュールを、様々な開発ツール１３１０を用いて書き、テスト用にソース制御システムに格納し、最終的にリポジトリ１３０４に発行することができる。ソース制御システムを、例えば履歴および改訂を追跡し続け、システムを構築およびテストするプロセスに流れ込むために係るシステムを一般に使用するという理由で、使用することができる。開発ツールでは、個人がコード・モジュールを作成できる幾つかの異なる粒度レベルを提供することができる。

アプリケーションをデプロイするとき、実行コンポーネント１３０２はリポジトリ１３０４からアプリケーションにアクセスし、そのアプリケーションの実行準備を行う。これを行うために、実行コンポーネントは、アプリケーションが実行されるマシン、使用されるトランスポート、セキュリティ証明書、等を決定する。この点で、実行コンポーネントは、本例ではワークフローによって駆動されるプロセス改善として知られるものを実装する。実行コンポーネントがその作業を完了し、全てのデプロイメント・パラメータが決定されると、アプリケーションを実行することができる。この点で、実行コンポーネント１３０２は接続されたアプリケーションに様々な状態変更を受けさせる。係る状態変更は、限定ではなく例として、「構築」状態から「改善」状態に移動させること、「改善」状態から「デプロイ」状態に移動させること、および／または「デプロイ」状態から「実行」状態に移動させることを含むことができる。これは、或る意味では、アプリケーションが受けうる１組の状態を一般化させたものである。図示および説明した実施形態では、個々の状態変化は、状態変化を引き起こす作業を行うワークフローとして実装される。

動作に際して、実行コンポーネントはアプリケーションのコンポーネントを様々なマシンに分散させ、それらのコンポーネントを１つの論理単位として扱うことができる。１つまたは複数の実施形態では、実行コンポーネントはコンポーネントを様々な環境（例えば、ＩＩＳ、ＷＡＳ、ＢｉｚＴａｌｋ、ＳＱＬ）で実行することができる。これらの環境は異なるマシン上にあるかもしれないが、異なるオペレーティング・システム上にあることもあるかもしれない。実行コンポーネントは、他の技術と比べて、調整インフラのプログラミングをより指向したインフラにはとらわれない。

このように、リポジトリ１３０４は多様な情報源、特に、モデル（主として分散モデルを含む）をリポジトリに寄せ集める。リポジトリは、そのリポジトリが統一されたモデルのビューをインフラとアプリケーションに提供できるようにそのリポジトリを他のデータ・ソースにプラグインさせる、アダプタを有する。

実行コンポーネントの視点からは、リポジトリは統一されたアプリケーションのビューを提供する。実行コンポーネントの作業は、そのアプリケーションを改良すること、そのアプリケーションをデプロイすること、そのアプリケーションをオンにすること、等によってそのアプリケーションを実行できる状態にすることである。

実行コンポーネントが扱う多様性は、ホスティングと、アプリケーションがその中またはその上で実行する必要がある他のインフラ・サブシステムの多様性である。この点で、実行コンポーネントを、この多様性を連合させ、これらの異なる種類のソフトウェア・インフラ全ての上に単一の論理的なホストのビューを提供するものとみなすことができる。

特定の種類のインフラの知識を実行コンポーネントに直接構築することを避けるため、実行コンポーネントは、実行コンポーネントが基礎となるインフラを扱うために使用する「ドライバ」と呼ばれるモデルを有する。実行コンポーネントは、インフラの部分ごとに命令を生成し、その命令を対応するドライバに送信することによって、分散モデルに作用する。個々のドライバは同じインタフェースを実装し、従って、実行コンポーネントは、ドライバのインタフェースと通信することによって基礎となるインフラを抽象的に扱うことができる。

これを、実行コンポーネントの「命令制御」部分と考えることができる。作業を分散モデルで実施したい場合、実行コンポーネントに通知する。次いで、実行コンポーネントは適切なモデルを分析し、ホストおよびインフラ・モジュールごとにコマンドを生成する。次いで、実行コンポーネントはドライバを介してこれらのコマンドを基盤に送信する。従って、実行コンポーネントでは、実行コンポーネントがコマンドをモデル全体に与えていると考えることができ、全ての多様性をランタイム環境に隠蔽する。

実行コンポーネント１３０２、アプリケーション１３０８、分析コンポーネント１３０６、およびリポジトリ１３０４の間のループに留意されたい。このループに対する１つの具体的な理由は、アプリケーションが問合せに答える仕方と時期を定義するサービス・レベル・アグリーメントという概念があることである。例えば、分析コンポーネントに問い合わせて、どれくらい迅速にアプリケーション１３０８が問合せに答え、または他の何らかの作業を実施しているかを確かめることができる。アプリケーションの性能が望ましくないかまたは何らかの性能指標を満たさない場合、アプリケーションがその性能指標を満足できるように、モデルをリポジトリ内で調節することができる。そうすると、実行コンポーネント１３０２は実行中のモデルを更新してアプリケーションをより効率的にすることができる。従って、動的なフィードバック・ループが、目標指向の振舞いを実現することができ、アプリケーションのエンド・ユーザが必ず良い性能を享受しているようにすることができる。しかし、より一般には、連合された命令制御をサポートすることに加えて、実行コンポーネント１３０２はまた、アプリケーションに関する連合された知識収集をサポートする。アプリケーションに関する知識を収集するために、「観測モデル」を分散アプリケーション・モデルの一部としてリポジトリ１３０４に追加することができる。実行コンポーネントは観測モデルを分析し、アプリケーションの各部でどのデータを収集すべきかを確かめ、これらの要求をドライバに送る。次いで、ドライバは、そのドライバが担当するシステムの部分に適切なデータを収集させるための作業を実施する。

アプリケーションが実行されると、アプリケーションはその部分の各々においてイベントを発信する。各部分が発信するイベントの形式は一般に様々である可能性がある。例えば、データベースは一種のイベント、すなわちウェブ・ページを毎秒送信する、等である。アプリケーションの知識収集側では、ドライバの作業はこれらの多様なイベントを収集し、それらのイベントを汎用的な形式に変換し、変換したイベントを分析コンポーネント１３０６に挿入することである。分析コンポーネントは観測モデルに従ってイベントに対して処理を行う。例えば、平均応答時間に関して報告するように求められた場合は、分析コンポーネントは「入口」イベントおよび「出口」イベントを応答時間イベントに変え、次いでそれらを平均するはずである。これらの結果は、最終的には、リポジトリ１３０４を介して利用可能になるはずである。従って、行われることは、アプリケーションと観測モデルとに相関する１組のイベントが実行コンポーネントによって生成されることである。

上のサービス・レベル・アグリーメントの例は、本システムの特定の具体的な使用方法を構成する。サービス・レベル・アグリーメントは、関連データと、分析コンポーネントから来るイベントの流れを監視するイベント・ハンドラとを測定し、サービス・レベル・アグリーメントに違反した場合は何らかの措置を講ずるための観測モデルとして実装される。その措置は、例えば、人間のプロセス（例えば、誰かに送信される電子メール、ポータル上で生成される警告、等）に相当することもあれば、または、アプリケーションの再調節のような自動化されたプロセスであることもある。

図１４は、１つまたは複数の実施形態に従うリポジトリ環境の例を一般的に１４００で示す。ここで、リポジトリ１３０４は開発ツール１３１０と統合サービス・コンポーネント１４０２の間に論理的に挟まれているとして示されている。リポジトリはアプリケーション、その性能、ライフサイクル、要件、および他の全ての関連情報に関する情報を含む。従って、リポジトリ１３０４はそのデータを、１４０４で一般的に指定した様々なソースから受け取ることができる。例えば、１４０６で示したもののような多種多様な機構を用いてアプリケーション・データを記述することができる。代替または追加として、１４０８では、アプリケーションがＳＱＬテーブルまたはストアド・プロシージャを使用する場合は、ＳＱＬカタログが適切であるかもしれない。代替または追加として、１４１０では、様々なソース・コード制御システムまたはサードパーティの記述を１４１２で用いてアプリケーション・データを記述してもよい。このように、開発ツール１３１０は、一般に、リポジトリと主要な関係にあり、リポジトリは他のデータ記憶域と主要な関係にある。リポジトリは、統合サービス・コンポーネントを用いて、これらの様々なデータ記憶域にわたる連合されたビューを生成する。

１つまたは複数の実施形態では、統合サービス・コンポーネント１４０２はこのデータの全てを処理し、リポジトリ１３０４を介して見えるようにすることができる。実際には、リポジトリをＳＱＬアプリケーションとして実装することができる。従って、リポジトリにアクセスするために利用されるＡＰＩはＳＱＬのＡＰＩであることができる。どのようにこれらが全て連動できるかの例として、以下を考える。アプリケーションがウェブ・ページ、ワークフロー、データベースを有するとする。ユーザは、一般に、既存のツールを使用して、ウェブ・ページと、ソース・コード制御においてこれらのアーチファクトを格納するデータベースとを構築することがある。ユーザは、リポジトリ内のワークフローと分散アプリケーション・モデルとを構築するためにモデリング・ツールを使用するはずである。分散アプリケーション・モデルは、ソース・コード制御システムにおいてウェブ・ページとワークフローを指し示す。実行コンポーネントがモデルを読みに行くと、データベース記述が実際には他の記憶域にあり統合サービス・コンポーネント１４０２を介してリポジトリに橋渡しされている場合には、リポジトリ１３０４はそのモデルがウェブ・ページのように見せ、そのデータベース記述がリポジトリ内にあるように見せる。

図１５は、１実施形態に従う実行環境の例を一般的に１５００で示す。環境１５００は、本例では、リポジトリ１５０４とサービス・バス１５０６の間に論理的に挟まれている実行部１５０２を備える。

１つまたは複数の実施形態では、実行部１５０２は、ＳｈａｒｅＰｏｉｎｔ、ＩＩＳ／ＷＡＳ、ＢｉｚＴａｌｋ、ＳＱＬ Ｓｅｒｖｅｒのようなホストまたはコンテナを連合させて、アプリケーションをスコープとする（すなわち、アプリケーション全体の）指令、制御、および監視を分散アプリケーションに提供する。実行部１５０２が実施する機能の中には、限定ではなく例として、モデル全体のスコープでコマンドおよび制御要求を、分散モデルの一部が実行されるコンテナ上のコマンドおよび制御要求に変換することが含まれる。図示および説明した実施形態では、この変換は、カスタマイズ可能なビジネス・プロセスによって推進される。さらに、実行部１５０２は、モデル全体のスコープで規定された観測モデルを、個々のコンテナが特定の種類のイベントを生成するという要求に変換する。これらのイベントがコンテナ内で生成されると、実行部はそれらのイベントを標準形式に変換し、サービス・バス１５０２を介して、リポジトリ１５０４の一部として公開された稼動記憶域（ｐｅｒｆｏｒｍａｎｔ ｓｔｏｒｅ）に送信する。実行部１５０２は、実行中のモデルのパラメータ構成の一部に対する変更をリアルタイムにサポートし、その結果、アプリケーションを調整することができ、基礎となるアプリケーションを再起動せずに観測モデルを変更することができる。「デプロイ」および「実行」のような動詞をモデルに適用する能力をサポートすることによって、およびモデルに関する観測された情報を集約することによって、実行部は、既存のコンテナを連合させ、単一のシステム上で実行されている分散モデルのエクスペリエンスを提供する。

図１５の実例をより具体的に参照すると、リポジトリ１５０４は、アプリケーションと、そのアプリケーションが従うルールであるポリシ・アサーションを保持する。リポジトリはまた、アプリケーションに関連付けられたリソースの全てを含む。例えば、この特定のアプリケーションを、これらの特定の８個のコンピュータ、４つのＳＱＬサーバ、および２つのウェブ・サーバ上で実行することができる。これらのアプリケーション、リソース、および他のリポジトリ・データを幾つかの異なる方法でアクセスすることができる。例えば、ポータルを介して、管理コンソール（ＭＭＣ）を介して、またはＱｕａｄｒａｎｔ（または、リポジトリを直接対象とした他の何らかのモデリング・ツール）を介して、アクセスを行うことができる。従って、実行部は、リポジトリからアプリケーションにアクセスし、そのアプリケーションに関して他の機能を改良し、デプロイし、開始、停止し、バージョン管理し、実施する、エンティティである。

動作に際して、実行部１５０２は、それぞれを異なるマシン上で実行できる、幾つかの異なるサービスから構成される。この特定の例では、デプロイされたアプリケーション・モデルは、図示したようにプロセスがプロセス・サーバおよびＳＱＬデータベースによって管理されるＳｈａｒｅｐｏｉｎｔアプリケーションであってもよい。実行部は、一般に、アプリケーション・モデルをとって、どの特定のＳＱＬサーバおよびプロセス・サーバが使用されようとしているかを確かめる等のような何らかの改良を実施する。どの特定のサーバまたはサービスが使用されるかを確かめた後は、実行部は、デプロイに使用するドライバを知っており、モデルをデプロイすることができる。実行部のドライバ管理機能により、実行部に、アプリケーションを実行できる様々な場所の全て、例えばＳｈａｒｅｐｏｉｎｔ、ＳＱＬ、ＣＯＭ＋、ＳＱＬ、Ｗｉｎｄｏｗｓ Ｓｈｅｌｌ等、を扱う能力が提供される。

このように、アプリケーションはリポジトリ内に存在し、考えられる限り多数の異なるコンポーネント・モジュールから構築されている。実行部はこれらのモジュールを理解し、モジュールまたはモジュールの知識を獲得し、そのモジュールを、そのモジュールが実行される場所にデプロイする。

次いで、これらのコンポーネント・モジュールは２つの異なる目的でサービス・バス１５０６を使用することができる。第１に、コンポーネント・モジュールは、サービス・バスを用いて互いに通信することができる。さらに、コンポーネント・モジュールは関連するイベント・データを獲得し、サービス・バスを使用して図１３の分析コンポーネントのような分析コンポーネントを介してリポジトリにイベント・データを戻すことができる。これにより、観測モデルをアプリケーションと関連して使用することができる。観測モデルは、どのイベントを生成すべきかを伝える命令を、ホスト内で実行されているアプリケーション・モジュールに提供する。観測モデルはまた、イベントが観測モデルの観測要求に答えるようにそのイベントを後処理する方法に関して分析コンポーネントに指示する。このように、観測モデルは、アプリケーションの実行に関する分析を行うために使用できる、アプリケーションに関する情報を選択的に収集する。係る情報を使用して、アプリケーションを改良するか、またはアプリケーションの実行を改善する変更をオンザフライで行うことができる。係る情報は、より一般的には、ロギング、ガバナンス、監視、等のようなものに有用である。

図１６は、１つまたは複数の実施形態に従う環境の例を一般的に１６００で示す。ここで、必要に応じて、図１５の実施形態と同じ番号を、同じコンポーネントを示すために使用している。環境１６００は、実行部１５０２、リポジトリ１５０４、サービス・バス１５０６以外にも、システムの分析サービスの一部とみなしうるものを備える分析コンポーネント１６０２を備える。

具体的には、ここで、分析コンポーネント１６０２は、イベント・データ（すなわち、イベントのインスタンス）をリポジトリ１５０４から読み出し、そのイベント・データに何らかの方法で作用するように構成される。イベント・データは以前に作成されており、サービス・バスを介してリポジトリに提供されたことを思い出すこと。

動作に際して、分析コンポーネント１６０２はイベント・データを任意の適切な方法で処理することができる。例えば、分析コンポーネントは、アプリケーションの性能に関する質問に答えるために、統計分析をイベントに対して実行することができる。さらに、ユーザは、分析コンポーネントによって作成されたデータに、特定のアプリケーションがどのように動作しているかを記述するユーザ・インタフェースを提供するポータルを介して、アクセスすることができる。

さらに、分析コンポーネントをまた、ＫＰＩ（ｋｅｙ ｐｅｒｆｏｒｍａｎｃｅ ｉｎｄｉｃａｔｏｒ）およびＳＬＡ（ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ）を読み、これらをアプリケーションの性能の分析において使用するように構成することができる。係るＫＰＩおよびＳＬＡを使用して、例えば、アプリケーションまたはそのコンポーネントの１つを再構成し、アプリケーションを再デプロイすることによって、アプリケーションの性能を向上させることができる。

ツール・コンポーネント
１つまたは複数の実施形態では、ツール・コンポーネント１１０（図１）は様々なツールを備え、その例には、Ｖｉｓｕａｌ Ｓｔｕｄｉｏコンポーネント１３２のようなコード・ベースのツール、Ｑｕａｄｒａｎｔコンポーネント１３４のようなモデル・ベースのツール、およびＳｙｓｔｅｍ Ｃｅｎｔｅｒコンポーネント１３６のようなエンタープライズ管理ツールが含まれる。

１つまたは複数の実施形態では、利用できる幾つかの異なるモデルがあり、それぞれを密接に関連付けることができる。具体的には、アプリケーションはモデル、コード・アーチファクトから構築され、エンタープライズ管理ツールというより大きなコンテクストで管理される。Ｖｉｓｕａｌ Ｓｔｕｄｉｏのようなコード・ベースのツールは、コード・アーチファクトの作成、テスト、更新をサポートする。Ｑｕａｄｒａｎｔのようなモデル・ベースのツールは、モデルの作成、テスト、更新をサポートする。モデル・ベースのツールは、モデル間の関係、モデルとコード・アーチファクトの間の関係を認識する。なぜならば、これらの関係がモデルにおいて記述されているからである。

基本的には、モデル・ベースのツールは、モデルの一定の品質を明らかにするビュー（ボックス・ライン（ｂｏｘ−ａｎｄ−ｌｉｎｅ）、フォーム、テーブル、等）を介して全てのモデルを見えるようにする、汎用的な編集エクスペリエンスを提供する。ユーザはこの汎用的な編集エクスペリエンスをカスタマイズして、カスタマイズしたビューを格納し、将来同様なデータを扱うときにそのビューを呼び出すことができる。開発者は、特定のモデル用にカスタマイズした新しいエディタを構築することができる。これらのエディタはカスタムな編集エクスペリエンスを提供することができるか、または或る特定のモデルに固有な機能（例えば、ワークフローをワークフロー・エディタでデバッグできること）を提供することができる。

リポジトリ１５０４は、モデルに対するスキーマとモデルのインスタンスの両方を含む。モデル・スキーマは単なるモデルでありリポジトリはスキーマを有するので、様々なモデル・ベースのツールを使用して、新しいモデルと、既存のモデルのインスタンスを生成することができる。

システムの例
図１７は、上述の様々な実施形態を実装できるコンピューティング装置の例１７００を示す。コンピューティング装置１７００は、例えば、クライアント装置および／またはサーバ装置のような任意の適切なコンピューティング装置であることができる。

コンピューティング装置１７００は、１つまたは複数のプロセッサもしくは演算装置１７０２、１つまたは複数のメモリおよび／もしくは記憶装置１７０４、１つまたは複数のＩ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ）装置１７０６、ならびに様々なコンポーネントおよび装置が互いに通信できるようにするバス１７０８を備える。バス１７０８は、メモリ・バスまたはメモリ・コントローラ、周辺バス、高速グラフィック・ポート、様々なバス・アーキテクチャの何れかを用いたプロセッサ・バスまたはローカル・バスを含む、任意の数種のバス構造のうち１つまたは複数を表す。バス１７０８は、有線バスおよび／または無線バスを含むことができる。

メモリ／記憶域コンポーネント１７０４は、１つまたは複数のコンピュータ記憶媒体を表す。コンポーネント１７０４は、（ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）のような）揮発性媒体および／または（ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュ・メモリ、光ディスク、磁気ディスク、等のような）不揮発性媒体を備えることができる。コンポーネント１７０４は、固定媒体（例えば、ＲＡＭ、ＲＯＭ、固定ハード・ドライブ、等）、および取外し可能媒体（例えば、フラッシュ・メモリ・ドライブ、取外し可能ハード・ドライブ、光ディスク、等）を備えることができる。

１つまたは複数の入出力装置１７０６により、ユーザはコマンドと情報をコンピューティング装置１７００に入力することができ、情報をユーザおよび／またはコンポーネントもしくは装置に提示することができる。入力装置の例には、キーボード、カーソル制御装置（例えば、マウス）、マイクロフォン、スキャナ、等が含まれる。出力装置の例には、表示装置（例えば、モニタまたはプロジェクタ）、スピーカ、プリンタ、ネットワーク・カード、等が含まれる。

本明細書では様々な技法をソフトウェアまたはプログラム・モジュールの一般的なコンテクストで説明することができる。一般に、ソフトウェアは、特定のタスクを実施するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。これらのモジュールおよび技法の実装形態を、何らかの形のコンピュータ読取可能媒体に記憶するか、またはその媒体にわたって送信することができる。コンピュータ読取可能媒体は、コンピューティング装置がアクセス可能な任意の利用可能な１つまたは複数の媒体であることができる。限定ではなく例として、コンピュータ読取可能媒体は、「コンピュータ記憶媒体」と「通信媒体」を備えることができる。

「コンピュータ記憶媒体」には、コンピュータ読取可能命令、データ構造、プログラム・モジュールまたは他のデータのような情報を記憶するための任意の方法または技術で実装した揮発性および不揮発性媒体、取外し可能および取外し不能媒体の両方が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または所望の情報の記憶に使用できコンピュータがアクセスできる他の任意の媒体が含まれるがこれらに限らない。

「通信媒体」は、一般に、コンピュータ読取可能命令、データ構造、プログラム・モジュールまたは他のデータを搬送波または他の伝送機構のような変調データ信号で具現化する。通信媒体はまた、任意の情報配送媒体を含む。「変調データ信号」という用語は、１つまたは複数のその特性集合を有するか信号内の情報をエンコードするよう変化した信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続のような有線媒体、ならびに音響、ＲＦ、赤外線および他の無線媒体のような無線媒体が含まれる。上の何れかの組合せもコンピュータ読取可能媒体の範囲内に含まれるべきである。

結論
諸実施形態では、コンポジット（複合）型の、自律的なアプリケーションおよびサービスを構築しデプロイできるようにするアーキテクチャを提供する。さらに、分散型のアプリケーションとサービスの間での通信を可能とするインフラが提供される。

１つまたは複数の実施形態では、例示的なアーキテクチャが、接続性サービス、プロセス・サービス、アイデンティティ・サービス、ライフサイクル・サービス、およびツールを含む５つの論理モジュールを備えるかまたは利用する。

主題を構造的特徴および／または方法論的動作に固有な言葉で説明したが、添付の特許請求の範囲で定義した主題は必ずしも上述の特定の特徴または動作に限定されないことは理解されよう。そうではなく、上述の特定の特徴および動作は諸請求項を実装する形態の例として開示されている。

Claims (5)

1. コンポジット・アプリケーションとサービスが互いに通信できるようにするための接続性サービスを提供するステップであって、前記接続性サービスは、１つまたは複数のアプリケーション・モジュールにおける期待される状態と期待されない状態に対する応答調整をサポートし、メッセージ仲介サービスを提供し、複数のエンドポイントを介した転送、発見、および同期を仮想化し、前記接続性サービスはさらに、複数の異なるエンコード標準をサポートし、メッセージ・ベースのポイント・ツー・ポイント通信を促進し、問合せをサポートし、アプリケーションが一貫して名付けられることを保証し、コンポジット・アプリケーションにセキュリティ・アーキテクチャを提供し、前記接続性サービスは、広域近接性認識型のルーティングを実装し、連合名前空間を提供する、ステップと、
   コンポジット・アプリケーションにランタイムを提供するプロセス・サービスを提供するステップであって、前記プロセス・サービスは、メッセージを受け取り、それに応答して、メッセージが送信されたプロセスを実行するように使用できる環境を提供し、メッセージを処理し、実行されているかもしれないプロセスにメッセージを関連づけることを試みる、ステップと、
   コンポジット・アプリケーションに関連付けられたアイデンティティ操作を実施するアイデンティティ・サービスを提供するステップであって、前記アイデンティティ・サービスは、アクセス層と前記アクセス層を介してアクセス可能なディレクトリ・スタックとを含み、前記アクセス層は、前記ディレクトリ・スタック内のデータにアクセスするための複数の異なる種類のＡＰＩと、コンポジット・アプリケーションと関連してアイデンティティを管理し使用するためのアクセス・サービスとを備える、ステップと、
   コンポジット・アプリケーションを実行できる環境を提供するライフサイクル・サービスを提供するステップであって、前記ライフサイクル・サービスは、コンポジット・アプリケーションに関連付けられた情報を保持し、複数の異なるデータ・ソースとコンポジット・アプリケーションの間でデータを同期し、コンポジット・アプリケーションにアクセスし、前記コンポジット・アプリケーションを異なるマシンに配布し、１つまたは複数のコンポジット・アプリケーションの性能を分析する、ステップと、
   を含む、コンピュータに実装された方法。
2. 実行時に、
   コンポジット・アプリケーションとサービスが互いに通信できるようにするための接続性サービスを提供するステップであって、前記接続性サービスは、１つまたは複数のアプリケーション・モジュールにおける期待される状態と期待されない状態に対する応答調整をサポートし、メッセージ仲介サービスを提供し、複数のエンドポイントを介した転送、発見、および同期を仮想化する、ステップと、
   コンポジット・アプリケーションにランタイムを提供するプロセス・サービスを提供するステップであって、前記プロセス・サービスは、メッセージを受け取り、それに応答して、メッセージが送信されたプロセスを実行するように使用できる環境を提供し、メッセージを処理し、実行されているかもしれないプロセスにメッセージを関連づけることを試みる、ステップと、
   コンポジット・アプリケーションに関連付けられたアイデンティティ操作を実施するアイデンティティ・サービスを提供するステップであって、前記アイデンティティ・サービスは、アクセス層と前記アクセス層を介してアクセス可能なディレクトリ・スタックとを含み、前記アクセス層は、前記ディレクトリ・スタック内のデータにアクセスするための複数の異なる種類のＡＰＩと、コンポジット・アプリケーションと関連してアイデンティティを管理し使用するためのアクセス・サービスとを備える、ステップと、
   コンポジット・アプリケーションを実行できる環境を提供するライフサイクル・サービスを提供するステップであって、前記ライフサイクル・サービスは、コンポジット・アプリケーションに関連付けられた情報を保持し、複数の異なるデータ・ソースとコンポジット・アプリケーションの間でデータを同期し、コンポジット・アプリケーションにアクセスし、前記コンポジット・アプリケーションを異なるマシンに配布し、１つまたは複数のコンポジット・アプリケーションの性能を分析する、ステップと、
   を含む方法を実装する命令を具現化する、１つまたは複数のコンピュータ読取可能記憶媒体。
3. 前記接続性サービスは、複数の異なるエンコード標準をサポートし、メッセージ・ベースのポイント・ツー・ポイント通信を促進し、問合せをサポートし、アプリケーションが一貫して名付けられることを保証し、コンポジット・アプリケーションにセキュリティ・アーキテクチャを提供する、請求項２に記載の１つまたは複数のコンピュータ読取可能媒体。
4. 前記接続性サービスは、広域近接性認識型のルーティングを実装し、連合名前空間を提供する、請求項３に記載の１つまたは複数のコンピュータ読取可能媒体。
5. 前記接続性サービスは、メッセージおよびイベントの登録を管理し、メッセージ・ノードを対象としたメッセージを受け取り、メッセージ・ノードからのメッセージを送信する、請求項２に記載の１つまたは複数のコンピュータ読取可能媒体。

Images