JP2004501427A - 分散コンピューティング環境でサービスの結果を返す機構および装置 - Google Patents

Abstract

分散コンピューティング環境内でサービスの結果を返すシステムおよび方法を提供する。クライアントが、サービスの１つまたは複数の関数を呼び出した後に、関数の結果を、複数の方法で、たとえば、メッセージ内で、スペース（たとえばネットワーク・アドレッシング可能なストレージ・ロケーション）内で、クライアントがイベントを介して知らされるスペース内で、メッセージ内で返される通知を使用して、スペース内で返される通知を使用して、およびクライアントがイベントを介して通報されるスペース内で返される通知を使用して、クライアントに返すことができる。通知に、スペースなどのストレージ・ロケーションの結果にアクセスし、読み取るのに必要な情報を含めることができる。サービスのスキーマで、サービスの関数を呼び出すのに使用可能な複数のメッセージを指定することができる。メッセージ、結果、および通知は、ＸＭＬなどの、プラットフォーム独立および／またはプログラム言語独立のデータ表現言語で表現することができる。この複数の方法の使用可能性によって、異なる機能を有するクライアントに関するものなどのさまざまな情況に関する分散コンピューティング環境の柔軟性および適応性を強化することができる。追加の柔軟性について、結果を、別のサービスに効率的に渡すこともできる。

Description

【０００１】
（発明の背景）
（１．発明の分野）
本発明は、ウェブ中心およびインターネット中心の分散コンピューティング環境を含む分散コンピューティング環境に関し、より詳細には、ネットワーク・クライアントとサービスを接続する、メッセージ・パッシング・モデルに基づく異機種分散コンピューティング環境に関する。
【０００２】
（２．関連技術の説明）
インテリジェント型デバイスの普及が進んでいる。このようなデバイスとしては、スマート・アプライアンス、パーソナル・デジタル・アシスタント（ＰＤＡ）、携帯電話、ラップ・トップ・コンピュータ、デスクトップ・コンピュータ、ワークステーション、メインフレーム、さらにはスーパー・コンピュータなどもある。ネットワークも、次第に、互いに通信できるインテリジェント型デバイスを相互接続する一般的な方法となってきている。ただし、さまざまなインテリジェント型デバイスの計算能力と記憶能力には大きな違いがある。能力が制限されているデバイスは、省スペース・デバイスまたは「シン（ｔｈｉｎ）」デバイス呼ばれることがある。シン・デバイスは、より能力の高いデバイスを相互接続するネットワークに参加することができない場合がある。しかし、さまざまな異なる種類のインテリジェント型デバイスを相互接続することが望ましいと考えられる。
【０００３】
ネットワーキング能力の向上はなおいっそう望まれている。ビジネス用ネットワークは、仕入れ先と顧客との相互の直接的なやり取りを取り込むように拡大を続けている。携帯電話、パーソナル・デジタル・アシスタント、およびインターネット対応コンピュータは、企業においても家庭においても当たり前のものになっている。ホーム・ネットワークは、テレビやステレオ機器などのオーディオ／ビジュアル機器を家庭用コンピュータ、およびセキュリティ・システムや温度制御サーモスタットなどのインテリジェント型システムを制御するその他のデバイスに相互接続するために使用することができる。ケーブルやＡＳＤＬなどの高帯域幅メディアを使用すると、インターネット・アクセス・ビデオ・オンデマンド、電子商取引などのサービスを向上させることができる。ネットワーク・システムは普及途上にある。正式なネットワークがなくても、インテリジェント型デバイスで互いに通信し、またリソースを共有できることが望ましい。
【０００４】
現在、従来のネットワークのセットアップ、拡張および管理は複雑な作業である。たとえば、ハードウェアまたはソフトウェアをネットワークに追加するには、多くの場合、ネットワーク管理者がドライバをロードをし、システムを設定する必要がある。ネットワーク構成に小さな変更を加えるにしても、ネットワーク全体を一定期間停止することが必要になる場合がある。さらに、所定のネットワークで通信するのに必要なインターフェースをサポートしていないインテリジェント型デバイスもある。
【０００５】
必要なのは、各種のインテリジェント型デバイスを接続し、通信およびリソースの共有を可能にしながら、従来のネットワークに存在する相互運用性と複雑な構成という問題を回避できる単純な方法である。ネットワークにデバイスを追加する機能を改善する技術はさまざまなものが存在する。たとえば、ユニバーサル・シリアル・バス、１３９４、およびＰＣＩなどの多くの現代的な入出力バスでは、プラグ＆プレイや動的ディスカバリ・プロトコルをサポートしており、新しいデバイスをバス上に追加する作業が簡単に行える。しかし、これらの解決方法は、特定の周辺機器バスに制限されており、一般的なネットワークには適していない。
【０００６】
最近の技術である、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のＪｉｎｉでは、プリンタおよびディスク・ドライブなどのデバイスをネットワーク上で簡単に接続し共有できるようにすることを追求している。Ｊｉｎｉを組み込んだデバイスは、ネットワークへアナウンスを行い、自デバイスの能力に関する詳細を知らせ、直ちにネットワーク上の他のデバイスからアクセスできる状態に入る。Ｊｉｎｉでは、さまざまなデバイスの機能をネットワーク上で共有する分散コンピューティングが可能になっている。Ｊｉｎｉ技術は、ユーザがネットワーク上でサービスおよびリソースを共有できるようにすることを目指している。Ｊｉｎｉ技術の他の目標は、たとえユーザのネットワーク・位置が変化してもユーザはネットワーク上の任意の場所のリソースに簡単にアクセスすることができるようにすることである。Ｊｉｎｉではさらに、デバイス、ソフトウェア、およびユーザのネットワークを構築し、保守し、変更するタスクを簡素化することも追及している。
【０００７】
Ｊｉｎｉでは、各Ｊｉｎｉ対応デバイスに特定の容量のメモリと処理能力が必要である。通常、Ｊｉｎｉ対応デバイスはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）を備えている。そのため、ＪｉｎｉシステムはＪａｖａ技術を中核とする。Ｊａｖａは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が開発した高水準オブジェクト指向プログラミング言語である。Ｊａｖａソース・コードをバイトコードと呼ばれる形式にコンパイルし、これをＪａｖａ仮想マシンで実行することができる。
【０００８】
バイトコードは、「実際の」コンピュータ・マシンであるハードウェア・プロセッサではなく、仮想マシンにより処理されるコンピュータ・ソース・コードである。仮想マシンは、一般化された機械語命令（バイトコード）を特定の機械語命令（コンピュータのプロセッサが理解する命令）に変換する。各プラットフォームの仮想マシンに付属する言語を使用し、ソース言語ステートメントを１回だけコンパイルして、その仮想マシンをサポートするプラットフォーム上で実行することができる。Ｊａｖａプログラミング言語は、このような言語の一例であり、Ｊａｖａ仮想マシン（ＪＶＭ）は、Ｊａｖａプログラミング言語で書かれたプログラムをサポートする仮想マシン・プラットフォームの一例である。Ｊａｖａ仮想マシンは、ほとんどのコンピューティング・プラットフォームに用意されているため、ＪａｖａしたがってＪｉｎｉは一定のプラットフォーム独立性を実現している。Ｊｉｎｉアーキテクチャでは、Ｊａｖａプログラミング言語がＪｉｎｉシステムのコンポーネントの実装言語であるという想定を活用している。Ｊａｖａコードを動的にダウンロードして実行できることが、Ｊｉｎｉアーキテクチャの多くの機能の中心となっている。
【０００９】
Ｊｉｎｉアーキテクチャの目的は、デバイスとソフトウェア・コンポーネントからなる複数のグループを単一の動的分散システムとして連合させることである。Ｊｉｎｉアーキテクチャの概念で重要なのは、サービスという概念である。サービスは、人、プログラム、または他のサービスが使用できるエンティティである。サービスの例としては、文書を印刷するサービスと、一方のワードプロセッサ形式から他方の形式に変換するサービスの２つがある。Ｊｉｎｉを使用すると、Ｊｉｎｉシステムのメンバがサービスへのアクセスを共有することができる。Ｊｉｎｉシステム内のサービスは、Ｊａｖａプログラミング言語で書かれた一組のインターフェースである、サービス・プロトコルを使用することにより互いに通信する。サービスの探索およびソリューションは、Ｊｉｎｉシステム内でルックアップ・サービスを使用して行う。ルックアップ・サービスにより、サービスによって提供される機能を示すインターフェースを、そのサービスを実装するオブジェクト群にマッピングする。
【００１０】
記述エントリもサービスに関連付けることができる。デバイスとアプリケーションは、発見（ｄｉｓｃｏｖｅｒｙ）と呼ばれるプロセスを使用してＪｉｎｉネットワークに登録する。デバイスまたはアプリケーションは、いったん登録されると、ルックアップ・サービス内に入る。ルックアップ・サービスでは、ネットワーク上のこれらのサービスへのポインタを格納するだけでなく、これらのサービスにアクセスするためのコードも格納する。たとえば、プリンタはルックアップ・サービスに登録されると、そのプリンタ・ドライバおよび／またはドライバとのインターフェースをルックアップ・サービスにロードする。クライアントがプリンタの使用を要求すると、そのドライバおよびドライバ・インターフェースはルックアップ・サービスからそのクライアントにダウンロードされる。このようにコードを移動できることは、クライアント側で、ドライバやその他のソフトウェアをプリインストールしたりロードをすることなく、ネットワークからのサービスを利用することができることを意味する。
【００１１】
Ｊｉｎｉシステム内のサービス間の通信は、Ｊａｖａ Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）を使用してを行う。ＲＭＩは、従来のリモート・プロシージャ・コールのメカニズムに対するＪａｖａプログラミング言語対応の拡張機能である。ＲＭＩでは、Ｊｉｎｉネットワーク内でオブジェクトからオブジェクトへデータを渡すことができるだけでなく、コードを含む完全なオブジェクトも渡すことができる。Ｊｉｎｉシステムは、コードがＪａｖａオブジェクトとしてカプセル化された形式でネットワーク内を移動できることに依存している。
【００１２】
Ｊｉｎｉシステム内のサービスへのアクセスはリースに基づく。リースとは、一定期間保証されたアクセスを許可することである。各リースはサービスの利用者とサービスのプロバイダとの間で、サービス・プロトコルの一環として交渉される。ある期間サービスが要求されると、ある期間、たぶん要求期間と考えられるが、アクセスを許可できる。サービスがＪｉｎｉシステムの一部としてとどまるためにはリースを更新する必要がある。
【００１３】
図１は、Ｊｉｎｉの基本的な技術の積み重ねを示している。Ｊｉｎｉ技術では、分散プログラミング・モデル１２（ＪａｖａＳｐａｃｅｓ、リース、およびオブジェクト・テンプレートによってサポートされている）を定義する。Ｊｉｎｉのオブジェクト通信は、ＴＣＰ／ＩＰ対応ネットワーキング・レイヤ１６上のＲＭＩレイヤ１４に基づいている。
【００１４】
Ｊｉｎｉは、分散コンピューティングを簡素化するための有望な技術である。ただし、デバイスの種類によっては、Ｊｉｎｉが適さない場合もある。コンピューティング技術の流れは、分散Ｗｅｂ中心サービスおよびコンテンツ・モデルに向かっており、クライアント・サービスとコンテンツの内容は急激に変化している。将来のクライアントは、ユーザがどこへでも持ち運べるコンパニオン・タイプのデバイスになると思われる。このようなデバイスとしては、たとえば、携帯電話とＰＤＡとの組み合わせが考えられる。このようなデバイスがより強力なデバイスとだけでなく、より軽量なシン・デバイスまたは非力なデバイスとも通信し、リソースを共有できることが望ましい。
【００１５】
さらに、インターネットが出現し、その結果ネットに接続したデバイスが爆発的に増え、こうした現象を活用するように設計された分散プログラミング・モデルが必要になった。クライアントが信頼できる、セキュリティで保護され安全な方法でサービスに接続するための実現技術が要求される。シック（ｔｈｉｃｋ）・クライアントからシン・クライアントに至るさまざまなクライアントとサービスをインターネット、企業内イントラネット、またさらには単一コンピュータ内で接続する必要がある。クライアントとサービスの両方から距離、待ち時間、実装を抽象化（ａｂｓｔｒａｃｔ）することが望ましい。
【００１６】
分散コンピューティング技術で重要な課題は、パワーのあるシック・クライアントから組み込み型モバイル・デバイスなどの非常に軽量なシン・クライアントに至るまでスケーラブルにすることである。Ｊｉｎｉなどの現在の分散コンピューティング技術は、あらゆる種類のクライアントのニーズに応じられるほどスケーラブルでないといえる。省スペース・デバイスや組み込み型デバイスなどの一部のデバイスでは、メモリリソースが十分でなかったり、十分なネットワーキングの帯域幅を欠いていたりして、現在の分散コンピューティング技術に十分に参加できない。組み込み型モバイル・デバイスなどのクライアント製品群のローエンドは、多くの場合、コード実行環境が限られていたり固定されている。これらのデバイスもまた、ストレージ能力が最低限であったりあるいは全く永続性がない場合がある。大半の小型組み込み型モバイル・デバイスは、Ｊａｖａ仮想マシンをサポートしていない。ほとんどのコード実行可能小型クライアントはネイティブ・コードのみを実行する。さらに、ほとんどの小型デバイスは、その単独の永続的ストレージ・メディアとしてせいぜいフラッシュ・メモリーやバッテリ・バックアップＲＡＭを備えているぐらいである。ストレージの容量は非常に小さく、時には本質的に読み取り専用であることが多い。さらに、このタイプのストレージ・メディアのアクセス・タイムは、より強力なクライアントのハード・ディスクのアクセス・タイムに比べて１桁以上遅いことが多い。
【００１７】
Ｊｉｎｉなどの既存の接続技術は、サイズが大きいことから、望んでいるほどはスケーラブルでありえない。たとえば、Ｊｉｎｉでは、すべての参加者がＪａｖａをサポートする必要があるが、小さなクライアントの多くはＪａｖａ仮想マシン用にリソースを確保することはできない。さらに、ＪｉｎｉではＲＭＩを使用するため、クライアント側でコードとコンテンツをダウンロードできる必要がある。Ｊｉｎｉは、新しいクラスをダウンロードすることにより既存のクライアント・プラットフォームを補強しているので、組み込む型デバイスなどの小型デバイスにセキュリティおよびサイズの面で問題が生じることがある。Ｊｉｎｉは、コードとデータを渡すことによりクライアントとリソースが通信するという形で動作する。クライアントがＪｉｎｉサービスをアクティブにすると、このサービスは結果をクライアントに返すが、これには大量のコードまたはコンテンツが含まれる場合がある。Ｊｉｎｉでは、クライアントはメソッドを呼び出し、大きなオブジェクトが返され、それをダウンロードすることがある。クライアントは、返されたオブジェクトを受け入れるだけのリソースを持たないことがある。さらに、ＲＭＩとＪａｖａ自体が大量のメモリを必要とする。多くの省スペース・デバイスは、現在の分散コンピューティング技術に事実上または少しでも加わるだけのリソースを持たないことがある。
【００１８】
既存の分散コンピューティング技術の問題としては他に、多くの場合、複数のレベルの接続能力およびプロトコルを必要とするという点があげられる。たとえば、Ｊｉｎｉでは、コンピュータとデバイスを接続するための妥当な速度のネットワークが存在していることを想定している。またＪｉｎｉでは、ＴＣＰ／ＩＰネットワーク・トランスポート・プロトコルをサポートするデバイスも必要とする。しかし、多くの小型デバイスは接続能力が限られている。小型デバイスは、ネットワーク接続の待ち時間が長かったり、または低速であったりし、ＴＣＰ／ＩＰをサポートしない場合もある。
【００１９】
上述のように、Ｊｉｎｉでは、ＪａｖａをサポートするＪａｖａ仮想マシンを備えるデバイスを必要とし、そのため、多くの小型デバイスには備えられないような処理能力およびストレージ機能を必要とする。このこともまた、Ｊａｖａ対応でないデバイスはＪｉｎｉシステムに直接参加できないという点でＪｉｎｉの柔軟性を制約している。ＪｉｎｉはＪａｖａを必要とするため、均質的な環境とみなすことができる。ただし、非常に小型の組み込み型デバイスからＰＤＡ、携帯電話、さらにラップトップおよび最強のコンピュータに至るまでの異機種分散コンピューティングに対応する分散コンピューティング機能を備えることが望ましい。コモン・オブジェクト・リクエスト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）など他の異機種ソリューションも存在する。ＣＯＲＢＡは、プログラム・オブジェクトが、作成に使用されたプログラミング言語に関係なく、またはそのオブジェクトが実行されるオペレーティング・システムに関係なく互いに通信できるようにするアーキテクチャである。しかし、ＣＯＲＢＡはＪｉｎｉで取り扱われている接続問題をすべて取り扱えるわけではない。さらに、ＣＯＲＢＡにはＪｉｎｉと似たスケーラビリティの問題もある。
【００２０】
ＪｉｎｉやＣＯＲＢＡなどの技術では、コード中心のプログラミング・モデルを使用して、リモート・コンピュータ間のインターフェースを定義している。コード中心プログラミング・モデルでは、リモート・クライアントまたはコンポーネント間の通信にプログラム・インターフェースまたはＡＰＩを定義する。ＡＰＩは、特定のプログラミング言語で定義することができる。ＡＰＩは、適切な相互運用性を確実なものとするために、すべてのソフトウェア・コンポーネントで矛盾がないようになっていなければならない。コンポーネントに対するアクセスはすべてこれらの標準ＡＰＩを通じて行うため、これらのＡＰＩを実装するコードがクライアント・プラットフォーム内に存在している必要がある。コードは、プラットフォームに静的にリンクすることも、また必要に応じて動的にダウンロードすることもできる。多くの組み込み型またはモバイル・デバイスは、単に、品質管理問題がかかわっているだけでなく、単一の言語およびプログラム実行環境に依存しているということから、コードをネットワークから動的に受け入れることができないのである。ネットワーキング・プロトコルなどのデータ中心モデルは、コードの移動に依存することを避けているが、このようなプロトコルは簡単に分散コンピューティングに対応できるほど機能豊富でなく、型安全性などコードやその他のプログラミング機能によるプログラミングを簡単に行うことができない。
【００２１】
従来の分散コンピューティング・システムは、第１のデバイスで実行されるプログラムが第２のデバイスのプログラムをリモート・コールできるということに依存しており、結果は第１のデバイスに返される。リモート・プロシージャ・コール（ＲＰＣ）は、プログラムまたはプロシージャのリモート・コールを行うための基本的メカニズムである。ＣＯＲＢＡとＪｉｎｉは両方とも、プログラム・メソッドをリモートから呼び出す機能に基づいている。ただし、ＪｉｎｉやＣＯＲＢＡなどのコードまたはオブジェクトを渡すことで通信を行うのは幾分複雑になることがある。たとえば、上述のように、ＪｉｎｉではＪａｖａ Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）を使用してサービス間の通信を行う。クライアントがＪａｖａオブジェクトをリモート・位置との間で移動するには、シリアライゼーション／デシリアライゼーションの何らかの手段が必要になる。Ｊａｖａ開発キット（ＪＤＫ）におけるこのような現在の機能は、Ｊａｖａオブジェクトの内容を判別するためにリフレクションＡＰＩに依存しており、最終的にはそのコードが仮想マシンに問い合わせを行う必要がある。このコードはかなり大きく、非効率である。
【００２２】
シリアライゼーション／デシリアライゼーションを行うための現在の方法には、サイズ、速度、およびオブジェクト・トラバーサル・モデルに関する基本的な問題がある。ＪＶＭの外部のコードは、Ｊａｖａオブジェクトの構造またはグラフを認識しないため、オブジェクト・グラフをトラバースし、引き離して、最終的にＪＶＭを呼び出す必要がある。Ｊａｖａオブジェクトの格納および移動を行う従来のシリアライゼーションおよびリフレクション・メカニズムは、すべての種類のデバイス、特により軽量のシン・デバイスについては実用的でない。Ｊａｖａリフレクションおよびシリアライゼーションの問題点として、オブジェクトのグラフ（オブジェクトの推移的閉包（ｔｒａｎｓｉｔｉｖｅ ｃｌｏｓｕｒｅ））リフレクションがＪＶＭの外部で実行することが困難であるという点があげられる。シリアライゼーションは、大量のコードを必要とし、大きすぎる。さらに、シリアライゼーションはＪａｖａ固有のオブジェクト交換形式であり、Ｊａｖａ非対応のデバイスでは使用できない。
【００２３】
Ｊｉｎｉ分散コンピューティング・モデルでは、Ｊａｖａデバイス間でＪａｖａオブジェクトを移動する必要がある。そのため、Ｊａｖａ対応でないプラットフォーム側でオブジェクトの発送および受取に使用することができないためシリアライゼーション・メカニズム自体はプラットフォーム独立ではない。シリアライゼーションは、均質的なオブジェクト形式であり、Ｊａｖａプラットフォームでのみ動作する。シリアライゼーションでは、リフレクションＡＰＩを使用するため、セキュリティ関連の制限を受ける場合があり、しばしば、ネイティブのＪＶＭ依存メソッドを使用して対処する必要がある。リフレクションＡＰＩは、オブジェクトのグラフを提供できるが、ＪＶＭとリフレクション・メソッドを呼び出すコードとの間で何回も呼び出しが行われるため非効率である。
【００２４】
Ｊａｖａリフレクションを使用してオブジェクトをシリアライズするには、オブジェクトの推移的閉包を動的に解析するときに、アプリケーション側がＪＶＭとピンポンのようにやり取りし、一度にフィールド１つずつオブジェクトを取り出す必要がある。Ｊａｖａデシリアライゼーションを使用してオブジェクトをデシリアライズするには、オブジェクトの推移的閉包を動的に解析するときに、アプリケーション側がＪＶＭと緊密に連携し、一度にフィールド１つずつオブジェクトを再構成する必要がある。そのため、Ｊａｖａシリアライゼーション／デシリアライゼーションは時間がかかり、扱いにくく、しかも、アプリケーションとＪＶＭのコードを大量に書く必要があるだけでなく、永続的な記憶領域も必要である。
【００２５】
Ｊａｖａをサポートするシン・クライアントの場合も、Ｊｉｎｉ ＲＭＩは、最小限のメモリ専有面積と最低限の帯域幅を備えるシン・クライアントの場合には実用的でないと思われる。Ｊｉｎｉ ＲＭＩと関連するシリアライゼーションは、実行時間が長く、コード・サイズが大きく、ＪＶＭリフレクションＡＰＩを必要とし、Ｊａｖａ固有オブジェクトの表現である。Ｊａｖａデシリアライゼーションも実行に時間がかかり、コード・サイズが大きく、シリアライズ・オブジェクト・パーサを必要とする。Ｊａｖａベースのシン・クライアントであっても、Ｊｉｎｉ内で要求されたときにクライアントへネットワーク経由で（必ず）返される巨大なＪａｖａオブジェクト（必要なクラスに沿って）を受け入れられない場合がある。さらにスケーラブルな分散コンピューティング・メカニズムが必要である。よりスケーラブルな分散コンピューティング・メカニズムでセキュリティ問題に対処すること、またＪａｖａオブジェクトなどのオブジェクトの受け渡しを可能にし、さらに一方のネットワーク・モードから他方のネットワーク・モードにプロセスを移行できるように、拡張可能であることが望ましい。
【００２６】
オブジェクト・ベースの分散コンピューティング・システムでは永続的記憶領域が必要である。ただし、上述のように、オブジェクト記憶領域での試みは多くの場合言語とオペレーティング・システムに特有のものである。さらに、これらのオブジェクト・ストレージ・システムは、複雑すぎて、多くの小さな組み込み型システムでは使用できない。たとえば、Ｊｉｎｉ技術では、ＪａｖａＳｐａｃｅｓを永続的オブジェクト・コンテナとして使用する。しかし、ＪａｖａＳｐａｃｅは、Ｊａｖａオブジェクトを格納するだけであり、小型デバイスに実装できない。ＪａｖａＳｐａｃｅ内の各オブジェクトは。シリアライズ化され、Ｊａｖａシリアライゼーションと関連する上述のペナルティを払う。小型デバイスから大型デバイスに至るまでの分散コンピューティング用に異機種オブジェクト・リポジトリを備えることが望ましいと考えられる。
【００２７】
Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のＪａｖａＳｐａｃｅｓは、エール大学コンピュータ・サイエンス学部のＤａｖｉｄ Ｇｅｌｅｒｎｔｅｒ教授の並列処理の成果を利用している。Ｇｅｌｅｒｎｔｅｒ教授の「Ｌｉｎｄａ」という名前の機能セットでは、ＴｕｐｌｅＳｐａｃｅと呼ばれる共有メモリ空間を作成し、コンピュータのプロセスの結果またはそれらのプロセス自体を格納し、複数のＣＰＵでアクセスできるようにする。Ｌｉｎｄａは、したがって複数のプロセッサ用にグローバルな共有メモリを備える。
【００２８】
Ｌｉｎｄａを拡張するもう１つの技術がＩＢＭ ＣｏｒｐｏｒａｔｉｏｎのＴＳｐａｃｅである。ＴＳｐａｃｅは、基本的なＬｉｎｄａ ＴｕｐｌｅＳｐａｃｅフレームワークを拡張し、実データ管理を行い、新しいデータ型および新しいセマンティック機能をダウンロードできるようにしている。ＴＳｐａｃｅは、一組のネットワーク通信バッファとこれらのバッファにアクセスするための一組のＡＰＩを備えている。したがって、上述の多くのソリューションのように、ＴＳｐａｃｅはコード中心プログラミング・モデルを使用しており、そのようなモデルの欠点も共有している。さらに、ＴＳｐａｃｅは、Ｊａｖａプログラミング言語で実装されているため、Ｊａｖａ仮想マシンやＪａｖａバイトコードを実行する、Ｊａｖａ実行可能マイクロプロセッサなどの他の手段を必要とする。したがって、ＴＳｐａｃｅは、十分なリソースをＪａｖａバイトコードの実行専用に割り当てることができない省スペース・デバイスには不適切と思われる。
【００２９】
オブジェクト指向分散システムでは、オブジェクト・リポジトリを特定し、それらのリポジトリ内で特定のオブジェクトを見つけることができることが望ましい。供述のように、Ｊｉｎｉルックアップ・サーバはメモリ専有面積の小さな小型デバイスには実用的でないと思われる。オブジェクト・ストアを特定するより効率的なメカニズムがあることが望ましい。
【００３０】
分散ネットワーク・コンピューティング・モデルでは、クライアントがサービスを特定する機能を備えることが望ましい。現在のネットワーク・プロトコルは、ネットワーク・サービスにアクセスするときにセキュリティを一切持たない単一の標準サービス・アクセス・インターフェースのみを提供するか、または管理者もしくは特権のある機能も含めて、サービスの全機能に対する「オール・オア・ナッシング」アクセス機能を提供する。また、サービスを特定する現在のネットワーク・プロトコルでは、サービスを見つける柔軟なメカニズムを提供していない。現在のプロトコルは、選択的サーチ機能をまったく備えていないか（たとえば、ＵＰｎＰ）、またはプリミティブ・キーワードおよび属性文法メカニズムのみを備える（たとえば、ＳＬＰ）。そのため、現在のサービス発見メカニズム（ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ ｍｅｃｈａｎｉｓｍ）はセキュリティおよびサーチ基準メカニズム（ｓｅａｒｃｈ ｃｒｉｔｅｒｉａ ｍｅｃｈａｎｉｓｍ）に関してあまりにも柔軟性が不足していると考えられる。
【００３１】
さらに、現在のサービス発見モデルは、サービスを特定するために対称モデルを使用している。ただし、近さに基づく機能を使用できるデバイスなどある種のサービス・デバイスが発見モデルをサポートするのはリソースの無駄と考えられる。これは、このようなデバイスが近いところにあるためすでに特定されているためである（たとえば、他方のデバイスを物理的にポイントしている一方のデバイス）。そのため、代替えとなる軽量発見メカニズムもこのようなデバイスに対して望ましいと考えられる。
【００３２】
分散オブジェクト・アクセスにも、偏りのない効率のよい共有メカニズムを必要とする。上述のように、Ｊｉｎｉは今のところ、リース・メカニズムを使用してオブジェクトを共有している。ただし、Ｊｉｎｉのリースは時間に基づいているため、さまざまな問題が発生しうる。たとえば、現在のオブジェクト・ホルダは、オブジェクトをどれだけの期間リースするかという考え方がなく、保持期間が長くなりすぎる場合がある。さらに、時間に基づくリースを使用するには、複数のマシンの間で時間が同期している必要がある。さらに、時間に基づくリースには、オペレーティング・システムのサポートも必要と考えられる。さらに、Ｊｉｎｉのリースは、ＲＭＩ経由で確立され、解放される。そのため、Ｊｉｎｉのリース・メカニズムには、ＲＭＩを使用する上述の問題が発生する。さらに、Ｊｉｎｉのリース・メカニズムは、リースの確立、更新、および取り消しのためのセキュリティ・メカニズムを備えていない。他のリース・メカニズムも望ましいと考えられる。
【００３３】
一般的に、メモリ専有面積の小さなモバイル・クライアント・デバイスは分散環境でさまざまなサービス、つまりレガシサービスと新サービスの両方を実行できることが望ましい。小型クライアントとしては、携帯電話およびＰＤＡがあり、通常は低帯域幅のさまざまなネットワーキング・インターフェースを備える。これらのデバイスは多くの場合、グラフィック機能が限られた非常に小さなディスプレイを備えているが、大画面のディスプレイを備え、グラフィック機能も高度なものを使用するラップトップやノートブック・コンピュータもある。サービスは、さまざまなアプリケーションだけでなくプリンタなどのデバイス用の制御プログラムもある。モバイル・クライアントは、使用できる場所であればどこでもこれらのサービスを使用できることが望ましい。
【００３４】
モバイル・クライアントは、多くの場合、一時的な動的ネットワーク・アドレスが割り当てられ、このクライアントが送るネットワーキング・メッセージはそのネットワーキング・インターフェースを超えて配信することはできない（そうでないと、異なるネットワーク上の２つの異なるクライアントが同じ動的アドレスを持つときに競合が発生することがある）。モバイル・クライアントは、多くの場合、全機能搭載のブラウザやその他の高度なソフトアウェア用の機能を持たない。ディスプレイが制限となって、クライアントが一部のアプリケーションを実行できない場合もある。従来のアプリケーション・モデルは、所定のユーザ・インターフェースまたはデータ特性に基づいている。アプリケーションに変更を加えると再コンパイルが必要になる。
【００３５】
このようなクライアントは分散アプリケーションまたはサービスを見つけて呼び出すメカニズムを備えることが望ましい場合がある。クライアントは、クライアントのメモリ専有面積に収まり切らない可能性のある一層大きなレガシ・アプリケーションを実行する必要がある場合もある。上述のように、Ｊｉｎｉなどの現在の技術は、省スペース・デバイスには実用的でない場合がある。また、モバイル・シン・クライアントが普及することでさらにニーズも高まる可能性がある。たとえば、ユーザとそのユーザのモバイル・クライアントの物理的な場所に基づいてサービスを特定することが望ましい場合がある。たとえば、現地のレストラン、天候、道路交通現況図、および映画情報など現地周辺のサービスに関する情報が非常に役立つことがある。それと同様に、特定の場所にあるプリンタなど計算リソースに関する情報が役立つ。現行技術では、クライアントの物理的場所に基づいてサービスを特定する自動的なメカニズムを備えていない。シン・モバイル・クライアントによって生じるニーズとしては、他に、人的要因を取り扱うものがある。シン・モバイル・クライアントは、通常、エルゴノミック・キーボードおよびモニタを備えない。このような人的要因サービスを提供することおよび／または分散コンピューティング環境でこのようなサービスを特定する機能があると望ましい。分散コンピューティング・モデルは、クライアントは一時的ドキュメントおよびサービスを見つける手段を備える必要がある。ドキュメントが拡張マークアップ言語（ＸＭＬ）によって提供されるものなどプラットフォーム独立および言語独立の型で表される汎用ドキュメント（サービスおよび／またはサービス通知を含む）を見つけるメカニズムを備えることが望ましい場合がある。Ｊｉｎｉ、Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ（ＵＰｎＰ）、およびＳｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＬＰ）のルックアップ・メカニズムを含む現在のアプローチでは、このような汎用ドキュメントルックアップ・メカニズムをサポートしていない。たとえば、Ｊｉｎｉルックアップ・メカニズムは、Ｊａｖａ言語型付けに限定されており、したがって、言語独立ではない。ＵＰｎＰおよびＳＬＰは、サービスのみについて発見プロトコルをサポートしており、汎用ドキュメントについては発見プロトコルをサポートしていない。
【００３６】
（発明の要旨）
上で概要を示した問題は、主に、分散コンピューティング環境内でサービスを通知し、アドレッシングし、かつ／またはアクセスするシステムおよび方法のさまざまな実施態様によって解決される。分散コンピューティング環境は、「スペース」またはオブジェクト・リポジトリに頼って、クライアントとサービスの間の相互作用のためのランデブー機構または触媒を提供することができる。サービスプロバイダは、スペース内のサービスを通知することができる。クライアントは、スペース内の通知を見つけ、通知からの情報を使用して、分散コンピューティング環境のＸＭＬ（拡張マークアップ言語）メッセージング機構を使用してサービスにアクセスすることができる。サービスまたはコンテンツを記述するＸＭＬ通知がそれぞれに含まれる、多数のスペースが存在することができる。したがって、スペースは、結果などの生データまたはデータに関する通知とすることができる、サービスのＸＭＬ通知および／またはＸＭＬデータのリポジトリとすることができる。
【００３７】
一実施態様では、スペース自体がサービスである。他のサービスと同様に、スペースは通知を有する。この通知は、スペースのクライアントが、スペース・サービスを実行できるようになるために最初に得なければならない。スペース自体の通知には、ＸＭＬスキーマ、１つまたは複数の証明書、およびスペースにアクセスする方法を示すＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を含めることができる。クライアントは、スペースにアクセスするために、スペース・サービスの通知からゲートを構築することができる。スペースのクライアント自体を、そのスペース内の通知を探すか既存の通知を変更することを求めるサービス・プロバイダとすることができる。あるいは、スペースのクライアントを、スペースによってリストされるサービスまたはコンテンツへのアクセスを求めるアプリケーションとすることができる。したがって、スペースは、分散コンピューティング環境でのクライアントとサービスの間の相互作用の触媒を提供することができる。
【００３８】
スペースに、名前付きの通知の集合を含めることができる。スペースは、スペース自体を記述した単一のルート通知を用いて作成することができる。追加の通知を、スペースに追加することができる。通知の名前によって、名前の階層などの必要なグラフ化情報の指定を含めて、スペース内の通知を特定することができる。好ましい実施態様では、スペースの構造が、分散コンピューティング環境によって指示されない。すなわち、スペースは、たとえば通知のフラットな関連しないセットまたは関連する通知のグラフ（たとえば市販データベース）などとして構成することができる。好ましい実施態様では、分散コンピューティング環境が、スペースが実際にその内容を格納する方法を指定しないので、スペースを、小さいデバイスから大きいデバイスまでによってサポートすることができる。たとえば、単純なスペースを、ＰＤＡなどの小さいデバイスにおさまるように調整することができる。より高度なスペースを、大規模な市販データベースを使用して大型サーバで実施することができる。
【００３９】
上で述べたように、スペースに、分散コンピューティング環境内のサービスに関する通知を含めることができる。通知は、分散コンピューティング環境内のサービスおよび／またはコンテンツのアドレッシングおよびアクセスの機構を提供することができる。通知はサービスのＵＲＩを指定することができる。いくつかの実施態様で、ＵＲＩはサービスをインターネットを介してアクセス可能にすることができる。通知には、サービスに関するＸＭＬスキーマを含めることもできる。ＸＭＬスキーマでは、サービスのクライアントがサービスの機能を呼び出すためにサービスに送ることができるメッセージのセットを指定することができる。ＸＭＬスキーマでは、クライアントとサービスのインターフェースを定義することができる。通知で指定されるＵＲＩとＸＭＬが一緒になって、サービスのアドレッシングとアクセスの方法を示すことができる。ＵＲＩとスキーマの両方を、スペース内の通知としてＸＭＬで提供することができる。したがって、分散コンピューティング環境内のサービスのアドレッシングおよびアクセスの機構を、スペース内の通知としてパブリッシュすることができる。クライアントは、スペースを発見し、その後、サービスまたはコンテンツに関する個々の通知をルックアップすることができる。スペースとあるスペース内のすべての通知を、ＵＲＩを使用してアドレッシングすることができる。一実施態様では、スペース名および通知名を、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）命名規約に従うものとすることができる。いくつかの実施態様で、スペースのアドレッシングに、たとえばＵＲＬなどのＵＲＩを使用することによって、スペースを、インターネット全体を通じてアドレッシング可能にすることができるようになる。
【００４０】
スペースのクライアントがスペース・サービスの通知を見つけた後に、スペースのそのクライアントは、他のサービスと同様に、スペース・サービスを実行することができる。スペース・サービスのクライアントが、別のサービス（たとえば、スペース内の通知を探すサービス）である場合があることに留意されたい。一実施態様では、スペース・サービスを実行するために、スペースのクライアントが、まず、スペースに関する認証サービスを実行して、認証トークンを得ることができる。認証サービスは、スペース・サービスのサービス通知で指定することができる。スペースのクライアントは、認証トークン、スペースのＸＭＬスキーマ（スペースのサービス通知から）、およびスペースのＵＲＩ（スペースのサービス通知から）を使用して、スペース用のゲートを構築する。スペースのクライアントは、その後、ゲートを使用してスペース・サービスにメッセージを送ることによって、スペース・サービスを実行することができる。
【００４１】
認証を使用する実施態様に関して、スペース・サービスが、認証トークンを埋め込まれた最初のメッセージをクライアントから受け取る時に、スペース・サービスは、同一の認証サービス（スペース・サービスのサービス通知で指定される）を使用して、クライアントを認証し、したがって、クライアントの識別を確立する。スペース・サービスは、クライアントの機能を判定し、それらを認証トークンにバインドすることができる。
【００４２】
スペースのクライアントは、スペース・サービスにメッセージを送ることによって、さまざまなスペース機能を実行することができる。一実施態様では、スペースのクライアントは、スペース・サービスに要求を送る時に、その要求で認証トークンを渡し、したがって、スペース・サービスが、クライアントの特定の機能に対して要求を検査することができる。
【００４３】
各スペースは、通常はサービスであり、スペース・サービスのコア機能を定義するＸＭＬスキーマを有することができる。ＸＭＬスキーマによって、スペース・サービスへのクライアント・インターフェースを指定することができる。一実施態様では、すべてのスペース・サービスが、スペース関連メッセージのベースレベルを提供することができる。ベースレベル・スペース機能は、ＰＤＡなどの小さいデバイスを含むほとんどのクライアントが使用できる基本的なスペース機能とすることができる。たとえばより高度なクライアント用など、追加の機能を提供することが望ましいであろう。ベースレベル・スペースに対する拡張は、スペースを通知するＸＭＬスキーマにより多くのメッセージを追加することによって達成することができる。たとえば、一実施態様では、ベースレベル・メッセージが関係グラフを通知に押し付けない。たとえば、通知の階層をトラバースするメッセージをスペース拡張とすることができる。そのような追加の機能の提供は、１つまたは複数の拡張されたＸＭＬスペース・スキーマまたはスペース用のスキーマ拡張を提供することによって行うことができる。拡張されたスキーマに、ベース・スキーマを含めることができ、その結果、拡張されたスペースのクライアントが、今まで通りベース・スペースとしてスペースにアクセスできるようになる。
【００４４】
一実施態様では、スペースが、スペース内で通知されるサービスをクライアントがインスタンス化する機能を提供することができる。サービスのインスタンス化は、クライアントがサービスを実行できるよう行う初期化である。サービスをインスタンス化するために、クライアントは、まず、スペース内でパブリッシュされるサービス通知の１つを選択することができる。クライアントは、スペース内で通知されるさまざまな通知をルックアップするためにスペースによって提供されるルックアップ機能などのさまざまな機能を使用することができる。その後、クライアントは、サービスをインスタンス化することをスペースに要求することができる。
【００４５】
一実施態様では、サービス・インスタンス化に、下記のアクションを含めることができる。クライアントが、選択されたサービスをインスタンス化することをスペース・サービスに要求した後に、スペース・サービスは、要求されたサービスをクライアントがインスタンス化できることを検証する。スペース・サービスは、クライアント・メッセージに含まれる認証トークンを検査することによって、この検証を実行することができる。認証トークンは、クライアントがスペース・サービスとのセッションを確立する時に受け取りた証明書である。スペース・サービスは、クライアントの認証トークンおよびそのクライアントについて示される機能に従って、クライアントが、要求されたサービスをインスタンス化できるかどうかを検証することができる。
【００４６】
クライアントができると仮定すると、スペース・サービスは、クライアントによって指定されるリース要求時間を有する、クライアントに関するサービス通知に対するリースを得ることもできる。スペース・サービスは、その後、割り振られたリースおよびサービスのサービス通知を含むメッセージをクライアントに送ることができる。一実施態様では、クライアントが、サービス通知で指定された認証サービスを実行し、認証トークンを得ることができる。次に、クライアントは、サービス用のゲートを構築することができる（たとえば、認証トークンと、通知からのＸＭＬスキーマおよびサービスＵＲＩを使用して）。上で述べたクライアントとスペース・サービスの間の通信は、分散コンピューティング環境のＸＭＬメッセージングを使用して実行される。クライアントは、その後、構成されたゲートとＸＭＬメッセージングを使用してサービスを実行することができる。サービスは、同様に、クライアントとのＸＭＬメッセージ通信用のサーバ・ゲートを構築することができる。
【００４７】
スペースは、クライアントによって実行されるサービスからの結果を格納する便利な機構を提供することができる。結果用のスペースを使用することによって、小さいクライアントが、サービス実行の結果を切れ切れに受け取ることができるようになる。いくつかのサービスは、大量の結果を生成することがある。サービスからの結果を格納するのにスペースを使用することによって、すべての結果を一度に受け取るリソースを有しないクライアントが、それでもサービスを使用できるようになる。さらに、スペースを使用して結果を格納することによって、高速だが忙しいサーバで動作するサービスが、大量の結果を返す時に、そのサービスを低速のクライアントと直接対話することから解放することできる。したがって、サービスを、他のクライアントによる使用のためにより早期に解放することができる。
【００４８】
スペースは、異なるクライアントによるおよび／または異なる時刻での結果のアクセスの便利な機構を提供することができる。たとえば、あるクライアントが、結果の全体を使用することができないが、ユーザが、後でその結果にアクセスできる別のクライアントを使用して結果の残りにアクセスすることを望む場合がある。たとえば、結果を、現在の株価（ＰＤＡによってアクセス可能）を示し、株価のチャート（後でラップトップ機によってアクセス可能）を示す株式市況情報とすることができる。また、分散コンピューティング環境で結果にスペースを使用することによって、クライアントが、まず結果をダウンロードする必要なしに、あるサービスの結果を別のサービスに供給できるようになる。たとえば、上の株式市況情報の場合に、ＰＤＡが、チャート自体をダウンロードする必要なしに、チャートを印刷する別のサービスにチャートを供給することができる。したがって、結果スペースは、クライアントが結果を処理または受け取るする必要なしに、クライアントが別のクライアントまたはサービスに渡す機構を提供することができる。
【００４９】
一実施態様では、結果にスペースを使用することが、必ずしもそのサービスがすべての結果をそのスペースに置かなければならないことを意味しない。サービスが生成するすべての結果について、異なる代替物を設けることができる。たとえば、結果の一部またはすべてを、メッセージ内で直列にしてクライアントに送ることができる。その代わりに、結果をスペース内に置くことができ、その後、結果を参照する（たとえば、結果のＵＲＩまたは結果に関する通知を含む）通報メッセージをクライアントに送ることができる。もう１つのオプションが、結果をスペースに置き、スペースからのイベントを介する通報を用いることである。たとえば、クライアントおよびサービスが、結果をある特定の名前で呼ぶことに合意し、その後、クライアントが、スペースに登録して（下で説明するものなどのスペース機能を使用して）、そのように命名された結果がスペースに追加される時にイベントを受け取るようにすることができる。イベント通報に関する上の説明を参照されたい。
【００５０】
したがって、サービスがクライアントに結果を返すために、分散コンピューティング環境内でさまざまな異なる機構を使用することができる。実際の結果を、ＸＭＬメッセージ内の値によってクライアントに返すことができ、あるいは、結果を、スペース内に置かれた実際の結果に関する参照（または実際の結果に関する通知）によってクライアントに返すことができ、このクライアントは、スペース内の結果を参照するメッセージを受け取る。さらに、結果または結果通知を、スペースに置き、クライアントにイベントによって通報することができる。
【００５１】
結果を処理するもう１つの機構は、クライアントが、結果を供給されるもう１つのサービスを指定することである。たとえば、クライアントが、結果を作るサービスを実行する時に、クライアントは、そのサービスに（たとえばＸＭＬメッセージングを介して）さらなる処理のためにもう１つのサービスに結果を送るように指示することができる。これには、クライアントが、他方のサービスに関する通知のＵＲＩを示し、その結果、結果を作るサービスが、他方のサービスを実行し、それに結果を渡すために他方のサービスへのゲートを生成できるようにすることを含めることができる。この例では、結果を作るサービスが、他方のサービスのクライアントになることができる。さらなる処理のためのサービスの例が、元のクライアントのために結果を表示することができる表示サービスである。この表示サービスは、クライアントと同一のデバイス上にあるか、それに関連するものとすることができる。
【００５２】
結果スペースは、分散コンピューティング環境が、最小限のメモリ・フットプリントおよび最小限の帯域幅を有するシン・クライアントに実用的である単純なリモート・メソッド呼出しを提供できるようにすることができる。というのは、従来のリモート・メソッド呼出し技法のように、巨大なプログラム・オブジェクト（必要なクラスと共に）を（必ず）ネットワークを介してクライアントに返すという悪い副作用を有する必要がないからである。その代わりに、結果を、結果スペースに返すことができ、望まれる場合に限って（それらがクライアント側に存在することができる場合に）、実際のオブジェクトをクライアントにダウンロードすることができる。
【００５３】
さまざまな実施態様で、結果を、複数の方法で、たとえば、メッセージ内で、スペース内で、クライアントがイベントを介して通報されるスペース内で、メッセージ内で返される通知を使用して、スペース内で返される通知を使用して、およびクライアントがイベントを介して通報されるスペース内で返される通知を使用して、クライアントに返すことができる。この複数の方法の使用可能性によって、異なる機能を有するクライアントに関するものなどのさまざまな情況に関する分散コンピューティング環境の柔軟性および適応性を強化することができる。追加の柔軟性について、結果を別のサービスに効率的に渡すこともできる。
【００５４】
クライアントは、第１のメッセージをサービスに送り、そのサービスの１つまたは複数の関数の呼出しを要求することができる。サービスに関するスキーマで、サービスの関数の呼出しに使用可能である第１のメッセージを含む複数のメッセージを指定することができる。メッセージおよびスキーマは、ＸＭＬなどの、プラットフォーム独立および／またはプログラミング言語独立のデータ表現言語で表現することができる。第１のメッセージに応答して、サービスの関数を呼び出すことができる。その後、サービスが、結果のセットを生成することができる。結果を、データ表現言語（たとえばＸＭＬ）で表現することができる。サービスは、結果のセットをスペース内の位置に格納することができ、この場合に、スペースに、ネットワーク・アドレッシング可能なストレージ位置が含まれる。一実施態様では、結果のセットの格納の準備としてスペースを作成することができる。一実施態様では、イベントを生成し、クライアントに送り、結果がスペースに格納されたことをクライアントに通報する。その後、クライアントは、スペースから結果のセットにアクセスし、読み取ることができる。一実施態様では、第２のクライアント（すなわち、関数を呼び出すメッセージを送りたクライアントと異なるクライアント）が、スペースから結果のセットを読み取ることができる。この形で、第１のクライアントが結果の読取および表示などの作業を達成するのに十分なリソースを有しない可能性がある時に、ユーザが、第２のクライアントを使用して結果を読み取り、表示することができる。
【００５５】
一実施態様では、結果をスペースに格納するのではなく、結果を、メッセージ内でクライアントに送ることができる。このメッセージは、データ表現言語（たとえばＸＭＬ）で表現することができ、一実施態様では、サービスに関するスキーマで指定することができる。
【００５６】
一実施態様では、結果を、結果に関する通知を使用して返すことができる。前に説明したように、クライアントは、第１のメッセージをサービスに送り、サービスの１つまたは複数の機能の呼出しを要求することができる。第１のメッセージに応答して、サービスの機能を呼び出すことができ、サービスが結果のセットを生成することができる。一実施態様では、サービスが、結果のセットをスペース内の位置に格納することができ、スペースに、ネットワーク・アドレッシング可能なストレージ位置が含まれる。サービスは、結果に関する通知を生成することができる。この通知に、スペースからなど、結果にアクセスし、読み取るのに使用可能な情報を含めることができる。たとえば、通知に、結果にアクセスできる場所のＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができる。一実施態様では、通知に、結果のフォーマットを指定するスキーマ（たとえばＸＭＬスキーマ）を含めることができる。一実施態様では、通知を、ＸＭＬなどのデータ表現言語で表現することができる。
【００５７】
一実施態様で、サービスが、通知を含むメッセージをクライアントに送ることができる。このメッセージは、データ表現言語（たとえばＸＭＬ）で表現することができ、一実施態様では、サービスに関するスキーマ内で指定することができる。もう１つの実施態様では、通知を、スペースに格納することができる。スペースは、結果が格納されるスペースと同一または異なるスペースとすることができる。クライアントは、そのスペースから通知を読み取ることができる。一実施態様では、イベントを生成し、クライアントに送り、結果に関する通知がスペースに格納されたことをクライアントに通報することができる。
【００５８】
クライアントは、通知を使用して結果のセットにアクセスし、読み取ることができる。一実施態様では、第２のクライアント（すなわち、関数を呼び出すメッセージを送りたクライアントと異なるクライアント）が、通知を使用して結果を読み取ることができる。
【００５９】
本発明は、さまざまな修正形態および代替形態を許すが、その特定の実施形態を、例として図に示し、以下で詳細に説明する。しかし、図面およびそれに対する詳細な説明が、開示される特定の形態に本発明を制限することを意図されておらず、逆に、その意図が、本発明の趣旨および範囲に含まれるすべての修正形態、同等物、および代替形態を包含することであることを理解されたい。
【００６０】
（発明の実施形態の詳細な説明）
分散コンピューティングの実施形態の概要
図２には、分散コンピューティング環境のプログラミング・モデルが示されている。このモデルには、分散コンピューティングを使いやすくするＡＰＩレイヤ１０２が含まれている。ＡＰＩレイヤ１０２は、クライアントとサービスとの接続を容易にするインターフェースを備えている。ＡＰＩレイヤ１０２は、クライアントおよびサービスの発見（ｄｉｓｃｏｖｅｒｙ）および接続に関係する。ＡＰＩレイヤ１０２は、メッセージ発送およびメッセージ受取機能を備える。このメッセージングＡＰＩは、拡張マークアップ言語（ＸＭＬ）など、表現データまたはメタデータ形式による単純メッセージ用のインターフェースを提供する。実施形態はここではＸＭＬを採用しているものについて説明しているが、他の実施形態では他のメタデータ型言語または形式を使用することもできることに注意されたい。いくつかの実施形態では、ＡＰＩレイヤは、さらに、Ｊａｖａオブジェクトなど、オブジェクト間の通信やオブジェクトの受け渡しのためのメッセージのインターフェースを備えることもできる。オブジェクト・リポジトリまたは「スペース」を発見し、特定のオブジェクトを見つけ、オブジェクトの要求および解放を行い、オブジェクトをオブジェクト・リポジトリに書き込んだり、オブジェクト・リポジトリからオブジェクト取り出したりするＡＰＩが用意される場合もある。ＡＰＩレイヤ１０２を通じてアクセス可能なオブジェクトは、ＸＭＬなどの表現データ形式で表現することができる。そのため、オブジェクト自体とは反対に、オブジェクトのＸＭＬ表現は操作が可能である。
【００６１】
ＡＰＩレイヤ１０２は、メッセージング・レイヤ１０４の上にある。メッセージング・レイヤ１０４は、ＸＭＬなどの表現データ形式に基づいている。一実施形態では、ＸＭＬメッセージは、ＡＰＩレイヤ１０２の呼び出しに従って、メッセージング・レイヤ１０４によって生成される。メッセージング・レイヤ１０４は、クライアントとサービスとの間で送ることができる定義済みの静的メッセージを備えている。メッセージング・レイヤ１０４は、さらに、動的に生成されるメッセージにも対応している。一実施形態では、ＪａｖａオブジェクトなどのオブジェクトをＸＭＬ表現に動的に変換することができる。メッセージング・レイヤ１０４により、ＸＭＬオブジェクト表現はメッセージとして送ることができる。逆に、メッセージング・レイヤ１０４は、オブジェクトのＸＭＬ表現を受け取ることができる。その後、そのメッセージからオブジェクトは再構成できる。一実施形態では、メッセージング・レイヤ１０４によって送られるメッセージは、アドレス、認証証明書、セキュリティ・トークン、およびメッセージ本体など、複数の基本要素を含むことができる。メッセージ・システムの発送および受取メカニズムは、完全に状態を保持しないようにできる。状態という概念を、発送側と受取側との間のメッセージ・ストリームに埋め込むことができる。そのため、メッセージ発送は非同期に行われる。好ましい実施形態では、接続モデルは課されていない。したがって、ＴＣＰなどのトランスポートは不要である。また、エラー条件は不達またはセキュリティ例外に限られる。
【００６２】
メッセージング・レイヤ１０４は、メッセージ対応ネットワーキング・レイヤ１０６の上にある。好ましい実施形態では、メッセージング・レイヤ１０４は、特定のネットワーキング・プロトコルを使用する必要がない。ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰは、メッセージ対応ネットワーキング・レイヤ１０６に使用できるメッセージ対応プロトコルの例である。ただし、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）などの他の専用プロトコルも使用できる。他にも、トランスポート・レイヤの下のＩｒＤＡやＢｌｕｅｔｏｏｔｈネットワーク・ドライバのメッセージ・プロトコルも考えられる。ネットワーキング・レイヤ１０６は、ＴＣＰ／ＩＰなどの単一の信頼できる接続プロトコルに限られない。したがって、さまざまなデバイスとの接続が可能である。
【００６３】
一実施形態では、メッセージ対応ネットワーク・レイヤ１０６は、Ｊａｖａ２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）プラットフォームが提供するネットワーキング・クラスから実装することができる。Ｊａｖａ２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎプラットフォームは、完全なＪａｖａプラットフォーム用のリソースを持たないまたは完全なＪａｖａプラットフォームを実行するのは効率的でない省スペース・デバイスに適している。Ｊ２ＭＥがすでにネットワーキング・プロトコルのメッセージ対応ファミリ（ソケットをサポートする）を備えているため、メッセージング・レイヤ１０４を追加した場合の省スペース・コストについて、分散コンピューティング機能をすでにＪ２ＭＥを含んでいる小型デバイス用に提供することができる。
【００６４】
メッセージ対応ネットワーキング・レイヤ１０６はさらに、Ｊａｖａ開発キット（ＪＤＫ）のｊａｖａ．ｎｅｔネットワーキング・クラスでも用意できる。それとは別に、メッセージ対応ネットワーキング機能をメッセージ対応ネットワーキング・レイヤ１０６に使用することもできる。好ましい実施形態では、信頼できるトランスポートは不要であり、したがって、ＵＤＰ／ＩＰなどの信頼できないデータグラム・トランスポートをサポートする組み込み型デバイスもまたメッセージング・レイヤをサポートできる。したがって、シン・クライアントは、単にシン・メッセージング・レイヤ１０４を基本ネットワーキング・プロトコル・スタックの上に追加するだけで分散コンピューティング環境に参加することができる。図３に示されているように、基本システムはネットワーキング・レイヤ１０６の上にメッセージング・レイヤ１０４を備える。ネットワーキング・レイヤは、信頼できるメッセージ、たとえばＴＣＰ、または信頼できないメッセージ、たとえばＵＤＰに対応できる。インターネット・プロトコル（ＩＰ）は、図３に、ネットワーキング・レイヤ１０６で使用できるプロトコルの例として示されている。ただし、分散コンピューティング環境ではＩＰを必要としない。分散コンピューティング環境では、ＩＰに加えて、他のプロトコルも使用できる。Ｅｔｈｅｒｎｅｔ（登録商標）、Ｔｏｋｅｎ Ｒｉｎｇ、Ｂｌｕｅｔｏｏｔｈなどのネットワーク・ドライバも、ネットワーキング・レイヤの一部とすることができる。多くの小さなクライアントがすでに、ＵＤＰ／ＩＰなどのネットワーク・ドライバおよびトランスポート・プロトコルを備えている。そこで、シンＸＭＬベースのメッセージング・レイヤを追加する際に、デバイスは分散コンピューティング環境に参加できる。
【００６５】
そこで、分散コンピューティング環境の基礎は、信頼できる接続および／または信頼できないデータグラムの上に実装された単純なメッセージ通信レイヤである。このメッセージング技術は、Ｊａｖａリモート・メソッド呼び出し（ＲＭＩ）を採用するＪｉｎｉなどの他の分散コンピューティング・システムで採用されている通信技術とはかなり異なる。メッセージ通信レイヤ１０４は、ＲＭＩで記述される状態を保持する同期スタイルではなく、状態を保持しない非同期スタイルの分散プログラミングをサポートしている。さらに、メッセージ通信レイヤ１０４は、ＸＭＬなどのデータ表現言語に基づいており、そのため、ＲＭＩと異なり、コピー元からコピー先へデータをコピーするが、コードはコピーしない。Ｊａｖａコードはメッセージの発送側または受取側に想定されていないため、ＸＭＬなどの表現データ言語を使用することにより、メッセージング・レイヤ１０４は非Ｊａｖａおよび非Ｊｉｎｉプラットフォームとの相互運用性をシームレスに実現できる。さらに、ＲＭＩとは異なり、メッセージング・レイヤ１０４は、ＴＣＰ／ＩＰなどの信頼できるトランスポート・メカニズムを必要としない。
【００６６】
メッセージ通信レイヤは、たとえば、バイトの配列またはバイト列として指定されたメッセージを送るために単純なｓｅｎｄ（）およびｒｅｃｅｉｖｅ（）メソッドを提供することができる。ｓｅｎｄ（）メソッドは即座に戻り、データ転送を非同期に実行することができる。フロー制御のため、ｓｅｎｄ（）メソッドがｓｅｎｄ（）リクエストを処理できないことを示す例外をスローした場合に呼び出されるコールバック・メソッドを提供できる。ｒｅｃｅｉｖｅ（）メソッドは同期メソッドで、次に使用可能なメッセージを返す。
【００６７】
このメッセージ通信レイヤは、さらに、「スペース」内にオブジェクト、サービス、およびコンテンツのＸＭＬ表現を格納するメソッドを備えることもできる。スペースは、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を使用してネットワーク上で名前が指定されアクセスされる。ＵＲＩは、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）またはＵＲＬの簡易版でもよい。いくつかの実施形態では、ＵＲＬクラスは大きすぎる場合がある。このような実施形態では、より単純なリソース・ロケータを使用し、クライアントとサーバとの間のメッセージの移動に使用するプロトコル、プロトコル依存ホストＩＤ、プロトコル依存ポートＩＤ、スペース名を指定する。
【００６８】
メッセージング・レイヤで提供しているｗｒｉｔｅ（）メソッドを使用してオブジェクトのＸＭＬ表現をスペースに追加することができる。一実施形態では、クライアント指定名とオブジェクトをパラメータとして与えることができる。一実施形態では、ｗｒｉｔｅメソッドは、オブジェクトをそのＸＭＬ表現に変換する。オブジェクトを返し、スペースから削除するためにｔａｋｅ（）メソッドを用意することができる。スペース内のＸＭＬ表現から指定されたオブジェクト返すためにｆｉｎｄ（）メソッドを用意することができる。ｆｉｎｄ（）メソッドもまた、クラスが与えられた場合にスペース内のマッチするオブジェクトの配列を返すのに使用できる。これらのスペース・メソッドはそれぞれ、メッセージ通信レイヤを使用して実装される。リース・メカニズムも、後述のように提供することができる。
【００６９】
発見サービスを、特定のスペースを見つけるためにクライアントが使用できる一般的なサーチ機能としてクライアントに提供することができる。シン・クライアントが実装することができないと思われる複雑なサーチ・プロトコルを定義しようとするのではなく、発見サービスが実際のサーチをＸＭＬベースのサーチ機能にオフロードし、発見サービスがインターフェース機能をクライアントに簡単に提供できるようにする。このアプローチは図４に示されている。一実施形態では、発見サービスは特定するものを指定するストリングを受け取り、ＸＭＬメッセージを既知の発見フロント・エンド（たぶん、デフォルトのスペースで見つかる）に送り、その後、ストリングを解析し、サーチ機能に対し対応するＸＭＬクエリを実行する（これは、インターネットサーチ機能でもよい）。発見フロント・エンドは、サーチ機能から受け取ったものを解析し、ストリングの配列（各ストリングは見つかったそれぞれのスペースのＵＲＩ）としてそれを再パッケージし、ＸＭＬメッセージでクライアントに送ることができる。発見サービスでは、メッセージングが接続指向トランスポートの上にあることを要求していないことに注意されたい。したがって、ＴＣＰを持たない非常に軽量のシン・クライアントであってもこのような発見サービスを使用できる。発見フロント・エンドでは、クライアントがクライアント上にブラウザまたはサーチ機能なしでスペースを発見することが可能である。クライアントは、キーワードを指定するストリングを、サーチ機能とインターフェースするフロント・エンドに送る単純な機能だけあればよい。
【００７０】
クライアントは、少なくともＡＰＩとメッセージング・レイヤのサブセットを使用してメッセージを送ることができるプラットフォームであれば何でもよい。一実施形態では、ＡＰＩレイヤは、静的（またはｒａｗ）および書式付き（またはｃｏｏｋｅｄ）メッセージの両方に対応できる。サーバは、メッセージ要求を受け取り、遂行できるプラットフォームであれば何でもよい。クライアントからサーバへ、または他のクライアントへバイト列を移動する明示的ｒａｗメッセージを送ることができる。メッセージ・タイプは、信頼できるメッセージ（たとえばＴＣＰ）、または信頼できないメッセージ（たとえばＵＤＰ）として指定できる。デバイスのうち最も小さいものは、ｒａｗの信頼できないメッセージ通信を、分散コンピューティング環境に参加する単独の手段として使用する。デバイスは、これらのメッセージを使用してその存在と状況をアナウンスする。このような小さなデバイスは、さらに、ｒａｗメッセージを受け取りて、機能のオン／オフなどのいくつかの機能を実行できる。
【００７１】
スペースなどのメッセージベースのサービスでは、信頼できる書式付きメッセージを送受取できる。スペース・メッセージは、きちんと定義されたヘッダーを備える形式とし、ＸＭＬを使用する。一実施形態では、書式付きメッセージは、クライアントがスペース・メソッドを使用して、スペースにオブジェクトを要求したり、スペースにオブジェクトを書き込んだり、スペースからオブジェクトを取り出したりする。メッセージ・コンテンツは、動的にＸＭＬ形式にすることができ、きちんと定義されたヘッダを備える。図５は、書式付きの静的メッセージをサポートするクライアント・プロファイルを示している。静的メッセージを使用することにより、小さなデバイスはコードのさらに小さなプロファイルを使用して、分散コンピューティング環境に参加することができる。たとえば、小さなデバイスは基本的なあらかじめ定められたメッセージだけを送ることができる。クライアントにもよるが、静的なあらかじめ定義されたメッセージが占有するメモリは少ないと考えられる（たとえば、２００バイト未満）。静的メッセージは、さらに、大きなデバイスにあってはオプションとしてもよい。他方、動的ＸＭＬメッセージは、オブジェクト値がコンパイル時にわかっていないときに役立つ。
【００７２】
図６には、メッセージング・システムとＸＭＬメッセージおよびＸＭＬオブジェクト表現とを組み合わせた分散コンピューティング・モデルが示されている。プラットフォームがＸＭＬから独立していることを利用すると、システムを異機種分散コンピューティング環境に対応させることができる。したがって、クライアント１１０は、Ｊａｖａなどの特定のプラットフォームではなくほとんどどのようなプラットフォームにでも実装することができる。メッセージング・システムは、インターネット・プロトコル（たとえば、ＴＣＰ／ＩＰやＵＤＰ／ＩＰ）などのネットワーク対応メッセージング・レイヤに実装することができる。そのため、コンピューティング環境をインターネットに分散させることができる。一実施形態では、メッセージング・システムはさらに、クライアントおよび／またはスペース・サーバおよび／またはサービスが同じコンピュータ・システムにあるときに、共有メモリを高速なプロセス間メッセージ・パッシング・メカニズムとして使用することもできる。図６の分散コンピューティング・モデルは、さらに、ほとんどどのような規模のクライアントであってもＸＭＬメッセージの発送および／または受取を行えるように設定できるため、非常にスケーラブルである。
【００７３】
図６に示されているように、分散コンピューティング・モデルで、サービス１１２およびクライアント１１０の２種類のソフトウェア・プログラムを実行することができる。サービス１１２は、サービスの使用を望んでいるクライアントに機能を通知することができる。サービス１１２は、スペース１１４で機能を通知する。図７に示されているように、クライアント１１０およびサービス１１２は同じネットワーク・デバイス内に常駐することもまた常駐しないこともある。たとえば、デバイス１２０および１２４はそれぞれ、１つのクライアントをサポートするが、サービス１１２ａおよびクライアント１１０ｂは同じデバイス１２２内に実装される。また、図７に示されているように、デバイスがクライアントとサービスをサポートするのに特定のプラットフォームを必要としない。たとえば、デバイス１２０は、Ｊａｖａベースとし、デバイス１２４はネイティブ・コードのランタイム環境を備える。
【００７４】
デバイスは、ネットワーキング・トランスポートでアドレス指定可能なユニットである。デバイスの例としては、それらに限定はされないが、ＰＤＡ、携帯電話、ノートパソコン、ラップトップ、デスクトップ・コンピュータ、より強力なコンピュータ・システム、さらにはスーパー・コンピュータもある。クライアントとサービスは両方とも、デバイスで実行されるソフトウェア（またはファームウェア）のＵＲＩアドレス指定可能なインスタンスとすることができる。クライアントは、分散コンピューティング環境アーキテクチャを使用してサービスを実行する。スペースとは、ＸＭＬドキュメントのリポジトリを管理するサービスである。これが冗長であっても、読みやすさのために、ここではスペース・サービスという用語を使用する。ソフトウェア・コンポーネントは、別々の時にクライアントでかつサービスであってもよい。たとえば、サービスがスペースを使用するときに（たとえば、自分を通知するために）、そのサービスはスペースのクライアントとなる。
【００７５】
図８は、一実施形態における分散コンピューティング環境の基本モデルを示している。この分散コンピューティング環境は、ネットワーク全体を通してクライアント１１０をサービス１１２に接続する。ネットワークは、インターネットなどのワイド・エリア・ネットワークでよい。また、ネットワークは、インターネットで無線ネットワークに接続されたローカル・エリア・ネットワーク（ＬＡＮ）などのネットワークの組み合わせとすることもできる。図８に示されているように、サービス１１２は、スペース１１４内で自分自身に対し通知１３２をパブリッシュする（ＸＭＬで表される）。通知１３２で、サービスのＸＭＬスキーマとＵＲＩアドレスを指定する。その後、クライアント１１０は、通知１３２をルックアップする。クライアント１１０は、通知１３２を使用して、ゲート１３０をインスタンス化する。ゲート１３０により、クライアント１１０はサービス１１２を実行するが、その際に、ＸＭＬメッセージをサービス１１２に（から）発送（し、そして受取）する。
【００７６】
サービスを実行した結果は一部、ＸＭＬメッセージでクライアントに返すことができる。ただし、小さなクライアントでは他の結果が大きすぎ一度に受け取りて消費することができないため、サービス１１２は、図９に示されているように、それらの結果または結果１３４のＸＭＬ表現をスペース１１４に入れ、値で返すのではなく、（ＸＭＬメッセージによる）参照でクライアント１１０に返す。結果への参照を返す方法の例として、それらに限定されないがスペース内の結果を参照しているＵＲＩをメッセージで返す方法や、結果のＵＲＩを含むＸＭＬドキュメントをメッセージで返す方法がある。後で、クライアント１１０は、結果にアクセスするか、または結果を参照で他のサービスに受け渡すことができる。結果を格納するスペースはサービスが通知されるスペースと異なっていてもよい。
【００７７】
一実施形態では、分散コンピューティング環境はコンテンツの定義、通知、および記述にＸＭＬを使用する。分散コンピューティング環境の新しいコンテンツ（たとえば、メッセージおよび通知）はＸＭＬで定義される。既存のコンテンツ・タイプ（たとえば、他の環境用に開発されたもの）も、ＸＭＬを使用して、あるレベルの間接化（メタデータ）として記述することができる。ＸＭＬは、Ｊａｖａがユニバーサル・コードを提供するのと似た方法で、ユニバーサル・データを提供するため、分散システム全体を通じてデータを表現する強力な手段となっている。ＸＭＬは、言語にとらわれない手段であり、自己記述的である。ＸＭＬコンテンツは、強い型付けで、スキーマを使用して妥当性を確認できる。システムは、用意されたＸＭＬスキーマを使用する際に、有効なＸＭＬコンテンツのみがメッセージで確実に渡されるようにできる。ＸＭＬコンテンツはさらに、ＨＴＭＬやＷＭＬなどの他のコンテンツ・タイプに変換することもできる。したがって、ＸＭＬを認識しないクライアントでも、そのまま、分散コンピューティング環境のサービスを使用できる。
【００７８】
一実施形態では、分散コンピューティング環境のメッセージで、クライアントをサービスと接続し、スペースおよびストア内のコンテンツを取り扱うために使用されるプロトコルを定義することができる。メッセージを使用してプロトコルを定義すると、さまざまな種類のデバイスをプロトコルに参加させることができる。各デバイスは、その能力と役割に最適の方法でプロトコルを自由に実装することができる。たとえば、すべてのデバイスがＪａｖａランタイム環境をサポートできるわけではない。分散コンピューティング環境のプロトコル定義では、デバイスでＪａｖａを使用する必要もなければ使用することを暗示してもいない。また除外することもない。
【００７９】
サービスの機能は、そのサービスが受け入れるメッセージに関して表すことができる。サービスのメッセージ・セットは、ＸＭＬスキーマを使用して定義することができる。ＸＭＬメッセージ・スキーマにより、ＸＭＬ型付きタグを使用して各メッセージ形式を定義する。タグの使用規則もまた、スキーマで定義できる。メッセージ・スキーマは、メッセージを受け取るために使用するサービスのメッセージ・エンドポイントとともにＸＭＬ通知の一コンポーネントであってよい。分散コンピューティング環境では、クライアントがサービスの機能のすべてのサブセットまたは一部のサブセットを使用することができる。クライアントに与えられた機能セットを強制するためにセキュリティ・ポリシーを採用する。たとえば、一組の機能をクライアントに与えた後、クライアントは適切な承認がないとそのセットを変更することはできない。この機能定義のモデルにより、基本機能セットから拡張機能セットまでのサービス・レベルに対応できる。認識されたメッセージの数に加えることにより、拡張機能をサービスに追加することができる。
【００８０】
一実施形態では、分散コンピューティング環境内のすべてのオペレーションは、クライアントとサービスとの間で送られるＸＭＬメッセージとして実現される。ストレージ（一時的記憶と継続的記憶の両方）プロバイダは、クライアントとサービスがコンテンツを格納し、通知し、アドレス指定できるようにするサービスの例である。クライアントおよびサービスは、一時的ストレージ・スペースを使用して互いを見つけまたブローカ・コンテンツを見つけることができる。サービスは、コンテンツまたはサービス通知をスペース内に配置する。通知を使って、コンテンツ・タイプまたはサービスの機能を記述することができる。クライアントは、その後、スペースをブラウズして、目的の機能セットとマッチする通知を探す。クライアントがマッチする通知を見つけると、通信チャネルを確立し、その通知を裏付けるサービスとの間で双方向メッセージ通信を行えるようにする。一実施形態では、通信チャネルは認証される。サービスのオペレーションの結果（もう１つのコンテンツ・タイプにすぎない）は、応答メッセージでクライアントに直接返され、スペース内で通知され格納されるか、またはスペース内で通知されるが永続的に格納される。格納されている結果は、ＵＲＩ（たとえば、応答メッセージで返される）を使用して取り扱われ、関連する認証証明書が割り当てられる。
【００８１】
メッセージ・ゲート
上述のように、分散コンピューティング環境では、ＸＭＬなどのデータ記述言語を使用する。ＸＭＬを使用してターゲット・エンティティ（たとえば、ドキュメント、サービス、またはクライアント）を記述し、そのエンティティにアクセスするためのコードを生成することができる。ターゲット・エンティティにアクセスするため生成されるコードは、メッセージ・ゲートと呼ばれる。したがって、一実施形態では、この分散コンピューティング環境は、他のオブジェクトにアクセスするために必要なオブジェクト間の必要なコードを受け渡す代わりに、この分散コンピューティング環境ではオブジェクトまたはターゲットＸＭＬ記述にアクセスできるようにしてターゲットにアクセスするためＸＭＬ記述に基づいてコードを生成するという点で、他の分散コンピューティング環境とは異なる。分散コンピューティング環境では、ＸＭＬスキーマを使用して、言語固有のＡＰＩに依存することなくＸＭＬスキーマだけで型安全性とともにプログラミング・モデル（たとえば、サポートされているメッセージ）を確実なものにすることができる。ＸＭＬスキーマから生成されたコードはさらに、ローカル・プラットフォームの言語、セキュリティ、型安全性、および実行環境の特性を組み込むこともできる。したがって、ローカル・プラットフォームでは、バグが入り込まないように、またスキーマに従って有効なデータのみが生成されるように、生成されるコードを制御する。生成されるコードは、クライアントのコード実行環境（たとえば、Ｊａｖａ、Ｃ＋＋、Ｓｍａｌｌｔａｌｋ）だけでなく、その管理およびセキュリティ・フレームワーク（Ｗｅｂサーバおよび／またはオペレーティング・システム）に適合する。
【００８２】
分散コンピューティング環境では、ＸＭＬスキーマから生成されるコードが実行時に「オンザフライで」生成されることを要求していないことに注意されたい。その代わりに、コードの一部または全部をサービスのカテゴリ（またはクラス）に合わせて事前に生成し、その後、プラットフォームのビルド・プロセスでリンクする。コードの事前生成は、いくつかのＸＭＬスキーマがすでに知られている組み込みデバイスなどのある種のクライアントに対し有用である。一実施形態では、コードの一部または全部が実際に、全く生成されなくてもよい。一実施形態では、プライベート・コード・ロード方式（クライアント内の）を使用して生成プロセスを補強することができる。さらに、いくつかの実施形態では、分散コンピューティング環境でサービスにアクセスする際に追加機能のコードをダウンロードするためのインターフェースを指定することができる（たとえば、後述のメッセージ・コンダクタを参照）。通常、ダウンロードされるこのようなコードは小さく、クライアントにはコードをダウンロードするかしないかのオプションが用意される。
【００８３】
「生成されるコード」というフレーズは、クライアント・コード実行環境の制御のもとでクライアント内で起動されるコードまたは別のところで（サービス・システムまたはスペース・サービス・システム上で）生成され、生成後クライアント・システムにダウンロードできるコードを指す。ただし、バインド時は実行時となる。実行時に、生成されたコードは、サービス・アドレス（ＵＲＩ）にバインドされ、メッセージがそのサービスのインスタンスに送られる。
【００８４】
上述のように、分散コンピューティング環境のサービスとのインターフェースをＸＭＬスキーマで指定し、クライアントがそのサービスに送る（そしてそのサービスから受け取る）メッセージの集まりを定義することができる。図１０に示されているように、クライアント１１０およびサービス１１２は、それぞれ、メッセージ・ゲート１３０を構築し、指定されたＸＭＬスキーマに従って通信する。サービス１１２について通知されたＸＭＬスキーマ（および場合によってはサービス通知の他の情報）から、クライアント１１０ａまたは１１０ｂがそれぞれメッセージ・ゲート１３０ａまたは１３０ｂを構築できる。同じＸＭＬスキーマから生成される対応するメッセージ・ゲート１３０ｃも、サービス１１２ａ上に存在する。ゲート１３０は、型安全なＸＭＬメッセージの発送および／または受取を行え、またメッセージの発送および／または受取のときにＸＭＬメッセージの型の正しさを検証できるメッセージ・エンドポイントである。メッセージ・ゲートはさらに、メッセージ・エンドポイントがセキュリティで保護されていることを確認する認証および／またはその他のセキュリティ・メカニズムにも対応する。一実施形態では、メッセージ・ゲートは常にセキュリティで保護されている。
【００８５】
上記の分散コンピューティング環境のメッセージング・レイヤをゲートに結合するか、またはゲートの一部とすることができる。メッセージング・レイヤは、非同期にネットワーキング・トランスポートを使用し、バイトの順序列を発送側から受取側へ送り、発送側と受取側の両方でこのバイト列が１つのアトミック・ユニット、つまりメッセージであるという概念を維持する。分散コンピューティング環境では、ネットワーキング・トランスポートがＩＰベースであるという仮定を置かない。その代わりに、メッセージング・レイヤは、デバイスによってどのようなネットワーキング・トランスポート・レイヤがサポートされていようと一番上に置かれる。
【００８６】
メッセージ・ゲートは、クライアントとサービスとの間でＸＭＬメッセージを送り受け取るメカニズムを備えることができる。ＸＭＬメッセージは、「型付けする」ことができる。たとえば、メッセージに、メッセージ・データ・フィールドが、たとえば整数、浮動小数点、テキスト・データなどであるかどうかを示すタグを入れることができる。メッセージ・ゲートは、発送または受け取ったメッセージの型の正しさを検証するように構築することができる。メッセージ・ゲートはさらに、受け取ったメッセージの発送側を認証（たとえば、セキュリティ保護機能を使用して識別）することもできる。サービスによって受け入れられるかつ／またはサービスによって送られるメッセージ・セットを記述するＸＭＬスキーマをサービスに対し提供することができる。メッセージ・ゲートは、そのゲートが構築されたＸＭＬスキーマに従って発送または受け取ったメッセージの正しさを検証する。
【００８７】
ゲートは、分散コンピューティング環境で、型検証および／またはメッセージの正しさの検証および／またはクライアントとサービスとの間のメッセージに対する発送側識別を実行するコードおよびデータの単一のアトミック・ユニットとして構築することができる。一実施形態では、メッセージ・ゲートに対するコードおよびデータのアトミック・ユニットが作成されると、これはその型付け、メッセージ記述子、および発送側識別に関して変更することはできない。他の実施形態では、ゲートは、作成後、メッセージ・スキーマ内のメッセージの削除、追加、または修正を含めて、メッセージ・スキーマのコンテンツに関して修正することができる。
【００８８】
メッセージ・ゲートは、分散コンピューティング環境におけるクライアントまたはサービスのメッセージ・エンドポイントである。メッセージ・ゲートは、型安全なＸＭＬメッセージを送り受け取るセキュリティで保護されたメッセージ・エンドポイントを備える。メッセージ・ゲートを使用すると、クライアントとサービスは、適当なメッセージ・トランスポート（たとえば、ＨＴＴＰ）で、セキュリティで保護され信頼できる方法により、ＸＭＬメッセージを交換することができる。クライアントでは、メッセージ・ゲートは、サービスの機能の一部または全部を使用する権限を表す。各機能は、サービスに送ることができるメッセージによって表すことができる。このようなメッセージはそれぞれ、メッセージの正しさを検証するクライアント・メッセージ・ゲートを通じて送ることができる。メッセージを受け取るには、メッセージを認証し、その正しさを検証するサービス・メッセージ・ゲートを使用する。
【００８９】
メッセージ・ゲートは、ＸＭＬメッセージの型検査を行うセキュリティで保護された通信エンドポイントを備えることができる。後述するように、メッセージ・ゲートはさらに、クライアントとサービスとの間のメッセージの流れを制限するメカニズムを備えることができる。一実施形態では、クライアントがサービスにアクセスしようとする場合、クライアントとサービスのメッセージ・ゲートのペアが、すでに存在しているのでなければ、作成される。一実施形態では、サービス・メッセージ・ゲートは、サービスがクライアント・メッセージ・ゲートから第１のメッセージを受け取ったときに作成される。一実施形態では、１つまたは複数のサービス・メッセージ・ゲートをサービスの初期化時に作成し、これを使用して、作成の際にクライアント・メッセージ・ゲートとペアを組むようにできる。メッセージ・ゲートを作成する場合、目的のレベルのセキュリティを交渉する認証サービスおよびクライアントとサービスとの間で受け渡すことができるメッセージ・セットが必要になることがある。一実施形態では、認証サービスはクライアントＩＤトークン（クライアント・トークンともいう）、サービスＩＤトークン（サービス・トークンともいう）、およびサービスに発送またはサービスから受け取ることができるデータ表現言語メッセージ・セットを記述するデータ表現言語メッセージ・スキーマを受け付けることができる。たとえば、サービスを呼び出す、またはサービスのいくつかの一部を呼び出すために、クライアントからサービスに送られるメッセージを記述できる。また、応答メッセージやイベント通知メッセージなど、サービスから送るメッセージも記述できる。メッセージ・ゲートの構築および使用での認証サービスの使用方法の詳細については、以下の「認証とセキュリティ」の項を参照のこと。
【００９０】
クライアント・メッセージ・ゲートとサービス・メッセージ・ゲートのペアにより、クライアントとサービスとの間でメッセージを送ることができる。一実施形態では、サービスのメッセージ・スキーマに記述されているとおり全メッセージ・セットのサブセットを発送かつまたは受け取るだけのメッセージ・ゲートを作成することができる。分散コンピューティング環境でこのような制限されたアクセスを利用することにより、セキュリティ・ポリシーに基づいて特定の個別メッセージ・タイプへのアクセスのみをクライアントに許可する最低限の特権のポリシーを実施することができる。ゲートの使用法およびゲートの作成方法の詳細については、以下の「認証とセキュリティ」の項を参照のこと。
【００９１】
クライアント・ゲートとサービス・ゲートは、サービス通知（サービス通知内のサービスのＵＲＩ）で指定されたプロトコルを使用して、クライアントからサービスへのメッセージの実際の発送（および受取）を実行する。クライアントは、このメッセージ・パッシングでサービスを実行する。メッセージ・ゲートは、クライアントとサービスとの間の抽象（ａｂｓｔｒａｃｔｉｏｎ）のレベルを与える。クライアントは、サービス・オブジェクトに直接アクセスする代わりにメッセージ・ゲートを通じてサービス・オブジェクトにアクセスすることができる。ゲートはクライアントからのサービスを抽象化しているので、クライアントが最初にサービスを使用するまで、サービスのコードをロードして開始する必要はない。
【００９２】
クライアント・ゲートも、ＸＭＬスキーマと突き合わせてメッセージの検証を実行するか、または、たとえば、メッセージがまだ検証されていないことをクライアントが示した場合に、ＸＭＬスキーマと突き合わせてメッセージの検証をサービス・ゲートによって実行することができる。いくつかの実施形態では、単純なクライアントの場合に検証は実用的でなく、クライアント側に必要ない場合がある。いくつかの実施形態では、サービス側で検証を実行できる。ゲートではさらに、認証有効化および／またはセキュリティ方式を実行することもできる。一実施形態では、クライアントがサービス通知で指定されたプロトコルをサポートしない場合、正しいゲートを構築できないことがある。この問題を避けるために、サービス通知（ゲート構築に使用される）はサービスに使用可能なＵＲＩのリストを含め、さまざまなクライアントをサポートできるようにする。
【００９３】
基本メッセージ・ゲートは、メッセージを発送および受け取るためのＡＰＩを実装できる。このＡＰＩは、ゲートとの間でデータ（たとえば、ＸＭＬメッセージ）を出し入れし、送る前および／または受取後のメッセージの妥当性を確認する。一実施形態では、メッセージ・ゲートは、メッセージを発送および受け取るための定められた最低限のＡＰＩをサポートできる。後述のように、このＡＰＩは他の機能に拡張することができる。図１０ｂに示されているように、ゲート１３０は、ＸＭＬスキーマ１３２に従って生成することができる。生成されたゲート・コードは、ＸＭＬスキーマに基づいてメッセージを検証する。このゲートは、メッセージＡＰＩを通じてメッセージ・タイプおよび／またはコンテンツが正しいかどうかを検証する。図１０ｂに示されているように、検証されたメッセージは、メッセージＡＰＩを通じて、サービスに送られる。このメッセージを、サービス側の対応するゲートで受け取る。このメッセージへの応答として、サービスは結果１８０を生成することができる。サービスは、そのゲートを通じて結果データ１８２を返す。結果データは、それ自体結果であるか、または、スペースに格納されている結果へのＵＲＩなど結果に対する参照である。さまざまな実施形態において、メッセージＡＰＩは、たとえば、同期メッセージ（要求応答）、非同期メッセージ（応答は要求から切断される）、ユニキャスト・メッセージ（２地点間）、マルチキャスト・メッセージ（ブロードキャスト）、およびパブリッシュとサブスクライブ（イベント・メッセージ）をサポートできる。リモート・メソッド呼び出しメッセージなどの他のタイプのメッセージもサポートできる。
【００９４】
ゲートによって送られた各メッセージは、受取ゲートがメッセージを認証するための認証証明書を含むことができる。各メッセージは、さらに、メッセージが損なわれていないあるいは改変されていないことを受取ゲートが検証するための情報を含むトークンも含む。たとえば、発送側は、受取側が検証するメッセージのハッシュまたはチェックサムを計算することができる。発送側はさらに、発送側の秘密鍵を使用してこのトークンおよび／またはメッセージ全体を暗号化し、暗号化されたメッセージに対応する公開鍵を含め、トークンが変更されていないことを受取側が検証できるようにする。詳細については、以下の「認証とセキュリティ」の項を参照のこと。
【００９５】
メッセージ・ゲートのペアは、クライアントからサービスへの要求およびサービスからクライアントへの応答を伝達するメカニズムを備える。２つの関連するメッセージ・ゲート・エンドポイントを使用して、要求応答メッセージ通信用のセキュリティで保護された双方向アトミック・メッセージ・チャネルを作成することができる。そこで、分散コンピューティング環境では、メッセージ・ゲートがクライアントとサービスの両方の側に存在するメッセージ・トランスポートを採用する。この２つのゲートは連携して、セキュリティで保護され信頼できるメッセージ・チャネルを実現する。
【００９６】
図１１ａには、サービス通知またはその他のサービス記述１３２からクライアント１１０内にゲート１３０ａを構築することを示す一実施形態の図が示されている。クライアントは、ＸＭＬサービス記述に基づいてゲートを生成するクライアント上の信頼できるコードであるゲート・ファクトリ１４０を備える。ゲート・ファクトリ１４０を使用すると、生成されるゲートが信頼できるコードでもあること、またそのコードがサービス通知に関して正しいものであることを確認することができる。図１１ｂに示されているように、ゲート１３０ｃはさらに、サービス１１２に構築することもできる。クライアント・ゲート１３０ａおよびサービス・ゲート１３０ｃは、クライアントとサービスとの間の通信を行うためのメッセージ・エンドポイントを提供する。一実施形態では、ゲート・ファクトリがゲート１３０を構築するために必要とする断片はサービス（サービス通知から）のＸＭＬスキーマとサービス（サービス通知から）のＵＲＩである。他の実施形態では、さらに、サービスを通知で指定された認証サービスを実行することにより、認証証明書を取得し、ゲート構築で使用することができる。
【００９７】
ゲート・ファクトリは、メッセージ・ゲートを作成するための信頼できるメカニズムを備える。いくつかの実施形態では、メッセージ・ゲートが信頼できるメッセージ・エンドポイントであることを確実なものとするために、ゲートを作成するために使用されるコードは信頼できるコードである必要がある。ゲート・ファクトリ１４０は、ゲートを作成するために使用されるコードの信頼できるパッケージとすることができる。一実施形態では、分散コンピューティング環境でメッセージの発送および受取を望む各クライアントおよびサービス・デバイス・プラットフォームはゲート・ファクトリを備える。いくつかの実施形態では、別のゲート・ファクトリによりゲートをあらかじめ構築して、あらかじめ構築されたゲートを備えたデバイスで完全なゲート・ファクトリを必要としなくて済むようにするか、またはゲートは、サービスＵＲＩおよび／または認証証明書の実行時に（たとえば、メッセージ通信が必要なときに）あらかじめ構築されたゲートにバインドする部分ゲート・ファクトリを備えることができる。
【００９８】
デバイス用のゲート・ファクトリは、ローカル・デバイス・プラットフォームの言語、セキュリティ、型安全性、および／または実行環境の特性を組み込むゲート・コードを生成できる。デバイスは、ゲート自体を構築することにより、生成されたゲート・コードにバグがないこと、有効なデータのみを生成すること、型安全であることを確認することができる。サービスにアクセスするためコードをダウンロードするのではなく自分のゲート・コードをデバイスで生成する利点は、クライアント・コード管理環境に制御権があるという点である。生成されるコードは、クライアントのコード実行環境（たとえば、Ｊａｖａ、Ｃ＋＋、Ｓｍａｌｌｔａｌｋ）だけでなく、その管理およびセキュリティ・フレームワーク（Ｗｅｂサーバおよび／またはオペレーティング・システム）に適合する。生成されたコードは、クライアントの実行時環境がコード作成に関わっていたため信頼できるコードでもある。したがって、信頼できる生成されたコードにより信頼できるセキュリティ情報も追加できる。そのため、デバイスはサービスに対するＸＭＬメッセージ・スキーマを受け取りてから、その後デバイスにアクセスするためにそのスキーマに基づいてゲートを構築することができる。ＸＭＬスキーマは、サービスとの契約を定義することとみなすことができ、生成されたゲート・コードは、その契約を実行するセキュリティで保護された手段を提供することとみなすことができる。信頼できない（たとえば、ダウンロードされた）コードが実行される開いているデバイスは、信頼できるコードでのみゲートを生成できるように設定できることに注意されたい。開いているデバイスは、ゲートの実装、特にゲート認証証明書を発見することができるデバッガなど、ゲートがツールからアクセスできない保護され分離されているコード・コンテナに封じ込められているプロセス・モデルを採用することができる。
【００９９】
ゲート・ファクトリ１４０は、クライアントのためにサービスと交渉し、メッセージをサービスに送るためのゲートを作成する。同様に、ゲートをサービスで構築し、クライアント・ゲートからメッセージを受け取り、メッセージをクライアント・ゲートに送るようにできる。それとともに、クライアントとサービス・ゲートは、セキュリティで保護された双方向通信チャネルを形成できる。
【０１００】
ゲート・ファクトリは、ゲートを作成する際にあるレベルの抽象化を行う。たとえば、クライアントがサービスを使用することを望んでいる場合、クライアントが直接サービスにアクセスするゲートを作成する代わりに、サービスをインスタンス化する一環としてゲート・ファクトリによりゲートを作成できる。
【０１０１】
ゲート・ファクトリは、構築するゲートの認証証明書を受け取るため認証サービス（たとえば、サービス通知により指定された）と通信するために使用される信頼できる独自のメッセージ・ゲートを作成または備えることができる。アクセスが制限されているサービスでは、認証証明書なしでゲートを構築することができる。サービスではアクセスを制限しないので、このようなサービスのゲートは、各メッセージを有する認証証明書を送る必要がない場合がある。認証サービスは、一実施形態では、アクセスを制限しないサービスの一例である。したがって、サービスでアクセスを制限するかどうかをチェックすることによりゲート構築を最適化するようにゲート・ファクトリを設定できる。サービスがアクセスを制限しない場合、ゲート・ファクトリはゲート構築の一環として認証サービスの実行を回避することができ、また構築されたゲートの一部として認証証明書に対する取り込まれた規定を回避できる。ゲート・ファクトリはさらに、ＸＭＬメッセージ・スキーマ（たとえば、サービス通知によって指定される）を受取またはダウンロードし、そのスキーマとマッチするゲートを作成することもできる。ゲート・ファクトリはさらに、ＵＲＩと通信するクライアント・メッセージ・ゲートの作成に使用するサービスおよび／またはサービス・メッセージ・ゲート用にＵＲＩを受取またはダウンロードすることもできる。
【０１０２】
さらに、サービスのＸＭＬスキーマと突き合わせてメッセージのチェックを実行することを望んでいないいくつかのクライアントに対して別のゲート構築最適化を採用することができる。クライアントは、軽量過ぎてチェックを実行できなかったり、チェックを実行するのにサービス・ゲートに依存していたり、単にチェックの実行を選択しなかったりする（たとえば、ゲート・メモリ占有面積を減らすため）。提供されるＸＭＬスキーマと突き合わせてメッセージを検証するためにゲートを構築するかどうかの表示を受け取るようにゲート・ファクトリを設定できる。いくつかの実施形態では、いくつかのクライアントが、構築されたゲートのスキーマと突き合わせてメッセージの検証を行う機能を備えていないゲート・ファクトリを備えることができる。いくつかの実施形態では、メッセージを検証しないようにゲートを事前に構築する。いくつかの実施形態では、送出メッセージのみを検証するか、または受け取ったメッセージのみを検証するように、ゲートを構築することができる。したがって、いくつかの実施形態では、クライアントは、ＸＭＬスキーマと突き合わせてメッセージをチェックするゲート・コードの一部または全部の構築を回避するか、または回避することを選択できる。
【０１０３】
いくつかの実施形態では、デバイスは、同じサービスが実行されるごとに構築するのを回避するためにゲートのキャッシュを維持することができる。たとえば、新しいゲートがゲート・ファクトリにより構築されるときに、ゲートをゲート・キャッシュ内に維持することができる。ゲートが使用されなくなったら、削除する代わりに、ゲート・キャッシュ内に保持する。ゲート・キャッシュがいっぱいになったら、最近最も使用されていないデータを追い出すアルゴリズムなどのキャッシュ置換アルゴリズムに従って１つまたは複数のゲートをゲート・キャッシュから削除することができる。ゲートを構築するためゲート・ファクトリが呼び出された場合、ゲート・ファクトリはまず、新しいゲートの構築を回避できるようにゲート・キャッシュをチェックしてマッチするゲートがすでに存在していないか調べる。
【０１０４】
他のゲートを構築するのに使用した断片を適切に再利用することによりゲートの構築を軽量化することができる。各ゲートのいくつかの部分は同じでよいため、メッセージ検証コードの一部など、ゲートからゲートへ再利用することができる。さらに、いくつかのデバイスについては、共通ゲート・コードをデバイスのシステム・ソフトウェアに組み込み、そのデバイスのすべてのゲートと共有することができる。したがって、ゲート・ファクトリは、ゲートごとにこの共通コードを再構築することを回避することができる。その代わりに、ゲート・ファクトリは、単に、ゲートをこのシステム・ソフトウェア部分にバインドすることができる。たとえば、デバイスにどのようなトランスポートが提供されていようとメッセージ・レイヤを取り扱えるシステム・ソフトウェア部分を用意することができる。
【０１０５】
特に、スペース・サービスは、スペース・サービスに対して構築されたサービス・ゲートがそのスペース・サービスの他のサービス・ゲートと同じ多くの機能を実行できるため、上述のゲート構築最適化の多くに対して適切な候補といえる。スペース・サービスの詳細については、以下の「スペース」のセクションを参照のこと。
【０１０６】
いくつかの場合において、より効率的なメソッド呼び出し形式が存在することがある。たとえば、ターゲット・サービスがクライアント・アプリケーションと同じＪａｖａ仮想マシンで実行される場合、より効率的なメソッド呼び出し形式は、サービスに対しＪａｖａ Ｄｙｎａｍｉｃ Ｐｒｏｘｙ Ｃｌａｓｓを作成することである。このような場合、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔ．Ｍｅｔｈｏｄ呼び出しは、メッセージの発送よりも高速なことがある。ゲート・バインド時間プロシージャは、このような最適化をチェックし、ゲート・ファクトリを実行する代わりにそれを使用して、ゲートを作成するか、または既存のゲートをバインドする。
【０１０７】
一実施形態では、専用クライアントや小型埋め込み型デバイスの場合などで、実行時のゲート・コードの生成は、メモリの消費とコード生成時間の観点から、望ましくないことがある。したがって、実行時にゲートを生成するゲート・ファクトリを用意する代わりに、いくつかの実施形態では、ゲートを事前に生成し、デバイスに組み込む。たとえば、埋め込み型ソフトウェアのビルド時に、実行時に構築しなくてよい組み込みのセキュリティで保護されたメッセージ・エンドポイントを含める手段としてメッセージ・ゲートを生成することができる。したがって、組み込み型ゲートを持つクライアントは、完全なゲート・ファクトリを必要としないか、またはＵＲＩおよび／または認証証明書など、組み込みゲートへのある種の実行時バインドを実行するために部分的ゲート・ファクトリのみあればよい。
【０１０８】
ゲートの事前構築用に生成ツールを用意することができる。そのゲート生成ツールは、ＸＭＬパーサ、コード・ジェネレータ、およびコード・コンパイラを備える。一実施形態では、コード・ジェネレータはＪａｖａソース・コード・ジェネレータであり、コード・コンパイラはＪａｖａコード・コンパイラである。組み込みメッセージ・ゲートが望まれるソフトウェアのビルド時に、ゲートが望まれる関連するすべてのＸＭＬスキーマからの入力とともに生成ツールが実行される。
【０１０９】
たとえば、デバイスがデジタル・カメラとの間でメッセージを送受取できる組み込みメッセージ・ゲートを備えることが望ましい場合、デバイス・ソフトウェアのビルドは、カメラのＸＭＬメッセージ・スキーマを入力としてゲート生成ツールを実行する作業を含む。ＸＭＬスキーマは、ＸＭＬスキーマをメッセージ検証プロセスで高速アクセスするのに適している内部形式に変換するＸＭＬパーサにより解析することができる。ツールのコード・ジェネレータは、カメラのスキーマに対応するゲートのソース・コードを提供することができる。いくつかの実施形態では、生成ツールはさらにソース・コードをコンパイルし、ゲート・コードはデバイスのソフトウェア・パッケージにリンクすることができる。実行時に、分散コンピューティング環境でカメラ・サービスを発見することができる。カメラ・サービスのメッセージＵＲＩをデバイス内でカメラの組み込みゲートにバインドすることができる。事前に構築されたゲートへのＵＲＩのバインドは、デバイス内のゲート・コンストラクタによって実行される。このゲート・コンストラクタは、かなり小さく、単純なゲート・ファクトリである。カメラ・サービスがインスタンス化されると、カメラ・サービスのＵＲＩがＸＭＬメッセージとしてゲート・コンストラクタに渡される。その後、ゲート・コンストラクタはＵＲＩを事前構築されたゲートにバインドする。
【０１１０】
したがって、ゲートは、実行時に部分的にまたは完全に生成されるか、またはゲートは、実行時に実行されるバインド・プロセス（たとえば、ＵＲＩまたは証明書の）で実行時の前に事前生成される。一実施形態では、ゲート・ファクトリなどのゲート生成ツールまたは事前構築されたゲートの生成ツールを、あるレベルのプラットフォーム独立性を実現するＪａｖａベースのツールとすることができる。それとは別に、ゲート生成ツールは、分散コンピューティング環境では特定のデバイスのネイティブ・コードなど任意の言語のものが提供できる。分散コンピューティング環境では、デバイスがゲートのコードの一部または全部をダウンロードできないことはないことに注意されたい。たとえば、いくつかの実施形態では、サービスは、そのサービスへのアクセスを望むクライアントによってダウンロードできるゲート・コードを提供する。ただし、ダウンロードされたコードは、サイズ、セキュリティ、および／または安全に関する危険性を示す場合がある。
【０１１１】
一実施形態の考えられるゲート・コンポーネントの詳細な図を図１２に示す。ゲートは、そのアドレス（または名前）１５０、デスティネーション・ゲート・アドレス１５２、有効なＸＭＬスキーマ（または内部形式）１５４、およびトランスポートＵＲＩ １５３を備えることができる。他の実施形態では、ゲートに認証証明書１５６を含むことができる。一部のゲートは、さらに、リース１５８および／またはメッセージ・コンダクタ１６０を備え、メッセージ順序付けを検証することができる。ゲートの名前１５０は、そのゲートを参照するだけの一意的なＩＤでよい（そのゲートの存続期間中）。ゲートは、ゲート名１５０を使用してアドレス指定することができる。一実施形態では、ゲート名はＸＭＬスキーマのストリング（たとえば、サービス通知からのストリング）と１２８ビット乱数などの乱数の組み合わせとして生成することができる。名前１５０を使用する際に、クライアントおよびサービスはネットワークに関して移行することができ、またそのまま協調動作する。好ましい実施形態では、ゲート・アドレスは、物理的メッセージ・トランスポート・アドレスおよび／またはソケット・レイヤと独立である。したがって、ゲート名はメッセージ・トランスポート・アドレスに対するバインドおよびバインド解除できる仮想メッセージ・エンドポイント・アドレスを与えることができる。一実施形態では、ゲートの名前は、そのゲートの存続期間中、そのゲートを参照するだけのＵｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＵＩＤ）でよい。
【０１１２】
ゲート名は、ゲートは存続している限り存続するため、同じデバイス内で実行する異なるアプリケーションとクライアントは特定のゲートを繰り返し見つけて、使用することができる。たとえば、サービスにアクセスするためデバイス内で実行している第１のクライアント・プロセスについてゲートを作成することができる。第１のクライアント・プロセスがそのサービスに対する活動を完了した後、ゲートを解放する。ゲートを解放する作業では、ゲートの第１のクライアント・プロセスのメッセージ・トランスポート・アドレス（たとえば、ＩＰおよび／またはポート・アドレス）へのバインドを解除する必要がある。ゲートは、ゲート・キャッシュまたはリポジトリに格納することができる。同じサービスを実行する必要がある同じデバイス内で実行している第２のクライアント・プロセスは、そのゲートを名前で特定し、そのゲートを使用してサービスにアクセスする。ゲートを使用するために、第２のクライアント・プロセスはゲートをそのメッセージ・トランスポート・アドレスにバインドし、第２のクライアント・プロセスに対するメッセージ・エンドポイントがゲート名と第２のクライアント・プロセスのトランスポート・アドレスとの組み合わせになるようにする。他の実施例では、クライアントは動的ＩＰアドレスを受け取ることができる（たとえば、モバイル・クライアント）。クライアントのトランスポート・アドレスが変更されると、（１つまたは複数の）ゲート名がクライアントの新しいトランスポート・アドレスに再バインドされ、クライアントがそのまま、サービスを再配置しゲートを再作成せずにすでにアクセスしているサービスにアクセスできる。ゲート名は、プロセスの移行にも使用できる。プロセスおよび関連するゲートを、分散コンピューティング環境の一ノードにチェックポイント化するかまたは保存して、他のノードに移動することができる。プロセスを新しいノードで再起動し、関連するゲートをその新しいノードのトランスポート・アドレスにバインドすると、プロセスは、移行前のアクセス先であった外部サービスにそのままアクセスすることができる。ゲートは、ペアの相手である他のゲートの現在の場所を追跡することができる。したがって、サービスまたはクライアントを移行しても、そのままアクセス可能である。たとえば、複製または負荷バランスをとったサービス実装をゲートによってサービスのクライアントから抽象することができる。そこで、ゲート名１５０は、分散コンピューティング環境でメッセージ・エンドポイントのアドレス指定を行う柔軟性の高いメカニズムを提供する。ゲート名を使用して、ローカル・ネットワークからインターネットにいたるさまざまなネットワーク上でゲートを特定および／またはアドレス指定することができる。ゲート名は、メッセージ・トランスポートとは無関係で、メッセージ・エンドポイント（ゲート）を基礎となる異なるトランスポート・アドレス（たとえば、ＩＰ／ポート・アドレス・ペア）へのバインド解除および再バインドによりトランスポートからトランスポートへ移動することができる。
【０１１３】
一実施形態では、ゲートをさらにサービスから分離し、同じゲートを使用して時間がたつうちに要求を異なるサービスに送ることができる。この作業には、ゲートのデスティネーション・ゲート・アドレス１５２のバインドを解除し、新しいデスティネーション・ゲート・アドレスをゲートにバインドする作業が必要である。
【０１１４】
ゲートは、デバイスのトランスポート・レイヤの上のレイヤとして実装することができる（たとえば、ネットワーキング・ソケット）。各ゲートは、トランスポート参照１５３を含む。ゲート名１５０は、上述のようにトランスポート参照１５３にバインドされる。複数のゲートが、同じメッセージ・トランスポートを共有することができる。たとえば、複数のゲートが同じＴＧＰ／ＩＰソケットへのトランスポート参照１５３を持つことができる。同じメッセージ・トランスポートを共有することにより、各ゲートのサイズおよび複雑さを低減することができる。分散コンピューティング環境内のデバイスは、メッセージの送受取に必要なゲートの数が増える場合がある。複数のゲートに対するメッセージ処理の複雑さは、共通メッセージ・トランスポートを共有することにより低減される。トランスポート参照１５３は、トランスポートＵＲＩ（たとえば、ＵＲＬ）またはソケット参照であり、基礎のトランスポートに名前を付け、そのトランスポートを他のゲートと共有するメカニズムを提供することができる。複数のローカル・ゲートは、同じトランスポートへの参照１５３を含むが、各ローカル・ゲートは、ペアのリモート・ゲートとの間でメッセージの送受取を行う他のローカルゲートとは無関係に動作する。
【０１１５】
スキーマ１５４は、ゲート・ファクトリによってスペースからゲート内にダウンロードすることができる。スキーマを、メッセージ検証プロセス中に素早くアクセスするのに適している内部形式にコンパイルすることができる。一実施形態では、スキーマは、クライアント・サービス・メッセージおよびプロバイダ・サービス・メッセージという２つのメッセージのグループを指定できる。クライアント・サービス・メッセージ・グループは、クライアントが送ることができるすべてのメッセージの記述（プロバイダがサポートする）を含み、プロバイダ・サービス・メッセージ・グループは、プロバイダが送ることができる（クライアントが受け取る）すべてのメッセージの記述を含む。一実施形態では、クライアントまたはプロバイダのいずれかがスペース・サービスに対し特定の要求を送り、クライアント・サービス・メッセージ全体、プロバイダ・サービス・メッセージ全体、クライアントおよびプロバイダ・サービス・メッセージ全体、またはクライアント・サービス・メッセージまたはプロバイダ・サービス・メッセージのいずれかの特定のメッセージのいずれかのメッセージとともに応答メッセージを取得する。さらに、ゲートが構築された後、クライアントは、ゲートが実際にメッセージを送りなくても、ただし、その代わりに、ゲートのメッセージ群を検査することにより、サービスの機能に関してクエリを実行することができる。
【０１１６】
上述のように、メッセージ・ゲートは、認証証明書を使用するメッセージの発送側、型安全性に対するメッセージ・コンテンツをＸＭＬスキーマに従って検証することができる。ただし、クライアントとサービスとの間でメッセージが正しい順序で送られることを検証することが望ましい。クライアント上のアプリケーションに関係する既存の特定の機能なしで（たとえば、クライアント上のアプリケーションにＧＵＩがない場合）実行するクライアント用のアプリケーション（サービス）を提供できることが望ましい。たとえば、クライアント上でＷｅｂブラウザをサービスのＧＵＩとして使用し、アプリケーション固有のＧＵＩを使用しないようにできる。ＸＭＬスキーマ内の可能なメッセージのうち、クライアントは次にサービスに送るメッセージを知る必要がある。クライアントはサービスに関する特定の情報がないまま次に送るメッセージを判別できることが望ましい。一実施形態では、サービスは必要な次の入力を示す応答メッセージを継続的に送ることができる。サービスは、その後、要求入力が指定されているクライアントから対応するメッセージのみを受け入れる。メッセージ順序付けに対する他のアドホックな方式も採用できる。
【０１１７】
他の実施形態では、各メッセージのシンタックスを検証する（スキーマに従ってゲート内ですでに実行されている可能性がある）のとは反対に、メッセージ・コンダクタ１６０をゲート内で採用するか、またはゲートに関連付け、メッセージの正しい順序を検証することができる。メッセージ・コンダクタ１６０は、アプリケーションの準備のためのより一般的なアプローチをとることができる。メッセージ・コンダクタ１６０は、サービスの通知で指定できる。スキーマ内のメッセージ・コンダクタ指示により、ゲート構築中に、クライアント上に生成するか、またはクライアントにダウンロードすることができ、次にサービスに送るメッセージを決定するのに必要なコレオグラフを提供できる。メッセージ・コンダクタは、Ｊａｖａアプリケーション、Ｊａｖａ Ｓｃｒｉｐｔ、およびＷＭＬスクリプトとして、または他のプログラミングまたはスクリプティング言語で実装できる。
【０１１８】
一実施形態では、メッセージ・コンダクタは入力を、クライアントとサービスの間で送ることができるメッセージの有効な順序またはコレオグラフを表示するＸＭＬ文書（たとえば、サービス通知からの）として受け入れることができる。このＸＭＬ文書はさらに、ユーザ・インターフェース情報とその他の規則を指定することもできる。コンダクタは、このＸＭＬ文書を解析して、内部形式にし、囲まれている順序付け情報に従ってメッセージ順序付け（および／またはその他の規則）を強制する。コンダクタは、メッセージの発送順序が狂うのを防ぐことができる。または、メッセージの発送順序が狂った場合、発送デバイス内に例外を発生させることができる。メッセージの受取順序が狂った場合、コンダクタは順序付けエラーを宣言する自動応答メッセージを送る。これで、発送側はメッセージを正しい順序で再送することができる。いくつかの実施形態では、コンダクタの一部または全部を複数のゲートで共有することができることに注意されたい。そのため、コンダクタを複数のゲートにリンクすることができる。
【０１１９】
分散コンピューティング環境の一実施形態では、サービスのフロント・エンド（サービス・インターフェース）をクライアントに組み込むことができる。一実施形態では、サービス・インターフェースを、サービスによってクライアントに提供される事前構築ユーザ・インターフェースとすることができる。一実施形態では、サービス・インターフェースを、サービス通知でクライアントに提供することができる。サービス・インターフェースは、クライアント上でサービスのユーザと対話し、サービスを実行するための入力を取得し、サービスを実行した結果をクライアントに表示することができる。「ユーザ」は、人間でも、組み込みシステムでも、他のクライアントまたはサービスなどでもよい。一実施形態では、クライアント・デバイスは、フロント・エンドを組み込んでいるサービスを実行できるだけなので、任意のサービスを用意することができない場合がある。一実施形態では、サービスのサービス・インターフェースは、クライアント上のＷｅｂブラウザに実装することができる。
【０１２０】
一実施形態では、メッセージ・コンダクタおよび／またはサービス・インターフェースはゲートの外部にあってもよく、したがって、ゲートとクライアントから抽象することができる。抽象されたメッセージ・コンダクタは、任意のクライアント・デバイスに対し任意のサービスを提供することができる。一実施形態では、メッセージ・コンダクタを、実質的にどのようなプラットフォームでも実行できるコードで書くことができる。一実施形態では、メッセージ・コンダクタは、Ｊａｖａ言語で書く。一実施形態では、メッセージ・コンダクタは、クライアント・デバイスに返される、オブジェクト、たとえば、Ｊａｖａオブジェクトの任意のダウンロードを必要としない。たとえば、非常に大きなオブジェクトを返す場合、メッセージ・コンダクタは、そのような非常に大きなオブジェクトをダウンロードしないことを選択できる。一実施形態では、メッセージ・コンダクタは、クライアントのために、ＸＭＬメッセージをクライアント・デバイスからサービスに送ることができる。メッセージ・コンダクタは、サービスのユーザと対話して、入力を受け取り、結果を表示することができる。
【０１２１】
一実施形態では、クライアントと対話し（たとえば、ユーザ・インターフェースを介して）、サービスを実行するためのすべての情報を取得するサービス・インターフェースを提供し、これにより、サービスを実行した結果または結果の場所に関する情報のいずれかを適宜表示することができる。サービス・インターフェースは、メッセージ・コンダクタ１６０の一部でもよく、またはメッセージ・コンダクタ１６０に加えてそれと連携することもできる。サービス・インターフェースは以下のいずれかである。
１．クライアント・デバイスに組み込まれ、クライアント上で実行される。
２．スペース・サーバからクライアント・デバイスにダウンロードされる。
３．スペース・サーバ上で実行される。
４．サービス・プロバイダ上で実行される。
【０１２２】
一実施形態では、クライアントに対して、分散コンピューティング環境のスペース・サーバは＃１を常にサポートし、＃２がサポートされていればそのことを示し（スペース内の通知で）、＃３と＃４のうち少なくとも１つがサポートされていればそのことを示す必要がある。＃４をサポートしているかどうかは、サービス・プロバイダが＃４をサポートしているかどうかにかかっていることに注意されたい。一実施形態では、サービス・プロバイダに対し、分散コンピューティング環境のスペース・サーバは＃４を常にサポートし、＃３をサポートしていればそのことを示す必要がある。
【０１２３】
サービス・インターフェースがどこで実行されようと、サービスがアクティブ化された後、サービス・インターフェースはクライアントと対話し、クライアントの表示装置に入力に対する要求を（リモートから）表示し、サービスの実行結果を（リモートから）表示することができる。クライアントとのこのような対話は、ＸＭＬメッセージとして実装される。このようなサービス・インターフェースおよび／またはメッセージ・コンダクタは、サービスを発見したけれども、ふつうサービスの使い方を知るために大部で無味乾燥のコンピュータ・マニュアルを読みたくないクライアント・ユーザのニーズに応えられる。サービス・インターフェースおよび／またはメッセージ・コンダクタがユーザと対話して、サービスが必要とするすべての入力を要求するときに、ユーザが要求した場合に、要求された入力の短い説明を用意することさえできる。サービス・インターフェースがクライアントから必要な情報を取得した後、ＸＭＬメッセージを、そのサービスを実行するサービス・プロバイダに送る。メッセージの順序は、ゲート内のメッセージ・コンダクタ１６０によって検証される。
【０１２４】
好ましい実施形態では、すべてのメッセージはゲート内を流れる。ゲートは、フロー制御メカニズムを提供するように構成することができる。たとえば、サービスが大量の着信メッセージおよび発信メッセージを処理する必要がある。フロー制御により、サービスは高トラフィック・ボリュームに追随することができる。フロー制御タグについてメッセージを監視するようにゲートを構成することができる。ゲートがメッセージを受け取ると、ゲートはそのメッセージに対するフロー制御タグを調べる。フロー制御タグはＸＭＬタグとすることができる。たとえば、メッセージには、ＯＦＦタグまたはＯＮタグのいずれかを記述できる。受け取ったメッセージにＯＦＦタグが含まれる場合、受取ゲートはペアのデスティネーション・ゲートへの発送メッセージを停止する。ゲートは、ＯＮタグを含むメッセージを受け取ると、メッセージの発送を再開する。
【０１２５】
そこで、サービス側ゲートはそのリソースの使用を監視し、そのリソースの使用がしきい値を超えた場合にフロー制御を起動する。たとえば、サービスが、ＯＦＦタグを含むメッセージを１つまたは複数のクライアント・ゲートに送ることにより負荷を低減することができる。ＯＦＦタグを含むメッセージを受け取ったクライアント・ゲートは、サービスへのメッセージ発送を停止する。クライアント内の保留メッセージは、バッファリングするか、または内部フロー制御メカニズムによって処理することができる。サービスがさらに要求を処理できるようになると、ＯＮタグを含む１つまたは複数のクライアントにメッセージを送り、クライアントはメッセージ発送を再開する。他の実施形態では、ＯＮおよびＯＦＦに加えて、またはＯＮおよびＯＦＦの代わりに、他のフロー制御タグをサポートすることができる。他のフロー制御タグはメッセージ・フローの低減を示すか、またはそのメッセージ・フローを高くすることができる。
【０１２６】
メッセージ・ゲートはリソース監視を実行するように構成することができる。たとえば、すべてのメッセージはゲート内を流れるため、ゲートはクライアントがサービス（および場合によっては、メモリーやスレッドなどの関連するリソース）を使用する状況を管理しかつ／または追跡するように構成することができる。ゲートは、サービスなどのリソースがどれだけ使用されているか、またどのサービス・リソースをどれだけ使用しているかを監視することにより、クライアントなどのソフトウェア・プログラムの活動を追跡するように構成できる。一実施形態では、ゲートはクライアント活動ログを生成するか、またはクライアント活動ログの生成を簡単に行えるようにする。各メッセージおよびその宛先または発送側をログに記録することができる。
【０１２７】
さらにゲートは、ゲート・ペアのローカル（発送）側からフロー制御に関するリソース監視を実行するように構成することもできる。クライアントが、割り当てられたサービス（またはリソース）使用の帯域幅を超えた場合、たとえば、ゲートは自動的にメッセージの流れを絞る。したがって、クライアント側メッセージ・ゲートは、発信メッセージの流れを監視することにより異なるフロー制御モードを自動的に起動することができる。発信メッセージ・フローがしきい値を超えた場合、ゲートは発信メッセージの流れを減らすかまたは遮断する。サービスのＸＭＬスキーマまたは通知でしきい値を指定することができる。いくつかの実施形態では、しきい値は特定のサービス・リソースを使用するメッセージのみまたはすべてのメッセージについて指定することができる。
【０１２８】
ゲートは、さらに、メッセージ・フローが増えるか、または再開するのを判別するように構成することもできる。一実施形態では、ゲートは、マッチする返信（応答）を受け取ることなく、送られた発信メッセージのカウントを保持することができる。マッチする応答がクライアント側ゲートに届いたら、未処理の要求メッセージのカウントを減らす。このカウントが未処理要求メッセージの指定されたしきい値以下に減ったら、ゲートは新しい要求メッセージを増やすか、またはその発送を再開することができる。
【０１２９】
ゲートは、メッセージ・ベースの課金請求機能をサポートするように構成できる。請求システムは、メッセージ・ゲートで発送および／または受け取ったメッセージの個数および／または種類に基づいて実装することができる。クライアントとの間でやり取りされるすべてのメッセージはゲートを通過するので、たとえば、１メッセージごとにまたは「即金で支払う」方式でサービス使用料金を簡単にクライアントに請求できるようにゲートを構成することができる。したがって、たとえば、ユーザの代わりに実行されているソフトウェアがメッセージを発送および／または受け取るごとにユーザに課金できる請求システムを分散コンピューティング環境内に実装することができる。
【０１３０】
一実施形態では、メッセージ・ゲートは、たとえば、サービスに関してＸＭＬスキーマから請求情報を受け取る。請求情報は請求ポリシーとチャージ・バックＵＲＩを表すことができる。チャージバックＵＲＩは、メッセージ・ゲートがユーザの代わりに時間課金または使用度課金する場合に使用する。メッセージ・ゲートは、課金メッセージをＸＭＬスキーマで指定したチャージバックＵＲＩに送ることによりチャージバックを実行する。このように構成されたゲートは請求ゲートと呼ばれる。請求ポリシーは、１メッセージ当たりの課金金額または累積メッセージ合計に対する課金金額などを示す。請求ポリシーは、ユーザに対しどれだけおよび／またはどのような頻度で（たとえば、ｘ個のメッセージを発送および／または受け取った後）課金するかを示す。このポリシーはある種のメッセージのみが課金を発生させ、このようなメッセージにより指定されたサービス・リソースが要求されることを示す。請求ポリシーはさらに、異なるクライアントまたはクライアントのクラスに対して異なる請求モデルを示す場合もある。たとえば、いくつかのクライアントがサービスにアクセスするためゲートを作成するときに一度限りの課金の対価を支払うように請求ポリシーを（たとえば、サービスのＸＭＬスキーマで）構成することができる。ポリシーは、即金で（たとえば、メッセージごとに）支払うクライアントを示す場合もあれば、または全く課金されないクライアントを示す場合もある。
【０１３１】
いくつかの実施形態では、クライアントは軽量すぎて完全なゲートをサポートできなかったり、クライアントに、直接分散コンピューティング環境に参加するためのソフトウェアを組み込めない場合がある。このような実施形態では、サーバ（サービスが通知されるスペース・サーバや他のサーバなど）はそのクライアントに対して完全または部分的なプロキシ・ゲートとすることができる。サーバは、クライアントで使用するサービスごとにサービス・エージェント（ゲートを含むことがある）をインスタンス化する。サービス・エージェントは、メッセージを送る許可を確認し、メッセージをプロバイダに送り、その際、場合によってはプロバイダが次のメッセージを受け付けるようになるまでキューに入れておき、メッセージをクライアントに送り、その際、場合によってはクライアントが次のメッセージを受け付けるようになるまでキューに入れておき、結果またはアクティブ・スペースに結果を格納する作業を管理するという操作を行うことができる。「ブリッジ」のセクションを参照されたい。たとえば、図１３に示されているように、クライアントは、ゲートが上述のメッセージング方式に直接参加することをサポートしていない従来のブラウザ４００とすることができる。ブラウザ４００は、プロキシ・サーブレット（エージェント）４０２によって補助される。ブラウザのユーザは、サーチ・エンジンを使用して、分散コンピューティング環境内のスペース通知サービスの前面に置かれる（その内容を表示する）Ｗｅｂページを見つけることができる。ユーザは、スペースのＷｅｂページをポイントしてクリックし、サーブレットの助けを借りて、サービスにアクセスすることができる。Ｗｅｂページには、スクリプト、たとえば、ＪａｖａやＷＭＬスクリプトを含むことができ、これを使用して、ブラウザをプロキシ・サーブレットに接続する。また、スクリプトを使用して、メッセージをプロキシ・サーブレットに送ることもできる。サーブレット・エージェントは、ブラウザ・クライアントに代わってＷｅｂページ・アクションをメッセージに翻訳する。これらのはアクションは、スペースのナビゲート、サービスの起動、および結果の返却を含む。結果ページＵＲＩ（ＸＭＬを含むページを参照する）は、直接（または必要ならばＨＴＭＬまたはＷＡＰに変換されて）ブラウザに返され、ユーザに対し表示される。したがって、ブラウザ・ベースのクライアントは、サービスの起動方法を知る必要がなく、またサービス使用セッションで送るメッセージを知る必要もない。たとえば、ＷＡＰブラウザのユーザ（たとえば、携帯電話の）は、スペース・ページに接続し、そのコンテンツ（サービス）を参照し、サービスを起動するが、すべてポイントしてクリックする操作により行える。エージェント４０２は、従来のクライアントと分散コンピューティング環境との間のクライアント・インターフェースを備える。
【０１３２】
分散コンピューティング環境は、異なる機能をサポートするクライアントとサービスとの間の通信を行うための数種類のメッセージ・ゲートを備えることができる。たとえば、上述のように、いくつかのゲートは、フロー制御または請求機能をサポートする。他の種類のメッセージ・ゲートでは、特定の形式のリモート・メソッド呼び出しをサポートする。このタイプのゲートは、メソッド・ゲートと呼ばれる。
【０１３３】
ゲートは、型安全なメッセージ、たとえばＸＭＬメッセージを送り受け取るセキュリティで保護されたメッセージ・エンドポイントである。リモート・メソッド呼び出し（ＲＭＩ）スタイルのゲートは、メソッド・ゲートと呼ばれる。直接データ中心ゲートは、メッセージ・ゲートと呼ばれる。メソッド・ゲートは、メッセージ・ゲートの上の「レイヤ」として実装することができる。正確な実装は、プラットフォームのバインドで定義することができる。
【０１３４】
図１４は、メソッド・ゲートを使用してリモート・メソッド呼び出しインターフェースをサービスに提供する方法を示す。メソッド・ゲートは、クライアントとサービスとの間のメソッド・インターフェースを提供する。メソッド・ゲートは双方向にすることができ、クライアントからサービスへ、またサービスからクライアントへのリモート・メソッドを呼び出しが可能である。ＸＭＬスキーマ情報１７０から（たとえば、スペース内のサービス通知から）メソッド・ゲート１７２を生成することができる。ＸＭＬスキーマ情報１７０は、メソッド・インターフェースを定義するＸＭＬを含む。この情報から、１つまたは複数のメソッドとのインターフェースのコードをゲートの一部として生成することができる。生成されたコード内の各メソッドを呼び出し（たとえば、クライアント・アプリケーション１７６からの）により、マーシャリングされたメソッド・パラメータを含むメッセージをサービスに送ることができる。含まれるメッセージのシンタックスおよびパラメータをＸＭＬスキーマで指定する。したがって、メソッド・ゲート１７２は、サービス・メソッドをリモートから呼び出すＸＭＬメッセージ・インターフェースを備える。メソッド・ゲートは、クライアント上に生成するか、またはサービス・メソッドが通知されたスペース・サーバまたは特別ゲートウェイ・サーバなどのサーバをプロキシとすることができる。
【０１３５】
サービスは、サービスのＸＭＬスキーマで定義されたメソッド・メッセージ・セットに対応するオブジェクト・メソッド・セットを実装するかまたは、それにリンクされている対応するメソッド・ゲートを備えることができる。サービスのメソッド・ゲートよって実装された、またはそれにリンクされているオブジェクト・メソッドとサービスのＸＭＬスキーマによって定義されたメソッド・メッセージとの間に一対一の対応関係がある。サービスの対応するメソッドがクライアントからメッセージを受け取りサービスのメソッドの１つを呼び出すと、サービスのメソッド・ゲートはメッセージ呼び出しのパラメータのアンマーシャリングまたはアンパックを行い、受け取ったメッセージによって示されるメソッドを呼び出し、アンマーシャリングされたパラメータを渡す。
【０１３６】
メソッド・ゲートは、同期要求応答メッセージ・インターフェースを備え、クライアントがこれを使用してリモートからメソッドを呼び出し、サービスが結果を返すようにする。基礎のメッセージ・パッシング・メカニズムは、クライアントから完全に隠されている。この形式のリモート・メソッド呼び出しでは、メソッドの結果を次のように処理することができる。一実施形態では、結果オブジェクト（および関連するクラス）をクライアントにダウンロードする代わりに、結果の参照のみをＸＭＬメッセージで返す。オブジェクト参照１７８は実際のオブジェクト結果１８０（たとえば、ネット上にそのまま格納）を表す生成されたコード・プロキシ（たとえば、結果ゲート）である。他の実施形態では、クライアントは実際の結果オブジェクトを受け取ることを選択できる。さらに、クライアントが結果オブジェクト参照を受け取った後、クライアントはこの参照を使用して実際の結果オブジェクトを受け取ったり操作したりできる。一実施形態では、結果参照に実際の結果への１つまたは複数のＵＲＩを含める。
【０１３７】
実際の結果オブジェクトは、サービス結果スペース内に格納される（これは、たとえば、サーブレットにより動的に作成できる）。この一時的結果スペースは、クエリ結果キャッシュとして機能することができる。古い結果領域をクリーンアップするサーバ・ソフトウェア（ガベージ・コレクタ）が結果キャッシュ（スペース）内を巡回する。メソッドを呼び出しごとに返される結果は、結果スペース内に通知される。クライアントがリモートから結果自体をインスタンス化し、その固有のメソッド・ゲートを生成できるメソッドである場合もあれば、そのようなメソッドを含む場合もある。したがって、分散コンピューティング環境では再帰的リモート・メソッドを呼び出しサポートすることができる。
【０１３８】
上述のように、クライアントはメソッド・ゲートを使用してリモートからサービス・メソッドを呼び出すと、サービス・メソッド・ゲートから実際の結果ではなくメソッド結果への参照が返される。この参照から、結果ゲートを生成して実際の結果にアクセスする。したがって、クライアントまたはクライアント・メソッド・ゲートは結果ＵＲＩ、それとたぶん、結果ＸＭＬスキーマおよび／または認証証明書を受け取り、これを使用してゲートを構築しリモート・メソッド結果にアクセスする。
【０１３９】
一実施形態では、サービス・ゲートは結果に対する「子ゲート」を作成する。この子結果ゲートは、親ゲートと同じ認証証明書を共有することができる。いくつかの実施形態では、結果は異なるアクセス権限セットを備え、したがって、その親と同じ認証証明書を共有しない。たとえば、給料支払い簿サービスではユーザの異なる集まりが給料支払い簿サービスの結果（給与）を読み取るためにそれを起動することができる。
【０１４０】
サービス・メソッド・ゲートは、子結果ゲートをメソッドの結果としてクライアント・ゲートに返す。クライアントは、その結果ゲートを使用して実際の結果にアクセスする。一実施形態では、結果ゲートを受け取るソフトウェア・プログラム（クライアント）は結果ゲートと結果自体とを区別することはできず、その場合、結果ゲートは実際の結果オブジェクトのオブジェクト・プロキシとなる。結果ゲートはさらに、結果オブジェクトへのリモート・メソッド呼び出しをサポートするメソッド・ゲートとすることもできる。このようにして、親と子のメソッド／結果ゲートのチェーンを作成できる。
【０１４１】
一実施形態では、メッセージ・ゲートおよびリモート・メソッドは、Ｊａｖａで書れている。この実施形態では、Ｊａｖａ入力システムに従ってメソッド結果が正しく入力される。上述のようにＪａｖａメソッドをリモートから呼び出した場合、結果ゲートは結果の型とマッチするＪａｖａの型にキャストすることができる。この実施形態では、分散コンピューティング環境でメソッド・ゲートを使用して、リモートＪａｖａオブジェクトがローカルＪａｖａオブジェクトとして動作するようにできる。メソッド呼び出しおよび結果は、実際のオブジェクトがローカルであるかリモートであるかに関係なくＪａｖａソフトウェア・プログラムと同じように表示される。結果に対するスペースの使用の詳細については、以下の「スペース」セクションを参照のこと。
【０１４２】
メッセージ・ゲートは、さらに、イベントのパブリッシュおよびサブスクライブ・メッセージ通信もサポートする。イベント・サポートのあるメッセージ・ゲートは、イベント・ゲートと呼ぶ。サービスのＸＭＬスキーマは、サービスによってパブリッシュされる１つまたは複数のイベントの集まりを示す。イベント・ゲートは、ＸＭＬスキーマから構築できる。イベント・ゲートは、サービスによってパブリッシュされたイベントの集まりの一部または全部を認識し、それらのイベントにサブスクライブし、各イベントを、サービスによって生成されるのといっしょに配布するように構成できる。
【０１４３】
サービスに対するイベントの集まりは、サービスのＸＭＬメッセージ・スキーマで記述することができる。ＸＭＬスキーマのイベント・メッセージごとに、イベント・ゲートはそのイベントの消費者としてサブスクライブする。一実施形態では、イベント・ゲートはＸＭＬスキーマで示されるすべてのイベントにサブスクライブする。ＸＭＬタグを使用してそれぞれのイベント・メッセージに名前を付ける。イベント・ゲートは、サブスクライブ先のイベントのＸＭＬタグを含むサブスクライブ・メッセージを送ることによりサブスクライブすることができる。
【０１４４】
サービスで対応するイベントが発生した場合、そのサービスはイベント・メッセージをサブスクライバに送り、そのイベントの発生を知らせる。イベント・メッセージは、ＸＭＬイベント・ドキュメントを含み、このメッセージはそれぞれのサブスクライブされたゲートに送られる。サブスクライブされたゲートがイベント・メッセージを受け取ると、ＸＭＬイベント・ドキュメントがそのメッセージから削除され、配布プロセスが開始する。イベント配布は、クライアント・プラットフォーム内のイベント・ドキュメントを配るプロセスである。クライアント・プラットフォーム内の各イベント消費者は、各タイプのイベントのイベント・ゲートにサブスクライブすることができる。Ｊａｖａプラットフォームで、入力システムはＪａｖａである（ＸＭＬイベント型から変換される）。イベント消費者は、イベント・ハンドラ・コールバック・メソッドをイベント・ゲートに供給する。イベント・ゲートは、これらのサブスクライブのリストを保存する。各イベント・メッセージがゲートに届くと（イベントを発生したサービスから）、ゲートはクライアント消費者のリストをトラバースし、各ハンドラ・メソッドを呼び出して、ＸＭＬイベント・ドキュメントをパラメータとして渡す。一実施形態では、ＸＭＬイベント・ドキュメントはハンドラ・コールバック・メソッドに渡される唯一のパラメータである。
【０１４５】
一実施形態では、イベント・ゲートはローカルの消費者クライアントのためにイベントに関して自動的にサブスクライブする。クライアントがインタレストをゲートに登録すると、ゲートはインタレストをイベント・プロデューサ・サービスに登録する。クライアントはさらに、インタレストのサブスクライブ解除も行い、これにより、ゲートはそのイベントを生成するサービスから登録を解除する。
【０１４６】
イベント・ゲートは、上述の標準要求応答メッセージ通信スタイルで通常のメッセージ・ゲートが行うのと全く同じようにしてＸＭＬスキーマを使用しイベント・ドキュメントの型検査を行う。イベント・ゲートは、さらに、送られたメッセージ内の認証証明書を含み、受け取ったイベント・メッセージの認証証明書を検証することができる。
【０１４７】
上述のゲート機能の組み合わせは単一のゲートでサポートされることに注意されたい。それぞれのタイプは、分かりやすくするため、別々に説明した。たとえば、ゲートは、メッセージ・ゲート、メソッド・ゲート、およびイベント・ゲートであって、フロー制御とリソース監視をサポートする。
【０１４８】
サービス発見メカニズム
一実施形態では、分散コンピューティング環境は、クライアントがサービスを見つけだし、サービスの機能の一部または全部を使用する権限を交渉するための手段を提供するサービス発見メカニズムを備える。スペースはサービスの一例であることに注意されたい。サービス発見メカニズムは、セキュリティで保護され、発信クライアント要求を追跡し、着信サービス応答とマッチングを行うことができる。
【０１４９】
サービス発見メカニズムは、それらに限定されないが、以下のようなさまざまな機能を提供することができる。柔軟なサーチ基準を使用してサービスを見つける機能、サービスの機能セット全体またはそのサブセットを使用する権限をクライアントに伝達することができる、承認メカニズム、たとえば認証証明書を要求する機能、クライアントにサービスのインターフェースを伝達するための証明書、ドキュメント、またはその他のオブジェクトを要求する機能などがある。一実施形態では、サービスのインターフェースは、サービスの機能の要求されたセットとのインターフェースを含むことができる。
【０１５０】
発見の追跡が最初の要求に応答する。一実施形態では、各クライアント要求は、マッチする応答で返されるデータの集合を含み、要求と応答の相関を求めることができる。
【０１５１】
分散コンピューティング環境の一実施形態では、サービス発見メカニズムは拡張可能文法に基づいて柔軟なサーチ基準を提供することができる。一実施形態では、サーチ対象のサービス名、サービス・タイプ、およびもしあればその他の要素とＸＭＬドキュメント内の要素とをマッチングすることができる。一実施形態では、ＸＭＬドキュメントはサービスに対するサービス通知である。ＸＭＬは、サーチのための柔軟で拡張可能な文法を提供する。ＸＭＬはさらに、マッチする要素について型安全であるという特徴も備える。一実施形態では、サービス名およびサービス・タイプは、ＸＭＬサービス通知の要素タイプと突き合わせて型検査を行うことができる。
【０１５２】
一実施形態では、分散コンピューティング環境はクライアントがサービス・アクセス権を交渉するためのメカニズムを備えることができる。一実施形態では、このメカニズムを使用して、サービスの全機能のサブセットについて交渉することができる。交渉の結果は、クライアントにサービスの機能の要求されたサブセットを使用する権限を伝達する認証証明書などの承認である。
【０１５３】
一実施形態では、サービス発見メカニズムを使用する際に、クライアントはサービスにセキュリティ能力証明書を要求することができる。一実施形態では、クライアントはサービスに対し、保護された（セキュア）通知の形で望む機能群を示すことができる。それに対してサービスは、クライアントに保護された通知で記述されている要求された機能を使用する権限を伝達することができる能力証明書で応答することができる。
【０１５４】
一実施形態では、分散コンピューティング環境は、クライアントがサービス・アクセス権限を交渉し、その後、サービスのアクセス・インターフェースをクライアントによって要求されたサービスの機能のセットまたはサブセットに提示するために使用できるセキュリティ証明書またはドキュメントを取得するためのメカニズムを備えることができる。
【０１５５】
一実施形態では、サービスから能力証明書を受け取ったクライアントは、「完全通知」と呼ばれるカスタム・サービス・アクセス・インターフェース・ドキュメントを生成することができる。一実施形態では、完全通知はＸＭＬドキュメントである。生成された通知を利用し、受け取った能力証明書によってクライアントに対し許可されるサービス機能にアクセスすることができる。一実施形態では、通知により、クライアントが能力証明書によりアクセスを許可されたサービス機能のみのインターフェースが提供される。一実施形態では、クライアントに対し、必要な機能に限りクライアントがアクセス特権を持つアクセスを許可することができる。
【０１５６】
一実施形態では、分散コンピューティング環境はクライアントがサービスと機能を交渉するためのメカニズムを備えることができる。一実施形態では、クライアントはサービスに対する機能を交渉することができる。サービスはその後、クライアントと交渉したパラメータに基づいて結果をカスタマイズする。たとえば、１６０×２００の解像度で１ビット表示が可能なクライアントは、サービスに対しそれらのパラメータを交渉し、それにより、サービスはクライアントに対し結果をカスタマイズできる。
【０１５７】
以下に、ＸＭＬ機能メッセージの一例を示したが、何らかの形で制限することを意図していない。

【０１５８】
分散コンピューティング環境は、サービスがサービス呼び出しの結果を返す方法をクライアントが交渉できるようにするメカニズムを備える。一実施形態では、能力証明要求時に、結果返却方法の１つを選択する手段をサービスに伝達することができる。その後、サービスはクライアントに、使用する結果メカニズム、さらにサービス・インターフェースを伝達することができるカスタム・サービス通知を生成する。
【０１５９】
一実施形態では、分散コンピューティング環境はサービス発見サーチ要求および要求への応答を追跡するメカニズムを備える。一実施形態では、サーチ要求および応答メッセージは、フィールドを備え、このフィールドを使用してストリングまたはＸＭＬドキュメントを含むことができる。一実施形態では、要求メッセージのフィールドに含まれるストリングまたはＸＭＬドキュメントはさらに、応答メッセージでも返される。一実施形態では、ストリングまたはＸＭＬドキュメントは応答メッセージで返す必要がある。一実施形態では、ストリングまたはＸＭＬドキュメントは、応答メッセージで返すときにストリングまたはドキュメント内に挿入または付加される追加情報を含むことができる。一実施形態では、このメカニズムを複雑なシステムのデバッグに使用することができる。一実施形態では、このメカニズムはさらに、クライアントに対し、ストリングまたはＸＭＬドキュメントを使用して、クライアントとサービスのみが理解できるクライアントとサービスとの間のカスタムサーチ情報を渡すことによりアクセスするサービスを選択するためのメソッドを提供することができる。
【０１６０】
コンポーネント（サービス）インターフェースのマッチング
分散コンピューティング環境は、コンポーネント（たとえば、サービス）仕様インターフェースと要求されたインターフェースとのマッチングを行うメカニズムを備えることができる。たとえば、クライアント（サービスでもよい）は、一組のインターフェース要求条件を満たすサービスを必要とすることがある。各コンポーネントは、それが適合するインターフェースの記述を含む。仕様インターフェース・マッチング・メカニズムを使用すると、リクエスタのインターフェース要求条件と最もよくマッチするコンポーネントを配置することができる。仕様インターフェース・マッチング・メカニズムではさらに、インターフェース要求条件の「ファジー」マッチングを実行できる。つまり、このメカニズムを使用すると、インターフェースのすべての側面を正確に指定しなくてもマッチングを実行でき、最近マッチング（ファジー）メカニズムを実現できる。一実施形態では、仕様インターフェース・マッチング・メカニズムを、単一のインターレス・レベルで仕様を要求しないマルチレベル・サブクラス化モデルとして実装できる。
【０１６１】
一実施形態では、コンポーネントは、ＸＭＬスキーマ定義言語（ＸＳＤＬ）を使用してそのインターフェースを記述することができる。ＸＳＤＬでは、インターフェースを記述する人間が解釈可能な言語を実現し、デバッグなど人間の介入を必要とする活動を簡素化することができる。一実施形態では、インターフェース記述を本書の別のところで説明しているように通知の一部（たとえば、サービス通知）として提供することができる。
【０１６２】
仕様インターフェース・マッチング・メカニズムを使用すると基本的な望ましいインターフェースとコンポーネントの一組のインターフェース記述とを比較することができる。基本的な望ましいインターフェースとマッチする１つまたは複数のコンポーネントが識別される。インターフェース記述は、コンポーネントによって提供されるインターフェースをより具体的に記述するサブクラス記述を含む。サーチ・プロセスで、クラス・タイプ階層を調べて、所定のクラスがサーチ・タイプのサブクラスであるかどうかを判別することができる。一実施形態では、サブクラスは基本クラスのプロパティーを継承する。このフェーズではサブクラス特有の情報は調べることができない。そのため、サーチは一般的に実行するということができる。識別されたコンポーネントは、次の（サブクラス）レベルでサーチできる。サーチは、サブクラスに特有なものとなり、インターフェース記述に含まれるサブクラス情報を解釈することにより実行できる。サーチは、リクエスタの望むインターフェースとの最近マッチのある１つまたは複数のコンポーネントが判別されるまで１つまたは複数のサブクラスについて続けられる。
【０１６３】
一実施形態では、インターフェース・マッチング・メカニズムは、類似のインターフェースを実装する２つまたはそれ以上のコンポーネントを区別する機能を備える。一実施形態では、インターフェース・マッチング・メカニズムは、同じコンポーネントの異なるリビジョンを区別する機能を備える。
【０１６４】
一実施形態では、コンポーネントが適用するインターフェースの仕様を含むコンポーネント記述を提示することができる。コンポーネント記述にさらに、コンポーネント自体に関する情報を含めることができる。インターフェース記述および／またはコンポーネント情報を使用して、所定のインターフェースの異なる実装を区別することができる。コンポーネント記述には、標準識別子とバージョン情報を入れることができる。バージョン情報を使用すると、コンポーネントのリビジョンを区別することができる。一実施形態では、コンポーネント記述を本書の別のところで説明しているように通知の一部（たとえば、サービス通知）として提供することができる。
【０１６５】
一実施形態では、特定の標準識別子についてコンポーネントをサーチする。マッチする標準識別子を持つ２つまたはそれ以上のコンポーネントを識別することができる。マッチする標準識別子を持つコンポーネントのうちから１つまたは複数のコンポーネントを選択することができる。選択手順では、インターフェース仕様バージョン、コンポーネント実装仕様、コンポーネント実装仕様バージョン、コンポーネント記述からのその他の情報または情報の組み合わせを使用して、リクエスタの要求条件に最もよくマッチする１つまたは複数のコンポーネントの集まりを出力することができる。
【０１６６】
スペース
上述のように、分散コンピューティング環境はスペースに依存し、サービスまたはコンテンツをクライアントに仲介するランデブー・メカニズムを備える。図１５は、スペース１１４の基本的な使用法を示している。サービス・プロバイダは、スペース１１４でサービスを通知することができる。クライアント１１０は、スペース１１４で通知を見つけ、通知からの情報を使用し、分散コンピューティング環境のＸＭＬメッセージング・メカニズムを利用してサービスにアクセスする。多くのスペースが存在し、それぞれサービスまたはコンテンツを記述するＸＭＬ通知を含む。したがって、スペースは、サービスおよび／またはＸＭＬデータのＸＭＬ通知のリポジトリと考えることができ、これは結果などの未処理データまたはデータの通知とすることができる。
【０１６７】
スペース自体はサービスである。サービスのように、スペースには通知があり、スペースのクライアントはまず、そのスペース・サービスを実行するためにそれを取得する必要がある。スペースの自通知は、ＸＭＬスキーマ、１つまたは複数の証明書、およびスペースにアクセスする方法を示すＵＲＩを含むことができる。クライアントは、スペースにアクセスするためにスペース・サービスの通知からゲートを構築することができる。スペースのクライアントはそれ自体、そのスペース内で通知するまたは既存の通知を修正することを求めるサービス・プロバイダである。または、スペースのクライアントはスペースによってリストに入れられたサービスまたはコンテンツにアクセスすることを求めるアプリケーションである。したがって、スペースは分散コンピューティング環境においてクライアントとサービスとの間の対話に対する触媒の働きをする。
【０１６８】
スペースは、名前付きの通知の集合といえる。一実施形態では、通知に名前を付ける作業は、名前ストリングを通知に関連付けるプロセスである。この関連付けは、スペースに通知を格納した後発生する。スペースから通知を取り除くと、名前と通知との関連付けが解除される。スペースは、スペース自体を記述する単一のルート通知で作成できる。追加通知をスペースに加えることができる。通知の名前で、スペース内の通知を特定できるが、これは、名前の階層など必要なグラフ化情報を指定する操作を含む。好ましい実施形態では、分散コンピューティング環境はスペースの構造を規定しない。つまり、たとえば、スペースをフラットな関係付けのない通知の集まりまたは関係付けのされている通知のグラフ（たとえば、商用データベース）として構造化される。好ましい実施形態では、分散コンピューティング環境はスペースに実際にその内容を格納する方法を規定しないので、小さなデバイスから大きなデバイスまでスペースをサポートすることができ。たとえば、単純なスペースは、ＰＤＡなどの小さなデバイスに収まるように手直しすることができる。より高度なスペースは、大規模な商用データベースを採用している大規模なサーバー上に実装することができる。
【０１６９】
上述のように、スペースは分散コンピューティング環境でサービスの通知を含むことができる。通知は、分散コンピューティング環境内でサービスおよび／またはコンテンツのアドレスを指定し、アクセスするためのメカニズムを提供する。通知により、サービスのＵＲＩを指定することができる。いくつかの実施形態では、ＵＲＩを使用すると、インターネット上でサービスにアクセスすることができる。また、通知はサービスのＸＭＬスキーマも含む場合がある。ＸＭＬスキーマにより、サービスのクライアントがそのサービスの機能を呼び出すためにサービスに送る一組のメッセージを指定することができる。ＸＭＬスキーマでは、クライアント・サービス・インターフェースを定義する。それとともに、ＵＲＩおよび通知で指定されたＸＭＬは、サービスのアドレスを指定し、サービスにアクセスする方法を指示する。ＵＲＩとスキーマは両方とも、ＸＭＬで、スペース内の通知として用意される。そのため、分散コンピューティング環境でサービスのアドレスを指定し、サービスにアクセスするメカニズムをスペース内の通知として公開することができる。クライアントは、スペースを発見し、サービスまたはコンテンツについて個々の通知をルックアップする。
【０１７０】
図１６は、一実施形態による通知構造を示す。通知５００は、他のＸＭＬドキュメントのように、階層状に配列された一連の要素５０２を含むことができる。各要素５０２は、データまたは追加要素を含む。要素はさらに属性５０４を持つ。属性は、名前−値ストリングのペアである。属性は、メタデータを格納し、これにより、要素内のデータを記述することが簡単になる。
【０１７１】
いくつかの実施形態では、通知は異なる状態で存在してもい。このような状態の１つにドラフト状態がある。一実施形態では、スペースの範囲外に存在するドラフト状態で通知を最初に構築する。通知の作成者は、ＸＭＬエディタを使用するなどさまざまな方法で構築することができる。ドラフト状態の要素および属性へのアクセスは、適当な手段を使用して未処理データおよびメタデータ・レベルで行われる。通常、ドラフト状態で通知に加えられた変更についてはイベントを発生しない。したがって、通知の作成者は、自由に、要素を追加、変更、または削除できるだけでなく、目的の属性セットを用意し、確認する分散コンピューティング環境の残り部分に対する通知をパブリッシュすることができる。
【０１７２】
一実施形態では、通知に対する可能な状態としてほかに、パブリッシュ状態がある。通知は、スペースに挿入されるとパブリッシュ状態に移行する。通知がスペース内に入ると、関連するクライアントおよびサービスが、たとえば、名前および／またはその要素をサーチ基準として使用してそれを特定することができる。たとえば、サーチ基準は、スペース内の通知と（たとえば、スペース・サービスにより）比較できるＸＭＬテンプレート・ドキュメントとして指定できる。パブリッシュされた通知は、クライアントが使用できる状態にある「オンライン」サービスを表す。サービスのメッセージ・アドレス（ＵＲＩ）は、通知内に要素として格納できる。スペースから削除される通知は、破棄されるかまたは保持されるドラフト状態に遷移して戻る。削除により、イベントが発生し、関連するリスナーが変更に気づく。メッセージ・ゲートは通常、パブリッシュされた通知から作成される。
【０１７３】
一実施形態では、通知に対する可能な状態としてほかに、永続的アーカイブ状態がある。アーカイブ・プロシージャは、ライブ・パブリッシュ通知を、後で再構成するため永続的に格納できるバイトのストリームに変換する。アーカイブ通知が、スペースからアーカイブ・サービスに送られる（たとえば、ｒａｗ　ＸＭＬ形式で）。通知のアーカイブ・サービスのＵＲＩは、通知内に要素として格納できる。ＸＭＬは、通知の格納および取り出しを行い、通知オブジェクトを再構成するのに十分な通知要素の状態を表す形式を用意できる。通知は、アーカイブ・サービスの実装に応じて、他の形式でも格納できる。パブリッシュされた通知を永続的にするプロセスでは、永続的アーカイブ状態の通知を準備する。将来使用するため永続的通知を（たとえば、アーカイブ・サービスにより）、ファイルやデータベースなどの永続的記憶場所に格納できる。スペースは、アーカイブ・プロシージャを介して、通知を格納できるが、スペースは必ずしも、永続通知エントリを実際に格納する際に重要な役割を果たすわけではない。永続通知を格納する方法は、通知のアーカイブ・サービスにより決定される。通常、アーカイブ通知の代わりに生成されるイベントはない。また、永続的アーカイブ状態での通知に対し変更が許されない場合がある。通知は、アーカイブと削除、またはアーカイブだけが許される。通知が、スペースから削除することなくアーカイブされると、スペースはシャドウ・バージョンの通知を格納する。アーカイブされたサービスにアクセスすると、通知がオンデマンドで永続的バッキング・ストアから「フォールトイン」する。この機能を使用すると、たとえば、オンデマンドで、ＬＤＡＰ（ライトウェイト・ディレクトリ・アクセス・プロトコル）エントリから通知に入力することができる。
【０１７４】
図１７は、通知がその存続期間中に置かれる通知状態遷移の一例を示す図である。まず、１に示されているように、通知を構築することができる。構築のときに、通知はドラフト状態にある。その後、２に示されているように、通知がスペースの中に挿入される。通知は、パブリッシュされた親として挿入できる。通知は、スペースに挿入された後、パブリッシュ状態にある。イベント（たとえば、ＡｄｖＩｎｓｅｒｔＥｖｅｎｔ）は、通知がスペース内に挿入されたときに生成される。イベントについては以下で詳述する。通知は、３に示されているように、アーカイブされ、永続的にされ、これにより、通知が永続的アーカイブ状態に遷移する。通知はさらに、４に示されているように、永続的アーカイブ状態からパブリッシュすることもできる。通知は、スペースから除去され、５に示されているように、ドラフト状態に遷移し戻される。イベント（たとえば、ＡｄｖＲｅｍｏｖｅＥｖｅｎｔ）は、通知が削除されたときに生成される。
【０１７５】
一実施形態では、アーカイブされた永続的状態は使用されない。この実施形態では、状態変化３および４も使用されない。この実施形態では、通知はドラフト状態またはパブリッシュ状態のいずれかである。
【０１７６】
スペース内に格納された通知は、バージョン（要素の場合もある）、作成日（属性の場合もある）、変更日（属性の場合もある）、実装サービスＵＲＩ（要素の場合もある）、および／または永続的アーカイブ・サービスＵＲＩ（要素の場合もある）などの標準化された要素および／または属性を備える。
【０１７７】
スペース自体は通常サービスである。スペース・サービスは、スペース内の通知をサーチする機能を備え、これは、通知のタイプによるスペースのサーチを含む。スペース・サービスはさらに、通知を読み込み、通知を書き込み（パブリッシュする）、通知を取る（削除する）機能も提供することができる。スペースはさらに、スペース・イベント通知メッセージのサブスクライブを行う機能も備える。スペースには、位置によりスペース関係グラフをナビゲートする機能、通知要素の読み込み、書き込み、または取り出しの機能、通知属性の読み込み、書き込み、または取り出しの機能、および通知イベントの通知メッセージのサブスクライブの機能など、拡張機能を備えるものもある。スペースの機能については、以下で詳述する。スペースの機能は、スペース通知のメッセージ・スキーマで具現化される。メッセージ・スキーマ、スペース・アドレス、および認証証明書から、クライアント・メッセージ・ゲートを作成し、スペースとその機能にアクセスできる。
【０１７８】
スペースおよびスペース内のすべての通知は、ＵＲＩを使用してアドレス指定できる。一実施形態では、スペースおよび通知名は、ＵＲＬ命名規則に従う。いくつかの実施形態では、スペースのアドレス指定にＵＲＩ、たとえばＵＲＬを使用すると、インターネット全体からスペースにアクセス可能になる。スペース・メッセージ受取側（スペース・サービス）を指定するには、そのスペースについてサービス通知で受け取ったＵＲＩを使用する。ＵＲＩには、プロトコル、ホスト、ポート番号、および名前を含めることができる。プロトコルでは、クライアントとスペースの間でメッセージを移動するために使用できるプロトコルに名前を付ける（たとえば、信頼できるソケットまたは信頼できないソケット）。ホストおよびポート番号は、プロトコル依存のＩＤである。名前は、スペース名の後に通知、要素、および／または属性名を続けたものである。一実施形態では、パス名を使用して、スペース内の通知を識別することができる。パス名は絶対パスまたは相対パスのいずれかである。絶対パス名では、スペースだけでなく、通知も指定できる。相対パス名は、想定されるスペース内で指定通知に相対的である。一実施形態では、パス名の作成に適用されるシンタックスは、ＵＲＩ（統一リソース識別子）のシンタックスである。したがって、その実施形態では、通知およびスペース名はＵＲＩ予約語文字または一連の文字を含むことができない。要素および属性へのパス名も、ＵＲＩを使用して指定できる。一般に、要素名および属性名は、ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｓｐａｃｅｎａｍｅ／ａｄｖｅｒｔｉｓｅｍｅｎｔ／ｅｌｅｍｅｎｔ／ａｔｔｒｉｂｕｔｅなど通知のパス名に付加することができる。
【０１７９】
一実施形態では、分散コンピューティング環境は、クライアントがスペースのＵＲＩを発見できるようにするが、そのスペースに対するサービス通知へのアクセスを制限するメカニズムを備える。一実施形態では、完全通知をスペースに戻すのではなく、スペースのＵＲＩとスペースに対する認証サービスのＵＲＩを返す。クライアントは、スペース内で通知されたドキュメントまたはサービスにアクセスするために、まず、リターン・メッセージで与えられるＵＲＩで認証サービスに対し自己認証を実行する。認証サービスは、認証証明書を返し、これを使用して、クライアントはスペースに対する部分的または完全アクセスを実行できる。クライアントは、認証証明書を受け取ると、スペースに接続し、スペース内のドキュメントまたはサービス通知にアクセスしようとする。
【０１８０】
分散コンピューティング環境は、クライアントをスペースに接続できるようにするメカニズムを備える。接続メカニズムの実施形態は、クライアント−スペース・アドレス指定、クライアント承認、セキュリティ、リース、クライアント能力判別、およびクライアント−スペース接続管理に対応している。クライアント−スペース接続をセッションと呼ぶ。一実施形態では、セッションに一意的なセッション識別番号（セッションＩＤ）を割り当てることができる。セッションＩＤにより、クライアント−スペース接続を一意に識別することができる。一実施形態では、クライアントがリースを更新しない場合にセッション・リース・メカニズムを使用してセッションの透過的ガベージ・コレクションを実行する。
【０１８１】
一実施形態によるこのような接続メカニズムの使用例を以下に示す。クライアントは、認証証明書を取得する。一実施形態では、スペースでは、クライアントがスペースへのアクセスを要求したことに応答して行う認証サービスを提供する。クライアントは、認証サービスを通じて認証証明書を取得することができる。クライアントは、認証証明書を受け取ると、接続要求メッセージを送ることによりスペースとの接続を開始できる。一実施形態では、接続要求メッセージに、スペース・サービスのＵＲＩアドレス、クライアントの認証証明書、およびクライアントが要求している接続リースに関する情報を含めることができる。スペースは、接続要求メッセージを受け取った後、そのメッセージの妥当性を確認する。一実施形態はＸＭＬスキーマを使用してメッセージの妥当性を確認できる。クライアントは認証証明書を使用して認証を受けることができる。一実施形態では、接続要求メッセージで受け取った情報を使用してスペースを使用するクライアントの能力を判別することができる。一実施形態では、スペースの各クライアントにスペースを使用するそれぞれの能力の集まりを割り当てることができる。一実施形態では、スペースの１つまたは複数のクライアントに関する能力情報を含むアクセス制御リスト（ＡＣＬ）をクライアント能力判別で使用することができる。一実施形態では、接続要求メッセージで受け取った情報を使用してＡＣＬ内のクライアントの能力をルックアップすることができる。
【０１８２】
クライアントを認証し、クライアントの能力を判別した後、クライアントを許可する接続リースを判別できる。リースが判別された後、クライアント−スペース間接続を維持する構造を生成できる。接続に対するセッションＩＤを生成する。一実施形態では、各クライアント−スペース間接続に一意的セッションＩＤを割り当てる。一実施形態では、アクティブ化スペースを作成し、クライアント−スペース間セッションに割り当てるか、またはそれとは別に、既存のアクティブ化スペースをクライアント−スペース間セッションに割り当てることができる。一実施形態では、アクティブ化スペースを使用すると、スペースを使用したときにクライアントのサービスの結果を格納することができる。一実施形態では、クライアントの能力を使用して、アクティブ化スペースがクライアントに対し作成されるかどうかを判別する。たとえば、クライアントは、結果を格納し取り出すアクティブ化スペースにアクセスする能力を持たないことがある。１つまたは複数のメッセージをクライアントに送り、接続が確立されたことをクライアントに通知することができる。その１つまたは複数のメッセージに、セッションＩＤとリースに関する情報を入れることができる。その後、クライアントでは、それらに限定されないが、通知ルックアップ、通知登録、および通知取り出しなどのスペースを使用できる。一実施形態では、割り当てられたリースの有効期限が切れるか、またはクライアントがスペースにリース取り消しを要求するメッセージを送るまで接続は開いたままである。一実施形態では、クライアント側で、そのリースの有効期限が切れる前にそのリースを更新する必要がある。クライアントがリースを更新する前にリースの有効期限が切れた場合、接続は切断され、クライアントとスペースとの接続が途絶える。一実施形態では、再接続するには、クライアントは接続手順を繰り返す必要がある。
【０１８３】
一実施形態では、スペースのクライアントはスペースの通知をいくつかの異なる方法で取得することができる。クライアントがスペースの通知を取得する方法のうちいくつかを図１８に示す。たとえば、スペース発見プロトコルを分散コンピューティング環境の一部として提供することができる。スペース発見は、クライアントまたはサービスがスペースを見つけるために使用するプロトコルである。リスナー・エージェント２０２は、発見要求が来ないか監視するように１つまたは複数のスペースと関連付けて設定できる。発見リスナー・エージェント２０２は、さまざまなネットワーク・インターフェース上で待機し、スペースを探しているクライアント２００ａからブロードキャスト要求またはユニキャスト要求を（エージェントのＵＲＩで）受け取る。その後、リスナー・エージェント２０２は要求されたスペースのサービス通知に関してサービス通知またはＵＲＩで応答する。一実施形態では、リスナー・エージェントは、一般に、スペースから分離されているが、それは、その機能がスペース・サービスの機能と直交しているからである。ただし、リスナー・エージェントは、スペース・サービスと同じデバイスまたは異なるデバイスに実装することができる。
【０１８４】
一実施形態では、発見プロトコルはデフォルト・スペース内で通知されるサービスでよい。クライアントは、追加スペースを発見するためにクライアントのデフォルト・スペースから発見プロトコルをインスタンス化する。発見プロトコルは、クライアントのデフォルト・スペースに事前に登録できる。それとは別に、発見プロトコルは、たとえば、クライアントは発見サービスによって処理されるローカル・ネットワークに接続した時に、そのスペース内に通知を置くことによりデフォルト・スペースに自己登録することもできる。
【０１８５】
一実施形態では、スペース発見プロトコルを、ＳＬＰ、Ｊｉｎｉ、ＵＰｎＰなどの他のプラットフォーム用の基本デバイス発見プロトコルにマッピングすることができる。そこで、クライアントは分散コンピューティング環境の発見プロトコルを使用して他の環境内のサービスを見つける。これらの他の環境とのブリッジを用意し、それらの他の環境内のサービスに通知を送って、ここで説明した分散コンピューティング環境のクライアントがそれらにアクセスできるようにする。「ブリッジ」のセクションを参照のこと。
【０１８６】
通知される発見プロトコルごとに、分散コンピューティング環境では発見プロトコルの結果を保持するための後続結果スペースを作成することができる。一実施形態では、分散コンピューティング環境内のスペース・サービスはＭｕｌｔｉｃａｓｔ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ（マルチキャストＵＤＰ）を使用してＬＡＮ上でアナウンスすることができる。リスナー・エージェントがこの情報を記録する。デバイス（クライアントまたはサービス）は、Ｍｕｌｔｉｃａｓｔ Ｒｅｑｕｅｓｔ Ｐｒｏｔｏｃｏｌ（マルチキャストＵＤＰ）を使用して、スペース・マネージャの発見を開始する。一実施形態では、スペース・マネージャは、それぞれのスペースのＵＲＩを示す情報で応答する。それとは別に、リスナー・エージェントは複数スペースについて応答することができる。発見応答は、さらに、各スペースにラベルを付ける短いストリング（たとえば、スペースのキーワードから取得する）と、たとえばそれぞれのスペースに対し操作を実行する各スペース・マネージャとのＴＣＰ接続を設定するために使用できる情報を含むことができる。要求側デバイスは複数のスペース・マネージャから応答（またはリスナー・エージェントから複数のスペース・リスティング）を受け取るので、この情報は、クライアントが接続先スペースを選択する場合に役立つ。
【０１８７】
上述のマルチキャスト発見に加えて、発見サービスではさらに、ネットワーク（たとえば、インターネット、他のＷＡＮ、ＬＡＮなど）上の既知のアドレスでスペース・マネージャを発見するために使用できるユニキャスト・メッセージング（たとえば、ＴＣＰで）を使用して発見を実行することもできる。ユニキャスト発見メッセージは、サービス通知を送るため既知のＵＲＩのスペース・サービスの要求を含むことができる。マルチキャスト発見プロトコルをおよびユニキャスト発見プロトコルは、メッセージ・レベルで定義され、そのため、発見に参加しているデバイスがＪａｖａをサポートしていようと他の特定の言語をサポートしていようと関係なく使用することができる。
【０１８８】
発見プロトコルを使用すると、分散コンピューティング環境内のクライアントをサポートするサーバ・コンテンツを拡散することとは独立にクライアントを拡散させることが容易にできる。たとえば、モバイル・クライアントは、その初期デフォルト・スペースをそのローカル・プラットフォームに組み込むことができる。デフォルト・スペースで通知されたローカル・サービスに加えて、モバイル・クライアントは、発見プロトコルにアクセスするためのサービスやスペースサーチ・エンジンにアクセスするためのサービスなど、追加スペースをサーチするサービスを備えることができる。
【０１８９】
一実施形態では、分散コンピューティング環境のスペース発見プロトコルは、一組のＸＭＬメッセージとその応答を定義し、クライアントが以下のことを行えるようにする。
・ ネットワーク・インターフェース上でプロトコル定義スペース発見メッセージをブロードキャストする。
・ リスナーから、それらのリスナーが表す候補スペースを記述するＸＭＬメッセージを受け取る。
・ クライアントが選択されたスペースのアドレスを知らなくても、発見されたスペースの１つをデフォルトとして選択する。
・ そのアドレスなど選択されたスペースに関する情報を取得し、クライアントが後で発見プロトコルの外部の手段により同じスペースを見つけることができるようにする（これは、後でクライアントがローカルでなくなったがまだクライアントに関わっているスペースにアクセスする場合に役立つ）。
【０１９０】
いくつかの実施形態では、マルチキャストおよびユニキャスト発見プロトコルはＩＰネットワークを必要とする。これらの発見プロトコルは、ＩＰネットワーク対応のデバイスの必要条件を満たすが、これらの発見プロトコルで直接サポートされないデバイスも多くある。分散コンピューティング環境でスペースの発見にこのようなデバイスの要求条件を満たすには、事前発見プロトコルを使用してＩＰネットワーク対応のエージェントを見つける。事前発見プロトコルは、ネットワーク・エージェントを要求する非ＩＰネットワーク・インターフェース上でメッセージを送るデバイスを含むことができる。ネットワーク・エージェントは、それ自身とデバイスとの間の接続を設定する。デバイスとエージェントの間の接続が設定されると、エージェントはこれがエージェントとして使用されるデバイスのためにＩＰネットワーク上で発見プロトコルに参加する。ネットワーク・エージェントは、さらに、一般に分散コンピューティング環境にデバイスを接続するためのインターフェースとなる。たとえば、発見されたスペース内で通知されるサービスを実行するためにデバイスのためにエージェント内にゲートを構築することができる。「ブリッジ」のセクションを参照されたい。
【０１９１】
クライアントが分散コンピューティング環境でスペースを特定するための方法としては他に、他のスペース内でスペースを通知する方法がある。スペースはサービスなので、他のサービスと同様、他のスペース内で通知を受けることができる。図１８に示されているように、クライアント２００ｂは、第２のスペース２０４ｂについて第１のスペース２０４ａ内で通知２０６を見つける。スペース２０４ｂは、次に、追加スペースへの通知を含む。サービス（スペースを実装する）はさらにクライアントとしても機能するため、スペースは通知を交換するかまたは一緒に連鎖し、図１９に示されているように、ベースの連合を実現する。分散コンピューティング環境にはスペースをいくつでも含めることができる。スペースの個数とトポロジは、実装に依存する。たとえば、ＩＰネットワーク上に実装されたスペースは、それぞれ異なるサブネットに対応していることがある。
【０１９２】
クライアントでスペースを特定する第３の方法として、図１８に示されているように、サービス２０８を実行する方法がある。サービス２０８は、実行され、その結果としてスペース・サービスのサービス通知を返す。サービス通知はＸＭＬ文書であり、分散コンピューティング環境はインターネットを含むため、サービス２０８はＷｅｂベースのサーチ・ツールとすることができる。このようなサービスの一例として、図４で説明しているスペース・ルックアップ・サービスがある。一実施形態では、分散コンピューティング環境内のスペースはＷｅｂページとして実装することができる。それぞれのＷｅｂページ・ベースは、Ｗｅｂページを分散コンピューティング環境内のスペースとして識別するためにサーチできるキーワードを含むことができる。スペースは、その他のサーチ可能なキーワードを含むだけでなく、さらにスペースを定義することができる。クライアントは、サーチ・サービス２０８に接続し、キーワードをＸＭＬメッセージの形式でサーチ・サービスに供給する。サーチ・サービスは、クライアントからキーワードを受け取りそのキーワードをインターネットサーチ・エンジンに送るが、これは従来のサーチ・エンジンまたはサードパーティ製のサーチ・エンジンでもよい。サーチ・サービスは、ＸＭＬメッセージとして直接にまたは結果スペースへの参照によりインターネットサーチ・エンジンからクライアントに結果を返す。結果は、サーチ要求とマッチするスペースのＵＲＩである。それとは別に、サーチ・サービスは、サーチによって識別されたスペースにコンタクトし、このようなそれぞれのスペースについてサービス通知を取得し、ＸＭＬメッセージとして直接に、または結果スペースでの参照により、スペース・サービス通知をクライアントに返すことができる。クライアントは、その後、サーチ結果からスペースを選択し、ゲート（それ自身によりまたはプロキシを通じて）を構築し、選択したスペースにアクセスすることができる。選択されたスペースにアクセスした後、クライアントはそのスペース内のサービス通知をルックアップし、これによりスペースが追加される。
【０１９３】
上述のように、スペースはＸＭＬペースのＷｅｂサイトとすることができ、そのため、インターネットＷｅｂ上でサーチ・メカニズムによりサーチすることができる。スペースはインターネットサーチ可能キーワードを含むことができる。小型クライアント・デバイスなどいくつかのデバイスでは、インターネット・ブラウザをサポートしていない。ただし、このようなデバイスであっても、分散コンピューティング環境内でスペースについてインターネット・サーチを実行することができる。デバイスは、キーワードの列を受け付けるプログラムを備え、これらのキーワードはサーバ上のプロキシ・プログラムに送られる（たとえば、サーチ・サービス）。プロキシは、これらのキーワード列をブラウザ・ベースのサーチ機能に送り（たとえば、インターネットサーチ機能）、サーチを実行することができる。プロキシは、サーチの出力を受け取ってサーチ結果の各ＵＲＩを表すストリング（たとえば、ＸＭＬストリング）に解析し、応答ストリングをクライアントに送り返す。したがって、クライアントは、Ｗｅｂブラウザなどのプログラムをサポートしていなくてもインターネットを介してスペースを特定することができる。さらに高機能のデバイスでは、プロキシの使用を避けて、インターネット・ベースのルックアップ・サービスを直接開始することができる。
【０１９４】
クライアントはスペースを特定するための第４の方法は、新規作成された空のスペースまたは既存のスペースが生成されるときには生成されたスペースに関する情報を取得または受け取る方法である。既存のスペースは、生成元のスペースと同じ機能（たとえば、同じＸＭＬスキーマ）を持つ空のスペースを生成するインターフェースを備えることができる。スペースの生成については以下で詳述する。
【０１９５】
スペースのクライアントはスペース・サービスの通知を見つけると、スペースのそのクライアントは他のサービスの場合と同様にスペース・サービスを実行できる。スペース・サービスのクライアントは別のサービスでもよいことに注意されたい（たとえば、スペース内で通知すること求めるサービス）。一実施形態では、図２０に示されているように、スペース・サービスを実行するため、スペースのクライアントはまずスペースに対し認証サービスを実行し、３００に示されているように、認証証明書を取得する。認証サービスは、スペース・サービスのサービスを通知で指定することができる。スペースのクライアントは、３０２に示されているように、認証証明書、スペースのＸＭＬスキーマ（スペースのサービス通知からの）、およびスペースのＵＲＩ（スペースのサービス通知からの）を使用して、スペースのゲートを構築する。次に、スペースのクライアントは、そのゲートを使用してメッセージをスペース・サービスに送ることによりスペース・サービスを実行する。第１のそのようなメッセージは３０４に示されている。
【０１９６】
認証を採用する実施形態では、スペース・サービスがクライアントから第１のメッセージを認証証明書が埋め込まれた状態で受け取ったときに、スペース・サービスは同じ認証サービス（スペース・サービスのサービス通知で指定されている）を使用して、クライアントを認証し、３０６で示されているように、その素性を確定する。スペース・サービスは、クライアントの能力を判別し、３０８で示されているように、クライアントを認証証明書にバインドする。
【０１９７】
３１０に示されているように、スペースのクライアントは、メッセージをスペース・サービスに送ることによりさまざまなスペース機能を実行することができる。一実施形態では、スペースのクライアントがスペース・サービスに要求を送るときに、クライアントはその要求で認証証明証を渡し、スペース・サービスがクライアントの特定の能力について要求をチェックできるようにする。
【０１９８】
各スペースは、通常、サービスであり、スペース・サービスのコア機能を定義するＸＭＬスキーマを備える場合がある。ＸＭＬスキーマでは、スペース・サービスとのクライアント・インターフェースを指定する。一実施形態では、すべてのスペース・サービスは、基本レベルのスペース関係のメッセージを出すことができる。基本レベルのスペース機能は、ＰＤＡなどの小型デバイスをはじめとするほとんどのクライアントで使用できる基本的なスペース機能である。たとえば、より高機能なクライアントについては、機能を増やすことが望ましい場合がある。基本レベルのスペースの拡張は、スペースを通知するＸＭＬスキーマにさらにメッセージを追加することにより実現できる。たとえば、一実施形態では、基本レベルのメッセージは、通知に対して関係グラフを強制しない。たとえば、通知の階層をトラバースするメッセージはスペース拡張である。このような追加機能は、スペースの１つまたは複数の拡張をＸＭＬスペース・スキーマまたはスキーマ拡張を通じて提供することができる。拡張されたスキーマは、基本スキーマを含むので、拡張スペースのクライアントもまた、基本スペースとしてスペースにアクセスすることができる。
【０１９９】
一実施形態では、基本スペース・サービスは、ＸＭＬドキュメントの一時的リポジトリを備える（たとえば、サービスの通知、実行中サービスの結果）。ただし、一実施形態の基本スペース・サービスは、スペース・コンテンツの永続性、スペース構造（たとえば、階層）のナビゲーションまたは作成、およびトランザクション・モデルをサポートする高度な機能に対応していない場合がある。永続性、階層、および／またはトランザクションをサポートするメカニズムは、ＸＭＬスキーマを拡張することによって実現される。拡張されたスペースはそれでも基本ＸＭＬスキーマを含むので、必要なのが、あるいはサポートできるのが基本スペースの機能だけの場合に、クライアントは拡張スペースを基本スペースとして取り扱うことができる。
【０２００】
一実施形態では、基本スペースは一時的なものとすることができる。基本スペースは、さまざまな目的のために受け入れることができる。サービス・プロバイダは、さまざまなスペースでサービスを登録することができる。一実施形態では、サービスはスペース内の情報のパブリッシュ後継続的にリースを更新する必要がある。このような性質があることから、サービス通知は、多くの場合に再構築かつ／または再確認するという点で一時的なものである。ただし、スペース内に何らかの永続性を実現することが望ましい。たとえば、結果があるスペースは、一定期間結果が失われないようにしたいユーザに対しては何らかの永続性を提供できる。一実施形態では、クライアントが永続的ストアによって裏付けられているスペース内のオブジェクトを制御し、その永続性ストアのメンテナンスを管理することができるスペース・インターフェースを指定することにより永続性を実現することができる。永続性インターフェースは、永続性に関してインターフェースを定義するスペースの拡張ＸＭＬスキーマで指定することができる。
【０２０１】
一実施形態では、基本スペースは、ＸＭＬドキュメントがスペースに追加され、ストリングによって識別できるインターフェースを備える。基本スペースは、スペース内のさまざまな名前をつけられたＸＭＬドキュメントの階層を実現することはできない。階層のサポートが望ましい実施形態では、ユーザが階層を指定することができる追加インターフェースを定義するとよい（ＸＭＬスキーマを拡張する）。階層をナビゲートしたり、関係グラフを位置でナビゲートするように他のインターフェースを指定することもできる。ただし、他のユーザはそれでも、基本スペース・インターフェースを使用して、階層を使わずに、同じドキュメントにアクセスすることができる。拡張スペース・スキーマでは、他のスペースの構造に対するインターフェースも実現できる。
【０２０２】
拡張ＸＭＬスペース・インターフェースもまた、スペース・トランザクション・モデルについて実現することができる。たとえば、拡張スペースＸＭＬスキーマがＡＣＩＤトランザクションのインターフェースを指定する。ＡＣＩＤは、エンタプライズ・レベルのトランザクションの４つの特性を記述するために使用される頭字語である。ＡＣＩＤは、Ａｔｏｍｉｃｉｔｙ（原子性）、Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）、Ｉｓｏｌａｔｉｏｎ（独立性）、およびＤｕｒａｂｉｌｉｔｙ（耐久性）のそれぞれの頭文字をとったものである。原子性とは、トランザクションを完全に完了するか、または元に戻すかのいずれかであることを意味する。障害が発生した場合、すべての操作およびプロシージャを元に戻し、すべてのデータを前の状態にロールバックする必要がある。一貫性とは、トランザクションがシステムを一方の一貫性のある状態から他方の一貫性のある状態に変換することを意味する。独立性とは、各トランザクションが同時に発生する他のトランザクションとは独立に発生することを意味する。耐久性とは、完了したトランザクションが、たとえばシステムに障害が発生したときでも、内容を失うことなく恒久的であるということを意味する。他のトランザクション・モデルはさらに、拡張スペース・スキーマで指定することができる。
【０２０３】
拡張スペース・スキーマは、拡張されたスペースの特徴、機能性、または機能を使用するためのメッセージ・インターフェース（たとえば、ＸＭＬメッセージ）を指定するＸＭＬドキュメントとすることができる。スペースには、基本スキーマおよび複数のを拡張スキーマを用意できる。これにより、クライアントの認証に応じて、異なるレベルのサービスを異なるクライアントに簡単に提供することができる。
【０２０４】
スペースの永続性、構造、およびトランザクションの拡張のほかに、必要に応じて、他のスペース拡張機能も指定できる。たとえば、通知要素の読み込み、書き込み、または取り出しの機能、通知属性の読み込み、書き込み、または取り出しの機能、および通知イベントの通知メッセージのサブスクライブの機能など、要素または属性のレベルで通知を操作するための拡張機能を備えることもできる。スペースは仮想的にいくつの機能でも提供でき、必要に応じて、基本スキーマおよび拡張スキーマに配列することができる。一実施形態では、すべての基本スペースは通知の読み込み、書き出し、取り込み、およびルックアップの機能、さらにスペース・イベント・サブスクライブの機能を備える必要がある。さまざまなスペース機能を用意できる。いくつかの実施形態では、スペースとのセッションを確立するための機能を備えることができる。このような実施形態では、スペース機能のうちの残りの機能は、これが完了するまでに利用できない。他の実施形態では、セッションという概念がないか、またはオプションであるか、および／または実装に依存する。
【０２０５】
他のスペース機能として、スペースにサービス通知を追加したり、スペースからサービス通知を削除する機能もある。さらに、ＸＭＬドキュメントを追加または削除するスペース機能も用意できる（通知ではなく、おそらくスペース内の結果）。スペース・サービスは、アイテムの追加を許可する前にアイテムの一意性を検査する。たとえば、スペースに追加される各アイテムは、アイテムを識別し、そのアイテムの一意性を検査するために使用できるユーザ指定のストリングと関連付けることができる。
【０２０６】
一実施形態では、クライアントはスペース内で通知されるすべてのサービスのリスティング、ツリー、またはその他の表現を要求することができる。ユーザは、その後、通知をスクロールまたは操縦して、目的のサービスを選択する。また、スペースはキーワードまたはストリング名を与えることによりクライアントがサービスをサーチできるようにするルックアップ機能も備える。一実施形態では、スペース機能は、スペースに追加されているスペース・エントリをルックアップするためのメカニズムを備える。ルックアップ機能は、名前とマッチするストリング、またはワイルドカード、またはデータベース・クエリでルックアップすることができる。ルックアップ機能は、クライアントが１つ選択できる、またはさらに絞り込みサーチを実行できる複数のエントリを返す。一実施形態では、ルックアップ機能は特定のＸＭＬスキーマとマッチするサービス通知を特定するためのメカニズムを備える。クライアントは、スペース内でサーチ対象となる、特定のＸＭＬスキーマ、または特定のＸＭＬの一部を指定することができる。したがって、インターフェース機能に従ってスペース内でサービスをサーチすることができる。
【０２０７】
分散コンピューティング環境で提供できるスペース機能としては他に、サービスおよびクライアントがＸＭＬなどの型付けモデルに基づき一時的ドキュメントを見つけられるメカニズムがある。このメカニズムは、汎用の型付けドキュメント・ルックアップ・メカニズムである。一実施形態では、このルックアップ・メカニズムはＸＭＬに基づく。このルックアップ・メカニズムを使用すると、クライアントおよびサービスは、サービス通知を介したサービスを含めて、一般にドキュメントを見つけることができる。
【０２０８】
一実施形態では、スペース・ルックアップおよび応答メッセージのペアを使用することにより、クライアントおよびサービスがネットワーク一時ドキュメント・ストア（スペース）内に格納されているＸＭＬドキュメントを見つけられるようにできる。スペースは、さまざまなドキュメントを格納するために使用されるドキュメント・スペースである。一実施形態では、ドキュメントはＸＭＬドキュメントまたはＸＭＬでカプセル化された非ＸＭＬドキュメントである。スペースについては他のところでさらに詳述する。ルックアップ・メッセージは、サービス通知およびデバイス・ドライバ通知を含む、スペース内に格納されているあらゆる種類のＸＭＬドキュメント上で機能する。一実施形態では、クライアント（他のサービスでもよい）は別のところで説明しているように発見メカニズムを使用して、１つまたは複数のドキュメント・スペースを見つけることができる。その後、クライアントはスペース・ルックアップ・メッセージを使用して、スペース内に格納されているドキュメントを特定することができる。
【０２０９】
分散コンピューティング環境には、サービスおよびクライアントがＸＭＬドキュメントの発行に関するイベントのサブスクライブおよび受取を行うためのメカニズムが備えられる。イベントは、スペースなどの一時的ＸＭＬドキュメント・リポジトリにＸＭＬドキュメントをパブリッシュしたり、そこから除去したりする機能を含むことができる。一実施形態では、イベントは、他のＸＭＬドキュメントを参照するＸＭＬドキュメントである。
【０２１０】
一実施形態では、スペース・イベント・サブスクライブおよび応答メッセージのペアを使用することにより、クライアントおよびサービスがスペースに追加またはスペースから削除されるドキュメントに関するイベントのサブスクライブを行える。一実施形態では、他のところで説明しているリース・メカニズムを使用して、イベント・サブスクライブをリースすることができる。一実施形態では、リースが取り消されるかまたはその有効期限が切れたときにサブスクライブを取り消すことができる。一実施形態では、サブスクライブ上のリースを更新する際に、サブスクライブを更新できる。
【０２１１】
一実施形態では、イベント・サブスクライブ・メッセージに、ドキュメント・マッチング・メカニズムとして使用できるＸＭＬスキーマを含めることができる。スキーマとマッチするドキュメントはサブスクライブによって取り扱われる。一実施形態では、スペースに追加され、ＸＭＬスキーマとマッチするドキュメントは、スペース・イベント・メッセージを生成する。
【０２１２】
また、スペースに何かを追加したときやスペースから何かを削除したときにその通知を取得するためクライアントが登録できる（または登録解除できる）スペース機能を提供することができる。スペースは一時的コンテンツを格納することができ、これはスペースに追加されたまたはスペースから削除されたサービスを反映する。たとえば、サービスが利用できるようになったときまたは利用できなくなったときにそのことをクライアントに通知するメカニズムを用意することができる。クライアントは、このような通知を取得するためイベント・サービスに登録することができる。一実施形態では、クライアントは指定されたストリングとマッチする名前または指定されたスキーマ（またはスキーマ部分）とマッチするスキーマを持つサービスをスペースに追加したりスペースから削除したりするときにそのことを通知するように登録することができる。したがって、スペース・イベント通知機能に登録するクエリは、上述のサービス・ルックアップ機能のものと同じであるか類似している。
【０２１３】
図４３は、一実施形態による、分散コンピューティング環境での、サーチ・サービスを使用するスペースのサーチを示す流れ図である。一実施形態では、デバイスのクライアントが、同一のまたは異なるデバイスのサーチ・サービスと対話して、データの格納および／または取出のためのスペース（すなわち、ネットワーク・アクセス可能オブジェクト・リポジトリ）を見つけることができる。この対話の実施形態を、さらに図４６ａおよび４６ｂに示す。クライアント１１０は、２０００に示されているように、サーチ・サービス２１０２にサーチ要求を送ることができる。サーチ要求には、スペースからサーチされる１つまたは複数の所望の特性を含めることができる。一実施形態では、サーチ要求が、拡張マークアップ言語（ＸＭＬ）などのデータ表現言語で表現される。一実施形態では、サーチ要求の所望の特性に、１つまたは複数のキーワードを含めることができる。クライアントに、キーワードを受け入れ、それらをサーチ・サービス２１０２に送るプログラム２１００を含めることができる。一実施形態では、キーワードを、ＸＭＬメッセージ２１０６としておよび／または本明細書に記載のゲートを使用して送ることができる。
【０２１４】
サーチ要求に基づいて、サーチ・サービス２１０２が、サーチを行うことができる。図４６ａに示された実施形態では、サーチを行う際に、サーチ・サービス２１０２が、インターネット・サーチ・エンジンなどのサーチ・エンジン２１０４と対話することができる。この形で、サーチ・サービスが、クライアントとサーチ・エンジンの間のプロキシとして働くことができる。プロキシは、ウェブ・ブラウザの使用またはサーチ結果のセット全体の受取によるなど、サーチ・エンジンとの対話のためのリソースを有しない小さいデバイスのクライアントに特に望ましい可能性がある。サーチ・エンジンに、ブラウザ・アクセス可能なインターネット・サーチ・エンジンなどの、ネットワーク・アクセス可能なサードパーティ・サーチ・エンジンを含めることができる。図４６ｂに示された実施形態では、サーチ・サービス２１０２に、サーチ・エンジン２１０４を含めるか、他の形で密に結合することができる。２００２に示されているように、サーチ・サービス２１０２は、サーチ要求を、データ表現言語（たとえばＸＭＬ）から、サーチ・エンジン２１０４によって使用可能なテキスト・フォーマットに変換することができる。２００４に示されているように、サーチ・サービス２１０２は、変換されたサーチ要求をサーチ・エンジン２１０４に送ることができる。
【０２１５】
２００６に示されているように、サーチをサーチ・エンジン２１０４によって実行して、サーチ結果を生成することができる。サーチ結果には、たとえば２１２０ａ、２１２０ｂ、および２１２０ｃなどの１つまたは複数の結果のスペースの位置（たとえばＵＲＩ）を含めることができる。一実施形態では、スペースに、インターネット２１１０を介してアクセス可能な１つまたは複数のウェブ・ページを含めることができる。ウェブ・ページには、ウェブ・ページを分散コンピューティング環境内のスペースとして識別する識別キーワードを含めることができる。サーチ要求に、このキーワードを、スペースについて望まれる特性を記述する１つまたは複数の他のキーワードと共に含めることができる。
【０２１６】
２００８に示されているように、サーチ・サービス２１０２は、サーチ・エンジン２１０４からテキスト・フォーマットでサーチ結果を受け取ることができる。２０１０に示されているように、サーチ・サービス２１０２は、テキスト・フォーマットのサーチ結果をデータ表現言語（たとえばＸＭＬ）のサーチ結果に変換し、その結果をクライアント１１０に送る。一実施形態では、サーチ・サービス２１０２が、結果のスペース２１２０ａ、２１２０ｂ、および２１２０ｃのそれぞれに関するサービス通知を得ることができる。各サービス通知に、めいめいのスペースにアクセスするのに使用可能な情報が含まれる。サーチ・サービス２１０２は、これらの通知への参照（たとえばＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）または通知自体をサーチ結果として送って、２０１２に示されているように、クライアントが、めいめいの位置の結果のスペースにアクセスできるようにする。一実施形態では、結果位置のスペースに、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）が含まれる。
【０２１７】
一実施形態では、サーチ結果をクライアント１１０に送る際に、サーチ・サービス２１０２が、サーチ結果を結果のスペース（すなわち、ネットワーク・アクセス可能なストレージ・リポジトリ）に格納し、その結果スペースのアドレスをクライアント１１０に送ることができる。クライアント１１０は、適当な時に、結果スペース内のサーチ結果にアクセスすることができる。結果スペースの使用は、結果のセット全体を受け取って表示するリソースを有しない小さいクライアントに特に望ましい。この情況では、一実施形態によれば、ユーザが、異なるクライアントを使用して結果スペースから結果を読み取ることができる。
【０２１８】
いくつかの実施形態では、サーチ・サービスが、サーチ・サービスを介して見つけることができるスペースを制限またはフィルタリングするか、分散コンピューティング環境内の少数のサポートされるスペースだけをサーチするようにクライアントを制限することができる。許可されるサーチの範囲は、クライアント認証に従って決定することができる。
【０２１９】
図４７は、一実施形態の分散コンピューティング環境での、スペース内のドキュメントのサーチを示す流れ図である。一実施形態では、クライアントが、サーチメッセージを介してスペースと対話して、スペース内のドキュメントを見つけることができる。２２００に示されているように、クライアントは、ルックアップ・メッセージをスペースに送ることができる。スペースには、１つまたは複数のドキュメントを格納するために動作可能であるネットワーク・アドレッシング可能記憶場所を含めることができる。格納されたドキュメントは、拡張マークアップ言語（ＸＭＬ）などのデータ表現言語で表現することができる。ルックアップ・メッセージが格納されたドキュメントの所望の特性を指定することができる。一実施形態では、ドキュメントに、ＸＭＬサービス通知およびＸＭＬデバイス通知ならびに汎用ＸＭＬドキュメントを含めることができる。たとえば、スペース内のＸＭＬドキュメントに、ＸＭＬで表現された、サービスの結果を含めることができる。
【０２２０】
２２０２に示されているように、ルックアップ・メッセージにマッチするドキュメントのセットを発見することができる。発見されるドキュメントには、ルックアップ・メッセージで指定された所望の特性にマッチするすべての格納されたドキュメントを含めることができる。０個以上の格納されたドキュメントが、所望の特性にマッチする可能性がある。一実施形態では、ルックアップ・メッセージに所望の名前を含めることができる。一実施形態では、ルックアップ・メッセージで指定された所望の名前に、１つまたは複数のワイルドカードを含めることができる。発見されるドキュメントのそれぞれが、所望の名前とマッチする名前を有することができ、名前によって、スペース内で発見されたドキュメントを識別することができる。一実施形態では、ルックアップ・メッセージに、データ表現言語で表現された所望のスキーマを含めることができる。発見されるドキュメントのそれぞれが、所望のスキーマとマッチするスキーマまたはスキーマの一部を有することができる。一実施形態では、ルックアップ・メッセージに、所望の名前および所望のスキーマの両方を含めることができる。この場合には、発見されるドキュメントのセットに、所望の名前とマッチする名前を有する発見されたドキュメントと、所望のスキーマとマッチするスキーマを有する発見されたドキュメントの両方を含めることができる。一実施形態では、ルックアップ・メッセージに、所望の名前も所望のスキーマも含めないことができる。この場合には、ルックアップ・メッセージは、本質的に、スペース内のすべてのドキュメントに関する要求であり、発見されるドキュメントのセットに、スペースに格納されたドキュメントの実質的にすべてを含めることができる。
【０２２１】
マッチするドキュメントが見つかった後に、２２０４に示されているように、スペースが、クライアントにサーチ応答メッセージを送ることができる。一実施形態では、サーチ応答メッセージに、発見されたドキュメントの名前を含めることができる。一実施形態では、サーチ応答メッセージに、０個以上の発見されたドキュメントのそれぞれに関する通知メッセージを含めることができる。各通知に、めいめいの発見されたドキュメントを得るか、ドキュメントが通知するリソース（たとえばサービス）にアクセスするために、クライアントによって使用可能な情報を含めることができる。一実施形態では、各通知に、めいめいの発見されたドキュメント（または、ドキュメントによって通知される、サービスなどのリソース）にアクセス可能である場所のＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができる。一実施形態では、発見されるドキュメントの少なくとも１つを、サービスに関する通知とすることができる。サービスに関する通知に、スキーマを含めることができ、このスキーマによって、サービスの１つまたは複数の関数を呼び出すのに使用可能な１つまたは複数のメッセージが指定される。通知は、ＸＭＬなどのデータ表現言語で表現することができる。
【０２２２】
一実施形態では、ルックアップ・メッセージおよびサーチ応答メッセージが、ＸＭＬなどのデータ表現言語で表現される。スペースに関するスキーマで、ルックアップ・メッセージおよびサーチ応答メッセージの形式を指定することができる。一実施形態では、このメッセージの対を、下記のようにＸＭＬで表現することができる。
ルックアップ・メッセージ

サーチ応答メッセージ

【０２２３】
ＸＭＬルックアップ・メッセージでは、「名前」を、ストリング値とすることができ、名前によって、スペース内の一意の識別子を指定することができる。ワイルドカードが使用される場合には、識別子が、一意でない場合がある。「ＡｄｖＳｃｈｅｍａ」は、ルックアップがマッチすると期待されるスキーマである。一実施形態では、両方のフィールドが任意選択である。ＸＭＬルックアップ応答メッセージでは、「Ａｄｖ」が、０個以上のマッチする通知のグループであり、「Ｎａｍｅｓ」が、通知に対応する名前のグループである。
【０２２４】
図４８は、一実施形態による、分散コンピューティング環境での、スペース内に格納された通知を使用する、サービスのアドレッシングを示す流れ図である。一実施形態では、２３００に示されているように、サービスが、スペース内でサービス通知をパブリッシュすることができる。スペースは、拡張マークアップ言語（ＸＭＬ）ドキュメントなどのドキュメントが格納されるネットワーク・アドレッシング可能記憶場所とすることができる。通知のパブリッシュは、この詳細な説明の他所で詳細に説明する。一実施形態では、通知に、サービスのＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）およびスキーマを含めることができる。ＵＲＩでは、サービスにアクセスできるネットワーク・アドレスを指定することができ、スキーマでは、サービスの１つまたは複数の関数を呼び出すのに使用可能である１つまたは複数のメッセージを指定することができる。一実施形態では、スキーマおよびメッセージを、ＸＭＬなどのデータ表現言語で表現することができる。２３０２に示されているように、クライアントは、スペースにアクセスし、通知を見つけることができる。たとえば、クライアントは、発見サービスを使用してスペースを見つけ、その後、図４７に示されたものなどのルックアップ・サービスを使用して、スペース内の通知を見つけることができる。
【０２２５】
一実施形態では、通知に、特定のサービスにアクセスするためにクライアントが必要とする情報の実質的にすべてが含まれる。２３０４に示されているように、クライアントは、スペースから通知を読み取ることができる。一実施形態では、クライアントは、通知内のＵＲＩおよびスキーマを使用して、サービスにアクセスするためのゲートを構築することができる。２３０５に示されているように、クライアントは、ＵＲＩにあるサービスにスキーマで指定された第１のメッセージを送って、サービスの１つまたは複数の関数を呼び出すことができる。それに応答して、２３０８に示されているように、サービスの関数を呼び出すことができる。一実施形態では、サービスが、第２のメッセージ（たとえば、呼び出された関数の結果を含むメッセージ）をクライアントに送ることができ、この第２のメッセージは、そのサービスのスキーマで指定されたものである。
【０２２６】
スペースのクライアントが、ＸＭＬドキュメント（たとえばサービス通知）がスペースに追加または除去される時に通報されるように契約する時に、そのクライアントは、通報のためのこの契約に対するリースを得ることができる。リースを用いて、スペース・サービスが、特定のクライアントへの通報の発送を継続するかどうかを知ることができる。たとえば、通知機能に対するリースは、更新されない場合に、ある時間の後に満了するようにすることができる。クライアントがスペースとのアクティブ・セッションを確立している間は、リースが不要である可能性があることに留意されたい。クライアントは、スペースとのアクティブ・セッションを切断した後に、対応するリースがアクティブのままである限り、そのイベント契約に従ってイベント通報の受取を継続することができる。下のリースの節を参照されたい。
【０２２７】
クライアントは、異なる型のイベントに対して契約することができる。例は、上で説明したように、スペースに追加または除去されるサービス通知である。クライアントは、クライアント（またはほかの誰か）によって開始されたサービスからの結果がスペースに置かれる時にも通報を受けることができる。たとえば、クライアントとサービスが、サービスの結果を参照する名前を相互に選択することができる。クライアントは、選択された名前によって参照される結果がスペースに追加される時にイベントを受け取るために、結果がポストまたは通知されるスペース・サービスに登録することができる。
【０２２８】
スペースは、クライアントが契約することができる異なる型のイベントを生成することができる。スペース変更の合成物として、イベントを、そのようなイベントについて契約したクライアントおよびサービスに対して作ることができる。一実施形態では、２つの主なスペース・イベント・カテゴリすなわち、スペースに関するカテゴリ（通知の挿入および除去）と、通知に対する変更を示すのに使用されるカテゴリ（要素または属性の追加、除去、変更）を設けることができる。どのイベントがサポートされるかは、スペースのＸＭＬメッセージ・スキーマで示すことができる。
【０２２９】
下記のイベントは、スペース・イベントまたは通知イベントを示すためにスペース・サービスによって作られる可能性があるイベントの例である。
【０２３０】
【表１】

【０２３１】
イベントは型付けされる。いくつかの実施形態では、スペースによってサポートされるイベント機能を使用すると、イベント・リスナーがたとえば、Ｊａｖａクラス（またはＸＭＬの型）階層を利用することができる。たとえば、ＡｄｖＥｌｅｍｅｎｔＥｖｅｎｔが発生するのを待つことで、リスナーは型ＡｄｖＥｌｅｍｅｎｔＥｖｅｎｔおよびそのサブクラス（ＸＭＬ型）のすべてのイベントを受け取る。したがって、この例では、要素変更に関係するすべてのイベントは（通知の挿入および削除はないが）、受取される。
【０２３２】
他の例では、トップレベルのイベント・クラスまたは型、たとえば、ＳｐａｃｅＥｖｅｎｔのサブスクライブまたは待機する際に、すべてのスペース・イベントが受取される。イベント・クラスの型は、たとえば、Ｊａｖａのｉｎｓｔａｎｃｅ　ｏｆ演算子またはＸＭＬ型付けシステムを介して区別することができる。
【０２３３】
イベントには、影響を受ける通知または要素へのＵＲＩが含まれる。たとえば、ＡｄｖｅｒｔｉｓｅｍｅｎｔＥｖｅｎｔおよびそのすべてのサブクラスは影響を受ける通知への参照（たとえば、ＵＲＩまたはＵＲＬ）を含む。ＡｄｖＥｌｅｍｅｎｔＥｖｅｎｔおよびそのサブクラスは、影響を受ける要素の名前について調査することができる。たとえば、前の要素値（ＵＲＩまたはＵＲＬ）は、ＡｄｖＥｌｅｍｅｎｔＲｅｍｏｖｅＥｖｅｎｔおよびＡｄｖＥｌｅｍｅｎｔＶａｌｕｅＣｈａｎｇｅＥｖｅｎｔから利用することができる。
【０２３４】
一実施形態のスペース・イベントの型階層を図２１に示した。型は、ＸＭＬで定義し、ＪａｖａやＣ＋＋などの他の適当なオブジェクト指向言語で使用することができる。
【０２３５】
スペースは、クライアントがスペース内で通知されたサービスをインスタンス化する機能を備える。サービスのインスタンス化は、クライアントがサービスを実行できるよう行われる初期化である。サービスのインスタンス化の一実施形態を図２２に示す。サービスをインスタンス化するために、クライアントはまず、３２０で示されているように、スペース内でパブリッシュされたサービス通知のうちから１つ選択する。クライアントは、スペースに用意されているルックアップ機能などのさまざまな機能を使用して、スペース内のさまざまな通知をルックアップすることができる。次に、クライアントは、３２２に示されているように、スペースに対しサービスのインスタンス化を要求する。
【０２３６】
一実施形態では、サービス・インスタンス化は、以下の操作を含む。クライアントがスペース・サービスに対し選択されたサービスのインスタンス化を要求した後、３２２に示されているように、スペース・サービスは、３２４に示されているように、クライアントが要求されたサービスをインスタンス化できることを確認する。スペース・サービスは、クライアントのメッセージに含まれる認証証明書を調べることによりこの確認を実行する。認証証明書は、スペース・サービスとのセッションを確立したときにクライアントが受け取る証明書である。スペース・サービスは、クライアントがそのクライアントに指示されているクライアントの認証証明書および能力に応じて要求されたサービスをインスタンス化できるかどうかを検証する。以下の「認証とセキュリティ」の項を参照のこと。
【０２３７】
クライアントが承認されていると仮定すると、スペース・サービスはさらに、３２６に示されているように、クライアントによって指定されているリース要求時間でクライアントに対するサービス通知のリースを取得することができる。リースについては以下で詳述する。スペース・サービスは、３２８に示されているように、割り当てられたリースとサービスのサービス通知を含むメッセージをクライアントに送る。一実施形態では、クライアントはサービス通知で指定された認証サービスを実行し、３３０で示されているように、認証証明書を取得する。認証サービスの詳細については、「認証とセキュリティ」の項を参照のこと。次に、３３２で示されているように、クライアントはサービスのためにゲートを構築する（たとえば、認証証明書と通知からのＸＭＬスキーマおよびサービスＵＲＩを使用する）。「ゲート」の項を参照のこと。クライアントとスペース・サービスとの上述の通信は、分散コンピューティング環境のＸＭＬメッセージングを使用して実行される。その後、クライアントは、構築されたゲートとＸＭＬメッセージングを使用してサービスを実行する。サービスは、同様に、ＸＭＬメッセージによるクライアントとの通信用にサービス・ゲートを構築する。
【０２３８】
まとめとして、スペースの使用例を以下で説明する。クライアントは、スペース・サービスにアクセス（たとえば、接続）することができる。（サービスは、スペースにアクセスするかまたはその他の方法でスペースを使用するためにクライアントとして機能する。）スペース・サービスは、１つまたは複数のサービス通知および／またはその他のコンテンツス・ペース内に格納し、サービス通知のそれぞれが、対応するサービスにアクセスし、実行するために使用できる情報含む。スペース・サービスは、スペース・サービスの機能を呼び出すために使用できる１つまたは複数のメッセージを指定するスキーマを備えることができる。たとえば、スキーマはスペースから通知を読み込み、スペース内で通知をパブリッシュするメソッドを指定できる。スキーマおよびサービス通知は、拡張可能マークアップ言語（ＸＭＬ）などのオブジェクトを表現言語で表すことができる。スペース・サービスにアクセスする場合、クライアントはＸＭＬメッセージ（スキーマで指定されている）などの情報をインターネット・アドレスにあるスペース・サービスに送る。スペース・サービスにアクセスする際に、クライアントはスペースに格納されている１つまたは複数のをサービス通知をサーチする。クライアントは、スペースからサービス通知の１つを選択できる。一実施形態では、クライアントは、スペースから目的のサービス通知を選択した後インスタンス化要求をスペースに送る。目的のサービスに対するリースを取得し、リースおよびスペース・サービスによって、選択されたサービス通知をクライアントに送る。その後、クライアントは目的のサービスに対するアクセスのためのゲートを構築する。目的のサービスをクライアントのために実行できる。
【０２３９】
スペース・サービスによって提供される機能としてはほかに、空のスペースの生成または作成の機能がある。このスペース機能を使用する際に、クライアント（他のクライアントへのサービスであってもよい）は新しいスペースを動的に作成することができる。一実施形態では、このスペース機能は、生成元のスペースと同じ機能（同じＸＭＬスキーマまたは拡張スキーマ）を持つ空のスペースを生成するインターフェースを備えることができる。この機能は、結果に対しスペースを（たとえば、動的に）生成する場合に使用できる。たとえば、クライアントは、サービスで結果を生成されたスペースに置くかまたは結果を生成されたスペースで通知するよう要求するスペースを生成することができる。クライアントは、生成されたスペースのＵＲＩおよび／または認証証明書をサービスに渡す。または、サービスは、結果に対しスペースを生成し、生成されたスペースのＵＲＩおよび／または認証証明書をクライアントに渡す。いくつかの実施形態では、スペースがいったん生成されると、他のスペースと同様に、ここで説明したスペースを発見メカニズムのうち１つまたは複数を使用して発見することができる。
【０２４０】
他のスペース内のインターフェースを介してスペースを作成するメカニズム（たとえば、スペース生成機能）を使用して、新しいスペースを効率よく作成することができる。たとえば、一実施形態では、格納用の元のスペースで使用しているのと同じ機能を使用して、生成されたスペース用の記憶域を割り当てることができる。また、生成されたスペースは共通サービス機能を元の（または親の）スペースと共有することができる。たとえば、新しいＵＲＩを新しいスペースに割り当てることができる。一実施形態では、新しいＵＲＩは元のスペースと共有される共通スペース機能へのリダイレクションとすることができる。したがって、新しく生成されたスペースは元のスペースと同じサービス・コードまたはその一部を使用することができる。
【０２４１】
スペース機能はさらに、たとえば、スペースのさまざまなセキュリティ・ポリシーおよびその他の管理機能を更新するためのセキュリティ管理機能を備える。たとえば、通知の個数および経過時間を、ルート・スペース・サービスにより制御し監視することができる。旧い通知を収集して処分することができる。たとえば、通知を旧いとみなすことができる場合については「リース」の項を参照のこと。スペースを実装するサービスは管理者の制御の下にある。管理者は、サービスに依存する形でポリシーを設定することができる。スペースで機能はさらに、空のスペースを削除する機能を備える。
【０２４２】
いくつかのスペースでは、モバイル・クライアントなどのある種のクライアントの拡散をさらにサポートする機能またはサービスを備えることができる。たとえば、モバイル・クライアントが発見プロトコルなどにより発見できるスペース内のサービスは、モバイル・クライアントに対し次のようにサポートする
・　クライアントに対し一時的ネットワーク・アドレスを割り当て管理する。
・　クライアントに対しメッセージ通信をプロキシに通す。
・　追加スペースに対しサーチ機能を用意する。たとえば、サービスにより、クライアントは単純なインターフェースを介してキーワードを指定することができる。その後サービスは、ここで詳述しているように、Ｗｅｂサーチ・エンジンでそのキーワードを使用して、Ｗｅｂ上でスペースをサーチする。他の実施形態では、サーチ・サービスは、クライアントを分散コンピューティング環境内でごく少数のサポートされているスペースをサーチすることに制約する。
【０２４３】
前に述べたように（図９および付属の文章を参照）、スペースはクライアントによって実行されるサービスからの結果を格納する便利なメカニズムを提供する。結果にスペースを使用する際に、小型クライアントはサービスを実行した結果をバラバラにして受け取ることができる。いくつかのサービスでは、大量の結果が生成されることがある。スペースを使用してサービスからな結果を格納することにより、一度に全部の結果を受け取るだけのリソースがないクライアントでもそのサービスを使用することができる。さらに、スペースを使用して結果を格納することにより、大量の結果が返されるときに高速な使用中サーバ上で実行されているサービスを低速なクライアントとの直接的な対話操作から解放することができる。したがって、サービスをすぐに解放することができ、他のクライアントで使用できる。
【０２４４】
スペースは、異なるクライアントにより、かつ／または異なるときに、結果にアクセスするための便利なメカニズムを備える。たとえば、クライアントは結果をまるごとは使用できない場合があるが、ユーザはその結果にアクセスできる他のクライアントを後で使用してその結果の残り部分にアクセスすることを望む。たとえば、結果には、株式市況や、現在の株価の表示（ＰＤＡからアクセス可能）、および株価チャートの表示（後でラップトップからアクセス可能）などがある。また、結果に対し分散コンピューティング環境でスペースを使用すると、クライアントは一方のサービスの結果を他方のサービスに供給することができ、しかも、結果を最初にダウンロードする必要がない。たとえば、上の株式市況の場合、ＰＤＡはチャートを他のサービスに送り、そこでチャートを印刷することができ、ＰＤＡでチャート自体をダウンロードする必要はない。したがって、結果スペースは、クライアントが結果を処理または受け取らずに、他のクライアントまたはサービスに渡すためのメカニズムを提供する。
【０２４５】
異なる実施形態では、結果に対しスペースを使用する決定は、サービスによって命じられるか、クライアントによって命じられるか、および／またはクライアントによって要求される。サービスは、たとえば、その通知で、結果に対しスペースを使用することを提案することがある。一実施形態では、クライアントまたはサービスのいずれかが結果に対する新しいスペースを生成するか、または結果に対し既存のスペースを使用することができる。スペースの生成に関する説明を参照のこと。
【０２４６】
一実施形態では、結果に対しスペースを使用しても、必ずしも、サービスがすべての結果をそのスペースに入れる必要があるわけではない。サービスが生成する結果に対し代替えもありうる。たとえば、結果の一部または全部をメッセージによりインラインでクライアントに送ることができる。それとは別に、結果をスペースに入れ、その後、通知メッセージをクライアントに送り、結果を参照するようにできる（たとえば、結果へのＵＲＩや結果の通知へのＵＲＩを含める）。他のオプションとして、結果をスペースに入れ、スペースからのイベントにより通知を送る方法もある。たとえば、クライアントおよびサービスは何らかの特定の名前で結果を呼び出し、クライアントはそのように名前を付けられた結果をスペースに追加するときにイベントを受け取るため（上記のものなどのスペース機能を使用して）スペースに登録することができる。イベント通知に関する上の説明を参照のこと。
【０２４７】
したがって、サービスが結果をクライアントに返すいくつかの異なるメカニズムを分散コンピューティング環境内で使用することができる。実際の結果をＸＭＬメッセージ内の値でクライアントに返すか、または結果をスペースに置かれている実際の値（または、実際の結果に対する通知）による参照でクライアントに返され、クライアントはスペース内の結果を参照しているメッセージを受け取る。さらに、結果または結果通知をスペース内に置き、イベントでクライアントに通知できる。
【０２４８】
結果を処理する他のメカニズムでは、クライアントが供給する結果に対し他のサービスを指定する。たとえば、クライアントは、結果を出力するサービスを実行する場合、そのサービスに（たとえば、ＸＭＬメッセージングを介して）、結果を他のサービスに送ってさらに処理するよう指示することができる。これには、他のサービスを実行して結果を渡すために、クライアントが他のサービスに通知のＵＲＩを指示し、結果出力サービスが他のサービスへのゲートを生成するようにする必要がある。この例では、結果出力サービスは他のサービスのクライアントでよい。いくつかの実施形態では、クライアントはスキーマまたは事前構築されたゲートを結果出力サービスに送り、サービスにアクセスしてさらに処理する。さらに処理するサービスの例として、元のクライアントの結果を表示することができる表示サービスがある。この表示サービスは、クライアントと同じデバイスにあるか、またはそのようなデバイスと関連付けられる。
【０２４９】
図４１は、１実施形態による分散コンピューティング環境での新しいスペースの作成を示す流れ図である。１９００に示されているように、クライアントは、第１スペース・サービスにアクセス（すなわち接続）することができる（サービスは、スペースへのアクセスまたは他の使用のためにクライアントとして働くことができる）。第１スペース・サービスは、１つまたは複数のサービス通知および／または他のコンテンツを第１スペースに格納することができ、サービス通知のそれぞれに、対応するサービスへのアクセスおよび実行に使用可能な情報を含めることができる。第１スペース・サービスに、第１スペース・サービスの関数を呼び出すのに使用可能な１つまたは複数のメッセージを指定する第１スキーマを含めることができる。たとえば、第１スキーマによって、第１スペースから通知を読み取るメソッド、および第１スペースで通知をパブリッシュするメソッドを指定することができる。第１スキーマおよびサービス通知は、拡張マークアップ言語（ＸＭＬ）などのオブジェクト表現言語で表現することができる。第１スペース・サービスにアクセスする際に、クライアントは、ＸＭＬメッセージなどの情報（第１スキーマで指定される）を、第１インターネット・アドレス（たとえばＵＲＩ）にある第１スペース・サービスに送ることができる。第１スペース・サービスにアクセスする際に、クライアントが、第１スペースに格納された１つまたは複数のサービス通知をサーチすることができる。
【０２５０】
１実施形態では、スペースに、新しいスペースを作成する機能を含めることができる。１９０２に示されているように、クライアントが第１スペースのインターフェースに適当な要求を送ることによるなど、第２スペースの作成を要求することができる。１実施形態では、要求を、第１スペースの第１スキーマに従うＸＭＬメッセージとしてフォーマットすることができる。１９０４に示されているように、それに応答して、第２スペースを有する第２スペース・サービスを、第２インターネット・アドレス（たとえばＵＲＩ）などで、作成することができる。上と同様に、第２スペース・サービスに、第２スペース・サービスの関数を呼び出すのに使用可能な１つまたは複数のメッセージを指定する第２スキーマを含めることができる。第２スキーマに少なくとも第１スキーマを含めることができ、第２スキーマに追加の機能性も含めることができる。１実施形態では、第２スペースのスキーマに第１スキーマの一部を含めることができ、あるいは、第２スキーマを第２スペースの作成の時点で指定することができる。１９０６に示されているように、クライアントは、第２スキーマで指定されるメッセージの少なくとも１つを第２スペースに送ることによって、第２スペースにアクセスすることができる。
【０２５１】
スペースの作成に、セキュリティに関するものなどの管理初期化を含めることができる。１実施形態では、要求する側がスペースを作成した時に、当初は、要求する側だけが、作成されたスペースへのアクセスを許可される。そのような作成されたスペースへのアクセスの制限は、クライアントおよびサービスがその作成されたスペースを使用して結果を格納する時に有用になるであろう。作成されたスペースの認証およびセキュリティに関する情報については、「認証およびセキュリティ」の節を参照されたい。クライアントは、新しいスペースを作成した後に、作成されたスペースにアクセスするゲートを構築することができる。
【０２５２】
したがって、さまざまな実施形態で、結果を、複数の方法で、たとえば、メッセージ内で、スペース内で、クライアントがイベントを介して通報されるスペース内で、メッセージ内で返される通知を使用して、スペース内で返される通知を使用して、およびクライアントがイベントを介して通報されるスペース内で返される通知を使用して、クライアントに返すことができる。結果を返すこのさまざまな方法を、図４４ａから４４ｇに示す。この複数の方法の使用可能性によって、異なる機能を有するクライアントに関するものなどのさまざまな情況に関する分散コンピューティング環境の柔軟性および適応性を強化することができる。追加の柔軟性について、図４５に示されているように、結果を、別のサービスに効率的に渡すこともできる。
【０２５３】
図４４ａは、１実施形態による分散コンピューティング環境での、サービスの結果をスペースに格納する方法を示す流れ図である。２０５０に示されているように、クライアントは、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。サービスのスキーマによって、第１メッセージを含む、サービスの関数を呼び出すのに使用可能な、複数のメッセージを指定することができる。メッセージおよびスキーマは、ＸＭＬなどの、プラットフォーム独立および／またはプログラミング言語独立のデータ表現言語で表現することができる。
【０２５４】
２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の関数を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。２０５６に示されているように、サービスは、結果のセットをスペース内のロケーションに格納することができ、このスペースには、ネットワーク・アドレッシング可能なストレージ位置が含まれる。１実施形態では、結果のセットの格納の準備としてスペースを作成することができる。
【０２５５】
２０５８に示されているように、クライアントは、スペースから結果のセットにアクセスし、読み取ることができる。１実施形態では、第２のクライアント（すなわち、関数を呼び出すメッセージを送ったクライアントと異なるクライアント）が、スペースから結果のセットを読み取ることができる。この形で、第１のクライアントが結果の読取および表示などの作業を達成するのに十分なリソースを有しない可能性がある時に、ユーザが、第２のクライアントを使用して結果を読み取り、表示することができる。１実施形態では、クライアントが、サービスが結果のセットのアドレスを第２サービスに渡すことを要求するメッセージをサービスに送ることができ、その結果、第２サービスが、スペース内のアドレスから結果のセットを読み取ることができるようになる。第２メッセージに、第２サービスの通知のＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができ、この第２サービスの通知には、第２サービスにアクセスするのに使用可能な情報が含まれる。この形で、結果を、クライアントに渡さずに、第１サービスから第２サービスに効率的に渡すことができる。
【０２５６】
図４４ｂは、１実施形態による、サービスの結果をスペース内に格納し、イベントを使用してクライアントに通報する方法を示す流れ図である。２０５０に示されているように、クライアントが、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の関数を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。２０５６に示されているように、サービスは、結果のセットをスペース内のロケーションに格納することができ、スペースに、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０５７に示されているように、イベントを生成し、クライアントに送って、結果がスペース内に格納されていることをクライアントに通報することができる。２０５８に示されているように、クライアントは、イベントに応答して、スペースから結果のセットにアクセスし、読み取ることができる。
【０２５７】
図４４ｃは、１実施形態による、サービスの結果をメッセージ内でクライアントに送る方法を示す流れ図である。２０５０に示されているように、クライアントは、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の機能を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。２０５５に示されているように、サービスは、結果を含むメッセージをクライアントに送ることができる。メッセージは、データ表現言語（たとえばＸＭＬ）で表現することができ、１実施形態では、サービスのスキーマで指定することができる。
【０２５８】
図４４ｄは、１実施形態による、通知を使用してサービスの結果を返す方法を示す流れ図である。２０５０に示されているように、クライアントが、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の機能を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。１実施形態では、サービスが、結果のセットをスペース内のロケーションに格納することができ、このスペースには、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０６０に示されているように、サービスが、結果に関する通知を生成することができる。通知には、スペースからなど、結果にアクセスし読み取るのに使用可能な情報を含めることができる。たとえば、通知に、結果にアクセスできる場所のＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができる。１実施形態では、通知に、結果のフォーマットを指定するスキーマ（たとえばＸＭＬスキーマ）を含めることができる。１実施形態では、通知を、ＸＭＬなどのデータ表現言語で表現することができる。２０６８に示されているように、クライアントは、通知を使用することによって、結果のセットにアクセスし、読み取ることができる。１実施形態では、第２のクライアント（すなわち、関数を呼び出すメッセージを送ったクライアントと異なるクライアント）が、通知を使用することによって結果のセットを読み取ることができる。
【０２５９】
図４４ｅは、１実施形態による、メッセージ内でクライアントに送られる通知を使用してサービスの結果を返す方法を示す流れ図である。２０５０に示されているように、クライアントが、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の機能を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。１実施形態では、サービスが、結果のセットをスペース内のロケーションに格納することができ、このスペースには、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０６０に示されているように、サービスが、結果に関する通知を生成することができる。通知には、スペースからなど、結果にアクセスし読み取るのに使用可能な情報を含めることができる。たとえば、通知に、結果にアクセスできる場所のＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができる。１実施形態では、通知に、結果のフォーマットを指定するスキーマ（たとえばＸＭＬスキーマ）を含めることができる。１実施形態では、通知を、ＸＭＬなどのデータ表現言語で表現することができる。２０６１に示されているように、サービスが、通知を含むメッセージをクライアントに送ることができる。メッセージは、データ表現言語（たとえばＸＭＬ）で表現することができ、１実施形態では、サービスのスキーマで指定することができる。２０６８に示されているように、クライアントは、通知を使用することによって、結果のセットにアクセスし、読み取ることができる。
【０２６０】
図４４ｆは、１実施形態による、スペースに格納された通知を使用してサービスの結果を返す方法を示す流れ図である。２０５０に示されているように、クライアントが、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の機能を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。１実施形態では、サービスが、結果のセットをスペース内のロケーションに格納することができ、このスペースには、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０５６に示されているように、サービスは、結果のセットをスペース内のロケーションに格納することができ、スペースに、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０６０に示されているように、サービスが、結果に関する通知を生成することができる。通知には、スペースからなど、結果にアクセスし読み取るのに使用可能な情報を含めることができる。たとえば、通知に、結果にアクセスできる場所のＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができる。１実施形態では、通知に、結果のフォーマットを指定するスキーマ（たとえばＸＭＬスキーマ）を含めることができる。１実施形態では、通知を、ＸＭＬなどのデータ表現言語で表現することができる。２０６２に示されているように、通知を、スペースに格納することができる。スペースは、２０５６で結果が格納されたスペースと同一のまたは異なるスペースとすることができる。２０６６に示されているように、クライアントは、スペースから通知を読み取ることができる。１実施形態では、第２のクライアント（すなわち、関数を呼び出すメッセージを送ったクライアントと異なるクライアント）が、スペースから通知を読み取ることができる。２０６８に示されているように、クライアントは、通知を使用することによって、結果のセットにアクセスし、読み取ることができる。
【０２６１】
図４４ｇは、１実施形態による、スペースに格納された通知と、イベントを使用することによるクライアントへの通報とを使用してサービスの結果を返す方法を示す流れ図である。２０５０に示されているように、クライアントが、第１メッセージをサービスに送って、サービスの１つまたは複数の関数の呼出しを要求することができる。２０５２に示されているように、第１メッセージに応答して、サービスの１つまたは複数の機能を呼び出すことができる。２０５４に示されているように、サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。１実施形態では、サービスが、結果のセットをスペース内のロケーションに格納することができ、このスペースには、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０５６に示されているように、サービスは、結果のセットをスペース内のロケーションに格納することができ、スペースに、ネットワーク・アドレッシング可能なストレージ位置が含まれる。２０６０に示されているように、サービスが、結果に関する通知を生成することができる。通知には、スペースからなど、結果にアクセスし読み取るのに使用可能な情報を含めることができる。たとえば、通知に、結果にアクセスできる場所のＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができる。１実施形態では、通知に、結果のフォーマットを指定するスキーマ（たとえばＸＭＬスキーマ）を含めることができる。１実施形態では、通知を、ＸＭＬなどのデータ表現言語で表現することができる。２０６２に示されているように、通知を、スペースに格納することができる。スペースは、２０５６で結果が格納されたスペースと同一のまたは異なるスペースとすることができる。２０６４に示されているように、イベントを生成し、クライアントに送って、結果に関する通知がスペースに格納されていることをクライアントに通報することができる。２０６６に示されているように、クライアントは、スペースから通知を読み取ることができる。２０６８に示されているように、クライアントは、通知を使用することによって、スペースから結果のセットにアクセスし、読み取ることができる。
【０２６２】
図４５は、１実施形態による、分散コンピューティング環境での、あるサービスの結果を別のサービスに送る方法を示す流れ図である。２０７０に示されているように、クライアントが、第１メッセージを第１サービスに送って、サービスの１つまたは複数の関数の呼出しを要求し、関数の結果を第２サービスに渡すことを要求することができる。第１サービスのスキーマによって、第１メッセージを含む、第１サービスの関数を呼び出すのに使用可能な複数のメッセージを指定することができる。メッセージおよびスキーマは、ＸＭＬなどのプラットフォーム独立のデータ表現言語で表現することができる。１実施形態では、第１メッセージに、第２サービスの通知のＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含めることができ、第２サービスの通知には、第２サービスへのアクセスに使用可能な情報が含まれる。
【０２６３】
２０７２に示されているように、第１メッセージに応答して、第１サービスの関数を呼び出すことができる。２０７４に示されているように、第１サービスが、結果のセットを生成することができる。結果は、データ表現言語（たとえばＸＭＬ）で表現することができる。２０７６に示されているように、第１サービスは、結果をクライアントに直接に送らずに、メッセージ内で結果を第２サービスに送ることができる。この形で、結果を、クライアントに渡さずに、第１サービスから第２サービスに効率的に渡すことができる。
【０２６４】
結果スペースおよびメソッド・ゲートにより、分散コンピューティング環境では、メモリが最低限しかなく、帯域幅の非常に狭い、シン・クライアントにとって実用的な単純なリモート・メソッド呼び出しを提供することができるが、それは、従来のリモート・メソッドを呼び出し手法のように巨大なプログラム・オブジェクトが（必要なクラスとともに）ネットワーク上で（必ず）クライアントに返される困った副作用がないからである。その代わり、結果は、結果スペースに返すことができ、必要な場合のみ（そして、クライアントに常駐できる場合）、クライアントにダウンロードされる実際のオブジェクトである。
【０２６５】
分散コンピューティング環境がリモート・メソッドを呼び出すため備えているメカニズムは以下のとおりである（「ゲート」の項のメソッド・ゲートの説明も参照のこと）。スペース内でオブジェクトを通知することができる（たとえば、サービスとして、またはサービスの一部として）。通知は、オブジェクトのＵＲＩ（たとえば、ＵＲＬ）をセキュリティ証明書およびＸＭＬスキーマなどの他のアクセス・パラメータとともに含む参照を含む。クライアントは、オブジェクトに対しクライアント・メソッド・ゲートを設定しているか、または構築し、これは、オブジェクト（またはサービス）自体のすべてのメソッドについて、メソッド・パラメータを取り、要求ＸＭＬメッセージを作成してオブジェクトのメソッドを呼び出すラッパー・メソッドを備える。ＸＭＬメッセージは、サービス・オブジェクト上で実際のメソッドを呼び出すサービス・ゲートに送られる。そのメソッドが結果オブジェクトを返すと、サービス・ゲートは結果オブジェクトを結果スペース内にポストし、メッセージを結果オブジェクトへの参照とともにクライアントに返す。
【０２６６】
したがって、クライアントがリモートメソッドを呼び出すためには、クライアントはまず、上述のように、オブジェクト（たとえば、サービス）をインスタンス化するメッセージを送る。一実施形態では、オブジェクトのインスタンス化を行うには、結果スペースを作成するかまたは生成する。他の実施形態では、結果スペースの作成は、オブジェクトのインスタンス化とは別である。インスタンス化により、オブジェクトＵＲＩがクライアントに返され、クライアントとサービス・ゲートは、クライアントはインスタンス化を要求したときに動的に作成される。いくつかの実施形態では、結果スペースはすでに存在しており、オブジェクト（サービス）によって通知される。これらのゲートの一部または全部も事前に構築されるかまたは再利用されている。
【０２６７】
クライアントがオブジェクトをインスタンス化した後、適切なクライアント・メソッド・ゲートをローカルで呼び出すと、上述のように、実際のリモート・オブジェクトへのリモート・コールが影響を受ける。分散コンピューティング環境のリモート・メソッド呼び出しの方式は再帰的であり、クライアント・ゲートが呼び出されると、オブジェクト自体ではなく、オブジェクト参照がクライアントに返される。このような返されたオブジェクトはすでにインスタンス化されていることに注意されたい。いくつかの実施形態では、クライアント側は、リモートで呼び出すだけでなく、オブジェクト自体を丸ごとダウンロードする決定を下す。
【０２６８】
上述のように呼び出されたメソッドまたはサービスは、結果ドキュメントと関連付けられている子ゲートを生成する。メソッドは、参照自体ではなく、参照の子ゲート（またはクライアントが子ゲートを構築するためのスキーマ、ＵＲＩおよび証明書）を返す。その後、クライアントは、子ゲートを通じて参照にアクセスすることができる。子ゲートは、メソッド・ゲートでもよい。
【０２６９】
上述のように、分散コンピューティング環境で提供されるこのリモート・メソッド呼び出しにより、実際の結果オブジェクトを、サービス結果スペース内に格納できる（これは、たとえば、サーブレットにより動的に作成できる）。結果スペースは一時的である。結果スペースは、クエリ結果キャッシュとして機能することができる。古い結果領域をクリーンアップするサーバ・ソフトウェア（ガベージ・コレクタ）が結果キャッシュ内を巡回する。分散ガベージ・コレクションを採用するが、それは、クライアントがスペースを必要としなくなったことを示すか、またはサーバの管理者が適切な制限値を設定することにより、破棄されるまで結果スペースが満たされるからである。
【０２７０】
図２３に戻ると、デフォルトのスペース３５０の図が示されている。分散コンピューティング環境は、少なくとも１つのデフォルト・スペースを用意し、クライアントは通知の初期セットを見つけられるようにする。デバイスは、事前構築されたゲートを組み込んだ、ローカルに存在するデフォルト・スペースを備えることができる。そのデフォルト・スペースで通知されたサービスは、ローカルでそのデバイスに存在し、デバイスが分散コンピューティング環境に参加するのを有効にするかまたは容易にするシステム・ソフトウェアを備える。
【０２７１】
デフォルト・スペース３５０は、図２３に示されているように、外部スペースを特定する１つまたは複数のメカニズム３５２を備える。デフォルト・スペース内の１つのサービスが、上述のスペース発見プロトコルを実行して外部スペースを見つけることができる。また、デフォルト・スペース内で外部スペースを通知することができる。さらに、外部スペースを決定するまたは見つけるデフォルト・スペース内でサービス（たとえば、サーチ・エンジンまたはサーチ・エンジンへのプロキシ・サーバ）を通知する。各スペースは、ファイル・システムのマウント・ポイントに似ている。したがって、分散コンピューティング環境はサービスに対しサーチ可能な動的マウント・ポイントを提供できる。デフォルト・スペースは、分散コンピューティング環境へのクライアントの初期マウント・ポイントである。
【０２７２】
デフォルト・スペースまたはデフォルト・スペースへのアクセス機能をデバイスに組み込むことができる。デバイスに存在するデフォルト・スペースおよびローカル・サービスを通じて、分散コンピューティング環境にクライアント実行環境を用意できる。デバイスのローカル・サービスおよびデフォルト・スペース・サービスは、事前構築ゲートを組み込んでいる。デフォルト・スペース内にリストされている組み込みサービスの１つは発見プロトコルを実行するサービスであり、クライアントは追加（たとえば、外部）スペースを特定することができる。デフォルト・スペースは、クライアント・ユーザがスペースを参照し、サービスを選択し、インスタンス化するために使用するクライアント用の実行環境を提供する組み込みサービスを備える。このようなサービスは、クライアントがストリング全体（たとえば、スペースサーチのためのキーワード）を操作する、結果参照（たとえば、スペースのリスティング、またはスペース内のサービス・リスティング）を表示または参照する、アイテム（たとえば、サービスを選択してインスタンス化するため）を選択するなどのための単純なユーザ・インターフェースを備える。
【０２７３】
主にサービスを提供するデバイスは、さらに、デフォルト・スペースも備え、サービスでさまざまなスペース内での自己通知を管理できるようにする組み込みサービスをデフォルト・スペースに備えることができる。たとえば、プリンタなどのデバイスは、ローカル・エリア・ネットワーク上でスペースを（たぶん、発見プロトコルを利用して）見つけ、プリンタ・サービスの通知をそのスペースに追加する組み込みデフォルト・サービスを備える。このサービスはさらに、たとえば、リースを更新したり、プリンタのＸＭＬスキーマを更新するなどして、ＬＡＮスペース内のプリンタ・サービス通知を維持することもできる。
【０２７４】
サービスを提供するいくつかのデバイスでは、サービスを通知し、その通知を維持するのにスペースを見つけるオーバーヘッドは望ましくない。一実施形態では、サービス通知をパブリッシュするために１つまたは複数のスペースをサーチし維持するのではなく、いくつかのデバイスのサービスが接続要求に対する応答としてそれらの通知を送る。たとえば、プリンタ・サービスを近接性ベースで利用できるプリンタ・デバイスは、スペース内で通知を維持しない（デバイスで、またはデバイスの外部で）。その代わり、他のデバイスがプリンタ・デバイスとの接続を確立すると（たとえば、クライアントを実行しているラップトップを所有するユーザがドキュメントを印刷しようとする）、プリンタ・サービスはサービス通知を送り、プリンタ・デバイスで印刷機能を提供するサービスに接続し、そのサービスを実行するＸＭＬサービス・スキーマを提供することができる。さらに、いくつかのデバイスではある近傍またはローカル・ネットワークでサービスに対する通知を維持するのみである。このようなデバイスでは、広範にアクセス性に関してトランスポートへのアクセスをサポートすることを望まない、またはアクセスできない場合がある。
【０２７５】
デバイスがスペース内でサービス通知を避けるまたは制限することが望ましいサービス・デバイスの一例として、機能を近接性ベースで利用できるデバイスがある。近接性ベース・サービスは、要求があった場合に機能の通知を行うことができる。これらの通知は、広くアクセスできない場合がある。たとえば、近接性ベース・サービスは無線通信システムで提供できる。「無線」という用語は、電磁波または音波が電線ではなく大気中を通して信号を伝送する通信、監視、または制御システムを意味する。ほとんどの無線システムでは、無線周波（ＲＦ）または赤外線（ＩＲ）の波長を使用する。通常、近接ベースの無線システムでは、トランシーバを備えるデバイスは通信チャネルを確立し維持するために他のデバイスから到達範囲内（近接）になければならない。デバイスは、他のデバイスを無線ローカル・エリア・ネットワーク（ＬＡＮ）に接続するためのハブとすることもできる。
【０２７６】
前述のように、分散コンピューティング環境の実施形態では、クライアントがサービスとランデブーするためのルックアップ・スペースを使用するメカニズムを提供する。近接コンピューティング環境では、分散コンピューティング環境の一実施形態は、クライアントがランデブー・ポイントとしてルックアップ・スペースを使用せずにサービスを発見するために使用するサービス発見メカニズムを提供する。近接コンピューティング環境の一例として、ＩｒＤＡポイントツーポイント通信環境がある。近接コンピューティング環境では、近接メカニズムがクライアントに対するサービスの「物理的」位置を見つけることができる。たとえば、ＩｒＤＡ環境では、クライアント・デバイスは、クライアントが使用することを望んでいるサービスを含むデバイスを物理的に指している。
【０２７７】
近接サービス発見メカニズムを使用すると、クライアントは、サービス通知を求めるためにサーチ要求をルックアップ・スペースに送るのではなく、直接サービス通知を求めることができる。クライアント・デバイスはサービス・デバイスへの近接接続を確立しているため、クライアントは目的のサービスを直接要求できる。たとえば、ＰＤＡクライアント・デバイスはプリンタ・デバイスとの近接接続を確立している場合があり、クライアントはプリンタ・デバイスのプリンタをサービス接続を要求することを「知っている」。
【０２７８】
一実施形態では、クライアントは、近接サービス発見メッセージをサービス・デバイスに送ることができる。メッセージには、クライアント・デバイスが近接接続を行う相手であるサービス・デバイスの目的のサービスを指定する情報を含む。一実施形態では、サービス・デバイスのサービスは近接サービス発見メッセージに応答し、クライアントに、目的のサービスに接続するためにクライアントが使用するサービス通知を送る。近接サービス発見メッセージは、さらに、クライアントの認証を行い、サービスでクライアントの能力を確定するために使用される情報を含む。受け取ったサービス通知を使用する際に、クライアントは、目的のサービスとの通信を確立するためのゲートを確立することができる。しかしながら、広くアクセス可能なスペースで通知を維持することを望まない、または維持できないサービスに対し通知をパブリッシュすることが望ましい。分散コンピューティング環境の一実施形態では、近接ベース・デバイスなどのサービス通知をパブリッシュしないデバイスとの接続を確立するデバイスは、非パブリッシュ・デバイスから受け取ったサービス通知をパブリッシュすることができる。たとえば、近接ベース・デバイスとの接続を確立し、代替えトランスポート接続を設定するデバイスは、代替えトランスポート環境で近接ベース・デバイスから受け取ったサービス通知をパブリッシュ（または再パブリッシュ）し、近接ベース・デバイス・サービスをデバイスの通常の近接範囲の外にある他のデバイスにより（（再）パブリッシュされたサービス通知を通じて）使用できるようにする。
【０２７９】
パブリッシュ・デバイスが、発見および／またはルックアップ・サービスを通じて近接ベース・デバイスのローカルでパブリッシュされたサービスを通知を特定するか、またはそれとは別に、サービス通知をローカル・サービス・デバイスがパブリッシュしないが、その代わりに、そのサービス通知を、上述のように、接続の確立後、ローカル・デバイスがパブリッシュ・デバイスに送る。一実施形態では、通知を維持するデバイスがローカル・デバイスに接続されているか、接続することが可能である限り、再パブリッシュされたサービス通知は使用可能にできる。たとえば、パブリッシュ・デバイスがローカル・デバイスから切断された場合（たとえば、デバイスの近接範囲から外へ移動する）、サービス通知はステールになるか、または削除される。通知が格納されているスペースがリース更新メッセージをパブリッシュ・デバイスに送ることができるようにするリース・メカニズムを実現できる。パブリッシュ・デバイスは、ローカル・デバイスとの接続を確認し、これによりローカル・デバイスが利用できなくなったときにそのことをスペースが検出できるようにする。ローカルの近傍（たとえば、近接領域）またはローカル・ネットワークに対し、ローカル・デバイスまたは管理ポリシーにより、サービス通知を再パブリッシュする規則を定める。図２４は、一実施形態により、近傍ベースのデバイスから提供されるサービスをデバイスの近傍の範囲外にあるデバイスでアクセスできるようにする近傍ベースのデバイスを他のトランスポート・メカニズムにブリッジするデバイスの一例を示す図である。パブリッシュ・デバイス１４０４は、Ｅｔｈｅｒｎｅｔ　ＬＡＮまたはインターネットなどのネットワーク１４１２に接続され、近接デバイス１４００および１４０４との近接接続１４１４を確立して維持する。近接接続は、たとえば、無線接続または有線ＬＡＮ接続とすることができる。近接デバイス１４００および１４０２は、それぞれ、接続後サービス通知をパブリッシュ・デバイス１４０４に送るか、または、それとは別に、パブリッシュ・デバイスが近接接続に発見および／またはルックアップ・サービスを使用してサービス通知を特定する。パブリッシュ・デバイス１４０４は、スペース１４０６内のサービス通知１４１６および１４１８を再パブリッシュすることにより、近接デバイスによって提供されるサービスをネットワーク１４１２上の他のデバイス１４０８および１４１０から利用できるようにする。スペース１４０６は、パブリッシュ・デバイスまたはＬＡＮに接続された他のデバイス（デバイス１４０８および１４１０を含む）上に格納できる。
【０２８０】
デバイス１４０８および１４１０を含むＬＡＮ上の他のデバイスは、スペース１４０６を発見し、再パブリッシュされたサービス通知１４１６および１４１８を近接ベース・デバイスについてルックアップし、前記のＸＭＬメッセージ・パッシング方式を使用して近接ベース・デバイス１４００および１４０２上でこれらのサービス（デバイス１４０４はプロキシまたブリッジとして機能する）とのデートの通信を確立し、近接デバイスとの間の要求の発送および結果の受取を行う。パブリッシュ・デバイス１４０４は、ネットワーク１４１２と近接ベース・デバイスへの近接接続１４１４との間のブリッジとして機能する。
【０２８１】
リース
リースは、分散コンピューティング環境で、部分的な障害、リソースの同期（スケジューリング）を処理し、秩序だったリソースのクリーンアップ・プロセスを実施するために使用される。リースを使用すると、分散システム全体で行き来する独立のクライアントおよびサービスを管理することができる。クライアントがサービス（スペース・サービスを含む）から取得するさまざまなリソースは、これらのサービスからリースすることができる。一般に、すべてのリソースをリースするできるわけでも、またリースする必要があるわけでもない。一実施形態では、どのリソースをリースする必要があるかの決定は、それぞれの特定のサービスの実装に任されている。特に、大量のクライアントが使用するリソースが同時に、リースを必要としない場合があったり、あるいはその代わりに、カスタム・リース・プロトコルを必要とする場合もある。このようなはリースのクラスは、サービス・プロバイダに任されている。たとえば、トランザクションを実装するものなどのカスタム・プロトコルは、基本リース方式に基づいて構築できる。一実施形態では、基本リース・モデルは相対的な時間ベースのモデルである。
【０２８２】
サービスは、リースをクライアントに発行し、リースに対し操作を実行する。一実施形態では、サービスのこのようなリース機能はすべてそのサービスのＸＭＬスキーマの一部である。したがって、クライアントはそのゲート（サービスに対応し、サービスのＸＭＬスキーマに対し構築される）を使用してリース操作を実行することができる。一実施形態では、リースを発行するサービスはすべて、（ｉ）リースの更新（リースの指定されたパラメータ（たとえば、リースＩＤ、リース証明書）、要求された新しいリース時間）、および（ｉｉ）リースの取り消し（リースの指定されたパラメータ（たとえば、リースＩＤ、リース証明書）という２つのリース操作を行える（リースの所有者によってのみ使用可能）。一実施形態では、すべてのリースは交渉可能な特定の相対的時間（リースの持続時間）について認可される。リクエスタではある時間を指定し（たとえば、秒で）、グランタ（ｇｒａｎｔｏｒ）ではその時間が経過するまでの間リースを認可できる。一実施形態では、値を−１にすると、無期限のリースを指定することができる。
【０２８３】
一実施形態では、サービス通知に１つまたは複数のリース・アドレスを含めることができる。一実施形態では、リース・アドレスはＵＲＩとすることができる。サービス・リソース・リースを更新する、または取り消す標準リース・メッセージを、リースＵＲＩに送ることができる。リースＵＲＩの例：

【０２８４】
通知は、さらに上述のように、さまざまなリース・メッセージを含む。リース・メッセージは、サービスのリソースに対するリースを更新するメッセージおよびリースを取り消すメッセージを含むことができる。一実施形態では、通知にメッセージをＸＭＬスキーマで含めることもできる。
【０２８５】
リース・メカニズムは、サービスおよびクライアントの障害を検出するメカニズムを備える。リースはさらに、共有および排他的リソース・アクセスを実現するメカニズムも備える。一実施形態では、すべてのサービス・リソースはリースがないか（リソースがリースされておらず、したがって使用できない）、共有リソースがあるか（リソースは複数のクライアントによりアクセスされる）、または排他的リースがあるか（リソースは一度に１つのクライアントだけによりアクセスされる）のいずれかである。一実施形態では、すべてのリソースはリースがない状態から始まる。リースがない状態は、現在基礎となるリソースにアクセスがないことを意味し、リソースのインタレストが存在していてリースに使用可能であることを示す。リース・レベルは、「なし」から「共有」へ、「なし」から「排他的」へ、または「共有」から「排他的」へ上げることができる。リース独立レベルも、「排他的」から「共有」へ、「排他的」から「なし」へ、または「共有」から「なし」へ下げることができる。一実施形態では、クライアントは自発的にリース独立レベルを上下させるか、またはサービスによりそのようにすることを要求することができる。サービスからの応答メッセージは、独立レベルの変更が受け入れられたかどうかを示す。
【０２８６】
要求−応答メッセージのペアを使用して、リースの請求、解放、および更新を行うことができる。予約されているＸＭＬタグを使用して各メッセージにタグを付け、メッセージがリース・メッセージであることを示す。分散コンピューティング環境では、メッセージの完全な構成を必ずしも定義しない。このような実施形態では、メッセージがリース・メッセージとしてタグ付けされる限り、サービス開発者側でカスタム・メッセージ・コンテンツを付加することができる。
【０２８７】
一実施形態では、リースされたリソースを使用するクライアントは、（ｉ）リソースを共有または排他的として請求する、（ｉｉ）リソース請求を解放する（要求された場合またはリソースで終了した場合）、および（ｉｉｉ）更新メッセージに応答する（同じまたは異なる独立レベルの他の請求により）のいずれかを行うことを期待される。更新メッセージは、サービスにより（たとえば、定期的間隔で）クライアントの障害を検出するために送られる。この間隔（更新メッセージが送られる）は、サービス固有である。一定時間経過後更新メッセージへの応答が発行されない場合（たとえば、サービス通知で知らされた時間に基づき）、リソース再利用プロセスがサービス内で開始し、そのリースを完全に破棄する。このような実施形態では、クライアントに送られる更新メッセージは、タイミングよく取り扱うべきである。図２５は、クライアントとインスタンス化されたサービスとの間の更新メッセージ、およびサービス・プロバイダとスペース・サービスとの間の更新メッセージの使い方を示している。両方とも、クライアントとサービスとの間の更新メッセージの使用と考えることができるが、それは、サービス・プロバイダがスペースの通知サービスへのクライアントであるためであることに注意されたい。
【０２８８】
更新メッセージは、クライアントには取り扱いが不便な「アウトオブバンド」方式で到着する。つまり、クライアントは、更新メッセージがいつサービスから送られるかを予測できないということである。アウトオブバンド・メッセージ処理により、クライアントのロジックがやっかいなものになり、その複雑度が増す。この問題を解決するために、自動リース更新メカニズムを実装し、アウトオブバンド・メッセージを取り扱う必要があるクライアントの労力を軽減し、クライアントの複雑さを低減する。自動リース更新メカニズムで、それぞれのゲート（メッセージ、メソッド、および／またはイベント・ゲート）は更新メッセージを受け取り、クライアントの助けを借りずにそれに自動的に応答することができる。更新要求に対するデフォルトの応答は、現在のレベルでリースを請求することである。それぞれのメッセージ・ゲートは、ゲートが更新メッセージを受け取ったときに自動的に通知スペース・サービスに送られる単一の留保更新応答メッセージを含むことができる。この「アウトオブバンド」メッセージは、クライアントの代わって処理され、クリーンなクライアント・プログラミング・モデルを生み出す。一実施形態では、ゲートにより、クライアントはリース・イベント・ハンドラを登録し、応答メッセージの中で異なる独立レベルを指定できる。
【０２８９】
リース・メカニズムは、さらに、ステール（無効の）通知を検出するメカニズムも備える。サービスがスペース内の通知をパブリッシュすると、そのサービスはこれが通知をパブリッシュしたことに基づいてリースを取得する。それぞれの通知には、サービスが通知を更新することを約束している時間が記述される。一実施形態では、すべてのタイムアウト値を秒単位で指定する。サービスがリースの更新を続ける場合、通知されたサービスがまだ提供中であるという何らかの確認をスペースで行うようにする。更新時間は、スペース・サービスによりゼロになるまでカウントダウンされる。サービスがリースを更新しない場合、サービスは失敗している可能性があるか、またはサービスを提供しなくなっているか、または提供できなくなっている。リースが更新されない場合、スペース・サービスはサービス通知をステールにするため、クライアントから使用できなくなる。サービスでは、スペースに更新メッセージを送ることにより通知を更新する。スペース・サービスは、これらのメッセージを受け取りて、通知更新時を初期値にリセットする。
【０２９０】
一実施形態では、ステール状態の通知は自動的には削除されない。スペースのポリシーに応じて、十分に長い期間期限切れになっているステール状態のサービス通知の削除を選択できる。削除ポリシーは、スペース・サービスで設定できる。スペース・サービスは、ステール状態の通知をサーチし、たとえば、それを削除するか、または管理者に知らせる。
【０２９１】
スペース・サービスは、リースを使用して、その機能によってスペースのクライアント（他のサービスを含む）に提供されるリソースを管理することができる。たとえば、クライアントがサービスを使用することを希望する場合、スペース・サービスはサービスのインスタンス化の一部としてクライアントにリースを要求する。サービスのインスタンス化を実行する際に、クライアントはサービスを実行できる。サービスをインスタンス化するために、クライアントはまず、スペース内でパブリッシュされたサービス通知のうちから１つ選択する。クライアントは、スペースに用意されているさまざまな機能を使用して、スペース内の通知をルックアップすることができる。次に、クライアントは、スペースに対しサービスのインスタンス化を要求する。サービスのインスタンス化のときに取得されたリースは、サービス通知を使用したときのものである（サービス通知をパブリッシュしたときのリースと同じではない）。スペース・サービスでは、共有されていることを示す通知の場合に複数のクライアントがサービス通知の使用についてリースすることができることに注意すべきである。そうでない場合、スペース・サービスでは、一度に１つのクライアントがサービス通知についてリースするだけである（排他的）。
【０２９２】
スペース・サービスがリースを使用してその機能によりクライアントに提供されるリソースを管理するもう１つの例として、ＸＭＬドキュメント（たとえば、サービス通知）がスペースに追加されるかまたはスペースから削除されるときにそのことを通知するようスペースのクライアントが登録する場合が上げられる。スペースの登録クライアントは、通知に対するこのサブスクライブでリースを取得できる。このリースにより、スペース・サービスは通知を送り続けるかどうかを知ることができる。このようなリースは、クライアントがスペースとのアクティブなセッションを確立している場合には、必要ないと思われる。また、スペースのクライアント（サービスの場合もある）がスペースとのセッションを確立するときに、クライアントがそのセッションでリースを取得することができることに注意されたい。このため、スペースはセッションと関連するリソースを管理することができる。
【０２９３】
他の実施形態では、分散コンピューティング環境は時間ベースではないリース・メカニズムを採用する。このリースは、オブジェクトに対し使用が請求されたときに生成される。時間ベースのメカニズムの代わりに請求メソッドでは、他の何かのパーティが同じオブジェクト（たとえば、サービス）にアクセスしたいということを現在のリースホルダに通知するコールバックを受け付ける。したがって、時間ベースのリースに対する他の実施形態として、代わりに、クライアントがスペース・オブジェクト（たとえば、サービス）に対する請求を行うことができる。他のクライアントが現在のリースホルダのリースと互換性のないリースを望んでいる場合、サービスは、「コールバック・メッセージ」をクライアントに送る。コールバック・メッセージを受け取ると、クライアント（つまり、クライアント・ゲート）はコールバック・メソッドを呼び出して、コールバック・メッセージに応答するかどうかを決定する（リースを持続する、リースを取り消す、アクセス・レベルを共有に変更するなど）。応答が決定されたら、クライアント・ゲートは応答メッセージをサービスに送る。リースを管理するこのような配布メカニズムは、ＸＭＬメッセージ通信レイヤを使用して実装できる。
【０２９４】
時間ベースでないリース実施形態では、分散コンピューティング環境は複数のレベル（または種類）のアクセスをサポートするリースを提供し、これにより、分散アルゴリズムでリース互換性を判別することができる。レベルには、（ｉ）オブジェクトをスペース内に保持する（ｋｅｅｐＩｎＳｐａｃｅ）、（ｉｉ）スペース内のオブジェクトを読み込む（ｒｅａｄＳｈａｒｅｄ）、および（ｉｉｉ）スペース内のオブジェクトを排他的に読み込む（ｒｅａｄＥｘｃｌｕｓｉｖｅ）というレベルがある。
【０２９５】
認証とセキュリティ
分散コンピューティング環境は、非同期メッセージ通信モデルに基づく自然発生の分散システムと異機種分散システムに対応し、データおよび／またはオブジェクトはＸＭＬなどの表現言語により表現することができる。分散コンピューティング環境では、たとえば、クライアントは、インターネット全体を通してサービスに接続することができる。分散コンピューティング環境では、大量のネットワーク・デバイスがセキュリティで保護された信頼できる動的な方式で連携動作する。分散コンピューティング環境により、準拠するソフトウェア・コンポーネント（クライアントおよびサービス）の間の相互運用性を実質的に可能にするプロトコルが定義される。
【０２９６】
分散コンピューティング環境のコンテキストでは、デバイスはネットワーキング・トランスポートでアドレス指定可能なユニットである。クライアントとサービスは、デバイスで実行されるソフトウェアまたはファームウェアのＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）アドレス指定可能なインスタンスとして実装することができる。
【０２９７】
インターネット・スペースには、多数のコンテンツ・ポイントが配置されている。ＵＲＩは、コンテンツ・ポイントを識別するのに使用される方法であり、テキストのページ、ビデオまたはサウンド・クリップ、イメージ、ソフトウェア、ファームウェア、またはその他のインターネット・コンテンツである。ＵＲＩの最も一般的な形式は、Ｗｅｂページ・アドレスであり、これは、Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ（ＵＲＬ）と呼ばれるＵＲＩの特定の形式またはサブセットである。ＵＲＩは、通常、リソース、リソースが置かれている特定のコンピュータ、およびコンピューター上のリソースの特定の名前（通常、ファイル名）にアクセスするために使用されるメカニズムを記述する。
【０２９８】
クライアントおよびサービス（両方とも、デバイスにソフトウェアおよび／またはファームウェアとして実装できる）は、インターネット、企業イントラネット、動的近接ネットワーク上で、単一コンピュータ内で、またはその他のネットワーク接続モデルにより接続できる。たとえば、クライアントおよびサービスをサポートするデバイスのサイズおよび複雑さは、単純な照明スイッチから複雑な高可用性のサーバーまでさまざまなものがある。デバイスの例としては、それらに限定されないが、ＰＤＡ、携帯電話、ノートブック・パソコン、ラップトップ・パソコン、より強力なＰＣ、さらに強力なコンピュータ・システム、そしてスーパー・コンピュータに至るまで、さまざまなものがある。いくつかの実施形態では、クライアントおよびサービスの距離、待ち時間、および実装を抽象化し、共通の発見および通信方法を使用し、「ブラック・ボックス」効果を生み出している。この定義方法により、ソフトウェアの実装問題は、根幹のプラットフォームで取り扱うことができ、インターネット規模に合わせて拡大縮小できる粗結合システムを実現できる。
【０２９９】
分散コンピューティング環境は、ＷＥＢおよびＸＭＬコンテンツ表現、動的デバイス発見、およびさまざまなネットワーク・デバイスからアクセス可能なセキュリティで保護されたデバイス通信など、インターネット中心のプログラミング・モデルを提供する。分散コンピューティング環境は、ＣＰＵレベルよりも上で抽象化されたネットワーク・プログラミング・モデルを含む。このプログラミング・モデルは、以下の特性を持つ。
ＵＲＩアドレス
コンテンツと呼ばれる強く型付けられたデータ（ＵＲＩでアドレス指定）
実質的に無制限の永続的コンテンツ記憶域（たとえば、ストア）（ＭＩＭＥタイプで識別されるものなどのＸＭＬおよび非ＸＭＬコンテンツを含む）
スペースと呼ばれる実質的に無制限の一時的コンテンツ・メモリ（ＸＭＬコンテンツを含む）
関係するクライアントに通知するためにスペース内に格納できる記述的ＸＭＬメタデータ（データに関するデータ）コンテンツ通知。
実質的に無制限の数の命令（メッセージとして埋め込まれる）
ＵＲＩによりアドレス指定されるセキュリティで保護されたメッセージ・エンドポイント（ゲート）
分散ソフトウェア・プログラム間のワーク・フローを調整するデータ・フローのサポート（イベント・メッセージ）
【０３００】
サービスおよびクライアントは、分散コンピューティング環境内でプログラムとして実行できる。サービスは、サービスの使用を望んでいるクライアントに機能を通知することができる。クライアントは、同じネットワーク・デバイス内に常駐する場合も常駐しない場合もあり、デバイスのコード実行環境はＪａｖａプラットフォームをサポートする場合もあればしない場合もある。ＵＲＩを使用してコンテンツおよびメッセージ・エンドポイントをアドレス指定する際に、分散コンピューティング環境は強力なアドレス指定方式となる。アドレスにより、コンテンツまたはエンドポイントの位置を指定し、また使用するルート（またはトランスポート・プロトコル）を指定することができる。ＵＲＩを使用してアドレス指定したアイテムはさらに、関連付けられたセキュリティ証明書を持つ。セキュリティ証明書を使用して、どのようなクライアントにアイテムへのアクセスを許可するか、また承認されたクライアントでそのアイテムに対しどの操作の実行を許可するかを制御することができる。
【０３０１】
分散コンピューティング環境によって提供される高度なアクセスは、適切な認証およびセキュリティ・システムおよび方法により制御できる。分散コンピューティング環境における認証とセキュリティには、メッセージ内のＸＭＬコンテンツの型付けの正しさの検証、受取側に対し発送側を安全に識別する操作、クライアントからサービスに、その逆にサービスからクライアントに送られるメッセージの完全性を検査するメカニズム、およびクライアントに対し受け付けられたサービスのメッセージ群を記述し、サービスで受け取ったメッセージに対しメッセージ要求条件を強制するメカニズムがある。上記のセキュリティおよび認証の機能は、コードおよびデータの単一アトミック・ユニットで活用できる。コードおよびデータのアトミック・ユニットを動的に作成できる。一実施形態では、コードおよびデータのアトミック・ユニットは、いったん作成されると、メッセージ・エンドポイント（ゲート）を表し、作成時に実装されたセキュリティおよび認証ポリシーに関して改変できない。
【０３０２】
ゲートは、サービスの機能の一部または全部を使用する権限を表す。各機能は、サービスに送ることができるメッセージに関して表すことができる。ゲートはさらに、クライアントがリソースをリースするときに障害が発生した場合を検出するのに使用できる。
【０３０３】
認証およびセキュリティはさらに、サービスを使用しようとするクライアントがそのサービスを使用することを承認されていること、クライアントがサービス通知を受け取る先であるスペースがサービス通知を提供することを承認されていること、および／またはサービス通知自体が承認されていることを検証するメカニズムを備えることができる。
【０３０４】
メッセージ通信は、クライアントからサービスに要求を伝達する手段およびサービスがクライアントに結果を応答する手段としてメッセージング・レイヤに実装できる。分散コンピューティング環境のメッセージング・レイヤでは、有効なＸＭＬメッセージが送られることを実質的に保証し、また言語独立のセキュリティ・モデルを使用可能にするメカニズムを備えることができる。メッセージング・レイヤでは、送るメッセージ・エンドポイントを受け取るメッセージ・エンドポイントにリンクさせることができる。２つの関連するメッセージ・エンドポイントは、クライアントとサービスとの間の要求−応答メッセージ通信に適したセキュリティで保護された双方向のアトミック・メッセージ・チャネルを提供することができる。
【０３０５】
分散コンピューティング環境の実施形態では、サービスに関してスペース内で通知をパブリッシュすることができる。通知は、サービスのＸＭＬスキーマおよびＵＲＩを含むＸＭＬドキュメントとすることができる。サービスはさらに、通知の中にサービスＩＤトークンまたは証明書を含めることもでき、通知で、クライアントとサービスの両方により使用される認証サービスを指定することができる。その後、クライアントはスペースのサービス通知を特定し、その通知を使用してクライアントでメッセージ・ゲートをインスタンス化する。クライアントは、通知で指定された認証サービスを使用して、メッセージでクライアントに送るための認証証明書を取得する。一実施形態では、クライアントはサービスＩＤトークンまたは証明書をサービス通知から認証サービスに渡し、続いて認証サービスはサービス・トークンと、または証明書を使用して、そのクライアントの認証証明書を生成することができる。一実施形態では、クライアントはメッセージ・ゲートを作成するために必要な情報を受け取るゲート・ファクトリを備え、そのゲート・ファクトリはメッセージ・ゲートを構築し、認証サービスと通信して、クライアントの認証証明書を取得する。対応するサービス・メッセージ・ゲートが、サービス側でインスタンス化される。
【０３０６】
クライアントは、ある時点で、第１のメッセージをサービスに送る。一実施形態では、クライアント・メッセージ・ゲートは認証サービスにより構築されたクライアントの認証証明書をメッセージ内に埋め込む。サービスがメッセージを受け取ると、同じ認証サービスを使用してメッセージで受け取った認証証明書を検証する。同じ認証サービスを共有することにより、さまざまな認証プロトコルを採用し、しかも、認証証明書の生成の詳細をクライアントとサービスから分離することができる。したがって、クライアントは異なる認証証明書プロトコルを異なるサービスとともに使用することができる。
【０３０７】
一実施形態では、認証サービスは、サービスからクライアント認証証明書を最初に受け取った後クライアントの能力を判別することができる（たとえば、サービスに対しクライアントがどのようなことを許されているか）。クライアントの能力は、クライアントの素性に縛られる。そこで、クライアントのメッセージ・ゲートはクライアントからサービスに送られるすべてのメッセージに認証証明書を埋め込む。メッセージは、サービス・メッセージ・ゲートに届き、そこで、認証サービスによりチェックされ、そのメッセージがクライアントからのものであること、メッセージ要求がクライアントの能力範囲内にあることを確認する。他の実施形態では、サービス・メッセージ・ゲートは、認証サービスを使用せずに、能力を判別および能力に関するメッセージ検査を処理する。
【０３０８】
クライアントおよびサービス・メッセージ・ゲートは連携して、セキュリティで保護され信頼できるメッセージ・チャネルを実現する。ゲートはセキュリティで保護されたメッセージ・エンドポイントとして使用され、クライアントはセキュリティで保護され承認されているＸＭＬメッセージをサービスとの間で送受されることによりサービスを実行できる。
【０３０９】
分散コンピューティング環境内のオペレーションは、クライアントとサービスとの間で送られるＸＭＬメッセージとして実現される。クライアントをサービスと接続し、スペースおよびストア内のコンテンツをアドレス指定するのに使用されるプロトコルは、クライアントとサービスとの間で送ることができるメッセージによって定義される。メッセージを使用してプロトコルを定義すると、さまざまな種類のデバイスをプロトコルに参加させることができる。各デバイスは、その能力と役割に最適の方法でプロトコルを自由に実装することができる。
【０３１０】
サービスの機能は、そのサービスが受け入れるメッセージに表すことができる。サービスのメッセージ・セットは、ＸＭＬスキーマを使用して定義することができる。ＸＭＬメッセージ・スキーマにより、ＸＭＬ型付きタグを使用して各メッセージ形式を定義する。タグの使用規則もまた、スキーマで定義できる。メッセージ・スキーマは、メッセージを受け取るために使用するサービスのメッセージ・エンドポイント（ゲート）とともにＸＭＬ通知の一コンポーネントであってよい。メッセージをＸＭＬメッセージ・スキーマに加えることにより、拡張機能（さらに多くの能力）をサービスに追加することができる。
【０３１１】
分散コンピューティング環境では、承認されたクライアントがサービスの能力すべてを使用できるか、またはサービスの能力のサブセットの使用に限定される。一実施形態では、一組の機能をクライアントに与えた後、クライアントは適切な承認がないとそのセットを変更することはできない。この機能定義のモデルにより、基本機能セットから拡張機能セットまでのサービス・レベルに対応できる。
【０３１２】
サービスのインスタンス化を実行する際に、クライアントはサービスを実行できる。サービスをインスタンス化するために、クライアントはまず、スペース内でパブリッシュされたサービス通知のうちから１つ選択する。クライアントは、スペースに用意されているさまざまな機能を使用して、スペース内の通知をサーチすることができる。次に、クライアントは、スペースに対しサービスのインスタンス化を要求する。サービスのインスタンス化は、以下のことを含むが、これに限られるわけではない。
１．クライアントは、スペース・サービスにサービスをインスタンス化するよう要求する。
２．スペース・サービスは、クライアントがサービスをインスタンス化することを許可されていることを検証する。
３．スペース・サービスは、クライアントによって指定されたリース要求時間にクライアントのサービス通知でリースを取得する。それとは別に、サービス通知をクライアントに送るができ、しかもリース・メカニズムを使用しない。
４．スペース・サービスは、ステップ３で割り当てたリースとサービスのサービス通知を含むメッセージをクライアントに送る。
５．クライアントは、サービス通知で指定された認証サービスを実行し、認証証明書を取得する。
６．クライアントは、サービスと通信するためクライアント・メッセージ・ゲートを構築する。
分散コンピューティング環境でクライアントとサービスとの間に信頼性を築くために、一連の動的に生成される数値（キー、またはトークン）を、クライアントのセキュリティまたは認証証明書として使用する。１つまたは複数の証明書を使用して、クライアントがサービスを使用する権限を検証し、クライアントとサービスとの間でやり取りするメッセージを検証することができる。それぞれクライアントおよびサービスは、固有の証明書を備える。
【０３１３】
サービスを使用するのに必要な認証証明書の種類がサービス・サーチを実行するクライアントに返される。一実施形態では、認証証明書は、クライアントがサービスを使用するごとに提示する必要がある隠蔽型オブジェクトである。一実施形態では、認証証明書はサービスに送られるすべてのメッセージ内でクライアントのためにメッセージ・ゲートにより提示される。どのような種類の認証証明書をサービスが必要としようと、クライアントとサービスの外部の認証サービスを使用することにより、クライアントおよびサービスは認証証明書構造または認証プロセスを意識する必要がない。
【０３１４】
認証証明書はさらに、サービス・チケットに加えてトランスポート固有のチケットを備えることができる。サービスを実行するときに、サービス通知で指定されるネットワーキング・トランスポートに応じて、トランスポートはセキュリティで保護された接続を提供できる。場合によっては、データ・リンク・レイヤがすでにセキュリティで保護されている場合、すでにセキュリティで保護されているデータ・リンク・レイヤ上でセキュリティで保護されたトランスポートを使用する必要はないと考えられる。
【０３１５】
認証証明書の概念は、証明書実装に基づくさまざまなレベルのセキュリティを可能にするだけの十分な抽象性を備えている。セキュリティのレベルにはそれらに限定されないが以下のものがある。
１．なし（空のメッセージにセキュリティ証明書はないか、または証明書がない）
トランスポートの物理的接続特性によりセキュリティが強制されるときは、証明書が空であるか、または証明書がないメッセージで十分である。たとえば、照明スイッチ・コントローラ１つだけに接続されたスマート・ライト・スイッチはそのスイッチが安全な方法で配線されているので安全である。
２．シグネチャ付きメッセージ（電子シグネチャ）
シグネチャ付きメッセージは、サービスがメッセージの発信源（クライアント）を検証できるようにする電子シグネチャを含む。
３．暗号化メッセージ（トランスポートでこれを取り扱う）
暗号化メッセージは、メッセージの内容をスクランブルし、他の証明書でそのスクランブルを解除する必要があるようにするという方法により、別のレベルのセキュリティを追加する。
４．能力メッセージ（サービス機能およびユーザ認識）
このレベルのセキュリティは、ユーザごとのセキュリティ機能を実現し（たとえば、ユーザが実行を許されているもの）、サービスおよび個々のサービス機能に対する精密なアクセス制御を行うことができる。
【０３１６】
高いレベルのセキュリティ（能力および暗号化）を実現するのに必要な実装が重いため、複数レベルのセキュリティ・ゾーンを使用する。メッセージ・トランスポートでこのようなセキュリティ・レベルをサポート（またはボートを支援）する場合、このサポートを活用して一方のレベルのセキュリティから他方のレベルのセキュリティへ橋架けするセキュリティ・レベル・ブリッジ・サービスを提供する。
【０３１７】
上述のように、セキュリティ・モデルのないサービスでは、空の認証証明書を受け付けることができる。アクセスが制限されていないサービスでは、認証証明書なしでまたは「空の」認証証明書付きでゲートを構築することができる。このようなサービスのゲートは、それぞれのメッセージとともに認証証明書を送らないか、または空の証明書を送る。認証サービスは、アクセスを制限しないサービスの一例である。他のサービスでは、ユーザＩＤとパスワードのペアを必要とする。
【０３１８】
証明書を使用するサービス・アクセスの認証
いくつかの実施形態では、サービスを実行しようとするクライアントが承認されているクライアントであることを検証し、クライアントによって受取されるサービス通知が承認されたサービス通知であること検証し、かつ／またはクライアントがサービス通知を受け取った発送元のスペースが承認されていることを検証するメカニズムは、公開鍵／秘密鍵非対称暗号メカニズムに基づく。このメカニズムでは、承認された発送側エンティティは公開鍵をメッセージに埋め込み、秘密鍵で公開鍵を含むメッセージを暗号化する。暗号化メッセージを受け取るエンティティは、公開鍵を使用してメッセージを復号化し、復号化されたメッセージに埋め込まれている同じ公開鍵を見つけ、そのメッセージが承認されたエンティティからのものであることを検証するが、それは、そのエンティティのみがメッセージを暗号化するのに必要な秘密鍵を持っているからである。そこで、エンティティは、実質的に忘れることができない、他のエンティティが復号化して（適切な公開鍵で）、エンティティによって送られたメッセージを検証することができる証明書を発行する。
【０３１９】
さまざまな鍵生成アルゴリズムを分散コンピューティング環境で使用できる。鍵の構成は、クライアントとサービスの両方から隠されており、クライアントとサービスはどのような鍵生成アルゴリズムを使用しているかを問わない。
【０３２０】
Ｋｅｒｂｅｒｏｓチケットは、分散コンピューティング環境で使用されるセキュリティ証明書の一例である。Ｋｅｒｂｅｒｏｓは、コンピュータ・ネットワーク内のサービスの要求を認証するセキュリティで保護された方法である。Ｋｅｒｂｅｒｏｓを使用すると、ユーザは特定のサービスを要求するために使用できる認証プロセスに暗号化された「チケット」を要求することができる。ユーザのパスワードは、ネットワークに通す必要はない。
【０３２１】
分散コンピューティング環境では、クライアントとサービスとの間で送られるメッセージの品質が損なわれないよう実質的に保証するメカニズムを提供する。一実施形態では、メッセージが改変されていないことを検証するため発送側は受取側が使用できる情報を含むトークンを埋め込む。メッセージに埋め込む情報を生成する方法はいくつかある。一実施形態では、メッセージのハッシュを計算し、それをメッセージとともに送る。ハッシュ法は、文字列を元の文字列を表す通常短い固定長の値または鍵に変換する操作を含む。メッセージを受け取ると、受取側はそのハッシュを再計算し、送られたハッシュに照らしてチェックする。メッセージが改変されていた場合、同じハッシュが生成される可能性はほとんどない。発送側は、ハッシュを暗号化し、対応する公開鍵を暗号化されたメッセージに入れて送り、そのハッシュが損なわれないように実質的に保証する。
【０３２２】
他の実施形態では、巡回冗長検査などの誤り検出方式を使用する。巡回冗長検査は、通信リンクで送られたデータ内にエラーがないか調べる方法である。巡回冗長検査を使用する実施形態では、発送側はｎビットの多項式をメッセージに適用し、その結果の巡回冗長検査（ＣＲＣ）をメッセージに付加する。受取側は、同じ多項式（メッセージでも渡される）をメッセージに適用し、その結果を発送側が付加した結果と比較する。マッチする場合、メッセージは正常に受け取られたということである。マッチしない場合、発送側はメッセージの再送を通知される。
【０３２３】
ゲート・ファクトリは「信頼できる」コードなので、ゲート・ファクトリもまたセキュリティで一定の役割を果たす。信頼できるゲート・ファクトリを使用してゲートを生成することにより、ゲートが信頼できるコードであり、そのコードがサービス通知に関して正しいものであることを保証できる。クライアントは、認証の一手段として、クライアントＩＤトークンまたは証明書をゲート・ファクトリに提示する必要がある。サービスは、クライアントがゲートを作成するときに、サービスＩＤトークンまたは証明書をクライアントに提示する（たとえば、通知を通じて）。ここで説明したように、クライアントおよびサービス・トークンのペアを使用して、クライアントがメッセージをサービスに送ることができるようにするために使用される第３の証明書を作成する。この第３の証明書は、認証証明書と呼ばれる。認証証明書は、認証プロセスの実行時に認証サービスにより作成される。一実施形態では、サービスは認証ポリシーを自由に使用できる。一実施形態では、認証サービスはサービスに代わって認証ポリシーを管理するため、サービス側では、使用されている特定の認証ポリシーを意識する必要はない。
【０３２４】
クライアントはサービス通知で指定した認証サービスを実行することにより受け取った認証証明書を使用してゲートを構築する。これにより、構築されたゲートは認証証明書をそれぞれのメッセージとともにサービスに送ることができる。サービスがクライアントから第１のメッセージで第１の認証証明書を受け取ると、サービスはサービス通知で指定されている認証サービスを使用してクライアントを認証し、認証証明書のクライアントのＩＤへのバインドを確立する。
【０３２５】
すでに述べたように、サービスによって出力されるいくつかの結果がスペース内で通知され、最終的に結果ゲートを使用してアクセスされる。結果ゲートは、結果を生成するために使用する入力ゲートと同じセキュリティ証明書を含む場合もあれば含まない場合もある。サービスへの入力は出力（結果）と非同期であるため、結果は、異なるアクセス権限セットが関連付けられる。たとえば、給料支払い簿サービスではクライアントの異なる集まりが給料支払い簿サービスを起動して給料支払い簿サービスの結果（給与）を読み取ることができる。そこで、クライアントは、結果へのアクセス権を取得するために別の認証プロセスを適用される必要があり、これは、結果に関する通知で指定された認証サービスから結果に対する認証証明書を受け取る作業も含む。
【０３２６】
メッセージ・ゲートにより、ほとんどのセキュリティ・チェックの負担がサービスから取り除かれる。サービスでは、能力の発揮と、クライアントの認証に集中することができる。クライアントが要求された（または割り当てられた）能力にのみアクセスできるようにする際に、特権は最低限にするという原則が守られる。
【０３２７】
セキュリティ・チェックは、ゲートの作成時および／またはゲートの使用時（メッセージを発送かつ／または受け取るとき）に実行される。クライアントが通知されたアイテム（サービス）へのアクセスを要求したときに、ゲート作成のプロセスが開始する。このプロセスで、クライアント・ゲート・ファクトリは、サービスと連携して、互いに相互認証を行う。ゲート作成時に実行されるチェックは広範にわたり、ゲートの使用時に実行されるチェックの回数が最小限に抑えられる。サービスでクライアントを認証した後、サービスはクライアントの特定の能力を判別し（たとえば、サービスでクライアントがどのようなことを実行することを許されているか）、その能力をクライアントの認証証明書に関連付けることができる。これらの特定の能力により、サービス上でクライアントがどのような操作を実行することを許されるかを指定できる。ゲートではすべてのメッセージに認証証明書が含まれることを確認するので、サービスでは、受け取ったときのそれぞれの要求を認証されたクライアントの能力に照らし合わせてチェックすることができる。
【０３２８】
ゲート作成チェックでは、ＸＭＬメッセージ・スキーマによって指定されたサービス能力の一部または全部を使用する許可がクライアントにあることを確認する。一実施形態では、これらのチェックは、Ｋｅｒｂｅｒｏｓなどの認証サービスとともにアクセス制御リスト（ＡＣＬ）を使用して実施する。チャレンジ−応答シーケンス（パスワードなど）も、クライアントの認証に使用できる。いくつかの実施形態では、ハードウェア・ベースの物理的識別方法を使用してクライアントを認証することができる。たとえば、ユーザは、識別と承認のためにスマート・カードなどの物理的識別機能を提供することができる。認証のための他のメカニズムも、他の実施形態で使用できる。
【０３２９】
一実施形態では、クライアントを認証するためにどのような手段を使用するとしても、認証はクライアントとサービスの両方に見えないものであり、ゲート・ファクトリが使用する認証サービスを認識し、その認証サービスが認証メカニズムとポリシーを取り扱う。ゲート・ファクトリは、製品と環境に依存しているか、または構成管理システムによって制御することさえできる。一実施形態では、クライアント独立の程度と方法はプラットフォーム依存であるが、ゲート・ファクトリには認識される。いくつかの実施形態では、ハードウェア・ベースの物理的識別方法を使用してクライアントを認証することができる。たとえば、ユーザは、識別と承認のためにスマート・カードなどの物理的識別機能を提供することができる。認証のための他のメカニズムも、他の実施形態で使用できる。
【０３３０】
分散コンピューティング環境のメッセージ・ゲートは、通常、単一のクライアントと関連付けられている。ゲート・ファクトリは関連付けの手段を決定する。メッセージを送るときに実行されるチェックにより、適切なクライアントがゲートを使用していることが確認される。一実施形態では、ゲートはメッセージで渡され、新しいクライアントがそのゲートを使用することを望んでいる場合、クローンが作成される。クローン・プロセスで、一組の作成チェックが新しく実行される。
【０３３１】
スペースのクライアントがスペース・サービスの通知を見つけると（クライアントは他のサービスでもよい）、スペースのクライアントは他のサービスの場合と同様にスペース・サービスを実行する。スペース・サービスを実行するには、認証メカニズムを使用する必要がある。スペース・サービスの実行ではそれに限定されないが、以下のことを行う。
１．スペースのクライアントは、まず、スペース・サービスのサービス通知で指定されている認証サービスを実行して認証証明書を取得する。
２．スペースのクライアントは、認証証明書、スペースのＸＭＬスキーマ（スペースのサービス通知からの）、およびスペースのＵＲＩ（スペースのサービス通知からの）を使用して、スペースのゲートを構築する。一実施形態では、クライアントはゲート構築するための情報をゲート・ファクトリに渡す。
３．スペースのクライアントは、そのゲートを使用してメッセージをサービスに送ることによりそのスペース・サービスを実行する。
４．スペース・サービスは、クライアントから認証証明書を埋め込んだ第１のメッセージを受け取ったときに、クライアントが使用したのと同じ認証サービスを使用してクライアントを認証するための認証証明書を取得し、クライアントの素性を確定する。
５．スペース・サービスは、その後、クライアントの能力（たとえば、クライアントがスペース・サービス上で実行を許されているもの）を判別し、その能力を認証証明書にバインドする。
【０３３２】
「スペース」の項で説明しているように、スペース機能は、生成元のスペースと実質的に同じ機能（同じＸＭＬスキーマ）を持つ空のスペースを生成するインターフェースを備えることができる。
【０３３３】
図４２は、一実施形態による、分散コンピューティング環境での、新しいスペースの保護された作成を示す流れ図である。１９５０に示されているように、クライアントは、第１のスペース・サービスにアクセス（たとえば接続）することができる（サービスは、アクセスまたは他の形でのスペースの使用に関してクライアントとして働くことができる）。１９５２に示されているように、クライアントが第１のスペースのインターフェースに適当な要求を送ることによるなど、第２のスペースの作成を要求することができる。スペースの作成を要求するクライアント（スペース・サービスのクライアントとして働くサービスを含む）を、要求元クライアントと呼ぶ場合がある。それに応答して、１９５４に示されているように、第２のスペースに伴う第２のスペース・サービスを、第２のインターネット・アドレスで作成することができる。上と同様に、第２のスペース・サービスに、第２のスペース・サービスの関数を呼び出すのに使用可能である１つまたは複数のメッセージを指定する第２のスキーマを含めることができる。第２のスキーマに、少なくとも第１のスキーマを含めることができ、第２のスキーマに、追加の機能も含めることができる。
【０３３４】
第２のスペースを、当初は、要求元クライアントだけにアクセスを許可するように構成することができる。一実施形態では、１９５６に示されているように、第２のスペースに関してルート認証トークンを作成する。やはり１９５６に示されているように、第２のスペースに関連する認証サービスを初期化することができ、これによって、第２のスペースを、ルート認証トークンを保持するクライアントだけにアクセスを許可するように構成する。１９５８に示されているように、ルート認証トークンを、要求元クライアントまたはサービスに送ることができる。１９６０に示されているように、要求元クライアントが、第２のスキーマで指定されたメッセージの少なくとも１つを第２のスペースに送ること、ルート認証トークンを使用することによって、第２のスペースにアクセスすることができる。
【０３３５】
したがって、一実施形態では、要求する側が、スペースを作成した時に、その要求する側だけが、作成されたスペースへのアクセスを許可される。たとえば、作成されたスペースを、保護されることをクライアントが必要とするサービスからの結果を格納するためのものとすることができる。一実施形態では、このセキュリティを、下記によって保証することができる。
・　１９５６で示されるように、初期ルート認証トークンを作成し、生成されたスペースの認証サービスを初期化する際に、認証サービスがルート認証トークンのみを認証し、他の認証証明書を返さないようにする（最初に許可されている生成されたスペースのクライアントはほかにない）。
・　　生成されたスペースのセキュリティ・ポリシーを初期化し、ルート認証トークンに関連付けられたルートＩＤで、セキュリティ管理機能を含むスペースのすべての機能にアクセスできるようにする。
・　１９５８で示すように、ルート認証トークンおよび生成されたスペースのサービス通知を生成されたスペースのリクエスタに返す。
【０３３６】
リクエスタは、生成されたスペースにアクセスするためのゲートを構築するが、それは、認証証明書と生成されたスペースのサービス通知を返すからである。一実施形態では、リクエスタとリクエスタが認証証明書と生成されたスペースのサービス通知を渡すクライアントまたはサービスのみが生成されたスペースにアクセスできる。生成されたスペースへのアクセスをこのように制限することは、たとえば、クライアントとサービスが結果をプライベートの状態に保持する場合にクライアントおよびサービスがその生成されたスペースを使用して結果を格納するときに役立つ。
【０３３７】
サービスを実行した後、クライアントはセキュリティ管理スペース機能を使用して生成されたスペースの認証ポリシーを変更し、その後、他のクライアントまたはサービスはその生成されたスペースにアクセスできる。さらに、発見プロトコルまたはその他の手段を用いて、生成されたスペースのサービス通知を生成されたスペースの他のクライアント（他のクライアントはサービスでもよい）から利用できるようにする。
【０３３８】
分散コンピューティング環境でのメッセージ・トランスポート・レイヤは、トランスポート時にクライアントとサービスとの間の通信のセキュリティおよび安全性を保護するメカニズムを備える。このようなセキュリティは、「ワイヤ・セキュリティ」または「トランスポート・セキュリティ」と呼ばれるものであり、これにより、ゲートを含むメッセージング・システムにより実装された認証セキュリティから区別できる。メッセージの暗号化は、分散コンピューティング環境のメッセージ・トランスポート・レイヤで行われる。暗号化されたトランスポートを要求するサービスは、ＸＭＬ通知にタグを付けることによりそのような作業を行う。その後、ゲート・ファクトリは、ＢｌｕｅｔｏｏｔｈやＨＴＴＰＳによって提供されるものなどのセキュリティで保護されたメッセージ・トランスポートを使用するゲート（または複数のゲート）を作成する。
【０３３９】
ＨＴＴＰＳ（Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、ユーザ・ページ要求さらにＷｅｂサーバによって返されるページの暗号化および復号化を行うＷｅｂプロトコルである。ＨＴＴＰＳでは、ストリーム暗号化アルゴリズム（たとえば、ＲＣ４）に多ビット鍵サイズ（４０〜１２８ビット以上）を使用して、商用のデータ交換に対し十分な暗号化を行う。ＨＴＴＰＳは、分散コンピューティング環境でトランスポートとして使用できる。
【０３４０】
Ｂｌｕｅｔｏｏｔｈは、新しく登場したピアツーピアの無線通信規格である。Ｂｌｕｅｔｏｏｔｈ鍵生成アルゴリズムを分散コンピューティング環境で使用できる。Ｂｌｕｅｔｏｏｔｈでは暗号鍵をサポートする。暗号鍵はトランスポートに依存しているが、クライアント、サービス、および組み合わせ鍵はトランスポートに依存しないようにできる。
【０３４１】
図２６ａ−クライアントに認証証明書を提供する認証サービス
図２６ａは、一実施形態により、認証証明書をクライアントに提供する認証サービスを示す流れ図である。分散コンピューティング環境のクライアントは、クライアントのために１つまたは複数の機能を実行するサービスを必要とすることがある。一実施形態では、セキュリティで保護されたメッセージング・チャネルを設定するときにクライアントとサービスで使用する認証サービスを提供する。認証サービスは、クライアントおよび／またはサービスの認証および望むレベルのセキュリティおよびクライアントとサービスとの間で渡されるメッセージ・セットを交渉するなどの機能をクライアントおよび／サービスのために実行する。認証サービスは、分散コンピューティング環境内で実行されているプロセスでもよい。認証サービスは、サービスおよび／またはクライアントと同じデバイスで実行するか、またはそれとは別に、認証サービスは、認証サーバなどの別のデバイスで実行する。一実施形態では、認証サービスはインターネット・ベースのサービスである。認証サービスは、それ独自のアドレス、たとえば、Ｕｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を持ち、これにより、クライアントおよび／またはサービスは認証サービスと通信できる。一実施形態では、認証サービスのアドレスを、サービスのサービス通知でクライアントに提供する。認証サービスを共有するクライアントおよびサービスを使用すると、クライアントとサービスとの間でセキュリティで保護されたメッセージング・チャンネルを確立し、いくつかのセキュリティおよび認証プロトコルのどれかをメッセージング・チャネルで使用できる。
【０３４２】
一実施形態では、クライアントはクライアントＩＤトークンまたは証明書を認証サービスに提示する。クライアント・トークンまたは証明書は十分に忘れがたいものであり、クライアントの素性を証明するものとして使用できる。次に、認証サービスは、クライアントＩＤトークンまたは証明書をチェックし、クライアントに、認証サービスのみが作成できる認証証明書を発行する。クライアントに返された認証証明書は、次に、クライアントによりすべてのメッセージに入れられてサービスに送られる。一実施形態では、クライアント・メッセージ・ゲートはゲート・ファクトリによって作成され、認証証明書をメッセージ・ゲートに格納すると、メッセージ・ゲートはクライアントに代わって認証証明書をすべてのメッセージに入れてサービスに送る。メッセージを受け取ると、サービスは認証証明書をチェックする。認証サービスのみが認証証明書を作成できるので、クライアントが認証証明書を改ざんしていないとサービスは認識する。一実施形態では、サービスは認証証明書をクライアントによって使用される同じ認証サービスに渡し、認証証明書が有効であることを確認し、クライアントが承認されたクライアントであることを検証し、クライアントの素性を調べる。
【０３４３】
スペース・サービスおよび認証サービスを含むすべてのサービスはそのクライアントを認証することができる。サービスによってクライアントの認証が行われると、クライアントはそのサービスにアクセスできる。たとえば、スペース・サービスの場合、クライアントはスペースからＸＭＬ通知を取得する。
【０３４４】
一実施形態では、サービスはそのサービスのすべてのクライアントが使用するあらかじめ整えられている証明書を用意する。この実施形態では、認証により、そのあらかじめ整えられた証明書が要求側クライアントに提供される。クライアントはあらかじめ整えられている証明書をサービスに提示すると、サービスによって承認される。
【０３４５】
ステップ１０００で、クライアントは認証証明書を認証サービスに要求する。一実施形態では、クライアントは目的のサービスのサービス通知をサーチし、特定する。一実施形態では、サービス通知はサービスにアクセスする際に使用される認証証明書を取得するために使用する認証サービスの通知を含む。一実施形態では、サービス通知は、認証サービスのＵＲＩなどのアドレスを含む。一実施形態では、クライアントは認証証明書を要求する認証サービスに情報を送る。一実施形態では、クライアントは情報をゲート作成プロセス、たとえば、ゲート・ファクトリに送り、ゲート作成プロセスは認証サービスにアクセスして認証証明書を取得する。
【０３４６】
ステップ１００２で、認証サービスはクライアントのために認証証明書を生成する。認証証明書は、メッセージング・システムのメッセージに埋め込むことができ、これによりメッセージの受取側がメッセージの発送側を認証し、メッセージが承認された発送側からのものであることを検証し、メッセージが発送側が受取側に送ることを許可されているメッセージであることを検証できるようにするデータ要素またはデータ構造である。分散コンピューティング環境の一実施形態では、認証証明書は特定のクライアントと特定のサービスとの間に設定されるメッセージング・チャンネルに固有のものである。ステップ１００２は、図２６ｂに詳しく示され、説明されている。図２６ａのステップ１００４で、認証サービスはクライアントに認証証明書を返す。一実施形態では、認証証明書は、クライアントに直接返すことができる。一実施形態では、認証証明書をゲート作成プロセス、たとえば、ゲート・ファクトリに返し、このプロセスが次に、認証証明書を使用してゲートを生成する。
【０３４７】
図２６ｂ−認証証明書を生成する認証サービス
図２６ｂは一実施形態により、図２６ａのステップ１００２で展開し、認証証明書を生成する認証サービスを示す流れ図である。一実施形態のステップ１００２ａで、認証サービスはクライアント・トークンとサービス・トークンを取得する。他の実施形態では、認証サービスはクライアント・トークンのみを取得する。一実施形態では、クライアント・トークンは分散コンピューティング環境におけるクライアントの一意的な識別子である。一実施形態では、サービス・トークンは分散コンピューティング環境におけるサービスの一意的な識別子である。たとえば、公開／秘密鍵暗号化メカニズムの公開鍵をクライアントとサービスに対する一意的な識別子として使用することができる。一実施形態では、クライアントはサービス通知でサービス・トークンを受け取り、クライアントはクライアント・トークンとサービス・トークンを認証サービスに送る。他の実施形態では、クライアントはクライアント・トークンとサービス通知ＵＲＩを認証サービスに送り、認証サービスはサービス通知からサービス・トークンを取り出すことができる。
【０３４８】
ステップ１００２ｂで、認証サービスはクライアントおよび／またはサービスを検証する。一実施形態では、認証サービスはステップ１００２ａで取得したクライアント・トークンおよびサービス・トークンを使用して、クライアントおよび／またはサービスを検証する。他の実施形態では、ステップ１００２ａでクライアント・トークンのみを取得しており、１００２ｂでクライアント・トークンのみを使用してクライアントを検証する。一実施形態では、クライアントはそのクライアント・トークンをすでに認証サービスに登録しており、認証サービスは受け取ったクライアント・トークンを登録されているクライアント・トークンと比較し、クライアントが有効なクライアントであるかどうかを検証することができる。一実施形態では、クライアントはパスワードが設定されているログオン・アカウントなどのチャレンジ／応答メカニズムを使用して認証サービスにアクセスし、クライアントを有効なクライアントとして検証することができる。一実施形態では、サービスはすでに認証サービスに登録されており、そのサービス・トークンを認証サービスに提供してある。認証サービスは、次に、受け取ったサービス・トークンをすでに登録されているサービス・トークンと比較して、クライアントが有効なサービスにアクセスしようとしていることを検証する。他のタイプのクライアントおよびサービス認証も使用できる。たとえば、クライアントは、認証サービスがクライアントを認証するためにかつ／またはクライアントがアクセスしようとしているサービスを認証するために使用できる電子シグネチャまたは電子証明書を提供する。
【０３４９】
ステップ１００２ｃで、認証サービスは認証証明書を生成する。一実施形態では、認証証明書は、認証サービスのみが作成できる認証トークンを含む。一実施形態では、認証サービスはクライアント・トークンとサービス・トークンを使用して認証証明書を生成する。他の実施形態では、認証サービスはクライアント・トークンだけを使用して、認証証明書を生成する。さらに他の実施形態では、認証サービスは認証証明書の生成に取得されているトークを使用しないが、その代わりに、認証証明書生成アルゴリズムを使用して実質的に忘れることはできない認証証明書を生成することができる。一実施形態では、認証サービスはサービス・トークンとクライアント・トークンを組み合わせて、一意的な認証証明書を生成する。たとえば、サービス・トークンとクライアント・トークンを６４ビット値とし、この２つのトークンを組み合わせて１２８ビットの認証証明書を生成することができる。他の実施形態では他の方法を使用して、認証証明書を生成することができる。
【０３５０】
デバイスを分散ネットワーク環境にブリッジする方法
分散コンピューティング環境で実装されるメッセージ通信モデルをサポートしないデバイスが、分散コンピューティング環境の外部にある。これらのデバイスは、分散コンピューティング環境のクライアントにとって有用と思われるサービスを備えている場合がある。分散コンピューティング環境には、このような外部デバイスを分散コンピューティング環境にブリッジするメカニズムが備えられている。分散コンピューティング環境内のクライアントはこのようなデバイスに用意されているサービスにアクセスすることができる。分散コンピューティング環境ではさらに、分散コンピューティング環境で使用するこのような外部デバイスを発見するため既存のデバイス発見プロトコルを活用することができる。
【０３５１】
多くの技術が、ネットワークのデバイス構成をパブリッシュし、監視するための発見プロトコルを定義している。これらの技術には、これらに限定されないが、Ｊｉｎｉ、ＳＬＰ、Ｂｌｕｅｔｏｏｔｈ、ＵＰｎＰがある。さらに、ＬｏｎＷｏｒｋｓ、ＵＳＢ、および１３９４などの多くの入出力バスも動的発見プロトコルをサポートしている。分散コンピューティング環境では、実装をＡＰＩでラップすることにより、デバイス発見技術を活用する。他のデバイス発見プロトコルを活用し、他の発見プロトコルにブリッジする方法を使用することにより、分散コンピューティング環境で、さまざまなネットワークおよび入出力バス上のデバイスまたはサービスを発見することができる。分散コンピューティング環境のデバイス発見は、したがって、分散コンピューティング環境に直接参加していなくても、ＰＤＡなどの小型デバイスを含むさまざまなデバイスに応用できる。発見プロトコルは、メッセージ・レベルで定義することができる。
【０３５２】
ブリッジ・メカニズムは、分散コンピューティング環境用のメッセージングＡＰＩでＢｌｕｅｔｏｏｔｈなどの１つまたは複数のを特定のデバイス発見プロトコルを「ラップ」する方法として提供される。ラップでは、コードおよび／またはデータ（ＡＰＩ）でデバイス発見プロトコルの枠組みを作り、プロトコルを分散コンピューティング環境内のクライアントおよび／またはサービスによって実行できるようにするが、そうでないとこれは実行できない。ブリッジ・メカニズムを実行すると、特定のデバイス発見プロトコルによりデバイスを発見する発見エージェントが分散コンピューティング環境のスペース内のデバイスに対しサービスをパブリッシュすることができる。サービスが分散ネットワーク環境でＸＭＬメッセージ・スキーマ・インターフェースをクライアントに提示し、特定のデバイス発見プロトコルにより発見されたさまざまなデバイスを動作させることができる。したがって、サービス通知は、基礎のラップされたデバイス発見プロトコルにより発見されたさまざまなデバイスを動作させるサービスに対してパブリッシュされる。そこで、通知されたサービスは、分散ネットワーク環境の外部にあるデバイス（またはサービス）を分散ネットワーク環境上のクライアントにブリッジする。
【０３５３】
図２７は、スペース１２００を持つ分散コンピューティング環境の一実施形態を示している。１つまたは複数の発見エージェント１２０４が、外部発見プロトコルに参加し、ブリッジ・メカニズム１２０２を通じて分散コンピューティング環境にブリッジする。ラップされたデバイス発見プロトコルを実行すると、ブリッジ・メカニズム１２０２を介した発見エージェント１２０４はスペース１２００内のサービス通知１２０６ａ〜１２０６ｃをパブリッシュし、そこで、通知１２０６ａ〜１２０６ｃのそれぞれが分散コンピューティング環境の外部にある発見プロトコル１２０４のうちの１つにより発見されるデバイスまたはサービスに対応する。クライアントは、その後、スペース１２００内のサービス通知１２０６ａ〜１２０６ｃを使用して外部デバイスにアクセスし、対応する外部デバイスまたはサービスを動作させるエージェント１２０４のうちの１つでサービスをインスタンス化する。
【０３５４】
そこで、分散コンピューティング環境のクライアントは、デバイス発見プロトコルをラップする発見エージェントを使用してデバイスを見つける。これらのデバイスとのブリッジとして機能するサービスをスペース内でパブリッシュし、通知して、分散コンピューティング環境のクライアントが外部デバイスによって提供されるサービスにアクセスできるようにする。通知されたサービスは、他のプロトコルまたは環境により分散コンピューティング環境の外部のデバイスを呼び出すことができる分散コンピューティング環境内のサービスであり、外部のデバイス／サービスを分散コンピューティング環境にブリッジする。分散コンピューティング環境内のクライアントは、分散コンピューティング環境内の通知されたサービスのみを「見」、外部のデバイス／サービスに気付くことすらしない。
【０３５５】
一実施形態では、分散コンピューティング環境は上述のラップされたデバイス発見プロトコルを含む基礎の外部デバイス発見プロトコルにマップされる、「スペース」の項で説明した発見プロトコルなどの特定のバージョンのスペース発見メッセージ・プロトコルを提供する。マップされた発見プロトコルは、スペース、デフォルト・スペースに自己登録するかまたは登録されるが、その際に、そのスペースに通知を入れる。通知される発見プロトコルごとに、発見プロトコルの結果を保持する後続の結果スペースが提供される。
【０３５６】
図２８は、一実施形態によりＢｌｕｅｔｏｏｔｈ発見サービス１２２０にマップされるスペース発見プロトコルの一例の図である。Ｂｌｕｅｔｏｏｔｈ発見サービス１２２０は、まず、分散コンピューティング環境に登録する１２３０。Ｂｌｕｅｔｏｏｔｈ発見サービス１２２０は、ブリッジＡＰＩでラップされ、発見サービス１２２０の通知１２２５がスペース１２２４に追加される１２３２。クライアントまたはサービスが、スペース１２２４上の発見サービス通知１２２５を特定する。発見サービス１２２０が実行されると（発見プロトコル１２２０と分散コンピューティング環境１２２２との間のブリッジとしてＡＰＩラッパを使用して）、発見プロセスの結果を格納するための新しいスペース１２２６が作成される１２３４。発見サービス１２２０は、それらの結果を（再び、ＡＰＩラッパを使用して）１つまたは複数の通知１２２７として発見結果スペース１２２６に格納する。それとは別に、発見サービス１２２０を実行した結果は分散コンピューティング環境のスペース１２２４または他の既存のスペースに格納される。図２８に示されているような方法を使用してデバイスを発見し、他の基礎の発見プロトコルを使用して他のサービスを発見する。
【０３５７】
上述のように、分散ネットワーク環境で実装されるメッセージ通信モデルをサポートしないデバイスが、分散ネットワーク環境の外部にある。これらのデバイスは、分散コンピューティング環境で提供されるサービスを使用する必要があるクライアントを備えることもある。分散コンピューティング環境は、外部クライアントまたはクライアント・デバイスを分散コンピューティング環境にブリッジするメカニズムが備えられており、外部デバイスのクライアントは分散コンピューティング環境内のサービスにアクセスすることができる。
【０３５８】
分散コンピューティング環境でクライアントとして使用されるエージェントを用意し、外部クライアントを分散コンピューティング環境にブリッジし、外部クライアントが分散コンピューティング環境内でパブリッシュされているサービスにアクセスできるようにする。一実施形態では、エージェントは、フロント・エンドでメッセージ通信モデルと専用プロトコル（たとえば、外部デバイスによってサポートされているプロトコル）を使用して外部デバイスにインターフェースし、さらに外部クライアントにインターフェースする分散コンピューティング環境内のサービスと通信することができるＸＭＬ対応バックエンドを備える。したがって、分散コンピューティング環境の外部のクライアントは、ブリッジ・エージェントを通じて分散コンピューティング環境内のサービスを特定してアクセスし、要求をサービスに送って結果データを含む応答をサービスから受け取ることができる。たとえば、外部クライアントは分散コンピューティング環境でブリッジ・エージェントを使用してスペース発見を実行し、通知されたサービスをルックアップし、分散コンピューティング環境内のサービスを呼び出す。
【０３５９】
一実施形態では、分散コンピューティング環境は分散コンピューティング環境クライアントからＪｉｎｉサービスにアクセスするためのブリッジ・メカニズムを備える。Ｊｉｎｉサービスはリモート・メソッド呼び出し（ＲＭＩ）を必要とし、また分散コンピューティング環境内のクライアントはＸＭＬメッセージなどのメッセージを使用してサービスと通信するので、分散コンピューティング環境クライアントによりＪｉｎｉサービスへのアクセスを可能にするプロトコル・ブリッジ・メカニズムを提供できる。一実施形態では、分散コンピューティング環境のスペース内でＪｉｎｉサービスの動的通知を有効にし、さらに分散コンピューティング環境内のクライアントからＪｉｎｉサービス・プロキシのアクセスを有効にすることができるコネクタ・メカニズムを定義する。一実施形態では、分散コンピューティング環境にブリッジできないＪｉｎｉサービスもある。
【０３６０】
一実施形態では、Ｊｉｎｉサービスによって使用されるＪｉｎｉ　ＲＭＩプロトコルを分散コンピューティング環境のクライアントによって使用されるＸＭＬメッセージングにブリッジするエージェントを分散コンピューティング環境内のサービスとして提供することができる。エージェントを起動すると、エージェントはＪｉｎｉスペースで一組の属性を持つＪｉｎｉサービスのルックアップを実行する。登録されているすべてのＪｉｎｉサービスについて、エージェントは、サービスに対応するＸＭＬ通知を生成し、分散コンピューティング環境内のスペースで通知を登録する。一実施形態では、エージェントは、Ｊｉｎｉルックアップ・サービスのイベント通知について登録でき、新しいＪｉｎｉサービスが登録されると実行される。新しいＪｉｎｉサービスが通知されると、エージェントはＪｉｎｉスペースで検索を実行し、新たに通知されたＪｉｎｉサービスを特定し、分散コンピューティング環境のスペースを新しいサービスに対する新しいＸＭＬ通知で更新する。一実施形態では、Ｊｉｎｉサービスが削除されると、エージェントはＪｉｎｉサービスの削除を通知するイベントを受け取る。エージェントは、サービスのＸＭＬ通知をスペースから削除する。
【０３６１】
一実施形態では、分散コンピューティング環境のスペースのＸＭＬ通知を介してＪｉｎｉサービスを呼び出すには、クライアントはスペース内のサービス通知をルックアップし、有効なメッセージをエージェントに送ってサービスにアクセスする。エージェントは、サービス・プロキシに対するＲＭＩコールを介して対応するメソッドを呼び出してＪｉｎｉサービスに対応するプロキシ・サービスを呼び出す。プロキシがインスタンス化されていない場合、エージェントはプロキシ・コードをダウンロードし、プロキシ・オブジェクトの新しいインスタンスをインスタンス化する。一実施形態では、すべてのクライアント接続は異なるプロキシ・インスタンスを持つ。クライアントから着信したメッセージは、エージェントによってプロキシのメソッド・コールに変換される。メソッド・コールからの結果は発信メッセージとしてクライアントに返される。
【０３６２】
一実施形態では、ＲＭＩメソッドへの引数として、単純なＪａｖａの型のみを使用できる。Ｊａｖａの複合型が必要な場合、１つまたは複数のデータ通知をコールの引数として渡し、データ通知はＪａｖａ複合型のデータの位置とアクセス方法を示す。一実施形態では、エージェントがＸＭＬメッセージがＲＭＩメソッド・コール呼び出しへの初期変換を動的に実行する。エージェントはサービス・インターフェースを認識するので、クライアントに通知される対応するメッセージ・セットを生成する。
【０３６３】
図２９は、分散コンピューティング環境の外部にあるクライアント１２５０を分散コンピューティング環境内のスペース１２５４にブリッジする方法を示す図である。ブリッジ・エージェント１２５２は、クライアント１２５０とスペース１２５４との間の仲介者として使用される。ブリッジ・エージェント１２５２は、クライアント１２５０が理解できる通信プロトコルでクライアント１２５０と通信する。ブリッジ・エージェント１２５２は、クライアントの通信プロトコルを、スペース１２５４によって提供される機能を実行するためにスペース１２５４と通信するために必要なＸＭＬメッセージング・プロトコルにマップする。ブリッジ・エージェント１２５２は、クライアント１２５０の要求があったときに、スペース１２５４上のサービスを特定して実行する。たとえば、クライアント１２５０は、スペース１２５４に特定のタイプのすべてのサービスのリストを要求することができる。ブリッジ・エージェント１２５２は、サービス通知１２５６ａ〜ｃを特定し、結果をクライアント１２５０に返す。それとは別に、結果を結果スペースにポストし、結果の位置をクライアント１２５０に返す。クライアント１２５０は、その後、サービス通知１２５６ａの実行を選択し、メッセージ（クライアント１２５０の通信プロトコルで）をブリッジ・エージェント１２５２に送る。ブリッジ・エージェント１２５２は、そこで、サービス通知１２５６ａによって表されるサービスを実行するのに必要なＸＭＬ要求メッセージを送り、サービスの結果をクライアント１２５０に返す。結果をクライアント１２５０に直接返す以外のサービスの結果の処理方法は、上の「スペース」の項で説明しているように使用できる。ブリッジ・エージェント１２５２は、外部クライアント１２５０のサービスとして機能し（外部クライアントのプロトコルを介して）、また分散コンピューティング環境内のクライアントとして機能して、分散コンピューティング環境内のサービスを外部クライアントにブリッジする。
【０３６４】
ときには、分散コンピューティング環境内であっても、クライアントおよびサービスは互いに直接通信し、また共通のスペースとのみ通信することはできない。この場合、スペース・サービスはクライアント・サービスにブリッジするサービス・プロキシを自動的に作成する。プロキシの主要な役目は、スペースを介してクライアントとサービスとの間でメッセージをやりとりすることである。サービス・プロキシは動的に作成される。作成メカニズムは、スペースの実装に左右される。プロキシ・メカニズムの説明については、図３０を参照のこと。クライアント５５４およびサービス５５６は、たとえば、これらが異なるトランスポートまたはネットワーク・プロトコルをサポートしているため、分散コンピューティング環境内で直接通信することができない場合がある。ただし、両方とも両方のプロトコルをサポートするスペース５５２とは通信できる。スペース・サービスは、クライアント５５４をサービス５５６にブリッジするプロキシ５５０を作成する。プロキシの共通の形態はブラウザ・プロキシである。プラザ・プロキシ（サーブレットとして実装されるは最も一般的である）は、従来のＷｅｂページ要求をメッセージに変換する。「スペース」の項のスペースルックアップ・サービス（およびプロキシ）の説明も参照のこと。
【０３６５】
分散コンピューティング環境は、分散コンピューティング環境内のクライアントをエンタプライズ・サービスにブリッジするメカニズムを備える。分散コンピューティング環境の一実施形態では、クライアントをエンタプライズ・サービスにブリッジする方法は、分散コンピューティング環境内のクライアント、分散コンピューティング環境内のブリッジ・サービス、およびエンタプライズ環境内のエンタプライズ・サービスを含む。分散コンピューティング環境のブリッジ・サービスは、クライアントとエンタプライズ・サービスとの間のブリッジ・サービスとして使用される。エンタプライズは、企業、中小企業、非営利団体、政府機関、またはその他の種類の組織である。エンタプライズでは、その事業の一部を実施するためにエンタプライズ・コンピューティング環境を利用する。エンタプライズ・コンピューティング環境は、さまざまなエンタプライズ・サービスを含む。分散コンピューティング環境内のクライアントは、エンタプライズ・コンピューティング環境のサービスを使用することを望んでいる場合がある。エンタプライズ・サービスは、三層クライアント／サーバ・アーキテクチャなどのさまざまなアーキテクチャに基づく。エンタプライズ・サービスを実装するのに使用できるアーキテクチャの一例としてＥｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓがある。Ｅｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓ（ＥＪＢ）は、クライアント／サーバ・モデルを使用してエンタプライズ環境のサーバー部分で実行する、Ｊａｖａプログラミング言語で書かれたプログラム・コンポーネントを設定するアーキテクチャである。オブジェクト指向プログラミングおよび分散オブジェクト技術では、コンポーネントとは、アプリケーションを形成するために分散ネットワーク内で同じコンピュータまたは他のコンピュータ内の他のコンポーネントと組み合わせて再利用可能なプログラムの基本要素のことである。ＥＪＢは、プログラム・コンポーネント（Ｂｅａｎｓ）をネットワーク内のクライアントに配布するＪａｖａＢｅａｎｓ技術に基づき構築されている。ＥＪＢ　Ｂｅａｎまたはコンポーネントを配置するには、コンテナと呼ばれる特定のアプリケーションの一部である必要がある。Ｅｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓには、ｓｅｓｓｉｏｎ　ｂｅａｎｓとｅｎｔｉｔｙ　ｂｅａｎｓの２種類のｂｅａｎｓがある。ｅｎｔｉｔｙ　ｂｅａｎｓは、ｓｅｓｓｉｏｎ　ｂｅａｎｓと異なり、永続性があり、最初の動作または状態を保持できるものである。ＥＪＢを使用すると、実質的にすべての主要なオペレーティング・システムに配置することができる。ＥＪＢのプログラム・コンポーネントは、一般にサーブレット（小さなサーバ・プログラム）と呼ばれている。サーブレットを実行するアプリケーションまたはコンテナは、アプリケーション・サーバと呼ばれることもある。
【０３６６】
ブリッジ・サービスは、ＸＭＬメッセージ通信を介してクライアントと対話し、分散ネットワーク環境の外にあるエンタプライズ・サービスに要求を行うのに必要な入力パラメータを収集する。たとえば、クライアントが分散コンピューティング環境内の他のサービスとまったく同様にブリッジ・サービスをルックアップし、インスタンス化することができる。ブリッジ・サービスは、エンタプライズ・サービスと対話して、エンタプライズ・サービスを実行する。この対話では、エンタプライズ・サービスが理解できるプロセス間通信アーキテクチャを使用する。たとえば、エンタプライズ・サービスがＥｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓ（ＥＪＢ）で実装されている場合、ブリッジ・サービスはＥＪＢを使用してエンタプライズ・サービスと通信する。ブリッジ・サービスは、エンタプライズ・サービスから結果を受け取り、その結果を直接クライアントに（ＸＭＬメッセージで）返すか、またはその結果を分散ネットワーク環境内のスペース（たとえば、結果スペース）に入れることができる。クライアントからは、ブリッジ・サービスは唯一のサービスのように見えるため（エンタプライズ・サービスはクライアントには隠されている）、クライアントはエンタプライズ・サービスのアーキテクチャをサポートする必要がない。複数の分散ネットワーク環境のクライアントが同じブリッジ・サービス（それぞれ、一意的なゲート・ペアを使用する）を使用して、エンタプライズ・サービスと対話する。
【０３６７】
ブリッジ・サービスまたはその他のエージェントは、分散コンピューティング環境内のスペースでブリッジ・サービス（およびエンタプライズ・サービス）の通知をパブリッシュする。たとえば、ブリッジ・サービスまたはその他のブリッジ・エージェントはＪａｖａリフレクションを使用して、ＥＪＢで実装されているエンタプライズ・システム内のサービスについてＢｅａｎｓを調べ、Ｂｅａｎｓへのブリッジ・サービスのサービス通知を作成し、分散コンピューティング環境内のスペースにそれらの通知をパブリッシュする。リフレクションは、クラスのフィールド、メソッド、およびコンストラクタに関する情報を発見し、セキュリティ制限の範囲内でオブジェクトに対する基礎の対応する部分の上で動作するリフレクトされたフィールド、メソッド、およびコンストラクタを使用するＪａｖａコードのメソッドである。リフレクションＡＰＩは、ターゲット・オブジェクトの公開メンバまたは所定のクラスで宣言されているメンバのいずれかにアクセスするのが必要なアプリケーションに対応している。ブリッジ・サービスが通知されると、クライアントは、サービスを提供するエンタプライズ・サービスのアーキテクチャを詳細を知ることなく、分散ネットワーク環境内の他の通知されたサービスと同様にブリッジ・サービス（およびしたがって対応するエンタプライズ・サービス）にアクセスできる。
【０３６８】
クライアントのディスプレイ
クライアントによって実行されたサービスからの結果を分散コンピューティング環境内で表示する方法はいくつかある。結果を表示するデバイスとしては、コンピュータのＣＲＴ、ラップトップのＬＣＤ、ノートブック・パソコンのディスプレーなど、プリンタ、スピーカ、および視覚的、聴覚的、またはその他の知覚可能な形式でサービスの結果を表示できるその他のデバイスがある。結果を表示する方法にはそれに限定されないが、次のものがある。
サービスが結果をクライアントに直接、または参照により返し、クライアントはそれらの結果の表示を処理する。
サービスが結果をクライアントに直接、または参照により返し、クライアントはそれらの結果を表示サービスに直接、または参照により渡し、表示サービスがそれらの結果を表示する。
サービスが結果の表示を直接処理する。
サービスが結果を表示サービスに直接、または参照により渡し、表示装置はそれらの結果を表示する。
【０３６９】
結果を表示する最後の方法では、クライアントが表示サービスを指定する。たとえば、クライアントがサービスの結果を表示するために使用することを望んでいるクライアントが常駐するデバイスの表示サービスまたは関連する表示サービスがある。クライアントがサービスを実行すると、クライアントはメッセージをサービスに送り、クライアントの表示サービスのサービス通知を指定する。その後、サービスは、ゲートを構築し、メッセージをクライアントの表示サービスに送ることができるようにする。したがって、結果を表示するとき、クライアントによって呼び出されたサービスはクライアントの表示サービスのクライアントとなり、その結果を（直接または参照により）表示のためその表示サービスに送る。クライアント−サービス間の関係、ゲート、およびメッセージングの詳細については、本書の他の項を参照のこと。
【０３７０】
従来のアプリケーション・モデルは、通常、所定のおおむね静的なユーザ・インターフェースおよび／またはデータ特性に基づく。従来のアプリケーションに変更を加えるには、コードを修正し再コンパイルする必要がある。サービスを通知し、分散コンピューティング環境のサービスと通信するためのＸＭＬメッセージ・スキーマを指定するための記述されたメカニズムを使用して、アプリケーション（クライアント、サービス、など）が自動的に表示オブジェクトの記述するためのメカニズムを提供する。動的表示オブジェクトを使用すると、新しいコードをダウンロードしたり、アプリケーションを再コンパイルしたり、アプリケーションを再リンクすることなく、アプリケーションの動作を変更することができる。同じ結果を異なる形式で表示する、表示のため結果の一部を抽出する、および異なる表示デバイスに結果を表示する表示スキーマを提供する。
【０３７１】
図３１は、一実施形態による関連するディスプレイ１３０２および表示サービス１３０４を備えるクライアント１３００の一実施形態の図である。表示サービス１３０４の通知１３０６をスペース１３０８に登録する。サービス１３１０の通知１３１２をサービス１３１０によりスペース１３１４に登録する。それとは別に、サービス通知１３１２および表示サービス通知１３０６を同じスペース上に登録する。クライアント１３００は、スペース１３１４上のサービス通知１３１２をサーチし発見して１３２０、サービス１３１０に要求を送る（サービス１３１０から結果または応答を受け取る）ためのゲートを設定する。一実施形態では、メッセージは通知１３１２の一部として受け取ったＸＭＬスキーマで指定したＸＭＬメッセージの形式である。クライアント１３００は、１つまたは複数のメッセージ（１３２２）をサービス１３１０に送る。この１つまたは複数のメッセージは、サービス１３１０を実行するメッセージと、表示のため結果を表示サービス１３０４に送るようサービス１３１０に命令するメッセージを含み、表示サービス通知１３０６の位置を指定する。通知の位置は、Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）として指定する。
【０３７２】
クライアント１３００からサービス１３１０にメッセージを命令として送ると、サービス１３１０は表示可能な結果を出力する１つまたは複数のオペレーションを実行する。サービス１３１０は、クライアント１３００から受け取った位置情報に基づいてスペース１３０８から表示サービス通知１３０６を取り出す。サービス通知は、ＸＭＬメッセージ・スキーマと、表示サービス１３０４とインターフェースするのに必要なその他の情報含む。次に、サービス１３１０は要求を表示サービス１３０４に送る（そして表示サービス１３０４から結果を受け取る）ためのゲートを設定する。他の実施形態では、クライアント１３００からサービス１３１０へのメッセージは、ＸＭＬスキーマと、サービス１３１０が表示サービス１３０４へのゲートを構築するのに必要なその他の情報を含むか、または表示サービス１３０４への事前に構築されたゲートを備える。
【０３７３】
クライアント１３００によって要求されたオペレーションの実行中、または完了した後、サービス１３１０は、表示サービス１３０４のスキーマによって指定されている方法によりオペレーションの結果を表示サービス１３０４に送る（たとえば、ＸＭＬメッセージ・スキーマでまたは表示サービスのパラメータとしての参照により指定されたＸＭＬメッセージ内にカプセル化される）。この点で、サービス１３１０は、表示サービス１３０４のクライアントである。その後、表示サービス１３０４は、クライアントのディスプレイ１３０２上にサービス１３１０から受け取った、または指示された結果をフォーマットして表示する。
【０３７４】
いくつかの実施形態では、サービス１３１０は、結果スペース（図に示されていない）などのスペースにオペレーションの結果をポストする。その後、サービス１３１０は、オペレーションも格納されている結果への参照を含むメッセージを表示サービス１３０４に送る。一実施形態では、参照はＵＲＩの形式である。その後、表示サービス１３０４は、スペースから結果を取り出し、その結果をディスプレイ１３０２に表示する。
【０３７５】
従来のアプリケーション・モデルは、通常、所定のおおむね静的なユーザ・インターフェースおよび／またはデータ特性に基づく。従来のアプリケーションに変更を加えるには、コードを修正し再コンパイルする必要がある。サービスを通知し、分散コンピューティング環境のサービスと通信するためのＸＭＬメッセージ・スキーマを指定するための記述されたメカニズムを使用して、アプリケーション（クライアント、サービス、など）が自動的に表示オブジェクトの記述するためのメカニズムを提供する。動的表示オブジェクトを使用すると、新しいコードをダウンロードしたり、アプリケーションを再コンパイルしたり、アプリケーションを再リンクすることなく、アプリケーションの動作を変更することができる。
【０３７６】
動的表示オブジェクトはＸＭＬスキーマで記述できる。これらのスキーマは、スペース内で通知される。これらのスキーマは、表示スキーマまたは表現スキーマと呼ぶ。その後、アプリケーション（またはアプリケーションの代わりに動作するその他のサービス）は、サービス通知からスキーマにアクセスし、フォーマット、データ型、およびスキーマに格納されているその他の情報に基づきデータを表示する。
【０３７７】
動的表示オブジェクトを含むスキーマの一例を以下に示す。

【０３７８】
上記のスキーマは、アプリケーションを再コンパイルすることなく、次のように変更できる。

【０３７９】
図３２Ａおよび図３２Ｂは一実施形態により動的表示オブジェクトのスキーマを使用する例を示す図である。図３２Ａで、アプリケーション１３２０（クライアント、サービス、またはその他のアプリケーション）はスペース１３２６に格納されている表現スキーマ通知１３２４で実装されている。表現スキーマ通知は、データ型、書式指定、フォント、位置、色、およびディスプレイ１３２２にアプリケーションのデータを表示するために使用されるその他の情報を記述する要素を含む。アプリケーション１３２０のための複数の表現スキーマ通知がある。たとえば、一連の表示ページ（たとえば、ＷｅｂサイトのＷｅｂページ）内の表示ページごとに１つのスキーマがある。
【０３８０】
一実施形態では、アプリケーション１３２０は、発見および／またはルックアップ・サービスを呼び出して、表現スキーマ通知を特定する。発見および／またはルックアップ・サービスは、１つまたは複数の通知、およびＵＲＩの一覧を含むＸＭＬドキュメントを特定の表示形式などを記述するスキーマのそれぞれに返す。その後、アプリケーション１３２０は、ＸＭＬドキュメントから１つまたは複数の表現スキーマを選択する。アプリケーション１３２０は、続いて、そのスキーマを解析し、スキーマ要素をユーザ・インターフェース・コンポーネントに分解する。これらのコンポーネントは、結果データを特定し、フォーマットし、適切なディスプレイ上に表示するために使用される。結果データは、たとえば、サービスの実行または結果スペースから得られる。そこで、静的な表示または所定の表示を用意するのとは反対に、アプリケーション１３２０は、アプリケーションを再構築することなく動的に変更できる表現スキーマに従って結果を表示するように構成される。
【０３８１】
同じ結果を異なる形式で表示する、表示のため結果の一部を抽出する、および異なる表示デバイスに結果を表示する表現スキーマを提供する。
【０３８２】
一実施形態では、１つまたは複数の表現スキーマ通知を分散コンピューティング環境内の１つまたは複数のスペースに格納することができる。１つまたは複数のデバイスでアプリケーションのコピーを呼び出すと、アプリケーションのそれぞれのコピーがサービスに対するサーチを実行し、アプリケーションによって使用される表現スキーマの通知を発見する。そこで、表示情報の中央永続的ストアをアプリケーションの複数のインスタンス用または他のアプリケーション用に保持することができる。表示情報は、アプリケーションを再コンパイルしたり再インストールすることなく、中央の場所で修正することができる。
【０３８３】
図３２Ｂでは、クライアント１３２８は、スペースのサービス１３３０のサービス通知を特定する。サービス１３３０を呼び出すと、クライアント１３２８はスペース１３２６の表現スキーマ通知１３２４の位置をサービス１３３０に渡す。サービス１３３０が結果をクライアント１３２８に送る用意が整っている場合、表現スキーマ通知１３２４によって提供される表現スキーマからの表示情報を使用してディスプレイ１３２２（クライアント１３２８が実行されているデバイスに結合されている）に結果を表示することができる。結果の表示方法を変更するには、表現スキーマ通知１３２４のＸＭＬメッセージを修正するか、または異なる表現スキーマを選択すればよく、クライアント１３２８またはサービス１３３０で変更する必要はない。サービス１３３０は表示サービスでよい。
【０３８４】
クライアント、アプリケーション、またはサービスは、１つまたは複数のサービスによって提供されるさまざまなオペレーションの結果を表示するための複数の表示スキーマを備える。それとは別に、表示スキーマは１つまたは複数のクライアントのさまざまな結果を表示するための情報を含む。そこで、クライアント１３２８は、１つの表示スキーマまたは複数の表示スキーマを使用することができる。異なる形式で、または異なるディスプレイに同じ結果をフォーマットして表示する２つまたはそれ以上の表示スキーマが用意されている。たとえば、結果セットに対しディスプレイの画面に結果を表示するための表示スキーマを１つ用意し、結果を印刷するための表示スキーマをもう１つ用意する。また、同じアプリケーション、クライアント、またはサービスのコピーを表示能力の異なるデバイスで実行し、異なるデバイスの表示要求条件を満たす２つまたはそれ以上の表示スキーマを提供するようにする。
【０３８５】
文字列管理
従来のシステムでの文字列処理は、一般に、あまり効率がよくなく、特に、可変サイズの文字列の場合に効率がよくなく、たとえば、文字列をメモリ内でコピーしたり移動したりするときにメモリ空間を浪費することになる。文字列処理がこのように不効率であることは、特に、組み込み型システムなどの省メモリ・システムでは問題になる。メモリ、特にスタック領域、および動的割り当て用の領域のサイズが、省スペース／システムでは制限される。そこで、組み込み型システムなどの省スペース・システム内で実行するプログラムでの文字列処理を効率良く行う方法が望まれる。
【０３８６】
図３３Ａは、Ｃプログラミング言語による代表的文字列表現の図である。Ｃでは、文字列は、文字列１４５２の先頭文字のメモリ位置（アドレス）を格納した文字型ポインタ１４５０（ｓｔｒｉｎｇ１）で表される。他の文字は、文字列１４５２の中の先頭文字の後に続き、通常、メモリ内の連続するアドレス指定可能なバイト位置に格納される。Ｃ文字列における文字は通常、８ビットである。Ｃ文字列の文字は、ＡＳＣＩＩ文字である。Ｃ文字列は、ＮＵＬＬを終端文字とする必要がある。ＮＵＬＬは、プラットフォームで定義されている２５６個の使用可能な８ビット値のうちの１つで、通常、２進値０ｂ００００００００である。文字列１４５２は、１３バイトを占有する（１２個の文字と終端文字を合わせて１３個）。
【０３８７】
Ｃにおける文字列操作の一例として、ｓｔｒｌｅｎ（）関数があり、これは、通常、標準Ｃライブラリの実装に付属している。ｓｔｒｌｅｎ（）関数は、入力として文字列ポインタをとり、終端文字を含まない文字列の長さ（バイト）を返す。たとえば、文字ポインタ１４５０をｓｔｒｌｅｎ（）関数に渡すと、長さ１２が返される。ｓｔｒｌｅｎ（）関数は、終端文字が見つかるまで文字数を数えながら文字列内を端から端まで走査するという方法で実装できる。
【０３８８】
Ｃの文字列コピーは、通常、Ｃライブラリ関数のｓｔｒｃｐｙ（）またはｓｔｒｎｃｐｙ（）で処理するが、これは次のように実装されている。

ｓｔｒｃｐｙ（）関数は、文字ポインタｓｒｃが指している文字列（終端文字を含む）を文字ポインタｄｅｓｔが指している文字列にコピーする。文字列は重なることはなく、コピー先文字列ｄｅｓｔはコピーを受け入れるだけ十分に大きくなければならない。ｓｔｒｎｃｐｙ（）関数も同様であるが、ただし、ｓｒｃのうちｎバイト以下がコピーされる。したがって、ｓｒｃの先頭ｎバイトに終端文字がなければ、結果に終端文字は含まれない。必要ならば、ｓｔｒｎｃｐｙ（）の後のコードに、終端文字をｄｅｓｔ文字列の終わりに追加する命令を入れることができる。ｓｒｃの長さがｎ未満の場合、ｄｅｓｔの残り部分はＮＵＬＬで埋められる。ｓｔｒｃｐｙ（）およびｓｔｒｎｃｐｙ（）関数は、コピー先文字列ｄｅｓｔへのポインタを返す。図３３Ｂは、文字列１４５２に対するｓｔｒｎｃｐｙ（）関数の結果の一例を示しているが、これは以下のパラメータを付けてｓｔｒｎｃｐｙ（）を呼び出した場合である。

ただし、ｓｔｒｉｎｇ２は文字列１４５２の終端文字の後の最初のバイトを指している文字ポインタ１４５４であり、ｓｔｒｉｎｇ１＋３は３バイトだけインクリメントされた文字ポインタ１４５０であり、５はコピー元の場所ｓｔｒｉｎｇ１＋３からｓｔｒｉｎｇ２にコピーする文字の個数（バイト数）である。コピーした後、ｓｔｒｉｎｇ１からコピーされた５個の文字の後の次の文字は、終端文字に設定される（文字はコピーの前に終端文字に初期化されている場合がある）。したがって、２つの文字列はメモリ内で（１３＋６）＝１９バイトを占有することになる。文字ポインタ１４５０をコピー元文字列としてｓｔｒｃｐｙ（）関数を適用した場合、元の文字列１４５２と結果である新しい文字列は（１３＊２）＝２６バイトを占有することになる。
【０３８９】
図３３Ｃは、一般のシステムで、具体的には組み込み型システムなどの省スペース・システムで文字列を表現し、管理する効率的な方法を示す図である。文字列１４５２は、メモリ内に１２バイトとして格納される（終端文字は不要である）。文字列構造１４６０は、文字列１４５２の先頭文字と末尾文字へのポインタ（アドレス（Ａ）とアドレス（Ｌ））を含む。この文字列構造を使用すると、末尾文字へのポインタから先頭文字へのポインタを引くことで、文字列の長さを効率よく計算できる。
【０３９０】
文字列コピー操作ｓｔｒｃｐｙ（）やｓｔｒｎｃｐｙ（）などの操作も、より効率的に処理できる。図３３ｃに示されているようなものなどの文字列構造を使用して、新しい文字列構造１４６２を作成し、先頭文字ポインタと末尾文字ポインタを文字列１４５２内のそれぞれの文字を指すように初期化する。したがって、文字列１４５２の一部または全部をその文字列用の新しい記憶域にコピーする必要はない。文字列は長さが数百文字あるいは数千文字にさえ達することがあるため、文字列構造とその文字列構造を利用するように実装されている文字列メソッドを使用してメモリを節約することは注目に値する。文字列の一部または全部のコピーを処理するこのような方法のことを、「部分文字列管理」と呼び、文字列の一部（部分文字列）を効率よく処理することができる。
【０３９１】
標準Ｃ文字列ライブラリの他の文字列関数を、図３３Ｃに示されているような文字列構造を利用する文字列関数で置き換えることができる。他のＣ文字列関数の例として、それに限定されないが、ｓｔｒｓｔｒ（）、ｓｔｒｃａｔ（）、およびｓｐｒｉｎｔｆ（）がある。図３３Ｃで説明されているような文字列処理構造および方法は、ＸＭＬドキュメントの階層構造とともに使用する際に、組み込み型システムなどの省メモリ・システムでＸＭＬテキスト（ＸＭＬメッセージなど）を効率よく処理することができる。購買発注書を定義するＸＭＬスキーマの簡単な例を以下に示す。

【０３９２】
ＸＭＬドキュメントの階層構造により、これらを再帰的に処理することができ、それぞれの再帰のレベルで次々にドキュメントのさらに小さな部分を処理してゆく。さまざまな部分への参照が再帰的に記録され、処理される。図３３Ｃに関して説明されているような文字列構造を使用して、さまざまな部分を記録することができる。このようにして、ＸＭＬドキュメントの最小単位が再帰的に処理される一実施形態で、特定のＸＭＬタグの内容（上の例の１行）を効率よく決定できる。所定のスコープ内のタグを効率よく列挙し処理できるため、同じスコープ内でタグが繰り返されるドキュメントもまた効率よく処理できる。
【０３９３】
図３３Ｃで説明しているような文字列構造を使用してＸＭＬドキュメントを処理する再帰的方法では、ＸＭＬドキュメント文字列全体を表し、ドキュメント文字列内の先頭バイトと末尾バイトを指している文字列構造を受け付けることができる。この方法では、ドキュメントの次のサブセクションを特定して、そのサブセクションを含むドキュメント文字列全体の部分文字列を表す文字列構造をそのサブセクションの型に対応する処理関数に渡す。サブセクション自体を、サブセクションの型に対応する処理関数に渡される文字列構造により表されるサブセクションの他のレベルに分解できる。この方法は、ドキュメント全体が処理されるまで、ＸＭＬドキュメントのサブセクションを再帰的に処理し続けることができる。
【０３９４】
再帰的処理で文字列構造を使用すると、処理のためサブセクションのコピーを作成しなくても処理を実行できる。サブセクションのコピーは、再帰が深くなるにつれ同じデータのコピーが増えてゆくため、再帰的処理では特にコストがかかる。文字列構造を使用すると、サブセクションの中の先頭バイトと末尾バイトへのポインタを含む文字列構造のみを作成し、次のレベルに引き渡すだけでよい。サブセクションの長さを決定するなどの他の操作は、文字列構造に格納されているアドレス情報を使用することで効率よく実行できる。さらに、文字列構造を使用すると、Ｃ文字列の終端に使用される文字などの終端文字は、必要なくなり、組み込み型デバイスなど省スペース・デバイスのメモリを節約できる。
【０３９５】
オブジェクトのＸＭＬ表現
前述のように、Ｊｉｎｉ　ＲＭＩは、最小限のメモリ占有面積と最低限の帯域幅を備えるシン・クライアントなどのいくつかのクライアントには実用的でないと思われる。Ｊｉｎｉ　ＲＭＩと関連するシリアライゼーションは、実行時間が長く、コード・サイズが大きく、ＪＶＭリフレクションＡＰＩを必要とし、Ｊａｖａ固有オブジェクト表現である。Ｊａｖａデシリアライゼーションも実行に時間がかかり、コード・サイズが大きく、シリアライズ・オブジェクト・パーサを必要とする。Ｊａｖａベースのシン・クライアントであっても、Ｊｉｎｉ内で要求されたときにネットワーク経由で（必ず）返される巨大なＪａｖａオブジェクト（必要なクラスに沿って）を受け入れられない場合がある。
【０３９６】
分散コンピューティング環境の実施形態を使用するとよりスケーラブルな分散コンピューティング・メカニズムを実現できる。分散コンピューティング環境には、分散コンピューティングを容易に行えるようにするＡＰＩレイヤが含まれる。ＡＰＩレイヤは、クライアントとサービスとの間のメッセージ発送およびメッセージ受取機能を備える。このメッセージングＡＰＩは、拡張マークアップ言語（ＸＭＬ）など、表現データまたはメタデータ形式による単純メッセージ用のインターフェースを提供する。実施形態はここではＸＭＬを採用しているものについて説明しているが、他の実施形態では他のメタデータ型言語または形式を使用することもできることに注意されたい。いくつかの実施形態では、ＡＰＩレイヤは、さらに、Ｊａｖａオブジェクトなど、オブジェクト間の通信やオブジェクトの受け渡しのためのメッセージのインターフェースを備えることもできる。ＡＰＩレイヤ１０２を通じてアクセス可能なオブジェクトは、ＸＭＬなどの表現データ形式で表現される。そのため、オブジェクト自体とは反対に、オブジェクトのＸＭＬ表現は操作が可能である。
【０３９７】
ＡＰＩレイヤは、メッセージング・レイヤの上に置かれる。メッセージング・レイヤは、ＸＭＬなどの表現データ形式に基づいている。一実施形態では、ＸＭＬメッセージは、ＡＰＩレイヤの呼び出しに従って、メッセージング・レイヤによって生成される。メッセージング・レイヤは、クライアントとサービスとの間で送ることができる定義済みの静的メッセージを備えることができる。メッセージング・レイヤは、さらに、動的に生成されるメッセージにも対応できる。一実施形態では、ＪａｖａオブジェクトなどのオブジェクトをＸＭＬ表現に動的に変換（コンパイル）することができる。オブジェクトは、コードおよび／またはデータ部分を含む。オブジェクトのコードおよび／またはデータ部分は、ＸＭＬ表現のＸＭＬタグにより識別されるコード・セグメントとデータ・セグメントにコンパイルすることができる。メッセージング・レイヤにより、ＸＭＬオブジェクト表現はメッセージとして送ることができる。逆に、メッセージング・レイヤは、オブジェクトのＸＭＬ表現を受け取ることができる。その後、そのメッセージからオブジェクトを再構成（逆コンパイル）できる。再構成では、ＸＭＬ表現のコードおよび／またはデータ・セグメントを識別するタグのＸＭＬ表現を調べ、タグに格納されている情報を使用して、そのオブジェクトのコードおよび／またはデータ部分を識別し、逆コンパイルする。
【０３９８】
オブジェクトのＸＭＬ表現の作成と発送
図３４は、一実施形態により、クライアント１５００とサービス１５０２の間でＪａｖａオブジェクトを移動するプロセスを示す図である。サービス１５０２は、スペース・サービスを含む、分散コンピューティング環境でサポートされているサービスであればどのようなものでもよい。クライアント１５００は、サービス１５０２のサービス通知から受け取ったＸＭＬスキーマを使用して作成したゲート１５０４を使用し、サービス１５０２の対応するゲート１５０６と通信する。ある時点で、クライアント１５００は、Ｊａｖａオブジェクト１５１０をサービス１５０２に送る必要がある。Ｊａｖａオブジェクト１５１０は、他のオブジェクトを参照し、次にこのオブジェクトは他のオブジェクトを参照し、というように続いてゆく。Ｊａｖａオブジェクト１５１０とその参照されているオブジェクト、次に参照するオブジェクト、というように続くことを、オブジェクト・グラフと呼ぶ。
【０３９９】
Ｊａｖａオブジェクト１５１０は、Ｊａｖａオブジェクト・コンパイル・プロセス１５１２に渡されてコンパイルされ、オブジェクト・グラフのＸＭＬ表現を出力する。オブジェクト・グラフのＸＭＬ表現は、ＸＭＬデータ・ストリーム１５１４としてゲート１５０４に渡される。ＸＭＬデータ・ストリーム１５１４は、オブジェクト・グラフ内のすべてのオブジェクトのＸＭＬ表現を含む。一実施形態では、オブジェクト・グラフ内のオブジェクトは、ＸＭＬデータ・ストリーム１５１４内に再帰的に格納される。
【０４００】
ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２のゲート１５０６に送る。ゲート１５０６は、ＸＭＬメッセージ１５１６からＸＭＬデータ・ストリーム１５１４を抽出して、ＸＭＬデータ・ストリーム１５１４をＸＭＬデータ・ストリーム逆コンパイル・プロセス１５１８に送り、逆コンパイルを行い、Ｊａｖａオブジェクト１５１０を含むオブジェクト・グラフを備えるオブジェクトを出力する。一実施形態では、オブジェクト・グラフ内のオブジェクトは、ＸＭＬデータ・ストリーム１５１４内に再帰的に格納され、したがって、再帰的逆コンパイル・プロセスが使用される。
【０４０１】
サービス１５０２でＪａｖａオブジェクトをクライアント１５００に送る必要がある場合、実質的に類似するプロセスを使用できる。Ｊａｖａオブジェクト１５２０は、Ｊａｖａオブジェクト・コンパイル・プロセス１５１２に渡されてコンパイルされ、オブジェクト・グラフのＸＭＬ表現を出力する。オブジェクト・グラフのＸＭＬ表現は、ＸＭＬデータ・ストリーム１５２２としてゲート１５０６に渡される。ゲート１５０６は、その後、ＸＭＬデータ・ストリーム１５２２をメッセージ１５２４にパッケージして、メッセージ１５２４をクライアント１５００のゲート１５０４に送る。ゲート１５０４は、ＸＭＬメッセージ１５２４からＸＭＬデータ・ストリーム１５２２を抽出して、ＸＭＬデータ・ストリーム１５２２をＸＭＬデータ・ストリーム逆コンパイル・プロセス１５１８に送って逆コンパイルを行い、Ｊａｖａオブジェクト１５２０を含むオブジェクト・グラフを備えるオブジェクトを出力する。
【０４０２】
他の実施形態では、ゲートはＪａｖａオブジェクトのコンパイルおよび逆コンパイルを実行する役目を持つ。この実施形態では、Ｊａｖａオブジェクト１５１０はゲート１５０４に渡される。ゲート１５０４は、オブジェクト１５１０をＪａｖａオブジェクト・コンパイル・プロセス１５１２に渡してコンパイルし、オブジェクト・グラフのＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に出力する。ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２のゲート１５０６に送る。ゲート１５０６は、ＸＭＬメッセージ１５１６からＸＭＬデータ・ストリーム１５１４を抽出して、ＸＭＬデータ・ストリーム１５１４をＸＭＬデータ・ストリーム逆コンパイル・プロセス１５１８に送って逆コンパイルを行い、Ｊａｖａオブジェクト１５１０を含むオブジェクト・グラフを備えるオブジェクトを出力する。Ｊａｖａオブジェクトをサービス１５０２からクライアント１５００に送るプロセスは、オブジェクトをクライアントからサービスに送るプロセスと実質的に類似している。
【０４０３】
一実施形態では、オブジェクト・コンパイル・プロセス１５１２とオブジェクト逆コンパイル・プロセス１５１８は、両方とも、クライアント１５００とサービス１５０２に存在し、プログラムする際に、コンパイルと逆コンパイルを２つのデバイスで実質的に同じように実行できるため、一方のオブジェクト出力は他方のオブジェクト入力と実質的に同一である。一実施形態では、Ｊａｖａオブジェクトの記述を含むＸＭＬスキーマをコンパイル・プロセスや逆コンパイル・プロセスにおいてクライアントおよび／またはサービスの両方で使用できる。一実施形態では、Ｊａｖａオブジェクトのコンパイルや逆コンパイルで使用するＸＭＬスキーマをサービスにより、サービス通知でクライアントに渡すことができる。
【０４０４】
ＸＭＬでは、言語独立およびプラットフォーム独立のオブジェクト表現形式を備えている。したがって、オブジェクトをオブジェクトのＸＭＬ表現にコンパイルし、逆コンパイルしてオブジェクトを再現する場合に、図３４に示されているようなプロセスは、Ｊａｖａオブジェクトの移動に限られず、実施形態によっては、ネットワーク内のエンティティ間で他の型のオブジェクトを移動するのにも適用される。
【０４０５】
ＪＶＭコンパイル／逆コンパイルＡＰＩ
図３５ａおよび図３５ｂは、仮想マシン（たとえば、ＪＶＭ）がオブジェクト（たとえば、Ｊａｖａオブジェクト）をオブジェクトのＸＭＬ表現にコンパイルする拡張機能および（Ｊａｖａ）オブジェクトのＸＭＬ表現を（Ｊａｖａ）オブジェクトに逆コンパイルする拡張機能を含む実施形態を示すデータ流れ図である。ＪＶＭは、コンパイル／逆コンパイル拡張機能のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を備えることができる。クライアント１５００およびサービス１５０２は、ＪＶＭ内で実行中の場合がある。ＪＶＭは、同じデバイスまたは異なるデバイスに置くことができる。
【０４０６】
図３５ａと図３５ｂの両方で、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ１５３０は、Ｊａｖａオブジェクト１５１０を入力として受け付け、オブジェクト１５１０とその参照されているオブジェクト（オブジェクト１５１０のオブジェクト・グラフ）のＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に出力する。さらに、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０は、ＸＭＬデータ・ストリーム１５２２を受け付けることができ、これは、オブジェクト１５２０のＸＭＬ表現とその参照されているすべてのオブジェクト（オブジェクト１５２０のオブジェクト・グラフ）を含み、Ｊａｖａオブジェクト１５２０（およびそのオブジェクト・グラフ内のすべてのオブジェクト）を出力する。
【０４０７】
図３５ａは、Ｊａｖａオブジェクト１５１０を送るときにクライアントがＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ１５３０を呼び出す場合の一実施形態を示している。クライアント１５１０は、Ｊａｖａオブジェクト１５１０をＡＰＩ　１５３０に渡し、オブジェクトをコンパイルして、ＸＭＬ表現を出力し、そのＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に格納し、ＸＭＬデータ・ストリーム１５１４を出力する。その後、クライアントは、ＸＭＬデータ・ストリーム１５１４をゲート１５０４に渡すことができる。ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をＸＭＬメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２に送る。
【０４０８】
ＸＭＬメッセージ１５２４をサービス１５０２から受け取った後、ゲート１５２２はメッセージ１５２４からＸＭＬデータ・ストリーム１５２２を抽出し、データ・ストリーム１５２２をクライアント１５００に渡す。クライアント１５００は、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０を呼び出して、ＡＰＩ　１５３０にＸＭＬデータ・ストリーム１５２２を渡す。その後、ＡＰＩ　１５３０はＸＭＬデータ・ストリーム１５２２を逆コンパイルして、Ｊａｖａオブジェクト１５２０およびその他のオブジェクトをそのオブジェクト・グラフに出力し、オブジェクトをクライアント１５００に返す。
【０４０９】
図３５ｂは、Ｊａｖａオブジェクト１５１０を送るときにＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０がゲートによって呼び出される場合の他の実施形態を示している。クライアント１５１０は、Ｊａｖａオブジェクト１５１０をゲート１５０４に渡す。ゲート１５０４は、オブジェクト１５１０をＡＰＩ　１５３０に渡し、オブジェクトをコンパイルしてＸＭＬ表現を出力し、そのＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に格納し、ＸＭＬデータ・ストリーム１５１４を出力する。ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をＸＭＬメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２に送る。
【０４１０】
ＸＭＬメッセージ１５２４をサービス１５０２から受け取った後、ゲート１５２２はメッセージ１５２４からＸＭＬデータ・ストリーム１５２２を抽出し、データ・ストリーム１５２２をＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０に渡す。その後、ＡＰＩ　１５３０はＸＭＬデータ・ストリーム１５２２を逆コンパイルして、Ｊａｖａオブジェクト１５２０およびその他のオブジェクトをそのオブジェクト・グラフに出力する。そしてゲートは、Ｊａｖａオブジェクト１５２０とその他のオブジェクトをクライアント１５００に送る。
【０４１１】
一実施形態では、ＪＶＭ　ＸＭＬコンパイラおよび逆コンパイラは、ＪＶＭの統合された機能として実装することができる。他の実施形態では、ＸＭＬコンパイラおよび逆コンパイラは、ＪＶＭの標準拡張機能でのＡＰＩメソッド呼び出しで具現化することができ、そのため、コアＪＶＭを修正する必要はない。ＪＶＭは、ＪＶＭ内で実行するプロセス（クライアントおよび／またはサービス）にＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０を供給するため、プロセスはＪＶＭによって提供されているＪａｖａオブジェクト・コンパイル／逆コンパイル機能にアクセスすることができる。一実施形態では、プロセスがオブジェクト・コンパイル／逆コンパイルを利用するために、そのプロセスで実行されるＪＶＭにＪＶＭ　ＸＭＬコンパイラ／逆コンパイラ機能とＡＰＩ　１５３０を備える必要がある。リフレクションとシリアライゼーションを使用してオブジェクトを変換して送るメソッドは、通常、ＪＶＭから切り離された別のアプリケーションで実装される。オブジェクトの推移的閉包（ｔｒａｓｉｔｉｖｅ ｃｌｏｓｕｒｅ）を動的に解析するときに、アプリケーション側がＪＶＭに繰り返しアクセスし、一度にフィールド１つずつオブジェクトを取り出す必要がある。この作業は、遅くかつやっかいなプロセスになりがちであり、またアプリケーションとＪＶＭコードが大量に必要になる。
【０４１２】
ＪＶＭ内にＪａｖａオブジェクト・コンパイル／逆コンパイル機能を実装することが好都合なのは、ＪＶＭがすでにオブジェクト・グラフの概念、および内容を理解しているからである。そこで、コンパイル／逆コンパイル機能で、ＸＭＬ表現を出力するためのオブジェクト・グラフの解析とオブジェクト・グラフを出力するためのＸＭＬ表現の解析にＪＶＭの知識を活用（そして、コードを再利用し）することができる。したがって、コンパイル／逆コンパイル機能では、リフレクションとシリアライゼーションを使用するオブジェクト送出メソッドの場合のように、ＪＶＭによって提供される機能を複製してはならない。これにより、コンパイル／逆コンパイル機能のコード占有領域を、リフレクションおよびシリアライゼーションを使用するオブジェクト送出メソッドと比べて小さくすることができる。また、オブジェクトは、ＪＶＭ ＸＭＬコンパイラ／逆コンパイラＡＰＩを１回呼び出すだけでコンパイルまたは逆コンパイルすることができる。
【０４１３】
さらに、オブジェクトのコンパイル逆コンパイルをＪＶＭに統合することにより、オブジェクトのコンパイルおよび逆コンパイルを、リフレクションおよびシリアライゼーションを使用したメソッドよりも高速に実行することができる場合があるが、それは、リフレクションおよびシリアライゼーションで実装されたオブジェクト・トラバーサル・モデルでは、ＪＶＭの外部にあるコードはＪａｖａオブジェクトの構造またはグラフを認識せず、オブジェクト・グラフをトラバースして、引き離し、最終的に、ＪＶＭを繰り返し呼び出してコンパイル（および逆コンパイルのための反転プロセス）を実行する必要があるからである。このプロセスは、コードの外部で、ＪＶＭの呼び出しを繰り返し実行する必要があるため、遅くなることがある。ここで説明したように、コンパイルおよび逆コンパイル機能をＪＶＭに統合することにより、ＪＶＭの外部のコードからＪＶＭへ繰り返し呼び出しを行わなくて済むようになる。一実施形態では、オブジェクトは、ＪＶＭ ＸＭＬコンパイラ／逆コンパイラＡＰＩを１回呼び出すだけでコンパイルまたは逆コンパイルすることができる。
【０４１４】
一実施形態では、コンパイラ／逆コンパイラ機能は分散コンピューティング環境におけるサービスとして実装できる。サービスは、スペース内でサービス通知をパブリッシュする。分散コンピューティング環境内のプロセスは、サーチまたは発見サービスを使用して、コンパイル／逆コンパイル・サービスを特定することができる。このプロセス（サービスのクライアント）は、次に、ＸＭＬ表現にコンパイルするＪａｖａオブジェクトおよび／またはＪａｖａオブジェクトに逆コンパイルするＸＭＬ表現サービスに渡すことによりそのサービスを使用できる。Ｊａｖａオブジェクトにコード（オブジェクトのメソッド）およびデータを含めることができる。オブジェクトのコードは、非一時的でなく、オブジェクトが作成された後このコードは変更されない。ただし、オブジェクトのデータは一時的な場合がある。同じＪａｖａクラスから作成された２つのオブジェクトは、同一のコードを含んでいても、２つのオブジェクト内のデータが異なることがある。一実施形態では、コンパイル機能はＪａｖａオブジェクトのデータをオブジェクトのＸＭＬ表現にコンパイルするが、ＸＭＬ表現の中にオブジェクトの実際のコードが含まれない場合がある。一実施形態では、オブジェクトに関する情報をコンパイルされたＸＭＬ表現の中に挿入し、そのオブジェクトのコードの再作成方法を受取側に通知するようにできる。ＸＭＬ表現をＸＭＬデータ・ストリームに格納し、受け取り側プロセス（クライアントまたはサービス）に（たとえば、メッセージで）送ることができる。受け取り側プロセスは、ＸＭＬデータ・ストリームを逆コンパイル機能に渡すことができる。逆コンパイル機能は、ＸＭＬデータ・ストリームを逆コンパイルして、そのデータを含むＪａｖａオブジェクトを出力することができる。一実施形態では、オブジェクトのコードは、ＸＭＬ表現に含まれるオブジェクトに関する情報を使用して逆コンパイル機能により再現することができるが、それはオブジェクトのコードが静的に定義され、そのオブジェクトを受け取るＪＶＭがオブジェクトについての情報を利用して（必要ならば）そのコードを再現することができるからである。
【０４１５】
一実施形態では、コンパイル機能によって出力されたオブジェクトのＸＭＬ表現に、にＪａｖａオブジェクトのデータおよびそのＪａｖａオブジェクトに関する情報を格納することができる。その情報は、Ｊａｖａオブジェクトのクラス情報を含むことができる。オブジェクト・シグネチャを情報に含め、そのシグネチャを利用して、オブジェクトのクラスなどを識別することができる。逆コンパイル機能では、Ｊａｖａオブジェクトに関する情報を使用してＪａｖａオブジェクトのコードを再作成し、ＸＭＬデータ・ストリームからデータをＪａｖａオブジェクトに逆コンパイルすることができる。したがって、逆コンパイルされたデータとオブジェクトを記述している情報から受け取り側クライアントまたはサービスを実行しているＪＶＭ上でコードとデータを含む完全なオブジェクトを再現することができる。一実施形態では、オブジェクトを記述する情報を１つまたは複数のＸＭＬタグの中に格納することができる。一実施形態では、ＸＭＬデータ・ストリームを受け取るクライアントまたはサービスはオブジェクトを記述するＸＭＬスキーマを含むことができ、またＸＭＬスキーマを使用して、逆コンパイルされたデータとそのオブジェクトに関する情報からＪａｖａオブジェクトを再構成することができる。逆コンパイル・プロセスは、オブジェクト・グラフを再帰的にたどり、オブジェクトによって参照されているオブジェクトを再構成するが、この作業は、ＸＭＬデータ・ストリームから参照されているオブジェクトのデータを逆コンパイルし、そのＸＭＬデータ・ストリーム内の参照されているオブジェクトに関する情報から参照されているオブジェクトのコードを再作成することで行う。
【０４１６】
一実施形態では、コンパイル機能によって出力されたオブジェクトのＸＭＬ表現に、オブジェクトのデータおよびオブジェクトのコードを識別する情報を格納することができる。一実施形態では、オブジェクトのコードを記述する情報をＸＭＬデータ・ストリーム内の１つまたは複数のＸＭＬタグの中に格納することができる。受け取ると、逆コンパイル機能はＸＭＬデータ・ストリームからのコードに関する情報を使用してＪａｖａオブジェクトのコードを再作成し、ＸＭＬデータ・ストリームからオブジェクトのデータを逆コンパイルすることができる。したがって、逆コンパイルされたデータとオブジェクトのコードを記述している情報から受け取り側クライアントまたはサービスを実行しているＪＶＭでコードとデータを含む完全なオブジェクトを再現することができる。
【０４１７】
オブジェクトのＸＭＬ表現を使用して分散コンピューティング環境内のエンティティ（通常、クライアントとサービス）間でオブジェクトを転送するシナリオを説明のため取り上げる。これらのシナリオは、例であり、制限することを意図していない。
【０４１８】
第１のシナリオでは、サービスはＸＭＬコンパイラ／逆コンパイラを使用して、ＪａｖａオブジェクトをそのオブジェクトのＸＭＬ表現にコンパイルし、そのＸＭＬ表現をクライアントに送る。クライアントは、ＸＭＬコンパイラ／逆コンパイラを使用してＸＭＬ表現を逆コンパイルし、オブジェクト内のデータに対し操作を実行し、後でＸＭＬコンパイラ／逆コンパイラを使用してそのオブジェクトをオブジェクトのＸＭＬ表現にコンパイルし、そのオブジェクトのＸＭＬ表現をサービスに返す。
【０４１９】
第２のシナリオでは、サービスはＸＭＬコンパイラ／逆コンパイラを使用して、ＪａｖａオブジェクトをそのオブジェクトのＸＭＬ表現にコンパイルし、そのＸＭＬ表現をクライアントに送る。次に、クライアントはＸＭＬ表現を他のサービスに送り、これはＸＭＬコンパイラ／逆コンパイラを使用してＸＭＬ表現を逆コンパイルしてオブジェクトを再生成し、クライアントから（場合によってはデータを修正する）要求があったときにオブジェクトに対し操作を実行し、ＸＭＬコンパイラ／逆コンパイラを使用してその修正されオブジェクトをそのＸＭＬ表現に再コンパイルし、そのオブジェクトのＸＭＬ表現をクライアントに送る。
【０４２０】
第３のシナリオでは、サービスはＸＭＬコンパイラ／逆コンパイラを使用して、ＪａｖａオブジェクトをそのオブジェクトのＸＭＬ表現にコンパイルし、そのＸＭＬ表現をオブジェクト・リポジトリまたはストア・スペースに送る。サービスは、次に、メッセージをクライアントに送り、ＸＭＬ表現の位置をクライアントに知らせる。メッセージは、ＸＭＬ表現のＵｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含む。その後、クライアントはストア・スペースからオブジェクトのＸＭＬ表現を取り出し、ＸＭＬコンパイラ／逆コンパイラを使用してその表現を逆コンパイルしてオブジェクトを再現する。それとは別に、クライアントはオブジェクトのＸＭＬ表現の位置を、そのオブジェクトで実行する操作の要求とともに他のサービスに送る。その後、他のサービスはストア・スペースからＸＭＬ表現を取り出し、ＸＭＬコンパイラ／逆コンパイラを使用してＸＭＬ表現を逆コンパイルしオブジェクトを再現して、オブジェクトに対し要求された操作を実行する。
【０４２１】
第４のシナリオでは、プロセス（クライアントまたはサービスの場合がある）は、ストア・スペースでサービス通知をサーチして見つけることにより、分散コンピューティング環境内のオブジェクト・リポジトリまたはストア・スペースを特定することができる。プロセスは、実行時に、複数のＪａｖａオブジェクトを作成し、取得する。プロセスは、ＸＭＬコンパイラ／逆コンパイラを使用して、１つまたは複数のオブジェクトをオブジェクトのＸＭＬ表現にコンパイルし、ストア・スペース・サービスのクライアントとして、オブジェクトのＸＭＬ表現をストア・スペースに送り、後でアクセスできるように、また他のプロセスによってアクセスできるように格納する。
【０４２２】
オブジェクトのＸＭＬ表現の逆コンパイルにおけるセキュリティ問題
スペースは、ここで説明しているように、分散コンピューティング環境でファイル・システムとして使用できる。システム内のファイルに対してはセキュリティをアクセス権限の形で提供する。アクセス権限は、ファイルのアクセス（開く、読み込む、書き出すの操作）ごとにチェックされる。したがって、分散コンピューティング環境でファイルのアクセス・セキュリティを実現する方法が望まれる。この方法はさらに、スペースに格納され、分散コンピューティング環境内のクライアントとサービスとの間で送られるＪａｖａオブジェクトのＸＭＬ表現に適用できる。
【０４２３】
一実施形態では、分散コンピューティング環境のデバイスのクライアントのユーザは、最初にクライアントにアクセスしたときに識別され、認証される。一実施形態では、ユーザは、識別と承認のためにスマート・カードなどの物理的識別機能を提供することができる。他の実施形態では、チャレンジ応答メカニズム（ユーザＩＤとパスワードなど）を使用して、識別と承認を行うことができる。さらに他の実施形態では、識別と承認に電子シグネチャなどの電子識別を使用する。識別と承認に他の方法を使用することもできる。識別されて承認されると、ユーザは、分散コンピューティング環境で１つまたは複数のサービスにアクセスすることを含む、クライアント上のさまざまな操作を実行できる。これらの操作のときに、上述のように、１つまたは複数のオブジェクトを作成する（ローカルで）か、またはどこか他のところ（たとえば、サービスまたはスペース）から取得することができる。オブジェクトは、修正して、オブジェクトのＸＭＬ表現にコンパイルし、ローカルで、クライアントによって格納するか、または（遷移的または永続的）ストアのためスペース・サービスに送ることができる。オブジェクトのいくつかはサービスからオブジェクトのＸＭＬ表現の形式で（サービスまたは他のサービスで格納）受取され、これは、ＸＭＬコンパイラ／逆コンパイラによって逆コンパイルされ、クライアント上にオブジェクトを再作成することができる。
【０４２４】
一実施形態では、オブジェクトのＸＭＬ表現を逆コンパイルするときに、それぞれのＸＭＬメッセージをチェックし、ユーザがそのオブジェクトに対するアクセス権限を持っていることを検証する。ユーザが適切なアクセス権限を持っていない場合、ＸＭＬコンパイラ／逆コンパイラはそのユーザに対してオブジェクトを逆コンパイルしない。一実施形態では、ＸＭＬコンパイラ／逆コンパイラによってセキュリティ例外がスローされる。一実施形態では、ユーザに対しアクセス違反が知らされる。
【０４２５】
オブジェクトに対し許されている作成者およびアクセス・レベル（作成者のみアクセス、読み取り専用、読み書き、削除、コピーなど）などのアクセス権限情報は、オブジェクトのＸＭＬ表現を含むＸＭＬメッセージ内に埋め込むことができる。アクセスの承認は、ユーザの識別と承認を行う際に決定される。たとえば、オブジェクトは、ほとんどのユーザに対し「読み取り専用」アクセスを許可し、オブジェクトの作成者には「読み書き」アクセスを許可する。ユーザが読み書きアクセス権限を使用してオブジェクトにアクセスしようとし、ユーザがオブジェクトを作成していなかった場合、逆コンパイル・プロセスにより、これがアクセス違反として検出され、アクセスが不許可になり、ユーザは通知を受ける。
【０４２６】
一実施形態では、ユーザがクライアントを使用して完了した場合、ユーザはログオフするか、またはそうでなければ、ユーザがクライアントを終了した（たとえば、スマート・カードを削除した）ことを通知する。逆コンパイルによりクライアント上に作成されたオブジェクトは、ユーザは終了したことをクライアントが検出したときに、自動的に検出される。このため、後からのユーザが故意にまたはうっかりそのユーザのオブジェクトにアクセスしようとしてもできない。一実施形態では、逆コンパイルによって作成されたすべてのオブジェクトは、ユーザが終了したことが検出されたときに削除される。他の実施形態では、クライアント上に永続的に作成されたオブジェクトの少なくとも一部を格納する方法が用意され（たとえば、アクセス権限情報を使用して）、これによりクライアントが後でオブジェクトにアクセスしたり、オブジェクトを他のユーザに提供してアクセスできるようにする。一実施形態では、ユーザは「スマート・カード」またはその他の物理的デバイスを使用し、クライアントへのアクセス権を取得する。ユーザは、スマート・カードをクライアント・デバイスに差し込んで、セッションを開始することができる。クライアントは、終了すると、スマート・カードを取り出す。クライアントは、スマート・カードが取り出されたことを検出し、クライアントが終了していることを検出し、その後、ＸＭＬ表現の逆コンパイルによって作成されたオブジェクトの削除へ進む。
【０４２７】
ＸＭＬベースのオブジェクト・リポジトリ
分散コンピューティング環境では、プロセス（サービスおよび／またはクライアント）には、ＸＭＬスキーマ、サービス通知、サービスによって生成された結果、ＪａｖａオブジェクトのＸＭＬ表現、および／または他の言語で実施されたオブジェクトなどの一時的および／または永続的記憶域があると望ましい場合がある。既存のオブジェクト記憶技術は、言語および／またはオペレーティング・システム固有のものになりがちである。これらの記憶域システムは、また、組み込み型システムなどの省スペース・システムで使用するには複雑すぎる傾向もある。
【０４２８】
ＪｉｎｉのＪａｖａＳｐａｃｅｓは、既存のオブジェクト・リポジトリ・メカニズムである。ＪａｖａＳｐａｃｅｓは、Ｊａｖａオブジェクトを格納することしかできず、メモリ容量に制限のある小型デバイスには大きすぎて実装できない。ＪａｖａＳｐａｃｅの各オブジェクトは、前記のようにシリアライズされ、そのため、リフレクションおよびシリアライゼーション手法について前述したのと同じ制限がある。
【０４２９】
異機種混在の（言語またはオペレーティング・システム依存でない）、小型デバイスから大型デバイスまで拡張性のある、オブジェクトの一時的記憶域または永続的記憶域を提供できる分散コンピューティング環境向けのストア・メカニズムを提示する。一実施形態では、分散コンピューティング環境でのストア・メカニズムは、ＸＭＬマークアップ言語で定義されているインターネットＷｅｂページまたはページ・セットとして実装することができる。ＸＭＬは、言語独立およびプラットフォーム独立のオブジェクト表現形式を用意し、Ｊａｖａおよび非Ｊａｖａソフトウェアが言語独立オブジェクトを格納し、取り出すことができるようにしている。ストア・メカニズムはＷｅｂ上にあるため、すべての型およびサイズ（小型から大型まで）のデバイスでストア・メカニズムにアクセスできる。Ｗｅｂブラウザーを使用して、Ｗｅｂページとして実装されているストア・メカニズムを表示することができる。Ｗｅｂサーチ・エンジンを使用して、Ｗｅｂページとして実装されているストア・メカニズム内のコンテンツをコンテンツすることができる。インターネット管理メカニズム（既存および将来の）およびＸＭＬツールを使用して、ＸＭＬベースのストア・メカニズムを管理することができる。
【０４３０】
一実施形態では、ストア・メカニズムを使用して、ＸＭＬで作成され、表現され、またはカプセル化されたオブジェクトを格納することができる。ストア・メカニズムに格納できるオブジェクトの例として、それには限定されないが、ＸＭＬスキーマ、オブジェクトのＸＭＬ表現（たとえば、上述のようにＸＭＬ表現にコンパイルされたＪａｖａオブジェクト）、サービス通知、およびＸＭＬでカプセル化されたサービス結果（データ）がある。一実施形態では、ＸＭＬオブジェクトの無許可アクセスを防止するために、電子シグネチャや証明書などの承認証明書をＸＭＬオブジェクトに付属させ、ＸＭＬオブジェクトにアクセスすることを望んでいるクライアントがＸＭＬオブジェクトにアクセスするための適切な承認証明書を持つことを義務づける。一実施形態では、ストア・メカニズムは、「スペース」の項で説明したようにスペースであってもよい。
【０４３１】
分散コンピューティング環境では、ストア・メカニズムはサービスである。サービスとして実装されたストア・メカニズムは、「ストア・サービス」と呼ばれる。ストア・サービスは、スペース内で通知をパブリッシュする。スペース自体はストア・サービスの一例である。一部のストア・サービスは一時的である。たとえば、サービス通知を格納するスペース・サービスは一時的ストアである。他のストア・サービスは永続的である。たとえば、サービスからの結果を格納するストア・サービスは永続的ストアである。
【０４３２】
図３６は、一実施形態により分散コンピューティング環境でストア・メカニズム１６００および１６０２にアクセスするクライアント１６０４およびサービスＡ １６０６の図である。この図は、例示を目的としており、本発明の範囲に限定することを求めていない。一実施形態では、ストア・メカニズム１６００および１６０２はそれぞれ、ウェブ・ブラウザおよび他のインターネット・ツールによってアクセス可能なインターネット・ウェブ・ページまたはＸＭＬで定義されるウェブ・ページの集合である。ストア・メカニズム１６００は、ＸＭＬを使用して実装されたオブジェクトを格納できる一時的ストアである。ストア・メカニズム１６０２は、これもまたＸＭＬを使用して実装されたオブジェクトを格納できる永続的ストアである。サービスＡ １６０６は、一時的ストア１６００でＸＭＬサービス通知１６０８をパブリッシュする。永続的ストアは、さらに、一時的ストア１６００に（または分散コンピューティング環境内の他の一時的ストアに）ＸＭＬサービス通知をパブリッシュすることもできる。ある時点で、クライアント１６０４は、サービスＡ １６０６によって提供される機能を必要とする。クライアント１６０４は、発見および／またはルックアップ・サービスを使用して、サービス通知１６０８を特定する。クライアント１６０４は、ここで説明しているように、メッセージ・ゲートを構築し、サービスＡ １６０６との通信を開始する。クライアント１６０４は、１つまたは複数のＸＭＬ要求メッセージをサービスＡ １６０６に送る。サービスＡ １６０６は、その１つまたは複数の要求メッセージに応答して１つまたは複数の機能を実行する。サービスＡ １６０６によって実行される機能の１つまたは複数により、クライアント１６０４に送る結果を出力する。
【０４３３】
一時的結果１６１０については、サービスＡ １６０６は、ＸＭＬ通知１６１２で結果をカプセル化し、通知１６１２を一時的ストア１６００に（または分散コンピューティング環境内の他の一時的ストアに）パブリッシュする。その後、サービスＡ １６０６は、結果１６１０が一時的ストア１６００の通知１６１２に格納されることをクライアント１６０４に通知するか、またはここで述べたように他のメカニズムによりクライアント１６０４に通知することができる。クライアント１６０４は、その後、通知１６１２から一時的結果１６１０を取り出す。通知１６１２は、一時的結果１６１０のフォーマット、コンテンツ、型などを記述するＸＭＬスキーマを含む。結果は、ＸＭＬでカプセル化される。たとえば、ＸＭＬタグを使用して、次のようにデータの一部を記述することができる。

【０４３４】
永続的結果１６１８については、サービスＡ　１６０６はサービスまたはここで説明されているようなその他のメカニズムを使用して、永続的ストア１６０２のＸＭＬサービス通知１６１６を特定し、永続的結果を格納するため永続的ストア１６０２を特定する。それとは別に、クライアント１６０４は、サービス通知１６１６を特定することにより、すでに永続的ストア１６０２を特定しており、永続的結果１６１８の記憶場所のＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）をＸＭＬメッセージでサービスＡに送る。一実施形態では、永続的結果１６１８は、ＸＭＬで定義され、Ｗｅｂブラウザによりアクセス可能なインターネットＷｅｂページまたはＷｅｂページ・セットに格納される。その後、サービスＡ　１６０６は、永続的ストア１６０２に永続的結果１６１８を格納する。続いてサービスＡ　１６０６は、永続的結果１６１８のＸＭＬ通知１６１６を一時的ストア１６００に（または分散コンピューティング環境内の他の一時的ストアに）パブリッシュし、通知１６１６の位置をクライアント１６０４に返す。通知１６１６は、永続的結果１６１８のフォーマット、コンテンツ、型などを記述するＸＭＬスキーマを含む。結果は、前述のようにＸＭＬでカプセル化される。通知はさらに、永続的結果１６１８のＵＲＩを含む。クライアント１６０４は、次に、通知１６１６を取り出し、これを使用して永続的結果１６１８を特定し、取り出す。それとは別に、サービスＡ　１６０６は、永続的結果１６１８の通知をパブリッシュせず、その代わりに、クライアント１６０４が通知をルックアップせずに結果にアクセスできるように、永続的結果１６１８のＵＲＩをクライアント１６０４に返す。いくつかの実施形態では、一時的ストア１６００に示されるさまざまな通知はそれぞれ、異なる一時的ストアまたはスペースに格納できることに注意されたい。
【０４３５】
したがって、ストア・メカニズムは、分散コンピューティング環境内でＸＭＬベースのインターネットＷｅｂページとして実装することができる。これらのストア・メカニズムは、分散コンピューティング環境内のさまざまなデバイスに実装され、クライアント（他のサービスでもよい）がストア・メカニズムを特定し使用できるようにするサービス通知を実現する。ストア・メカニズムを管理するために使用できるＷｅｂおよびＸＭＬツールは既存のものでもこれからのものでもよい。ストア・メカニズムは、ＸＭＬで実装されたまたはカプセル化されたさまざまな型のオブジェクトを格納できる。クライアントは、省スペース・デバイスからスーパー・コンピュータに至るまで実質的にいかなるサイズのデバイスのクライアントであっても、ストア・メカニズムにアクセスして、インターネット上でさまざまなオブジェクトを格納し取り出すことができる。クライアントは、ＸＭＬによって定められている言語独立の記憶形式であれば、Ｊａｖａアプリケーションでも非Ｊａｖａアプリケーションでもよい。一時的または永続的オブジェクト・リポジトリは、分散コンピューティング環境内のファイル・システムに対応しており、ここで説明しているように、アクセス・チェックおよびその他のセキュリティ・メカニズムの機能を備える。
【０４３６】
ＪａｖａオブジェクトをＸＭＬドキュメントに動的に変換する
一実施形態では、分散コンピューティング環境はオブジェクト・クラス・インスタンスをＸＭＬドキュメントに変換しそれを表現するメカニズムを備える。クラス・インスタンスの表現を他のサービスに送るために、オブジェクトは変換されＸＭＬドキュメントとして表現される。一実施形態では、ＸＭＬドキュメントを受け取ると、プログラムがドキュメントによって表現されたオブジェクトに対応するクラス・インスタンスをインスタンス化する。一実施形態では、オブジェクトはＪａｖａオブジェクトであり、プログラムはＪａｖａプログラムである。
【０４３７】
一実施形態では、中間形式を使用してＸＭＬドキュメントを表現し、この中間形式を動的に処理して、ＸＭＬドキュメントを表現するクラス・インスタンスを生成することができる。クラスによって、一組のインスタンス変数とインスタンス変数にアクセスするための「セットアンドゲット」メソッドを定義する。対応するＸＭＬドキュメントを一組のタグとして定義し、インスタンス変数ごとに１つのタグを割り当てることができる。ドキュメントの解析を行うときに、ハッシュ可能な表現を構築し、ハッシュ鍵にインスタンス変数名を含め、値にインスタンス変数値を入れる。複合インスタンス変数が複数出現する場合、列挙型値をそのハッシュ・テーブルに格納することができる。一実施形態では、プロセスをインスタンス変数について複合型のうちただ１つのレベルに制限し、要素を均質的なものとすることができる。
【０４３８】
一実施形態では、保護されたインスタンス変数を、対応するクラスの名前を含めることができるクラス定義に追加することができる。ＸＭＬドキュメント表現ではクラス名をドキュメント型として使用できる。ドキュメントにクラス名を埋め込むと、オブジェクトを再構築するときに、正しいクラス・インスタンスのインスタンス化を動的に行うことができる。
【０４３９】
一実施形態では、ドキュメントを受け取った後、クラス・インスタンス・ジェネレータ・メソッドを使用して、クラス型を抽出し、ドキュメントを解析して中間ハッシュ・テーブル表現を生成することができる。ジェネレータ・メソッドは、新しいクラス・インスタンスをインスタンス化し、セット・メソッドを使用してハッシュ・テーブル値からインスタンス・オブジェクトを初期化することができる。一実施形態では、クラス型が定義され、ハッシュ・テーブルは汎用なので、このプロセスは、上のクラス定義にマッチするクラスに対して実行される。一実施形態では、反転プロセスも実行することができ、クラス・インスタンスを処理して中間ハッシュ・テーブルの表現にし、ジェネレータ・メソッドを使用してハッシュ・テーブル表現からＸＭＬドキュメントを出力することができる。このプロセスはさらに、上の指定にマッチするＸＭＬドキュメントについて実行できるように汎用なものとすることもできる。
【０４４０】
このメソッドは、Ｊａｖａクラス・オブジェクトに制限する意図はなく、他のプログラミング言語のクラス・オブジェクト・インスタンスを含む、他のコンピュータベースのオブジェクトにも適用される。さらに、このメソッドは、オブジェクト・インスタンスのＸＭＬ表現に制限する意図はなく、他のデータ表現言語（ＨＴＭＬなど）など他の表現形式をＸＭＬの代わりに使用することもできる。
【０４４１】
ＸＭＬベースのプロセスの移行
分散コンピューティング環境では、配布されるアプリケーションの配布および管理を行える。たとえば、分散コンピューティング環境には、モニタ、プリンタ、キーボード、およびＰＤＡ、携帯電話などのモバイル・デバイスには通常装備されないさまざまなその他の入出力デバイスを備えるステーションとドッキング可能なモバイル・クライアントが含まれる。これらのモバイル・クライアントは、１つまたは複数のアプリケーションを実行し、分散コンピューティング環境において、一方のステーションから他方のステーションに移行することができる。したがって、分散コンピューティング環境の一実施形態では、分散コンピューティング環境内の一方のノードのモバイル・クライアントから他方のノードの同じモバイル・クライアントまたは他方のモバイル・クライアントに現在状態全体を保持したまま実行中アプリケーション（プロセス）を移行する方法を提示する。
【０４４２】
一実施形態では、クライアントまたはサービス上で実行しているプロセスの状態のＸＭＬ表現を作成する。一実施形態では、プロセスの状態のＸＭＬ表現は、プロセスが実行されているデバイスおよび／または仮想マシンの計算状態を含み、デバイスおよび／または仮想マシンの計算状態はデバイスおよび／または仮想マシン上のプロセスの実行状態に関する情報を含む。プロセス状態は、それに限定されないが、スレッド、スレッドによって参照されているすべてのオブジェクト、プロセスの実行中に作成される一時的変数、オブジェクト、およびそのデータなどである。一実施形態では、プロセスによってスペースから得られ、プロセスが実行されているデバイスおよび／または仮想マシンの外部にある外部サービスへのアクセス権の付与を表す１つまたは複数のリースを記述するデータは、ＸＭＬで表され、プロセス状態とともに格納される。リースについては、本書の「リース」の項で詳述する。
【０４４３】
ここで説明しているようにＸＭＬおよびメッセージング・システムを使用すると、プロセスの状態のＸＭＬ表現を分散コンピューティング環境内のノードからノードへ、たとえばインターネット上のノードからノードへ移動することができる。プロセスの状態のＸＭＬ表現はさらに、上述のようにＸＭＬベースのストア・メカニズムによりＸＭＬオブジェクトとして格納することができ、後から、ストア・メカニズムから取り出して、同じノード上、または分散コンピューティング環境内の異なるノード上でプロセスの実行を再開することができる。一実施形態では、ここで説明しているようにＸＭＬオブジェクトのコンパイル／逆コンパイル・プロセスを使用して、プロセスの状態のＸＭＬ表現を作成（コンパイル）し、プロセスの状態のＸＭＬ表現を逆コンパイルすることによりプロセスの状態を再生成することができる。
【０４４４】
このメカニズムを使用することにより、プロセスの状態のＸＭＬ表現を初期ノードから、スペースなどのＸＭＬベースのストア・メカニズムに格納することができる。それ以降、他のノードでプロセスの格納済みの状態を特定し、プロセスの状態をダウンロードし、状態が格納されたときに実行されていた時点のダウンロードされた格納済みの状態からプロセスを再開できる。プロセス状態はＸＭＬ形式で格納されるので、ここで説明しているＸＭＬベースのストア・メカニズムでＸＭＬオブジェクトを格納し、特定し、取り出すためのツールおよびサーチ機能を使用して、プロセスの移行を可能にすることができる。プロセスの状態の格納されているＸＭＬ表現の通知をパブリッシュする際に、同じノードまたは別のノード上で実行されているプロセスの再開するクライアントが格納されている状態を特定し、アクセスできるようにする。
【０４４５】
プロセスの状態のＸＭＬ表現をＸＭＬベースの永続的ストア・メカニズムに格納し、プロセスの永続的スナップショットを作成できる。これは、たとえば、ノードを故意にシャットダウンしたり、または故意でなくシャットダウンをしたためノード上のプロセスが中断した後、ノード上のプロセス実行を再開するための方法として使用できる。プロセスの格納されている状態の通知をパブリッシュし、クライアントが分散コンピューティング環境内の格納されている状態を特定できるようにする。一実施形態では、プロセスの格納されている状態のＸＭＬ表現の無許可アクセスを防止するために、電子シグネチャや証明書などの承認証明書を格納されている状態に付属させ、格納されている状態からプロセスを再開することを望んでいるクライアントが格納されている状態にアクセスするための適切な承認証明書を持つことを義務づける。
【０４４６】
図３７は、一実施形態によりプロセスの状態のＸＭＬ表現を使用するプロセス移行を示す図である。プロセスＡ　１６３６ａが、ノード１６３０上で実行されている。プロセスＡ　１６３６ａは、クライアントまたはサービスである。プロセスＡ　１６３６ａの実行中のある時点に、プロセスＡ　１６３６ａの実行の状態を捕捉し、プロセスＡ　１６３８のＸＭＬでカプセル化された状態で格納する。ノード１６３０上のプロセスＡ　１６３６ａの実行は停止させられる。後で、ノード１６３２は、プロセスＡ　１６３８のＸＭＬでカプセル化された状態を特定し、ノード１６３２上でプロセスＡ　１６３６ｂを再開するためにそれを使用する。プロセスＡを再開するには、格納されている状態１６３８を使用してスレッド実行を再開し、一時変数を再計算し、リースされているリソースを再確立し、プロセス１６３８の格納されているＸＭＬ状態で記録されているとおりに実行を再開するのに必要な他の機能を実行する。
【０４４７】
分散コンピューティング環境でＸＭＬベースのプロセス移行を使用する一例を以下に示すが、制限することを意図していない。モバイル・クライアント・デバイスは、ノード１６３０に接続され、プロセスＡ　１６３６ａを実行している。モバイル・クライアント・デバイスのユーザは、ノード１６３０でプロセスＡ　１６３６ａの実行を停止し、後で、別の（または同じ）ノードから実行を再開しようと考えている。一実施形態では、ユーザは、プロセスＡ　１６３６ａの状態を格納し、後で実行再開すること望んでいるかどうかを判別するよう求められることがある。ユーザが肯定的に答えた場合、プロセスのＸＭＬでカプセル化された状態を捕捉し、永続的ストア１６３４に格納する。後から、ユーザはノード１６３２でモバイル・コンピューティング・デバイスに接続する。一実施形態では、ユーザはプロセス１６３６ｂを実行し、［Ｒｅｓｕｍｅ　ｆｒｏｍ　Ｓｔｏｒｅｄ　Ｓｔａｔｅ］オプションを選択する。次に、ノード１６３２は、プロセスＡ　１６３８のＸＭＬでカプセル化された状態をサーチして特定し、ダウンロードし、それを使用してプロセスＡ　１６３６ｂを再開する。それとは別に、プロセスはそれ自体、他のノード上で「サスペンド」していたことを認識し、ユーザの入力がなくても格納された状態から再開する。
【０４４８】
アプリケーション
ユーザがリモートの場所からネットワーク・データにアクセスし、ユーザがブラウザにアクセスした場合にリモート・データをユーザにローカル・データのように見せかける技術が存在する。ただし、このような技術では、クライアント・デバイスの位置近くのネットワークにクエリを実行する自動的インフラストラクチャが実現されない。クライアント・デバイス近くにあるネットワークおよびサービスに関する情報を発見するメカニズムがあることが望ましい。たとえば、このようなメカニズムを使用する際に、クライアント・デバイスの一定距離範囲（半径）内にあるレストラン、天候、地図、交通、映画情報などに関する情報を特定し、目的の情報をクライアント・デバイスに表示することができる。このメカニズムを使用する例として、ローカル環境、たとえば映画館の中で現在上映中作品のタイトルや上演時間を表示したり、レストランでメニュー選択と価格を表示するために、サービスを自動的に特定することができる携帯電話が考えられる。ここで説明しているような分散コンピューティング環境では、このようなメカニズムを使用してクライアント・デバイスに近接するローカル情報および／またはサービスを含むスペースを発見することができる。このメカニズムはさらに、他の分散コンピューティング環境、たとえば、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のＪｉｎｉシステムで応用することができる。
【０４４９】
一実施形態では、モバイル・クライアント・デバイスは、グローバル・ポジショニング・システム（ＧＰＳ）機能と無線接続技術を備える。ローカル分散コンピューティング・ネットワークを実現できる。たとえば、都市に、全市内分散コンピューティング環境を築くことができる。他の例としては、ローカル分散コンピューティング環境を備えるショッピング・モールがある。ローカル分散コンピューティング・ネットワークは、クライアント・デバイスが分散コンピューティング環境に接続し、ローカル環境内でサービスおよびデータを発見することができる発見メカニズムを備える。たとえば、環境内の１つまたは複数のデバイスが無線接続技術を備え、これによりモバイル・クライアント・デバイスはネットワークに接続し、前述のＸＭＬメッセージング・システムを介して発見メカニズムにアクセスすることができる。ローカル分散コンピューティング環境は、サービスおよび／またはデータをモバイル・クライアントから利用できるようにするための通知を使用する１つまたは複数のスペースを備える。たとえば、全市内分散コンピューティング環境は、モール、映画館、ローカル・ニュース、ローカルの天候、交通などのエンティティを表すスペースを含む。スペースは、スペースが表すエンティティのサービスおよびそれに関する情報にアクセスするための個々のサービスおよび／またはデータ通知を含む。発見メカニズムは、ローカル分散コンピューティング環境、環境内のスペース・サービスによって表されるエンティティ、および／または環境内のスペースで通知されるさまざまなサービスの１つまたは複数のＧＰＳ位置測定機能を含む。
【０４５０】
一実施形態では、ローカル分散コンピューティング・ネットワークへの有線接続が提供される。この環境では、モバイル・クライアント・デバイスを使用するユーザは、有線接続の「ドッキング・ステーション」を使用してネットワークに直接「プラグイン」することができる。有線接続の例としては、これらに限定されないが、ユニバーサル・シリアル・バス（ＵＳＢ）、ＦｉｒｅＷｉｒｅ、およびツイストペア・インターネットなどがある。一実施形態では、トーキング・ステーションはさらに、モバイル・クライアント・デバイス用のキーボード、マウス、およびディスプレイなどの入出力機能を備える。この実施形態では、モバイル・クライアント・デバイスの位置が、ドッキング・ステーションによりルックアップ・メカニズム又は発見メカニズムに送られる。
【０４５１】
一実施形態では、モバイル・クライアント・デバイスは、分散コンピューティング・ネットワークに接続する。モバイル・クライアント・デバイスのユーザが分散コンピューティング・ネットワークの無線通信到達範囲内でナビゲートするときに、モバイル・クライアント・デバイスは、常時、またはさまざまな間隔で、ローカル・ルックアップ・メカニズム又は発見メカニズムへの入力として位置ベクトルを供給する。モバイル・クライアント・デバイスは、モバイル・クライアントに組み込まれている、または関連付けられているＧＰＳシステムから位置ベクトルを取得する。一実施形態では、クライアントは位置情報を（たとえば、ＸＭＬメッセージングを介して）ここで説明したスペース特定メカニズムなどのローカル・サービス発見メカニズムに送る。たとえば、クライアントは、クライアントの位置の特定の範囲内でサービスを提供するスペースの発見を指定するスペース発見プロトコルを実行するか、またはクライアントはクライアントの近傍に対して提供されるサービスを通知するスペースをサーチするためのスペース・サーチ・サービスをインスタンス化する。
【０４５２】
モバイル・クライアント・デバイスが分散コンピューティング環境内のスペースの指定された範囲内に移動したときに、そのスペース内に格納されているサービスおよび／またはデータをモバイル・クライアント・デバイスから利用できるようにする。クライアント・デバイスが定期的にその位置を発見メカニズムに伝える実施形態では、ローカル・サービスおよび／またはデータは自動的に、クライアントのユーザから利用できるようになる。一実施形態では、モバイル・クライアント・デバイスのユーザは、スペースの指定された範囲を調べる。たとえば、ユーザは選択により、現在の位置から１マイルの範囲内にあるすべてのレストランを表示することができる。それとは別に、ローカル分散コンピューティング・ネットワークの構成で範囲を指定することもできる。たとえば、市境から３マイル以内にいるすべてのユーザにそのサービスを提供するように、全市内分散コンピューティング・ネットワークを構成することができる。一実施形態では、スペースによって提供されるさまざまなサービスおよび／またはデータを表す視覚的インジケータ、たとえば、アイコンをモバイル・クライアント・デバイスに表示することができる。そこで、クライアントは、表示されているサービスおよび／またはデータの１つまたは複数にアクセスすることができる。一実施形態では、２つまたはそれ以上のスペースから得た情報を同時に、モバイル・クライアント・デバイスに表示することができる。一実施形態では、ユーザは検出するサービスおよび／またはデータを選択することができる。たとえば、ショッピング・モールでは、モバイル・クライアント・デバイスを携帯するユーザは選択により、モール内のすべての靴屋を表示することができる。
【０４５３】
一実施形態では、コードの実行で使用される実行可能コードおよび／またはデータをモバイル・クライアント・デバイスにダウンロードし、ユーザがスペース内のサービスによって提供されるアプリケーションを実行するようにできる。たとえば、映画を見に行く人は、モバイル・クライアント・デバイスがあれば、映画館のスペース内のサービスから対話的な映画レビューをダウンロードし、自分が見ている映画に関するフィードバックをリアルタイムで送り返すことができる。一実施形態では、別のところで説明しているように、ＸＭＬオブジェクト・コンパイル／逆コンパイル・メカニズムを使用し、コードおよび／またはデータをコンパイルしてコードおよび／またはデータのＸＭＬ表現を出力したり、ＸＭＬ表現を逆コンパイルしてコードおよび／またはデータをモバイル・クライアント・デバイスに再現することができる。一実施形態では、プロセスの実行可能バージョンがすでにモバイル・クライアント・デバイスに存在し、プロセスの格納された状態をモバイル・クライアント・デバイスにダウンロードすることにより、ユーザが格納されている状態を使用してプロセスを実行することができる。一実施形態では、プロセスの実行可能バージョンがすでにモバイル・クライアント・デバイスに存在し、プロセスのデータをモバイル・クライアント・デバイスにダウンロードできる。たとえば、データをダウンロードして、モバイル・クライアント・デバイスのビューア・プログラムで表示することができる。一実施形態では、プロセスを実行するためのコードおよびデータを含むプロセスの実行可能バージョンをダウンロードして、モバイル・クライアント・デバイスで実行することができる。一実施形態では、モバイル・クライアント・デバイスに代わってサービスがリモートからアプリケーションを実行し、サービスとクライアントが、データおよびオプションでデータを記述するＸＭＬスキーマを含むＸＭＬメッセージを互いにやり取りすることができる。一実施形態では、サービス上で一部のコードを実行し、クライアント上で一部のコードを実行することができる。たとえば、サービスは、数値計算などのデータ・セットに対する演算を行うコードを実行することができる。モバイル・クライアント・デバイスは、ＸＭＬメッセージでサービスからクライアントに渡されたデータの一部を表示し、モバイル・クライアント・デバイスのユーザがデータを入力したり選択したり、またデータをサービスに送ってデータに対し１つまたは複数の演算を実行できるようにするコードを実行する。
【０４５４】
一実施形態では、モバイル・クライアント・デバイスは、分散コンピューティング・ネットワーク内で２つまたはそれ以上のサービスに同時に接続することができる。これらのサービスは、独立に使用することも、また一連のタスクを実行するのと合わせて使用することもできる。たとえば、１つのサービスをリモート・クライアント・デバイスが使用してデータ・セットに対する演算を特定しかつ／または実行し、第２のサービスを使用してデータ・セットを印刷する。
【０４５５】
図３８は、一実施形態によりローカルの分散コンピューティング・ネットワークでスペースにアクセスするモバイル・クライアント・デバイスの図である。ＧＰＳ対応モバイル・コンピューティング・デバイス１７００のユーザは、ローカル分散コンピューティング環境の近傍内に移動する。モバイル・クライアント・デバイス１７００は、ＧＰＳ１７０２によって提供される位置をローカル分散コンピューティング・ネットワーク内の１つまたは複数の発見メカニズム１７０６に送る。発見メカニズム１７０６は、モバイル・クライアント・デバイスの提供されたＧＰＳ位置と環境内のスペースの所定の位置を使用して、ユーザがいつ１つまたは複数のスペースの指定された範囲内または環境内の１つまたは複数のスペースが対応する近傍内を移動するかを判別する。たとえば、発見メカニズム１７０６は、モバイル・クライアント・デバイス１７００がスペース１７０４の範囲内を移動したことを判別できる。発見メカニズム１７０６は、そこで、スペース１７０４からモバイル・クライアント・デバイス１７００に１つまたは複数の通知１７１０を送る。それとは別に、発見メカニズム１７０６は、スペース１７０４またはスペース１７０４内の１つまたは複数の通知のＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）をモバイル・クライアント・デバイス１７００に送る。サービス通知１７０８で通知されるさまざまなサービスおよび／またはコンテンツ通知１７１０で表されるデータを表すアイコンを、モバイル・クライアント・デバイス１７００に表示することができる。そこで、ユーザはモバイル・クライアント・デバイスで実行するかつ／または表示するため通知されたサービスおよび／またはデータのうち１つまたは複数を選択できる。モバイル・コンピューティング・デバイス１７００は、サービスを提供するデバイスと無線接続を確立し、そのデバイスと通信して、前述のようにＸＭＬベースのメッセージング・システムを使用してサービスを実行する。それとは別に、モバイル・コンピューティング・デバイス１７００のユーザはドッキング・ステーションでデバイスに接続する。ドッキング・ステーションの位置は、ユーザがルックアップ・メカニズムまたは発見メカニズム１７０６と、ドッキング・ステーションの通知を含むスペースを使用してユーザの指定範囲内にあるストッキング・ステーションの位置を発見し利用できるかどうかを判別することにより、発見される。発見メカニズム１７０６は、さらに、モバイル・クライアント・デバイス１７００がスペース１７１４の選択された範囲内に移動したときにそのことを検出できる。さまざまなサービス通知１７１８およびコンテンツ通知１７２０をモバイル・クライアント・デバイス１７００のユーザから利用できるようにする。モバイル・クライアント・デバイスがスペースの１つの指定範囲の外に出たときに、そのスペースによって提供される通知はモバイル・クライアント・デバイス１７００のディスプレイから削除される。一実施形態では、スペース上の通知は、提供されるサービスまたはデータの位置情報を含む。したがって、発見メカニズム１７０６は、モバイル・クライアント・デバイス１７００がスペース１７１８上で通知された特定のサービスの指定範囲内をいつ移動したかを判別し、モバイル・クライアント・デバイス１７００の位置に基づいてサービス通知を送る（または削除する）。
【０４５６】
コンピューティング・デバイスは、同時にパワーと機能を獲得する一方でダウンサイジングを進めている。ストレージ・デバイス、ＣＰＵ、ＲＡＭ、Ｉ／Ｏ　ＡＳＩＣＳ、電源など、サイズが小さくなり、小型のモバイル・クライアント・デバイスにフルサイズのパソコンの機能の多くを搭載できる。しかし、コンピュータ・システムのコンポーネントのいくつかは、人的要因およびその他の要因のせいで簡単には縮小できない。こうしたコンポーネントとしては、それらに限定されないが、キーボード、モニタ、スキャナ、およびプリンタがある。一部のコンポーネントのサイズを縮小することに限度があるため、モバイル・クライアント・デバイスはパソコンの役割を真に肩代わりすることはできない。
【０４５７】
一実施形態では、ユーザがモバイル・クライアント・デバイスを使い、人的要因やその他の要因によりモバイル・クライアント・デバイスでは利用できないコンポーネントに接続し使用できるようにするドッキング・ステーションが提示されている。たとえば、ドッキング・ステーションは、空港や図書館などの公共の場所に備えることができる。ドッキング・ステーションは、モニタ、キーボード、プリンタ、またはモバイル・クライアント・デバイスを使用するユーザ用のその他のデバイスを備える。一実施形態では、ドッキング・ステーションは、ユーザが接続しているモバイル・クライアント・デバイスなどの実際のコンピューティング・デバイスの助けがないと完全には機能しない。ドッキング・ステーションは、さまざまな入出力機能などのサービスを、モバイル・クライアント・デバイスの計算能力を使用するクライアントに提供する。
【０４５８】
ドッキング・ステーションは、１つまたは複数の接続用オプションをモバイル・クライアント・デバイスに提供する。接続オプションには、無線接続や有線接続がある。無線接続の例としては、それらに限定されないが、ノートブック・コンピュータのネットワーク・インターフェース・カード（ＮＩＣ）で提供されるようなＩｒＤＡなどの赤外線や、無線ネットワーク接続がある。有線接続の例としては、それらに限定されないが、ＵＳＢ、ＦｉｒｅＷｉｒｅ、およびツイストペアＥｔｈｅｒｎｅｔなどがある。
【０４５９】
モバイル・クライアント・デバイスは、モバイル・クライアント・デバイスについて上述したものに実質的に似た方法を使用してドッキング・ステーションの位置を発見する。ローカル分散コンピューティング・ネットワーク内の１つまたは複数のドッキング・ステーションの位置を発見するには、発見メカニズムを使用して、ドッキング・ステーションの通知があるスペースを発見する。モバイル・クライアント・デバイスは、位置を発見メカニズムに送る。一実施形態では、発見メカニズムまたはルックアップ・メカニズムは、モバイル・クライアント・デバイスの位置に最も近い１つまたは複数のドッキング・ステーションの位置を返す。それとは別に、発見メカニズムまたはルックアップ・メカニズムはドッキング・ステーションの通知を含むスペースのＵＲＩを返し、その後、モバイル・クライアント・デバイスはスペースに接続して、デバイスに近いところにある１つまたは複数のドッキング・ステーションの位置を送る。一実施形態では、モバイル・クライアント・デバイスは、ルックアップ・メカニズム又は発見メカニズムに情報を供給し、モニタの解像度、画面サイズ、グラフィック能力、プリンタやスキャナなどの使用可能なデバイスなどの要求条件を指定することができる。一実施形態では、さまざまなドッキング・ステーションの使用可能性（ドッキング・ステーションを使用する他のユーザから）、コンポーネント、および能力などの１つまたは複数のドッキング・ステーションに関する情報をモバイル・クライアント・デバイスのユーザに提供する。
【０４６０】
ユーザがドッキング・ステーションに接近すると請求プロトコルが開始する。ドッキング・ステーションがその請求を受理すると、セキュリティで保護された入出力接続が、モバイル・クライアント・デバイスとドッキング・ステーションとの間で確立される。それとは別に、ユーザはモバイル・クライアント・デバイスに表示されるルックアップ・メカニズム又は発見メカニズムを使用して発見された１つまたは複数のドッキング・ステーションのうちからドッキング・ステーションを選択する。ユーザがドッキング・ステーションを選択すると請求プロトコルが開始し請求の持続時間中、ユーザに、ドッキング・ステーションへのセキュリティで保護された排他的接続が与えられる。ユーザがドッキング・ステーション上のセッションを終了し、ドッキング・ステーションを開放して他のユーザが利用できるようにするドッキング・ステーションの解放方法も定める。一実施形態では請求プロトコルは、前述のようにドッキング・ステーション・サービス上のリースとすることができる。
【０４６１】
図３９ａは、一実施形態により、モバイル・デバイスのユーザがドッキング・ステーションの場所を発見することを示す図である。モバイル・クライアント・デバイス１７５０は、発見メカニズム１７５６と接続する。モバイル・クライアント・デバイス１７５０は、ＧＰＳ　１７５２を使用して得られた位置を発見メカニズム１７５６に送る。モバイル・クライアント・デバイス１７５０は、さらに、ドッキング・ステーションの要求条件を発見メカニズム１７５６に送る。発見メカニズム１７５６は、モバイル・クライアント・デバイス１７５０の要求条件を満たすドッキング・ステーション１７５８の通知に対して１つまたは複数のスペース１７５４をサーチする。一実施形態では、ルックアップ・メカニズム又は発見メカニズムが、通知１７５８に格納されている位置情報をモバイル・デバイス１７５０の与えられた位置と比較してモバイル・デバイス１７５０の指定範囲内にある１つまたは複数のドッキング・ステーションを特定する。発見メカニズム１７５６は、そこで、モバイル・クライアント・デバイス１７５０の指定範囲内にある１つまたは複数のドッキング・ステーションの位置を与える。それとは別に、発見メカニズム１７５６はモバイル・クライアント・デバイス１７５０に最も近いドッキング・ステーションを特定し、その位置をモバイル・クライアント・デバイス１７５０に送る。
【０４６２】
図３９ｂは、一実施形態によるドッキング・ステーション１７６０に接続するモバイル・クライアント・デバイス１７５０の図である。一実施形態では、ユーザはモバイル・クライアント・デバイス１７５０をドッキング・ステーション１７６０に無線で接続する。他の実施形態では、ユーザはドッキング・ステーション１７６０とモバイル・クライアント・デバイス１７５０とを１つまたは複数のケーブルで接続してクッキング・ステーション１７６０との有線接続を確立する。一実施形態では、モバイル・クライアント・デバイス１７５０のユーザはドッキング・ステーション１７６０への請求を確立する。この請求により、接続時間中、ドッキング・ステーションへのセキュリティで保護された排他的権限を確立する。一実施形態では請求メカニズムは、前述のようにリソース（ドッキング・ステーション）のリース・メカニズムである。一実施形態では、ユーザは、ドッキング・ステーションの使用に対し対価支払いを請求される。たとえば、ユーザは、ドッキング・ステーションを請求するプロセスの一部としてクレジット・カード番号を指定する。「メッセージ・ゲート」の項の請求書ゲートの説明を参照のこと。いったん接続されると、ユーザはキーボード、モニタ、プリンタなど、ドッキング・ステーション１７６０によって提供されるさまざまな機能を使用できる。ドッキング・ステーション１７６０はさらに、ローカル分散コンピューティング・ネットワークへの接続も含み、ドッキング・ステーション１７６０に接続されているモバイル・クライアント・デバイス１７５０のユーザに対しネットワーク内の他のデバイスのサービスおよびコンテンツ通知を特定する発見サービスを提供しているため、ユーザは前述のように、分散コンピューティング環境内のさまざまなサービスおよびコンテンツを特定し、使用することができる。
【０４６３】
ユーザは、終了すると、モバイル・クライアント・デバイス１７５０をドッキング・ステーション１７６０から切断する。一実施形態ではドッキング・ステーションの解放メカニズムは、モバイル・クライアント・デバイス１７５０がドッキング・ステーション１７５０から切断されると自動的に開始する。この解放メカニズムにより、モバイル・クライアント・デバイス１７５０のユーザが確立したドッキング・ステーション１７６０の請求がクリアされる。一実施形態では、この解放メカニズムは、ドッキング・ステーションが利用できることを発見メカニズムに１７５６および／またはドッキング・ステーション通知１７５８に通知する。
【０４６４】
一実施形態では、ユーザは発見メカニズムを使用せずにモバイル・クライアント・デバイスをドッキング・ステーションに接続することができる。たとえば、空港内にいるユーザは、ドッキング・ステーションで目で見て見つけ、モバイル・クライアント・デバイスを接続する。他の例としては、複数のドッキング・ステーションを配置したドッキング・ステーション室を備える図書館が考えられ、ユーザはそこで利用可能なドッキング・ステーションにアクセスすることができる。
【０４６５】
省スペースおよび／または組み込み型デバイス
単純な組み込み型または省スペース・デバイスでは、プログラムの命令を格納し実行しようにもメモリ容量が限られている場合がある。単純な組み込み型デバイスは、デバイスの機能を開始するための制御入力とデバイスのステータスを報告するための出力に制限があることを認識する必要がある。単純な組み込み型デバイスの一例として、スイッチとそのスイッチにより制御されるデバイスを制御するための回路を組み込んだ「スマート」スイッチ（照明スイッチなど）がある。スマート・スイッチは、２つの制御要求（デバイスの状態を変更する、デバイスの状態を要求する）を認識し、１つのステータス・メッセージ（デバイスの状態）を送るだけでよい。スマート・スイッチは、１つまたは複数の制御システムから制御要求を受け取り、その１つまたは複数の制御システムにステータス・メッセージを報告することにより、接続されているデバイスを管理することができる。
【０４６６】
一実施形態では、分散コンピューティング環境は、分散コンピューティング環境の完全なプロトコルを実装するのに必要なリソース（メモリなど）が足りない小型デバイスを含めるためのフレームワーク（プロトコル）を提供する。一実施形態では、小型デバイス対応プロトコルと完全なプロトコルとの間にブリッジとしてエージェントを用意する。このエージェントは、小型デバイスのために完全なプロトコルの発見を実行するので、デバイスは完全な発見プロトコルおよびサービス・アクティブ化を実行する必要がない。一実施形態では、小型デバイスはサービス特有のメッセージを送るだけでよい。一実施形態では、これらのメッセージは、小型デバイスで事前に加工され、小型デバイスはサービス・アクティブ化の一部であるメッセージをエージェントに送るだけである。エージェントは、サービスに対し完全なプロトコルを介してサービス・アクティブ化を実行し、サービスからサービスへ着信メッセージを転送したり、サービス化がクライアントへ返信を転送したりすることができる。したがって、エージェントは小型クライアントのサービス・コネクタとして機能する。分散コンピューティング環境の一実施形態では、特定の制御要求セットをＸＭＬメッセージの形式で受け取り、要求、報告ステータスなどを作成する特定のＸＭＬメッセージ・セットを送るように組み込み型デバイスを構成することができる。一実施形態では、制御システムは、制御される各デバイスまたはデバイスのカテゴリに固有のＸＭＬ要求メッセージを送り、デバイスからＸＭＬメッセージを受け取ることによりさまざまなデバイスを管理するように構成できる。一実施形態では、１つまたは複数のＸＭＬスキーマを使用して、組み込み型デバイスの固有のＸＭＬメッセージ・セットを定義することができ、スキーマは、ＸＭＬメッセージを送受される際に組み込み型デバイスおよび／または制御システムによって使用される。
【０４６７】
組み込み型デバイスは、単純な組み込み型デバイスを制御し監視するための特定のメッセージ・セットをサポートする前述のようなＸＭＬメッセージング・システムの「軽量（シン）」実装を含む。ＸＭＬメッセージング・システムの実装は、省スペースの単純な組み込み型デバイスで使用できるように手直しされ、省スペース・デバイスの限られたメモリにも適合する。一実施形態では、ＸＭＬメッセージング・システムは、省スペース組み込み型デバイスをターゲットとする仮想マシン（たとえば、ＫＶＭ）を備える省スペース・デバイスに実装することができる。ネットワーキング・スタック（１つまたは複数の制御システムとの通信のためのトランスポート・プロトコルをサポートする）は、仮想マシンと関連付けられ、ＸＭＬメッセージング・レイヤはネットワーキング・スタックの「上に置かれる」。メッセージング・システムのこのような実装は、省スペース・デバイスや組み込み型デバイス以外のデバイスでも使用できることに注意されたい。
【０４６８】
一実施形態では、静的メッセージまたは事前に生成されたメッセージを、制御システムから組み込み型デバイスへの要求に使用する。静的メッセージは、プリコンパイルされ、組み込み型デバイス内に格納される。着信メッセージを格納されている静的メッセージと比較し、メッセージのマッチがないか調べてメッセージで要求された機能を実行するので、着信メッセージを解析するためのコードの必要性が減じられるか、またはその必要がない。発信メッセージは、格納されている静的メッセージから直接読み取られるため、発信メッセージを動的にコンパイル必要は少ないか、またはその必要がない。したがって、静的メッセージは、組み込み型システムのメッセージング・レイヤのコード量を減らすために使用される。たとえば、静的なＪａｖａオブジェクト（Ｊａｖａ　ｏｐコード）を要求メッセージとステータス・メッセージに使用できる。
【０４６９】
図４０ａは、一実施形態により、制御システム１８００により制御される組み込み型デバイス１８０４ａと１８０４ｂの一実施形態を示す。制御システム１８００は、そのシステムが制御するデバイス１８０４ａおよび１８０４ｂとさまざまな方法でネットワークにつながっている。ネットワーク１８１０は有線（Ｅｔｈｅｒｎｅｔ、同軸、ツイストペア、電力網など）および／または無線（ＩｒＤＡ、マイクロ波など）を利用できる。一実施形態では、組み込み型デバイス１８０４ａおよび１８０４ｂは、ネットワーク１８１０上で制御システム１８００と通信するためＸＭＬメッセージング・システムのシン実装を備える。制御システム１８００は、組み込み型デバイス１８０４ａおよび１８０４ｂに要求を送り、そこから応答を受け取るためのＸＭＬメッセージング・システムの実装を用意する。一実施形態では、制御システム１８００は、ユーザが組み込み型デバイス１８０４ａと１８０４ｂのステータスを表示し、遠隔制御するためのインターフェースを備えるように構成されたソフトウェアおよびハードウェアを搭載する。一実施形態では、制御システム１８００は、組み込み型デバイス１８０４ａおよび１８０４ｂの自動制御を行うためのソフトウェアおよび／またはハードウェアを備える。
【０４７０】
一実施形態では、組み込み型デバイス１８０４ａと１８０４ｂは、他の環境の一部である。それらのデバイスは、分散ネットワーク環境で実装されているメッセージ通信モデルをサポートしていない。たとえば、これらのデバイスは、ＬｏｎＷｏｒｋｓネットワークなどのネットワークで接続されたオートメーションおよび制御システム内のノードである。制御システム１８００は、他の環境内のデバイスを制御するための制御システムのハードウェアおよび／またはソフトウェアを含む。制御システム１８００は、分散コンピューティング環境と他の環境との間のブリッジとして使用される。分散コンピューティング環境ではさらに、分散コンピューティング環境からアクセスするデバイスを発見するため既存のデバイス発見プロトコルをラップする１つまたは複数の方法も備える。ブリッジおよびラップを行うプロトコルについては「ブリッジ」の項で詳述する。
【０４７１】
制御システム１８００は、リモートまたはローカルで、分散コンピューティング環境内の１つまたは複数の他のシステムに接続する。図４０ａは、インターネット１８０２を介してクライアント１８０６に接続されている制御システム１８００を示している。クライアント１８０６は、制御システム１８００を通じて、組み込み型デバイス１８０４ａおよび１８０４ｂのステータスを間接的に要求し、その制御要求を送る。したがって、制御システム１８００は、組み込み型デバイス１８０４ａおよび１８０４ｂのプロキシまたはブリッジとして使用される。「ブリッジ」の項を参照されたい。クライアント１８０６と制御システム１８００との間の高度な通信を有効にするために、クライアントと制御システムは、組み込み型デバイス１８０４ａおよび１８０４ｂ上のシン実装と異なるＸＭＬメッセージング・システムの実装を備える。一実施形態では、クライアント１８０６は、ユーザが組み込み型デバイス１８０４ａと１８０４ｂのステータスを表示し、遠隔制御するためのインターフェースを備えるように構成されたソフトウェアおよびハードウェアを搭載する。一実施形態では、クライアント１８０６は、正しい承認証明書を制御システム１８００に提示し、クライアント１８０６が組み込み型デバイス１８０４ａおよび１８０４ｂにアクセスできるようにする必要がある。一実施形態では、クライアント１８０６は、異なるレベルのアクセス権を与えられる。たとえば、クライアント１８０６は、組み込み型デバイス１８０４ａおよび１８０４ｂのステータスを表示することしかできず、デバイスを遠隔制御することはできない。一実施形態では、制御システム１８００はサービスであり、分散コンピューティング環境でサービス通知がパブリッシュされ、そのため、クライアント１８０６は前述のようにクライアント−サービス手法を使用してアクセスできる。一実施形態では、クライアント１８０６は制御システム１８００のステータスを表示し、遠隔制御することができる。
【０４７２】
図４０ｂは、一実施形態により、インターネット１８０２を介して組み込み型デバイス１８０４ｃおよび１８０４ｄに接続されているクライアント制御システム１８０８を示している。一実施形態では、組み込み型デバイス１８０４ｃおよび１８０４ｄは、ネットワーク１８０２上でクライアント制御システム１８０８と通信するためＸＭＬメッセージング・システムのシン実装を備える。クライアント制御システム１８０８は、組み込み型デバイス１８０４ｃおよび１８０４ｄに要求を送り、そこから応答受け取るためのＸＭＬメッセージング・システムの実装を用意する。一実施形態では、クライアント制御システム１８０８は、ユーザが組み込み型デバイス１８０４ｃと１８０４ｄのステータスを表示し、遠隔制御するためのインターフェースを備えるように構成されたソフトウェアおよびハードウェアを搭載する。一実施形態では、クライアント制御システム１８００は、組み込み型デバイス１８０４ｃおよび１８０４ｄの自動制御を行うためのソフトウェアおよび／またはハードウェアを備える。
【０４７３】
図４０ａと図４０ｂとの違いは、図４０ｂに示されている実施形態では、組み込み型デバイス１８０４ｃと１８０４ｄは、プロキシ（たとえば、制御システム）なしで分散コンピューティング環境内の１つまたは複数のクライアントによりアクセスされるという点である。組み込み型デバイス１８０４ｃおよび１８０４ｄは、デバイスの機能にアクセスするためのサービスを備え、分散コンピューティング環境内でサービス通知をパブリッシュし、前述のようにクライアント−サービス手法を介してアクセスされる。
【０４７４】
分散コンピューティング環境は、リソースが制限されているクライアントがＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）アドレス指定リソースを取り出すためのメカニズムを備える。たとえば、ＩｒＤＡ接続を介してでないとメッセージを送受できないクライアントは、ＵＲＩ接続を確立して、結果スペースから結果を取り出すことができない。一実施形態では、クライアントとＵＲＩリソースとの間のブリッジとしてサービスを提供する。ブリッジ・サービスは、ＸＭＬメッセージを介してクライアントと対話し、入力パラメータを集める。以下に、ＸＭＬ入力メッセージシンタックスの一例を示したが、何らかの形で制限することを意図していない。

【０４７５】
次に、分散コンピューティング環境の外部で、ブリッジ・サービスはＵＲＩ接続を確立し、リソースを取り出す。リソースは、１つまたは複数のＸＭＬメッセージでペイロードとしてカプセル化され、ブリッジ・サービスによってクライアントに送られる。
【０４７６】
ＸＭＬメッセージング・システムのシン実装を備える組み込み型デバイスの可能な使い方の一例を説明のため掲載しているが、制限することを意図していない。建物には、エネルギーを消費する複数のエレクトロニクス・デバイス（たとえば、照明、空調、事務機器）が置かれているため、最適なエネルギー消費レベルを維持するためのシステムを必要とする。このような複数のデバイスはそれぞれ、エレクトロニクス・デバイスを制御するための組み込み型デバイスを備える。これらの組み込み型デバイスは、ＸＭＬメッセージング・システムのシン実装を備える。１つまたは複数の制御システムを、ネットワーク、たとえば、建物内ＬＡＮやさらにはインターネット内のデバイスに結合する。制御システムでは、建物管理ソフトウェア・パッケージおよびデバイスを監視し制御するためソフトウェア・パッケージによって使用されるように構成されているＸＭＬメッセージング・システムの実装を格納し、実行する。制御システムは、ユーザからの入力を受け付け、複数のデバイスのそれぞれのステータス情報はじめとする、建物内エネルギー消費システムのステータス情報を表示し、他の何らかの方法で出力する。エネルギー消費は、複数のデバイスのそれぞれからＸＭＬステータス・メッセージを受け取ることにより監視する。エネルギー消費レベルを調整する必要がある場合、ＸＭＬ制御メッセージを１つまたは複数のデバイスに送ってエネルギー消費を変更させる。
【０４７７】
サービスの実装
一実施形態では、分散コンピューティング環境はサービスをサーブレットとして実装するためのメカニズムを備える。このメカニズムは、分散コンピューティング環境向けにサービスを開発するための機能を備える。
【０４７８】
一実施形態では、スペース内でサービスを初期化し登録するための機能を備えるアプリケーション・プログラミング・インターフェース（ＡＰＩ）が提供される。一実施形態では、このＡＰＩを使用して、サービスの初期化機能を呼び出し、サービスのステータスを定義する初期化ステータス・ページ、たとえば、ＨＴＭＬページを生成することができる。ユーザは、ブラウザからステータス・ページにアクセスすることによりサービスのステータスにアクセスできる。一実施形態では、ＡＰＩを使用して、着信メッセージを処理し、そのメッセージに応答してドキュメントを生成する。
サーブレット・メカニズムの実施形態では、それに限定されないが、以下のような複数の機能を提供する。
サービスへのクライアント接続の管理（一意的なセッションＩＤ）
結果通知を格納するために使用されるアクティブ化スペースの管理
アクティブ化スペースの接続セッションおよび結果に対するリースの管理
セッションおよび結果のガベージ・コレクション
クライアントの認証
セッションごとのクライアント機能の生成
【０４７９】
一実施形態では、分散コンピューティング環境は、新しい複雑なサービスを他の既存のサービスから構築するためのサービス・カスケード接続メカニズムを備える。たとえば、ＪＰＥＧ−ＰｏｓｔＳｃｒｉｐｔ変換サービスおよび印刷サービスから、変換および印刷サービスを組み合わせることで、第３のカスケード接続されたサービスを作成する。一実施形態では、２つまたはそれ以上のサービスのアクセス・メソッドをカスケード接続されたサービスのアクセス・メソッドとして定義することにより２つまたはそれ以上のサービスを組み合わせて１つの複雑なサービスを作る。カスケード接続サービスに対する以下のサービス通知は、説明のため掲載したものであり、いかなる形でも制限することを意図していない。

【０４８０】
結論
さまざまな実施形態はさらに、キャリア媒体に関する前述の説明により実装された命令および／またはデータを受け取り、送り、または格納することを含む。一般に、キャリア媒体には、磁気または光媒体などの記憶媒体やメモリ媒体、たとえば、ディスクやＣＤ−ＲＯＭ、ＲＡＭ（ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性または不揮発性媒体、さらに、ネットワークおよび／または無線リンクなどの通信媒体を介して伝達される電気信号、電磁信号、またはデジタル信号などの伝送媒体または信号が含まれる。
【０４８１】
本開示を利用しようとする当業者には明白なように、さまざまな修正および変更が可能である。本発明はそのような全ての修正および変更を包括的に取り入れることを意図しており、したがって、明細書、付録、および図面は、制限のためではなく、説明のためであるとみなすべきである。
【図面の簡単な説明】
【図１】
従来の分散コンピューティング技術の積み重ねの図である。
【図２】
一実施形態による分散コンピューティング環境プログラミング・モデルの図である。
【図３】
一実施形態による分散コンピューティング環境のメッセージング・レイヤおよびネットワーキング・レイヤの図である。
【図４】
一実施形態により分散コンピューティング環境でオブジェクトまたはサービスを通知するスペースを見つけるための発見サービスの図である。
【図５】
一実施形態による分散コンピューティング環境の静的メッセージおよび書式付きメッセージをサポートするクライアント・プロファイルの図である。
【図６】
一実施形態によるＸＭＬメッセージングを採用する分散コンピューティング・モデルの図である。
【図７】
一実施形態によるプラットフォーム独立の分散コンピューティング環境の図である。
【図８】
一実施形態によりスペース内でサービスが通知される分散コンピューティング・モデルの図である。
【図９】
一実施形態によりスペース内に結果が格納される分散コンピューティング・モデルの図である。
【図１０】
ａ：一実施形態による分散コンピューティング・モデル内のメッセージング・エンドポイントとしてのクライアントおよびサービス・ゲートの図である。
ｂ：　一実施形態によりサービスにアクセスするためスキーマに従ってメッセージ・エンドポイントを生成することを示す図である。
【図１１】
ａ：一実施形態による分散コンピューティング環境におけるゲート作成の図である。
ｂ：一実施形態による分散コンピューティング環境におけるゲート作成とゲート・ペアの図である。
【図１２】
一実施形態による分散コンピューティング環境での可能なゲート構成要素の図である。
【図１３】
一実施形態による分散コンピューティング環境に参加する従来のプラウザ用のプロキシ・クライアントの図である。
【図１４】
一実施形態により分散コンピューティング環境でメソッド・ゲートを使用してリモート・メソッド呼び出しインターフェースをサービスに提供する方法を示す図である。
【図１５】
一実施形態により分散コンピューティング環境でスペースを使用する方法を示す図である。
【図１６】
一実施形態による通知構造を示す図である。
【図１７】
一実施形態により通知がその存続期間中に置かれる通知状態遷移の一例を示す図である
【図１８】
一実施形態による分散コンピューティング環境でのさまざまなスペース特定メカニズムの図である。
【図１９】
一実施形態による分散コンピューティング環境でのスペース連合の図である。
【図２０】
一実施形態により分散コンピューティング環境でクライアントがスペース・サービスによりセッションを形成する方法を示す流れ図である。
【図２１】
一実施形態のスペース・イベント型階層の図である。
【図２２】
一実施形態による分散コンピューティング環境でのサービス・インスタンス化を示す流れ図である。
【図２３】
一実施形態による分散コンピューティング環境でのデフォルトのスペースの図である。
【図２４】
一実施形態により、近傍ベースのデバイスから提供されるサービスをデバイスの近傍の範囲外にあるデバイスでアクセスできるようにする近傍ベースのデバイスを他のトランスポート・メカニズムにブリッジするデバイスの一例を示す図である。
【図２５】
一実施形態により分散コンピューティング環境でリース更新メッセージを使用する方法を示す図である。
【図２６】
ａ：一実施形態により、認証証明書をクライアントに提供する認証サービスを示す流れ図である。
ｂ：一実施形態により、図２６ａのステップ１００２上で展開し、認証証明書を生成する認証サービスを示す流れ図である。
【図２７】
ブリッジ・メカニズムの一実施形態の図である。
【図２８】
一実施形態により外部発見サービスにマップされるスペース発見プロトコルの一例の図である。
【図２９】
一実施形態により、分散コンピューティング環境の外部にあるクライアントを分散コンピューティング環境内のスペースにブリッジする方法を示す図である。
【図３０】
一実施形態によるプロキシ・メカニズムの図である。
【図３１】
一実施形態による関連するディスプレイおよび表示サービスを備えるクライアントの一実施形態の図である。
【図３２】
一実施形態により動的表示オブジェクトのスキーマを使用する例を示す図である。
【図３３】
Ａ：Ｃプログラミング言語による代表的ストリング表現の図である。
Ｂ：従来のストリング関数の例を示す図である。
Ｃ：一実施形態により、一般にはストリングを、具体的には組み込み型システムなどの省スペース・システムを表現し管理する効率的な方法を示す図である。
【図３４】
一実施形態により、クライアントとサービスの間でオブジェクトを移動するプロセスを示す図である。
【図３５】
仮想マシン（たとえば、ＪＶＭ）がオブジェクト（たとえば、Ｊａｖａオブジェクト）をオブジェクトのＸＭＬ表現にコンパイルする拡張機能および（Ｊａｖａ）オブジェクトのＸＭＬ表現を（Ｊａｖａ）オブジェクトに逆コンパイルする拡張機能を含む実施形態を示すデータ流れ図である。
【図３６】
一実施形態により分散コンピューティング環境でストア・メカニズムにアクセスするクライアントおよびサービスの図である。
【図３７】
一実施形態によりプロセスの状態のＸＭＬ表現を使用するプロセス移行を示す図である。
【図３８】
一実施形態によりローカルの分散コンピューティング・ネットワークでスペースにアクセスするモバイル・クライアント・デバイスの図である。
【図３９】
ａ：一実施形態により、モバイルデバイスのユーザがドッキング・ステーションの場所を発見すること示す図である。
ｂ：一実施形態によるドッキング・ステーションに接続するモバイル・クライアント・デバイスの図である。
【図４０】
ａ：一実施形態により、制御システムにより制御され、分散コンピューティング環境内でアクセス可能な組み込み型デバイスの一実施形態を示す図である。
ｂ：一実施形態により、ネットワーク（たとえば、インターネット）を介して分散コンピューティング環境内でアクセス可能な組み込み型デバイスに接続するデバイス制御システムの図である。
【図４１】
一実施形態による、分散コンピューティング環境での、新しいスペースの作成を示す流れ図である。
【図４２】
一実施形態による、分散コンピューティング環境での、新しいスペースの保護された作成を示す流れ図である。
【図４３】
一実施形態による、分散コンピューティング環境での、サーチ・サービスを使用するスペースのサーチを示す流れ図である。
【図４４ａ】
一実施形態による、分散コンピューティング環境での、サービスの結果をスペース内に格納する方法を示す流れ図である。
【図４４ｂ】
一実施形態による、分散コンピューティング環境での、サービスの結果をスペース内に格納し、イベントを使用してクライアントに通報する方法を示す流れ図である。
【図４４ｃ】
一実施形態による、分散コンピューティング環境での、サービスの結果をメッセージ内で送る方法を示す流れ図である。
【図４４ｄ】
一実施形態による、分散コンピューティング環境での、通知を使用してサービスの結果を返す方法を示す流れ図である。
【図４４ｅ】
一実施形態による、分散コンピューティング環境での、クライアントに発送される通知を使用してサービスの結果を返す方法を示す流れ図である。
【図４４ｆ】
一実施形態による、分散コンピューティング環境での、スペースに格納された通知を使用してサービスの結果を返す方法を示す流れ図である。
【図４４ｇ】
一実施形態による、分散コンピューティング環境での、スペースに格納された通知と、イベントを使用することによるクライアントへの通報とを使用してサービスの結果を返す方法を示す流れ図である。
【図４５】
一実施形態による、分散コンピューティング環境での、あるサービスの結果を別のサービスに送る方法を示す流れ図である。
【図４６ａ】
一実施形態による、分散コンピューティング環境での、サーチ・サービスと、サーチ・サービスとクライアントの対話を示す図である。
【図４６ｂ】
一実施形態による、分散コンピューティング環境での、サーチ・サービスと、サーチ・サービスとクライアントの対話を示す図である。
【図４７】
一実施形態による、分散コンピューティング環境での、スペース内のドキュメントのサーチを示す流れ図である。
【図４８】
一実施形態による、分散コンピューティング環境での、スペース内に格納された通知を使用する、サービスのアドレッシングを示す流れ図である。

Claims (45)

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. 通知が結果のセットのＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｎｄｉｃａｔｏｒ（ＵＲＩ）を含む請求項２２に記載の方法。
30. 第１クライアントと、
    第１クライアントに通信可能に結合された第１サービスと
    を含むシステムであって、
    第１クライアントが、第１サービスの１つまたは複数の関数を呼び出すために、第１サービスに第１メッセージを送るように動作可能であり、その際、第１サービスに関するスキーマが第１サービスの関数を呼び出すのに使用可能な複数のメッセージを指定し、第１メッセージがスキーマによって指定され、
    第１サービスが、
    第１クライアントによって送られた第１メッセージを受け取り、
    第１メッセージに応答して、データ表現言語で表現された結果のセットを生成し、
    データ表現言語で表現された、結果のセットを含む第２メッセージをクライアントに送るように動作可能であるシステム。
31. 第１サービスのスキーマが第１サービスの関数を呼び出すのに使用可能な複数のメッセージを指定し、第１メッセージがスキーマによって指定されるようになっていて、第１クライアントが、第１サービスの１つまたは複数の関数を呼び出すために第１メッセージを第１サービスに送ること、
    第１サービスが、第１メッセージに応答して、データ表現言語で表現される結果のセットを生成すること、および、
    第１クライアントに直接結果のセットを返さずに、ネットワーク・アドレッシング可能なストレージ位置を含むスペース内に結果のセットを格納すること
    を実施するようにコンピュータ実行可能であるプログラム命令を含む担体媒体。
32. プログラム命令が、さらに、
    スペースに結果のセットが格納されたことを第１クライアントに通報するために第１クライアントにイベントを送ることを実施するようにコンピュータ実行可能である請求項３１に記載の担体媒体。
33. プログラム命令が、さらに、
    第１クライアントが、イベントに応答してスペースから結果のセットを読み取ることを実施するようにコンピュータ実行可能である請求項３２に記載の担体媒体。
34. プログラム命令が、さらに、
    第１クライアントが、第２サービスに結果のセットの位置を渡す要求を含む第２メッセージを第１サービスに送ること、および、
    第２サービスが、位置から結果のセットを読み取ること
    を実施するようにコンピュータ実行可能である請求項３１に記載の担体媒体。
35. プログラム命令が、さらに、
    第２クライアントが、スペースから結果のセットを読み取ることを実施するようにコンピュータ実行可能である請求項３１に記載の担体媒体。
36. データ表現言語が拡張マークアップ言語（ＸＭＬ）を含む請求項３１に記載の担体媒体。
37. 第１サービスのスキーマが第１サービスの関数を呼び出すのに使用可能な複数のメッセージを指定し、第１メッセージがスキーマによって指定されるようになっていて、第１クライアントが、第１サービスの１つまたは複数の関数を呼び出すために、第１サービスに第１メッセージを送ること、
    第１サービスが、第１メッセージに応答して、データ表現言語で表現される結果のセットを生成すること、
    結果のセットにアクセスするのに使用可能な情報を含む、結果のセットの通知を生成すること
    を実施するようにコンピュータ実行可能であるプログラム命令を含む担体媒体。
38. プログラム命令が、さらに、
    第１クライアントに直接結果のセットを返さずに、ネットワーク・アドレッシング可能なストレージ位置を含むスペースに結果のセットを格納することを実施するようにコンピュータ実行可能である請求項３７に記載の担体媒体。
39. プログラム命令が、さらに、
    結果のセットの通知を含む第２メッセージを第１クライアントに送ることであって、第２メッセージがデータ表現言語で表現されること
    を実施するようにコンピュータ実行可能である請求項３７に記載の担体媒体。
40. プログラム命令が、さらに、
    第１クライアントが、結果のセットに関する通知で指定された位置から結果のセットを読み取ること
    を実施するようにコンピュータ実行可能である請求項３９に記載の担体媒体。
41. プログラム命令が、さらに、
    ネットワーク・アドレッシング可能なストレージ位置を含むスペースに結果のセットの通知を格納することを実施するようにコンピュータ実行可能である請求項３７に記載の担体媒体。
42. プログラム命令が、さらに、
    スペースへの結果のセットに関する通知の格納について第１クライアントに通報するために、第１クライアントにイベントを送ることを実施するようにコンピュータ実行可能である請求項４１に記載の担体媒体。
43. データ表現言語が拡張マークアップ言語（ＸＭＬ）を含む請求項３７に記載の担体媒体。
44. 通知が結果のセットのＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｎｄｉｃａｔｏｒ（ＵＲＩ）を含む請求項３７に記載の担体媒体。
45. サービスに関するスキーマがサービスの関数を呼び出すのに使用可能な複数のメッセージを指定し、第１メッセージがスキーマによって指定されるようになっていて、クライアントが、サービスの１つまたは複数の関数を呼び出すためにサービスに第１メッセージを送ること、
    サービスが、第１メッセージに応答して、データ表現言語で表現される結果のセットを生成すること、
    結果のセットを含む、データ表現言語で表現された第２メッセージをクライアントに送ること
    を実施するようにコンピュータ実行可能であるプログラム命令を含む担体媒体。

Images