JP2004504657A - 分散コンピューティング環境でのセキュア・メッセージングを用いるリモート・メソッド・コール - Google Patents

分散コンピューティング環境でのセキュア・メッセージングを用いるリモート・メソッド・コール Download PDF

Info

Publication number
JP2004504657A
JP2004504657A JP2001583282A JP2001583282A JP2004504657A JP 2004504657 A JP2004504657 A JP 2004504657A JP 2001583282 A JP2001583282 A JP 2001583282A JP 2001583282 A JP2001583282 A JP 2001583282A JP 2004504657 A JP2004504657 A JP 2004504657A
Authority
JP
Japan
Prior art keywords
service
message
client
gate
space
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2001583282A
Other languages
English (en)
Inventor
スロウター，グレゴリイ・エル
ソウルパフ，トーマス・イー
トラバーサット，バーナード・エイ
ドゥイゴウ，マイケル・ジェイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of JP2004504657A publication Critical patent/JP2004504657A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

分散コンピューティング環境内のクライアントとサーバの間のセキュア・インターフェースを説明する。メソッド・ゲートが、サービスの関数をリモート呼出しするインターフェースを提供することができる。メソッド・ゲートは、サービスの関数をリモート呼出しする１つまたは複数のメッセージの定義を含むことができる通知から生成することができる。クライアントは、メソッド・コールの表現を含むメッセージを生成することができる。サービスは、メッセージのセットに対応する関数を呼び出すことができる。サービス側のメソッド・ゲートは、メッセージをアンマーシャリングし、関数を呼び出すことができる。クライアントは、関数の結果を直接受け取ることができる。その代わりに、結果を格納することができ、結果に対する通知を提供することができ、結果にアクセスするためのゲートを生成することができる。メッセージ・ゲートは、クライアントとサービスの間でのメッセージの発送および受取を実行することができる。一実施形態では、サービスの関数を、コンピュータ・プログラミング言語（たとえばＪａｖａ）のメソッドとすることができる。一実施形態では、メソッド・コールの表現を含むメッセージを、実際のメソッド・コールが行われなかった時に生成することができる。一実施形態では、メソッド・コールを、サービスに送ることができるメッセージに変換することができ、サービスは、メッセージがメソッド・コールから生成されたことを知らない場合がある。一実施形態では、サービスが、関数を要求するメッセージを、メソッド・コールに変換することができ、クライアントは、サービスがメソッドを呼び出して関数を実行することを知らない場合がある。証明書を、メッセージに埋め込み、サービスでのメッセージ認証に使用することができる。

Description

【０００１】
（発明の背景）
（１．発明の分野）
本発明は、ウェブ中心およびインターネット中心の分散コンピューティング環境を含む分散コンピューティング環境に関し、より詳細には、ネットワーク・クライアントとサービスを接続するメッセージ・パッシング・モデルに基づくセキュア・リモート・メソッド・コール機構を含む異機種分散コンピューティング環境に関する。
【０００２】
（２．関連技術の説明）
インテリジェント型デバイスの普及が進んでいる。このようなデバイスとしては、スマート・アプライアンス、パーソナル・デジタル・アシスタント（ＰＤＡ）、携帯電話、ラップ・トップ・コンピュータ、デスクトップ・コンピュータ、ワークステーション、メインフレーム、さらにはスーパー・コンピュータなどもある。ネットワークも、次第に、互いに通信できるインテリジェント型デバイスを相互接続する一般的な方法となってきている。ただし、さまざまなインテリジェント型デバイスの計算能力と記憶能力には大きな違いがある。能力が制限されているデバイスは、省スペース・デバイスまたは「シン（ｔｈｉｎ）」デバイス呼ばれることがある。シン・デバイスは、より能力の高いデバイスを相互接続するネットワークに参加することができない場合がある。しかし、さまざまな異なる種類のインテリジェント型デバイスを相互接続することが望ましいと考えられる。
【０００３】
ネットワーキング能力の向上はなおいっそう望まれている。ビジネス用ネットワークは、仕入れ先と顧客との相互の直接的なやり取りを取り込むように拡大を続けている。携帯電話、パーソナル・デジタル・アシスタント、およびインターネット対応コンピュータは、企業においても家庭においても当たり前のものになっている。ホーム・ネットワークは、テレビやステレオ機器などのオーディオ／ビジュアル機器を家庭用コンピュータ、およびセキュリティ・システムや温度制御サーモスタットなどのインテリジェント型システムを制御するその他のデバイスに相互接続するために使用することができる。ケーブルやＡＳＤＬなどの高帯域幅メディアを使用すると、インターネット・アクセス・ビデオ・オンデマンド、電子商取引などのサービスを向上させることができる。ネットワーク・システムは普及途上にある。正式なネットワークがなくても、インテリジェント型デバイスで互いに通信し、またリソースを共有できることが望ましい。
【０００４】
現在、従来のネットワークのセットアップ、拡張および管理は複雑な作業である。たとえば、ハードウェアまたはソフトウェアをネットワークに追加するには、多くの場合、ネットワーク管理者がドライバをロードをし、システムを設定する必要がある。ネットワーク構成に小さな変更を加えるにしても、ネットワーク全体を一定期間停止することが必要になる場合がある。さらに、所定のネットワークで通信するのに必要なインターフェースをサポートしていないインテリジェント型デバイスもある。
【０００５】
必要なのは、各種のインテリジェント型デバイスを接続し、通信およびリソースの共有を可能にしながら、従来のネットワークに存在する相互運用性と複雑な構成という問題を回避できる単純な方法である。ネットワークにデバイスを追加する機能を改善する技術はさまざまなものが存在する。たとえば、ユニバーサル・シリアル・バス、１３９４、およびＰＣＩなどの多くの現代的な入出力バスでは、プラグ＆プレイや動的ディスカバリ・プロトコルをサポートしており、新しいデバイスをバス上に追加する作業が簡単に行える。しかし、これらの解決方法は、特定の周辺機器バスに制限されており、一般的なネットワークには適していない。
【０００６】
最近の技術である、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のＪｉｎｉでは、プリンタおよびディスク・ドライブなどのデバイスをネットワーク上で簡単に接続し共有できるようにすることを追求している。Ｊｉｎｉを組み込んだデバイスは、ネットワークへアナウンスを行い、自デバイスの能力に関する詳細を知らせ、直ちにネットワーク上の他のデバイスからアクセスできる状態に入る。Ｊｉｎｉでは、さまざまなデバイスの機能をネットワーク上で共有する分散コンピューティングが可能になっている。Ｊｉｎｉ技術は、ユーザがネットワーク上でサービスおよびリソースを共有できるようにすることを目指している。Ｊｉｎｉ技術の他の目標は、たとえユーザのネットワーク・ロケーションが変化してもユーザはネットワーク上の任意の場所のリソースに簡単にアクセスすることができるようにすることである。Ｊｉｎｉではさらに、デバイス、ソフトウェア、およびユーザのネットワークを構築し、保守し、変更するタスクを簡素化することも追及している。
【０００７】
Ｊｉｎｉでは、各Ｊｉｎｉ対応デバイスに特定の容量のメモリと処理能力が必要である。通常、Ｊｉｎｉ対応デバイスはＪａｖａ仮想マシン（ＪＶＭ）を備えている。そのため、ＪｉｎｉシステムはＪａｖａ技術を中核とする。Ｊａｖａは、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が開発した高水準オブジェクト指向プログラミング言語である。Ｊａｖａソース・コードをバイトコードと呼ばれる形式にコンパイルし、これをＪａｖａ仮想マシンで実行することができる。
【０００８】
バイトコードは、「実際の」コンピュータ・マシンであるハードウェア・プロセッサではなく、仮想マシンにより処理されるコンピュータ・ソース・コードである。仮想マシンは、一般化された機械語命令（バイトコード）を特定の機械語命令（コンピュータのプロセッサが理解する命令）に変換する。各プラットフォームの仮想マシンに付属する言語を使用し、ソース言語ステートメントを１回だけコンパイルして、その仮想マシンをサポートするプラットフォーム上で実行することができる。Ｊａｖａプログラミング言語は、このような言語の一例であり、Ｊａｖａ仮想マシン（ＪＶＭ）は、Ｊａｖａプログラミング言語で書かれたプログラムをサポートする仮想マシン・プラットフォームの一例である。Ｊａｖａ仮想マシンは、ほとんどのコンピューティング・プラットフォームに用意されているため、ＪａｖａしたがってＪｉｎｉは一定のプラットフォーム独立性を実現している。Ｊｉｎｉアーキテクチャでは、Ｊａｖａプログラミング言語がＪｉｎｉシステムのコンポーネントの実装言語であるという想定を活用している。Ｊａｖａコードを動的にダウンロードして実行できることが、Ｊｉｎｉアーキテクチャの多くの機能の中心となっている。
【０００９】
Ｊｉｎｉアーキテクチャの目的は、デバイスとソフトウェア・コンポーネントからなる複数のグループを単一の動的分散システムとして連合させることである。Ｊｉｎｉアーキテクチャの概念で重要なのは、サービスという概念である。サービスは、人、プログラム、または他のサービスが使用できるエンティティである。サービスの例としては、文書を印刷するサービスと、一方のワードプロセッサ形式から他方の形式に変換するサービスの２つがある。Ｊｉｎｉを使用すると、Ｊｉｎｉシステムのメンバがサービスへのアクセスを共有することができる。Ｊｉｎｉシステム内のサービスは、Ｊａｖａプログラミング言語で書かれた一組のインターフェースである、サービス・プロトコルを使用することにより互いに通信する。サービスの探索およびソリューションは、Ｊｉｎｉシステム内でルックアップ・サービスを使用して行う。ルックアップ・サービスにより、サービスによって提供される機能を示すインターフェースを、そのサービスを実装するオブジェクト群にマッピングする。
【００１０】
記述エントリもサービスに関連付けることができる。デバイスとアプリケーションは、発見（ｄｉｓｃｏｖｅｒｙ）と呼ばれるプロセスを使用してＪｉｎｉネットワークに登録する。デバイスまたはアプリケーションは、いったん登録されると、ルックアップ・サービス内に入る。ルックアップ・サービスでは、ネットワーク上のこれらのサービスへのポインタを格納するだけでなく、これらのサービスにアクセスするためのコードも格納する。たとえば、プリンタはルックアップ・サービスに登録されると、そのプリンタ・ドライバおよび／またはドライバとのインターフェースをルックアップ・サービスにロードする。クライアントがプリンタの使用を要求すると、そのドライバおよびドライバ・インターフェースはルックアップ・サービスからそのクライアントにダウンロードされる。このようにコードを移動できることは、クライアント側で、ドライバやその他のソフトウェアをプリインストールしたりロードをすることなく、ネットワークからのサービスを利用することができることを意味する。
【００１１】
Ｊｉｎｉシステム内のサービス間の通信は、Ｊａｖａ　Ｒｅｍｏｔｅ　Ｍｅｔｈｏｄ　Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）を使用してを行う。ＲＭＩは、従来のリモート・プロシージャ・コールのメカニズムに対するＪａｖａプログラミング言語対応の拡張機能である。ＲＭＩでは、Ｊｉｎｉネットワーク内でオブジェクトからオブジェクトへデータを渡すことができるだけでなく、コードを含む完全なオブジェクトも渡すことができる。Ｊｉｎｉシステムは、コードがＪａｖａオブジェクトとしてカプセル化された形式でネットワーク内を移動できることに依存している。
【００１２】
Ｊｉｎｉシステム内のサービスへのアクセスはリースに基づく。リースとは、一定期間保証されたアクセスを許可することである。各リースはサービスの利用者とサービスの提供者との間で、サービス・プロトコルの一環として交渉される。ある期間サービスが要求されると、ある期間、たぶん要求期間と考えられるが、アクセスを許可できる。サービスがＪｉｎｉシステムの一部としてとどまるためにはリースを更新する必要がある。
【００１３】
図１は、Ｊｉｎｉの基本的な技術の積み重ねを示している。Ｊｉｎｉ技術では、分散プログラミング・モデル１２（ＪａｖａＳｐａｃｅｓ、リース、およびオブジェクト・テンプレートによってサポートされている）を定義する。Ｊｉｎｉのオブジェクト通信は、ＴＣＰ／ＩＰ対応ネットワーキング・レイヤ１６上のＲＭＩレイヤ１４に基づいている。
【００１４】
Ｊｉｎｉは、分散コンピューティングを簡素化するための有望な技術である。ただし、デバイスの種類によっては、Ｊｉｎｉが適さない場合もある。コンピューティング技術の流れは、分散Ｗｅｂ中心サービスおよびコンテンツ・モデルに向かっており、クライアント・サービスとコンテンツの内容は急激に変化している。将来のクライアントは、ユーザがどこへでも持ち運べるコンパニオン・タイプのデバイスになると思われる。このようなデバイスとしては、たとえば、携帯電話とＰＤＡとの組み合わせが考えられる。このようなデバイスがより強力なデバイスとだけでなく、より軽量なシン・デバイスまたは非力なデバイスとも通信し、リソースを共有できることが望ましい。
【００１５】
さらに、インターネットが出現し、その結果ネットに接続したデバイスが爆発的に増え、こうした現象を活用するように設計された分散プログラミング・モデルが必要になった。クライアントが信頼できる、セキュリティで保護され安全な方法でサービスに接続するための実現技術が要求される。シック（ｔｈｉｃｋ）・クライアントからシン・クライアントに至るさまざまなクライアントとサービスをインターネット、企業内イントラネット、またさらには単一コンピュータ内で接続する必要がある。クライアントとサービスの両方から距離、待ち時間、実装を抽象化（ａｂｓｔｒａｃｔ）することが望ましい。
【００１６】
分散コンピューティング技術で重要な課題は、パワーのあるシック・クライアントから組み込み型モバイル・デバイスなどの非常に軽量なシン・クライアントに至るまでスケーラブルにすることである。Ｊｉｎｉなどの現在の分散コンピューティング技術は、あらゆる種類のクライアントのニーズに応じられるほどスケーラブルでないといえる。省スペース・デバイスや組み込み型デバイスなどの一部のデバイスでは、メモリリソースが十分でなかったり、十分なネットワーキングの帯域幅を欠いていたりして、現在の分散コンピューティング技術に十分に参加できない。組み込み型モバイル・デバイスなどのクライアント製品群のローエンドは、多くの場合、コード実行環境が限られていたり固定されている。これらのデバイスもまた、ストレージ能力が最低限であったりあるいは全く永続性がない場合がある。大半の小型組み込み型モバイル・デバイスは、Ｊａｖａ仮想マシンをサポートしていない。ほとんどのコード実行可能小型クライアントはネイティブ・コードのみを実行する。さらに、ほとんどの小型デバイスは、その単独の永続的ストレージ・メディアとしてせいぜいフラッシュ・メモリーやバッテリ・バックアップＲＡＭを備えているぐらいである。ストレージの容量は非常に小さく、時には本質的に読み取り専用であることが多い。さらに、このタイプのストレージ・メディアのアクセス・タイムは、より強力なクライアントのハード・ディスクのアクセス・タイムに比べて１桁以上遅いことが多い。
【００１７】
Ｊｉｎｉなどの既存の接続技術は、サイズが大きいことから、望んでいるほどはスケーラブルでありえない。たとえば、Ｊｉｎｉでは、すべての参加者がＪａｖａをサポートする必要があるが、小さなクライアントの多くはＪａｖａ仮想マシン用にリソースを確保することはできない。さらに、ＪｉｎｉではＲＭＩを使用するため、クライアント側でコードとコンテンツをダウンロードできる必要がある。Ｊｉｎｉは、新しいクラスをダウンロードすることにより既存のクライアント・プラットフォームを補強しているので、組み込む型デバイスなどの小型デバイスにセキュリティおよびサイズの面で問題が生じることがある。Ｊｉｎｉは、コードとデータを渡すことによりクライアントとリソースが通信するという形で動作する。クライアントがＪｉｎｉサービスをアクティブにすると、このサービスは結果をクライアントに返すが、これには大量のコードまたはコンテンツが含まれる場合がある。Ｊｉｎｉでは、クライアントはメソッドを呼び出し、大きなオブジェクトが返され、それをダウンロードすることがある。クライアントは、返されたオブジェクトを受け入れるだけのリソースを持たないことがある。さらに、ＲＭＩとＪａｖａ自体が大量のメモリを必要とする。多くの省スペース・デバイスは、現在の分散コンピューティング技術に事実上または少しでも加わるだけのリソースを持たないことがある。
【００１８】
既存の分散コンピューティング技術の問題としては他に、多くの場合、複数のレベルの接続能力およびプロトコルを必要とするという点があげられる。たとえば、Ｊｉｎｉでは、コンピュータとデバイスを接続するための妥当な速度のネットワークが存在していることを想定している。またＪｉｎｉでは、ＴＣＰ／ＩＰネットワーク・トランスポート・プロトコルをサポートするデバイスも必要とする。しかし、多くの小型デバイスは接続能力が限られている。小型デバイスは、ネットワーク接続の待ち時間が長かったり、または低速であったりし、ＴＣＰ／ＩＰをサポートしない場合もある。
【００１９】
上述のように、Ｊｉｎｉでは、ＪａｖａをサポートするＪａｖａ仮想マシンを備えるデバイスを必要とし、そのため、多くの小型デバイスには備えられないような処理能力およびストレージ機能を必要とする。このこともまた、Ｊａｖａ対応でないデバイスはＪｉｎｉシステムに直接参加できないという点でＪｉｎｉの柔軟性を制約している。ＪｉｎｉはＪａｖａを必要とするため、均質的な環境とみなすことができる。ただし、非常に小型の組み込み型デバイスからＰＤＡ、携帯電話、さらにラップトップおよび最強のコンピュータに至るまでの異機種分散コンピューティングに対応する分散コンピューティング機能を備えることが望ましい。コモン・オブジェクト・リクエスト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）など他の異機種ソリューションも存在する。ＣＯＲＢＡは、プログラム・オブジェクトが、作成に使用されたプログラミング言語に関係なく、またはそのオブジェクトが実行されるオペレーティング・システムに関係なく互いに通信できるようにするアーキテクチャである。しかし、ＣＯＲＢＡはＪｉｎｉで取り扱われている接続問題をすべて取り扱えるわけではない。さらに、ＣＯＲＢＡにはＪｉｎｉと似たスケーラビリティの問題もある。
【００２０】
ＪｉｎｉやＣＯＲＢＡなどの技術では、コード中心のプログラミング・モデルを使用して、リモート・コンピュータ間のインターフェースを定義している。コード中心プログラミング・モデルでは、リモート・クライアントまたはコンポーネント間の通信にプログラム・インターフェースまたはＡＰＩを定義する。ＡＰＩは、特定のプログラミング言語で定義することができる。ＡＰＩは、適切な相互運用性を確実なものとするために、すべてのソフトウェア・コンポーネントで矛盾がないようになっていなければならない。コンポーネントに対するアクセスはすべてこれらの標準ＡＰＩを通じて行うため、これらのＡＰＩを実装するコードがクライアント・プラットフォーム内に存在している必要がある。コードは、プラットフォームに静的にリンクすることも、また必要に応じて動的にダウンロードすることもできる。多くの組み込み型またはモバイル・デバイスは、単に、品質管理問題がかかわっているだけでなく、単一の言語およびプログラム実行環境に依存しているということから、コードをネットワークから動的に受け入れることができないのである。ネットワーキング・プロトコルなどのデータ中心モデルは、コードの移動に依存することを避けているが、このようなプロトコルは簡単に分散コンピューティングに対応できるほど機能豊富でなく、型安全性などコードやその他のプログラミング機能によるプログラミングを簡単に行うことができない。
【００２１】
従来の分散コンピューティング・システムは、第１のデバイスで実行されるプログラムが第２のデバイスのプログラムをリモート・コールできるということに依存しており、結果は第１のデバイスに返される。リモート・プロシージャ・コール（ＲＰＣ）は、プログラムまたはプロシージャのリモート・コールを行うための基本的メカニズムである。ＣＯＲＢＡとＪｉｎｉは両方とも、プログラム・メソッドをリモートから呼び出す機能に基づいている。ただし、ＪｉｎｉやＣＯＲＢＡなどのコードまたはオブジェクトを渡すことで通信を行うのは幾分複雑になることがある。たとえば、上述のように、ＪｉｎｉではＪａｖａ　Ｒｅｍｏｔｅ　Ｍｅｔｈｏｄ　Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）を使用してサービス間の通信を行う。クライアントがＪａｖａオブジェクトをリモート・ロケーションとの間で移動するには、シリアライゼーション／デシリアライゼーションの何らかの手段が必要になる。Ｊａｖａ開発キット（ＪＤＫ）におけるこのような現在の機能は、Ｊａｖａオブジェクトの内容を判別するためにリフレクションＡＰＩに依存しており、最終的にはそのコードが仮想マシンに問い合わせを行う必要がある。このコードはかなり大きく、非効率である。
【００２２】
シリアライゼーション／デシリアライゼーションを行うための現在の方法には、サイズ、速度、およびオブジェクト・トラバーサル・モデルに関する基本的な問題がある。ＪＶＭの外部のコードは、Ｊａｖａオブジェクトの構造またはグラフを認識しないため、オブジェクト・グラフをトラバースし、引き離して、最終的にＪＶＭを呼び出す必要がある。Ｊａｖａオブジェクトの格納および移動を行う従来のシリアライゼーションおよびリフレクション・メカニズムは、すべての種類のデバイス、特により軽量のシン・デバイスについては実用的でない。Ｊａｖａリフレクションおよびシリアライゼーションの問題点として、オブジェクトのグラフ（オブジェクトの推移的閉包（ｔｒａｎｓｉｔｉｖｅ ｃｌｏｓｕｒｅ））リフレクションがＪＶＭの外部で実行することが困難であるという点があげられる。シリアライゼーションは、大量のコードを必要とし、大きすぎる。さらに、シリアライゼーションはＪａｖａ固有のオブジェクト交換形式であり、Ｊａｖａ非対応のデバイスでは使用できない。
【００２３】
Ｊｉｎｉ分散コンピューティング・モデルでは、Ｊａｖａデバイス間でＪａｖａオブジェクトを移動する必要がある。そのため、Ｊａｖａ対応でないプラットフォーム側でオブジェクトの発送および受取に使用することができないためシリアライゼーション・メカニズム自体はプラットフォーム独立ではない。シリアライゼーションは、均質的なオブジェクト形式であり、Ｊａｖａプラットフォームでのみ動作する。シリアライゼーションでは、リフレクションＡＰＩを使用するため、セキュリティ関連の制限を受ける場合があり、しばしば、ネイティブのＪＶＭ依存メソッドを使用して対処する必要がある。リフレクションＡＰＩは、オブジェクトのグラフを提供できるが、ＪＶＭとリフレクション・メソッドを呼び出すコードとの間で何回も呼び出しが行われるため非効率である。
【００２４】
Ｊａｖａリフレクションを使用してオブジェクトをシリアライズするには、オブジェクトの推移的閉包を動的に解析するときに、アプリケーション側がＪＶＭとピンポンのようにやり取りし、一度にフィールド１つずつオブジェクトを取り出す必要がある。Ｊａｖａデシリアライゼーションを使用してオブジェクトをデシリアライズするには、オブジェクトの推移的閉包を動的に解析するときに、アプリケーション側がＪＶＭと緊密に連携し、一度にフィールド１つずつオブジェクトを再構成する必要がある。そのため、Ｊａｖａシリアライゼーション／デシリアライゼーションは時間がかかり、扱いにくく、しかも、アプリケーションとＪＶＭのコードを大量に書く必要があるだけでなく、永続的な記憶領域も必要である。
【００２５】
Ｊａｖａをサポートするシン・クライアントの場合も、Ｊｉｎｉ　ＲＭＩは、最小限のメモリ専有面積と最低限の帯域幅を備えるシン・クライアントの場合には実用的でないと思われる。Ｊｉｎｉ　ＲＭＩと関連するシリアライゼーションは、実行時間が長く、コード・サイズが大きく、ＪＶＭリフレクションＡＰＩを必要とし、Ｊａｖａ固有オブジェクトの表現である。Ｊａｖａデシリアライゼーションも実行に時間がかかり、コード・サイズが大きく、シリアライズ・オブジェクト・パーサを必要とする。Ｊａｖａベースのシン・クライアントであっても、Ｊｉｎｉ内で要求されたときにクライアントへネットワーク経由で（必ず）返される巨大なＪａｖａオブジェクト（必要なクラスに沿って）を受け入れられない場合がある。さらにスケーラブルな分散コンピューティング・メカニズムが必要である。よりスケーラブルな分散コンピューティング・メカニズムでセキュリティ問題に対処すること、またＪａｖａオブジェクトなどのオブジェクトの受け渡しを可能にし、さらに一方のネットワーク・モードから他方のネットワーク・モードにプロセスを移行できるように、拡張可能であることが望ましい。
【００２６】
オブジェクト・ベースの分散コンピューティング・システムでは永続的記憶領域が必要である。ただし、上述のように、オブジェクト記憶領域での試みは多くの場合言語とオペレーティング・システムに特有のものである。さらに、これらのオブジェクト・ストレージ・システムは、複雑すぎて、多くの小さな組み込み型システムでは使用できない。たとえば、Ｊｉｎｉ技術では、ＪａｖａＳｐａｃｅｓを永続的オブジェクト・コンテナとして使用する。しかし、ＪａｖａＳｐａｃｅは、Ｊａｖａオブジェクトを格納するだけであり、小型デバイスに実装できない。ＪａｖａＳｐａｃｅ内の各オブジェクトは。シリアライズ化され、Ｊａｖａシリアライゼーションと関連する上述のペナルティを払う。小型デバイスから大型デバイスに至るまでの分散コンピューティング用に異機種オブジェクト・リポジトリを備えることが望ましいと考えられる。
【００２７】
Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のＪａｖａＳｐａｃｅｓは、エール大学コンピュータ・サイエンス学部のＤａｖｉｄ　Ｇｅｌｅｒｎｔｅｒ教授の並列処理の成果を利用している。Ｇｅｌｅｒｎｔｅｒ教授の「Ｌｉｎｄａ」という名前の機能セットでは、ＴｕｐｌｅＳｐａｃｅと呼ばれる共有メモリ空間を作成し、コンピュータのプロセスの結果またはそれらのプロセス自体を格納し、複数のＣＰＵでアクセスできるようにする。Ｌｉｎｄａは、したがって複数のプロセッサ用にグローバルな共有メモリを備える。
【００２８】
Ｌｉｎｄａを拡張するもう１つの技術がＩＢＭ　ＣｏｒｐｏｒａｔｉｏｎのＴＳｐａｃｅである。ＴＳｐａｃｅは、基本的なＬｉｎｄａ　ＴｕｐｌｅＳｐａｃｅフレームワークを拡張し、実データ管理を行い、新しいデータ型および新しいセマンティック機能をダウンロードできるようにしている。ＴＳｐａｃｅは、一組のネットワーク通信バッファとこれらのバッファにアクセスするための一組のＡＰＩを備えている。したがって、上述の多くのソリューションのように、ＴＳｐａｃｅはコード中心プログラミング・モデルを使用しており、そのようなモデルの欠点も共有している。さらに、ＴＳｐａｃｅは、Ｊａｖａプログラミング言語で実装されているため、Ｊａｖａ仮想マシンやＪａｖａバイトコードを実行する、Ｊａｖａ実行可能マイクロプロセッサなどの他の手段を必要とする。したがって、ＴＳｐａｃｅは、十分なリソースをＪａｖａバイトコードの実行専用に割り当てることができない省スペース・デバイスには不適切と思われる。
【００２９】
オブジェクト指向分散システムでは、オブジェクト・リポジトリを特定し、それらのリポジトリ内で特定のオブジェクトを見つけることができることが望ましい。供述のように、Ｊｉｎｉルックアップ・サーバはメモリ専有面積の小さな小型デバイスには実用的でないと思われる。オブジェクト・ストアを特定するより効率的なメカニズムがあることが望ましい。
【００３０】
分散ネットワーク・コンピューティング・モデルでは、クライアントがサービスを特定する機能を備えることが望ましい。現在のネットワーク・プロトコルは、ネットワーク・サービスにアクセスするときにセキュリティを一切持たない単一の標準サービス・アクセス・インターフェースのみを提供するか、または管理者もしくは特権のある機能も含めて、サービスの全機能に対する「オール・オア・ナッシング」アクセス機能を提供する。また、サービスを特定する現在のネットワーク・プロトコルでは、サービスを見つける柔軟なメカニズムを提供していない。現在のプロトコルは、選択的サーチ機能をまったく備えていないか（たとえば、ＵＰｎＰ）、またはプリミティブ・キーワードおよび属性文法メカニズムのみを備える（たとえば、ＳＬＰ）。そのため、現在のサービス発見メカニズム（ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ ｍｅｃｈａｎｉｓｍ）はセキュリティおよびサーチ基準メカニズム（ｓｅａｒｃｈ ｃｒｉｔｅｒｉａ ｍｅｃｈａｎｉｓｍ）に関してあまりにも柔軟性が不足していると考えられる。
【００３１】
さらに、現在のサービス発見モデルは、サービスを特定するために対称モデルを使用している。ただし、近さに基づく機能を使用できるデバイスなどある種のサービス・デバイスが発見モデルをサポートするのはリソースの無駄と考えられる。これは、このようなデバイスが近いところにあるためすでに特定されているためである（たとえば、他方のデバイスを物理的にポイントしている一方のデバイス）。そのため、代替えとなる軽量発見メカニズムもこのようなデバイスに対して望ましいと考えられる。
【００３２】
分散オブジェクト・アクセスにも、偏りのない効率のよい共有メカニズムを必要とする。上述のように、Ｊｉｎｉは今のところ、リース・メカニズムを使用してオブジェクトを共有している。ただし、Ｊｉｎｉのリースは時間に基づいているため、さまざまな問題が発生しうる。たとえば、現在のオブジェクト・ホルダは、オブジェクトをどれだけの期間リースするかという考え方がなく、保持期間が長くなりすぎる場合がある。さらに、時間に基づくリースを使用するには、複数のマシンの間で時間が同期している必要がある。さらに、時間に基づくリースには、オペレーティング・システムのサポートも必要と考えられる。さらに、Ｊｉｎｉのリースは、ＲＭＩ経由で確立され、解放される。そのため、Ｊｉｎｉのリース・メカニズムには、ＲＭＩを使用する上述の問題が発生する。さらに、Ｊｉｎｉのリース・メカニズムは、リースの確立、更新、および取り消しのためのセキュリティ・メカニズムを備えていない。他のリース・メカニズムも望ましいと考えられる。
【００３３】
一般的に、メモリ専有面積の小さなモバイル・クライアント・デバイスは分散環境でさまざまなサービス、つまりレガシサービスと新サービスの両方を実行できることが望ましい。小型クライアントとしては、携帯電話およびＰＤＡがあり、通常は低帯域幅のさまざまなネットワーキング・インターフェースを備える。これらのデバイスは多くの場合、グラフィック機能が限られた非常に小さなディスプレイを備えているが、大画面のディスプレイを備え、グラフィック機能も高度なものを使用するラップトップやノートブック・コンピュータもある。サービスは、さまざまなアプリケーションだけでなくプリンタなどのデバイス用の制御プログラムもある。モバイル・クライアントは、使用できる場所であればどこでもこれらのサービスを使用できることが望ましい。
【００３４】
モバイル・クライアントは、多くの場合、一時的な動的ネットワーク・アドレスが割り当てられ、このクライアントが送るネットワーキング・メッセージはそのネットワーキング・インターフェースを超えて配信することはできない（そうでないと、異なるネットワーク上の２つの異なるクライアントが同じ動的アドレスを持つときに競合が発生することがある）。モバイル・クライアントは、多くの場合、全機能搭載のブラウザやその他の高度なソフトアウェア用の機能を持たない。ディスプレイが制限となって、クライアントが一部のアプリケーションを実行できない場合もある。従来のアプリケーション・モデルは、所定のユーザ・インターフェースまたはデータ特性に基づいている。アプリケーションに変更を加えると再コンパイルが必要になる。
【００３５】
このようなクライアントは分散アプリケーションまたはサービスを見つけて呼び出すメカニズムを備えることが望ましい場合がある。クライアントは、クライアントのメモリ専有面積に収まり切らない可能性のある一層大きなレガシ・アプリケーションを実行する必要がある場合もある。上述のように、Ｊｉｎｉなどの現在の技術は、省スペース・デバイスには実用的でない場合がある。また、モバイル・シン・クライアントが普及することでさらにニーズも高まる可能性がある。たとえば、ユーザとそのユーザのモバイル・クライアントの物理的な場所に基づいてサービスを特定することが望ましい場合がある。たとえば、現地のレストラン、天候、道路交通現況図、および映画情報など現地周辺のサービスに関する情報が非常に役立つことがある。それと同様に、特定の場所にあるプリンタなど計算リソースに関する情報が役立つ。現行技術では、クライアントの物理的場所に基づいてサービスを特定する自動的なメカニズムを備えていない。シン・モバイル・クライアントによって生じるニーズとしては、他に、人的要因を取り扱うものがある。シン・モバイル・クライアントは、通常、エルゴノミック・キーボードおよびモニタを備えない。このような人的要因サービスを提供することおよび／または分散コンピューティング環境でこのようなサービスを特定する機能があると望ましい。分散コンピューティング・モデルは、クライアントは一時的ドキュメントおよびサービスを見つける手段を備える必要がある。ドキュメントが拡張マークアップ言語（ＸＭＬ）によって提供されるものなどプラットフォーム独立および言語独立の型で表される汎用ドキュメント（サービスおよび／またはサービス通知を含む）を見つけるメカニズムを備えることが望ましい場合がある。Ｊｉｎｉ、Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ（ＵＰｎＰ）、およびＳｅｒｖｉｃｅ　Ｌｏｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ（ＳＬＰ）のルックアップ・メカニズムを含む現在のアプローチでは、このような汎用ドキュメントルックアップ・メカニズムをサポートしていない。たとえば、Ｊｉｎｉルックアップ・メカニズムは、Ｊａｖａ言語型付けに限定されており、したがって、言語独立ではない。ＵＰｎＰおよびＳＬＰは、サービスのみについて発見プロトコルをサポートしており、汎用ドキュメントについては発見プロトコルをサポートしていない。
【００３６】
（発明の要約）
分散コンピューティング環境でクライアントとサービスの間のメソッド・インターフェースを提供するメソッド・ゲートの実施態様を説明する。メソッド・ゲートは、両方向とし、クライアントからサービスへおよびサービスからクライアントへのリモート・メソッド・コールを可能にすることができる。メソッド・ゲートは、データ表現言語のスキーマ情報から（たとえばスペース内のサービス通知から）生成することができる。データ表現言語のスキーマ情報に、１つまたは複数のメソッド・インターフェースに関する定義を含めることができる。この情報から、１つまたは複数のメソッドへインターフェースするゲートの一部として、コードを生成することができる。生成されたコード内の、各メソッド・コール（たとえばクライアント・アプリケーションからの）は、マーシャリングされたメソッド・パラメータを含むメッセージを、サービスに発送させることができる。含まれるメッセージの構文およびパラメータは、データ表現言語のスキーマで指定することができる。したがって、メソッド・ゲートは、サービス・メソッドをリモート呼出しするためのデータ表現言語のメッセージ・インターフェースを提供する。メソッド・ゲートは、クライアント側で生成するか、スペース・サーバなどのサーバ上でプロキシ化することができ、後者の場合に、サービス・メソッドが、通知されたか、特別なゲートウェイ・サービスである。
【００３７】
サービスは、データ表現言語で実施され、サービスのデータ表現言語スキーマで定義されるメソッド・メッセージのセットに対応するオブジェクト・メソッドのセットを実施するかこれにリンクされた対応するメソッド・ゲートを有することができる。サービスのメソッド・ゲートによって実施されるかこれにリンクされるオブジェクト・メソッドと、サービスのデータ表現言語スキーマによって定義されるメソッド・メッセージの間に、１対１対応がある可能性がある。サービスの対応するメソッドが、サービスのメソッドの１つを呼び出すクライアントからのメッセージを受け取った後に、サービスのメソッド・ゲートが、メッセージ呼出しのパラメータをアンマーシャリングまたはアンパックすることができ、その後、受け取ったメッセージによって示されるメソッドを呼び出し、アンマーシャリングされたパラメータを渡すことができる。
【００３８】
メソッド・ゲートは、サービスに結果を返させるメソッドをクライアントがリモート呼出しする、同期式の要求−応答データ表現言語のメッセージ・インターフェースを提供することができる。基礎となるメッセージ・パッシングの仕組みを、クライアントから完全に隠蔽することができる。リモート・メソッド・コールのこの形は、次のようなメソッド結果を扱うことができる。一実施態様では、結果オブジェクト（および関連するクラス）をクライアントにダウンロードするのではなく、１つまたは複数の結果参照だけを、データ表現言語のメッセージで返すことができる。オブジェクト参照は、実際のオブジェクト結果を表す、生成された結果ゲートとすることができる。他の実施態様では、クライアントが、実際の結果オブジェクトを受け取ることを選択することができる。さらに、クライアントは、結果オブジェクト参照を受け取った後に、この参照を使用して、実際の結果オブジェクトを受取または操作することができる。一実施態様では、結果参照に、実際の結果への１つまたは複数のＵＲＩが含まれる。
【００３９】
実際の結果オブジェクトを、サービス結果スペースに格納することができる。この一時的な結果スペースは、照会結果キャッシュとして働くことができる。各メソッド・コールから返された結果を、結果スペース内で通知することができる。結果自体を、クライアントがリモート・インスタンス化することができ、したがってそれ自体のメソッド・ゲートを生成することができるメソッドとするか、そのメソッドを結果自体に含めることができる。したがって、分散コンピューティング環境は、再帰的リモート・メソッド・コールをサポートすることができる。
【００４０】
クライアントが、メソッド・ゲートを使用してサービス・メソッドをリモート呼出しする時に、実際の結果の代わりに、メソッド結果への参照を、サービス・メソッド・ゲートから返すことができる。この参照から、結果ゲートを生成して、実際の結果にアクセスすることができる。したがって、クライアント・ゲートまたはクライアント・メソッド・ゲートは、結果のＵＲＩと、おそらくは結果のデータ表現言語スキーマおよび／またはリモート・メソッド結果にアクセスするゲートを構築する認証証明書を受け取ることができる。
【００４１】
サービス・メソッド・ゲートは、メソッドの結果として、クライアント・ゲートに結果ゲートを返すことができる。クライアントは、結果ゲートを使用して実際の結果にアクセスすることができる。一実施態様では、結果ゲートを受け取るクライアントが、結果ゲートと結果自体を区別することができず、この場合に、結果ゲートを、実際の結果オブジェクトのオブジェクト・プロキシとすることができる。結果ゲートは、結果オブジェクトへのリモート・メソッド・コールをサポートするメソッド・ゲートとすることもできる。この形で、親子のメソッド・ゲート／結果ゲートの連鎖を作成することができる。
【００４２】
クライアント・メッセージ・ゲートおよびサービス・メッセージ・ゲートは、サービス通知で指定されるプロトコルを使用して、クライアントからサービスへのメソッド・コールメッセージおよび結果メッセージの実際の発送および受取を実行することができる。
【００４３】
一実施態様で、リモート・メソッドをＪａｖａメソッドとすることができる。この実施態様では、メソッド結果に、Ｊａｖａの型付けシステムに従って正しい型を与えることができる。Ｊａｖａメソッドが、上で説明したようにリモート呼出しされる時には、結果ゲートを、結果の型に一致するＪａｖａの型にキャストすることができる。この実施態様では、メソッド・ゲートを、分散コンピューティング環境内で使用して、リモートＪａｖａオブジェクトがローカルＪａｖａオブジェクトであるかのように振る舞うことを可能にする。メソッド・コールおよび結果は、実際のオブジェクトがローカルであれリモートであれ、クライアントＪａｖａソフトウェア・プログラムに同一に見えるようにすることができる。
【００４４】
一実施態様では、メソッド・コールの表現を含むメッセージを、実際のメソッド・コールが行われなかった時に、クライアント側で生成することができる。この実施態様では、クライアントが実際にコンピュータ・プログラミング言語のメソッド・コールを生成せずに、クライアント側のプロセスが、サービス側のコンピュータ・プログラミング言語のメソッドを呼び出すことができる。
【００４５】
一実施態様では、クライアントが、メソッド・コールを１つまたは複数のメッセージに変換することができ、このメッセージを、サービスに送ることができ、このメッセージには、メソッド・コールにアンマーシャリングできる情報が含まれるのではなく、クライアントに代わって関数を実行するためにサービスが使用することのできる情報が含まれる。この実施態様では、サービスは、メッセージが元々メソッド・コールから生成されたことを知らない場合がある。これらのメッセージは、それでもメソッド・コールの「表現」とみなすことができるが、アンマーシャリングしてメソッド・コールを再生成することができるマーシャリングされたメソッド・コールとしてサービスが認識する形ではない可能性がある。
【００４６】
一実施態様では、サービスが、サービスが１つまたは複数の関数を実行することを要求する１つまたは複数のメッセージを、メソッド・コールに変換することができる。この実施態様では、メッセージを生成するために、クライアントに対するメソッド・コールが行われていない場合がある。したがって、クライアントは、要求された関数を実行するためにサービスがメソッドを呼び出すことを知らなくてもよい。
【００４７】
一実施態様では、証明書を、サービスに対するクライアントおよびメッセージの検証に使用することができる。証明書は、クライアントによってサーバに送られるメッセージのそれぞれに組み込むことができる。サービスは、クライアントからのメッセージを検査して、メッセージにクライアントの正しい証明書が含まれることを検証することができる。一実施態様では、サービス・メソッド・ゲートが、検証を実行することができる。もう１つの実施態様では、サービス・メッセージ・ゲートが、検証を実行することができ、その後、検証されたメッセージをサービス・メソッド・ゲートに渡すことができる。
【００４８】
本発明はさまざまな修正を加えることができ、また他の形態も可能であるが、特定の実施形態を図面の例を用いて示しており、これらについて以下で詳述する。ただし、図面および詳細な説明は本発明を開示されている特定の形態に制限する意図はなく、むしろその反対に、発明は本発明の精神と範囲にあるすべての修正、等価物、および代替え物を対象とすることは理解されるであろう。
【００４９】
（発明の実施形態の詳細な説明）
分散コンピューティングの実施形態の概要
図２には、分散コンピューティング環境のプログラミング・モデルが示されている。このモデルには、分散コンピューティングを使いやすくするＡＰＩレイヤ１０２が含まれている。ＡＰＩレイヤ１０２は、クライアントとサービスとの接続を容易にするインターフェースを備えている。ＡＰＩレイヤ１０２は、クライアントおよびサービスの発見（ｄｉｓｃｏｖｅｒｙ）および接続に関係する。ＡＰＩレイヤ１０２は、メッセージ発送およびメッセージ受取機能を備える。このメッセージングＡＰＩは、拡張マークアップ言語（ＸＭＬ）など、表現データまたはメタデータ形式による単純メッセージ用のインターフェースを提供する。実施形態はここではＸＭＬを採用しているものについて説明しているが、他の実施形態では他のメタデータ型言語または形式を使用することもできることに注意されたい。いくつかの実施形態では、ＡＰＩレイヤは、さらに、Ｊａｖａオブジェクトなど、オブジェクト間の通信やオブジェクトの受け渡しのためのメッセージのインターフェースを備えることもできる。オブジェクト・リポジトリまたは「スペース」を発見し、特定のオブジェクトを見つけ、オブジェクトの要求および解放を行い、オブジェクトをオブジェクト・リポジトリに書き込んだり、オブジェクト・リポジトリからオブジェクト取り出したりするＡＰＩが用意される場合もある。ＡＰＩレイヤ１０２を通じてアクセス可能なオブジェクトは、ＸＭＬなどの表現データ形式で表現することができる。そのため、オブジェクト自体とは反対に、オブジェクトのＸＭＬ表現は操作が可能である。
【００５０】
ＡＰＩレイヤ１０２は、メッセージング・レイヤ１０４の上にある。メッセージング・レイヤ１０４は、ＸＭＬなどの表現データ形式に基づいている。一実施形態では、ＸＭＬメッセージは、ＡＰＩレイヤ１０２の呼び出しに従って、メッセージング・レイヤ１０４によって生成される。メッセージング・レイヤ１０４は、クライアントとサービスとの間で送ることができる定義済みの静的メッセージを備えている。メッセージング・レイヤ１０４は、さらに、動的に生成されるメッセージにも対応している。一実施形態では、ＪａｖａオブジェクトなどのオブジェクトをＸＭＬ表現に動的に変換することができる。メッセージング・レイヤ１０４により、ＸＭＬオブジェクト表現はメッセージとして送ることができる。逆に、メッセージング・レイヤ１０４は、オブジェクトのＸＭＬ表現を受け取ることができる。その後、そのメッセージからオブジェクトは再構成できる。一実施形態では、メッセージング・レイヤ１０４によって送られるメッセージは、アドレス、認証証明書、セキュリティ・トークン、およびメッセージ本体など、複数の基本要素を含むことができる。メッセージ・システムの発送および受取メカニズムは、完全に状態を保持しないようにできる。状態という概念を、発送側と受取側との間のメッセージ・ストリームに埋め込むことができる。そのため、メッセージ発送は非同期に行われる。好ましい実施形態では、接続モデルは課されていない。したがって、ＴＣＰなどのトランスポートは不要である。また、エラー条件は不達またはセキュリティ例外に限られる。
【００５１】
メッセージング・レイヤ１０４は、メッセージ対応ネットワーキング・レイヤ１０６の上にある。好ましい実施形態では、メッセージング・レイヤ１０４は、特定のネットワーキング・プロトコルを使用する必要がない。ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰは、メッセージ対応ネットワーキング・レイヤ１０６に使用できるメッセージ対応プロトコルの例である。ただし、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）などの他の専用プロトコルも使用できる。他にも、トランスポート・レイヤの下のＩｒＤＡやＢｌｕｅｔｏｏｔｈネットワーク・ドライバのメッセージ・プロトコルも考えられる。ネットワーキング・レイヤ１０６は、ＴＣＰ／ＩＰなどの単一の信頼できる接続プロトコルに限られない。したがって、さまざまなデバイスとの接続が可能である。
【００５２】
一実施形態では、メッセージ対応ネットワーク・レイヤ１０６は、Ｊａｖａ２　Ｍｉｃｒｏ　Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）プラットフォームが提供するネットワーキング・クラスから実装することができる。Ｊａｖａ２　Ｍｉｃｒｏ　Ｅｄｉｔｉｏｎプラットフォームは、完全なＪａｖａプラットフォーム用のリソースを持たないまたは完全なＪａｖａプラットフォームを実行するのは効率的でない省スペース・デバイスに適している。Ｊ２ＭＥがすでにネットワーキング・プロトコルのメッセージ対応ファミリ（ソケットをサポートする）を備えているため、メッセージング・レイヤ１０４を追加した場合の省スペース・コストについて、分散コンピューティング機能をすでにＪ２ＭＥを含んでいる小型デバイス用に提供することができる。
【００５３】
メッセージ対応ネットワーキング・レイヤ１０６はさらに、Ｊａｖａ開発キット（ＪＤＫ）のｊａｖａ．ｎｅｔネットワーキング・クラスでも用意できる。それとは別に、メッセージ対応ネットワーキング機能をメッセージ対応ネットワーキング・レイヤ１０６に使用することもできる。好ましい実施形態では、信頼できるトランスポートは不要であり、したがって、ＵＤＰ／ＩＰなどの信頼できないデータグラム・トランスポートをサポートする組み込み型デバイスもまたメッセージング・レイヤをサポートできる。したがって、シン・クライアントは、単にシン・メッセージング・レイヤ１０４を基本ネットワーキング・プロトコル・スタックの上に追加するだけで分散コンピューティング環境に参加することができる。図３に示されているように、基本システムはネットワーキング・レイヤ１０６の上にメッセージング・レイヤ１０４を備える。ネットワーキング・レイヤは、信頼できるメッセージ、たとえばＴＣＰ、または信頼できないメッセージ、たとえばＵＤＰに対応できる。インターネット・プロトコル（ＩＰ）は、図３に、ネットワーキング・レイヤ１０６で使用できるプロトコルの例として示されている。ただし、分散コンピューティング環境ではＩＰを必要としない。分散コンピューティング環境では、ＩＰに加えて、他のプロトコルも使用できる。Ｅｔｈｅｒｎｅｔ（登録商標）、Ｔｏｋｅｎ　Ｒｉｎｇ、Ｂｌｕｅｔｏｏｔｈなどのネットワーク・ドライバも、ネットワーキング・レイヤの一部とすることができる。多くの小さなクライアントがすでに、ＵＤＰ／ＩＰなどのネットワーク・ドライバおよびトランスポート・プロトコルを備えている。そこで、シンＸＭＬベースのメッセージング・レイヤを追加する際に、デバイスは分散コンピューティング環境に参加できる。
【００５４】
そこで、分散コンピューティング環境の基礎は、信頼できる接続および／または信頼できないデータグラムの上に実装された単純なメッセージ通信レイヤである。このメッセージング技術は、Ｊａｖａリモート・メソッド呼び出し（ＲＭＩ）を採用するＪｉｎｉなどの他の分散コンピューティング・システムで採用されている通信技術とはかなり異なる。メッセージ通信レイヤ１０４は、ＲＭＩで記述される状態を保持する同期スタイルではなく、状態を保持しない非同期スタイルの分散プログラミングをサポートしている。さらに、メッセージ通信レイヤ１０４は、ＸＭＬなどのデータ表現言語に基づいており、そのため、ＲＭＩと異なり、コピー元からコピー先へデータをコピーするが、コードはコピーしない。Ｊａｖａコードはメッセージの発送側または受取側に想定されていないため、ＸＭＬなどの表現データ言語を使用することにより、メッセージング・レイヤ１０４は非Ｊａｖａおよび非Ｊｉｎｉプラットフォームとの相互運用性をシームレスに実現できる。さらに、ＲＭＩとは異なり、メッセージング・レイヤ１０４は、ＴＣＰ／ＩＰなどの信頼できるトランスポート・メカニズムを必要としない。
【００５５】
メッセージ通信レイヤは、たとえば、バイトの配列またはバイト列として指定されたメッセージを送るために単純なｓｅｎｄ（）およびｒｅｃｅｉｖｅ（）メソッドを提供することができる。ｓｅｎｄ（）メソッドは即座に戻り、データ転送を非同期に実行することができる。フロー制御のため、ｓｅｎｄ（）メソッドがｓｅｎｄ（）リクエストを処理できないことを示す例外をスローした場合に呼び出されるコールバック・メソッドを提供できる。ｒｅｃｅｉｖｅ（）メソッドは同期メソッドで、次に使用可能なメッセージを返す。
【００５６】
このメッセージ通信レイヤは、さらに、「スペース」内にオブジェクト、サービス、およびコンテンツのＸＭＬ表現を格納するメソッドを備えることもできる。スペースは、ＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）を使用してネットワーク上で名前が指定されアクセスされる。ＵＲＩは、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）またはＵＲＬの簡易版でもよい。いくつかの実施形態では、ＵＲＬクラスは大きすぎる場合がある。このような実施形態では、より単純なリソース・ロケータを使用し、クライアントとサーバとの間のメッセージの移動に使用するプロトコル、プロトコル依存ホストＩＤ、プロトコル依存ポートＩＤ、スペース名を指定する。
【００５７】
メッセージング・レイヤで提供しているｗｒｉｔｅ（）メソッドを使用してオブジェクトのＸＭＬ表現をスペースに追加することができる。一実施形態では、クライアント指定名とオブジェクトをパラメータとして与えることができる。一実施形態では、ｗｒｉｔｅメソッドは、オブジェクトをそのＸＭＬ表現に変換する。オブジェクトを返し、スペースから削除するためにｔａｋｅ（）メソッドを用意することができる。スペース内のＸＭＬ表現から指定されたオブジェクト返すためにｆｉｎｄ（）メソッドを用意することができる。ｆｉｎｄ（）メソッドもまた、クラスが与えられた場合にスペース内のマッチするオブジェクトの配列を返すのに使用できる。これらのスペース・メソッドはそれぞれ、メッセージ通信レイヤを使用して実装される。リース・メカニズムも、後述のように提供することができる。
【００５８】
発見サービスを、特定のスペースを見つけるためにクライアントが使用できる一般的なサーチ機能としてクライアントに提供することができる。シン・クライアントが実装することができないと思われる複雑なサーチ・プロトコルを定義しようとするのではなく、発見サービスが実際のサーチをＸＭＬベースのサーチ機能にオフロードし、発見サービスがインターフェース機能をクライアントに簡単に提供できるようにする。このアプローチは図４に示されている。一実施形態では、発見サービスは特定するものを指定する文字列を受け取り、ＸＭＬメッセージを既知の発見フロント・エンド（たぶん、デフォルトのスペースで見つかる）に送り、その後、文字列を解析し、サーチ機能に対し対応するＸＭＬクエリを実行する（これは、インターネットサーチ機能でもよい）。発見フロント・エンドは、サーチ機能から受け取ったものを解析し、文字列の配列（各文字列は見つかったそれぞれのスペースのＵＲＩ）としてそれを再パッケージし、ＸＭＬメッセージでクライアントに送ることができる。発見サービスでは、メッセージングが接続指向トランスポートの上にあることを要求していないことに注意されたい。したがって、ＴＣＰを持たない非常に軽量のシン・クライアントであってもこのような発見サービスを使用できる。発見フロント・エンドでは、クライアントがクライアント上にブラウザまたはサーチ機能なしでスペースを発見することが可能である。クライアントは、キーワードを指定する文字列を、サーチ機能とインターフェースするフロント・エンドに送る単純な機能だけあればよい。
【００５９】
クライアントは、少なくともＡＰＩとメッセージング・レイヤのサブセットを使用してメッセージを送ることができるプラットフォームであれば何でもよい。一実施形態では、ＡＰＩレイヤは、静的（またはｒａｗ）および書式付き（またはｃｏｏｋｅｄ）メッセージの両方に対応できる。サーバは、メッセージ要求を受け取り、遂行できるプラットフォームであれば何でもよい。クライアントからサーバへ、または他のクライアントへバイト列を移動する明示的ｒａｗメッセージ発送を提供できる。メッセージ・タイプは、信頼できるメッセージ（たとえばＴＣＰ）、または信頼できないメッセージ（たとえばＵＤＰ）として指定できる。デバイスのうち最も小さいものは、ｒａｗの信頼できないメッセージ通信を、分散コンピューティング環境に参加する単独の手段として使用する。デバイスは、これらのメッセージを使用してその存在と状況をアナウンスする。このような小さなデバイスは、さらに、ｒａｗメッセージを受け取りて、機能のオン／オフなどのいくつかの機能を実行できる。
【００６０】
スペースなどのメッセージベースのサービスでは、信頼できる書式付きメッセージを送受取できる。スペース・メッセージは、きちんと定義されたヘッダーを備える形式とし、ＸＭＬを使用する。一実施形態では、書式付きメッセージは、クライアントがスペース・メソッドを使用して、スペースにオブジェクトを要求したり、スペースにオブジェクトを書き込んだり、スペースからオブジェクトを取り出したりする。メッセージ・コンテンツは、動的にＸＭＬ形式にすることができ、きちんと定義されたヘッダを備える。図５は、書式付きの静的メッセージをサポートするクライアント・プロファイルを示している。静的メッセージを使用することにより、小さなデバイスはコードのさらに小さなプロファイルを使用して、分散コンピューティング環境に参加することができる。たとえば、小さなデバイスは基本的なあらかじめ定められたメッセージだけを送ることができる。クライアントにもよるが、静的なあらかじめ定義されたメッセージが占有するメモリは少ないと考えられる（たとえば、２００バイト未満）。静的メッセージは、さらに、大きなデバイスにあってはオプションとしてもよい。他方、動的ＸＭＬメッセージは、オブジェクト値がコンパイル時にわかっていないときに役立つ。
【００６１】
図６には、メッセージング・システムとＸＭＬメッセージおよびＸＭＬオブジェクト表現とを組み合わせた分散コンピューティング・モデルが示されている。プラットフォームがＸＭＬから独立していることを利用すると、システムを異機種分散コンピューティング環境に対応させることができる。したがって、クライアント１１０は、Ｊａｖａなどの特定のプラットフォームではなくほとんどどのようなプラットフォームにでも実装することができる。メッセージング・システムは、インターネット・プロトコル（たとえば、ＴＣＰ／ＩＰやＵＤＰ／ＩＰ）などのネットワーク対応メッセージング・レイヤに実装することができる。そのため、コンピューティング環境をインターネットに分散させることができる。一実施形態では、メッセージング・システムはさらに、クライアントおよび／またはスペース・サーバおよび／またはサービスが同じコンピュータ・システムにあるときに、共有メモリを高速なプロセス間メッセージ・パッシング・メカニズムとして使用することもできる。図６の分散コンピューティング・モデルは、さらに、ほとんどどのような規模のクライアントであってもＸＭＬメッセージの発送および／または受取を行えるように設定できるため、非常にスケーラブルである。
【００６２】
図６に示されているように、分散コンピューティング・モデルで、サービス１１２およびクライアント１１０の２種類のソフトウェア・プログラムを実行することができる。サービス１１２は、サービスの使用を望んでいるクライアントに機能を通知することができる。サービス１１２は、スペース１１４で機能を通知する。図７に示されているように、クライアント１１０およびサービス１１２は同じネットワーク・デバイス内に常駐することもまた常駐しないこともある。たとえば、デバイス１２０および１２４はそれぞれ、１つのクライアントをサポートするが、サービス１１２ａおよびクライアント１１０ｂは同じデバイス１２２内に実装される。また、図７に示されているように、デバイスがクライアントとサービスをサポートするのに特定のプラットフォームを必要としない。たとえば、デバイス１２０は、Ｊａｖａベースとし、デバイス１２４はネイティブ・コードのランタイム環境を備える。
【００６３】
デバイスは、ネットワーキング・トランスポートでアドレス指定可能なユニットである。デバイスの例としては、それらに限定はされないが、ＰＤＡ、携帯電話、ノートパソコン、ラップトップ、デスクトップ・コンピュータ、より強力なコンピュータ・システム、さらにはスーパー・コンピュータもある。クライアントとサービスは両方とも、デバイスで実行されるソフトウェア（またはファームウェア）のＵＲＩアドレス指定可能なインスタンスとすることができる。クライアントは、分散コンピューティング環境アーキテクチャを使用してサービスを実行する。スペースとは、ＸＭＬドキュメントのリポジトリを管理するサービスである。これが冗長であっても、読みやすさのために、ここではスペース・サービスという用語を使用する。ソフトウェア・コンポーネントは、別々の時にクライアントでかつサービスであってもよい。たとえば、サービスがスペースを使用するときに（たとえば、自分を通知するために）、そのサービスはスペースのクライアントとなる。
【００６４】
図８は、一実施形態における分散コンピューティング環境の基本モデルを示している。この分散コンピューティング環境は、ネットワーク全体を通してクライアント１１０をサービス１１２に接続する。ネットワークは、インターネットなどのワイド・エリア・ネットワークでよい。また、ネットワークは、インターネットで無線ネットワークに接続されたローカル・エリア・ネットワーク（ＬＡＮ）などのネットワークの組み合わせとすることもできる。図８に示されているように、サービス１１２は、スペース１１４内で自分自身に対し通知１３２をパブリッシュする（ＸＭＬで表される）。通知１３２で、サービスのＸＭＬスキーマとＵＲＩアドレスを指定する。その後、クライアント１１０は、通知１３２をルックアップする。クライアント１１０は、通知１３２を使用して、ゲート１３０をインスタンス化する。ゲート１３０により、クライアント１１０はサービス１１２を実行するが、その際に、ＸＭＬメッセージをサービス１１２に（から）発送（し、そして受取）する。
【００６５】
サービスを実行した結果は一部、ＸＭＬメッセージでクライアントに返すことができる。ただし、小さなクライアントでは他の結果が大きすぎ一度に受け取りて消費することができないため、サービス１１２は、図９に示されているように、それらの結果または結果１３４のＸＭＬ表現をスペース１１４に入れ、値で返すのではなく、（ＸＭＬメッセージによる）参照でクライアント１１０に返す。結果への参照を返す方法の例として、それらに限定されないがスペース内の結果を参照しているＵＲＩをメッセージで返す方法や、結果のＵＲＩを含むＸＭＬドキュメントをメッセージで返す方法がある。後で、クライアント１１０は、結果にアクセスするか、または結果を参照で他のサービスに受け渡すことができる。結果を格納するスペースはサービスが通知されるスペースと異なっていてもよい。
【００６６】
一実施形態では、分散コンピューティング環境はコンテンツの定義、通知、および記述にＸＭＬを使用する。分散コンピューティング環境の新しいコンテンツ（たとえば、メッセージおよび通知）はＸＭＬで定義される。既存のコンテンツ・タイプ（たとえば、他の環境用に開発されたもの）も、ＸＭＬを使用して、あるレベルの間接化（メタデータ）として記述することができる。ＸＭＬは、Ｊａｖａがユニバーサル・コードを提供するのと似た方法で、ユニバーサル・データを提供するため、分散システム全体を通じてデータを表現する強力な手段となっている。ＸＭＬは、言語にとらわれない手段であり、自己記述的である。ＸＭＬコンテンツは、強い型付けで、スキーマを使用して妥当性を確認できる。システムは、用意されたＸＭＬスキーマを使用する際に、有効なＸＭＬコンテンツのみがメッセージで確実に渡されるようにできる。ＸＭＬコンテンツはさらに、ＨＴＭＬやＷＭＬなどの他のコンテンツ・タイプに変換することもできる。したがって、ＸＭＬを認識しないクライアントでも、そのまま、分散コンピューティング環境のサービスを使用できる。
【００６７】
一実施形態では、分散コンピューティング環境のメッセージで、クライアントをサービスと接続し、スペースおよびストア内のコンテンツを取り扱うために使用されるプロトコルを定義することができる。メッセージを使用してプロトコルを定義すると、さまざまな種類のデバイスをプロトコルに参加させることができる。各デバイスは、その能力と役割に最適の方法でプロトコルを自由に実装することができる。たとえば、すべてのデバイスがＪａｖａランタイム環境をサポートできるわけではない。分散コンピューティング環境のプロトコル定義では、デバイスでＪａｖａを使用する必要もなければ使用することを暗示してもいない。また除外することもない。
【００６８】
サービスの機能は、そのサービスが受け入れるメッセージに関して表すことができる。サービスのメッセージ・セットは、ＸＭＬスキーマを使用して定義することができる。ＸＭＬメッセージ・スキーマにより、ＸＭＬ型付きタグを使用して各メッセージ形式を定義する。タグの使用規則もまた、スキーマで定義できる。メッセージ・スキーマは、メッセージを受け取るために使用するサービスのメッセージ・エンドポイントとともにＸＭＬ通知の一コンポーネントであってよい。分散コンピューティング環境では、クライアントがサービスの機能のすべてのサブセットまたは一部のサブセットを使用することができる。クライアントに与えられた機能セットを強制するためにセキュリティ・ポリシーを採用する。たとえば、一組の機能をクライアントに与えた後、クライアントは適切な承認がないとそのセットを変更することはできない。この機能定義のモデルにより、基本機能セットから拡張機能セットまでのサービス・レベルに対応できる。認識されたメッセージの数に加えることにより、拡張機能をサービスに追加することができる。
【００６９】
一実施形態では、分散コンピューティング環境内のすべてのオペレーションは、クライアントとサービスとの間で送られるＸＭＬメッセージとして実現される。ストレージ（一時的記憶と継続的記憶の両方）プロバイダは、クライアントとサービスがコンテンツを格納し、通知し、アドレス指定できるようにするサービスの例である。クライアントおよびサービスは、一時的ストレージ・スペースを使用して互いを見つけまたブローカ・コンテンツを見つけることができる。サービスは、コンテンツまたはサービス通知をスペース内に配置する。通知を使って、コンテンツ・タイプまたはサービスの機能を記述することができる。クライアントは、その後、スペースをブラウズして、目的の機能セットとマッチする通知を探す。クライアントがマッチする通知を見つけると、通信チャネルを確立し、その通知を裏付けるサービスとの間で双方向メッセージ通信を行えるようにする。一実施形態では、通信チャネルは認証される。サービスのオペレーションの結果（もう１つのコンテンツ・タイプにすぎない）は、応答メッセージでクライアントに直接返され、スペース内で通知され格納されるか、またはスペース内で通知されるが永続的に格納される。格納されている結果は、ＵＲＩ（たとえば、応答メッセージで返される）を使用して取り扱われ、関連する認証証明書が割り当てられる。
【００７０】
メッセージ・ゲート
上述のように、分散コンピューティング環境では、ＸＭＬなどのデータ記述言語を使用する。ＸＭＬを使用してターゲット・エンティティ（たとえば、ドキュメント、サービス、またはクライアント）を記述し、そのエンティティにアクセスするためのコードを生成することができる。ターゲット・エンティティにアクセスするため生成されるコードは、メッセージ・ゲートと呼ばれる。したがって、一実施形態では、この分散コンピューティング環境は、他のオブジェクトにアクセスするために必要なオブジェクト間の必要なコードを受け渡す代わりに、この分散コンピューティング環境ではオブジェクトまたはターゲットＸＭＬ記述にアクセスできるようにしてターゲットにアクセスするためＸＭＬ記述に基づいてコードを生成するという点で、他の分散コンピューティング環境とは異なる。分散コンピューティング環境では、ＸＭＬスキーマを使用して、言語固有のＡＰＩに依存することなくＸＭＬスキーマだけで型安全性とともにプログラミング・モデル（たとえば、サポートされているメッセージ）を確実なものにすることができる。ＸＭＬスキーマから生成されたコードはさらに、ローカル・プラットフォームの言語、セキュリティ、型安全性、および実行環境の特性を組み込むこともできる。したがって、ローカル・プラットフォームでは、バグが入り込まないように、またスキーマに従って有効なデータのみが生成されるように、生成されるコードを制御する。生成されるコードは、クライアントのコード実行環境（たとえば、Ｊａｖａ、Ｃ＋＋、Ｓｍａｌｌｔａｌｋ）だけでなく、その管理およびセキュリティ・フレームワーク（Ｗｅｂサーバおよび／またはオペレーティング・システム）に適合する。
【００７１】
分散コンピューティング環境では、ＸＭＬスキーマから生成されるコードが実行時に「オンザフライで」生成されることを要求していないことに注意されたい。その代わりに、コードの一部または全部をサービスのカテゴリ（またはクラス）に合わせて事前に生成し、その後、プラットフォームのビルド・プロセスでリンクする。コードの事前生成は、いくつかのＸＭＬスキーマがすでに知られている組み込みデバイスなどのある種のクライアントに対し有用である。一実施形態では、コードの一部または全部が実際に、全く生成されなくてもよい。一実施形態では、プライベート・コード・ロード方式（クライアント内の）を使用して生成プロセスを補強することができる。さらに、いくつかの実施形態では、分散コンピューティング環境でサービスにアクセスする際に追加機能のコードをダウンロードするためのインターフェースを指定することができる（たとえば、後述のメッセージ・コンダクタを参照）。通常、ダウンロードされるこのようなコードは小さく、クライアントにはコードをダウンロードするかしないかのオプションが用意される。
【００７２】
「生成されるコード」というフレーズは、クライアント・コード実行環境の制御のもとでクライアント内で起動されるコードまたは別のところで（サービス・システムまたはスペース・サービス・システム上で）生成され、生成後クライアント・システムにダウンロードできるコードを指す。ただし、バインド時は実行時となる。実行時に、生成されたコードは、サービス・アドレス（ＵＲＩ）にバインドされ、メッセージがそのサービスのインスタンスに送られる。
【００７３】
上述のように、分散コンピューティング環境のサービスとのインターフェースをＸＭＬスキーマで指定し、クライアントがそのサービスに送る（そしてそのサービスから受け取る）メッセージの集まりを定義することができる。図１０に示されているように、クライアント１１０およびサービス１１２は、それぞれ、メッセージ・ゲート１３０を構築し、指定されたＸＭＬスキーマに従って通信する。サービス１１２について通知されたＸＭＬスキーマ（および場合によってはサービス通知の他の情報）から、クライアント１１０ａまたは１１０ｂがそれぞれメッセージ・ゲート１３０ａまたは１３０ｂを構築できる。同じＸＭＬスキーマから生成される対応するメッセージ・ゲート１３０ｃも、サービス１１２ａ上に存在する。ゲート１３０は、型安全なＸＭＬメッセージの発送および／または受取を行え、またメッセージの発送および／または受取のときにＸＭＬメッセージの型の正しさを検証できるメッセージ・エンドポイントである。メッセージ・ゲートはさらに、メッセージ・エンドポイントがセキュリティで保護されていることを確認する認証および／またはその他のセキュリティ・メカニズムにも対応する。一実施形態では、メッセージ・ゲートは常にセキュリティで保護されている。
【００７４】
上記の分散コンピューティング環境のメッセージング・レイヤをゲートに結合するか、またはゲートの一部とすることができる。メッセージング・レイヤは、非同期にネットワーキング・トランスポートを使用し、バイトの順序列を発送側から受取側へ送り、発送側と受取側の両方でこのバイト列が１つのアトミック・ユニット、つまりメッセージであるという概念を維持する。分散コンピューティング環境では、ネットワーキング・トランスポートがＩＰベースであるという仮定を置かない。その代わりに、メッセージング・レイヤは、デバイスによってどのようなネットワーキング・トランスポート・レイヤがサポートされていようと一番上に置かれる。
【００７５】
メッセージ・ゲートは、クライアントとサービスとの間でＸＭＬメッセージを送り受け取るメカニズムを備えることができる。ＸＭＬメッセージは、「型付けする」ことができる。たとえば、メッセージに、メッセージ・データ・フィールドが、たとえば整数、浮動小数点、テキスト・データなどであるかどうかを示すタグを入れることができる。メッセージ・ゲートは、発送または受け取ったメッセージの型の正しさを検証するように構築することができる。メッセージ・ゲートはさらに、受け取ったメッセージの発送側を認証（たとえば、セキュリティ保護機能を使用して識別）することもできる。サービスによって受け入れられるかつ／またはサービスによって送られるメッセージ・セットを記述するＸＭＬスキーマをサービスに対し提供することができる。メッセージ・ゲートは、そのゲートが構築されたＸＭＬスキーマに従って発送または受け取ったメッセージの正しさを検証する。
【００７６】
ゲートは、分散コンピューティング環境で、型検証および／またはメッセージの正しさの検証および／またはクライアントとサービスとの間のメッセージに対する発送側識別を実行するコードおよびデータの単一のアトミック・ユニットとして構築することができる。一実施形態では、メッセージ・ゲートに対するコードおよびデータのアトミック・ユニットが作成されると、これはその型付け、メッセージ記述子、および発送側識別に関して変更することはできない。他の実施形態では、ゲートは、作成後、メッセージ・スキーマ内のメッセージの削除、追加、または修正を含めて、メッセージ・スキーマのコンテンツに関して修正することができる。
【００７７】
メッセージ・ゲートは、分散コンピューティング環境におけるクライアントまたはサービスのメッセージ・エンドポイントである。メッセージ・ゲートは、型安全なＸＭＬメッセージを送り受け取るセキュリティで保護されたメッセージ・エンドポイントを備える。メッセージ・ゲートを使用すると、クライアントとサービスは、適当なメッセージ・トランスポート（たとえば、ＨＴＴＰ）で、セキュリティで保護され信頼できる方法により、ＸＭＬメッセージを交換することができる。クライアントでは、メッセージ・ゲートは、サービスの機能の一部または全部を使用する権限を表す。各機能は、サービスに送ることができるメッセージによって表すことができる。このようなメッセージはそれぞれ、メッセージの正しさを検証するクライアント・メッセージ・ゲートを通じて送ることができる。メッセージを受け取るには、メッセージを認証し、その正しさを検証するサービス・メッセージ・ゲートを使用する。
【００７８】
メッセージ・ゲートは、ＸＭＬメッセージの型検査を行うセキュリティで保護された通信エンドポイントを備えることができる。後述するように、メッセージ・ゲートはさらに、クライアントとサービスとの間のメッセージの流れを制限するメカニズムを備えることができる。一実施形態では、クライアントがサービスにアクセスしようとする場合、クライアントとサービスのメッセージ・ゲートのペアが、すでに存在しているのでなければ、作成される。一実施形態では、サービス・メッセージ・ゲートは、サービスがクライアント・メッセージ・ゲートから第１のメッセージを受け取ったときに作成される。一実施形態では、１つまたは複数のサービス・メッセージ・ゲートをサービスの初期化時に作成し、これを使用して、作成の際にクライアント・メッセージ・ゲートとペアを組むようにできる。メッセージ・ゲートを作成する場合、目的のレベルのセキュリティを交渉する認証サービスおよびクライアントとサービスとの間で受け渡すことができるメッセージ・セットが必要になることがある。一実施形態では、認証サービスはクライアントＩＤトークン（クライアント・トークンともいう）、サービスＩＤトークン（サービス・トークンともいう）、およびサービスに発送またはサービスから受け取ることができるデータ表現言語メッセージ・セットを記述するデータ表現言語メッセージ・スキーマを受け付けることができる。たとえば、サービスを呼び出す、またはサービスのいくつかの一部を呼び出すために、クライアントからサービスに送られるメッセージを記述できる。また、応答メッセージやイベント通知メッセージなど、サービスから送るメッセージも記述できる。メッセージ・ゲートの構築および使用での認証サービスの使用方法の詳細については、以下の「認証とセキュリティ」の項を参照のこと。
【００７９】
クライアント・メッセージ・ゲートとサービス・メッセージ・ゲートのペアにより、クライアントとサービスとの間でメッセージを送ることができる。一実施形態では、サービスのメッセージ・スキーマに記述されているとおり全メッセージ・セットのサブセットを発送かつまたは受け取るだけのメッセージ・ゲートを作成することができる。分散コンピューティング環境でこのような制限されたアクセスを利用することにより、セキュリティ・ポリシーに基づいて特定の個別メッセージ・タイプへのアクセスのみをクライアントに許可する最低限の特権のポリシーを実施することができる。ゲートの使用法およびゲートの作成方法の詳細については、以下の「認証とセキュリティ」の項を参照のこと。
【００８０】
クライアント・ゲートとサービス・ゲートは、サービス通知（サービス通知内のサービスのＵＲＩ）で指定されたプロトコルを使用して、クライアントからサービスへのメッセージの実際の発送（および受取）を実行する。クライアントは、このメッセージ・パッシングでサービスを実行する。メッセージ・ゲートは、クライアントとサービスとの間の抽象（ａｂｓｔｒａｃｔｉｏｎ）のレベルを与える。クライアントは、サービス・オブジェクトに直接アクセスする代わりにメッセージ・ゲートを通じてサービス・オブジェクトにアクセスすることができる。ゲートはクライアントからのサービスを抽象化しているので、クライアントが最初にサービスを使用するまで、サービスのコードをロードして開始する必要はない。
【００８１】
クライアント・ゲートも、ＸＭＬスキーマと突き合わせてメッセージの検証を実行するか、または、たとえば、メッセージがまだ検証されていないことをクライアントが示した場合に、ＸＭＬスキーマと突き合わせてメッセージの検証をサービス・ゲートによって実行することができる。いくつかの実施形態では、単純なクライアントの場合に検証は実用的でなく、クライアント側に必要ない場合がある。いくつかの実施形態では、サービス側で検証を実行できる。ゲートではさらに、認証有効化および／またはセキュリティ方式を実行することもできる。一実施形態では、クライアントがサービス通知で指定されたプロトコルをサポートしない場合、正しいゲートを構築できないことがある。この問題を避けるために、サービス通知（ゲート構築に使用される）はサービスに使用可能なＵＲＩのリストを含め、さまざまなクライアントをサポートできるようにする。
【００８２】
基本メッセージ・ゲートは、メッセージを発送および受け取るためのＡＰＩを実装できる。このＡＰＩは、ゲートとの間でデータ（たとえば、ＸＭＬメッセージ）を出し入れし、送る前および／または受取後のメッセージの妥当性を確認する。一実施形態では、メッセージ・ゲートは、メッセージを発送および受け取るための定められた最低限のＡＰＩをサポートできる。後述のように、このＡＰＩは他の機能に拡張することができる。図１０ｂに示されているように、ゲート１３０は、ＸＭＬスキーマ１３２に従って生成することができる。生成されたゲート・コードは、ＸＭＬスキーマに基づいてメッセージを検証する。このゲートは、メッセージＡＰＩを通じてメッセージ・タイプおよび／またはコンテンツが正しいかどうかを検証する。図１０ｂに示されているように、検証されたメッセージは、メッセージＡＰＩを通じて、サービスに送られる。このメッセージを、サービス側の対応するゲートで受け取る。このメッセージへの応答として、サービスは結果１８０を生成することができる。サービスは、そのゲートを通じて結果データ１８２を返す。結果データは、それ自体結果であるか、または、スペースに格納されている結果へのＵＲＩなど結果に対する参照である。さまざまな実施形態において、メッセージＡＰＩは、たとえば、同期メッセージ（要求応答）、非同期メッセージ（応答は要求から切断される）、ユニキャスト・メッセージ（２地点間）、マルチキャスト・メッセージ（ブロードキャスト）、およびパブリッシュとサブスクライブ（イベント・メッセージ）をサポートできる。リモート・メソッド呼び出しメッセージなどの他のタイプのメッセージもサポートできる。
【００８３】
ゲートによって送られた各メッセージは、受取ゲートがメッセージを認証するための認証証明書を含むことができる。各メッセージは、さらに、メッセージが損なわれていないあるいは改変されていないことを受取ゲートが検証するための情報を含むトークンも含む。たとえば、発送側は、受取側が検証するメッセージのハッシュまたはチェックサムを計算することができる。発送側はさらに、発送側の秘密鍵を使用してこのトークンおよび／またはメッセージ全体を暗号化し、暗号化されたメッセージに対応する公開鍵を含め、トークンが変更されていないことを受取側が検証できるようにする。詳細については、以下の「認証とセキュリティ」の項を参照のこと。
【００８４】
メッセージ・ゲートのペアは、クライアントからサービスへの要求およびサービスからクライアントへの応答を伝達するメカニズムを備える。２つの関連するメッセージ・ゲート・エンドポイントを使用して、要求応答メッセージ通信用のセキュリティで保護された双方向アトミック・メッセージ・チャネルを作成することができる。そこで、分散コンピューティング環境では、メッセージ・ゲートがクライアントとサービスの両方の側に存在するメッセージ・トランスポートを採用する。この２つのゲートは連携して、セキュリティで保護され信頼できるメッセージ・チャネルを実現する。
【００８５】
図１１ａには、サービス通知またはその他のサービス記述１３２からクライアント１１０内にゲート１３０ａを構築することを示す一実施形態の図が示されている。クライアントは、ＸＭＬサービス記述に基づいてゲートを生成するクライアント上の信頼できるコードであるゲート・ファクトリ１４０を備える。ゲート・ファクトリ１４０を使用すると、生成されるゲートが信頼できるコードでもあること、またそのコードがサービス通知に関して正しいものであることを確認することができる。図１１ｂに示されているように、ゲート１３０ｃはさらに、サービス１１２に構築することもできる。クライアント・ゲート１３０ａおよびサービス・ゲート１３０ｃは、クライアントとサービスとの間の通信を行うためのメッセージ・エンドポイントを提供する。一実施形態では、ゲート・ファクトリがゲート１３０を構築するために必要とする断片はサービス（サービス通知から）のＸＭＬスキーマとサービス（サービス通知から）のＵＲＩである。他の実施形態では、さらに、サービスを通知で指定された認証サービスを実行することにより、認証証明書を取得し、ゲート構築で使用することができる。
【００８６】
ゲート・ファクトリは、メッセージ・ゲートを作成するための信頼できるメカニズムを備える。いくつかの実施形態では、メッセージ・ゲートが信頼できるメッセージ・エンドポイントであることを確実なものとするために、ゲートを作成するために使用されるコードは信頼できるコードである必要がある。ゲート・ファクトリ１４０は、ゲートを作成するために使用されるコードの信頼できるパッケージとすることができる。一実施形態では、分散コンピューティング環境でメッセージの発送および受取を望む各クライアントおよびサービス・デバイス・プラットフォームはゲート・ファクトリを備える。いくつかの実施形態では、別のゲート・ファクトリによりゲートをあらかじめ構築して、あらかじめ構築されたゲートを備えたデバイスで完全なゲート・ファクトリを必要としなくて済むようにするか、またはゲートは、サービスＵＲＩおよび／または認証証明書の実行時に（たとえば、メッセージ通信が必要なときに）あらかじめ構築されたゲートにバインドする部分ゲート・ファクトリを備えることができる。
【００８７】
デバイス用のゲート・ファクトリは、ローカル・デバイス・プラットフォームの言語、セキュリティ、型安全性、および／または実行環境の特性を組み込むゲート・コードを生成できる。デバイスは、ゲート自体を構築することにより、生成されたゲート・コードにバグがないこと、有効なデータのみを生成すること、型安全であることを確認することができる。サービスにアクセスするためコードをダウンロードするのではなく自分のゲート・コードをデバイスで生成する利点は、クライアント・コード管理環境に制御権があるという点である。生成されるコードは、クライアントのコード実行環境（たとえば、Ｊａｖａ、Ｃ＋＋、Ｓｍａｌｌｔａｌｋ）だけでなく、その管理およびセキュリティ・フレームワーク（Ｗｅｂサーバおよび／またはオペレーティング・システム）に適合する。生成されたコードは、クライアントの実行時環境がコード作成に関わっていたため信頼できるコードでもある。したがって、信頼できる生成されたコードにより信頼できるセキュリティ情報も追加できる。そのため、デバイスはサービスに対するＸＭＬメッセージ・スキーマを受け取りてから、その後デバイスにアクセスするためにそのスキーマに基づいてゲートを構築することができる。ＸＭＬスキーマは、サービスとの契約を定義することとみなすことができ、生成されたゲート・コードは、その契約を実行するセキュリティで保護された手段を提供することとみなすことができる。信頼できない（たとえば、ダウンロードされた）コードが実行される開いているデバイスは、信頼できるコードでのみゲートを生成できるように設定できることに注意されたい。開いているデバイスは、ゲートの実装、特にゲート認証証明書を発見することができるデバッガなど、ゲートがツールからアクセスできない保護され分離されているコード・コンテナに封じ込められているプロセス・モデルを採用することができる。
【００８８】
ゲート・ファクトリ１４０は、クライアントのためにサービスと交渉し、メッセージをサービスに送るためのゲートを作成する。同様に、ゲートをサービスで構築し、クライアント・ゲートからメッセージを受け取り、メッセージをクライアント・ゲートに送るようにできる。それとともに、クライアントとサービス・ゲートは、セキュリティで保護された双方向通信チャネルを形成できる。
【００８９】
ゲート・ファクトリは、ゲートを作成する際にあるレベルの抽象化を行う。たとえば、クライアントがサービスを使用することを望んでいる場合、クライアントが直接サービスにアクセスするゲートを作成する代わりに、サービスをインスタンス化する一環としてゲート・ファクトリによりゲートを作成できる。
【００９０】
ゲート・ファクトリは、構築するゲートの認証証明書を受け取るため認証サービス（たとえば、サービス通知により指定された）と通信するために使用される信頼できる独自のメッセージ・ゲートを作成または備えることができる。アクセスが制限されているサービスでは、認証証明書なしでゲートを構築することができる。サービスではアクセスを制限しないので、このようなサービスのゲートは、各メッセージを有する認証証明書を送る必要がない場合がある。認証サービスは、一実施形態では、アクセスを制限しないサービスの一例である。したがって、サービスでアクセスを制限するかどうかをチェックすることによりゲート構築を最適化するようにゲート・ファクトリを設定できる。サービスがアクセスを制限しない場合、ゲート・ファクトリはゲート構築の一環として認証サービスの実行を回避することができ、また構築されたゲートの一部として認証証明書に対する取り込まれた規定を回避できる。ゲート・ファクトリはさらに、ＸＭＬメッセージ・スキーマ（たとえば、サービス通知によって指定される）を受取またはダウンロードし、そのスキーマとマッチするゲートを作成することもできる。ゲート・ファクトリはさらに、ＵＲＩと通信するクライアント・メッセージ・ゲートの作成に使用するサービスおよび／またはサービス・メッセージ・ゲート用にＵＲＩを受取またはダウンロードすることもできる。
【００９１】
さらに、サービスのＸＭＬスキーマと突き合わせてメッセージのチェックを実行することを望んでいないいくつかのクライアントに対して別のゲート構築最適化を採用することができる。クライアントは、軽量過ぎてチェックを実行できなかったり、チェックを実行するのにサービス・ゲートに依存していたり、単にチェックの実行を選択しなかったりする（たとえば、ゲート・メモリ占有面積を減らすため）。提供されるＸＭＬスキーマと突き合わせてメッセージを検証するためにゲートを構築するかどうかの表示を受け取るようにゲート・ファクトリを設定できる。いくつかの実施形態では、いくつかのクライアントが、構築されたゲートのスキーマと突き合わせてメッセージの検証を行う機能を備えていないゲート・ファクトリを備えることができる。いくつかの実施形態では、メッセージを検証しないようにゲートを事前に構築する。いくつかの実施形態では、送出メッセージのみを検証するか、または受け取ったメッセージのみを検証するように、ゲートを構築することができる。したがって、いくつかの実施形態では、クライアントは、ＸＭＬスキーマと突き合わせてメッセージをチェックするゲート・コードの一部または全部の構築を回避するか、または回避することを選択できる。
【００９２】
いくつかの実施形態では、デバイスは、同じサービスが実行されるごとに構築するのを回避するためにゲートのキャッシュを維持することができる。たとえば、新しいゲートがゲート・ファクトリにより構築されるときに、ゲートをゲート・キャッシュ内に維持することができる。ゲートが使用されなくなったら、削除する代わりに、ゲート・キャッシュ内に保持する。ゲート・キャッシュがいっぱいになったら、最近最も使用されていないデータを追い出すアルゴリズムなどのキャッシュ置換アルゴリズムに従って１つまたは複数のゲートをゲート・キャッシュから削除することができる。ゲートを構築するためゲート・ファクトリが呼び出された場合、ゲート・ファクトリはまず、新しいゲートの構築を回避できるようにゲート・キャッシュをチェックしてマッチするゲートがすでに存在していないか調べる。
【００９３】
他のゲートを構築するのに使用した断片を適切に再利用することによりゲートの構築を軽量化することができる。各ゲートのいくつかの部分は同じでよいため、メッセージ検証コードの一部など、ゲートからゲートへ再利用することができる。さらに、いくつかのデバイスについては、共通ゲート・コードをデバイスのシステム・ソフトウェアに組み込み、そのデバイスのすべてのゲートと共有することができる。したがって、ゲート・ファクトリは、ゲートごとにこの共通コードを再構築することを回避することができる。その代わりに、ゲート・ファクトリは、単に、ゲートをこのシステム・ソフトウェア部分にバインドすることができる。たとえば、デバイスにどのようなトランスポートが提供されていようとメッセージ・レイヤを取り扱えるシステム・ソフトウェア部分を用意することができる。
【００９４】
特に、スペース・サービスは、スペース・サービスに対して構築されたサービス・ゲートがそのスペース・サービスの他のサービス・ゲートと同じ多くの機能を実行できるため、上述のゲート構築最適化の多くに対して適切な候補といえる。スペース・サービスの詳細については、以下の「スペース」のセクションを参照のこと。
【００９５】
いくつかの場合において、より効率的なメソッド呼び出し形式が存在することがある。たとえば、ターゲット・サービスがクライアント・アプリケーションと同じＪａｖａ仮想マシンで実行される場合、より効率的なメソッド呼び出し形式は、サービスに対しＪａｖａ　Ｄｙｎａｍｉｃ　Ｐｒｏｘｙ　Ｃｌａｓｓを作成することである。このような場合、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔ．Ｍｅｔｈｏｄ呼び出しは、メッセージの発送よりも高速なことがある。ゲート・バインド時間プロシージャは、このような最適化をチェックし、ゲート・ファクトリを実行する代わりにそれを使用して、ゲートを作成するか、または既存のゲートをバインドする。
【００９６】
一実施形態では、専用クライアントや小型埋め込み型デバイスの場合などで、実行時のゲート・コードの生成は、メモリの消費とコード生成時間の観点から、望ましくないことがある。したがって、実行時にゲートを生成するゲート・ファクトリを用意する代わりに、いくつかの実施形態では、ゲートを事前に生成し、デバイスに組み込む。たとえば、埋め込み型ソフトウェアのビルド時に、実行時に構築しなくてよい組み込みのセキュリティで保護されたメッセージ・エンドポイントを含める手段としてメッセージ・ゲートを生成することができる。したがって、組み込み型ゲートを持つクライアントは、完全なゲート・ファクトリを必要としないか、またはＵＲＩおよび／または認証証明書など、組み込みゲートへのある種の実行時バインドを実行するために部分的ゲート・ファクトリのみあればよい。
【００９７】
ゲートの事前構築用に生成ツールを用意することができる。そのゲート生成ツールは、ＸＭＬパーサ、コード・ジェネレータ、およびコード・コンパイラを備える。一実施形態では、コード・ジェネレータはＪａｖａソース・コード・ジェネレータであり、コード・コンパイラはＪａｖａコード・コンパイラである。組み込みメッセージ・ゲートが望まれるソフトウェアのビルド時に、ゲートが望まれる関連するすべてのＸＭＬスキーマからの入力とともに生成ツールが実行される。
【００９８】
たとえば、デバイスがデジタル・カメラとの間でメッセージを送受取できる組み込みメッセージ・ゲートを備えることが望ましい場合、デバイス・ソフトウェアのビルドは、カメラのＸＭＬメッセージ・スキーマを入力としてゲート生成ツールを実行する作業を含む。ＸＭＬスキーマは、ＸＭＬスキーマをメッセージ検証プロセスで高速アクセスするのに適している内部形式に変換するＸＭＬパーサにより解析することができる。ツールのコード・ジェネレータは、カメラのスキーマに対応するゲートのソース・コードを提供することができる。いくつかの実施形態では、生成ツールはさらにソース・コードをコンパイルし、ゲート・コードはデバイスのソフトウェア・パッケージにリンクすることができる。実行時に、分散コンピューティング環境でカメラ・サービスを発見することができる。カメラ・サービスのメッセージＵＲＩをデバイス内でカメラの組み込みゲートにバインドすることができる。事前に構築されたゲートへのＵＲＩのバインドは、デバイス内のゲート・コンストラクタによって実行される。このゲート・コンストラクタは、かなり小さく、単純なゲート・ファクトリである。カメラ・サービスがインスタンス化されると、カメラ・サービスのＵＲＩがＸＭＬメッセージとしてゲート・コンストラクタに渡される。その後、ゲート・コンストラクタはＵＲＩを事前構築されたゲートにバインドする。
【００９９】
したがって、ゲートは、実行時に部分的にまたは完全に生成されるか、またはゲートは、実行時に実行されるバインド・プロセス（たとえば、ＵＲＩまたは証明書の）で実行時の前に事前生成される。一実施形態では、ゲート・ファクトリなどのゲート生成ツールまたは事前構築されたゲートの生成ツールを、あるレベルのプラットフォーム独立性を実現するＪａｖａベースのツールとすることができる。それとは別に、ゲート生成ツールは、分散コンピューティング環境では特定のデバイスのネイティブ・コードなど任意の言語のものが提供できる。分散コンピューティング環境では、デバイスがゲートのコードの一部または全部をダウンロードできないことはないことに注意されたい。たとえば、いくつかの実施形態では、サービスは、そのサービスへのアクセスを望むクライアントによってダウンロードできるゲート・コードを提供する。ただし、ダウンロードされたコードは、サイズ、セキュリティ、および／または安全に関する危険性を示す場合がある。
【０１００】
一実施形態の考えられるゲート・コンポーネントの詳細な図を図１２に示す。ゲートは、そのアドレス（または名前）１５０、デスティネーション・ゲート・アドレス１５２、有効なＸＭＬスキーマ（または内部形式）１５４、およびトランスポートＵＲＩ　１５３を備えることができる。他の実施形態では、ゲートに認証証明書１５６を含むことができる。一部のゲートは、さらに、リース１５８および／またはメッセージ・コンダクタ１６０を備え、メッセージ順序付けを検証することができる。ゲートの名前１５０は、そのゲートを参照するだけの一意的なＩＤでよい（そのゲートの存続期間中）。ゲートは、ゲート名１５０を使用してアドレス指定することができる。一実施形態では、ゲート名はＸＭＬスキーマの文字列（たとえば、サービス通知からの文字列）と１２８ビット乱数などの乱数の組み合わせとして生成することができる。名前１５０を使用する際に、クライアントおよびサービスはネットワークに関して移行することができ、またそのまま協調動作する。好ましい実施形態では、ゲート・アドレスは、物理的メッセージ・トランスポート・アドレスおよび／またはソケット・レイヤと独立である。したがって、ゲート名はメッセージ・トランスポート・アドレスに対するバインドおよびバインド解除できる仮想メッセージ・エンドポイント・アドレスを与えることができる。一実施形態では、ゲートの名前は、そのゲートの存続期間中、そのゲートを参照するだけのＵｎｉｖｅｒｓａｌ　Ｕｎｉｑｕｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＵＩＤ）でよい。
【０１０１】
ゲート名は、ゲートは存続している限り存続するため、同じデバイス内で実行する異なるアプリケーションとクライアントは特定のゲートを繰り返し見つけて、使用することができる。たとえば、サービスにアクセスするためデバイス内で実行している第１のクライアント・プロセスについてゲートを作成することができる。第１のクライアント・プロセスがそのサービスに対する活動を完了した後、ゲートを解放する。ゲートを解放する作業では、ゲートの第１のクライアント・プロセスのメッセージ・トランスポート・アドレス（たとえば、ＩＰおよび／またはポート・アドレス）へのバインドを解除する必要がある。ゲートは、ゲート・キャッシュまたはリポジトリに格納することができる。同じサービスを実行する必要がある同じデバイス内で実行している第２のクライアント・プロセスは、そのゲートを名前で特定し、そのゲートを使用してサービスにアクセスする。ゲートを使用するために、第２のクライアント・プロセスはゲートをそのメッセージ・トランスポート・アドレスにバインドし、第２のクライアント・プロセスに対するメッセージ・エンドポイントがゲート名と第２のクライアント・プロセスのトランスポート・アドレスとの組み合わせになるようにする。他の実施例では、クライアントは動的ＩＰアドレスを受け取ることができる（たとえば、モバイル・クライアント）。クライアントのトランスポート・アドレスが変更されると、（１つまたは複数の）ゲート名がクライアントの新しいトランスポート・アドレスに再バインドされ、クライアントがそのまま、サービスを再配置しゲートを再作成せずにすでにアクセスしているサービスにアクセスできる。ゲート名は、プロセスの移行にも使用できる。プロセスおよび関連するゲートを、分散コンピューティング環境の一ノードにチェックポイント化するかまたは保存して、他のノードに移動することができる。プロセスを新しいノードで再起動し、関連するゲートをその新しいノードのトランスポート・アドレスにバインドすると、プロセスは、移行前のアクセス先であった外部サービスにそのままアクセスすることができる。ゲートは、ペアの相手である他のゲートの現在の場所を追跡することができる。したがって、サービスまたはクライアントを移行しても、そのままアクセス可能である。たとえば、複製または負荷バランスをとったサービス実装をゲートによってサービスのクライアントから抽象することができる。そこで、ゲート名１５０は、分散コンピューティング環境でメッセージ・エンドポイントのアドレス指定を行う柔軟性の高いメカニズムを提供する。ゲート名を使用して、ローカル・ネットワークからインターネットにいたるさまざまなネットワーク上でゲートを特定および／またはアドレス指定することができる。ゲート名は、メッセージ・トランスポートとは無関係で、メッセージ・エンドポイント（ゲート）を基礎となる異なるトランスポート・アドレス（たとえば、ＩＰ／ポート・アドレス・ペア）へのバインド解除および再バインドによりトランスポートからトランスポートへ移動することができる。
【０１０２】
一実施形態では、ゲートをさらにサービスから分離し、同じゲートを使用して時間がたつうちに要求を異なるサービスに送ることができる。この作業には、ゲートのデスティネーション・ゲート・アドレス１５２のバインドを解除し、新しいデスティネーション・ゲート・アドレスをゲートにバインドする作業が必要である。
【０１０３】
ゲートは、デバイスのトランスポート・レイヤの上のレイヤとして実装することができる（たとえば、ネットワーキング・ソケット）。各ゲートは、トランスポート参照１５３を含む。ゲート名１５０は、上述のようにトランスポート参照１５３にバインドされる。複数のゲートが、同じメッセージ・トランスポートを共有することができる。たとえば、複数のゲートが同じＴＧＰ／ＩＰソケットへのトランスポート参照１５３を持つことができる。同じメッセージ・トランスポートを共有することにより、各ゲートのサイズおよび複雑さを低減することができる。分散コンピューティング環境内のデバイスは、メッセージの送受取に必要なゲートの数が増える場合がある。複数のゲートに対するメッセージ処理の複雑さは、共通メッセージ・トランスポートを共有することにより低減される。トランスポート参照１５３は、トランスポートＵＲＩ（たとえば、ＵＲＬ）またはソケット参照であり、基礎のトランスポートに名前を付け、そのトランスポートを他のゲートと共有するメカニズムを提供することができる。複数のローカル・ゲートは、同じトランスポートへの参照１５３を含むが、各ローカル・ゲートは、ペアのリモート・ゲートとの間でメッセージの送受取を行う他のローカルゲートとは無関係に動作する。
【０１０４】
スキーマ１５４は、ゲート・ファクトリによってスペースからゲート内にダウンロードすることができる。スキーマを、メッセージ検証プロセス中に素早くアクセスするのに適している内部形式にコンパイルすることができる。一実施形態では、スキーマは、クライアント・サービス・メッセージおよびプロバイダ・サービス・メッセージという２つのメッセージのグループを指定できる。クライアント・サービス・メッセージ・グループは、クライアントが送ることができるすべてのメッセージの記述（プロバイダがサポートする）を含み、プロバイダ・サービス・メッセージ・グループは、プロバイダが送ることができる（クライアントが受け取る）すべてのメッセージの記述を含む。一実施形態では、クライアントまたはプロバイダのいずれかがスペース・サービスに対し特定の要求を送り、クライアント・サービス・メッセージ全体、プロバイダ・サービス・メッセージ全体、クライアントおよびプロバイダ・サービス・メッセージ全体、またはクライアント・サービス・メッセージまたはプロバイダ・サービス・メッセージのいずれかの特定のメッセージのいずれかのメッセージとともに応答メッセージを取得する。さらに、ゲートが構築された後、クライアントは、ゲートが実際にメッセージを送りなくても、ただし、その代わりに、ゲートのメッセージ群を検査することにより、サービスの機能に関してクエリを実行することができる。
【０１０５】
上述のように、メッセージ・ゲートは、認証証明書を使用するメッセージの発送側、型安全性に対するメッセージ・コンテンツをＸＭＬスキーマに従って検証することができる。ただし、クライアントとサービスとの間でメッセージが正しい順序で送られることを検証することが望ましい。クライアント上のアプリケーションに関係する既存の特定の機能なしで（たとえば、クライアント上のアプリケーションにＧＵＩがない場合）実行するクライアント用のアプリケーション（サービス）を提供できることが望ましい。たとえば、クライアント上でＷｅｂブラウザをサービスのＧＵＩとして使用し、アプリケーション固有のＧＵＩを使用しないようにできる。ＸＭＬスキーマ内の可能なメッセージのうち、クライアントは次にサービスに送るメッセージを知る必要がある。クライアントはサービスに関する特定の情報がないまま次に送るメッセージを判別できることが望ましい。一実施形態では、サービスは必要な次の入力を示す応答メッセージを継続的に送ることができる。サービスは、その後、要求入力が指定されているクライアントから対応するメッセージのみを受け入れる。メッセージ順序付けに対する他のアドホックな方式も採用できる。
【０１０６】
他の実施形態では、各メッセージのシンタックスを検証する（スキーマに従ってゲート内ですでに実行されている可能性がある）のとは反対に、メッセージ・コンダクタ１６０をゲート内で採用するか、またはゲートに関連付け、メッセージの正しい順序を検証することができる。メッセージ・コンダクタ１６０は、アプリケーションの準備のためのより一般的なアプローチをとることができる。メッセージ・コンダクタ１６０は、サービスの通知で指定できる。スキーマ内のメッセージ・コンダクタ指示により、ゲート構築中に、クライアント上に生成するか、またはクライアントにダウンロードすることができ、次にサービスに送るメッセージを決定するのに必要なコレオグラフを提供できる。メッセージ・コンダクタは、Ｊａｖａアプリケーション、Ｊａｖａ　Ｓｃｒｉｐｔ、およびＷＭＬスクリプトとして、または他のプログラミングまたはスクリプティング言語で実装できる。
【０１０７】
一実施形態では、メッセージ・コンダクタは入力を、クライアントとサービスの間で送ることができるメッセージの有効な順序またはコレオグラフを表示するＸＭＬ文書（たとえば、サービス通知からの）として受け入れることができる。このＸＭＬ文書はさらに、ユーザ・インターフェース情報とその他の規則を指定することもできる。コンダクタは、このＸＭＬ文書を解析して、内部形式にし、囲まれている順序付け情報に従ってメッセージ順序付け（および／またはその他の規則）を強制する。コンダクタは、メッセージの発送順序が狂うのを防ぐことができる。または、メッセージの発送順序が狂った場合、発送デバイス内に例外を発生させることができる。メッセージの受取順序が狂った場合、コンダクタは順序付けエラーを宣言する自動応答メッセージを送る。これで、発送側はメッセージを正しい順序で再送することができる。いくつかの実施形態では、コンダクタの一部または全部を複数のゲートで共有することができることに注意されたい。そのため、コンダクタを複数のゲートにリンクすることができる。
【０１０８】
分散コンピューティング環境の一実施形態では、サービスのフロント・エンド（サービス・インターフェース）をクライアントに組み込むことができる。一実施形態では、サービス・インターフェースを、サービスによってクライアントに提供される事前構築ユーザ・インターフェースとすることができる。一実施形態では、サービス・インターフェースを、サービス通知でクライアントに提供することができる。サービス・インターフェースは、クライアント上でサービスのユーザと対話し、サービスを実行するための入力を取得し、サービスを実行した結果をクライアントに表示することができる。「ユーザ」は、人間でも、組み込みシステムでも、他のクライアントまたはサービスなどでもよい。一実施形態では、クライアント・デバイスは、フロント・エンドを組み込んでいるサービスを実行できるだけなので、任意のサービスを用意することができない場合がある。一実施形態では、サービスのサービス・インターフェースは、クライアント上のＷｅｂブラウザに実装することができる。
【０１０９】
一実施形態では、メッセージ・コンダクタおよび／またはサービス・インターフェースはゲートの外部にあってもよく、したがって、ゲートとクライアントから抽象することができる。抽象されたメッセージ・コンダクタは、任意のクライアント・デバイスに対し任意のサービスを提供することができる。一実施形態では、メッセージ・コンダクタを、実質的にどのようなプラットフォームでも実行できるコードで書くことができる。一実施形態では、メッセージ・コンダクタは、Ｊａｖａ言語で書く。一実施形態では、メッセージ・コンダクタは、クライアント・デバイスに返される、オブジェクト、たとえば、Ｊａｖａオブジェクトの任意のダウンロードを必要としない。たとえば、非常に大きなオブジェクトを返す場合、メッセージ・コンダクタは、そのような非常に大きなオブジェクトをダウンロードしないことを選択できる。一実施形態では、メッセージ・コンダクタは、クライアントのために、ＸＭＬメッセージをクライアント・デバイスからサービスに送ることができる。メッセージ・コンダクタは、サービスのユーザと対話して、入力を受け取り、結果を表示することができる。
【０１１０】
一実施形態では、クライアントと対話し（たとえば、ユーザ・インターフェースを介して）、サービスを実行するためのすべての情報を取得するサービス・インターフェースを提供し、これにより、サービスを実行した結果または結果の場所に関する情報のいずれかを適宜表示することができる。サービス・インターフェースは、メッセージ・コンダクタ１６０の一部でもよく、またはメッセージ・コンダクタ１６０に加えてそれと連携することもできる。サービス・インターフェースは以下のいずれかである。
１．クライアント・デバイスに組み込まれ、クライアント上で実行される。
２．スペース・サーバからクライアント・デバイスにダウンロードされる。
３．スペース・サーバ上で実行される。
４．サービス・プロバイダ上で実行される。
【０１１１】
一実施形態では、クライアントに対して、分散コンピューティング環境のスペース・サーバは＃１を常にサポートし、＃２がサポートされていればそのことを示し（スペース内の通知で）、＃３と＃４のうち少なくとも１つがサポートされていればそのことを示す必要がある。＃４をサポートしているかどうかは、サービス・プロバイダが＃４をサポートしているかどうかにかかっていることに注意されたい。一実施形態では、サービス・プロバイダに対し、分散コンピューティング環境のスペース・サーバは＃４を常にサポートし、＃３をサポートしていればそのことを示す必要がある。
【０１１２】
サービス・インターフェースがどこで実行されようと、サービスがアクティブ化された後、サービス・インターフェースはクライアントと対話し、クライアントの表示装置に入力に対する要求を（リモートから）表示し、サービスの実行結果を（リモートから）表示することができる。クライアントとのこのような対話は、ＸＭＬメッセージとして実装される。このようなサービス・インターフェースおよび／またはメッセージ・コンダクタは、サービスを発見したけれども、ふつうサービスの使い方を知るために大部で無味乾燥のコンピュータ・マニュアルを読みたくないクライアント・ユーザのニーズに応えられる。サービス・インターフェースおよび／またはメッセージ・コンダクタがユーザと対話して、サービスが必要とするすべての入力を要求するときに、ユーザが要求した場合に、要求された入力の短い説明を用意することさえできる。サービス・インターフェースがクライアントから必要な情報を取得した後、ＸＭＬメッセージを、そのサービスを実行するサービス・プロバイダに送る。メッセージの順序は、ゲート内のメッセージ・コンダクタ１６０によって検証される。
【０１１３】
好ましい実施形態では、すべてのメッセージはゲート内を流れる。ゲートは、フロー制御メカニズムを提供するように構成することができる。たとえば、サービスが大量の着信メッセージおよび発送メッセージを処理する必要がある。フロー制御により、サービスは高トラフィック・ボリュームに追随することができる。フロー制御タグについてメッセージを監視するようにゲートを構成することができる。ゲートがメッセージを受け取ると、ゲートはそのメッセージに対するフロー制御タグを調べる。フロー制御タグはＸＭＬタグとすることができる。たとえば、メッセージには、ＯＦＦタグまたはＯＮタグのいずれかを記述できる。受け取ったメッセージにＯＦＦタグが含まれる場合、受取ゲートはペアのデスティネーション・ゲートへの発送メッセージを停止する。ゲートは、ＯＮタグを含むメッセージを受け取ると、メッセージの発送を再開する。
【０１１４】
そこで、サービス側ゲートはそのリソースの使用を監視し、そのリソースの使用がしきい値を超えた場合にフロー制御を起動する。たとえば、サービスが、ＯＦＦタグを含むメッセージを１つまたは複数のクライアント・ゲートに送ることにより負荷を低減することができる。ＯＦＦタグを含むメッセージを受け取ったクライアント・ゲートは、サービスへのメッセージ発送を停止する。クライアント内の保留メッセージは、バッファリングするか、または内部フロー制御メカニズムによって処理することができる。サービスがさらに要求を処理できるようになると、ＯＮタグを含む１つまたは複数のクライアントにメッセージを送り、クライアントはメッセージ発送を再開する。他の実施形態では、ＯＮおよびＯＦＦに加えて、またはＯＮおよびＯＦＦの代わりに、他のフロー制御タグをサポートすることができる。他のフロー制御タグはメッセージ・フローの低減を示すか、またはそのメッセージ・フローを高くすることができる。
【０１１５】
メッセージ・ゲートはリソース監視を実行するように構成することができる。たとえば、すべてのメッセージはゲート内を流れるため、ゲートはクライアントがサービス（および場合によっては、メモリーやスレッドなどの関連するリソース）を使用する状況を管理しかつ／または追跡するように構成することができる。ゲートは、サービスなどのリソースがどれだけ使用されているか、またどのサービス・リソースをどれだけ使用しているかを監視することにより、クライアントなどのソフトウェア・プログラムの活動を追跡するように構成できる。一実施形態では、ゲートはクライアント活動ログを生成するか、またはクライアント活動ログの生成を簡単に行えるようにする。各メッセージおよびその宛先または発送側をログに記録することができる。
【０１１６】
さらにゲートは、ゲート・ペアのローカル（発送）側からフロー制御に関するリソース監視を実行するように構成することもできる。クライアントが、割り当てられたサービス（またはリソース）使用の帯域幅を超えた場合、たとえば、ゲートは自動的にメッセージの流れを絞る。したがって、クライアント側メッセージ・ゲートは、発送メッセージの流れを監視することにより異なるフロー制御モードを自動的に起動することができる。発送メッセージ・フローがしきい値を超えた場合、ゲートは発送メッセージの流れを減らすかまたは遮断する。サービスのＸＭＬスキーマまたは通知でしきい値を指定することができる。いくつかの実施形態では、しきい値は特定のサービス・リソースを使用するメッセージのみまたはすべてのメッセージについて指定することができる。
【０１１７】
ゲートは、さらに、メッセージ・フローが増えるか、または再開するのを判別するように構成することもできる。一実施形態では、ゲートは、マッチする返信（応答）を受け取ることなく、送られた発送メッセージのカウントを保持することができる。マッチする応答がクライアント側ゲートに届いたら、未処理の要求メッセージのカウントを減らす。このカウントが未処理要求メッセージの指定されたしきい値以下に減ったら、ゲートは新しい要求メッセージを増やすか、またはその発送を再開することができる。
【０１１８】
ゲートは、メッセージ・ベースの課金請求機能をサポートするように構成できる。請求システムは、メッセージ・ゲートで発送および／または受け取ったメッセージの個数および／または種類に基づいて実装することができる。クライアントとの間でやり取りされるすべてのメッセージはゲートを通過するので、たとえば、１メッセージごとにまたは「即金で支払う」方式でサービス使用料金を簡単にクライアントに請求できるようにゲートを構成することができる。したがって、たとえば、ユーザの代わりに実行されているソフトウェアがメッセージを発送および／または受け取るごとにユーザに課金できる請求システムを分散コンピューティング環境内に実装することができる。
【０１１９】
一実施形態では、メッセージ・ゲートは、たとえば、サービスに関してＸＭＬスキーマから請求情報を受け取る。請求情報は請求ポリシーとチャージ・バックＵＲＩを表すことができる。チャージバックＵＲＩは、メッセージ・ゲートがユーザの代わりに時間課金または使用度課金する場合に使用する。メッセージ・ゲートは、課金メッセージをＸＭＬスキーマで指定したチャージバックＵＲＩに送ることによりチャージバックを実行する。このように構成されたゲートは請求ゲートと呼ばれる。請求ポリシーは、１メッセージ当たりの課金金額または累積メッセージ合計に対する課金金額などを示す。請求ポリシーは、ユーザに対しどれだけおよび／またはどのような頻度で（たとえば、ｘ個のメッセージを発送および／または受け取った後）課金するかを示す。このポリシーはある種のメッセージのみが課金を発生させ、このようなメッセージにより指定されたサービス・リソースが要求されることを示す。請求ポリシーはさらに、異なるクライアントまたはクライアントのクラスに対して異なる請求モデルを示す場合もある。たとえば、いくつかのクライアントがサービスにアクセスするためゲートを作成するときに一度限りの課金の対価を支払うように請求ポリシーを（たとえば、サービスのＸＭＬスキーマで）構成することができる。ポリシーは、即金で（たとえば、メッセージごとに）支払うクライアントを示す場合もあれば、または全く課金されないクライアントを示す場合もある。
【０１２０】
いくつかの実施形態では、クライアントは軽量すぎて完全なゲートをサポートできなかったり、クライアントに、直接分散コンピューティング環境に参加するためのソフトウェアを組み込めない場合がある。このような実施形態では、サーバ（サービスが通知されるスペース・サーバや他のサーバなど）はそのクライアントに対して完全または部分的なプロキシ・ゲートとすることができる。サーバは、クライアントで使用するサービスごとにサービス・エージェント（ゲートを含むことがある）をインスタンス化する。サービス・エージェントは、メッセージを送る許可を確認し、メッセージをプロバイダに送り、その際、場合によってはプロバイダが次のメッセージを受け付けるようになるまでキューに入れておき、メッセージをクライアントに送り、その際、場合によってはクライアントが次のメッセージを受け付けるようになるまでキューに入れておき、結果またはアクティブ・スペースに結果を格納する作業を管理するという操作を行うことができる。「ブリッジ」のセクションを参照されたい。たとえば、図１３に示されているように、クライアントは、ゲートが上述のメッセージング方式に直接参加することをサポートしていない従来のブラウザ４００とすることができる。ブラウザ４００は、プロキシ・サーブレット（エージェント）４０２によって補助される。ブラウザのユーザは、サーチ・エンジンを使用して、分散コンピューティング環境内のスペース通知サービスの前面に置かれる（その内容を表示する）Ｗｅｂページを見つけることができる。ユーザは、スペースのＷｅｂページをポイントしてクリックし、サーブレットの助けを借りて、サービスにアクセスすることができる。Ｗｅｂページには、スクリプト、たとえば、ＪａｖａやＷＭＬスクリプトを含むことができ、これを使用して、ブラウザをプロキシ・サーブレットに接続する。また、スクリプトを使用して、メッセージをプロキシ・サーブレットに送ることもできる。サーブレット・エージェントは、ブラウザ・クライアントに代わってＷｅｂページ・アクションをメッセージに翻訳する。これらのはアクションは、スペースのナビゲート、サービスの起動、および結果の返却を含む。結果ページＵＲＩ（ＸＭＬを含むページを参照する）は、直接（または必要ならばＨＴＭＬまたはＷＡＰに変換されて）ブラウザに返され、ユーザに対し表示される。したがって、ブラウザ・ベースのクライアントは、サービスの起動方法を知る必要がなく、またサービス使用セッションで送るメッセージを知る必要もない。たとえば、ＷＡＰブラウザのユーザ（たとえば、携帯電話の）は、スペース・ページに接続し、そのコンテンツ（サービス）を参照し、サービスを起動するが、すべてポイントしてクリックする操作により行える。エージェント４０２は、従来のクライアントと分散コンピューティング環境との間のクライアント・インターフェースを備える。
【０１２１】
分散コンピューティング環境は、異なる機能をサポートするクライアントとサービスとの間の通信を行うための数種類のメッセージ・ゲートを備えることができる。たとえば、上述のように、いくつかのゲートは、フロー制御または請求機能をサポートする。他の種類のメッセージ・ゲートでは、特定の形式のリモート・メソッド呼び出しをサポートする。このタイプのゲートは、メソッド・ゲートと呼ばれる。
【０１２２】
ゲートは、型安全なメッセージ、たとえばＸＭＬメッセージを送り受け取るセキュリティで保護されたメッセージ・エンドポイントである。リモート・メソッド呼び出し（ＲＭＩ）スタイルのゲートは、メソッド・ゲートと呼ばれる。直接データ中心ゲートは、メッセージ・ゲートと呼ばれる。メソッド・ゲートは、メッセージ・ゲートの上の「レイヤ」として実装することができる。正確な実装は、プラットフォームのバインドで定義することができる。
【０１２３】
図１４は、メソッド・ゲートを使用してリモート・メソッド呼び出しインターフェースをサービスに提供する方法を示す。メソッド・ゲートは、クライアントとサービスとの間のメソッド・インターフェースを提供する。メソッド・ゲートは双方向にすることができ、クライアントからサービスへ、またサービスからクライアントへのリモート・メソッドを呼び出しが可能である。ＸＭＬスキーマ情報１７０から（たとえば、スペース内のサービス通知から）メソッド・ゲート１７２を生成することができる。ＸＭＬスキーマ情報１７０は、メソッド・インターフェースを定義するＸＭＬを含む。この情報から、１つまたは複数のメソッドとのインターフェースのコードをゲートの一部として生成することができる。生成されたコード内の各メソッドを呼び出し（たとえば、クライアント・アプリケーション１７６からの）により、マーシャリングされたメソッド・パラメータを含むメッセージをサービスに送ることができる。含まれるメッセージのシンタックスおよびパラメータをＸＭＬスキーマで指定する。したがって、メソッド・ゲート１７２は、サービス・メソッドをリモートから呼び出すＸＭＬメッセージ・インターフェースを備える。メソッド・ゲートは、クライアント上に生成するか、またはサービス・メソッドが通知されたスペース・サーバまたは特別ゲートウェイ・サーバなどのサーバをプロキシとすることができる。
【０１２４】
サービスは、サービスのＸＭＬスキーマで定義されたメソッド・メッセージ・セットに対応するオブジェクト・メソッド・セットを実装するかまたは、それにリンクされている対応するメソッド・ゲートを備えることができる。サービスのメソッド・ゲートよって実装された、またはそれにリンクされているオブジェクト・メソッドとサービスのＸＭＬスキーマによって定義されたメソッド・メッセージとの間に一対一の対応関係がある。サービスの対応するメソッドがクライアントからメッセージを受け取りサービスのメソッドの１つを呼び出すと、サービスのメソッド・ゲートはメッセージ呼び出しのパラメータのアンマーシャリングまたはアンパックを行い、受け取ったメッセージによって示されるメソッドを呼び出し、アンマーシャリングされたパラメータを渡す。
【０１２５】
メソッド・ゲートは、同期要求応答メッセージ・インターフェースを備え、クライアントがこれを使用してリモートからメソッドを呼び出し、サービスが結果を返すようにする。基礎のメッセージ・パッシング・メカニズムは、クライアントから完全に隠されている。この形式のリモート・メソッド呼び出しでは、メソッドの結果を次のように処理することができる。一実施形態では、結果オブジェクト（および関連するクラス）をクライアントにダウンロードする代わりに、結果の参照のみをＸＭＬメッセージで返す。オブジェクト参照１７８は実際のオブジェクト結果１８０（たとえば、ネット上にそのまま格納）を表す生成されたコード・プロキシ（たとえば、結果ゲート）である。他の実施形態では、クライアントは実際の結果オブジェクトを受け取ることを選択できる。さらに、クライアントが結果オブジェクト参照を受け取った後、クライアントはこの参照を使用して実際の結果オブジェクトを受け取ったり操作したりできる。一実施形態では、結果参照に実際の結果への１つまたは複数のＵＲＩを含める。
【０１２６】
実際の結果オブジェクトは、サービス結果スペース内に格納される（これは、たとえば、サーブレットにより動的に作成できる）。この一時的結果スペースは、クエリ結果キャッシュとして機能することができる。古い結果領域をクリーンアップするサーバ・ソフトウェア（ガベージ・コレクタ）が結果キャッシュ（スペース）内を巡回する。メソッドを呼び出しごとに返される結果は、結果スペース内に通知される。クライアントがリモートから結果自体をインスタンス化し、その固有のメソッド・ゲートを生成できるメソッドである場合もあれば、そのようなメソッドを含む場合もある。したがって、分散コンピューティング環境では再帰的リモート・メソッドを呼び出しサポートすることができる。
【０１２７】
上述のように、クライアントはメソッド・ゲートを使用してリモートからサービス・メソッドを呼び出すと、サービス・メソッド・ゲートから実際の結果ではなくメソッド結果への参照が返される。この参照から、結果ゲートを生成して実際の結果にアクセスする。したがって、クライアントまたはクライアント・メソッド・ゲートは結果ＵＲＩ、それとたぶん、結果ＸＭＬスキーマおよび／または認証証明書を受け取り、これを使用してゲートを構築しリモート・メソッド結果にアクセスする。
【０１２８】
一実施形態では、サービス・ゲートは結果に対する「子ゲート」を作成する。この子結果ゲートは、親ゲートと同じ認証証明書を共有することができる。いくつかの実施形態では、結果は異なるアクセス権限セットを備え、したがって、その親と同じ認証証明書を共有しない。たとえば、給料支払い簿サービスではユーザの異なる集まりが給料支払い簿サービスの結果（給与）を読み取るためにそれを起動することができる。
【０１２９】
サービス・メソッド・ゲートは、子結果ゲートをメソッドの結果としてクライアント・ゲートに返す。クライアントは、その結果ゲートを使用して実際の結果にアクセスする。一実施形態では、結果ゲートを受け取るソフトウェア・プログラム（クライアント）は結果ゲートと結果自体とを区別することはできず、その場合、結果ゲートは実際の結果オブジェクトのオブジェクト・プロキシとなる。結果ゲートはさらに、結果オブジェクトへのリモート・メソッド呼び出しをサポートするメソッド・ゲートとすることもできる。このようにして、親と子のメソッド／結果ゲートのチェーンを作成できる。
【０１３０】
一実施形態では、メッセージ・ゲートおよびリモート・メソッドは、Ｊａｖａで書れている。この実施形態では、Ｊａｖａ入力システムに従ってメソッド結果が正しく入力される。上述のようにＪａｖａメソッドをリモートから呼び出した場合、結果ゲートは結果の型とマッチするＪａｖａの型にキャストすることができる。この実施形態では、分散コンピューティング環境でメソッド・ゲートを使用して、リモートＪａｖａオブジェクトがローカルＪａｖａオブジェクトとして動作するようにできる。メソッド呼び出しおよび結果は、実際のオブジェクトがローカルであるかリモートであるかに関係なくＪａｖａソフトウェア・プログラムと同じように表示される。結果に対するスペースの使用の詳細については、以下の「スペース」セクションを参照のこと。
【０１３１】
メソッド・ゲートは、単に未処理メッセージ・インターフェースではなく、クライアントへのメソッド・インターフェースを提供する。一実施形態では、メソッド・ゲートは、メッセージ・ゲートの上に実装することができる。メッセージ・ゲートは、トランスポート・アクセス、メッセージ・コンテンツ妥当性確認、およびメッセージ・コンテンツ・アクセスを使用するメソッド・ゲートを提供する（ゲットアンドセット（ｇｅｔ ＆ ｓｅｔ）コンテンツ・メソッド）。一実施形態では、生成されたコード内（つまり、メソッド・ゲート）の各メソッド呼び出しにより、マーシャリングされたメソッド・パラメータを含む単一の同期メッセージがサービスに送られる。その後、メソッド・ゲートにより、現在のスレッドはブロックし、サービスから応答メッセージが返るのを待つ。
【０１３２】
このプログラミングのスタイルを、同期式要求−応答プログラミングと称する場合がある。クライアントが、メソッドを呼び出し、サービスに結果を返させる。基礎となるメッセージ・パッシング機構は、クライアントから完全に隠蔽される。この形のＲＭＩは、独自の興味深い形でメソッド結果を扱う。一実施形態では、オブジェクト（および関連するクラス）をクライアントにダウンロードするのではなく、結果オブジェクト参照（通知または通知ＵＲＩ）だけが返される。この実施形態では、オブジェクト参照を与えられて、実際のオブジェクト（まだネット上で外に格納されている）へのアクセスを与える結果ゲートを生成することができる。
【０１３３】
一実施形態では、サービスによって出力されたいくつかの結果がスペース内で通知され、最終的に結果ゲートを使用してアクセスされる。結果ゲートは、結果を生成するために使用するを入力ゲートと同じセキュリティ証明書を含む場合もあれば含まない場合もある。サービスへの入力は出力（結果）と非同期であるため、結果は、異なるアクセス権限セットが関連付けられる場合がある。Ｂ２Ｂシナリオを使用すると、給料支払い簿サービスについては、ユーザの異なる集まりが給料支払い簿サービスの結果（給与）を読み取るために給料支払い簿サービスを起動することができる。
【０１３４】
一実施形態では、メッセージ・ゲートの結果に対する結果ゲート生成を手動で開始できる。インライン結果（たとえば、サービスから応答として送られたＸＭＬドキュメント）にアクセスするには、メッセージ・ゲートに用意されているメッセージ・コンテンツ・アクセス（たとえば、ゲットアンドセット）メソッドを使用する。メソッド結果のゲート生成は自動的に開始する。プログラミングのメソッド・ゲート・モデルは、結果ゲート生成を隠し、クラス・ロードのオーバーヘッドのない、またはアプリケーション・プログラマが手動で結果ゲートを生成する必要のない、シームレスなリモート・メソッド呼び出しプログラミング・モデルを作成する。
【０１３５】
図４５ａ〜図４５ｄは、メソッド・ゲートを使用する分散コンピューティング環境のクライアントとサービスの間の通信のメカニズムのさまざまな実施形態を示す流れ図である。図４５ａの２１００で、コンピュータ・プログラミング言語（たとえばＪａｖａ）のメソッド・コールの表現を含むメッセージを、クライアント・デバイス上で生成することができる。一実施形態では、メッセージを、データ表現言語で表すことができる。一実施形態では、データ表現言語が、ＸＭＬである。一実施形態では、クライアント・プロセスが、メソッド・コールを行うことができ、このメソッド・コールを、メッセージを含むメソッド・コールの表現にマーシャリングすることができる。メッセージ内のメソッド・コールの表現には、メソッド・コールを識別する識別子（たとえばメソッド名）、および０個以上のメソッド・コールのパラメータ値を含めることができるが、これに制限はされない。メソッドの表現は、データ表現言語で表すことができる。たとえば、表現の要素を、メッセージ内の１つまたは複数のタグ（たとえばＸＭＬタグ）とすることができる。
【０１３６】
一実施形態では、メソッド・ゲートが、クライアント・プロセスによって生成されたメソッド・コールにアクセスすることができ、その後、メソッド・コールをメッセージにマーシャリングすることができる。一実施形態では、実際のメソッド・コールが行われなかった時に、メソッド・コールの表現を含むメッセージをクライアント側で生成することができる。この実施形態では、実際にコンピュータ・プログラミング言語のメソッド・コールを生成せずに、クライアント上のプロセスが、サービス側のコンピュータ・プログラミング言語のメソッドを呼び出すことができる。たとえば、クライアントは、サービスの１つまたは複数のメソッドを呼び出すためにクライアントがサービスに送ることができる１つまたは複数の「缶詰にされた」メッセージを含めることができる。したがって、クライアントは、クライアント上のプロセスが実際にメソッド・コールを行わずに、メッセージを使用して、メソッドを実行するようにサービスに要求することができる。
【０１３７】
２１０２で、クライアントが、サービスにメッセージを送ることができる。一実施形態では、クライアント・メソッド・ゲートが、サービスにメッセージを送ることができる。一実施形態では、クライアント・メソッド・ゲートが、サービスに直接メッセージを送ることができる。もう１つの実施形態では、クライアント・メソッド・ゲートが、クライアント・メッセージ・ゲートにメッセージを供給することができ、このクライアント・メッセージ・ゲートが、サービスにメッセージを送ることができる。
【０１３８】
２１０４で、サービスがメッセージを受け取った後に、受け取ったメッセージ内のメソッド・コールの表現に従って、サービス側で関数を実行することができる。一実施形態では、サービスが、受け取ったメッセージからメソッド・コールをアンマーシャリングまたはアンパックし、受け取ったメッセージによって指定されるメソッドを呼び出し、呼び出されるメソッドに、アンマーシャリングされたパラメータ値を渡す。一実施形態では、アンマーシャリグおよび呼び出しを、サービス側のメソッド・ゲートによって実行することができる。一実施形態では、メソッドを呼び出す代わりに、サービスが、メッセージに応答して関数（たとえば、他のメソッドまたは他のアクション）を実行することができる。たとえば、サービスは、サービス側でメソッドを呼び出さずに、メソッド・コールの所望の結果を生成する関数を実行することができる。もう１つの実施形態では、サービスが、メソッド・コールの結果データを前に生成しており、メッセージに応答して、メソッドを呼び出さずに、その結果データをクライアントに供給することができる。
【０１３９】
２１０６で、サービス側の関数が、メッセージに応答して結果データを生成することができる。２１０８で、結果データを、クライアントに供給することができる。一実施形態では、結果データを、クライアントに直接（たとえばメッセージ内で）返すことができる。もう１つの実施形態では、結果データを、分散コンピューティング環境（たとえば、サービス・デバイスにまたはサービス・デバイスの外部のスペース・サービスに）に格納し、格納された結果データにアクセスするための通知をクライアントに供給することができる。その後、クライアントは、通知を使用して、結果データにアクセスする結果ゲートをセット・アップすることができる。もう１つの実施形態では、サービスが、結果データにアクセスする結果ゲートをクライアントに返すことができる。
【０１４０】
一実施形態では、クライアントが、メソッド・コールを、サービスに送ることができる１つまたは複数のメッセージに変換するが、このメッセージには、メソッド・コールにアンマーシャリングできる情報が含まれず、その代わりに、クライアントに代わって関数を実行するためにサービスが使用できる情報が含まれる。この実施形態では、サービスが、メッセージが元々はメソッド・コールから生成されたものであることを知らない場合がある。一実施形態では、クライアント・メソッド・ゲートが、クライアント側で生成されたメソッド・コールを、クライアントのために１つまたは複数の関数を実行することをサービスに要求する１つまたは複数のメッセージに変換することができるが、このメッセージには、サービスがメソッド・コールにアンマーシャリングすることができるマーシャリングされたメソッド・コールが含まれない。このメッセージは、それでもメソッド・コールの「表現」と見なすことができるが、サービスが、アンマーシャリングしてメソッド・コールを再生成することができるマーシャリングされたメソッド・コールとして認識する形ではない場合がある。
【０１４１】
一実施形態では、サービスが、１つまたは複数の関数を実行するようにサービスに要求する１つまたは複数のメッセージを、メソッド・コールに変換することができる。この実施形態では、メッセージを生成するためにクライアント側でメソッド・コールが行われなかった可能性がある（クライアントが、メソッド・コールに応答して１つまたは複数のメッセージを生成していない可能性がある）。したがって、クライアントは、サービスが、要求された関数を実行するためにメソッドを呼び出しつつあることを知らない場合がある。一実施形態では、サービス・メソッド・ゲートが、クライアントからメッセージを受け取り、メッセージ内の情報からメソッド・コールを構築することができる。
【０１４２】
図４５ｂでは、クライアント・デバイス内で実行されるクライアント・プロセスが、２１１０で、メソッド・コールを行うことができる（すなわち、メソッドを呼び出す）。一実施形態では、メソッド・コールを、Ｊａｖａメソッドへの呼出しとすることができる。一実施形態では、呼び出されるメソッドを、クライアント・デバイス上でローカルに実施することができず、クライアント・デバイスの外部のサービス・デバイスで実施される。２１１２で、クライアント・デバイス側のクライアント・メソッド・ゲートが、メソッド・コールを受け取ることができる。クライアント・メソッド・ゲートは、メソッド・コールをデータ表現言語のメッセージにマーシャリングすることができる。一実施形態では、データ表現言語がＸＭＬである。メッセージに、メソッドの識別子と、メソッドの１つまたは複数のパラメータ値を含めることができる。識別子は、メッセージの受取側に対してメソッドを識別する名前、数、または他の値とすることができる。メソッド・コールに、１つまたは複数のパラメータを含めることができ、呼び出された時に、呼び出す側が、これらのパラメータの値を供給する。一実施形態では、複数のメソッド・コールが、同一の識別子を共有することができ、これらのメソッド・コールを、メソッドのパラメータによって区別することができる。
【０１４３】
２１１４で、クライアント・メソッド・ゲートが、サービス・デバイスにメッセージを送ることができる。一実施形態では、クライアント・メソッド・ゲートが、サービス・メソッド・ゲートに直接メッセージを送ることができる。もう１つの実施形態では、図４５ｃに示されているように、２１２４で、クライアント・メソッド・ゲートが、クライアント・メッセージ・ゲートにメッセージを供給することができる。クライアント・メッセージ・ゲートは、２１２６で、そのメッセージをサービス・メッセージ・ゲートに送ることができる。サービス・メッセージ・ゲートは、その後、２１２８で、サービス・メソッドに供給することができる。図４５ｃに示された実施形態では、メソッド・ゲートが、メッセージの発送および受取を処理する責任から解放され、ＲＭＩ機能とメッセージ処理機能を区分することによって、分散コンピューティング環境のプログラミング・モデルが単純になる。
【０１４４】
一実施形態では、クライアントが、サービス側でメッセージ（およびクライアント）を検証するために、メッセージに証明書を付加することができる。一実施形態では、証明書を、分散コンピューティング環境内の認証サービスからクライアントが入手した可能性がある。一実施形態では、サービスが、使用すべき認証サービスを識別する情報（たとえばサービス通知内で）をクライアントに供給した可能性がある。一実施形態では、サービスが、クライアントを認証するものと同一の認証サービスを使用することができる（たとえば、最初のメッセージがクライアントから受け取った時に）。サービスは、クライアントからのメッセージのそれぞれを検査して、メッセージにクライアントの正しい証明書が含まれることを検証することができる。一実施形態では、サービス・メソッド・ゲートが、検証を実行することができる。もう１つの実施形態では、サービス・メッセージ・ゲートが、検証を実行することができ、検証されたメッセージをサービス・メソッド・ゲートに渡すことができる。証明書および検証に関するさらなる情報については、認証およびセキュリティの節を参照されたい。
【０１４５】
図４５ｂに戻って、２１１６で、サービス・メソッド・ゲートが、受け取ったメッセージからメソッド・コールをアンマーシャリングまたはアンパックし、受け取ったメッセージによって示されるメソッドを呼び出し、呼び出されるメソッドにアンマーシャリングされたパラメータ値を渡すことができる。サービス・メソッド・ゲートは、メッセージに含まれる識別子を使用して、メソッド・コールのテンプレートを特定することができる。サービス・メソッド・ゲートは、サービスのＸＭＬスキーマで定義されたメソッド・メッセージのセットに対応するメソッドのセットを実装するか、それにリンクされることが可能である。サービスのメソッド・ゲートによって実装されるかこれにリンクされるオブジェクト・メソッドと、サービスのＸＭＬスキーマによって定義されるメソッド・メッセージの間に１対１対応がある場合がある。一実施形態では、たとえばサービス通知で、サービスによってクライアントに供給されるメッセージ・スキーマに従って、クライアント側でメソッド・ゲートを作成することができる。一実施形態では、ゲート・ファクトリを使用して、クライアント側でメソッド・ゲートを生成することができる。
【０１４６】
２１１８で、呼び出されるメソッドを、サービス側で実施するか実行することができる。２１２０で、呼び出されるメソッドが、メソッド・コールで受け取ったパラメータ値に従って、呼出しからの結果出力を作ることができる。２１２２で、メソッド・コールの結果を、最初にそのメソッドを呼び出したクライアント・プロセスに供給することができる。一実施形態では、サービスが、１つまたは複数の結果メッセージで、クライアントに直接結果を提供することができる。もう１つの実施形態では、サービスが、結果をスペースに置くことができ、結果にアクセスするための結果通知をクライアントに供給することができる。図４５ｄおよび４５ｅに、結果にアクセスする結果ゲートをクライアントに供給することができる他の実施形態を示す。
【０１４７】
図４５ｄの２１３０で、サービス・メソッド・ゲートが、サービス・メッセージ・ゲートに結果参照を供給することができる。一実施形態では、結果参照を、結果に対する通知とすることができる。もう１つの実施形態では、結果参照を、結果のアドレス、たとえばＵＲＩとすることができる。２１３２で、サービス・メッセージ・ゲートが、メッセージ内で結果参照をクライアント・メッセージ・ゲートに送ることができる。２１３４で、クライアントが、メッセージを受け取った後に、結果参照メッセージから結果ゲートを作成することができる。たとえば、結果通知をメッセージ内で供給することができ、クライアントが、本明細書の他所で説明する通知からのメッセージ・ゲートの作成に類似する形で、結果通知に従って結果ゲートを作成することができる。２１３６で、クライアントが、結果ゲートを使用して、結果にアクセスする。たとえば、結果がサービス・デバイス上にある場合があり、サービスがサービス結果ゲートを生成している。クライアント結果ゲートは、サービス結果ゲートとの通信のために生成され、たとえば、サービス結果ゲートのＵＲＩが結果通知に含まれている。その代わりに、サービスが、分散コンピューティング環境の他所に結果を格納し、クライアント結果ゲートが、結果についてセット・アップされた結果ゲートを用いて通信するように構成される。たとえば、結果をスペース上に置くことができ、クライアント・ゲートが、スペース上の結果ゲートと通信することができる。
【０１４８】
図４５ｅでは、２１４０で、サービスが結果ゲートを作成することができる。その後、サービスは、２１４２で、結果ゲートをクライアントに（メッセージ内で）送ることができる。受け取った結果ゲートを、その後、クライアントが、結果にアクセスするのに使用することができる。この実施形態では、クライアントが、結果ゲートをセット・アップする責任から解放される。
【０１４９】
最初にメソッドを呼び出したクライアント・プロセスに対して、本明細書に記載のＲＭＩのプロセスは透過的である。クライアント・プロセスにとっては、メソッドがローカルに呼び出されているように見え、結果がローカルに供給されているように見える。したがって、メソッド・ゲートがメッセージ・パッシング機構と組み合わされることで、「シン」クライアントは、そうでなければクライアントで実行するのに大きすぎ、かつ／または複雑すぎるプロセスを実行できるようになる。
【０１５０】
Ｊａｖａプラットフォーム・メソッド・ゲート実施形態の例を、下に示す。Ｊａｖａプラットフォームの実際のＪａｖａメソッド・ゲート実施形態は、分散コンピューティング環境プラットフォーム・バインディングで定義される。結果へのアクセスを許可する各Ｊａｖａメソッド・ゲートは、実際には、結果のインターフェースを実装するＪａｖａクラス・インスタンス（オブジェクト）である。たとえば、結果が、型Ｔａｂｌｅのオブジェクトである場合に、結果メソッド・ゲート・クラスを、次のように定義することができる。
Figure 2004504657
【０１５１】
ＴａｂｌｅＭｅｔｈｏｄＧａｔｅオブジェクトは、テーブル型にキャストされてから、メソッド呼び出し結果として返される。このプロセスは再帰的である。つまり、ｇｅｔＮｅｘｔＣｅｌｌメソッドを呼び出すと、ＣｅｌｌＭｅｔｈｏｄＧａｔｅクラスおよびオブジェクト・インスタンスが生成され、ｇｅｔＮｅｘｔＣｅｌｌ結果を表す。
Figure 2004504657
【０１５２】
特定のサービスでどのゲート・タイプ（メッセージまたはメソッド）を使用するかの選択は、プラットフォームのバインドと各サービス通知により組み合わせて処理される。いくつかのプラットフォームでは、メソッド・ゲートをサポートしていない場合がある。プラットフォームでメソッド・ゲートをサポートしている場合、バインドで正確な実装を定義することができる。第二に、サービス通知のインターフェースは、ＲＭＩスタイルのプログラミングに役立つ場合もあれば役立たない場合もある。ＲＭＩスタイルのプログラミング・モデルをサポートするサービス・インターフェースは、以下のＸＭＬ属性でをフラグが立てられる。
Figure 2004504657
【０１５３】
メッセージ・ゲートは、さらに、イベントのパブリッシュおよびサブスクライブ・メッセージ通信もサポートする。イベント・サポートのあるメッセージ・ゲートは、イベント・ゲートと呼ぶ。サービスのＸＭＬスキーマは、サービスによってパブリッシュされる１つまたは複数のイベントの集まりを示す。イベント・ゲートは、ＸＭＬスキーマから構築できる。イベント・ゲートは、サービスによってパブリッシュされたイベントの集まりの一部または全部を認識し、それらのイベントにサブスクライブし、各イベントを、サービスによって生成されるのといっしょに配布するように構成できる。
【０１５４】
サービスに対するイベントの集まりは、サービスのＸＭＬメッセージ・スキーマで記述することができる。ＸＭＬスキーマのイベント・メッセージごとに、イベント・ゲートはそのイベントの消費者としてサブスクライブする。一実施形態では、イベント・ゲートはＸＭＬスキーマで示されるすべてのイベントにサブスクライブする。ＸＭＬタグを使用してそれぞれのイベント・メッセージに名前を付ける。イベント・ゲートは、サブスクライブ先のイベントのＸＭＬタグを含むサブスクライブ・メッセージを送ることによりサブスクライブすることができる。
【０１５５】
サービスで対応するイベントが発生した場合、そのサービスはイベント・メッセージをサブスクライバに送り、そのイベントの発生を知らせる。イベント・メッセージは、ＸＭＬイベント・ドキュメントを含み、このメッセージはそれぞれのサブスクライブされたゲートに送られる。サブスクライブされたゲートがイベント・メッセージを受け取ると、ＸＭＬイベント・ドキュメントがそのメッセージから削除され、配布プロセスが開始する。イベント配布は、クライアント・プラットフォーム内のイベント・ドキュメントを配るプロセスである。クライアント・プラットフォーム内の各イベント消費者は、各タイプのイベントのイベント・ゲートにサブスクライブすることができる。Ｊａｖａプラットフォームで、入力システムはＪａｖａである（ＸＭＬイベント型から変換される）。イベント消費者は、イベント・ハンドラ・コールバック・メソッドをイベント・ゲートに供給する。イベント・ゲートは、これらのサブスクライブのリストを保存する。各イベント・メッセージがゲートに届くと（イベントを発生したサービスから）、ゲートはクライアント消費者のリストをトラバースし、各ハンドラ・メソッドを呼び出して、ＸＭＬイベント・ドキュメントをパラメータとして渡す。一実施形態では、ＸＭＬイベント・ドキュメントはハンドラ・コールバック・メソッドに渡される唯一のパラメータである。
【０１５６】
一実施形態では、イベント・ゲートはローカルの消費者クライアントのためにイベントに関して自動的にサブスクライブする。クライアントがインタレストをゲートに登録すると、ゲートはインタレストをイベント・プロデューサ・サービスに登録する。クライアントはさらに、インタレストのサブスクライブ解除も行い、これにより、ゲートはそのイベントを生成するサービスから登録を解除する。
【０１５７】
イベント・ゲートは、上述の標準要求応答メッセージ通信スタイルで通常のメッセージ・ゲートが行うのと全く同じようにしてＸＭＬスキーマを使用しイベント・ドキュメントの型検査を行う。イベント・ゲートは、さらに、送られたメッセージ内の認証証明書を含み、受け取ったイベント・メッセージの認証証明書を検証することができる。
【０１５８】
上述のゲート機能の組み合わせは単一のゲートでサポートされることに注意されたい。それぞれのタイプは、分かりやすくするため、別々に説明した。たとえば、ゲートは、メッセージ・ゲート、メソッド・ゲート、およびイベント・ゲートであって、フロー制御とリソース監視をサポートする。
【０１５９】
サービス発見メカニズム
一実施形態では、分散コンピューティング環境は、クライアントがサービスを見つけだし、サービスの機能の一部または全部を使用する権限を交渉するための手段を提供するサービス発見メカニズムを備える。スペースはサービスの一例であることに注意されたい。サービス発見メカニズムは、セキュリティで保護され、発送クライアント要求を追跡し、着信サービス応答とマッチングを行うことができる。
【０１６０】
サービス発見メカニズムは、それらに限定されないが、以下のようなさまざまな機能を提供することができる。柔軟なサーチ基準を使用してサービスを見つける機能、サービスの機能セット全体またはそのサブセットを使用する権限をクライアントに伝達することができる、承認メカニズム、たとえば認証証明書を要求する機能、クライアントにサービスのインターフェースを伝達するための証明書、ドキュメント、またはその他のオブジェクトを要求する機能などがある。一実施形態では、サービスのインターフェースは、サービスの機能の要求されたセットとのインターフェースを含むことができる。
【０１６１】
発見の追跡が最初の要求に応答する。一実施形態では、各クライアント要求は、マッチする応答で返されるデータの集合を含み、要求と応答の相関を求めることができる。
【０１６２】
分散コンピューティング環境の一実施形態では、サービス発見メカニズムは拡張可能文法に基づいて柔軟なサーチ基準を提供することができる。一実施形態では、サーチ対象のサービス名、サービス・タイプ、およびもしあればその他の要素とＸＭＬドキュメント内の要素とをマッチングすることができる。一実施形態では、ＸＭＬドキュメントはサービスに対するサービス通知である。ＸＭＬは、サーチのための柔軟で拡張可能な文法を提供する。ＸＭＬはさらに、マッチする要素について型安全であるという特徴も備える。一実施形態では、サービス名およびサービス・タイプは、ＸＭＬサービス通知の要素タイプと突き合わせて型検査を行うことができる。
【０１６３】
一実施形態では、分散コンピューティング環境はクライアントがサービス・アクセス権を交渉するためのメカニズムを備えることができる。一実施形態では、このメカニズムを使用して、サービスの全機能のサブセットについて交渉することができる。交渉の結果は、クライアントにサービスの機能の要求されたサブセットを使用する権限を伝達する認証証明書などの承認である。
【０１６４】
一実施形態では、サービス発見メカニズムを使用する際に、クライアントはサービスにセキュリティ能力証明書を要求することができる。一実施形態では、クライアントはサービスに対し、保護された（セキュア）通知の形で望む機能群を示すことができる。それに対してサービスは、クライアントに保護された通知で記述されている要求された機能を使用する権限を伝達することができる能力証明書で応答することができる。
【０１６５】
一実施形態では、分散コンピューティング環境は、クライアントがサービス・アクセス権限を交渉し、その後、サービスのアクセス・インターフェースをクライアントによって要求されたサービスの機能のセットまたはサブセットに提示するために使用できるセキュリティ証明書またはドキュメントを取得するためのメカニズムを備えることができる。
【０１６６】
一実施形態では、サービスから能力証明書を受け取ったクライアントは、「完全通知」と呼ばれるカスタム・サービス・アクセス・インターフェース・ドキュメントを生成することができる。一実施形態では、完全通知はＸＭＬドキュメントである。生成された通知を利用し、受け取った能力証明書によってクライアントに対し許可されるサービス機能にアクセスすることができる。一実施形態では、通知により、クライアントが能力証明書によりアクセスを許可されたサービス機能のみのインターフェースが提供される。一実施形態では、クライアントに対し、必要な機能に限りクライアントがアクセス特権を持つアクセスを許可することができる。
【０１６７】
一実施形態では、分散コンピューティング環境はクライアントがサービスと機能を交渉するためのメカニズムを備えることができる。一実施形態では、クライアントはサービスに対する機能を交渉することができる。サービスはその後、クライアントと交渉したパラメータに基づいて結果をカスタマイズする。たとえば、１６０×２００の解像度で１ビット表示が可能なクライアントは、サービスに対しそれらのパラメータを交渉し、それにより、サービスはクライアントに対し結果をカスタマイズできる。
【０１６８】
以下に、ＸＭＬ機能メッセージの一例を示したが、何らかの形で制限することを意図していない。
Figure 2004504657
【０１６９】
分散コンピューティング環境は、サービスがサービス呼び出しの結果を返す方法をクライアントが交渉できるようにするメカニズムを備える。一実施形態では、能力証明要求時に、結果返却方法の１つを選択する手段をサービスに伝達することができる。その後、サービスはクライアントに、使用する結果メカニズム、さらにサービス・インターフェースを伝達することができるカスタム・サービス通知を生成する。
【０１７０】
一実施形態では、分散コンピューティング環境はサービス発見サーチ要求および要求への応答を追跡するメカニズムを備える。一実施形態では、サーチ要求および応答メッセージは、フィールドを備え、このフィールドを使用して文字列またはＸＭＬドキュメントを含むことができる。一実施形態では、要求メッセージのフィールドに含まれる文字列またはＸＭＬドキュメントはさらに、応答メッセージでも返される。一実施形態では、文字列またはＸＭＬドキュメントは応答メッセージで返す必要がある。一実施形態では、文字列またはＸＭＬドキュメントは、応答メッセージで返すときに文字列またはドキュメント内に挿入または付加される追加情報を含むことができる。一実施形態では、このメカニズムを複雑なシステムのデバッグに使用することができる。一実施形態では、このメカニズムはさらに、クライアントに対し、文字列またはＸＭＬドキュメントを使用して、クライアントとサービスのみが理解できるクライアントとサービスとの間のカスタムサーチ情報を渡すことによりアクセスするサービスを選択するためのメソッドを提供することができる。
【０１７１】
コンポーネント（サービス）インターフェースのマッチング
分散コンピューティング環境は、コンポーネント（たとえば、サービス）仕様インターフェースと要求されたインターフェースとのマッチングを行うメカニズムを備えることができる。たとえば、クライアント（サービスでもよい）は、一組のインターフェース要求条件を満たすサービスを必要とすることがある。各コンポーネントは、それが適合するインターフェースの記述を含む。仕様インターフェース・マッチング・メカニズムを使用すると、リクエスタのインターフェース要求条件と最もよくマッチするコンポーネントを配置することができる。仕様インターフェース・マッチング・メカニズムではさらに、インターフェース要求条件の「ファジー」マッチングを実行できる。つまり、このメカニズムを使用すると、インターフェースのすべての側面を正確に指定しなくてもマッチングを実行でき、最近マッチング（ファジー）メカニズムを実現できる。一実施形態では、仕様インターフェース・マッチング・メカニズムを、単一のインターレス・レベルで仕様を要求しないマルチレベル・サブクラス化モデルとして実装できる。
【０１７２】
一実施形態では、コンポーネントは、ＸＭＬスキーマ定義言語（ＸＳＤＬ）を使用してそのインターフェースを記述することができる。ＸＳＤＬでは、インターフェースを記述する人間が解釈可能な言語を実現し、デバッグなど人間の介入を必要とする活動を簡素化することができる。一実施形態では、インターフェース記述を本書の別のところで説明しているように通知の一部（たとえば、サービス通知）として提供することができる。
【０１７３】
仕様インターフェース・マッチング・メカニズムを使用すると基本的な望ましいインターフェースとコンポーネントの一組のインターフェース記述とを比較することができる。基本的な望ましいインターフェースとマッチする１つまたは複数のコンポーネントが識別される。インターフェース記述は、コンポーネントによって提供されるインターフェースをより具体的に記述するサブクラス記述を含む。サーチ・プロセスで、クラス・タイプ階層を調べて、所定のクラスがサーチ・タイプのサブクラスであるかどうかを判別することができる。一実施形態では、サブクラスは基本クラスのプロパティーを継承する。このフェーズではサブクラス特有の情報は調べることができない。そのため、サーチは一般的に実行するということができる。識別されたコンポーネントは、次の（サブクラス）レベルでサーチできる。サーチは、サブクラスに特有なものとなり、インターフェース記述に含まれるサブクラス情報を解釈することにより実行できる。サーチは、リクエスタの望むインターフェースとの最近マッチのある１つまたは複数のコンポーネントが判別されるまで１つまたは複数のサブクラスについて続けられる。
【０１７４】
一実施形態では、インターフェース・マッチング・メカニズムは、類似のインターフェースを実装する２つまたはそれ以上のコンポーネントを区別する機能を備える。一実施形態では、インターフェース・マッチング・メカニズムは、同じコンポーネントの異なるリビジョンを区別する機能を備える。
【０１７５】
一実施形態では、コンポーネントが適用するインターフェースの仕様を含むコンポーネント記述を提示することができる。コンポーネント記述にさらに、コンポーネント自体に関する情報を含めることができる。インターフェース記述および／またはコンポーネント情報を使用して、所定のインターフェースの異なる実装を区別することができる。コンポーネント記述には、標準識別子とバージョン情報を入れることができる。バージョン情報を使用すると、コンポーネントのリビジョンを区別することができる。一実施形態では、コンポーネント記述を本書の別のところで説明しているように通知の一部（たとえば、サービス通知）として提供することができる。
【０１７６】
一実施形態では、特定の標準識別子についてコンポーネントをサーチする。マッチする標準識別子を持つ２つまたはそれ以上のコンポーネントを識別することができる。マッチする標準識別子を持つコンポーネントのうちから１つまたは複数のコンポーネントを選択することができる。選択手順では、インターフェース仕様バージョン、コンポーネント実装仕様、コンポーネント実装仕様バージョン、コンポーネント記述からのその他の情報または情報の組み合わせを使用して、リクエスタの要求条件に最もよくマッチする１つまたは複数のコンポーネントの集まりを出力することができる。
【０１７７】
スペース
上述のように、分散コンピューティング環境はスペースに依存し、サービスまたはコンテンツをクライアントに仲介するランデブー・メカニズムを備える。図１５は、スペース１１４の基本的な使用法を示している。サービス・プロバイダは、スペース１１４でサービスを通知することができる。クライアント１１０は、スペース１１４で通知を見つけ、通知からの情報を使用し、分散コンピューティング環境のＸＭＬメッセージング・メカニズムを利用してサービスにアクセスする。多くのスペースが存在し、それぞれサービスまたはコンテンツを記述するＸＭＬ通知を含む。したがって、スペースは、サービスおよび／またはＸＭＬデータのＸＭＬ通知のリポジトリと考えることができ、これは結果などの未処理データまたはデータの通知とすることができる。
【０１７８】
スペース自体はサービスである。サービスのように、スペースには通知があり、スペースのクライアントはまず、そのスペース・サービスを実行するためにそれを取得する必要がある。スペースの自通知は、ＸＭＬスキーマ、１つまたは複数の証明書、およびスペースにアクセスする方法を示すＵＲＩを含むことができる。クライアントは、スペースにアクセスするためにスペース・サービスの通知からゲートを構築することができる。スペースのクライアントはそれ自体、そのスペース内で通知するまたは既存の通知を修正することを求めるサービス・プロバイダである。または、スペースのクライアントはスペースによってリストに入れられたサービスまたはコンテンツにアクセスすることを求めるアプリケーションである。したがって、スペースは分散コンピューティング環境においてクライアントとサービスとの間の対話に対する触媒の働きをする。
【０１７９】
スペースは、名前付きの通知の集合といえる。一実施形態では、通知に名前を付ける作業は、名前文字列を通知に関連付けるプロセスである。この関連付けは、スペースに通知を格納した後発生する。スペースから通知を取り除くと、名前と通知との関連付けが解除される。スペースは、スペース自体を記述する単一のルート通知で作成できる。追加通知をスペースに加えることができる。通知の名前で、スペース内の通知を特定できるが、これは、名前の階層など必要なグラフ化情報を指定する操作を含む。好ましい実施形態では、分散コンピューティング環境はスペースの構造を規定しない。つまり、たとえば、スペースをフラットな関係付けのない通知の集まりまたは関係付けのされている通知のグラフ（たとえば、商用データベース）として構造化される。好ましい実施形態では、分散コンピューティング環境はスペースに実際にその内容を格納する方法を規定しないので、小さなデバイスから大きなデバイスまでスペースをサポートすることができ。たとえば、単純なスペースは、ＰＤＡなどの小さなデバイスに収まるように手直しすることができる。より高度なスペースは、大規模な商用データベースを採用している大規模なサーバー上に実装することができる。
【０１８０】
上述のように、スペースは分散コンピューティング環境でサービスの通知を含むことができる。通知は、分散コンピューティング環境内でサービスおよび／またはコンテンツのアドレスを指定し、アクセスするためのメカニズムを提供する。通知により、サービスのＵＲＩを指定することができる。いくつかの実施形態では、ＵＲＩを使用すると、インターネット上でサービスにアクセスすることができる。また、通知はサービスのＸＭＬスキーマも含む場合がある。ＸＭＬスキーマにより、サービスのクライアントがそのサービスの機能を呼び出すためにサービスに送る一組のメッセージを指定することができる。ＸＭＬスキーマでは、クライアント・サービス・インターフェースを定義する。それとともに、ＵＲＩおよび通知で指定されたＸＭＬは、サービスのアドレスを指定し、サービスにアクセスする方法を指示する。ＵＲＩとスキーマは両方とも、ＸＭＬで、スペース内の通知として用意される。そのため、分散コンピューティング環境でサービスのアドレスを指定し、サービスにアクセスするメカニズムをスペース内の通知として公開することができる。クライアントは、スペースを発見し、サービスまたはコンテンツについて個々の通知をルックアップする。
【０１８１】
図１６は、一実施形態による通知構造を示す。通知５００は、他のＸＭＬドキュメントのように、階層状に配列された一連の要素５０２を含むことができる。各要素５０２は、データまたは追加要素を含む。要素はさらに属性５０４を持つ。属性は、名前−値文字列のペアである。属性は、メタデータを格納し、これにより、要素内のデータを記述することが簡単になる。
【０１８２】
いくつかの実施形態では、通知は異なる状態で存在してもい。このような状態の１つにドラフト状態がある。一実施形態では、スペースの範囲外に存在するドラフト状態で通知を最初に構築する。通知の作成者は、ＸＭＬエディタを使用するなどさまざまな方法で構築することができる。ドラフト状態の要素および属性へのアクセスは、適当な手段を使用して未処理データおよびメタデータ・レベルで行われる。通常、ドラフト状態で通知に加えられた変更についてはイベントを発生しない。したがって、通知の作成者は、自由に、要素を追加、変更、または削除できるだけでなく、目的の属性セットを用意し、確認する分散コンピューティング環境の残り部分に対する通知をパブリッシュすることができる。
【０１８３】
一実施形態では、通知に対する可能な状態としてほかに、パブリッシュ状態がある。通知は、スペースに挿入されるとパブリッシュ状態に移行する。通知がスペース内に入ると、関連するクライアントおよびサービスが、たとえば、名前および／またはその要素をサーチ基準として使用してそれを特定することができる。たとえば、サーチ基準は、スペース内の通知と（たとえば、スペース・サービスにより）比較できるＸＭＬテンプレート・ドキュメントとして指定できる。パブリッシュされた通知は、クライアントが使用できる状態にある「オンライン」サービスを表す。サービスのメッセージ・アドレス（ＵＲＩ）は、通知内に要素として格納できる。スペースから削除される通知は、破棄されるかまたは保持されるドラフト状態に遷移して戻る。削除により、イベントが発生し、関連するリスナーが変更に気づく。メッセージ・ゲートは通常、パブリッシュされた通知から作成される。
【０１８４】
一実施形態では、通知に対する可能な状態としてほかに、永続的アーカイブ状態がある。アーカイブ・プロシージャは、ライブ・パブリッシュ通知を、後で再構成するため永続的に格納できるバイトのストリームに変換する。アーカイブ通知が、スペースからアーカイブ・サービスに送られる（たとえば、ｒａｗ　ＸＭＬ形式で）。通知のアーカイブ・サービスのＵＲＩは、通知内に要素として格納できる。ＸＭＬは、通知の格納および取り出しを行い、通知オブジェクトを再構成するのに十分な通知要素の状態を表す形式を用意できる。通知は、アーカイブ・サービスの実装に応じて、他の形式でも格納できる。パブリッシュされた通知を永続的にするプロセスでは、永続的アーカイブ状態の通知を準備する。将来使用するため永続的通知を（たとえば、アーカイブ・サービスにより）、ファイルやデータベースなどの永続的記憶場所に格納できる。スペースは、アーカイブ・プロシージャを介して、通知を格納できるが、スペースは必ずしも、永続通知エントリを実際に格納する際に重要な役割を果たすわけではない。永続通知を格納する方法は、通知のアーカイブ・サービスにより決定される。通常、アーカイブ通知の代わりに生成されるイベントはない。また、永続的アーカイブ状態での通知に対し変更が許されない場合がある。通知は、アーカイブと削除、またはアーカイブだけが許される。通知が、スペースから削除することなくアーカイブされると、スペースはシャドウ・バージョンの通知を格納する。アーカイブされたサービスにアクセスすると、通知がオンデマンドで永続的バッキング・ストアから「フォールトイン」する。この機能を使用すると、たとえば、オンデマンドで、ＬＤＡＰ（ライトウェイト・ディレクトリ・アクセス・プロトコル）エントリから通知に入力することができる。
【０１８５】
図１７は、通知がその存続期間中に置かれる通知状態遷移の一例を示す図である。まず、１に示されているように、通知を構築することができる。構築のときに、通知はドラフト状態にある。その後、２に示されているように、通知がスペースの中に挿入される。通知は、パブリッシュされた親として挿入できる。通知は、スペースに挿入された後、パブリッシュ状態にある。イベント（たとえば、ＡｄｖＩｎｓｅｒｔＥｖｅｎｔ）は、通知がスペース内に挿入されたときに生成される。イベントについては以下で詳述する。通知は、３に示されているように、アーカイブされ、永続的にされ、これにより、通知が永続的アーカイブ状態に遷移する。通知はさらに、４に示されているように、永続的アーカイブ状態からパブリッシュすることもできる。通知は、スペースから除去され、５に示されているように、ドラフト状態に遷移し戻される。イベント（たとえば、ＡｄｖＲｅｍｏｖｅＥｖｅｎｔ）は、通知が削除されたときに生成される。
【０１８６】
一実施形態では、アーカイブされた永続的状態は使用されない。この実施形態では、状態変化３および４も使用されない。この実施形態では、通知はドラフト状態またはパブリッシュ状態のいずれかである。
【０１８７】
スペース内に格納された通知は、バージョン（要素の場合もある）、作成日（属性の場合もある）、変更日（属性の場合もある）、実装サービスＵＲＩ（要素の場合もある）、および／または永続的アーカイブ・サービスＵＲＩ（要素の場合もある）などの標準化された要素および／または属性を備える。
【０１８８】
スペース自体は通常サービスである。スペース・サービスは、スペース内の通知をサーチする機能を備え、これは、通知のタイプによるスペースのサーチを含む。スペース・サービスはさらに、通知を読み込み、通知を書き込み（パブリッシュする）、通知を取る（削除する）機能も提供することができる。スペースはさらに、スペース・イベント通知メッセージのサブスクライブを行う機能も備える。スペースには、位置によりスペース関係グラフをナビゲートする機能、通知要素の読み込み、書き込み、または取り出しの機能、通知属性の読み込み、書き込み、または取り出しの機能、および通知イベントの通知メッセージのサブスクライブの機能など、拡張機能を備えるものもある。スペースの機能については、以下で詳述する。スペースの機能は、スペース通知のメッセージ・スキーマで具現化される。メッセージ・スキーマ、スペース・アドレス、および認証証明書から、クライアント・メッセージ・ゲートを作成し、スペースとその機能にアクセスできる。
【０１８９】
スペースおよびスペース内のすべての通知は、ＵＲＩを使用してアドレス指定できる。一実施形態では、スペースおよび通知名は、ＵＲＬ命名規則に従う。いくつかの実施形態では、スペースのアドレス指定にＵＲＩ、たとえばＵＲＬを使用すると、インターネット全体からスペースにアクセス可能になる。スペース・メッセージ受取側（スペース・サービス）を指定するには、そのスペースについてサービス通知で受け取ったＵＲＩを使用する。ＵＲＩには、プロトコル、ホスト、ポート番号、および名前を含めることができる。プロトコルでは、クライアントとスペースの間でメッセージを移動するために使用できるプロトコルに名前を付ける（たとえば、信頼できるソケットまたは信頼できないソケット）。ホストおよびポート番号は、プロトコル依存のＩＤである。名前は、スペース名の後に通知、要素、および／または属性名を続けたものである。一実施形態では、パス名を使用して、スペース内の通知を識別することができる。パス名は絶対パスまたは相対パスのいずれかである。絶対パス名では、スペースだけでなく、通知も指定できる。相対パス名は、想定されるスペース内で指定通知に相対的である。一実施形態では、パス名の作成に適用されるシンタックスは、ＵＲＩ（統一リソース識別子）のシンタックスである。したがって、その実施形態では、通知およびスペース名はＵＲＩ予約語文字または一連の文字を含むことができない。要素および属性へのパス名も、ＵＲＩを使用して指定できる。一般に、要素名および属性名は、ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｓｐａｃｅｎａｍｅ／ａｄｖｅｒｔｉｓｅｍｅｎｔ／ｅｌｅｍｅｎｔ／ａｔｔｒｉｂｕｔｅなど通知のパス名に付加することができる。
【０１９０】
一実施形態では、分散コンピューティング環境は、クライアントがスペースのＵＲＩを発見できるようにするが、そのスペースに対するサービス通知へのアクセスを制限するメカニズムを備える。一実施形態では、完全通知をスペースに戻すのではなく、スペースのＵＲＩとスペースに対する認証サービスのＵＲＩを返す。クライアントは、スペース内で通知されたドキュメントまたはサービスにアクセスするために、まず、リターン・メッセージで与えられるＵＲＩで認証サービスに対し自己認証を実行する。認証サービスは、認証証明書を返し、これを使用して、クライアントはスペースに対する部分的または完全アクセスを実行できる。クライアントは、認証証明書を受け取ると、スペースに接続し、スペース内のドキュメントまたはサービス通知にアクセスしようとする。
【０１９１】
分散コンピューティング環境は、クライアントをスペースに接続できるようにするメカニズムを備える。接続メカニズムの実施形態は、クライアント−スペース・アドレス指定、クライアント承認、セキュリティ、リース、クライアント能力判別、およびクライアント−スペース接続管理に対応している。クライアント−スペース接続をセッションと呼ぶ。一実施形態では、セッションに一意的なセッション識別番号（セッションＩＤ）を割り当てることができる。セッションＩＤにより、クライアント−スペース接続を一意に識別することができる。一実施形態では、クライアントがリースを更新しない場合にセッション・リース・メカニズムを使用してセッションの透過的ガベージ・コレクションを実行する。
【０１９２】
一実施形態によるこのような接続メカニズムの使用例を以下に示す。クライアントは、認証証明書を取得する。一実施形態では、スペースでは、クライアントがスペースへのアクセスを要求したことに応答して行う認証サービスを提供する。クライアントは、認証サービスを通じて認証証明書を取得することができる。クライアントは、認証証明書を受け取ると、接続要求メッセージを送ることによりスペースとの接続を開始できる。一実施形態では、接続要求メッセージに、スペース・サービスのＵＲＩアドレス、クライアントの認証証明書、およびクライアントが要求している接続リースに関する情報を含めることができる。スペースは、接続要求メッセージを受け取った後、そのメッセージの妥当性を確認する。一実施形態はＸＭＬスキーマを使用してメッセージの妥当性を確認できる。クライアントは認証証明書を使用して認証を受けることができる。一実施形態では、接続要求メッセージで受け取った情報を使用してスペースを使用するクライアントの能力を判別することができる。一実施形態では、スペースの各クライアントにスペースを使用するそれぞれの能力の集まりを割り当てることができる。一実施形態では、スペースの１つまたは複数のクライアントに関する能力情報を含むアクセス制御リスト（ＡＣＬ）をクライアント能力判別で使用することができる。一実施形態では、接続要求メッセージで受け取った情報を使用してＡＣＬ内のクライアントの能力をルックアップすることができる。
【０１９３】
クライアントを認証し、クライアントの能力を判別した後、クライアントを許可する接続リースを判別できる。リースが判別された後、クライアント−スペース間接続を維持する構造を生成できる。接続に対するセッションＩＤを生成する。一実施形態では、各クライアント−スペース間接続に一意的セッションＩＤを割り当てる。一実施形態では、アクティブ化スペースを作成し、クライアント−スペース間セッションに割り当てるか、またはそれとは別に、既存のアクティブ化スペースをクライアント−スペース間セッションに割り当てることができる。一実施形態では、アクティブ化スペースを使用すると、スペースを使用したときにクライアントのサービスの結果を格納することができる。一実施形態では、クライアントの能力を使用して、アクティブ化スペースがクライアントに対し作成されるかどうかを判別する。たとえば、クライアントは、結果を格納し取り出すアクティブ化スペースにアクセスする能力を持たないことがある。１つまたは複数のメッセージをクライアントに送り、接続が確立されたことをクライアントに通知することができる。その１つまたは複数のメッセージに、セッションＩＤとリースに関する情報を入れることができる。その後、クライアントでは、それらに限定されないが、通知ルックアップ、通知登録、および通知取り出しなどのスペースを使用できる。一実施形態では、割り当てられたリースの有効期限が切れるか、またはクライアントがスペースにリース取り消しを要求するメッセージを送るまで接続は開いたままである。一実施形態では、クライアント側で、そのリースの有効期限が切れる前にそのリースを更新する必要がある。クライアントがリースを更新する前にリースの有効期限が切れた場合、接続は切断され、クライアントとスペースとの接続が途絶える。一実施形態では、再接続するには、クライアントは接続手順を繰り返す必要がある。
【０１９４】
一実施形態では、スペースのクライアントはスペースの通知をいくつかの異なる方法で取得することができる。クライアントがスペースの通知を取得する方法のうちいくつかを図１８に示す。たとえば、スペース発見プロトコルを分散コンピューティング環境の一部として提供することができる。スペース発見は、クライアントまたはサービスがスペースを見つけるために使用するプロトコルである。リスナー・エージェント２０２は、発見要求が来ないか監視するように１つまたは複数のスペースと関連付けて設定できる。発見リスナー・エージェント２０２は、さまざまなネットワーク・インターフェース上で待機し、スペースを探しているクライアント２００ａからブロードキャスト要求またはユニキャスト要求を（エージェントのＵＲＩで）受け取る。その後、リスナー・エージェント２０２は要求されたスペースのサービス通知に関してサービス通知またはＵＲＩで応答する。一実施形態では、リスナー・エージェントは、一般に、スペースから分離されているが、それは、その機能がスペース・サービスの機能と直交しているからである。ただし、リスナー・エージェントは、スペース・サービスと同じデバイスまたは異なるデバイスに実装することができる。
【０１９５】
一実施形態では、発見プロトコルはデフォルト・スペース内で通知されるサービスでよい。クライアントは、追加スペースを発見するためにクライアントのデフォルト・スペースから発見プロトコルをインスタンス化する。発見プロトコルは、クライアントのデフォルト・スペースに事前に登録できる。それとは別に、発見プロトコルは、たとえば、クライアントは発見サービスによって処理されるローカル・ネットワークに接続した時に、そのスペース内に通知を置くことによりデフォルト・スペースに自己登録することもできる。
【０１９６】
一実施形態では、スペース発見プロトコルを、ＳＬＰ、Ｊｉｎｉ、ＵＰｎＰなどの他のプラットフォーム用の基本デバイス発見プロトコルにマッピングすることができる。そこで、クライアントは分散コンピューティング環境の発見プロトコルを使用して他の環境内のサービスを見つける。これらの他の環境とのブリッジを用意し、それらの他の環境内のサービスに通知を送って、ここで説明した分散コンピューティング環境のクライアントがそれらにアクセスできるようにする。「ブリッジ」のセクションを参照のこと。
【０１９７】
通知される発見プロトコルごとに、分散コンピューティング環境では発見プロトコルの結果を保持するための後続結果スペースを作成することができる。一実施形態では、分散コンピューティング環境内のスペース・サービスはＭｕｌｔｉｃａｓｔ　Ａｎｎｏｕｎｃｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ（マルチキャストＵＤＰ）を使用してＬＡＮ上でアナウンスすることができる。リスナー・エージェントがこの情報を記録する。デバイス（クライアントまたはサービス）は、Ｍｕｌｔｉｃａｓｔ　Ｒｅｑｕｅｓｔ　Ｐｒｏｔｏｃｏｌ（マルチキャストＵＤＰ）を使用して、スペース・マネージャの発見を開始する。一実施形態では、スペース・マネージャは、それぞれのスペースのＵＲＩを示す情報で応答する。それとは別に、リスナー・エージェントは複数スペースについて応答することができる。発見応答は、さらに、各スペースにラベルを付ける短い文字列（たとえば、スペースのキーワードから取得する）と、たとえばそれぞれのスペースに対し操作を実行する各スペース・マネージャとのＴＣＰ接続を設定するために使用できる情報を含むことができる。要求側デバイスは複数のスペース・マネージャから応答（またはリスナー・エージェントから複数のスペース・リスティング）を受け取るので、この情報は、クライアントが接続先スペースを選択する場合に役立つ。
【０１９８】
上述のマルチキャスト発見に加えて、発見サービスではさらに、ネットワーク（たとえば、インターネット、他のＷＡＮ、ＬＡＮなど）上の既知のアドレスでスペース・マネージャを発見するために使用できるユニキャスト・メッセージング（たとえば、ＴＣＰで）を使用して発見を実行することもできる。ユニキャスト発見メッセージは、サービス通知を送るため既知のＵＲＩのスペース・サービスの要求を含むことができる。マルチキャスト発見プロトコルをおよびユニキャスト発見プロトコルは、メッセージ・レベルで定義され、そのため、発見に参加しているデバイスがＪａｖａをサポートしていようと他の特定の言語をサポートしていようと関係なく使用することができる。
【０１９９】
発見プロトコルを使用すると、分散コンピューティング環境内のクライアントをサポートするサーバ・コンテンツを拡散することとは独立にクライアントを拡散させることが容易にできる。たとえば、モバイル・クライアントは、その初期デフォルト・スペースをそのローカル・プラットフォームに組み込むことができる。デフォルト・スペースで通知されたローカル・サービスに加えて、モバイル・クライアントは、発見プロトコルにアクセスするためのサービスやスペースサーチ・エンジンにアクセスするためのサービスなど、追加スペースをサーチするサービスを備えることができる。
【０２００】
一実施形態では、分散コンピューティング環境のスペース発見プロトコルは、一組のＸＭＬメッセージとその応答を定義し、クライアントが以下のことを行えるようにする。
・　ネットワーク・インターフェース上でプロトコル定義スペース発見メッセージをブロードキャストする。
・　リスナーから、それらのリスナーが表す候補スペースを記述するＸＭＬメッセージを受け取る。
・　クライアントが選択されたスペースのアドレスを知らなくても、発見されたスペースの１つをデフォルトとして選択する。
・　そのアドレスなど選択されたスペースに関する情報を取得し、クライアントが後で発見プロトコルの外部の手段により同じスペースを見つけることができるようにする（これは、後でクライアントがローカルでなくなったがまだクライアントに関わっているスペースにアクセスする場合に役立つ）。
【０２０１】
いくつかの実施形態では、マルチキャストおよびユニキャスト発見プロトコルはＩＰネットワークを必要とする。これらの発見プロトコルは、ＩＰネットワーク対応のデバイスの必要条件を満たすが、これらの発見プロトコルで直接サポートされないデバイスも多くある。分散コンピューティング環境でスペースの発見にこのようなデバイスの要求条件を満たすには、事前発見プロトコルを使用してＩＰネットワーク対応のエージェントを見つける。事前発見プロトコルは、ネットワーク・エージェントを要求する非ＩＰネットワーク・インターフェース上でメッセージを送るデバイスを含むことができる。ネットワーク・エージェントは、それ自身とデバイスとの間の接続を設定する。デバイスとエージェントの間の接続が設定されると、エージェントはこれがエージェントとして使用されるデバイスのためにＩＰネットワーク上で発見プロトコルに参加する。ネットワーク・エージェントは、さらに、一般に分散コンピューティング環境にデバイスを接続するためのインターフェースとなる。たとえば、発見されたスペース内で通知されるサービスを実行するためにデバイスのためにエージェント内にゲートを構築することができる。「ブリッジ」のセクションを参照されたい。
【０２０２】
クライアントが分散コンピューティング環境でスペースを特定するための方法としては他に、他のスペース内でスペースを通知する方法がある。スペースはサービスなので、他のサービスと同様、他のスペース内で通知を受けることができる。図１８に示されているように、クライアント２００ｂは、第２のスペース２０４ｂについて第１のスペース２０４ａ内で通知２０６を見つける。スペース２０４ｂは、次に、追加スペースへの通知を含む。サービス（スペースを実装する）はさらにクライアントとしても機能するため、スペースは通知を交換するかまたは一緒に連鎖し、図１９に示されているように、ベースの連合を実現する。分散コンピューティング環境にはスペースをいくつでも含めることができる。スペースの個数とトポロジは、実装に依存する。たとえば、ＩＰネットワーク上に実装されたスペースは、それぞれ異なるサブネットに対応していることがある。
【０２０３】
クライアントでスペースを特定する第３の方法として、図１８に示されているように、サービス２０８を実行する方法がある。サービス２０８は、実行され、その結果としてスペース・サービスのサービス通知を返す。サービス通知はＸＭＬ文書であり、分散コンピューティング環境はインターネットを含むため、サービス２０８はＷｅｂベースのサーチ・ツールとすることができる。このようなサービスの一例として、図４で説明しているスペース・ルックアップ・サービスがある。一実施形態では、分散コンピューティング環境内のスペースはＷｅｂページとして実装することができる。それぞれのＷｅｂページ・ベースは、Ｗｅｂページを分散コンピューティング環境内のスペースとして識別するためにサーチできるキーワードを含むことができる。スペースは、その他のサーチ可能なキーワードを含むだけでなく、さらにスペースを定義することができる。クライアントは、サーチ・サービス２０８に接続し、キーワードをＸＭＬメッセージの形式でサーチ・サービスに供給する。サーチ・サービスは、クライアントからキーワードを受け取りそのキーワードをインターネットサーチ・エンジンに送るが、これは従来のサーチ・エンジンまたはサードパーティ製のサーチ・エンジンでもよい。サーチ・サービスは、ＸＭＬメッセージとして直接にまたは結果スペースへの参照によりインターネットサーチ・エンジンからクライアントに結果を返す。結果は、サーチ要求とマッチするスペースのＵＲＩである。それとは別に、サーチ・サービスは、サーチによって識別されたスペースにコンタクトし、このようなそれぞれのスペースについてサービス通知を取得し、ＸＭＬメッセージとして直接に、または結果スペースでの参照により、スペース・サービス通知をクライアントに返すことができる。クライアントは、その後、サーチ結果からスペースを選択し、ゲート（それ自身によりまたはプロキシを通じて）を構築し、選択したスペースにアクセスすることができる。選択されたスペースにアクセスした後、クライアントはそのスペース内のサービス通知をルックアップし、これによりスペースが追加される。
【０２０４】
上述のように、スペースはＸＭＬペースのＷｅｂサイトとすることができ、そのため、インターネットＷｅｂ上でサーチ・メカニズムによりサーチすることができる。スペースはインターネットサーチ可能キーワードを含むことができる。小型クライアント・デバイスなどいくつかのデバイスでは、インターネット・ブラウザをサポートしていない。ただし、このようなデバイスであっても、分散コンピューティング環境内でスペースについてインターネット・サーチを実行することができる。デバイスは、キーワードの列を受け付けるプログラムを備え、これらのキーワードはサーバ上のプロキシ・プログラムに送られる（たとえば、サーチ・サービス）。プロキシは、これらのキーワード列をブラウザ・ベースのサーチ機能に送り（たとえば、インターネットサーチ機能）、サーチを実行することができる。プロキシは、サーチの出力を受け取ってサーチ結果の各ＵＲＩを表す文字列（たとえば、ＸＭＬ文字列）に解析し、応答文字列をクライアントに送り返す。したがって、クライアントは、Ｗｅｂブラウザなどのプログラムをサポートしていなくてもインターネットを介してスペースを特定することができる。さらに高機能のデバイスでは、プロキシの使用を避けて、インターネット・ベースのルックアップ・サービスを直接開始することができる。
【０２０５】
クライアントはスペースを特定するための第４の方法は、新規作成された空のスペースまたは既存のスペースが生成されるときには生成されたスペースに関する情報を取得または受け取る方法である。既存のスペースは、生成元のスペースと同じ機能（たとえば、同じＸＭＬスキーマ）を持つ空のスペースを生成するインターフェースを備えることができる。スペースの生成については以下で詳述する。
【０２０６】
スペースのクライアントはスペース・サービスの通知を見つけると、スペースのそのクライアントは他のサービスの場合と同様にスペース・サービスを実行できる。スペース・サービスのクライアントは別のサービスでもよいことに注意されたい（たとえば、スペース内で通知すること求めるサービス）。一実施形態では、図２０に示されているように、スペース・サービスを実行するため、スペースのクライアントはまずスペースに対し認証サービスを実行し、３００に示されているように、認証証明書を取得する。認証サービスは、スペース・サービスのサービスを通知で指定することができる。スペースのクライアントは、３０２に示されているように、認証証明書、スペースのＸＭＬスキーマ（スペースのサービス通知からの）、およびスペースのＵＲＩ（スペースのサービス通知からの）を使用して、スペースのゲートを構築する。次に、スペースのクライアントは、そのゲートを使用してメッセージをスペース・サービスに送ることによりスペース・サービスを実行する。第１のそのようなメッセージは３０４に示されている。
【０２０７】
認証を採用する実施形態では、スペース・サービスがクライアントから第１のメッセージを認証証明書が埋め込まれた状態で受け取ったときに、スペース・サービスは同じ認証サービス（スペース・サービスのサービス通知で指定されている）を使用して、クライアントを認証し、３０６で示されているように、その素性を確定する。スペース・サービスは、クライアントの能力を判別し、３０８で示されているように、クライアントを認証証明書にバインドする。
【０２０８】
３１０に示されているように、スペースのクライアントは、メッセージをスペース・サービスに送ることによりさまざまなスペース機能を実行することができる。一実施形態では、スペースのクライアントがスペース・サービスに要求を送るときに、クライアントはその要求で認証証明証を渡し、スペース・サービスがクライアントの特定の能力について要求をチェックできるようにする。
【０２０９】
各スペースは、通常、サービスであり、スペース・サービスのコア機能を定義するＸＭＬスキーマを備える場合がある。ＸＭＬスキーマでは、スペース・サービスとのクライアント・インターフェースを指定する。一実施形態では、すべてのスペース・サービスは、基本レベルのスペース関係のメッセージを出すことができる。基本レベルのスペース機能は、ＰＤＡなどの小型デバイスをはじめとするほとんどのクライアントで使用できる基本的なスペース機能である。たとえば、より高機能なクライアントについては、機能を増やすことが望ましい場合がある。基本レベルのスペースの拡張は、スペースを通知するＸＭＬスキーマにさらにメッセージを追加することにより実現できる。たとえば、一実施形態では、基本レベルのメッセージは、通知に対して関係グラフを強制しない。たとえば、通知の階層をトラバースするメッセージはスペース拡張である。このような追加機能は、スペースの１つまたは複数の拡張をＸＭＬスペース・スキーマまたはスキーマ拡張を通じて提供することができる。拡張されたスキーマは、基本スキーマを含むので、拡張スペースのクライアントもまた、基本スペースとしてスペースにアクセスすることができる。
【０２１０】
一実施形態では、基本スペース・サービスは、ＸＭＬドキュメントの一時的リポジトリを備える（たとえば、サービスの通知、実行中サービスの結果）。ただし、一実施形態の基本スペース・サービスは、スペース・コンテンツの永続性、スペース構造（たとえば、階層）のナビゲーションまたは作成、およびトランザクション・モデルをサポートする高度な機能に対応していない場合がある。永続性、階層、および／またはトランザクションをサポートするメカニズムは、ＸＭＬスキーマを拡張することによって実現される。拡張されたスペースはそれでも基本ＸＭＬスキーマを含むので、必要なのが、あるいはサポートできるのが基本スペースの機能だけの場合に、クライアントは拡張スペースを基本スペースとして取り扱うことができる。
【０２１１】
一実施形態では、基本スペースは一時的なものとすることができる。基本スペースは、さまざまな目的のために受け入れることができる。サービス・プロバイダは、さまざまなスペースでサービスを登録することができる。一実施形態では、サービスはスペース内の情報のパブリッシュ後継続的にリースを更新する必要がある。このような性質があることから、サービス通知は、多くの場合に再構築かつ／または再確認するという点で一時的なものである。ただし、スペース内に何らかの永続性を実現することが望ましい。たとえば、結果があるスペースは、一定期間結果が失われないようにしたいユーザに対しては何らかの永続性を提供できる。一実施形態では、クライアントが永続的ストアによって裏付けられているスペース内のオブジェクトを制御し、その永続性ストアのメンテナンスを管理することができるスペース・インターフェースを指定することにより永続性を実現することができる。永続性インターフェースは、永続性に関してインターフェースを定義するスペースの拡張ＸＭＬスキーマで指定することができる。
【０２１２】
一実施形態では、基本スペースは、ＸＭＬドキュメントがスペースに追加され、文字列によって識別できるインターフェースを備える。基本スペースは、スペース内のさまざまな名前をつけられたＸＭＬドキュメントの階層を実現することはできない。階層のサポートが望ましい実施形態では、ユーザが階層を指定することができる追加インターフェースを定義するとよい（ＸＭＬスキーマを拡張する）。階層をナビゲートしたり、関係グラフを位置でナビゲートするように他のインターフェースを指定することもできる。ただし、他のユーザはそれでも、基本スペース・インターフェースを使用して、階層を使わずに、同じドキュメントにアクセスすることができる。拡張スペース・スキーマでは、他のスペースの構造に対するインターフェースも実現できる。
【０２１３】
拡張ＸＭＬスペース・インターフェースもまた、スペース・トランザクション・モデルについて実現することができる。たとえば、拡張スペースＸＭＬスキーマがＡＣＩＤトランザクションのインターフェースを指定する。ＡＣＩＤは、エンタプライズ・レベルのトランザクションの４つの特性を記述するために使用される頭字語である。ＡＣＩＤは、Ａｔｏｍｉｃｉｔｙ（原子性）、Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）、Ｉｓｏｌａｔｉｏｎ（独立性）、およびＤｕｒａｂｉｌｉｔｙ（耐久性）のそれぞれの頭文字をとったものである。原子性とは、トランザクションを完全に完了するか、または元に戻すかのいずれかであることを意味する。障害が発生した場合、すべての操作およびプロシージャを元に戻し、すべてのデータを前の状態にロールバックする必要がある。一貫性とは、トランザクションがシステムを一方の一貫性のある状態から他方の一貫性のある状態に変換することを意味する。独立性とは、各トランザクションが同時に発生する他のトランザクションとは独立に発生することを意味する。耐久性とは、完了したトランザクションが、たとえばシステムに障害が発生したときでも、内容を失うことなく恒久的であるということを意味する。他のトランザクション・モデルはさらに、拡張スペース・スキーマで指定することができる。
【０２１４】
拡張スペース・スキーマは、拡張されたスペースの特徴、機能性、または機能を使用するためのメッセージ・インターフェース（たとえば、ＸＭＬメッセージ）を指定するＸＭＬドキュメントとすることができる。スペースには、基本スキーマおよび複数のを拡張スキーマを用意できる。これにより、クライアントの認証に応じて、異なるレベルのサービスを異なるクライアントに簡単に提供することができる。
【０２１５】
スペースの永続性、構造、およびトランザクションの拡張のほかに、必要に応じて、他のスペース拡張機能も指定できる。たとえば、通知要素の読み込み、書き込み、または取り出しの機能、通知属性の読み込み、書き込み、または取り出しの機能、および通知イベントの通知メッセージのサブスクライブの機能など、要素または属性のレベルで通知を操作するための拡張機能を備えることもできる。スペースは仮想的にいくつの機能でも提供でき、必要に応じて、基本スキーマおよび拡張スキーマに配列することができる。一実施形態では、すべての基本スペースは通知の読み込み、書き出し、取り込み、およびルックアップの機能、さらにスペース・イベント・サブスクライブの機能を備える必要がある。さまざまなスペース機能を用意できる。いくつかの実施形態では、スペースとのセッションを確立するための機能を備えることができる。このような実施形態では、スペース機能のうちの残りの機能は、これが完了するまでに利用できない。他の実施形態では、セッションという概念がないか、またはオプションであるか、および／または実装に依存する。
【０２１６】
他のスペース機能として、スペースにサービス通知を追加したり、スペースからサービス通知を削除する機能もある。さらに、ＸＭＬドキュメントを追加または削除するスペース機能も用意できる（通知ではなく、おそらくスペース内の結果）。スペース・サービスは、アイテムの追加を許可する前にアイテムの一意性を検査する。たとえば、スペースに追加される各アイテムは、アイテムを識別し、そのアイテムの一意性を検査するために使用できるユーザ指定の文字列と関連付けることができる。
【０２１７】
一実施形態では、クライアントはスペース内で通知されるすべてのサービスのリスティング、ツリー、またはその他の表現を要求することができる。ユーザは、その後、通知をスクロールまたは操縦して、目的のサービスを選択する。また、スペースはキーワードまたは文字列名を与えることによりクライアントがサービスをサーチできるようにするルックアップ機能も備える。一実施形態では、スペース機能は、スペースに追加されているスペース・エントリをルックアップするためのメカニズムを備える。ルックアップ機能は、名前とマッチする文字列、またはワイルドカード、またはデータベース・クエリでルックアップすることができる。ルックアップ機能は、クライアントが１つ選択できる、またはさらに絞り込みサーチを実行できる複数のエントリを返す。一実施形態では、ルックアップ機能は特定のＸＭＬスキーマとマッチするサービス通知を特定するためのメカニズムを備える。クライアントは、スペース内でサーチ対象となる、特定のＸＭＬスキーマ、または特定のＸＭＬの一部を指定することができる。したがって、インターフェース機能に従ってスペース内でサービスをサーチすることができる。
【０２１８】
分散コンピューティング環境で提供できるスペース機能としては他に、サービスおよびクライアントがＸＭＬなどの型付けモデルに基づき一時的ドキュメントを見つけられるメカニズムがある。このメカニズムは、汎用の型付けドキュメント・ルックアップ・メカニズムである。一実施形態では、このルックアップ・メカニズムはＸＭＬに基づく。このルックアップ・メカニズムを使用すると、クライアントおよびサービスは、サービス通知を介したサービスを含めて、一般にドキュメントを見つけることができる。
【０２１９】
一実施形態では、スペース・ルックアップおよび応答メッセージのペアを使用することにより、クライアントおよびサービスがネットワーク一時ドキュメント・ストア（スペース）内に格納されているＸＭＬドキュメントを見つけられるようにできる。スペースは、さまざまなドキュメントを格納するために使用されるドキュメント・スペースである。一実施形態では、ドキュメントはＸＭＬドキュメントまたはＸＭＬでカプセル化された非ＸＭＬドキュメントである。スペースについては他のところでさらに詳述する。ルックアップ・メッセージは、サービス通知およびデバイス・ドライバ通知を含む、スペース内に格納されているあらゆる種類のＸＭＬドキュメント上で機能する。一実施形態では、クライアント（他のサービスでもよい）は別のところで説明しているように発見メカニズムを使用して、１つまたは複数のドキュメント・スペースを見つけることができる。その後、クライアントはスペース・ルックアップ・メッセージを使用して、スペース内に格納されているドキュメントを特定することができる。
【０２２０】
分散コンピューティング環境には、サービスおよびクライアントがＸＭＬドキュメントの発行に関するイベントのサブスクライブおよび受取を行うためのメカニズムが備えられる。イベントは、スペースなどの一時的ＸＭＬドキュメント・リポジトリにＸＭＬドキュメントをパブリッシュしたり、そこから除去したりする機能を含むことができる。一実施形態では、イベントは、他のＸＭＬドキュメントを参照するＸＭＬドキュメントである。
【０２２１】
一実施形態では、スペース・イベント・サブスクライブおよび応答メッセージのペアを使用することにより、クライアントおよびサービスがスペースに追加またはスペースから削除されるドキュメントに関するイベントのサブスクライブを行える。一実施形態では、他のところで説明しているリース・メカニズムを使用して、イベント・サブスクライブをリースすることができる。一実施形態では、リースが取り消されるかまたはその有効期限が切れたときにサブスクライブを取り消すことができる。一実施形態では、サブスクライブ上のリースを更新する際に、サブスクライブを更新できる。
【０２２２】
一実施形態では、イベント・サブスクライブ・メッセージに、ドキュメント・マッチング・メカニズムとして使用できるＸＭＬスキーマを含めることができる。スキーマとマッチするドキュメントはサブスクライブによって取り扱われる。一実施形態では、スペースに追加され、ＸＭＬスキーマとマッチするドキュメントは、スペース・イベント・メッセージを生成する。
【０２２３】
また、スペースに何かを追加したときやスペースから何かを削除したときにその通知を取得するためクライアントが登録できる（または登録解除できる）スペース機能を提供することができる。スペースは一時的コンテンツを格納することができ、これはスペースに追加されたまたはスペースから削除されたサービスを反映する。たとえば、サービスが利用できるようになったときまたは利用できなくなったときにそのことをクライアントに通知するメカニズムを用意することができる。クライアントは、このような通知を取得するためイベント・サービスに登録することができる。一実施形態では、クライアントは指定された文字列とマッチする名前または指定されたスキーマ（またはスキーマ部分）とマッチするスキーマを持つサービスをスペースに追加したりスペースから削除したりするときにそのことを通知するように登録することができる。したがって、スペース・イベント通知機能に登録するクエリは、上述のサービス・ルックアップ機能のものと同じであるか類似している。
【０２２４】
イベントは型付けされる。いくつかの実施形態では、スペースによってサポートされるイベント機能を使用すると、イベント・リスナーがたとえば、Ｊａｖａクラス（またはＸＭＬの型）階層を利用することができる。たとえば、ＡｄｖＥｌｅｍｅｎｔＥｖｅｎｔが発生するのを待つことで、リスナーは型ＡｄｖＥｌｅｍｅｎｔＥｖｅｎｔおよびそのサブクラス（ＸＭＬ型）のすべてのイベントを受け取る。したがって、この例では、要素変更に関係するすべてのイベントは（通知の挿入および削除はないが）、受取される。
【０２２５】
他の例では、トップレベルのイベント・クラスまたは型、たとえば、ＳｐａｃｅＥｖｅｎｔのサブスクライブまたは待機する際に、すべてのスペース・イベントが受取される。イベント・クラスの型は、たとえば、Ｊａｖａのｉｎｓｔａｎｃｅ　ｏｆ演算子またはＸＭＬ型付けシステムを介して区別することができる。
【０２２６】
イベントには、影響を受ける通知または要素へのＵＲＩが含まれる。たとえば、ＡｄｖｅｒｔｉｓｅｍｅｎｔＥｖｅｎｔおよびそのすべてのサブクラスは影響を受ける通知への参照（たとえば、ＵＲＩまたはＵＲＬ）を含む。ＡｄｖＥｌｅｍｅｎｔＥｖｅｎｔおよびそのサブクラスは、影響を受ける要素の名前について調査することができる。たとえば、前の要素値（ＵＲＩまたはＵＲＬ）は、ＡｄｖＥｌｅｍｅｎｔＲｅｍｏｖｅＥｖｅｎｔおよびＡｄｖＥｌｅｍｅｎｔＶａｌｕｅＣｈａｎｇｅＥｖｅｎｔから利用することができる。
【０２２７】
一実施形態のスペース・イベントの型階層を図２１に示した。型は、ＸＭＬで定義し、ＪａｖａやＣ＋＋などの他の適当なオブジェクト指向言語で使用することができる。
【０２２８】
スペースは、クライアントがスペース内で通知されたサービスをインスタンス化する機能を備える。サービスのインスタンス化は、クライアントがサービスを実行できるよう行われる初期化である。サービスのインスタンス化の一実施形態を図２２に示す。サービスをインスタンス化するために、クライアントはまず、３２０で示されているように、スペース内でパブリッシュされたサービス通知のうちから１つ選択する。クライアントは、スペースに用意されているルックアップ機能などのさまざまな機能を使用して、スペース内のさまざまな通知をルックアップすることができる。次に、クライアントは、３２２に示されているように、スペースに対しサービスのインスタンス化を要求する。
【０２２９】
一実施形態では、サービス・インスタンス化は、以下の操作を含む。クライアントがスペース・サービスに対し選択されたサービスのインスタンス化を要求した後、３２２に示されているように、スペース・サービスは、３２４に示されているように、クライアントが要求されたサービスをインスタンス化できることを確認する。スペース・サービスは、クライアントのメッセージに含まれる認証証明書を調べることによりこの確認を実行する。認証証明書は、スペース・サービスとのセッションを確立したときにクライアントが受け取る証明書である。スペース・サービスは、クライアントがそのクライアントに指示されているクライアントの認証証明書および能力に応じて要求されたサービスをインスタンス化できるかどうかを検証する。以下の「認証とセキュリティ」の項を参照のこと。
【０２３０】
クライアントが承認されていると仮定すると、スペース・サービスはさらに、３２６に示されているように、クライアントによって指定されているリース要求時間でクライアントに対するサービス通知のリースを取得することができる。リースについては以下で詳述する。スペース・サービスは、３２８に示されているように、割り当てられたリースとサービスのサービス通知を含むメッセージをクライアントに送る。一実施形態では、クライアントはサービス通知で指定された認証サービスを実行し、３３０で示されているように、認証証明書を取得する。認証サービスの詳細については、「認証とセキュリティ」の項を参照のこと。次に、３３２で示されているように、クライアントはサービスのためにゲートを構築する（たとえば、認証証明書と通知からのＸＭＬスキーマおよびサービスＵＲＩを使用する）。「ゲート」の項を参照のこと。クライアントとスペース・サービスとの上述の通信は、分散コンピューティング環境のＸＭＬメッセージングを使用して実行される。その後、クライアントは、構築されたゲートとＸＭＬメッセージングを使用してサービスを実行する。サービスは、同様に、ＸＭＬメッセージによるクライアントとの通信用にサービス・ゲートを構築する。
【０２３１】
まとめとして、スペースの使用例を以下で説明する。クライアントは、スペース・サービスにアクセス（たとえば、接続）することができる。（サービスは、スペースにアクセスするかまたはその他の方法でスペースを使用するためにクライアントとして機能する。）スペース・サービスは、１つまたは複数のサービス通知および／またはその他のコンテンツス・ペース内に格納し、サービス通知のそれぞれが、対応するサービスにアクセスし、実行するために使用できる情報含む。スペース・サービスは、スペース・サービスの機能を呼び出すために使用できる１つまたは複数のメッセージを指定するスキーマを備えることができる。たとえば、スキーマはスペースから通知を読み込み、スペース内で通知をパブリッシュするメソッドを指定できる。スキーマおよびサービス通知は、拡張可能マークアップ言語（ＸＭＬ）などのオブジェクトを表現言語で表すことができる。スペース・サービスにアクセスする場合、クライアントはＸＭＬメッセージ（スキーマで指定されている）などの情報をインターネット・アドレスにあるスペース・サービスに送る。スペース・サービスにアクセスする際に、クライアントはスペースに格納されている１つまたは複数のをサービス通知をサーチする。クライアントは、スペースからサービス通知の１つを選択できる。一実施形態では、クライアントは、スペースから目的のサービス通知を選択した後インスタンス化要求をスペースに送る。目的のサービスに対するリースを取得し、リースおよびスペース・サービスによって、選択されたサービス通知をクライアントに送る。その後、クライアントは目的のサービスに対するアクセスのためのゲートを構築する。目的のサービスをクライアントのために実行できる。
【０２３２】
スペース・サービスによって提供される機能としてはほかに、空のスペースの生成または作成の機能がある。このスペース機能を使用する際に、クライアント（他のクライアントへのサービスであってもよい）は新しいスペースを動的に作成することができる。一実施形態では、このスペース機能は、生成元のスペースと同じ機能（同じＸＭＬスキーマまたは拡張スキーマ）を持つ空のスペースを生成するインターフェースを備えることができる。この機能は、結果に対しスペースを（たとえば、動的に）生成する場合に使用できる。たとえば、クライアントは、サービスで結果を生成されたスペースに置くかまたは結果を生成されたスペースで通知するよう要求するスペースを生成することができる。クライアントは、生成されたスペースのＵＲＩおよび／または認証証明書をサービスに渡す。または、サービスは、結果に対しスペースを生成し、生成されたスペースのＵＲＩおよび／または認証証明書をクライアントに渡す。いくつかの実施形態では、スペースがいったん生成されると、他のスペースと同様に、ここで説明したスペースを発見メカニズムのうち１つまたは複数を使用して発見することができる。
【０２３３】
他のスペース内のインターフェースを介してスペースを作成するメカニズム（たとえば、スペース生成機能）を使用して、新しいスペースを効率よく作成することができる。たとえば、一実施形態では、格納用の元のスペースで使用しているのと同じ機能を使用して、生成されたスペース用の記憶域を割り当てることができる。また、生成されたスペースは共通サービス機能を元の（または親の）スペースと共有することができる。たとえば、新しいＵＲＩを新しいスペースに割り当てることができる。一実施形態では、新しいＵＲＩは元のスペースと共有される共通スペース機能へのリダイレクションとすることができる。したがって、新しく生成されたスペースは元のスペースと同じサービス・コードまたはその一部を使用することができる。
【０２３４】
スペース機能はさらに、たとえば、スペースのさまざまなセキュリティ・ポリシーおよびその他の管理機能を更新するためのセキュリティ管理機能を備える。たとえば、通知の個数および経過時間を、ルート・スペース・サービスにより制御し監視することができる。旧い通知を収集して処分することができる。たとえば、通知を旧いとみなすことができる場合については「リース」の項を参照のこと。スペースを実装するサービスは管理者の制御の下にある。管理者は、サービスに依存する形でポリシーを設定することができる。スペースで機能はさらに、空のスペースを削除する機能を備える。いくつかのスペースでは、モバイル・クライアントなどのある種のクライアントの拡散をさらにサポートする機能またはサービスを備えることができる。たとえば、モバイル・クライアントが発見プロトコルなどにより発見できるスペース内のサービスは、モバイル・クライアントに対し次のようにサポートする
・　クライアントに対し一時的ネットワーク・アドレスを割り当て管理する。
・　クライアントに対しメッセージ通信をプロキシに通す。
・　追加スペースに対しサーチ機能を用意する。たとえば、サービスにより、クライアントは単純なインターフェースを介してキーワードを指定することができる。その後サービスは、ここで詳述しているように、Ｗｅｂサーチ・エンジンでそのキーワードを使用して、Ｗｅｂ上でスペースをサーチする。他の実施形態では、サーチ・サービスは、クライアントを分散コンピューティング環境内でごく少数のサポートされているスペースをサーチすることに制約する。
【０２３５】
前に述べたように（図９および付属の文章を参照）、スペースはクライアントによって実行されるサービスからの結果を格納する便利なメカニズムを提供する。結果にスペースを使用する際に、小型クライアントはサービスを実行した結果をバラバラにして受け取ることができる。いくつかのサービスでは、大量の結果が生成されることがある。スペースを使用してサービスからな結果を格納することにより、一度に全部の結果を受け取るだけのリソースがないクライアントでもそのサービスを使用することができる。さらに、スペースを使用して結果を格納することにより、大量の結果が返されるときに高速な使用中サーバ上で実行されているサービスを低速なクライアントとの直接的な対話操作から解放することができる。したがって、サービスをすぐに解放することができ、他のクライアントで使用できる。
【０２３６】
スペースは、異なるクライアントにより、かつ／または異なるときに、結果にアクセスするための便利なメカニズムを備える。たとえば、クライアントは結果をまるごとは使用できない場合があるが、ユーザはその結果にアクセスできる他のクライアントを後で使用してその結果の残り部分にアクセスすることを望む。たとえば、結果には、株式市況や、現在の株価の表示（ＰＤＡからアクセス可能）、および株価チャートの表示（後でラップトップからアクセス可能）などがある。また、結果に対し分散コンピューティング環境でスペースを使用すると、クライアントは一方のサービスの結果を他方のサービスに供給することができ、しかも、結果を最初にダウンロードする必要がない。たとえば、上の株式市況の場合、ＰＤＡはチャートを他のサービスに送り、そこでチャートを印刷することができ、ＰＤＡでチャート自体をダウンロードする必要はない。したがって、結果スペースは、クライアントが結果を処理または受け取らずに、他のクライアントまたはサービスに渡すためのメカニズムを提供する。
【０２３７】
異なる実施形態では、結果に対しスペースを使用する決定は、サービスによって命じられるか、クライアントによって命じられるか、および／またはクライアントによって要求される。サービスは、たとえば、その通知で、結果に対しスペースを使用することを提案することがある。一実施形態では、クライアントまたはサービスのいずれかが結果に対する新しいスペースを生成するか、または結果に対し既存のスペースを使用することができる。スペースの生成に関する説明を参照のこと。
【０２３８】
一実施形態では、結果に対しスペースを使用しても、必ずしも、サービスがすべての結果をそのスペースに入れる必要があるわけではない。サービスが生成する結果に対し代替えもありうる。たとえば、結果の一部または全部をメッセージによりインラインでクライアントに送ることができる。それとは別に、結果をスペースに入れ、その後、通知メッセージをクライアントに送り、結果を参照するようにできる（たとえば、結果へのＵＲＩや結果の通知へのＵＲＩを含める）。他のオプションとして、結果をスペースに入れ、スペースからのイベントにより通知を送る方法もある。たとえば、クライアントおよびサービスは何らかの特定の名前で結果を呼び出し、クライアントはそのように名前を付けられた結果をスペースに追加するときにイベントを受け取るため（上記のものなどのスペース機能を使用して）スペースに登録することができる。イベント通知に関する上の説明を参照のこと。
【０２３９】
したがって、サービスが結果をクライアントに返すいくつかの異なるメカニズムを分散コンピューティング環境内で使用することができる。実際の結果をＸＭＬメッセージ内の値でクライアントに返すか、または結果をスペースに置かれている実際の値（または、実際の結果に対する通知）による参照でクライアントに返され、クライアントはスペース内の結果を参照しているメッセージを受け取る。さらに、結果または結果通知をスペース内に置き、イベントでクライアントに通知できる。
【０２４０】
結果を処理する他のメカニズムでは、クライアントが供給する結果に対し他のサービスを指定する。たとえば、クライアントは、結果を出力するサービスを実行する場合、そのサービスに（たとえば、ＸＭＬメッセージングを介して）、結果を他のサービスに送ってさらに処理するよう指示することができる。これには、他のサービスを実行して結果を渡すために、クライアントが他のサービスに通知のＵＲＩを指示し、結果出力サービスが他のサービスへのゲートを生成するようにする必要がある。この例では、結果出力サービスは他のサービスのクライアントでよい。いくつかの実施形態では、クライアントはスキーマまたは事前構築されたゲートを結果出力サービスに送り、サービスにアクセスしてさらに処理する。さらに処理するサービスの例として、元のクライアントの結果を表示することができる表示サービスがある。この表示サービスは、クライアントと同じデバイスにあるか、またはそのようなデバイスと関連付けられる。
【０２４１】
結果スペースおよびメソッド・ゲートにより、分散コンピューティング環境では、メモリが最低限しかなく、帯域幅の非常に狭い、シン・クライアントにとって実用的な単純なリモート・メソッド呼び出しを提供することができるが、それは、従来のリモート・メソッドを呼び出し手法のように巨大なプログラム・オブジェクトが（必要なクラスとともに）ネットワーク上で（必ず）クライアントに返される困った副作用がないからである。その代わり、結果は、結果スペースに返すことができ、必要な場合のみ（そして、クライアントに常駐できる場合）、クライアントにダウンロードされる実際のオブジェクトである。
【０２４２】
分散コンピューティング環境がリモート・メソッドを呼び出すため備えているメカニズムは以下のとおりである（「ゲート」の項のメソッド・ゲートの説明も参照のこと）。スペース内でオブジェクトを通知することができる（たとえば、サービスとして、またはサービスの一部として）。通知は、オブジェクトのＵＲＩ（たとえば、ＵＲＬ）をセキュリティ証明書およびＸＭＬスキーマなどの他のアクセス・パラメータとともに含む参照を含む。クライアントは、オブジェクトに対しクライアント・メソッド・ゲートを設定しているか、または構築し、これは、オブジェクト（またはサービス）自体のすべてのメソッドについて、メソッド・パラメータを取り、要求ＸＭＬメッセージを作成してオブジェクトのメソッドを呼び出すラッパー・メソッドを備える。ＸＭＬメッセージは、サービス・オブジェクト上で実際のメソッドを呼び出すサービス・ゲートに送られる。そのメソッドが結果オブジェクトを返すと、サービス・ゲートは結果オブジェクトを結果スペース内にポストし、メッセージを結果オブジェクトへの参照とともにクライアントに返す。
【０２４３】
したがって、クライアントがリモートメソッドを呼び出すためには、クライアントはまず、上述のように、オブジェクト（たとえば、サービス）をインスタンス化するメッセージを送る。一実施形態では、オブジェクトのインスタンス化を行うには、結果スペースを作成するかまたは生成する。他の実施形態では、結果スペースの作成は、オブジェクトのインスタンス化とは別である。インスタンス化により、オブジェクトＵＲＩがクライアントに返され、クライアントとサービス・ゲートは、クライアントはインスタンス化を要求したときに動的に作成される。いくつかの実施形態では、結果スペースはすでに存在しており、オブジェクト（サービス）によって通知される。これらのゲートの一部または全部も事前に構築されるかまたは再利用されている。
【０２４４】
クライアントがオブジェクトをインスタンス化した後、適切なクライアント・メソッド・ゲートをローカルで呼び出すと、上述のように、実際のリモート・オブジェクトへのリモート・コールが影響を受ける。分散コンピューティング環境のリモート・メソッド呼び出しの方式は再帰的であり、クライアント・ゲートが呼び出されると、オブジェクト自体ではなく、オブジェクト参照がクライアントに返される。このような返されたオブジェクトはすでにインスタンス化されていることに注意されたい。いくつかの実施形態では、クライアント側は、リモートで呼び出すだけでなく、オブジェクト自体を丸ごとダウンロードする決定を下す。
【０２４５】
上述のように呼び出されたメソッドまたはサービスは、結果ドキュメントと関連付けられている子ゲートを生成する。メソッドは、参照自体ではなく、参照の子ゲート（またはクライアントが子ゲートを構築するためのスキーマ、ＵＲＩおよび証明書）を返す。その後、クライアントは、子ゲートを通じて参照にアクセスすることができる。子ゲートは、メソッド・ゲートでもよい。
【０２４６】
上述のように、分散コンピューティング環境で提供されるこのリモート・メソッド呼び出しにより、実際の結果オブジェクトを、サービス結果スペース内に格納できる（これは、たとえば、サーブレットにより動的に作成できる）。結果スペースは一時的である。結果スペースは、クエリ結果キャッシュとして機能することができる。古い結果領域をクリーンアップするサーバ・ソフトウェア（ガベージ・コレクタ）が結果キャッシュ内を巡回する。分散ガベージ・コレクションを採用するが、それは、クライアントがスペースを必要としなくなったことを示すか、またはサーバの管理者が適切な制限値を設定することにより、破棄されるまで結果スペースが満たされるからである。
【０２４７】
図２３に戻ると、デフォルトのスペース３５０の図が示されている。分散コンピューティング環境は、少なくとも１つのデフォルト・スペースを用意し、クライアントは通知の初期セットを見つけられるようにする。デバイスは、事前構築されたゲートを組み込んだ、ローカルに存在するデフォルト・スペースを備えることができる。そのデフォルト・スペースで通知されたサービスは、ローカルでそのデバイスに存在し、デバイスが分散コンピューティング環境に参加するのを有効にするかまたは容易にするシステム・ソフトウェアを備える。
【０２４８】
デフォルト・スペース３５０は、図２３に示されているように、外部スペースを特定する１つまたは複数のメカニズム３５２を備える。デフォルト・スペース内の１つのサービスが、上述のスペース発見プロトコルを実行して外部スペースを見つけることができる。また、デフォルト・スペース内で外部スペースを通知することができる。さらに、外部スペースを決定するまたは見つけるデフォルト・スペース内でサービス（たとえば、サーチ・エンジンまたはサーチ・エンジンへのプロキシ・サーバ）を通知する。各スペースは、ファイル・システムのマウント・ポイントに似ている。したがって、分散コンピューティング環境はサービスに対しサーチ可能な動的マウント・ポイントを提供できる。デフォルト・スペースは、分散コンピューティング環境へのクライアントの初期マウント・ポイントである。
【０２４９】
デフォルト・スペースまたはデフォルト・スペースへのアクセス機能をデバイスに組み込むことができる。デバイスに存在するデフォルト・スペースおよびローカル・サービスを通じて、分散コンピューティング環境にクライアント実行環境を用意できる。デバイスのローカル・サービスおよびデフォルト・スペース・サービスは、事前構築ゲートを組み込んでいる。デフォルト・スペース内にリストされている組み込みサービスの１つは発見プロトコルを実行するサービスであり、クライアントは追加（たとえば、外部）スペースを特定することができる。デフォルト・スペースは、クライアント・ユーザがスペースを参照し、サービスを選択し、インスタンス化するために使用するクライアント用の実行環境を提供する組み込みサービスを備える。このようなサービスは、クライアントが文字列全体（たとえば、スペースサーチのためのキーワード）を操作する、結果参照（たとえば、スペースのリスティング、またはスペース内のサービス・リスティング）を表示または参照する、アイテム（たとえば、サービスを選択してインスタンス化するため）を選択するなどのための単純なユーザ・インターフェースを備える。
【０２５０】
主にサービスを提供するデバイスは、さらに、デフォルト・スペースも備え、サービスでさまざまなスペース内での自己通知を管理できるようにする組み込みサービスをデフォルト・スペースに備えることができる。たとえば、プリンタなどのデバイスは、ローカル・エリア・ネットワーク上でスペースを（たぶん、発見プロトコルを利用して）見つけ、プリンタ・サービスの通知をそのスペースに追加する組み込みデフォルト・サービスを備える。このサービスはさらに、たとえば、リースを更新したり、プリンタのＸＭＬスキーマを更新するなどして、ＬＡＮスペース内のプリンタ・サービス通知を維持することもできる。
【０２５１】
サービスを提供するいくつかのデバイスでは、サービスを通知し、その通知を維持するのにスペースを見つけるオーバーヘッドは望ましくない。一実施形態では、サービス通知をパブリッシュするために１つまたは複数のスペースをサーチし維持するのではなく、いくつかのデバイスのサービスが接続要求に対する応答としてそれらの通知を送る。たとえば、プリンタ・サービスを近接性ベースで利用できるプリンタ・デバイスは、スペース内で通知を維持しない（デバイスで、またはデバイスの外部で）。その代わり、他のデバイスがプリンタ・デバイスとの接続を確立すると（たとえば、クライアントを実行しているラップトップを所有するユーザがドキュメントを印刷しようとする）、プリンタ・サービスはサービス通知を送り、プリンタ・デバイスで印刷機能を提供するサービスに接続し、そのサービスを実行するＸＭＬサービス・スキーマを提供することができる。さらに、いくつかのデバイスではある近傍またはローカル・ネットワークでサービスに対する通知を維持するのみである。このようなデバイスでは、広範にアクセス性に関してトランスポートへのアクセスをサポートすることを望まない、またはアクセスできない場合がある。
【０２５２】
デバイスがスペース内でサービス通知を避けるまたは制限することが望ましいサービス・デバイスの一例として、機能を近接性ベースで利用できるデバイスがある。近接性ベース・サービスは、要求があった場合に機能の通知を行うことができる。これらの通知は、広くアクセスできない場合がある。たとえば、近接性ベース・サービスは無線通信システムで提供できる。「無線」という用語は、電磁波または音波が電線ではなく大気中を通して信号を伝送する通信、監視、または制御システムを意味する。ほとんどの無線システムでは、無線周波（ＲＦ）または赤外線（ＩＲ）の波長を使用する。通常、近接ベースの無線システムでは、トランシーバを備えるデバイスは通信チャネルを確立し維持するために他のデバイスから到達範囲内（近接）になければならない。デバイスは、他のデバイスを無線ローカル・エリア・ネットワーク（ＬＡＮ）に接続するためのハブとすることもできる。
【０２５３】
前述のように、分散コンピューティング環境の実施形態では、クライアントがサービスとランデブーするためのルックアップ・スペースを使用するメカニズムを提供する。近接コンピューティング環境では、分散コンピューティング環境の一実施形態は、クライアントがランデブー・ポイントとしてルックアップ・スペースを使用せずにサービスを発見するために使用するサービス発見メカニズムを提供する。近接コンピューティング環境の一例として、ＩｒＤＡポイントツーポイント通信環境がある。近接コンピューティング環境では、近接メカニズムがクライアントに対するサービスの「物理的」位置を見つけることができる。たとえば、ＩｒＤＡ環境では、クライアント・デバイスは、クライアントが使用することを望んでいるサービスを含むデバイスを物理的に指している。
【０２５４】
近接サービス発見メカニズムを使用すると、クライアントは、サービス通知を求めるためにサーチ要求をルックアップ・スペースに送るのではなく、直接サービス通知を求めることができる。クライアント・デバイスはサービス・デバイスへの近接接続を確立しているため、クライアントは目的のサービスを直接要求できる。たとえば、ＰＤＡクライアント・デバイスはプリンタ・デバイスとの近接接続を確立している場合があり、クライアントはプリンタ・デバイスのプリンタをサービス接続を要求することを「知っている」。
【０２５５】
一実施形態では、クライアントは、近接サービス発見メッセージをサービス・デバイスに送ることができる。メッセージには、クライアント・デバイスが近接接続を行う相手であるサービス・デバイスの目的のサービスを指定する情報を含む。一実施形態では、サービス・デバイスのサービスは近接サービス発見メッセージに応答し、クライアントに、目的のサービスに接続するためにクライアントが使用するサービス通知を送る。近接サービス発見メッセージは、さらに、クライアントの認証を行い、サービスでクライアントの能力を確定するために使用される情報を含む。受け取ったサービス通知を使用する際に、クライアントは、目的のサービスとの通信を確立するためのゲートを確立することができる。しかしながら、広くアクセス可能なスペースで通知を維持することを望まない、または維持できないサービスに対し通知をパブリッシュすることが望ましい。分散コンピューティング環境の一実施形態では、近接ベース・デバイスなどのサービス通知をパブリッシュしないデバイスとの接続を確立するデバイスは、非パブリッシュ・デバイスから受け取ったサービス通知をパブリッシュすることができる。たとえば、近接ベース・デバイスとの接続を確立し、代替えトランスポート接続を設定するデバイスは、代替えトランスポート環境で近接ベース・デバイスから受け取ったサービス通知をパブリッシュ（または再パブリッシュ）し、近接ベース・デバイス・サービスをデバイスの通常の近接範囲の外にある他のデバイスにより（（再）パブリッシュされたサービス通知を通じて）使用できるようにする。
【０２５６】
パブリッシュ・デバイスが、発見および／またはルックアップ・サービスを通じて近接ベース・デバイスのローカルでパブリッシュされたサービスを通知を特定するか、またはそれとは別に、サービス通知をローカル・サービス・デバイスがパブリッシュしないが、その代わりに、そのサービス通知を、上述のように、接続の確立後、ローカル・デバイスがパブリッシュ・デバイスに送る。一実施形態では、通知を維持するデバイスがローカル・デバイスに接続されているか、接続することが可能である限り、再パブリッシュされたサービス通知は使用可能にできる。たとえば、パブリッシュ・デバイスがローカル・デバイスから切断された場合（たとえば、デバイスの近接範囲から外へ移動する）、サービス通知はステールになるか、または削除される。通知が格納されているスペースがリース更新メッセージをパブリッシュ・デバイスに送ることができるようにするリース・メカニズムを実現できる。パブリッシュ・デバイスは、ローカル・デバイスとの接続を確認し、これによりローカル・デバイスが利用できなくなったときにそのことをスペースが検出できるようにする。ローカルの近傍（たとえば、近接領域）またはローカル・ネットワークに対し、ローカル・デバイスまたは管理ポリシーにより、サービス通知を再パブリッシュする規則を定める。図２４は、一実施形態により、近傍ベースのデバイスから提供されるサービスをデバイスの近傍の範囲外にあるデバイスでアクセスできるようにする近傍ベースのデバイスを他のトランスポート・メカニズムにブリッジするデバイスの一例を示す図である。パブリッシュ・デバイス１４０４は、Ｅｔｈｅｒｎｅｔ　ＬＡＮまたはインターネットなどのネットワーク１４１２に接続され、近接デバイス１４００および１４０４との近接接続１４１４を確立して維持する。近接接続は、たとえば、無線接続または有線ＬＡＮ接続とすることができる。近接デバイス１４００および１４０２は、それぞれ、接続後サービス通知をパブリッシュ・デバイス１４０４に送るか、または、それとは別に、パブリッシュ・デバイスが近接接続に発見および／またはルックアップ・サービスを使用してサービス通知を特定する。パブリッシュ・デバイス１４０４は、スペース１４０６内のサービス通知１４１６および１４１８を再パブリッシュすることにより、近接デバイスによって提供されるサービスをネットワーク１４１２上の他のデバイス１４０８および１４１０から利用できるようにする。スペース１４０６は、パブリッシュ・デバイスまたはＬＡＮに接続された他のデバイス（デバイス１４０８および１４１０を含む）上に格納できる。
【０２５７】
デバイス１４０８および１４１０を含むＬＡＮ上の他のデバイスは、スペース１４０６を発見し、再パブリッシュされたサービス通知１４１６および１４１８を近接ベース・デバイスについてルックアップし、前記のＸＭＬメッセージ・パッシング方式を使用して近接ベース・デバイス１４００および１４０２上でこれらのサービス（デバイス１４０４はプロキシまたブリッジとして機能する）とのデートの通信を確立し、近接デバイスとの間の要求の発送および結果の受取を行う。パブリッシュ・デバイス１４０４は、ネットワーク１４１２と近接ベース・デバイスへの近接接続１４１４との間のブリッジとして機能する。
【０２５８】
リース
リースは、分散コンピューティング環境で、部分的な障害、リソースの同期（スケジューリング）を処理し、秩序だったリソースのクリーンアップ・プロセスを実施するために使用される。リースを使用すると、分散システム全体で行き来する独立のクライアントおよびサービスを管理することができる。クライアントがサービス（スペース・サービスを含む）から取得するさまざまなリソースは、これらのサービスからリースすることができる。一般に、すべてのリソースをリースするできるわけでも、またリースする必要があるわけでもない。一実施形態では、どのリソースをリースする必要があるかの決定は、それぞれの特定のサービスの実装に任されている。特に、大量のクライアントが使用するリソースが同時に、リースを必要としない場合があったり、あるいはその代わりに、カスタム・リース・プロトコルを必要とする場合もある。このようなはリースのクラスは、サービス・プロバイダに任されている。たとえば、トランザクションを実装するものなどのカスタム・プロトコルは、基本リース方式に基づいて構築できる。一実施形態では、基本リース・モデルは相対的な時間ベースのモデルである。
【０２５９】
サービスは、リースをクライアントに発行し、リースに対し操作を実行する。一実施形態では、サービスのこのようなリース機能はすべてそのサービスのＸＭＬスキーマの一部である。したがって、クライアントはそのゲート（サービスに対応し、サービスのＸＭＬスキーマに対し構築される）を使用してリース操作を実行することができる。一実施形態では、リースを発行するサービスはすべて、（ｉ）リースの更新（リースの指定されたパラメータ（たとえば、リースＩＤ、リース証明書）、要求された新しいリース時間）、および（ｉｉ）リースの取り消し（リースの指定されたパラメータ（たとえば、リースＩＤ、リース証明書）という２つのリース操作を行える（リースの所有者によってのみ使用可能）。一実施形態では、すべてのリースは交渉可能な特定の相対的時間（リースの持続時間）について認可される。リクエスタではある時間を指定し（たとえば、秒で）、グランタ（ｇｒａｎｔｏｒ）ではその時間が経過するまでの間リースを認可できる。一実施形態では、値を−１にすると、無期限のリースを指定することができる。
【０２６０】
一実施形態では、サービス通知に１つまたは複数のリース・アドレスを含めることができる。一実施形態では、リース・アドレスはＵＲＩとすることができる。サービス・リソース・リースを更新する、または取り消す標準リース・メッセージを、リースＵＲＩに送ることができる。リースＵＲＩの例：
Figure 2004504657
【０２６１】
通知は、さらに上述のように、さまざまなリース・メッセージを含む。リース・メッセージは、サービスのリソースに対するリースを更新するメッセージおよびリースを取り消すメッセージを含むことができる。一実施形態では、通知にメッセージをＸＭＬスキーマで含めることもできる。
【０２６２】
リース・メカニズムは、サービスおよびクライアントの障害を検出するメカニズムを備える。リースはさらに、共有および排他的リソース・アクセスを実現するメカニズムも備える。一実施形態では、すべてのサービス・リソースはリースがないか（リソースがリースされておらず、したがって使用できない）、共有リソースがあるか（リソースは複数のクライアントによりアクセスされる）、または排他的リースがあるか（リソースは一度に１つのクライアントだけによりアクセスされる）のいずれかである。一実施形態では、すべてのリソースはリースがない状態から始まる。リースがない状態は、現在基礎となるリソースにアクセスがないことを意味し、リソースのインタレストが存在していてリースに使用可能であることを示す。リース・レベルは、「なし」から「共有」へ、「なし」から「排他的」へ、または「共有」から「排他的」へ上げることができる。リース独立レベルも、「排他的」から「共有」へ、「排他的」から「なし」へ、または「共有」から「なし」へ下げることができる。一実施形態では、クライアントは自発的にリース独立レベルを上下させるか、またはサービスによりそのようにすることを要求することができる。サービスからの応答メッセージは、独立レベルの変更が受け入れられたかどうかを示す。
【０２６３】
要求−応答メッセージのペアを使用して、リースの請求、解放、および更新を行うことができる。予約されているＸＭＬタグを使用して各メッセージにタグを付け、メッセージがリース・メッセージであることを示す。分散コンピューティング環境では、メッセージの完全な構成を必ずしも定義しない。このような実施形態では、メッセージがリース・メッセージとしてタグ付けされる限り、サービス開発者側でカスタム・メッセージ・コンテンツを付加することができる。
【０２６４】
一実施形態では、リースされたリソースを使用するクライアントは、（ｉ）リソースを共有または排他的として請求する、（ｉｉ）リソース請求を解放する（要求された場合またはリソースで終了した場合）、および（ｉｉｉ）更新メッセージに応答する（同じまたは異なる独立レベルの他の請求により）のいずれかを行うことを期待される。更新メッセージは、サービスにより（たとえば、定期的間隔で）クライアントの障害を検出するために送られる。この間隔（更新メッセージが送られる）は、サービス固有である。一定時間経過後更新メッセージへの応答が発行されない場合（たとえば、サービス通知で知らされた時間に基づき）、リソース再利用プロセスがサービス内で開始し、そのリースを完全に破棄する。このような実施形態では、クライアントに送られる更新メッセージは、タイミングよく取り扱うべきである。図２５は、クライアントとインスタンス化されたサービスとの間の更新メッセージ、およびサービス・プロバイダとスペース・サービスとの間の更新メッセージの使い方を示している。両方とも、クライアントとサービスとの間の更新メッセージの使用と考えることができるが、それは、サービス・プロバイダがスペースの通知サービスへのクライアントであるためであることに注意されたい。
【０２６５】
更新メッセージは、クライアントには取り扱いが不便な「アウトオブバンド」方式で到着する。つまり、クライアントは、更新メッセージがいつサービスから送られるかを予測できないということである。アウトオブバンド・メッセージ処理により、クライアントのロジックがやっかいなものになり、その複雑度が増す。この問題を解決するために、自動リース更新メカニズムを実装し、アウトオブバンド・メッセージを取り扱う必要があるクライアントの労力を軽減し、クライアントの複雑さを低減する。自動リース更新メカニズムで、それぞれのゲート（メッセージ、メソッド、および／またはイベント・ゲート）は更新メッセージを受け取り、クライアントの助けを借りずにそれに自動的に応答することができる。更新要求に対するデフォルトの応答は、現在のレベルでリースを請求することである。それぞれのメッセージ・ゲートは、ゲートが更新メッセージを受け取ったときに自動的に通知スペース・サービスに送られる単一の留保更新応答メッセージを含むことができる。この「アウトオブバンド」メッセージは、クライアントの代わって処理され、クリーンなクライアント・プログラミング・モデルを生み出す。一実施形態では、ゲートにより、クライアントはリース・イベント・ハンドラを登録し、応答メッセージの中で異なる独立レベルを指定できる。
【０２６６】
分散コンピューティング環境で標準リース・メッセージを定義することができる。一実施形態では、カスタム・リース・モデルにより追加リース・メッセージを定義することができる。一実施形態では、リースを発行するすべてのサービスは、更新および取り消しリース・メッセージを送る場合にＵＲＩを指定することができる。リース・メッセージは、メッセージの発送側を認証するために埋め込まれた証明書を含むことができる。一実施形態では、クライアントはサービスのインスタンス化時に認証サービスから証明書（たとえば、認証証明書）を受け取り、サービスに送られるメッセージ内にその証明書を埋め込むことができる。一実施形態では、認証サービスは、そのサービスのサービス通知の中で指定されている。その後、サービスは、クライアントからメッセージで受け取ったときに証明書を認証する。一実施形態では、サービスは、最初に受け取ったときの証明書をクライアントが証明書を生成するために使用したのと同じ認証サービスに送る。したがって、証明書を発行し、リース・メッセージに証明書を埋め込む作業により、セキュリティで保護されたリース環境を実現することができる。たとえば、証明書を取り消しリース・メッセージ内に埋め込むと、承認され証明されているクライアント（およびリースを発行したサービス）以外のものがリースを取り消すことを事実上禁止することができる。詳細については、「認証とセキュリティ」の項を参照のこと。
【０２６７】
図４４は、リソースをリースするメカニズムを示す流れ図である。ステップ２０００で、クライアントは、サービスによって提供されるリソース上でリースを要求する。一実施形態では、リースは時間ベースである、つまり、一定期間をクライアントに対し認可される。他の実施形態では、リースは、クライアントまたはサービスが取り消すまで維持される時間ベースでないリースとすることができる。一実施形態では、サービスはスペース・サービスであり、リソースは他のサービスに対するサービス通知であってスペース・サービスによりクライアントにリースされる。一実施形態では、サービスはスペース・サービスであり、クライアントはそれ自体サービスであり、リソースはクライアント／サービスの代わりにスペース・サービスによるサービス通知をパブリッシュすることである。一実施形態では、クライアントは、リソースを指定し、リソース上でリースを要求するサービスに要求メッセージを送る。一実施形態では、メッセージにより、要求されたリース期間を指定する。一実施形態では、クライアント・メッセージ・ゲートは、クライアントのために、サービスにリース要求メッセージを送ることができる。一実施形態では、リース要求メッセージはＸＭＬメッセージである。
【０２６８】
ステップ２００２で、サービスは、リソース上のリースをクライアントに対し認可する。一実施形態では、サービスは、クライアントからリース要求メッセージを受け取る。その後、サービスはリソース上でリースを認可することができる。一実施形態では、リース要求メッセージは、要求されたリース期間を含む。一実施形態では、サービスは、要求されたリース期間以内の認可されたリース期間についてリースを認可することができる。一実施形態では、要求されたリース期間は無期限のリースに対応する（つまり、期限切れのない期間）。この実施形態では、リース自体に期限切れがないため、クライアントまたはサービス側でリースを取り消す必要がある。
【０２６９】
クライアントに提供されるサービス通知を使用して、サービスのアクセス中にサービスによって提供され、クライアントによって要求されるリソースの初期リースを確立することができる。一実施形態では、リソース上のリースはサービスのインスタンス化時に認可される。この実施形態では、クライアントは、リースを要求しているサービスにリース要求メッセージを送ることはできない。この実施形態では、サービスは、サービス通知からインスタンス化されたときに、１つまたは複数のリソースに対する初期リースをクライアントに認可することができる。たとえば、スペース・サービスは、クライアントからの要求メッセージに応答して、スペース・サービス上のサービス通知からサービスをインスタンス化することができる。サービスは、クライアントが明示的にリースを要求するメッセージを送りなくても、インスタンス化されたときに、サービスによって提供される１つまたは複数のリソース上についてクライアントにリースを認可することができる。
【０２７０】
ステップ２００４で、クライアントはリースの更新を要求する。一実施形態では、サービスは、クライアントにリース更新要求メッセージを送る。一実施形態では、すでに認可されているリース期間の期限切れの前にリース更新要求メッセージをクライアントに送る。クライアントは、リースの更新を要求するサービスに対するリース更新応答メッセージでそのメッセージに応答する。時間ベースのリースを使用する一実施形態では、リース更新応答メッセージは、要求されたリース期間を含む。時間ベースでないリースを使用する他の実施形態では、リース更新応答メッセージは、リースを継続することを要求する。一実施形態では、クライアントは、リースがもはや必要なくなったことをサービスに指示するリース更新応答メッセージを返す。一実施形態では、クライアントがリース更新応答メッセージを送らないと、サービス側では、応答メッセージがサービスに届かないということでクライアントがもはやリースを必要としなくなったものと想定する。たとえば、クライアントはネットワークから切断されている可能性がある。これにより、サービスは、使用されていないリースを検出し、リースしているリソースを含むリソースのガベージ・コレクションを実行するメカニズムを利用できる。
【０２７１】
一実施形態では、サービスは、クライアントにリース更新要求メッセージを送らない。この実施形態では、クライアントはその代わりに、認可されたリース期間を監視し、認可されたリース期間の期限切れ前にリース更新メッセージをサービスに送る。リース更新メッセージでは、リースしているリソースおよびリソースのリースに対する要求された新しいリース期間を指定する。一実施形態では、要求されたリース期間は無期限のリースに対応する（つまり、期限切れのない期間）。クライアントは、リースを必要としなくなったら、更新メッセージを送らず、リースを破棄する。
【０２７２】
一実施形態では、クライアント・メッセージ・ゲートがクライアント・プロセスのためにリースの更新を処理する。したがって、クライアント・プロセスはリース・メンテナンスの処理の役割から解放される。一実施形態では、クライアント・メッセージ・ゲートは、サービスから送られたリース更新要求メッセージに自動的に応答する。一実施形態では、デフォルトのリース更新応答メッセージがゲートにコンパイルされ、そのリース更新要求メッセージを受け取ったゲートによってサービスに自動的に送られる。他の実施形態では、サービスは、リース更新要求メッセージを送らない。この実施形態では、クライアント・ゲートは、リース更新メッセージを自動的に送る。一実施形態では、自動発送が定期的に実行される。一実施形態では、クライアント・メッセージ・ゲートが、現在認可されているリース期間を監視し、現在認可されているリース期間の期限切れ前にリース更新メッセージを送る。
【０２７３】
一実施形態では、リースは排他的アクセスおよび共有アクセスを含む複数のアクセス・レベルのうちの１つである。排他的アクセスにより、クライアントにリソースへの排他的権限が与えられ、他のクライアントはリースの持続期間中リソースにアクセスすることを禁じられる。共有アクセスでは、他のクライアントに、クライアントと同じリソースを現時点でリース権限、つまり、クライアントが保持しているリースの期間と重なるリソースへのリースを取得する権限が与えられる。一実施形態では、クライアントは一アクセス・レベルでリースを保持し、他のアクセス・レベルでリースを要求するリース更新メッセージを送る。
【０２７４】
ステップ２００６で、サービスは、クライアントからリース更新メッセージを受け取った後、リソースのリースの更新をクライアントに認可する。サービスからクライアントに送られたリース更新要求メッセージへの応答としてリース更新メッセージが発送済みであるか、または既に認可されているリース期間の期限切れ前にクライアントにより自動的に発送されている。一実施形態では、リースは、認可されたリース期間に対して認可できる。一実施形態では、リース更新メッセージは、リース更新期間をすでに要求している。一実施形態では、認可されたリース期間は要求されたリース期間以内とする。一実施形態では、サービスは、クライアントによるリース更新要求を拒否する。たとえば、クライアントは、最大累積リース期間を超えているか、または他のクライアントがリソースに対する排他的リース・アクセス権を必要としている場合がある。一実施形態では、サービスは、要求されたリース期間よりも短い期間について、リースを認可することができる。一実施形態では、サービスは、メッセージをクライアントに送り、リースが更新された場合にそのことをクライアントに通知する。一実施形態では、メッセージは、認可されたリース期間を含む。
【０２７５】
ステップ２００８で、クライアントは、リースの取り消しを要求しているサービスにメッセージを送る。このメッセージで、クライアントがリースを取り消すリソースを指定する。ステップ２０１０で、サービスはリースを取り消す。サービスは、ステップ２００８で述べたように、リース取り消し要求メッセージの受取への応答としてリースを取り消す。一実施形態では、サービスは、さらに、認可されたリース期間がクライアントからリース更新メッセージを受け取らないうちに期限切れになった場合にリースを取り消すことができる。サービスはさらに、他のさまざまな理由によりリースを取り消すことができる。たとえば、他のクライアントはリソースに対する排他的アクセスを要求するか、またはリソースが利用できなくなる。一実施形態では、サービスは、メッセージをクライアントに送り、リースが取り消された場合にそのことをクライアントに通知する。
【０２７６】
一実施形態では、後述の認証証明書などのセキュリティ証明書を、図４４で述べられているように、クライアントとサービスとの間で送られるリース・メッセージに含めることができる。たとえば、クライアントは、サービスに送られるリース更新およびリース取り消し要求メッセージ内にセキュリティ証明書を埋め込むことができる。サービスは、メッセージを受け取ると、その証明書を調べてそれがリースホルダからのものであることを確認し、さらに、メッセージの信憑性も確認する。こうして、適切な証明書を持たないエンティティがサービスによりクライアントも現在のリースを修正するのを防止することによりリース・メカニズム内にセキュリティを確保する。
【０２７７】
一実施形態では、クライアントとサービスとの間で送られるリース・メッセージのすべてはデータ表現言語によるものである。一実施形態では、データ表現言語は拡張可能マークアップ言語（ＸＭＬ）である。一実施形態では、すべてのメッセージは、サービス・メッセージ・ゲートとクライアント・メッセージ・ゲートとが送受される。一実施形態では、リース・メッセージは、クライアントに提供されるＸＭＬメッセージ・スキーマで記述することができ、これを使用して、クライアント・メッセージ・ゲートを構築できる。一実施形態では、ＸＭＬメッセージ・スキーマは、たとえば、スペース・サービスから取り出したサービス通知でクライアントが取得している。
【０２７８】
リース・メカニズムは、さらに、ステール（無効の）通知を検出するメカニズムも備える。サービスがスペース内の通知をパブリッシュすると、そのサービスはこれが通知をパブリッシュしたことに基づいてリースを取得する。それぞれの通知には、サービスが通知を更新することを約束している時間が記述される。一実施形態では、すべてのタイムアウト値を秒単位で指定する。サービスがリースの更新を続ける場合、通知されたサービスがまだ提供中であるという何らかの確認をスペースで行うようにする。更新時間は、スペース・サービスによりゼロになるまでカウントダウンされる。サービスがリースを更新しない場合、サービスは失敗している可能性があるか、またはサービスを提供しなくなっているか、または提供できなくなっている。リースが更新されない場合、スペース・サービスはサービス通知をステールにするため、クライアントから使用できなくなる。サービスでは、スペースに更新メッセージを送ることにより通知を更新する。スペース・サービスは、これらのメッセージを受け取りて、通知更新時を初期値にリセットする。
【０２７９】
一実施形態では、ステール状態の通知は自動的には削除されない。スペースのポリシーに応じて、十分に長い期間期限切れになっているステール状態のサービス通知の削除を選択できる。削除ポリシーは、スペース・サービスで設定できる。スペース・サービスは、ステール状態の通知をサーチし、たとえば、それを削除するか、または管理者に知らせる。
【０２８０】
スペース・サービスは、リースを使用して、その機能によってスペースのクライアント（他のサービスを含む）に提供されるリソースを管理することができる。たとえば、クライアントがサービスを使用することを希望する場合、スペース・サービスはサービスのインスタンス化の一部としてクライアントにリースを要求する。サービスのインスタンス化を実行する際に、クライアントはサービスを実行できる。サービスをインスタンス化するために、クライアントはまず、スペース内でパブリッシュされたサービス通知のうちから１つ選択する。クライアントは、スペースに用意されているさまざまな機能を使用して、スペース内の通知をルックアップすることができる。次に、クライアントは、スペースに対しサービスのインスタンス化を要求する。サービスのインスタンス化のときに取得されたリースは、サービス通知を使用したときのものである（サービス通知をパブリッシュしたときのリースと同じではない）。スペース・サービスでは、共有されていることを示す通知の場合に複数のクライアントがサービス通知の使用についてリースすることができることに注意すべきである。そうでない場合、スペース・サービスでは、一度に１つのクライアントがサービス通知についてリースするだけである（排他的）。
【０２８１】
スペース・サービスがリースを使用してその機能によりクライアントに提供されるリソースを管理するもう１つの例として、ＸＭＬドキュメント（たとえば、サービス通知）がスペースに追加されるかまたはスペースから削除されるときにそのことを通知するようスペースのクライアントが登録する場合が上げられる。スペースの登録クライアントは、通知に対するこのサブスクライブでリースを取得できる。このリースにより、スペース・サービスは通知を送り続けるかどうかを知ることができる。このようなリースは、クライアントがスペースとのアクティブなセッションを確立している場合には、必要ないと思われる。また、スペースのクライアント（サービスの場合もある）がスペースとのセッションを確立するときに、クライアントがそのセッションでリースを取得することができることに注意されたい。このため、スペースはセッションと関連するリソースを管理することができる。
【０２８２】
他の実施形態では、分散コンピューティング環境は時間ベースではないリース・メカニズムを採用する。このリースは、オブジェクトに対し使用が請求されたときに生成される。時間ベースのメカニズムの代わりに請求メソッドでは、他の何かのパーティが同じオブジェクト（たとえば、サービス）にアクセスしたいということを現在のリースホルダに通知するコールバックを受け付ける。したがって、時間ベースのリースに対する他の実施形態として、代わりに、クライアントがスペース・オブジェクト（たとえば、サービス）に対する請求を行うことができる。他のクライアントが現在のリースホルダのリースと互換性のないリースを望んでいる場合、サービスは、「コールバック・メッセージ」をクライアントに送る。コールバック・メッセージを受け取ると、クライアント（つまり、クライアント・ゲート）はコールバック・メソッドを呼び出して、コールバック・メッセージに応答するかどうかを決定する（リースを持続する、リースを取り消す、アクセス・レベルを共有に変更するなど）。応答が決定されたら、クライアント・ゲートは応答メッセージをサービスに送る。リースを管理するこのような配布メカニズムは、ＸＭＬメッセージ通信レイヤを使用して実装できる。
【０２８３】
時間ベースでないリース実施形態では、分散コンピューティング環境は複数のレベル（または種類）のアクセスをサポートするリースを提供し、これにより、分散アルゴリズムでリース互換性を判別することができる。レベルには、（ｉ）オブジェクトをスペース内に保持する（ｋｅｅｐＩｎＳｐａｃｅ）、（ｉｉ）スペース内のオブジェクトを読み込む（ｒｅａｄＳｈａｒｅｄ）、および（ｉｉｉ）スペース内のオブジェクトを排他的に読み込む（ｒｅａｄＥｘｃｌｕｓｉｖｅ）というレベルがある。
【０２８４】
認証とセキュリティ
分散コンピューティング環境は、非同期メッセージ通信モデルに基づく自然発生の分散システムと異機種分散システムに対応し、データおよび／またはオブジェクトはＸＭＬなどの表現言語により表現することができる。分散コンピューティング環境では、たとえば、クライアントは、インターネット全体を通してサービスに接続することができる。分散コンピューティング環境では、大量のネットワーク・デバイスがセキュリティで保護された信頼できる動的な方式で連携動作する。分散コンピューティング環境により、準拠するソフトウェア・コンポーネント（クライアントおよびサービス）の間の相互運用性を実質的に可能にするプロトコルが定義される。
【０２８５】
分散コンピューティング環境のコンテキストでは、デバイスはネットワーキング・トランスポートでアドレス指定可能なユニットである。クライアントとサービスは、デバイスで実行されるソフトウェアまたはファームウェアのＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）アドレス指定可能なインスタンスとして実装することができる。
【０２８６】
インターネット・スペースには、多数のコンテンツ・ポイントが配置されている。ＵＲＩは、コンテンツ・ポイントを識別するのに使用される方法であり、テキストのページ、ビデオまたはサウンド・クリップ、イメージ、ソフトウェア、ファームウェア、またはその他のインターネット・コンテンツである。ＵＲＩの最も一般的な形式は、Ｗｅｂページ・アドレスであり、これは、Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ（ＵＲＬ）と呼ばれるＵＲＩの特定の形式またはサブセットである。ＵＲＩは、通常、リソース、リソースが置かれている特定のコンピュータ、およびコンピューター上のリソースの特定の名前（通常、ファイル名）にアクセスするために使用されるメカニズムを記述する。
【０２８７】
クライアントおよびサービス（両方とも、デバイスにソフトウェアおよび／またはファームウェアとして実装できる）は、インターネット、企業イントラネット、動的近接ネットワーク上で、単一コンピュータ内で、またはその他のネットワーク接続モデルにより接続できる。たとえば、クライアントおよびサービスをサポートするデバイスのサイズおよび複雑さは、単純な照明スイッチから複雑な高可用性のサーバーまでさまざまなものがある。デバイスの例としては、それらに限定されないが、ＰＤＡ、携帯電話、ノートブック・パソコン、ラップトップ・パソコン、より強力なＰＣ、さらに強力なコンピュータ・システム、そしてスーパー・コンピュータに至るまで、さまざまなものがある。いくつかの実施形態では、クライアントおよびサービスの距離、待ち時間、および実装を抽象化し、共通の発見および通信方法を使用し、「ブラック・ボックス」効果を生み出している。この定義方法により、ソフトウェアの実装問題は、根幹のプラットフォームで取り扱うことができ、インターネット規模に合わせて拡大縮小できる粗結合システムを実現できる。
【０２８８】
分散コンピューティング環境は、ＷＥＢおよびＸＭＬコンテンツ表現、動的デバイス発見、およびさまざまなネットワーク・デバイスからアクセス可能なセキュリティで保護されたデバイス通信など、インターネット中心のプログラミング・モデルを提供する。分散コンピューティング環境は、ＣＰＵレベルよりも上で抽象化されたネットワーク・プログラミング・モデルを含む。このプログラミング・モデルは、以下の特性を持つ。
ＵＲＩアドレス
コンテンツと呼ばれる強く型付けられたデータ（ＵＲＩでアドレス指定）
実質的に無制限の永続的コンテンツ記憶域（たとえば、ストア）（ＭＩＭＥタイプで識別されるものなどのＸＭＬおよび非ＸＭＬコンテンツを含む）
スペースと呼ばれる実質的に無制限の一時的コンテンツ・メモリ（ＸＭＬコンテンツを含む）
関係するクライアントに通知するためにスペース内に格納できる記述的ＸＭＬメタデータ（データに関するデータ）コンテンツ通知。
実質的に無制限の数の命令（メッセージとして埋め込まれる）
ＵＲＩによりアドレス指定されるセキュリティで保護されたメッセージ・エンドポイント（ゲート）
分散ソフトウェア・プログラム間のワーク・フローを調整するデータ・フローのサポート（イベント・メッセージ）
【０２８９】
サービスおよびクライアントは、分散コンピューティング環境内でプログラムとして実行できる。サービスは、サービスの使用を望んでいるクライアントに機能を通知することができる。クライアントは、同じネットワーク・デバイス内に常駐する場合も常駐しない場合もあり、デバイスのコード実行環境はＪａｖａプラットフォームをサポートする場合もあればしない場合もある。ＵＲＩを使用してコンテンツおよびメッセージ・エンドポイントをアドレス指定する際に、分散コンピューティング環境は強力なアドレス指定方式となる。アドレスにより、コンテンツまたはエンドポイントの位置を指定し、また使用するルート（またはトランスポート・プロトコル）を指定することができる。ＵＲＩを使用してアドレス指定したアイテムはさらに、関連付けられたセキュリティ証明書を持つ。セキュリティ証明書を使用して、どのようなクライアントにアイテムへのアクセスを許可するか、また承認されたクライアントでそのアイテムに対しどの操作の実行を許可するかを制御することができる。
【０２９０】
分散コンピューティング環境によって提供される高度なアクセスは、適切な認証およびセキュリティ・システムおよび方法により制御できる。分散コンピューティング環境における認証とセキュリティには、メッセージ内のＸＭＬコンテンツの型付けの正しさの検証、受取側に対し発送側を安全に識別する操作、クライアントからサービスに、その逆にサービスからクライアントに送られるメッセージの完全性を検査するメカニズム、およびクライアントに対し受け付けられたサービスのメッセージ群を記述し、サービスで受け取ったメッセージに対しメッセージ要求条件を強制するメカニズムがある。上記のセキュリティおよび認証の機能は、コードおよびデータの単一アトミック・ユニットで活用できる。コードおよびデータのアトミック・ユニットを動的に作成できる。一実施形態では、コードおよびデータのアトミック・ユニットは、いったん作成されると、メッセージ・エンドポイント（ゲート）を表し、作成時に実装されたセキュリティおよび認証ポリシーに関して改変できない。
【０２９１】
ゲートは、サービスの機能の一部または全部を使用する権限を表す。各機能は、サービスに送ることができるメッセージに関して表すことができる。ゲートはさらに、クライアントがリソースをリースするときに障害が発生した場合を検出するのに使用できる。
【０２９２】
認証およびセキュリティはさらに、サービスを使用しようとするクライアントがそのサービスを使用することを承認されていること、クライアントがサービス通知を受け取る先であるスペースがサービス通知を提供することを承認されていること、および／またはサービス通知自体が承認されていることを検証するメカニズムを備えることができる。
【０２９３】
メッセージ通信は、クライアントからサービスに要求を伝達する手段およびサービスがクライアントに結果を応答する手段としてメッセージング・レイヤに実装できる。分散コンピューティング環境のメッセージング・レイヤでは、有効なＸＭＬメッセージが送られることを実質的に保証し、また言語独立のセキュリティ・モデルを使用可能にするメカニズムを備えることができる。メッセージング・レイヤでは、送るメッセージ・エンドポイントを受け取るメッセージ・エンドポイントにリンクさせることができる。２つの関連するメッセージ・エンドポイントは、クライアントとサービスとの間の要求−応答メッセージ通信に適したセキュリティで保護された双方向のアトミック・メッセージ・チャネルを提供することができる。
【０２９４】
分散コンピューティング環境の実施形態では、サービスに関してスペース内で通知をパブリッシュすることができる。通知は、サービスのＸＭＬスキーマおよびＵＲＩを含むＸＭＬドキュメントとすることができる。サービスはさらに、通知の中にサービスＩＤトークンまたは証明書を含めることもでき、通知で、クライアントとサービスの両方により使用される認証サービスを指定することができる。その後、クライアントはスペースのサービス通知を特定し、その通知を使用してクライアントでメッセージ・ゲートをインスタンス化する。クライアントは、通知で指定された認証サービスを使用して、メッセージでクライアントに送るための認証証明書を取得する。一実施形態では、クライアントはサービスＩＤトークンまたは証明書をサービス通知から認証サービスに渡し、続いて認証サービスはサービス・トークンと、または証明書を使用して、そのクライアントの認証証明書を生成することができる。一実施形態では、クライアントはメッセージ・ゲートを作成するために必要な情報を受け取るゲート・ファクトリを備え、そのゲート・ファクトリはメッセージ・ゲートを構築し、認証サービスと通信して、クライアントの認証証明書を取得する。対応するサービス・メッセージ・ゲートが、サービス側でインスタンス化される。
【０２９５】
クライアントは、ある時点で、第１のメッセージをサービスに送る。一実施形態では、クライアント・メッセージ・ゲートは認証サービスにより構築されたクライアントの認証証明書をメッセージ内に埋め込む。サービスがメッセージを受け取ると、同じ認証サービスを使用してメッセージで受け取った認証証明書を検証する。同じ認証サービスを共有することにより、さまざまな認証プロトコルを採用し、しかも、認証証明書の生成の詳細をクライアントとサービスから分離することができる。したがって、クライアントは異なる認証証明書プロトコルを異なるサービスとともに使用することができる。
【０２９６】
一実施形態では、認証サービスは、サービスからクライアント認証証明書を最初に受け取った後クライアントの能力を判別することができる（たとえば、サービスに対しクライアントがどのようなことを許されているか）。クライアントの能力は、クライアントの素性に縛られる。そこで、クライアントのメッセージ・ゲートはクライアントからサービスに送られるすべてのメッセージに認証証明書を埋め込む。メッセージは、サービス・メッセージ・ゲートに届き、そこで、認証サービスによりチェックされ、そのメッセージがクライアントからのものであること、メッセージ要求がクライアントの能力範囲内にあることを確認する。他の実施形態では、サービス・メッセージ・ゲートは、認証サービスを使用せずに、能力を判別および能力に関するメッセージ検査を処理する。
【０２９７】
クライアントおよびサービス・メッセージ・ゲートは連携して、セキュリティで保護され信頼できるメッセージ・チャネルを実現する。ゲートはセキュリティで保護されたメッセージ・エンドポイントとして使用され、クライアントはセキュリティで保護され承認されているＸＭＬメッセージをサービスとの間で送受されることによりサービスを実行できる。
【０２９８】
分散コンピューティング環境内のオペレーションは、クライアントとサービスとの間で送られるＸＭＬメッセージとして実現される。クライアントをサービスと接続し、スペースおよびストア内のコンテンツをアドレス指定するのに使用されるプロトコルは、クライアントとサービスとの間で送ることができるメッセージによって定義される。メッセージを使用してプロトコルを定義すると、さまざまな種類のデバイスをプロトコルに参加させることができる。各デバイスは、その能力と役割に最適の方法でプロトコルを自由に実装することができる。
【０２９９】
サービスの機能は、そのサービスが受け入れるメッセージに表すことができる。サービスのメッセージ・セットは、ＸＭＬスキーマを使用して定義することができる。ＸＭＬメッセージ・スキーマにより、ＸＭＬ型付きタグを使用して各メッセージ形式を定義する。タグの使用規則もまた、スキーマで定義できる。メッセージ・スキーマは、メッセージを受け取るために使用するサービスのメッセージ・エンドポイント（ゲート）とともにＸＭＬ通知の一コンポーネントであってよい。メッセージをＸＭＬメッセージ・スキーマに加えることにより、拡張機能（さらに多くの能力）をサービスに追加することができる。
【０３００】
分散コンピューティング環境では、承認されたクライアントがサービスの能力すべてを使用できるか、またはサービスの能力のサブセットの使用に限定される。一実施形態では、一組の機能をクライアントに与えた後、クライアントは適切な承認がないとそのセットを変更することはできない。この機能定義のモデルにより、基本機能セットから拡張機能セットまでのサービス・レベルに対応できる。
【０３０１】
サービスのインスタンス化を実行する際に、クライアントはサービスを実行できる。サービスをインスタンス化するために、クライアントはまず、スペース内でパブリッシュされたサービス通知のうちから１つ選択する。クライアントは、スペースに用意されているさまざまな機能を使用して、スペース内の通知を検索することができる。次に、クライアントは、スペースに対しサービスのインスタンス化を要求する。サービスのインスタンス化は、以下のことを含むが、これに限られるわけではない。
１．クライアントは、スペース・サービスにサービスをインスタンス化するよう要求する。
２．スペース・サービスは、クライアントがサービスをインスタンス化することを許可されていることを検証する。
３．スペース・サービスは、クライアントによって指定されたリース要求時間にクライアントのサービス通知でリースを取得する。それとは別に、サービス通知をクライアントに送るができ、しかもリース・メカニズムを使用しない。
４．スペース・サービスは、ステップ３で割り当てたリースとサービスのサービス通知を含むメッセージをクライアントに送る。
５．クライアントは、サービス通知で指定された認証サービスを実行し、認証証明書を取得する。
６．クライアントは、サービスと通信するためクライアント・メッセージ・ゲートを構築する。
分散コンピューティング環境でクライアントとサービスとの間に信頼性を築くために、一連の動的に生成される数値（キー、またはトークン）を、クライアントのセキュリティまたは認証証明書として使用する。１つまたは複数の証明書を使用して、クライアントがサービスを使用する権限を検証し、クライアントとサービスとの間でやり取りするメッセージを検証することができる。それぞれクライアントおよびサービスは、固有の証明書を備える。
【０３０２】
サービスを使用するのに必要な認証証明書の種類がサービス・サーチを実行するクライアントに返される。一実施形態では、認証証明書は、クライアントがサービスを使用するごとに提示する必要がある隠蔽型オブジェクトである。一実施形態では、認証証明書はサービスに送られるすべてのメッセージ内でクライアントのためにメッセージ・ゲートにより提示される。どのような種類の認証証明書をサービスが必要としようと、クライアントとサービスの外部の認証サービスを使用することにより、クライアントおよびサービスは認証証明書構造または認証プロセスを意識する必要がない。
【０３０３】
認証証明書はさらに、サービス・チケットに加えてトランスポート固有のチケットを備えることができる。サービスを実行するときに、サービス通知で指定されるネットワーキング・トランスポートに応じて、トランスポートはセキュリティで保護された接続を提供できる。場合によっては、データ・リンク・レイヤがすでにセキュリティで保護されている場合、すでにセキュリティで保護されているデータ・リンク・レイヤ上でセキュリティで保護されたトランスポートを使用する必要はないと考えられる。
【０３０４】
認証証明書の概念は、証明書実装に基づくさまざまなレベルのセキュリティを可能にするだけの十分な抽象性を備えている。セキュリティのレベルにはそれらに限定されないが以下のものがある。
１．なし（空のメッセージにセキュリティ証明書はないか、または証明書がない）
トランスポートの物理的接続特性によりセキュリティが強制されるときは、証明書が空であるか、または証明書がないメッセージで十分である。たとえば、照明スイッチ・コントローラ１つだけに接続されたスマート・ライト・スイッチはそのスイッチが安全な方法で配線されているので安全である。
２．シグネチャ付きメッセージ（電子シグネチャ）
シグネチャ付きメッセージは、サービスがメッセージの発送源（クライアント）を検証できるようにする電子シグネチャを含む。
３．暗号化メッセージ（トランスポートでこれを取り扱う）
暗号化メッセージは、メッセージの内容をスクランブルし、他の証明書でそのスクランブルを解除する必要があるようにするという方法により、別のレベルのセキュリティを追加する。
４．能力メッセージ（サービス機能およびユーザ認識）
このレベルのセキュリティは、ユーザごとのセキュリティ機能を実現し（たとえば、ユーザが実行を許されているもの）、サービスおよび個々のサービス機能に対する精密なアクセス制御を行うことができる。
【０３０５】
高いレベルのセキュリティ（能力および暗号化）を実現するのに必要な実装が重いため、複数レベルのセキュリティ・ゾーンを使用する。メッセージ・トランスポートでこのようなセキュリティ・レベルをサポート（またはボートを支援）する場合、このサポートを活用して一方のレベルのセキュリティから他方のレベルのセキュリティへ橋架けするセキュリティ・レベル・ブリッジ・サービスを提供する。
【０３０６】
上述のように、セキュリティ・モデルのないサービスでは、空の認証証明書を受け付けることができる。アクセスが制限されていないサービスでは、認証証明書なしでまたは「空の」認証証明書付きでゲートを構築することができる。このようなサービスのゲートは、それぞれのメッセージとともに認証証明書を送らないか、または空の証明書を送る。認証サービスは、アクセスを制限しないサービスの一例である。他のサービスでは、ユーザＩＤとパスワードのペアを必要とする。
【０３０７】
証明書を使用するサービス・アクセスの認証
いくつかの実施形態では、サービスを実行しようとするクライアントが承認されているクライアントであることを検証し、クライアントによって受取されるサービス通知が承認されたサービス通知であること検証し、かつ／またはクライアントがサービス通知を受け取った発送元のスペースが承認されていることを検証するメカニズムは、公開鍵／秘密鍵非対称暗号メカニズムに基づく。このメカニズムでは、承認された発送側エンティティは公開鍵をメッセージに埋め込み、秘密鍵で公開鍵を含むメッセージを暗号化する。暗号化メッセージを受け取るエンティティは、公開鍵を使用してメッセージを復号化し、復号化されたメッセージに埋め込まれている同じ公開鍵を見つけ、そのメッセージが承認されたエンティティからのものであることを検証するが、それは、そのエンティティのみがメッセージを暗号化するのに必要な秘密鍵を持っているからである。そこで、エンティティは、実質的に忘れることができない、他のエンティティが復号化して（適切な公開鍵で）、エンティティによって送られたメッセージを検証することができる証明書を発行する。
【０３０８】
一実施形態では、分散コンピューティング環境でのメッセージはクライアント−サービス間通信モデルでエンティティを承認するため暗号化された公開鍵のいくつかのレイヤを含む。一実施形態では、サービスは公開鍵Ｘ１を含む証明書Ｃ１を構築する。その後、サービスは秘密鍵Ｙ１を使用して証明書を暗号化する。サービスは、暗号化された証明書Ｃ１をサービス通知の一部としてスペース内に格納する。その後、スペースは、証明書Ｃ１とスペースの公開鍵Ｘ２を含む新しい証明書Ｃ２を構築する。その後、スペースは秘密鍵Ｙ２を使用して証明書Ｃ２を暗号化する。クライアントがスペースにサービスを要求すると、スペースはサービス通知と証明書Ｃ２をクライアントに送る。クライアントは、ゲートを構築すると、ゲートに、暗号化された証明書Ｃ２とクライアントの公開鍵Ｘ３を含む他の証明書Ｃ３を含むメッセージをサービスに送らせる。Ｃ３は、送る前にクライアントの秘密鍵Ｙ３を使用して暗号化される。クライアントの公開鍵Ｘ３とスペースの公開鍵Ｘ２も、メッセージとともに送られる。一実施形態では、スペースの公開鍵Ｘ２はＣ３に含まれ、そのため、Ｃ３で暗号化される。この実施形態では、クライアントの公開鍵Ｘ３はメッセージ内で暗号化されずに送られる。他の実施形態では、クライアントの公開鍵Ｘ３とスペースの公開鍵Ｘ２は、メッセージ内で暗号化されずに送られる。
【０３０９】
ゲートを作成した後、一実施形態では、クライアントは暗号化された証明書Ｃ３および公開鍵Ｘ３を含むメッセージをサービスに送る。一実施形態では、スペースの公開鍵Ｘ２はＣ３に含まれる。他の実施形態では、公開鍵Ｘ２はＣ３の外部のメッセージに（暗号化されずに）含まれる。サービスは、メッセージを受け取ると、受け取られたクライアントの公開鍵Ｘ３を使用して証明書Ｃ３を復号化し、メッセージを復号化するために使用する受け取った公開鍵Ｘ３と照らし合わせて復号化された証明書Ｃ３の中に埋め込まれている公開鍵Ｘ３をチェックし、メッセージが承認されたクライアントからのものであることを検証する。その後、サービスはスペースの公開鍵Ｘ２で証明書Ｃ２（復号化された証明書Ｃ３から抽出した）を復号化し、スペースの公開鍵Ｘ２と照らし合わせて復号化された証明書Ｃ２に埋め込まれている公開鍵Ｘ２をチェックし、スペース証明書Ｃ２が承認されたスペースからのものであることを検証する。一実施形態では、スペースの公開鍵Ｘ２は証明書Ｃ３に含まれている。他の実施形態では、スペースの公開鍵Ｘ２はＣ３の外部のメッセージに含まれている。他の実施形態では、たとえば、サービスはスペース自体から別のところにあるスペースの公開鍵Ｘ２を取得する。最後に、サービスはサービスの公開鍵Ｘ１で証明書Ｃ１（復号化された証明書Ｃ２から抽出した）を復号化し、復号化された証明書をチェックして、その証明書がサービスによって作成されたものであることを検証する（証明書はサービスの公開鍵を含んでいる必要がある）。
【０３１０】
さまざまな鍵生成アルゴリズムを分散コンピューティング環境で使用できる。鍵の構成は、クライアントとサービスの両方から隠されており、クライアントとサービスはどのような鍵生成アルゴリズムを使用しているかを問わない。
【０３１１】
Ｋｅｒｂｅｒｏｓチケットは、分散コンピューティング環境で使用されるセキュリティ証明書の一例である。Ｋｅｒｂｅｒｏｓは、コンピュータ・ネットワーク内のサービスの要求を認証するセキュリティで保護された方法である。Ｋｅｒｂｅｒｏｓを使用すると、ユーザは特定のサービスを要求するために使用できる認証プロセスに暗号化された「チケット」を要求することができる。ユーザのパスワードは、ネットワークに通す必要はない。
【０３１２】
分散コンピューティング環境では、クライアントとサービスとの間で送られるメッセージの品質が損なわれないよう実質的に保証するメカニズムを提供する。一実施形態では、メッセージが改変されていないことを検証するため発送側は受取側が使用できる情報を含むトークンを埋め込む。メッセージに埋め込む情報を生成する方法はいくつかある。一実施形態では、メッセージのハッシュを計算し、それをメッセージとともに送る。ハッシュ法は、文字列を元の文字列を表す通常短い固定長の値または鍵に変換する操作を含む。メッセージを受け取ると、受取側はそのハッシュを再計算し、送られたハッシュに照らしてチェックする。メッセージが改変されていた場合、同じハッシュが生成される可能性はほとんどない。発送側は、ハッシュを暗号化し、対応する公開鍵を暗号化されたメッセージに入れて送り、そのハッシュが損なわれないように実質的に保証する。
【０３１３】
他の実施形態では、巡回冗長検査などの誤り検出方式を使用する。巡回冗長検査は、通信リンクで送られたデータ内にエラーがないか調べる方法である。巡回冗長検査を使用する実施形態では、発送側はｎビットの多項式をメッセージに適用し、その結果の巡回冗長検査（ＣＲＣ）をメッセージに付加する。受取側は、同じ多項式（メッセージでも渡される）をメッセージに適用し、その結果を発送側が付加した結果と比較する。マッチする場合、メッセージは正常に受け取られたということである。マッチしない場合、発送側はメッセージの再送を通知される。
【０３１４】
ゲート・ファクトリは「信頼できる」コードなので、ゲート・ファクトリもまたセキュリティで一定の役割を果たす。信頼できるゲート・ファクトリを使用してゲートを生成することにより、ゲートが信頼できるコードであり、そのコードがサービス通知に関して正しいものであることを保証できる。クライアントは、認証の一手段として、クライアントＩＤトークンまたは証明書をゲート・ファクトリに提示する必要がある。サービスは、クライアントがゲートを作成するときに、サービスＩＤトークンまたは証明書をクライアントに提示する（たとえば、通知を通じて）。ここで説明したように、クライアントおよびサービス・トークンのペアを使用して、クライアントがメッセージをサービスに送ることができるようにするために使用される第３の証明書を作成する。この第３の証明書は、認証証明書と呼ばれる。認証証明書は、認証プロセスの実行時に認証サービスにより作成される。一実施形態では、サービスは認証ポリシーを自由に使用できる。一実施形態では、認証サービスはサービスに代わって認証ポリシーを管理するため、サービス側では、使用されている特定の認証ポリシーを意識する必要はない。
【０３１５】
クライアントはサービス通知で指定した認証サービスを実行することにより受け取った認証証明書を使用してゲートを構築する。これにより、構築されたゲートは認証証明書をそれぞれのメッセージとともにサービスに送ることができる。サービスがクライアントから第１のメッセージで第１の認証証明書を受け取ると、サービスはサービス通知で指定されている認証サービスを使用してクライアントを認証し、認証証明書のクライアントのＩＤへのバインドを確立する。
【０３１６】
すでに述べたように、サービスによって出力されるいくつかの結果がスペース内で通知され、最終的に結果ゲートを使用してアクセスされる。結果ゲートは、結果を生成するために使用する入力ゲートと同じセキュリティ証明書を含む場合もあれば含まない場合もある。サービスへの入力は出力（結果）と非同期であるため、結果は、異なるアクセス権限セットが関連付けられる。たとえば、給料支払い簿サービスではクライアントの異なる集まりが給料支払い簿サービスを起動して給料支払い簿サービスの結果（給与）を読み取ることができる。そこで、クライアントは、結果へのアクセス権を取得するために別の認証プロセスを適用される必要があり、これは、結果に関する通知で指定された認証サービスから結果に対する認証証明書を受け取る作業も含む。
【０３１７】
メッセージ・ゲートにより、ほとんどのセキュリティ・チェックの負担がサービスから取り除かれる。サービスでは、能力の発揮と、クライアントの認証に集中することができる。クライアントが要求された（または割り当てられた）能力にのみアクセスできるようにする際に、特権は最低限にするという原則が守られる。
【０３１８】
セキュリティ・チェックは、ゲートの作成時および／またはゲートの使用時（メッセージを発送かつ／または受け取るとき）に実行される。クライアントが通知されたアイテム（サービス）へのアクセスを要求したときに、ゲート作成のプロセスが開始する。このプロセスで、クライアント・ゲート・ファクトリは、サービスと連携して、互いに相互認証を行う。ゲート作成時に実行されるチェックは広範にわたり、ゲートの使用時に実行されるチェックの回数が最小限に抑えられる。サービスでクライアントを認証した後、サービスはクライアントの特定の能力を判別し（たとえば、サービスでクライアントがどのようなことを実行することを許されているか）、その能力をクライアントの認証証明書に関連付けることができる。これらの特定の能力により、サービス上でクライアントがどのような操作を実行することを許されるかを指定できる。ゲートではすべてのメッセージに認証証明書が含まれることを確認するので、サービスでは、受け取ったときのそれぞれの要求を認証されたクライアントの能力に照らし合わせてチェックすることができる。
【０３１９】
ゲート作成チェックでは、ＸＭＬメッセージ・スキーマによって指定されたサービス能力の一部または全部を使用する許可がクライアントにあることを確認する。一実施形態では、これらのチェックは、Ｋｅｒｂｅｒｏｓなどの認証サービスとともにアクセス制御リスト（ＡＣＬ）を使用して実施する。チャレンジ−応答シーケンス（パスワードなど）も、クライアントの認証に使用できる。いくつかの実施形態では、ハードウェア・ベースの物理的識別方法を使用してクライアントを認証することができる。たとえば、ユーザは、識別と承認のためにスマート・カードなどの物理的識別機能を提供することができる。認証のための他のメカニズムも、他の実施形態で使用できる。
【０３２０】
一実施形態では、クライアントを認証するためにどのような手段を使用するとしても、認証はクライアントとサービスの両方に見えないものであり、ゲート・ファクトリが使用する認証サービスを認識し、その認証サービスが認証メカニズムとポリシーを取り扱う。ゲート・ファクトリは、製品と環境に依存しているか、または構成管理システムによって制御することさえできる。一実施形態では、クライアント独立の程度と方法はプラットフォーム依存であるが、ゲート・ファクトリには認識される。いくつかの実施形態では、ハードウェア・ベースの物理的識別方法を使用してクライアントを認証することができる。たとえば、ユーザは、識別と承認のためにスマート・カードなどの物理的識別機能を提供することができる。認証のための他のメカニズムも、他の実施形態で使用できる。
【０３２１】
分散コンピューティング環境のメッセージ・ゲートは、通常、単一のクライアントと関連付けられている。ゲート・ファクトリは関連付けの手段を決定する。メッセージを送るときに実行されるチェックにより、適切なクライアントがゲートを使用していることが確認される。一実施形態では、ゲートはメッセージで渡され、新しいクライアントがそのゲートを使用することを望んでいる場合、クローンが作成される。クローン・プロセスで、一組の作成チェックが新しく実行される。
【０３２２】
スペースのクライアントがスペース・サービスの通知を見つけると（クライアントは他のサービスでもよい）、スペースのクライアントは他のサービスの場合と同様にスペース・サービスを実行する。スペース・サービスを実行するには、認証メカニズムを使用する必要がある。スペース・サービスの実行ではそれに限定されないが、以下のことを行う。
１．スペースのクライアントは、まず、スペース・サービスのサービス通知で指定されている認証サービスを実行して認証証明書を取得する。
２．スペースのクライアントは、認証証明書、スペースのＸＭＬスキーマ（スペースのサービス通知からの）、およびスペースのＵＲＩ（スペースのサービス通知からの）を使用して、スペースのゲートを構築する。一実施形態では、クライアントはゲート構築するための情報をゲート・ファクトリに渡す。
３．スペースのクライアントは、そのゲートを使用してメッセージをサービスに送ることによりそのスペース・サービスを実行する。
４．スペース・サービスは、クライアントから認証証明書を埋め込んだ第１のメッセージを受け取ったときに、クライアントが使用したのと同じ認証サービスを使用してクライアントを認証するための認証証明書を取得し、クライアントの素性を確定する。
５．スペース・サービスは、その後、クライアントの能力（たとえば、クライアントがスペース・サービス上で実行を許されているもの）を判別し、その能力を認証証明書にバインドする。
【０３２３】
「スペース」の項で説明しているように、スペース機能は、生成元のスペースと実質的に同じ機能（同じＸＭＬスキーマ）を持つ空のスペースを生成するインターフェースを備えることができる。生成機能は、特に、結果に対しスペースを動的に生成する場合に使用できる。リクエスタがスペースを生成すると、リクエスタのみがその生成されたスペースにアクセスすることが許される。たとえば、生成されたスペースは、クライアントを安全な状態に保持する必要があるサービスからの結果を格納するために使用される。このセキュリティは以下のようにして保証される。
【０３２４】
初期ルート認証証明書を作成し、生成されたスペースの認証サービスを初期化する際に、認証サービスがルート認証証明書のみを認証し、他の認証証明書を返さないようにする（最初に許可されている生成されたスペースのクライアントはほかにない）。
【０３２５】
生成されたスペースのセキュリティ・ポリシーを初期化し、ルート認証証明書に関連付けられたルートＩＤで、セキュリティ管理機能を含むスペースのすべての機能にアクセスできるようにする。ルート認証証明書および生成されたスペースのサービス通知を生成されたスペースのリクエスタに返す。
【０３２６】
リクエスタは、生成されたスペースにアクセスするためのゲートを構築するが、それは、認証証明書と生成されたスペースのサービス通知を返すからである。一実施形態では、リクエスタとリクエスタが認証証明書と生成されたスペースのサービス通知を渡すクライアントまたはサービスのみが生成されたスペースにアクセスできる。生成されたスペースへのアクセスをこのように制限することは、たとえば、クライアントとサービスが結果をプライベートの状態に保持する場合にクライアントおよびサービスがその生成されたスペースを使用して結果を格納するときに役立つ。
【０３２７】
サービスを実行した後、クライアントはセキュリティ管理スペース機能を使用して生成されたスペースの認証ポリシーを変更し、その後、他のクライアントまたはサービスはその生成されたスペースにアクセスできる。さらに、発見プロトコルまたはその他の手段を用いて、生成されたスペースのサービス通知を生成されたスペースの他のクライアント（他のクライアントはサービスでもよい）から利用できるようにする。
【０３２８】
分散コンピューティング環境でのメッセージ・トランスポート・レイヤは、トランスポート時にクライアントとサービスとの間の通信のセキュリティおよび安全性を保護するメカニズムを備える。このようなセキュリティは、「ワイヤ・セキュリティ」または「トランスポート・セキュリティ」と呼ばれるものであり、これにより、ゲートを含むメッセージング・システムにより実装された認証セキュリティから区別できる。メッセージの暗号化は、分散コンピューティング環境のメッセージ・トランスポート・レイヤで行われる。暗号化されたトランスポートを要求するサービスは、ＸＭＬ通知にタグを付けることによりそのような作業を行う。その後、ゲート・ファクトリは、ＢｌｕｅｔｏｏｔｈやＨＴＴＰＳによって提供されるものなどのセキュリティで保護されたメッセージ・トランスポートを使用するゲート（または複数のゲート）を作成する。
【０３２９】
ＨＴＴＰＳ（Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、ユーザ・ページ要求さらにＷｅｂサーバによって返されるページの暗号化および復号化を行うＷｅｂプロトコルである。ＨＴＴＰＳでは、ストリーム暗号化アルゴリズム（たとえば、ＲＣ４）に多ビット鍵サイズ（４０〜１２８ビット以上）を使用して、商用のデータ交換に対し十分な暗号化を行う。ＨＴＴＰＳは、分散コンピューティング環境でトランスポートとして使用できる。
【０３３０】
Ｂｌｕｅｔｏｏｔｈは、新しく登場したピアツーピアの無線通信規格である。Ｂｌｕｅｔｏｏｔｈ鍵生成アルゴリズムを分散コンピューティング環境で使用できる。Ｂｌｕｅｔｏｏｔｈでは暗号鍵をサポートする。暗号鍵はトランスポートに依存しているが、クライアント、サービス、および組み合わせ鍵はトランスポートに依存しないようにできる。
【０３３１】
図２６ａ−クライアントに認証証明書を提供する認証サービス
図２６ａは、一実施形態により、認証証明書をクライアントに提供する認証サービスを示す流れ図である。分散コンピューティング環境のクライアントは、クライアントのために１つまたは複数の機能を実行するサービスを必要とすることがある。一実施形態では、セキュリティで保護されたメッセージング・チャネルを設定するときにクライアントとサービスで使用する認証サービスを提供する。認証サービスは、クライアントおよび／またはサービスの認証および望むレベルのセキュリティおよびクライアントとサービスとの間で渡されるメッセージ・セットを交渉するなどの機能をクライアントおよび／サービスのために実行する。認証サービスは、分散コンピューティング環境内で実行されているプロセスでもよい。認証サービスは、サービスおよび／またはクライアントと同じデバイスで実行するか、またはそれとは別に、認証サービスは、認証サーバなどの別のデバイスで実行する。一実施形態では、認証サービスはインターネット・ベースのサービスである。認証サービスは、それ独自のアドレス、たとえば、Ｕｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を持ち、これにより、クライアントおよび／またはサービスは認証サービスと通信できる。一実施形態では、認証サービスのアドレスを、サービスのサービス通知でクライアントに提供する。認証サービスを共有するクライアントおよびサービスを使用すると、クライアントとサービスとの間でセキュリティで保護されたメッセージング・チャンネルを確立し、いくつかのセキュリティおよび認証プロトコルのどれかをメッセージング・チャネルで使用できる。
【０３３２】
一実施形態では、クライアントはクライアントＩＤトークンまたは証明書を認証サービスに提示する。クライアント・トークンまたは証明書は十分に忘れがたいものであり、クライアントの素性を証明するものとして使用できる。次に、認証サービスは、クライアントＩＤトークンまたは証明書をチェックし、クライアントに、認証サービスのみが作成できる認証証明書を発行する。クライアントに返された認証証明書は、次に、クライアントによりすべてのメッセージに入れられてサービスに送られる。一実施形態では、クライアント・メッセージ・ゲートはゲート・ファクトリによって作成され、認証証明書をメッセージ・ゲートに格納すると、メッセージ・ゲートはクライアントに代わって認証証明書をすべてのメッセージに入れてサービスに送る。メッセージを受け取ると、サービスは認証証明書をチェックする。認証サービスのみが認証証明書を作成できるので、クライアントが認証証明書を改ざんしていないとサービスは認識する。一実施形態では、サービスは認証証明書をクライアントによって使用される同じ認証サービスに渡し、認証証明書が有効であることを確認し、クライアントが承認されたクライアントであることを検証し、クライアントの素性を調べる。
【０３３３】
スペース・サービスおよび認証サービスを含むすべてのサービスはそのクライアントを認証することができる。サービスによってクライアントの認証が行われると、クライアントはそのサービスにアクセスできる。たとえば、スペース・サービスの場合、クライアントはスペースからＸＭＬ通知を取得する。
【０３３４】
一実施形態では、サービスはそのサービスのすべてのクライアントが使用するあらかじめ整えられている証明書を用意する。この実施形態では、認証により、そのあらかじめ整えられた証明書が要求側クライアントに提供される。クライアントはあらかじめ整えられている証明書をサービスに提示すると、サービスによって承認される。
【０３３５】
ステップ１０００で、クライアントは認証証明書を認証サービスに要求する。一実施形態では、クライアントは目的のサービスのサービス通知をサーチし、特定する。一実施形態では、サービス通知はサービスにアクセスする際に使用される認証証明書を取得するために使用する認証サービスの通知を含む。一実施形態では、サービス通知は、認証サービスのＵＲＩなどのアドレスを含む。一実施形態では、クライアントは認証証明書を要求する認証サービスに情報を送る。一実施形態では、クライアントは情報をゲート作成プロセス、たとえば、ゲート・ファクトリに送り、ゲート作成プロセスは認証サービスにアクセスして認証証明書を取得する。
【０３３６】
ステップ１００２で、認証サービスはクライアントのために認証証明書を生成する。認証証明書は、メッセージング・システムのメッセージに埋め込むことができ、これによりメッセージの受取側がメッセージの発送側を認証し、メッセージが承認された発送側からのものであることを検証し、メッセージが発送側が受取側に送ることを許可されているメッセージであることを検証できるようにするデータ要素またはデータ構造である。分散コンピューティング環境の一実施形態では、認証証明書は特定のクライアントと特定のサービスとの間に設定されるメッセージング・チャンネルに固有のものである。ステップ１００２は、図２６ｂに詳しく示され、説明されている。図２６ａのステップ１００４で、認証サービスはクライアントに認証証明書を返す。一実施形態では、認証証明書は、クライアントに直接返すことができる。一実施形態では、認証証明書をゲート作成プロセス、たとえば、ゲート・ファクトリに返し、このプロセスが次に、認証証明書を使用してゲートを生成する。
【０３３７】
図２６ｂ−認証証明書を生成する認証サービス
図２６ｂは一実施形態により、図２６ａのステップ１００２で展開し、認証証明書を生成する認証サービスを示す流れ図である。一実施形態のステップ１００２ａで、認証サービスはクライアント・トークンとサービス・トークンを取得する。他の実施形態では、認証サービスはクライアント・トークンのみを取得する。一実施形態では、クライアント・トークンは分散コンピューティング環境におけるクライアントの一意的な識別子である。一実施形態では、サービス・トークンは分散コンピューティング環境におけるサービスの一意的な識別子である。たとえば、公開／秘密鍵暗号化メカニズムの公開鍵をクライアントとサービスに対する一意的な識別子として使用することができる。一実施形態では、クライアントはサービス通知でサービス・トークンを受け取り、クライアントはクライアント・トークンとサービス・トークンを認証サービスに送る。他の実施形態では、クライアントはクライアント・トークンとサービス通知ＵＲＩを認証サービスに送り、認証サービスはサービス通知からサービス・トークンを取り出すことができる。
【０３３８】
ステップ１００２ｂで、認証サービスはクライアントおよび／またはサービスを検証する。一実施形態では、認証サービスはステップ１００２ａで取得したクライアント・トークンおよびサービス・トークンを使用して、クライアントおよび／またはサービスを検証する。他の実施形態では、ステップ１００２ａでクライアント・トークンのみを取得しており、１００２ｂでクライアント・トークンのみを使用してクライアントを検証する。一実施形態では、クライアントはそのクライアント・トークンをすでに認証サービスに登録しており、認証サービスは受け取ったクライアント・トークンを登録されているクライアント・トークンと比較し、クライアントが有効なクライアントであるかどうかを検証することができる。一実施形態では、クライアントはパスワードが設定されているログオン・アカウントなどのチャレンジ／応答メカニズムを使用して認証サービスにアクセスし、クライアントを有効なクライアントとして検証することができる。一実施形態では、サービスはすでに認証サービスに登録されており、そのサービス・トークンを認証サービスに提供してある。認証サービスは、次に、受け取ったサービス・トークンをすでに登録されているサービス・トークンと比較して、クライアントが有効なサービスにアクセスしようとしていることを検証する。他のタイプのクライアントおよびサービス認証も使用できる。たとえば、クライアントは、認証サービスがクライアントを認証するためにかつ／またはクライアントがアクセスしようとしているサービスを認証するために使用できる電子シグネチャまたは電子証明書を提供する。
【０３３９】
ステップ１００２ｃで、認証サービスは認証証明書を生成する。一実施形態では、認証証明書は、認証サービスのみが作成できる認証トークンを含む。一実施形態では、認証サービスはクライアント・トークンとサービス・トークンを使用して認証証明書を生成する。他の実施形態では、認証サービスはクライアント・トークンだけを使用して、認証証明書を生成する。さらに他の実施形態では、認証サービスは認証証明書の生成に取得されているトークを使用しないが、その代わりに、認証証明書生成アルゴリズムを使用して実質的に忘れることはできない認証証明書を生成することができる。一実施形態では、認証サービスはサービス・トークンとクライアント・トークンを組み合わせて、一意的な認証証明書を生成する。たとえば、サービス・トークンとクライアント・トークンを６４ビット値とし、この２つのトークンを組み合わせて１２８ビットの認証証明書を生成することができる。他の実施形態では他の方法を使用して、認証証明書を生成することができる。
【０３４０】
図４１−ゲートの作成
図４１は、一実施形態によるクライアント用にゲートを作成する方法を示す流れ図である。一実施形態では、ゲート・ファクトリはＸＭＬサービス記述に基づいてゲートを生成するクライアント上の信頼できるコードである。他の実施形態では、ゲート・ファクトリは別のデバイスに常駐し、クライアントがゲートを生成するために使用できる。たとえば、ゲート・ファクトリ・サービスは、クライアントがゲートを生成するためにアクセスできる。ゲート・ファクトリを使用すると、生成されたゲートが信頼できるコードであること、またそのコードがサービス通知に関して正しいものであることを確認することができる。
【０３４１】
ゲート作成時に実行されるセキュリティ・チェックは広範にわたり、ゲートの使用時に実行する必要のあるセキュリティ・チェックの回数が最小限に抑えられる。ゲート作成時のセキュリティ・チェックにより、サービス通知から取り出されたメッセージ・スキーマで指定された一組のサービス能力を使用する許可がクライアントにあることを確認することができる。一実施形態では、これらのセキュリティ・チェックは、認証サービスとともにアクセス制御リスト（ＡＣＬ）を使用して実施する。一実施形態では、チャレンジ／応答シーケンス（ログオンおよびパスワード・アカウントなど）も、クライアントの認証に使用できる。一実施形態では、クライアント認証およびゲート作成セキュリティ・チェックは、クライアントおよびサービスから隠されており、ゲート・ファクトリは使用する認証サービスのみを認識し、認証サービスは認証メカニズムおよびポリシーを認識できる。
【０３４２】
ステップ１０１０で、ゲート・ファクトリはクライアントがサービスと通信する際に使用する認証証明書を取得する。一実施形態では、クライアントは認証サービスから認証証明書をすでに取得しており、その認証証明書をゲート・ファクトリに提供する。他の実施形態では、ゲート・ファクトリは認証サービスから認証証明書を取得する。
【０３４３】
一実施形態では、ゲート・ファクトリはサービスのメッセージ・スキーマも取得する。一実施形態では、ゲート・ファクトリはクライアントからメッセージ・スキーマを取得する。他の実施形態では、ゲート・ファクトリはサービス通知からメッセージ・スキーマを受け取る。たとえば、クライアントは、サービス通知のＵＲＩをゲート・ファクトリに送り、ゲート・ファクトリはＵＲＩを使用してメッセージ・スキーマを取得しサービス通知に接続する。メッセージ・スキーマでは、サービスに発送またはサービスから受け取るメッセージ群を記述する。たとえば、サービスを呼び出す、またはサービスのいくつかの一部を呼び出すために、クライアントからサービスに送られるメッセージを記述できる。また、応答メッセージやイベント通知メッセージなど、サービスからクライアントに送るメッセージも記述できる。一実施形態では、メッセージをＸＭＬメッセージとし、メッセージ・スキーマをＸＭＬメッセージ・スキーマとすることができる。
【０３４４】
ステップ１０１２で、ゲート・ファクトリはクライアント・メッセージ・ゲートを生成する。一実施形態では、ゲート・ファクトリにより、生成されたメッセージ・ゲートに認証証明書がデータとして埋め込まれ、メッセージ・ゲート・コードで認証証明書にアクセスできる。他の実施形態では、認証証明書をクライアントのメッセージ・ゲートの外部に格納することができる。一実施形態では、サービスのＵＲＩも埋め込むか、またはゲート・ファクトリによってゲートに提供することができる。
【０３４５】
ステップ１０１２で、ゲート・ファクトリはそのメッセージ・スキーマを使用してクライアント・メッセージ・ゲートを生成する。メッセージ・スキーマは、クライアントがメッセージ・ゲートを通じてサービスに送るメッセージ群を定義するのに使用できる。ゲート・ファクトリでは、そのメッセージ・スキーマをゲートにコンパイルする。メッセージ・スキーマは、ゲート・ファクトリによって、メッセージ検証プロセス中に素早くアクセスするのに適している内部形式でゲートにコンパイルすることができる。サービスへのアクセスは、スキーマを使用して特定のクライアントに対し制限することができ、それにより、サービスへの一部のアクセスにクライアントを限定できる。一実施形態では、クライアントがクライアントの能力および／またはアクセス権に基づきサービス通知をたとえばスペースから取得すると、そのサービスに関して制限されたメッセージ・スキーマがクライアントに提供される。したがって、ゲート・ファクトリは、制限されたメッセージ・スキーマをコンパイルしてクライアント・メッセージ・ゲートにし、それにより、クライアントのサービスへのアクセスを制限することができる。一実施形態では、認証サービスはクライアントがサービスに送ることができるメッセージ・セット全体のうちのサブセットを判別することができる。分散コンピューティング環境ではアクセスの１つまたは複数のレベルをサービスに設定できる。あるレベルのアクセスでは、サービスのクライアントはそのサービスに対するメッセージ・スキーマによる要求メッセージのすべてにアクセスすることができ、したがって、サービスが分散コンピューティング環境でクライアントに提供している実質的にすべての機能にアクセスできる。他のレベルでは、サービスのクライアントはメッセージ・スキーマによる要求メッセージのさまざまなサブセットにアクセスすることができ、したがって、サービスの機能のさまざまなサブセットにアクセスすることができる。一実施形態では、アクセスのレベルもクライアントの能力によって決まる。たとえば、シンクライアントは、大きなデータ・ファイルをダウンロードできず、したがって、大きなデータ・ファイルのダウンロードを要求するメッセージを使用することは制限される。一実施形態では、クライアントはクライアントに関する情報を認証サービスに提供し、そのクライアントのアクセス・レベルを判別できるようにする。一実施形態では、情報にはサービスに対する特定のレベルのアクセスの要求を含めることができる。一実施形態では、ゲート・ファクトリは情報を認証サービスに提供し、そのクライアントのアクセス・レベルを判別できるようにする。そこで、ゲート・ファクトリは、メッセージ・スキーマで記述されているメッセージ・セット全体のサブセットをクライアントの能力および／またはアクセス・レベルに基づいてサービスに送ることができるクライアント・メッセージ・ゲートを生成する。
【０３４６】
ステップ１０１４で、ゲート・ファクトリは、クライアント・メッセージ・ゲートを生成しており、ゲートは生成されたことをクライアントに通知することができる。一実施形態では、クライアント・メッセージ・ゲートはクライアントによってアクセス可能な別個のコード・モジュールである。一実施形態では、クライアント・メッセージ・ゲートは、クライアントに常駐する。クライアントは、メッセージを生成し、そのメッセージをクライアント・メッセージ・ゲートに渡し、このゲートにより、メッセージを検証し、メッセージをサービスに送ることができる。クライアントおよびサービスでメッセージを交換するためのゲート・ペア・メカニズムの実施形態は図４２ａ〜４２ｃに詳しく示されている。ゲート・ファクトリの実施形態については別のところで詳述する。ゲートは、コードとデータからなり、それ自体はメッセージで渡すことができる。このため、クライアントおよび／またはサービス上にゲートを作成する代替方法となる。一実施形態では、メッセージで渡されたゲートは、新しいクライアントがそのゲートを使用することを望んでいる場合、クローンが作成される。このクローン作成プロセスでは、新しいクライアントの認証を含むゲート作成セキュリティ・チェックを新たにいくつか実行する。新しいクライアントに対しては新しい一意的な認証証明書が生成されクローンのゲートに埋め込まれる。
【０３４７】
図４２ａ−メッセージをサービスに送るクライアント
図４２ａは、一実施形態によりクライアントが第１のメッセージをサービスに送る方法を示す流れ図である。ステップ１０２０で、クライアントはメッセージをクライアント・メッセージ・ゲートに送る。一実施形態では、メッセージはＸＭＬメッセージである。ステップ１０２２で、メッセージ・ゲートはメッセージを送る前にメッセージに認証証明書を埋め込む。一実施形態では、認証証明書は、上述のように、認証サービスによりゲート構築の一部として提供されている。
【０３４８】
一実施形態では、メッセージ・ゲートは、メッセージのデータ表現言語の型の正しさ、シンタックスなどを検証することができる。一実施形態では、メッセージ・ゲートはメッセージと、データ表現言語メッセージ・スキーマのメッセージ・テンプレートとを比較し、メッセージのデータ表現言語の型の正しさを調べる。一実施形態ではメッセージはＸＭＬメッセージであり、メッセージ・ゲートはＸＭＬメッセージ・スキーマと照らしてメッセージをチェックすることができる。一実施形態では、メッセージ・スキーマは、上述のように、認証サービスによりゲート構築の一部として提供されている。一実施形態では、メッセージ・ゲートはメッセージのメッセージ・テンプレートをスキーマに配置し、メッセージ内のさまざまなアイテムまたはフィールドをそのメッセージ・テンプレートと比較して、アイテムの型の正しさを判別する。
【０３４９】
一実施形態では、第１のメッセージはクライアントから受け取ったサービスに送られる要求メッセージであり、メッセージ・ゲートは、メッセージおよび／またはメッセージで指定された要求サービス機能が、クライアントによってサービスに送ることができるメッセージおよび／またはサービス機能の許容されるサブセット内にあるかどうかを判別することができる。一実施形態では、メッセージ・ゲートはメッセージをメッセージ・スキーマによる許容されるメッセージのサブセットと比較し、メッセージが許容されるものであるかどうかを判別する。一実施形態では、認証サービスによってクライアントに提供されるサービスはアクセス・レベルを使用して、クライアントによりサービスに送られる許容されるメッセージのサブセットを判別することができる。一実施形態では、第１の要求メッセージは、クライアントと通信チャンネルの確立をサービスに要求する。一実施形態では、通信チャネルはゲート・ペアで構成される。ゲート・ペアは、クライアント・メッセージ・ゲートとサービス・メッセージ・ゲートからなる。一実施形態では、サービス・メッセージ・ゲートは、第１のメッセージがサービスに送られたときにはサービス上に存在していない。
【０３５０】
ステップ１０２４で、クライアント・メッセージ・ゲートはクライアントをサービスに接続する通信チャネルを介して第１のメッセージをサービスに送る。一実施形態では、クライアント・メッセージ・ゲートは、メッセージをサービスのＵＲＩに送る。一実施形態では、サービスＵＲＩが、サービス通知でクライアントに提供されている。一実施形態では、クライアント・メッセージ・ゲートが特定のサービスＵＲＩについて作成され、すべてのメッセージは特定のサービスＵＲＩに発送され、そのためクライアントからサービスへのメッセージ・チャネルが作成される。一実施形態では、要求メッセージはクライアント・メッセージ・ゲートのアドレスを含むので、サービスはクライアント・メッセージ・ゲートを通じてクライアントとの通信リンクを確立できる。メッセージ・ゲートに使用できるアドレスの例として、それに限定されないがＵｎｉｖｅｒｓａｌ　Ｕｎｉｑｕｅ　Ｉｄｅｎｔｉｆｉｅｒｓ（ＵＵＩＤ）やＵＲＩがある。サービスがクライアントから第１のメッセージを受け取るプロセスは図４２ｂに示され説明されている。
【０３５１】
図４２ｂ−メッセージをクライアントから受け取るサービス
図４２ｂは、一実施形態によりクライアントからメッセージ受け取り、認証サービスを使用してメッセージを認証するサービスを示す流れ図である。ステップ１０３０で、サービスは、クライアントから第１のメッセージを受け取る。一実施形態では、サービス・メッセージ・ゲートは、第１のメッセージがサービスによって受け取られたときにはサービス上に存在していない。一実施形態では、クライアント・メッセージ・ゲートは第１のメッセージをそのサービスのＵＲＩに送り、サービスはクライアントから第１のメッセージを受け取り、その後、サービス・メッセージ・ゲートを生成する。一実施形態では、サービスに関するメカニズムを構成することにより、一般にサービス通知でクライアントに送られるＵＲＩでクライアントからのメッセージを含むメッセージを受け取るようにする。クライアントから第１のメッセージを受け取ると、サービスはサービス・ゲートを生成し、サービス・メッセージ・ゲートとクライアント・メッセージ・ゲートからなるゲート・ペアを通じてクライアントとの通信チャネルを確立する。一実施形態では、クライアント・メッセージ・ゲートのアドレス（たとえば、ＵＵＩＤまたはＵＲＩ）をクライアントから第１のメッセージでサービスに送り、これを使用してサービス・メッセージ・ゲートを生成する。一実施形態では、サービス・メッセージ・ゲートはクライアント・メッセージ・ゲートとのみ通信し、したがってメッセージ・ゲートと関連するクライアントと通信する。そこで、いくつかの実施形態では、少なくとも１つの一意的なサービス・メッセージ・ゲートが、サービスと現在通信中のクライアントごとに存在する。
【０３５２】
上述のように、クライアント・メッセージ・ゲートは認証証明書を、サービスに送られる第１のメッセージ内に埋め込んでいる。ステップ１０３２で、サービスは認証証明書を認証サービスに送る。一実施形態では、認証サービスはクライアントが認証証明書を生成するために使用するのと同じ認証サービスである。一実施形態では、サービス・メッセージ・ゲートが認証証明書を認証証明書に送る。一実施形態では、メッセージ全体が認証サービスに送られる。
【０３５３】
ステップ１０３４で、認証サービスは認証証明書の検証を実行する。一実施形態では、認証サービスは認証証明書を作成したときの認証証明書のコピーを含む。一実施形態では、認証サービスはサービスから受け取った認証証明書と認証証明書のコピーとを比較する。ステップ１０３６で認証証明書がマッチした場合、認証サービスは、認証証明書は検証され、有効であるように思われることをサービスに通知する。検証プロセスが失敗した場合、認証サービスは、認証証明書が無効であるように思われることをサービスに通知する。
【０３５４】
一実施形態では、認証サービスはサービスの機能にアクセスするクライアントのアクセス・レベルを設定できる。一実施形態では、クライアントは、認証サービスでサービスのアクセス・レベルを設定済みである。一実施形態では、認証サービスはクライアントのアクセス・レベルをサービスに通知する。サービス側ではクライアントのアクセス・レベルを使用して、クライアントがサービスに送るサービス・メッセージ・スキーマで記述されているとおり要求メッセージのサブセットを判別する。
【０３５５】
ステップ１０３８で、認証サービスが、ステップ１０３６で認証証明書は有効であるとサービスに通知した場合、サービスはクライアント・ゲートとのペアを組むサービス・メッセージ・ゲートを生成し、ゲート・ペアを形成する。サービス・メッセージ・ゲートは、サービスからクライアントに送られたメッセージに埋め込み、クライアントから受け取ったメッセージ内の認証証明書と比較するための認証証明書を含む。サービス・メッセージ・ゲートはさらにクライアント・メッセージ・ゲートのアドレス（ＵＵＩＤやＵＲＩなど）を含む。サービス・メッセージ・ゲートは、さらに、クライアントから受け取ったメッセージがクライアントによってサービスに送られる許容されるメッセージのサブセット内に含まれることを検証するためのクライアントのアクセス・レベル情報を含むことができる。サービス・メッセージ・ゲートはさらに、クライアントから受け取ったメッセージの型検査およびシンタックスの検証を行い、メッセージがメッセージの許容されるサブセット内に含まれるかどうかを検証する際に使用するメッセージ・スキーマも含む。一実施形態では、サービスは新しいサービス・メッセージ・ゲートを作成することができる。他の実施形態では、クライアントと通信するためにサービス・メッセージ・ゲートを生成するのに使用できるサービス・メッセージ・ゲートがステップ１０３８の前にすでに存在する。この実施形態では、サービスは新しいゲートを作成せず、その代わりに、既存のゲートを、クライアントとサービスとの間に確立されるメッセージ・チャネルに関する情報で更新することができる。
【０３５６】
一実施形態では、サービスは、サービス・メッセージ・ゲート生成した後、メッセージをクライアントに送る。このメッセージは、クライアント・メッセージ・ゲートに対しサービス・メッセージ・ゲートを識別し、メッセージ・ゲート・ペアを使用してクライアントとサービスとの間に通信チャネルを確立するための情報を含む。一実施形態では、メッセージは、サービス・メッセージ・ゲートのアドレス（ＵＵＩＤやＵＲＩなど）を含む。
【０３５７】
図４２ｃ−認証証明書が埋め込まれているメッセージの交換
図４２ｃは、一実施形態によりクライアントおよびサービスがメッセージを埋め込まれた認証証明書と交換する一般的プロセスを示す流れ図である。一実施形態では、クライアント・メッセージ・ゲートとサービ・スメッセージ・ゲートは確立された後、クライアントおよびサービスは認証サービスのサービスを必要としなくなる。クライアント・メッセージ・ゲートおよびサービス・メッセージ・ゲートは、メッセージを送るときに、認証証明書をメッセージに埋め込む。クライアント・メッセージ・ゲートとサービス・メッセージ・ゲートは、メッセージを受け取るときに、埋め込まれている認証証明書とゲートに含まれる認証証明書のコピーとを比較することにより、メッセージを検証することができる。
【０３５８】
ステップ１０４０で、発送側側（クライアントまたはサービス）メッセージ・ゲートは、メッセージを送る前にメッセージに認証証明書を埋め込む。一実施形態では、認証サービスによって認証証明書が提供されている。一実施形態では、メッセージはＸＭＬメッセージである。一実施形態では、発送側メッセージ・ゲートは、メッセージを送る前にメッセージのデータ表現言語の型の正しさ、シンタックスなどを検証することもできる。一実施形態では、発送側メッセージ・ゲートはメッセージと、メッセージ・スキーマのメッセージ・テンプレートとを比較し、メッセージの型の正しさを調べる。たとえば、メッセージはＸＭＬメッセージであり、メッセージ・ゲートはＸＭＬメッセージ・スキーマを含む。発送側メッセージ・ゲートはメッセージのメッセージ・テンプレートをスキーマに配置し、メッセージ内のさまざまなＸＭＬアイテムまたはフィールドをそのメッセージ・テンプレートと比較して、アイテムの型の正しさを判別する。
【０３５９】
一実施形態では、発送側メッセージ・ゲートは、メッセージが許容可能であるかどうかをチェックする。一実施形態では、メッセージはクライアントから受け取ったサービスに送られる要求メッセージであり、メッセージ・ゲートは、メッセージで指定された要求サービス機能が、認証サービスを通じてクライアント側でサービスと確立したアクセス・レベルによりクライアントに提供される機能のサブセット内にあるかどうかを判別する。一実施形態では、メッセージ・ゲートはメッセージをメッセージ・スキーマによる許容される要求メッセージのサブセットと比較し、メッセージが許容されるものであるかどうかを判別する。一実施形態では、メッセージがサービスからクライアントへの応答メッセージである場合に、メッセージの許容可能性をチェックしない。他の実施形態では、サービスからクライアントへの応答メッセージはクライアント・メッセージ・ゲートによりチェックされ、クライアントが応答メッセージを受け取ることを承認されていることを確認する。
【０３６０】
ステップ１０４２で、発送側（クライアントまたはサービス）メッセージ・ゲートは、発送元（クライアントまたはサービス）を宛先（クライアントまたはサービス）に接続する通信チャネルを介してメッセージを宛先（クライアントまたはサービス）メッセージ・ゲートに送る。一実施形態では、受取側メッセージ・ゲートは、メッセージを受け取るときに、埋め込まれている認証証明書とゲートに含まれる認証証明書のコピーとを比較することにより、メッセージの発送側を検証することができる。
【０３６１】
一実施形態では、メッセージは発送の前に暗号化する。一実施形態では、メッセージ・ゲートは暗号化を実行できる。他の実施形態では、メッセージ・ゲートの外部のプロセスが暗号化を実行できる。たとえば、メッセージ・ゲートは通信チャネルで完了したメッセージをドライバ・プロセスに渡し、ドライバ・プロセスはメッセージの暗号化を実行する。一実施形態では、メッセージの暗号化および復号化は、トランスポート・メカニズム（たとえば、ＨＴＴＰＳ）により実行される。
【０３６２】
ステップ１０４４で、受取側（クライアントまたはサービス）メッセージ・ゲートは、ステップ１０４２で送られたメッセージを受け取る。一実施形態では、メッセージが暗号化された場合、メッセージはメッセージ・ゲートにより受け取る前にプロセスによって復号化する。他の実施形態では、メッセージが暗号化されている場合、メッセージ・ゲートはそのメッセージを復号化する。ステップ１０４６で、受取側メッセージ・ゲートは、埋め込まれている認証証明書と受取側ゲートに含まれる認証証明書のコピーとを比較することにより、メッセージの発送側を検証することができる。
【０３６３】
いくつかの実施形態では、少なくともいくつかのクライアントについて認証証明書を必要としないサービスもある。一実施形態では、クライアントに対し認証証明書を必要としないサービスにアクセスするクライアントは認証サービスを使用せずにメッセージ・ゲートを生成することができる。他の実施形態では、認証サービスはＮＵＬＬ、空、またはその他の何らかの汎用認証証明書を、サービスを使用するのに認証を必要としないクライアントに返す。認証を必要としない一実施形態では、メッセージ・ゲートは認証証明書を埋め込まずにメッセージを送る。他の実施形態では、ＮＵＬＬ、空、またはその他の何らかの汎用認証証明書をメッセージ・ゲートによってメッセージに埋め込むことができる。
【０３６４】
一実施形態では、受取側メッセージ・ゲートは、メッセージを受け取った後、メッセージのデータ表現言語の型の正しさ、シンタックスなどを検証することができる。一実施形態では、受取側メッセージ・ゲートはメッセージと、メッセージ・スキーマのメッセージ・テンプレートとを比較し、メッセージの型の正しさを調べる。たとえば、メッセージはＸＭＬメッセージであり、メッセージ・ゲートはＸＭＬメッセージ・スキーマを含む。受取側メッセージ・ゲートはメッセージのメッセージ・テンプレートをスキーマに配置し、メッセージ内のさまざまなＸＭＬアイテムまたはフィールドをそのメッセージ・テンプレートと比較して、アイテムの型の正しさを判別する。
【０３６５】
一実施形態では、受取側メッセージ・ゲートは、メッセージが許容可能であるかどうかをチェックする。一実施形態では、メッセージはクライアントから受け取った要求メッセージであり、メッセージ・ゲートは、メッセージで指定された要求サービス機能が、認証サービスを通じてクライアント側でサービスと確立したアクセス・レベルによりクライアントに提供される機能のサブセット内にあるかどうかを判別する。一実施形態では、受取側メッセージ・ゲートはメッセージをメッセージ・スキーマによる許容される要求メッセージのサブセットと比較し、メッセージが許容されるものであるかどうかを判別する。
【０３６６】
一実施形態では、発送側および受取側はメッセージの型の正しさおよび／または許容可能性を検証することができる。他の実施形態では、発送側はメッセージの検証を実行する。さらに他の実施形態では、発送側はメッセージ検証を実行せず、受取側がメッセージ検証を実行する。さらに他の実施形態では、検証を一切実行しない。
【０３６７】
いくつかのクライアントはクライアント・メッセージ・ゲートの全機能をサポートするには「軽量（シン）」過ぎる。これらのクライアントは、上述のように要求メッセージを送る前の要求メッセージ検証および応答メッセージを受け取った後の応答メッセージ検証を一部または全部実行しない。たとえば、いくつかの単純なクライアント・デバイスはサービスに送ることができる小さな要求メッセージ・セットとサービスから受け付けることができる小さな応答セットを含む。一実施形態では、上述のように、メッセージ検証を実行せずに要求メッセージを送り、応答メッセージを受け取るクライアント・デバイスに対し最小のクライアント・メッセージ・ゲートを構築することができる。他の実施形態では、クライアントに対して上述のようにメッセージの検証、発送、および受取の機能の一部または全部を備える他のデバイスにプロキシ・クライアント・メッセージ・ゲートを設定することができる。
【０３６８】
図４３−メッセージの完全性のチェック
図４３は、一実施形態によりメッセージの完全性を確認するメカニズムを示す流れ図である。ステップ１０５０で、発送側ゲートは、クライアントまたはサービスの代わりに機能し、送るメッセージ内にトークンを埋め込む。このトークンは、上述のように、認証証明書をから分離され、区別される。このトークンは、受取側ゲートがメッセージが損なわれていない、あるいは改変されていないことを検証できるようにする情報を含む。たとえば、発送側は、受取側が検証するメッセージのハッシュまたはチェックサムを計算することができる。発送側はさらに、発送側の秘密鍵を使用してこのトークンおよび／またはメッセージ全体を暗号化し、暗号化されたメッセージに対応する公開鍵を含め、トークンが変更されていないことを受取側が検証できるようにする。ステップ１０５２で、発送側ゲートがメッセージを送る。ステップ１０５４で、受取側ゲートは、サービスまたはクライアントのために機能し、メッセージを受け取る。ステップ１０５６で、受取側ゲートはメッセージおよび埋め込まれたトークンを調べ、メッセージが損なわれていないことを検証する。
【０３６９】
メッセージに埋め込むトークンを生成する方法がいくつかある。一実施形態では、メッセージのハッシュを計算し、それをメッセージとともに送る。ハッシュ法は、文字列を元の文字列を表す通常短い固定長の値または鍵に変換する操作を含む。メッセージを受け取ると、受取側はそのハッシュを再計算し、送られたハッシュに照らしてチェックする。メッセージが改変されていた場合、同じハッシュが生成される可能性はほとんどない。発送側は、ハッシュを暗号化し、対応する公開鍵を暗号化されたメッセージに入れて送り、そのハッシュが損なわれないように実質的に保証する。他の実施形態では、巡回冗長検査などの誤り検出方式を使用する。巡回冗長検査は、通信リンクで送られたデータ内にエラーがないか調べる方法である。巡回冗長検査を使用する実施形態では、発送側はｎビットの多項式をメッセージに適用し、その結果の巡回冗長検査（ＣＲＣ）をメッセージに付加する。受取側は、同じ多項式（メッセージでも渡される）をメッセージに適用し、その結果を発送側が付加した結果と比較する。マッチする場合、メッセージは正常に受け取られたということである。マッチしない場合、発送側はメッセージの再送を通知される。他の実施形態には、生成、埋め込み、およびメッセージ内のエラーまたは悪意ある改ざんの有無をチェックするトークンのチェックのため他の方法が含まれる。
【０３７０】
デバイスを分散ネットワーク環境にブリッジする方法
分散コンピューティング環境で実装されるメッセージ通信モデルをサポートしないデバイスが、分散コンピューティング環境の外部にある。これらのデバイスは、分散コンピューティング環境のクライアントにとって有用と思われるサービスを備えている場合がある。分散コンピューティング環境には、このような外部デバイスを分散コンピューティング環境にブリッジするメカニズムが備えられている。分散コンピューティング環境内のクライアントはこのようなデバイスに用意されているサービスにアクセスすることができる。分散コンピューティング環境ではさらに、分散コンピューティング環境で使用するこのような外部デバイスを発見するため既存のデバイス発見プロトコルを活用することができる。
【０３７１】
多くの技術が、ネットワークのデバイス構成をパブリッシュし、監視するための発見プロトコルを定義している。これらの技術には、これらに限定されないが、Ｊｉｎｉ、ＳＬＰ、Ｂｌｕｅｔｏｏｔｈ、ＵＰｎＰがある。さらに、ＬｏｎＷｏｒｋｓ、ＵＳＢ、および１３９４などの多くの入出力バスも動的発見プロトコルをサポートしている。分散コンピューティング環境では、実装をＡＰＩでラップすることにより、デバイス発見技術を活用する。他のデバイス発見プロトコルを活用し、他の発見プロトコルにブリッジする方法を使用することにより、分散コンピューティング環境で、さまざまなネットワークおよび入出力バス上のデバイスまたはサービスを発見することができる。分散コンピューティング環境のデバイス発見は、したがって、分散コンピューティング環境に直接参加していなくても、ＰＤＡなどの小型デバイスを含むさまざまなデバイスに応用できる。発見プロトコルは、メッセージ・レベルで定義することができる。
【０３７２】
ブリッジ・メカニズムは、分散コンピューティング環境用のメッセージングＡＰＩでＢｌｕｅｔｏｏｔｈなどの１つまたは複数のを特定のデバイス発見プロトコルを「ラップ」する方法として提供される。ラップでは、コードおよび／またはデータ（ＡＰＩ）でデバイス発見プロトコルの枠組みを作り、プロトコルを分散コンピューティング環境内のクライアントおよび／またはサービスによって実行できるようにするが、そうでないとこれは実行できない。ブリッジ・メカニズムを実行すると、特定のデバイス発見プロトコルによりデバイスを発見する発見エージェントが分散コンピューティング環境のスペース内のデバイスに対しサービスをパブリッシュすることができる。サービスが分散ネットワーク環境でＸＭＬメッセージ・スキーマ・インターフェースをクライアントに提示し、特定のデバイス発見プロトコルにより発見されたさまざまなデバイスを動作させることができる。したがって、サービス通知は、基礎のラップされたデバイス発見プロトコルにより発見されたさまざまなデバイスを動作させるサービスに対してパブリッシュされる。そこで、通知されたサービスは、分散ネットワーク環境の外部にあるデバイス（またはサービス）を分散ネットワーク環境上のクライアントにブリッジする。
【０３７３】
図２７は、スペース１２００を持つ分散コンピューティング環境の一実施形態を示している。１つまたは複数の発見エージェント１２０４が、外部発見プロトコルに参加し、ブリッジ・メカニズム１２０２を通じて分散コンピューティング環境にブリッジする。ラップされたデバイス発見プロトコルを実行すると、ブリッジ・メカニズム１２０２を介した発見エージェント１２０４はスペース１２００内のサービス通知１２０６ａ〜１２０６ｃをパブリッシュし、そこで、通知１２０６ａ〜１２０６ｃのそれぞれが分散コンピューティング環境の外部にある発見プロトコル１２０４のうちの１つにより発見されるデバイスまたはサービスに対応する。クライアントは、その後、スペース１２００内のサービス通知１２０６ａ〜１２０６ｃを使用して外部デバイスにアクセスし、対応する外部デバイスまたはサービスを動作させるエージェント１２０４のうちの１つでサービスをインスタンス化する。
【０３７４】
そこで、分散コンピューティング環境のクライアントは、デバイス発見プロトコルをラップする発見エージェントを使用してデバイスを見つける。これらのデバイスとのブリッジとして機能するサービスをスペース内でパブリッシュし、通知して、分散コンピューティング環境のクライアントが外部デバイスによって提供されるサービスにアクセスできるようにする。通知されたサービスは、他のプロトコルまたは環境により分散コンピューティング環境の外部のデバイスを呼び出すことができる分散コンピューティング環境内のサービスであり、外部のデバイス／サービスを分散コンピューティング環境にブリッジする。分散コンピューティング環境内のクライアントは、分散コンピューティング環境内の通知されたサービスのみを「見」、外部のデバイス／サービスに気付くことすらしない。
【０３７５】
一実施形態では、分散コンピューティング環境は上述のラップされたデバイス発見プロトコルを含む基礎の外部デバイス発見プロトコルにマップされる、「スペース」の項で説明した発見プロトコルなどの特定のバージョンのスペース発見メッセージ・プロトコルを提供する。マップされた発見プロトコルは、スペース、デフォルト・スペースに自己登録するかまたは登録されるが、その際に、そのスペースに通知を入れる。通知される発見プロトコルごとに、発見プロトコルの結果を保持する後続の結果スペースが提供される。
【０３７６】
図２８は、一実施形態によりＢｌｕｅｔｏｏｔｈ発見サービス１２２０にマップされるスペース発見プロトコルの一例の図である。Ｂｌｕｅｔｏｏｔｈ発見サービス１２２０は、まず、分散コンピューティング環境に登録する１２３０。Ｂｌｕｅｔｏｏｔｈ発見サービス１２２０は、ブリッジＡＰＩでラップされ、発見サービス１２２０の通知１２２５がスペース１２２４に追加される１２３２。クライアントまたはサービスが、スペース１２２４上の発見サービス通知１２２５を特定する。発見サービス１２２０が実行されると（発見プロトコル１２２０と分散コンピューティング環境１２２２との間のブリッジとしてＡＰＩラッパを使用して）、発見プロセスの結果を格納するための新しいスペース１２２６が作成される１２３４。発見サービス１２２０は、それらの結果を（再び、ＡＰＩラッパを使用して）１つまたは複数の通知１２２７として発見結果スペース１２２６に格納する。それとは別に、発見サービス１２２０を実行した結果は分散コンピューティング環境のスペース１２２４または他の既存のスペースに格納される。図２８に示されているような方法を使用してデバイスを発見し、他の基礎の発見プロトコルを使用して他のサービスを発見する。
【０３７７】
上述のように、分散ネットワーク環境で実装されるメッセージ通信モデルをサポートしないデバイスが、分散ネットワーク環境の外部にある。これらのデバイスは、分散コンピューティング環境で提供されるサービスを使用する必要があるクライアントを備えることもある。分散コンピューティング環境は、外部クライアントまたはクライアント・デバイスを分散コンピューティング環境にブリッジするメカニズムが備えられており、外部デバイスのクライアントは分散コンピューティング環境内のサービスにアクセスすることができる。
【０３７８】
分散コンピューティング環境でクライアントとして使用されるエージェントを用意し、外部クライアントを分散コンピューティング環境にブリッジし、外部クライアントが分散コンピューティング環境内でパブリッシュされているサービスにアクセスできるようにする。一実施形態では、エージェントは、フロント・エンドでメッセージ通信モデルと専用プロトコル（たとえば、外部デバイスによってサポートされているプロトコル）を使用して外部デバイスにインターフェースし、さらに外部クライアントにインターフェースする分散コンピューティング環境内のサービスと通信することができるＸＭＬ対応バックエンドを備える。したがって、分散コンピューティング環境の外部のクライアントは、ブリッジ・エージェントを通じて分散コンピューティング環境内のサービスを特定してアクセスし、要求をサービスに送って結果データを含む応答をサービスから受け取ることができる。たとえば、外部クライアントは分散コンピューティング環境でブリッジ・エージェントを使用してスペース発見を実行し、通知されたサービスを検索し、分散コンピューティング環境内のサービスを呼び出す。
【０３７９】
一実施形態では、分散コンピューティング環境は分散コンピューティング環境クライアントからＪｉｎｉサービスにアクセスするためのブリッジ・メカニズムを備える。Ｊｉｎｉサービスはリモート・メソッド呼び出し（ＲＭＩ）を必要とし、また分散コンピューティング環境内のクライアントはＸＭＬメッセージなどのメッセージを使用してサービスと通信するので、分散コンピューティング環境クライアントによりＪｉｎｉサービスへのアクセスを可能にするプロトコル・ブリッジ・メカニズムを提供できる。一実施形態では、分散コンピューティング環境のスペース内でＪｉｎｉサービスの動的通知を有効にし、さらに分散コンピューティング環境内のクライアントからＪｉｎｉサービス・プロキシのアクセスを有効にすることができるコネクタ・メカニズムを定義する。一実施形態では、分散コンピューティング環境にブリッジできないＪｉｎｉサービスもある。
【０３８０】
一実施形態では、Ｊｉｎｉサービスによって使用されるＪｉｎｉ　ＲＭＩプロトコルを分散コンピューティング環境のクライアントによって使用されるＸＭＬメッセージングにブリッジするエージェントを分散コンピューティング環境内のサービスとして提供することができる。エージェントを起動すると、エージェントはＪｉｎｉスペースで一組の属性を持つＪｉｎｉサービスの検索を実行する。登録されているすべてのＪｉｎｉサービスについて、エージェントは、サービスに対応するＸＭＬ通知を生成し、分散コンピューティング環境内のスペースで通知を登録する。一実施形態では、エージェントは、Ｊｉｎｉルックアップ・サービスのイベント通知について登録でき、新しいＪｉｎｉサービスが登録されると実行される。新しいＪｉｎｉサービスが通知されると、エージェントはＪｉｎｉスペースで検索を実行し、新たに通知されたＪｉｎｉサービスを特定し、分散コンピューティング環境のスペースを新しいサービスに対する新しいＸＭＬ通知で更新する。一実施形態では、Ｊｉｎｉサービスが削除されると、エージェントはＪｉｎｉサービスの削除を通知するイベントを受け取る。エージェントは、サービスのＸＭＬ通知をスペースから削除する。
【０３８１】
一実施形態では、分散コンピューティング環境のスペースのＸＭＬ通知を介してＪｉｎｉサービスを呼び出すには、クライアントはスペース内のサービス通知を検索し、有効なメッセージをエージェントに送ってサービスにアクセスする。エージェントは、サービス・プロキシに対するＲＭＩコールを介して対応するメソッドを呼び出してＪｉｎｉサービスに対応するプロキシ・サービスを呼び出す。プロキシがインスタンス化されていない場合、エージェントはプロキシ・コードをダウンロードし、プロキシ・オブジェクトの新しいインスタンスをインスタンス化する。一実施形態では、すべてのクライアント接続は異なるプロキシ・インスタンスを持つ。クライアントから着信したメッセージは、エージェントによってプロキシのメソッド・コールに変換される。メソッド・コールからの結果は発送メッセージとしてクライアントに返される。
【０３８２】
一実施形態では、ＲＭＩメソッドへの引数として、単純なＪａｖａの型のみを使用できる。Ｊａｖａの複合型が必要な場合、１つまたは複数のデータ通知をコールの引数として渡し、データ通知はＪａｖａ複合型のデータの位置とアクセス方法を示す。一実施形態では、エージェントがＸＭＬメッセージがＲＭＩメソッド・コール呼び出しへの初期変換を動的に実行する。エージェントはサービス・インターフェースを認識するので、クライアントに通知される対応するメッセージ・セットを生成する。
【０３８３】
図２９は、分散コンピューティング環境の外部にあるクライアント１２５０を分散コンピューティング環境内のスペース１２５４にブリッジする方法を示す図である。ブリッジ・エージェント１２５２は、クライアント１２５０とスペース１２５４との間の仲介者として使用される。ブリッジ・エージェント１２５２は、クライアント１２５０が理解できる通信プロトコルでクライアント１２５０と通信する。ブリッジ・エージェント１２５２は、クライアントの通信プロトコルを、スペース１２５４によって提供される機能を実行するためにスペース１２５４と通信するために必要なＸＭＬメッセージング・プロトコルにマップする。ブリッジ・エージェント１２５２は、クライアント１２５０の要求があったときに、スペース１２５４上のサービスを特定して実行する。たとえば、クライアント１２５０は、スペース１２５４に特定のタイプのすべてのサービスのリストを要求することができる。ブリッジ・エージェント１２５２は、サービス通知１２５６ａ〜ｃを特定し、結果をクライアント１２５０に返す。それとは別に、結果を結果スペースにポストし、結果の位置をクライアント１２５０に返す。クライアント１２５０は、その後、サービス通知１２５６ａの実行を選択し、メッセージ（クライアント１２５０の通信プロトコルで）をブリッジ・エージェント１２５２に送る。ブリッジ・エージェント１２５２は、そこで、サービス通知１２５６ａによって表されるサービスを実行するのに必要なＸＭＬ要求メッセージを送り、サービスの結果をクライアント１２５０に返す。結果をクライアント１２５０に直接返す以外のサービスの結果の処理方法は、上の「スペース」の項で説明しているように使用できる。ブリッジ・エージェント１２５２は、外部クライアント１２５０のサービスとして機能し（外部クライアントのプロトコルを介して）、また分散コンピューティング環境内のクライアントとして機能して、分散コンピューティング環境内のサービスを外部クライアントにブリッジする。
【０３８４】
ときには、分散コンピューティング環境内であっても、クライアントおよびサービスは互いに直接通信し、また共通のスペースとのみ通信することはできない。この場合、スペース・サービスはクライアント・サービスにブリッジするサービス・プロキシを自動的に作成する。プロキシの主要な役目は、スペースを介してクライアントとサービスとの間でメッセージをやりとりすることである。サービス・プロキシは動的に作成される。作成メカニズムは、スペースの実装に左右される。プロキシ・メカニズムの説明については、図３０を参照のこと。クライアント５５４およびサービス５５６は、たとえば、これらが異なるトランスポートまたはネットワーク・プロトコルをサポートしているため、分散コンピューティング環境内で直接通信することができない場合がある。ただし、両方とも両方のプロトコルをサポートするスペース５５２とは通信できる。スペース・サービスは、クライアント５５４をサービス５５６にブリッジするプロキシ５５０を作成する。プロキシの共通の形態はブラウザ・プロキシである。プラザ・プロキシ（サーブレットとして実装されるは最も一般的である）は、従来のＷｅｂページ要求をメッセージに変換する。「スペース」の項のスペースルックアップ・サービス（およびプロキシ）の説明も参照のこと。
【０３８５】
分散コンピューティング環境は、分散コンピューティング環境内のクライアントをエンタプライズ・サービスにブリッジするメカニズムを備える。分散コンピューティング環境の一実施形態では、クライアントをエンタプライズ・サービスにブリッジする方法は、分散コンピューティング環境内のクライアント、分散コンピューティング環境内のブリッジ・サービス、およびエンタプライズ環境内のエンタプライズ・サービスを含む。分散コンピューティング環境のブリッジ・サービスは、クライアントとエンタプライズ・サービスとの間のブリッジ・サービスとして使用される。エンタプライズは、企業、中小企業、非営利団体、政府機関、またはその他の種類の組織である。エンタプライズでは、その事業の一部を実施するためにエンタプライズ・コンピューティング環境を利用する。エンタプライズ・コンピューティング環境は、さまざまなエンタプライズ・サービスを含む。分散コンピューティング環境内のクライアントは、エンタプライズ・コンピューティング環境のサービスを使用することを望んでいる場合がある。エンタプライズ・サービスは、三層クライアント／サーバ・アーキテクチャなどのさまざまなアーキテクチャに基づく。エンタプライズ・サービスを実装するのに使用できるアーキテクチャの一例としてＥｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓがある。Ｅｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓ（ＥＪＢ）は、クライアント／サーバ・モデルを使用してエンタプライズ環境のサーバー部分で実行する、Ｊａｖａプログラミング言語で書かれたプログラム・コンポーネントを設定するアーキテクチャである。オブジェクト指向プログラミングおよび分散オブジェクト技術では、コンポーネントとは、アプリケーションを形成するために分散ネットワーク内で同じコンピュータまたは他のコンピュータ内の他のコンポーネントと組み合わせて再利用可能なプログラムの基本要素のことである。ＥＪＢは、プログラム・コンポーネント（Ｂｅａｎｓ）をネットワーク内のクライアントに配布するＪａｖａＢｅａｎｓ技術に基づき構築されている。ＥＪＢ　Ｂｅａｎまたはコンポーネントを配置するには、コンテナと呼ばれる特定のアプリケーションの一部である必要がある。Ｅｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓには、ｓｅｓｓｉｏｎ　ｂｅａｎｓとｅｎｔｉｔｙ　ｂｅａｎｓの２種類のｂｅａｎｓがある。ｅｎｔｉｔｙ　ｂｅａｎｓは、ｓｅｓｓｉｏｎ　ｂｅａｎｓと異なり、永続性があり、最初の動作または状態を保持できるものである。ＥＪＢを使用すると、実質的にすべての主要なオペレーティング・システムに配置することができる。ＥＪＢのプログラム・コンポーネントは、一般にサーブレット（小さなサーバ・プログラム）と呼ばれている。サーブレットを実行するアプリケーションまたはコンテナは、アプリケーション・サーバと呼ばれることもある。
【０３８６】
ブリッジ・サービスは、ＸＭＬメッセージ通信を介してクライアントと対話し、分散ネットワーク環境の外にあるエンタプライズ・サービスに要求を行うのに必要な入力パラメータを収集する。たとえば、クライアントが分散コンピューティング環境内の他のサービスとまったく同様にブリッジ・サービスを検索し、インスタンス化することができる。ブリッジ・サービスは、エンタプライズ・サービスと対話して、エンタプライズ・サービスを実行する。この対話では、エンタプライズ・サービスが理解できるプロセス間通信アーキテクチャを使用する。たとえば、エンタプライズ・サービスがＥｎｔｅｒｐｒｉｓｅ　ＪａｖａＢｅａｎｓ（ＥＪＢ）で実装されている場合、ブリッジ・サービスはＥＪＢを使用してエンタプライズ・サービスと通信する。ブリッジ・サービスは、エンタプライズ・サービスから結果を受け取り、その結果を直接クライアントに（ＸＭＬメッセージで）返すか、またはその結果を分散ネットワーク環境内のスペース（たとえば、結果スペース）に入れることができる。クライアントからは、ブリッジ・サービスは唯一のサービスのように見えるため（エンタプライズ・サービスはクライアントには隠されている）、クライアントはエンタプライズ・サービスのアーキテクチャをサポートする必要がない。複数の分散ネットワーク環境のクライアントが同じブリッジ・サービス（それぞれ、一意的なゲート・ペアを使用する）を使用して、エンタプライズ・サービスと対話する。
【０３８７】
ブリッジ・サービスまたはその他のエージェントは、分散コンピューティング環境内のスペースでブリッジ・サービス（およびエンタプライズ・サービス）の通知をパブリッシュする。たとえば、ブリッジ・サービスまたはその他のブリッジ・エージェントはＪａｖａリフレクションを使用して、ＥＪＢで実装されているエンタプライズ・システム内のサービスについてＢｅａｎｓを調べ、Ｂｅａｎｓへのブリッジ・サービスのサービス通知を作成し、分散コンピューティング環境内のスペースにそれらの通知をパブリッシュする。リフレクションは、クラスのフィールド、メソッド、およびコンストラクタに関する情報を発見し、セキュリティ制限の範囲内でオブジェクトに対する基礎の対応する部分の上で動作するリフレクトされたフィールド、メソッド、およびコンストラクタを使用するＪａｖａコードのメソッドである。リフレクションＡＰＩは、ターゲット・オブジェクトの公開メンバまたは所定のクラスで宣言されているメンバのいずれかにアクセスするのが必要なアプリケーションに対応している。ブリッジ・サービスが通知されると、クライアントは、サービスを提供するエンタプライズ・サービスのアーキテクチャを詳細を知ることなく、分散ネットワーク環境内の他の通知されたサービスと同様にブリッジ・サービス（およびしたがって対応するエンタプライズ・サービス）にアクセスできる。
【０３８８】
クライアントのディスプレイ
クライアントによって実行されたサービスからの結果を分散コンピューティング環境内で表示する方法はいくつかある。結果を表示するデバイスとしては、コンピュータのＣＲＴ、ラップトップのＬＣＤ、ノートブック・パソコンのディスプレーなど、プリンタ、スピーカ、および視覚的、聴覚的、またはその他の知覚可能な形式でサービスの結果を表示できるその他のデバイスがある。結果を表示する方法にはそれに限定されないが、次のものがある。
サービスが結果をクライアントに直接、または参照により返し、クライアントはそれらの結果の表示を処理する。
サービスが結果をクライアントに直接、または参照により返し、クライアントはそれらの結果を表示サービスに直接、または参照により渡し、表示サービスがそれらの結果を表示する。
サービスが結果の表示を直接処理する。
サービスが結果を表示サービスに直接、または参照により渡し、表示装置はそれらの結果を表示する。
【０３８９】
結果を表示する最後の方法では、クライアントが表示サービスを指定する。たとえば、クライアントがサービスの結果を表示するために使用することを望んでいるクライアントが常駐するデバイスの表示サービスまたは関連する表示サービスがある。クライアントがサービスを実行すると、クライアントはメッセージをサービスに送り、クライアントの表示サービスのサービス通知を指定する。その後、サービスは、ゲートを構築し、メッセージをクライアントの表示サービスに送ることができるようにする。したがって、結果を表示するとき、クライアントによって呼び出されたサービスはクライアントの表示サービスのクライアントとなり、その結果を（直接または参照により）表示のためその表示サービスに送る。クライアント−サービス間の関係、ゲート、およびメッセージングの詳細については、本書の他の項を参照のこと。
【０３９０】
従来のアプリケーション・モデルは、通常、所定のおおむね静的なユーザ・インターフェースおよび／またはデータ特性に基づく。従来のアプリケーションに変更を加えるには、コードを修正し再コンパイルする必要がある。サービスを通知し、分散コンピューティング環境のサービスと通信するためのＸＭＬメッセージ・スキーマを指定するための記述されたメカニズムを使用して、アプリケーション（クライアント、サービス、など）が自動的に表示オブジェクトの記述するためのメカニズムを提供する。動的表示オブジェクトを使用すると、新しいコードをダウンロードしたり、アプリケーションを再コンパイルしたり、アプリケーションを再リンクすることなく、アプリケーションの動作を変更することができる。同じ結果を異なる形式で表示する、表示のため結果の一部を抽出する、および異なる表示デバイスに結果を表示する表示スキーマを提供する。
【０３９１】
図３１は、一実施形態による関連するディスプレイ１３０２および表示サービス１３０４を備えるクライアント１３００の一実施形態の図である。表示サービス１３０４の通知１３０６をスペース１３０８に登録する。サービス１３１０の通知１３１２をサービス１３１０によりスペース１３１４に登録する。それとは別に、サービス通知１３１２および表示サービス通知１３０６を同じスペース上に登録する。クライアント１３００は、スペース１３１４上のサービス通知１３１２を検索し発見して１３２０、サービス１３１０に要求を送る（サービス１３１０から結果または応答を受け取る）ためのゲートを設定する。一実施形態では、メッセージは通知１３１２の一部として受け取ったＸＭＬスキーマで指定したＸＭＬメッセージの形式である。クライアント１３００は、１つまたは複数のメッセージ（１３２２）をサービス１３１０に送る。この１つまたは複数のメッセージは、サービス１３１０を実行するメッセージと、表示のため結果を表示サービス１３０４に送るようサービス１３１０に命令するメッセージを含み、表示サービス通知１３０６の位置を指定する。通知の位置は、Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）として指定する。
【０３９２】
クライアント１３００からサービス１３１０にメッセージを命令として送ると、サービス１３１０は表示可能な結果を出力する１つまたは複数のオペレーションを実行する。サービス１３１０は、クライアント１３００から受け取った位置情報に基づいてスペース１３０８から表示サービス通知１３０６を取り出す。サービス通知は、ＸＭＬメッセージ・スキーマと、表示サービス１３０４とインターフェースするのに必要なその他の情報含む。次に、サービス１３１０は要求を表示サービス１３０４に送る（そして表示サービス１３０４から結果を受け取る）ためのゲートを設定する。他の実施形態では、クライアント１３００からサービス１３１０へのメッセージは、ＸＭＬスキーマと、サービス１３１０が表示サービス１３０４へのゲートを構築するのに必要なその他の情報を含むか、または表示サービス１３０４への事前に構築されたゲートを備える。
【０３９３】
クライアント１３００によって要求されたオペレーションの実行中、または完了した後、サービス１３１０は、表示サービス１３０４のスキーマによって指定されている方法によりオペレーションの結果を表示サービス１３０４に送る（たとえば、ＸＭＬメッセージ・スキーマでまたは表示サービスのパラメータとしての参照により指定されたＸＭＬメッセージ内にカプセル化される）。この点で、サービス１３１０は、表示サービス１３０４のクライアントである。その後、表示サービス１３０４は、クライアントのディスプレイ１３０２上にサービス１３１０から受け取った、または指示された結果をフォーマットして表示する。
【０３９４】
いくつかの実施形態では、サービス１３１０は、結果スペース（図に示されていない）などのスペースにオペレーションの結果をポストする。その後、サービス１３１０は、オペレーションも格納されている結果への参照を含むメッセージを表示サービス１３０４に送る。一実施形態では、参照はＵＲＩの形式である。その後、表示サービス１３０４は、スペースから結果を取り出し、その結果をディスプレイ１３０２に表示する。
【０３９５】
従来のアプリケーション・モデルは、通常、所定のおおむね静的なユーザ・インターフェースおよび／またはデータ特性に基づく。従来のアプリケーションに変更を加えるには、コードを修正し再コンパイルする必要がある。サービスを通知し、分散コンピューティング環境のサービスと通信するためのＸＭＬメッセージ・スキーマを指定するための記述されたメカニズムを使用して、アプリケーション（クライアント、サービス、など）が自動的に表示オブジェクトの記述するためのメカニズムを提供する。動的表示オブジェクトを使用すると、新しいコードをダウンロードしたり、アプリケーションを再コンパイルしたり、アプリケーションを再リンクすることなく、アプリケーションの動作を変更することができる。
【０３９６】
動的表示オブジェクトはＸＭＬスキーマで記述できる。これらのスキーマは、スペース内で通知される。これらのスキーマは、表示スキーマまたは表現スキーマと呼ぶ。その後、アプリケーション（またはアプリケーションの代わりに動作するその他のサービス）は、サービス通知からスキーマにアクセスし、フォーマット、データ型、およびスキーマに格納されているその他の情報に基づきデータを表示する。
【０３９７】
動的表示オブジェクトを含むスキーマの一例を以下に示す。
Figure 2004504657
【０３９８】
上記のスキーマは、アプリケーションを再コンパイルすることなく、次のように変更できる。
Figure 2004504657
【０３９９】
図３２Ａおよび図３２Ｂは一実施形態により動的表示オブジェクトのスキーマを使用する例を示す図である。図３２Ａで、アプリケーション１３２０（クライアント、サービス、またはその他のアプリケーション）はスペース１３２６に格納されている表現スキーマ通知１３２４で実装されている。表現スキーマ通知は、データ型、書式指定、フォント、位置、色、およびディスプレイ１３２２にアプリケーションのデータを表示するために使用されるその他の情報を記述する要素を含む。アプリケーション１３２０のための複数の表現スキーマ通知がある。たとえば、一連の表示ページ（たとえば、ＷｅｂサイトのＷｅｂページ）内の表示ページごとに１つのスキーマがある。
【０４００】
一実施形態では、アプリケーション１３２０は、発見および／またはルックアップ・サービスを呼び出して、表現スキーマ通知を特定する。発見および／またはルックアップ・サービスは、１つまたは複数の通知、およびＵＲＩの一覧を含むＸＭＬドキュメントを特定の表示形式などを記述するスキーマのそれぞれに返す。その後、アプリケーション１３２０は、ＸＭＬドキュメントから１つまたは複数の表現スキーマを選択する。アプリケーション１３２０は、続いて、そのスキーマを解析し、スキーマ要素をユーザ・インターフェース・コンポーネントに分解する。これらのコンポーネントは、結果データを特定し、フォーマットし、適切なディスプレイ上に表示するために使用される。結果データは、たとえば、サービスの実行または結果スペースから得られる。そこで、静的な表示または所定の表示を用意するのとは反対に、アプリケーション１３２０は、アプリケーションを再構築することなく動的に変更できる表現スキーマに従って結果を表示するように構成される。
【０４０１】
同じ結果を異なる形式で表示する、表示のため結果の一部を抽出する、および異なる表示デバイスに結果を表示する表現スキーマを提供する。
【０４０２】
一実施形態では、１つまたは複数の表現スキーマ通知を分散コンピューティング環境内の１つまたは複数のスペースに格納することができる。１つまたは複数のデバイスでアプリケーションのコピーを呼び出すと、アプリケーションのそれぞれのコピーがサービスに対するサーチを実行し、アプリケーションによって使用される表現スキーマの通知を発見する。そこで、表示情報の中央永続的ストアをアプリケーションの複数のインスタンス用または他のアプリケーション用に保持することができる。表示情報は、アプリケーションを再コンパイルしたり再インストールすることなく、中央の場所で修正することができる。
【０４０３】
図３２Ｂでは、クライアント１３２８は、スペースのサービス１３３０のサービス通知を特定する。サービス１３３０を呼び出すと、クライアント１３２８はスペース１３２６の表現スキーマ通知１３２４の位置をサービス１３３０に渡す。サービス１３３０が結果をクライアント１３２８に送る用意が整っている場合、表現スキーマ通知１３２４によって提供される表現スキーマからの表示情報を使用してディスプレイ１３２２（クライアント１３２８が実行されているデバイスに結合されている）に結果を表示することができる。結果の表示方法を変更するには、表現スキーマ通知１３２４のＸＭＬメッセージを修正するか、または異なる表現スキーマを選択すればよく、クライアント１３２８またはサービス１３３０で変更する必要はない。サービス１３３０は表示サービスでよい。
【０４０４】
クライアント、アプリケーション、またはサービスは、１つまたは複数のサービスによって提供されるさまざまなオペレーションの結果を表示するための複数の表示スキーマを備える。それとは別に、表示スキーマは１つまたは複数のクライアントのさまざまな結果を表示するための情報を含む。そこで、クライアント１３２８は、１つの表示スキーマまたは複数の表示スキーマを使用することができる。異なる形式で、または異なるディスプレイに同じ結果をフォーマットして表示する２つまたはそれ以上の表示スキーマが用意されている。たとえば、結果セットに対しディスプレイの画面に結果を表示するための表示スキーマを１つ用意し、結果を印刷するための表示スキーマをもう１つ用意する。また、同じアプリケーション、クライアント、またはサービスのコピーを表示能力の異なるデバイスで実行し、異なるデバイスの表示要求条件を満たす２つまたはそれ以上の表示スキーマを提供するようにする。
【０４０５】
文字列管理
従来のシステムでの文字列処理は、一般に、あまり効率がよくなく、特に、可変サイズの文字列の場合に効率がよくなく、たとえば、文字列をメモリ内でコピーしたり移動したりするときにメモリ空間を浪費することになる。文字列処理がこのように不効率であることは、特に、組み込み型システムなどの省メモリ・システムでは問題になる。メモリ、特にスタック領域、および動的割り当て用の領域のサイズが、省スペース／システムでは制限される。そこで、組み込み型システムなどの省スペース・システム内で実行するプログラムでの文字列処理を効率良く行う方法が望まれる。
【０４０６】
図３３Ａは、Ｃプログラミング言語による代表的文字列表現の図である。Ｃでは、文字列は、文字列１４５２の先頭文字のメモリ位置（アドレス）を格納した文字型ポインタ１４５０（ｓｔｒｉｎｇ１）で表される。他の文字は、文字列１４５２の中の先頭文字の後に続き、通常、メモリ内の連続するアドレス指定可能なバイト位置に格納される。Ｃ文字列における文字は通常、８ビットである。Ｃ文字列の文字は、ＡＳＣＩＩ文字である。Ｃ文字列は、ＮＵＬＬを終端文字とする必要がある。ＮＵＬＬは、プラットフォームで定義されている２５６個の使用可能な８ビット値のうちの１つで、通常、２進値０ｂ００００００００である。文字列１４５２は、１３バイトを占有する（１２個の文字と終端文字を合わせて１３個）。
【０４０７】
Ｃにおける文字列操作の一例として、ｓｔｒｌｅｎ（）関数があり、これは、通常、標準Ｃライブラリの実装に付属している。ｓｔｒｌｅｎ（）関数は、入力として文字列ポインタをとり、終端文字を含まない文字列の長さ（バイト）を返す。たとえば、文字ポインタ１４５０をｓｔｒｌｅｎ（）関数に渡すと、長さ１２が返される。ｓｔｒｌｅｎ（）関数は、終端文字が見つかるまで文字数を数えながら文字列内を端から端まで走査するという方法で実装できる。
【０４０８】
Ｃの文字列コピーは、通常、Ｃライブラリ関数のｓｔｒｃｐｙ（）またはｓｔｒｎｃｐｙ（）で処理するが、これは次のように実装されている。
Figure 2004504657
ｓｔｒｃｐｙ（）関数は、文字ポインタｓｒｃが指している文字列（終端文字を含む）を文字ポインタｄｅｓｔが指している文字列にコピーする。文字列は重なることはなく、コピー先文字列ｄｅｓｔはコピーを受け入れるだけ十分に大きくなければならない。ｓｔｒｎｃｐｙ（）関数も同様であるが、ただし、ｓｒｃのうちｎバイト以下がコピーされる。したがって、ｓｒｃの先頭ｎバイトに終端文字がなければ、結果に終端文字は含まれない。必要ならば、ｓｔｒｎｃｐｙ（）の後のコードに、終端文字をｄｅｓｔ文字列の終わりに追加する命令を入れることができる。ｓｒｃの長さがｎ未満の場合、ｄｅｓｔの残り部分はＮＵＬＬで埋められる。ｓｔｒｃｐｙ（）およびｓｔｒｎｃｐｙ（）関数は、コピー先文字列ｄｅｓｔへのポインタを返す。図３３Ｂは、文字列１４５２に対するｓｔｒｎｃｐｙ（）関数の結果の一例を示しているが、これは以下のパラメータを付けてｓｔｒｎｃｐｙ（）を呼び出した場合である。
Figure 2004504657
ただし、ｓｔｒｉｎｇ２は文字列１４５２の終端文字の後の最初のバイトを指している文字ポインタ１４５４であり、ｓｔｒｉｎｇ１＋３は３バイトだけインクリメントされた文字ポインタ１４５０であり、５はコピー元の場所ｓｔｒｉｎｇ１＋３からｓｔｒｉｎｇ２にコピーする文字の個数（バイト数）である。コピーした後、ｓｔｒｉｎｇ１からコピーされた５個の文字の後の次の文字は、終端文字に設定される（文字はコピーの前に終端文字に初期化されている場合がある）。したがって、２つの文字列はメモリ内で（１３＋６）＝１９バイトを占有することになる。文字ポインタ１４５０をコピー元文字列としてｓｔｒｃｐｙ（）関数を適用した場合、元の文字列１４５２と結果である新しい文字列は（１３＊２）＝２６バイトを占有することになる。
【０４０９】
図３３Ｃは、一般のシステムで、具体的には組み込み型システムなどの省スペース・システムで文字列を表現し、管理する効率的な方法を示す図である。文字列１４５２は、メモリ内に１２バイトとして格納される（終端文字は不要である）。文字列構造１４６０は、文字列１４５２の先頭文字と末尾文字へのポインタ（アドレス（Ａ）とアドレス（Ｌ））を含む。この文字列構造を使用すると、末尾文字へのポインタから先頭文字へのポインタを引くことで、文字列の長さを効率よく計算できる。
【０４１０】
文字列コピー操作ｓｔｒｃｐｙ（）やｓｔｒｎｃｐｙ（）などの操作も、より効率的に処理できる。図３３ｃに示されているようなものなどの文字列構造を使用して、新しい文字列構造１４６２を作成し、先頭文字ポインタと末尾文字ポインタを文字列１４５２内のそれぞれの文字を指すように初期化する。したがって、文字列１４５２の一部または全部をその文字列用の新しい記憶域にコピーする必要はない。文字列は長さが数百文字あるいは数千文字にさえ達することがあるため、文字列構造とその文字列構造を利用するように実装されている文字列メソッドを使用してメモリを節約することは注目に値する。文字列の一部または全部のコピーを処理するこのような方法のことを、「部分文字列管理」と呼び、文字列の一部（部分文字列）を効率よく処理することができる。
【０４１１】
標準Ｃ文字列ライブラリの他の文字列関数を、図３３Ｃに示されているような文字列構造を利用する文字列関数で置き換えることができる。他のＣ文字列関数の例として、それに限定されないが、ｓｔｒｓｔｒ（）、ｓｔｒｃａｔ（）、およびｓｐｒｉｎｔｆ（）がある。図３３Ｃで説明されているような文字列処理構造および方法は、ＸＭＬドキュメントの階層構造とともに使用する際に、組み込み型システムなどの省メモリ・システムでＸＭＬテキスト（ＸＭＬメッセージなど）を効率よく処理することができる。購買発注書を定義するＸＭＬスキーマの簡単な例を以下に示す。
Figure 2004504657
【０４１２】
ＸＭＬドキュメントの階層構造により、これらを再帰的に処理することができ、それぞれの再帰のレベルで次々にドキュメントのさらに小さな部分を処理してゆく。さまざまな部分への参照が再帰的に記録され、処理される。図３３Ｃに関して説明されているような文字列構造を使用して、さまざまな部分を記録することができる。このようにして、ＸＭＬドキュメントの最小単位が再帰的に処理される一実施形態で、特定のＸＭＬタグの内容（上の例の１行）を効率よく決定できる。所定のスコープ内のタグを効率よく列挙し処理できるため、同じスコープ内でタグが繰り返されるドキュメントもまた効率よく処理できる。
【０４１３】
図３３Ｃで説明しているような文字列構造を使用してＸＭＬドキュメントを処理する再帰的方法では、ＸＭＬドキュメント文字列全体を表し、ドキュメント文字列内の先頭バイトと末尾バイトを指している文字列構造を受け付けることができる。この方法では、ドキュメントの次のサブセクションを特定して、そのサブセクションを含むドキュメント文字列全体の部分文字列を表す文字列構造をそのサブセクションの型に対応する処理関数に渡す。サブセクション自体を、サブセクションの型に対応する処理関数に渡される文字列構造により表されるサブセクションの他のレベルに分解できる。この方法は、ドキュメント全体が処理されるまで、ＸＭＬドキュメントのサブセクションを再帰的に処理し続けることができる。
【０４１４】
再帰的処理で文字列構造を使用すると、処理のためサブセクションのコピーを作成しなくても処理を実行できる。サブセクションのコピーは、再帰が深くなるにつれ同じデータのコピーが増えてゆくため、再帰的処理では特にコストがかかる。文字列構造を使用すると、サブセクションの中の先頭バイトと末尾バイトへのポインタを含む文字列構造のみを作成し、次のレベルに引き渡すだけでよい。サブセクションの長さを決定するなどの他の操作は、文字列構造に格納されているアドレス情報を使用することで効率よく実行できる。さらに、文字列構造を使用すると、Ｃ文字列の終端に使用される文字などの終端文字は、必要なくなり、組み込み型デバイスなど省スペース・デバイスのメモリを節約できる。
【０４１５】
オブジェクトのＸＭＬ表現
前述のように、Ｊｉｎｉ　ＲＭＩは、最小限のメモリ占有面積と最低限の帯域幅を備えるシン・クライアントなどのいくつかのクライアントには実用的でないと思われる。Ｊｉｎｉ　ＲＭＩと関連するシリアライゼーションは、実行時間が長く、コード・サイズが大きく、ＪＶＭリフレクションＡＰＩを必要とし、Ｊａｖａ固有オブジェクト表現である。Ｊａｖａデシリアライゼーションも実行に時間がかかり、コード・サイズが大きく、シリアライズ・オブジェクト・パーサを必要とする。Ｊａｖａベースのシン・クライアントであっても、Ｊｉｎｉ内で要求されたときにネットワーク経由で（必ず）返される巨大なＪａｖａオブジェクト（必要なクラスに沿って）を受け入れられない場合がある。
【０４１６】
分散コンピューティング環境の実施形態を使用するとよりスケーラブルな分散コンピューティング・メカニズムを実現できる。分散コンピューティング環境には、分散コンピューティングを容易に行えるようにするＡＰＩレイヤが含まれる。ＡＰＩレイヤは、クライアントとサービスとの間のメッセージ発送およびメッセージ受取機能を備える。このメッセージングＡＰＩは、拡張マークアップ言語（ＸＭＬ）など、表現データまたはメタデータ形式による単純メッセージ用のインターフェースを提供する。実施形態はここではＸＭＬを採用しているものについて説明しているが、他の実施形態では他のメタデータ型言語または形式を使用することもできることに注意されたい。いくつかの実施形態では、ＡＰＩレイヤは、さらに、Ｊａｖａオブジェクトなど、オブジェクト間の通信やオブジェクトの受け渡しのためのメッセージのインターフェースを備えることもできる。ＡＰＩレイヤ１０２を通じてアクセス可能なオブジェクトは、ＸＭＬなどの表現データ形式で表現される。そのため、オブジェクト自体とは反対に、オブジェクトのＸＭＬ表現は操作が可能である。
【０４１７】
ＡＰＩレイヤは、メッセージング・レイヤの上に置かれる。メッセージング・レイヤは、ＸＭＬなどの表現データ形式に基づいている。一実施形態では、ＸＭＬメッセージは、ＡＰＩレイヤの呼び出しに従って、メッセージング・レイヤによって生成される。メッセージング・レイヤは、クライアントとサービスとの間で送ることができる定義済みの静的メッセージを備えることができる。メッセージング・レイヤは、さらに、動的に生成されるメッセージにも対応できる。一実施形態では、ＪａｖａオブジェクトなどのオブジェクトをＸＭＬ表現に動的に変換（コンパイル）することができる。オブジェクトは、コードおよび／またはデータ部分を含む。オブジェクトのコードおよび／またはデータ部分は、ＸＭＬ表現のＸＭＬタグにより識別されるコード・セグメントとデータ・セグメントにコンパイルすることができる。メッセージング・レイヤにより、ＸＭＬオブジェクト表現はメッセージとして送ることができる。逆に、メッセージング・レイヤは、オブジェクトのＸＭＬ表現を受け取ることができる。その後、そのメッセージからオブジェクトを再構成（逆コンパイル）できる。再構成では、ＸＭＬ表現のコードおよび／またはデータ・セグメントを識別するタグのＸＭＬ表現を調べ、タグに格納されている情報を使用して、そのオブジェクトのコードおよび／またはデータ部分を識別し、逆コンパイルする。
【０４１８】
オブジェクトのＸＭＬ表現の作成と発送
図３４は、一実施形態により、クライアント１５００とサービス１５０２の間でＪａｖａオブジェクトを移動するプロセスを示す図である。サービス１５０２は、スペース・サービスを含む、分散コンピューティング環境でサポートされているサービスであればどのようなものでもよい。クライアント１５００は、サービス１５０２のサービス通知から受け取ったＸＭＬスキーマを使用して作成したゲート１５０４を使用し、サービス１５０２の対応するゲート１５０６と通信する。ある時点で、クライアント１５００は、Ｊａｖａオブジェクト１５１０をサービス１５０２に送る必要がある。Ｊａｖａオブジェクト１５１０は、他のオブジェクトを参照し、次にこのオブジェクトは他のオブジェクトを参照し、というように続いてゆく。Ｊａｖａオブジェクト１５１０とその参照されているオブジェクト、次に参照するオブジェクト、というように続くことを、オブジェクト・グラフと呼ぶ。
【０４１９】
Ｊａｖａオブジェクト１５１０は、Ｊａｖａオブジェクト・コンパイル・プロセス１５１２に渡されてコンパイルされ、オブジェクト・グラフのＸＭＬ表現を出力する。オブジェクト・グラフのＸＭＬ表現は、ＸＭＬデータ・ストリーム１５１４としてゲート１５０４に渡される。ＸＭＬデータ・ストリーム１５１４は、オブジェクト・グラフ内のすべてのオブジェクトのＸＭＬ表現を含む。一実施形態では、オブジェクト・グラフ内のオブジェクトは、ＸＭＬデータ・ストリーム１５１４内に再帰的に格納される。
【０４２０】
ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２のゲート１５０６に送る。ゲート１５０６は、ＸＭＬメッセージ１５１６からＸＭＬデータ・ストリーム１５１４を抽出して、ＸＭＬデータ・ストリーム１５１４をＸＭＬデータ・ストリーム逆コンパイル・プロセス１５１８に送り、逆コンパイルを行い、Ｊａｖａオブジェクト１５１０を含むオブジェクト・グラフを備えるオブジェクトを出力する。一実施形態では、オブジェクト・グラフ内のオブジェクトは、ＸＭＬデータ・ストリーム１５１４内に再帰的に格納され、したがって、再帰的逆コンパイル・プロセスが使用される。
【０４２１】
サービス１５０２でＪａｖａオブジェクトをクライアント１５００に送る必要がある場合、実質的に類似するプロセスを使用できる。Ｊａｖａオブジェクト１５２０は、Ｊａｖａオブジェクト・コンパイル・プロセス１５１２に渡されてコンパイルされ、オブジェクト・グラフのＸＭＬ表現を出力する。オブジェクト・グラフのＸＭＬ表現は、ＸＭＬデータ・ストリーム１５２２としてゲート１５０６に渡される。ゲート１５０６は、その後、ＸＭＬデータ・ストリーム１５２２をメッセージ１５２４にパッケージして、メッセージ１５２４をクライアント１５００のゲート１５０４に送る。ゲート１５０４は、ＸＭＬメッセージ１５２４からＸＭＬデータ・ストリーム１５２２を抽出して、ＸＭＬデータ・ストリーム１５２２をＸＭＬデータ・ストリーム逆コンパイル・プロセス１５１８に送って逆コンパイルを行い、Ｊａｖａオブジェクト１５２０を含むオブジェクト・グラフを備えるオブジェクトを出力する。
【０４２２】
他の実施形態では、ゲートはＪａｖａオブジェクトのコンパイルおよび逆コンパイルを実行する役目を持つ。この実施形態では、Ｊａｖａオブジェクト１５１０はゲート１５０４に渡される。ゲート１５０４は、オブジェクト１５１０をＪａｖａオブジェクト・コンパイル・プロセス１５１２に渡してコンパイルし、オブジェクト・グラフのＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に出力する。ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２のゲート１５０６に送る。ゲート１５０６は、ＸＭＬメッセージ１５１６からＸＭＬデータ・ストリーム１５１４を抽出して、ＸＭＬデータ・ストリーム１５１４をＸＭＬデータ・ストリーム逆コンパイル・プロセス１５１８に送って逆コンパイルを行い、Ｊａｖａオブジェクト１５１０を含むオブジェクト・グラフを備えるオブジェクトを出力する。Ｊａｖａオブジェクトをサービス１５０２からクライアント１５００に送るプロセスは、オブジェクトをクライアントからサービスに送るプロセスと実質的に類似している。
【０４２３】
一実施形態では、オブジェクト・コンパイル・プロセス１５１２とオブジェクト逆コンパイル・プロセス１５１８は、両方とも、クライアント１５００とサービス１５０２に存在し、プログラムする際に、コンパイルと逆コンパイルを２つのデバイスで実質的に同じように実行できるため、一方のオブジェクト出力は他方のオブジェクト入力と実質的に同一である。一実施形態では、Ｊａｖａオブジェクトの記述を含むＸＭＬスキーマをコンパイル・プロセスや逆コンパイル・プロセスにおいてクライアントおよび／またはサービスの両方で使用できる。一実施形態では、Ｊａｖａオブジェクトのコンパイルや逆コンパイルで使用するＸＭＬスキーマをサービスにより、サービス通知でクライアントに渡すことができる。
【０４２４】
ＸＭＬでは、言語独立およびプラットフォーム独立のオブジェクト表現形式を備えている。したがって、オブジェクトをオブジェクトのＸＭＬ表現にコンパイルし、逆コンパイルしてオブジェクトを再現する場合に、図３４に示されているようなプロセスは、Ｊａｖａオブジェクトの移動に限られず、実施形態によっては、ネットワーク内のエンティティ間で他の型のオブジェクトを移動するのにも適用される。
【０４２５】
図４６は、オブジェクトのＸＭＬ表現を使用してサービスからクライアントにオブジェクトを送るメカニズムを示している。ステップ２２００で、クライアントはオブジェクトをサービスに要求する。一実施形態では、オブジェクトはＪａｖａオブジェクトである。一実施形態では、クライアントは、メッセージ（たとえば、ＸＭＬメッセージ）を、オブジェクトを要求しているサービスに送る。ステップ２２０２で、サービスは要求を受け取った後、オブジェクトをコンパイル・プロセスに送る。一実施形態では、コンパイル・プロセスはサービスが実行されている仮想マシン内に組み込まれる。一実施形態では、仮想マシンはＪａｖａ仮想マシン（ＪＶＭ）である。一実施形態では、コンパイル・プロセスは、ＪＶＭへの拡張機能として提供できる。ステップ２２０４で、コンパイル・プロセスはオブジェクトのデータ表現言語表現を生成する。一実施形態では、データ表現言語はＸＭＬである。オブジェクトの表現は、オブジェクトの名前または識別子およびそのオブジェクトに対する１つまたは複数のインスタンス変数を含む。オブジェクト指向プログラミングで使用するインスタンス変数は、クラス・テンプレートの変数の１つであって、そのクラスのオブジェクトごとに異なる値を持つ。ステップ２２０６で、サービスはオブジェクトのデータ表現言語表現をクライアントに送る。一実施形態では、表現はメッセージにパッケージされる。一実施形態では、メッセージはデータ表現言語で記述される。別のところで説明したように、メッセージ・ゲートをクライアントとサービスとの間で受け渡しされるメッセージに使用される。
【０４２６】
ステップ２２０８で、クライアントはオブジェクトのデータ表現言語表現を受け取り、その表現を逆コンパイル・プロセスに送る。一実施形態では、逆コンパイル・プロセスはクライアントが実行されている仮想マシン内に組み込まれる。一実施形態では、仮想マシンはＪａｖａ仮想マシン（ＪＶＭ）である。一実施形態では、逆コンパイル・プロセスはＪＶＭへの拡張機能として設けられる。ステップ２２１０で、逆コンパイルはオブジェクトのコピーをオブジェクトのデータ表現言語表現から生成する。その後、オブジェクトがクライアントに送られる。
【０４２７】
ＪＶＭコンパイル／逆コンパイルＡＰＩ
図３５ａおよび図３５ｂは、仮想マシン（たとえば、ＪＶＭ）がオブジェクト（たとえば、Ｊａｖａオブジェクト）をオブジェクトのＸＭＬ表現にコンパイルする拡張機能および（Ｊａｖａ）オブジェクトのＸＭＬ表現を（Ｊａｖａ）オブジェクトに逆コンパイルする拡張機能を含む実施形態を示すデータ流れ図である。ＪＶＭは、コンパイル／逆コンパイル拡張機能のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を備えることができる。クライアント１５００およびサービス１５０２は、ＪＶＭ内で実行中の場合がある。ＪＶＭは、同じデバイスまたは異なるデバイスに置くことができる。
【０４２８】
図３５ａと図３５ｂの両方で、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ１５３０は、Ｊａｖａオブジェクト１５１０を入力として受け付け、オブジェクト１５１０とその参照されているオブジェクト（オブジェクト１５１０のオブジェクト・グラフ）のＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に出力する。さらに、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０は、ＸＭＬデータ・ストリーム１５２２を受け付けることができ、これは、オブジェクト１５２０のＸＭＬ表現とその参照されているすべてのオブジェクト（オブジェクト１５２０のオブジェクト・グラフ）を含み、Ｊａｖａオブジェクト１５２０（およびそのオブジェクト・グラフ内のすべてのオブジェクト）を出力する。
【０４２９】
図３５ａは、Ｊａｖａオブジェクト１５１０を送るときにクライアントがＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ１５３０を呼び出す場合の一実施形態を示している。クライアント１５１０は、Ｊａｖａオブジェクト１５１０をＡＰＩ　１５３０に渡し、オブジェクトをコンパイルして、ＸＭＬ表現を出力し、そのＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に格納し、ＸＭＬデータ・ストリーム１５１４を出力する。その後、クライアントは、ＸＭＬデータ・ストリーム１５１４をゲート１５０４に渡すことができる。ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をＸＭＬメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２に送る。
【０４３０】
ＸＭＬメッセージ１５２４をサービス１５０２から受け取った後、ゲート１５２２はメッセージ１５２４からＸＭＬデータ・ストリーム１５２２を抽出し、データ・ストリーム１５２２をクライアント１５００に渡す。クライアント１５００は、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０を呼び出して、ＡＰＩ　１５３０にＸＭＬデータ・ストリーム１５２２を渡す。その後、ＡＰＩ　１５３０はＸＭＬデータ・ストリーム１５２２を逆コンパイルして、Ｊａｖａオブジェクト１５２０およびその他のオブジェクトをそのオブジェクト・グラフに出力し、オブジェクトをクライアント１５００に返す。
【０４３１】
図３５ｂは、Ｊａｖａオブジェクト１５１０を送るときにＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０がゲートによって呼び出される場合の他の実施形態を示している。クライアント１５１０は、Ｊａｖａオブジェクト１５１０をゲート１５０４に渡す。ゲート１５０４は、オブジェクト１５１０をＡＰＩ　１５３０に渡し、オブジェクトをコンパイルしてＸＭＬ表現を出力し、そのＸＭＬ表現をＸＭＬデータ・ストリーム１５１４に格納し、ＸＭＬデータ・ストリーム１５１４を出力する。ゲート１５０４は、その後、ＸＭＬデータ・ストリーム１５１４をＸＭＬメッセージ１５１６にパッケージして、メッセージ１５１６をサービス１５０２に送る。
【０４３２】
ＸＭＬメッセージ１５２４をサービス１５０２から受け取った後、ゲート１５２２はメッセージ１５２４からＸＭＬデータ・ストリーム１５２２を抽出し、データ・ストリーム１５２２をＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０に渡す。その後、ＡＰＩ　１５３０はＸＭＬデータ・ストリーム１５２２を逆コンパイルして、Ｊａｖａオブジェクト１５２０およびその他のオブジェクトをそのオブジェクト・グラフに出力する。そしてゲートは、Ｊａｖａオブジェクト１５２０とその他のオブジェクトをクライアント１５００に送る。
【０４３３】
一実施形態では、ＪＶＭ　ＸＭＬコンパイラおよび逆コンパイラは、ＪＶＭの統合された機能として実装することができる。他の実施形態では、ＸＭＬコンパイラおよび逆コンパイラは、ＪＶＭの標準拡張機能でのＡＰＩメソッド呼び出しで具現化することができ、そのため、コアＪＶＭを修正する必要はない。ＪＶＭは、ＪＶＭ内で実行するプロセス（クライアントおよび／またはサービス）にＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩ　１５３０を供給するため、プロセスはＪＶＭによって提供されているＪａｖａオブジェクト・コンパイル／逆コンパイル機能にアクセスすることができる。一実施形態では、プロセスがオブジェクト・コンパイル／逆コンパイルを利用するために、そのプロセスで実行されるＪＶＭにＪＶＭ　ＸＭＬコンパイラ／逆コンパイラ機能とＡＰＩ　１５３０を備える必要がある。リフレクションとシリアライゼーションを使用してオブジェクトを変換して送るメソッドは、通常、ＪＶＭから切り離された別のアプリケーションで実装される。オブジェクトの推移的閉包（ｔｒａｓｉｔｉｖｅ ｃｌｏｓｕｒｅ）を動的に解析するときに、アプリケーション側がＪＶＭに繰り返しアクセスし、一度にフィールド１つずつオブジェクトを取り出す必要がある。この作業は、遅くかつやっかいなプロセスになりがちであり、またアプリケーションとＪＶＭコードが大量に必要になる。
【０４３４】
ＪＶＭ内にＪａｖａオブジェクト・コンパイル／逆コンパイル機能を実装することが好都合なのは、ＪＶＭがすでにオブジェクト・グラフの概念、および内容を理解しているからである。そこで、コンパイル／逆コンパイル機能で、ＸＭＬ表現を出力するためのオブジェクト・グラフの解析とオブジェクト・グラフを出力するためのＸＭＬ表現の解析にＪＶＭの知識を活用（そして、コードを再利用し）することができる。したがって、コンパイル／逆コンパイル機能では、リフレクションとシリアライゼーションを使用するオブジェクト送出メソッドの場合のように、ＪＶＭによって提供される機能を複製してはならない。これにより、コンパイル／逆コンパイル機能のコード占有領域を、リフレクションおよびシリアライゼーションを使用するオブジェクト送出メソッドと比べて小さくすることができる。また、オブジェクトは、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩを１回呼び出すだけでコンパイルまたは逆コンパイルすることができる。
【０４３５】
さらに、オブジェクトのコンパイル逆コンパイルをＪＶＭに統合することにより、オブジェクトのコンパイルおよび逆コンパイルを、リフレクションおよびシリアライゼーションを使用したメソッドよりも高速に実行することができる場合があるが、それは、リフレクションおよびシリアライゼーションで実装されたオブジェクト・トラバーサル・モデルでは、ＪＶＭの外部にあるコードはＪａｖａオブジェクトの構造またはグラフを認識せず、オブジェクト・グラフをトラバースして、引き離し、最終的に、ＪＶＭを繰り返し呼び出してコンパイル（および逆コンパイルのための反転プロセス）を実行する必要があるからである。このプロセスは、コードの外部で、ＪＶＭの呼び出しを繰り返し実行する必要があるため、遅くなることがある。ここで説明したように、コンパイルおよび逆コンパイル機能をＪＶＭに統合することにより、ＪＶＭの外部のコードからＪＶＭへ繰り返し呼び出しを行わなくて済むようになる。一実施形態では、オブジェクトは、ＪＶＭ　ＸＭＬコンパイラ／逆コンパイラＡＰＩを１回呼び出すだけでコンパイルまたは逆コンパイルすることができる。
【０４３６】
一実施形態では、コンパイラ／逆コンパイラ機能は分散コンピューティング環境におけるサービスとして実装できる。サービスは、スペース内でサービス通知をパブリッシュする。分散コンピューティング環境内のプロセスは、サーチまたは発見サービスを使用して、コンパイル／逆コンパイル・サービスを特定することができる。このプロセス（サービスのクライアント）は、次に、ＸＭＬ表現にコンパイルするＪａｖａオブジェクトおよび／またはＪａｖａオブジェクトに逆コンパイルするＸＭＬ表現サービスに渡すことによりそのサービスを使用できる。Ｊａｖａオブジェクトにコード（オブジェクトのメソッド）およびデータを含めることができる。オブジェクトのコードは、非一時的でなく、オブジェクトが作成された後このコードは変更されない。ただし、オブジェクトのデータは一時的な場合がある。同じＪａｖａクラスから作成された２つのオブジェクトは、同一のコードを含んでいても、２つのオブジェクト内のデータが異なることがある。一実施形態では、コンパイル機能はＪａｖａオブジェクトのデータをオブジェクトのＸＭＬ表現にコンパイルするが、ＸＭＬ表現の中にオブジェクトの実際のコードが含まれない場合がある。一実施形態では、オブジェクトに関する情報をコンパイルされたＸＭＬ表現の中に挿入し、そのオブジェクトのコードの再作成方法を受取側に通知するようにできる。ＸＭＬ表現をＸＭＬデータ・ストリームに格納し、受け取り側プロセス（クライアントまたはサービス）に（たとえば、メッセージで）送ることができる。受け取り側プロセスは、ＸＭＬデータ・ストリームを逆コンパイル機能に渡すことができる。逆コンパイル機能は、ＸＭＬデータ・ストリームを逆コンパイルして、そのデータを含むＪａｖａオブジェクトを出力することができる。一実施形態では、オブジェクトのコードは、ＸＭＬ表現に含まれるオブジェクトに関する情報を使用して逆コンパイル機能により再現することができるが、それはオブジェクトのコードが静的に定義され、そのオブジェクトを受け取るＪＶＭがオブジェクトについての情報を利用して（必要ならば）そのコードを再現することができるからである。
【０４３７】
一実施形態では、コンパイル機能によって出力されたオブジェクトのＸＭＬ表現に、にＪａｖａオブジェクトのデータおよびそのＪａｖａオブジェクトに関する情報を格納することができる。その情報は、Ｊａｖａオブジェクトのクラス情報を含むことができる。オブジェクト・シグネチャを情報に含め、そのシグネチャを利用して、オブジェクトのクラスなどを識別することができる。逆コンパイル機能では、Ｊａｖａオブジェクトに関する情報を使用してＪａｖａオブジェクトのコードを再作成し、ＸＭＬデータ・ストリームからデータをＪａｖａオブジェクトに逆コンパイルすることができる。したがって、逆コンパイルされたデータとオブジェクトを記述している情報から受け取り側クライアントまたはサービスを実行しているＪＶＭ上でコードとデータを含む完全なオブジェクトを再現することができる。一実施形態では、オブジェクトを記述する情報を１つまたは複数のＸＭＬタグの中に格納することができる。一実施形態では、ＸＭＬデータ・ストリームを受け取るクライアントまたはサービスはオブジェクトを記述するＸＭＬスキーマを含むことができ、またＸＭＬスキーマを使用して、逆コンパイルされたデータとそのオブジェクトに関する情報からＪａｖａオブジェクトを再構成することができる。逆コンパイル・プロセスは、オブジェクト・グラフを再帰的にたどり、オブジェクトによって参照されているオブジェクトを再構成するが、この作業は、ＸＭＬデータ・ストリームから参照されているオブジェクトのデータを逆コンパイルし、そのＸＭＬデータ・ストリーム内の参照されているオブジェクトに関する情報から参照されているオブジェクトのコードを再作成することで行う。
【０４３８】
一実施形態では、コンパイル機能によって出力されたオブジェクトのＸＭＬ表現に、オブジェクトのデータおよびオブジェクトのコードを識別する情報を格納することができる。一実施形態では、オブジェクトのコードを記述する情報をＸＭＬデータ・ストリーム内の１つまたは複数のＸＭＬタグの中に格納することができる。受け取ると、逆コンパイル機能はＸＭＬデータ・ストリームからのコードに関する情報を使用してＪａｖａオブジェクトのコードを再作成し、ＸＭＬデータ・ストリームからオブジェクトのデータを逆コンパイルすることができる。したがって、逆コンパイルされたデータとオブジェクトのコードを記述している情報から受け取り側クライアントまたはサービスを実行しているＪＶＭでコードとデータを含む完全なオブジェクトを再現することができる。
【０４３９】
オブジェクトのＸＭＬ表現を使用して分散コンピューティング環境内のエンティティ（通常、クライアントとサービス）間でオブジェクトを転送するシナリオを説明のため取り上げる。これらのシナリオは、例であり、制限することを意図していない。
【０４４０】
第１のシナリオでは、サービスはＸＭＬコンパイラ／逆コンパイラを使用して、ＪａｖａオブジェクトをそのオブジェクトのＸＭＬ表現にコンパイルし、そのＸＭＬ表現をクライアントに送る。クライアントは、ＸＭＬコンパイラ／逆コンパイラを使用してＸＭＬ表現を逆コンパイルし、オブジェクト内のデータに対し操作を実行し、後でＸＭＬコンパイラ／逆コンパイラを使用してそのオブジェクトをオブジェクトのＸＭＬ表現にコンパイルし、そのオブジェクトのＸＭＬ表現をサービスに返す。
【０４４１】
第２のシナリオでは、サービスはＸＭＬコンパイラ／逆コンパイラを使用して、ＪａｖａオブジェクトをそのオブジェクトのＸＭＬ表現にコンパイルし、そのＸＭＬ表現をクライアントに送る。次に、クライアントはＸＭＬ表現を他のサービスに送り、これはＸＭＬコンパイラ／逆コンパイラを使用してＸＭＬ表現を逆コンパイルしてオブジェクトを再生成し、クライアントから（場合によってはデータを修正する）要求があったときにオブジェクトに対し操作を実行し、ＸＭＬコンパイラ／逆コンパイラを使用してその修正されオブジェクトをそのＸＭＬ表現に再コンパイルし、そのオブジェクトのＸＭＬ表現をクライアントに送る。
【０４４２】
第３のシナリオでは、サービスはＸＭＬコンパイラ／逆コンパイラを使用して、ＪａｖａオブジェクトをそのオブジェクトのＸＭＬ表現にコンパイルし、そのＸＭＬ表現をオブジェクト・リポジトリまたはストア・スペースに送る。サービスは、次に、メッセージをクライアントに送り、ＸＭＬ表現の位置をクライアントに知らせる。メッセージは、ＸＭＬ表現のＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含む。その後、クライアントはストア・スペースからオブジェクトのＸＭＬ表現を取り出し、ＸＭＬコンパイラ／逆コンパイラを使用してその表現を逆コンパイルしてオブジェクトを再現する。それとは別に、クライアントはオブジェクトのＸＭＬ表現の位置を、そのオブジェクトで実行する操作の要求とともに他のサービスに送る。その後、他のサービスはストア・スペースからＸＭＬ表現を取り出し、ＸＭＬコンパイラ／逆コンパイラを使用してＸＭＬ表現を逆コンパイルしオブジェクトを再現して、オブジェクトに対し要求された操作を実行する。
【０４４３】
第４のシナリオでは、プロセス（クライアントまたはサービスの場合がある）は、ストア・スペースでサービス通知をサーチして見つけることにより、分散コンピューティング環境内のオブジェクト・リポジトリまたはストア・スペースを特定することができる。プロセスは、実行時に、複数のＪａｖａオブジェクトを作成し、取得する。プロセスは、ＸＭＬコンパイラ／逆コンパイラを使用して、１つまたは複数のオブジェクトをオブジェクトのＸＭＬ表現にコンパイルし、ストア・スペース・サービスのクライアントとして、オブジェクトのＸＭＬ表現をストア・スペースに送り、後でアクセスできるように、また他のプロセスによってアクセスできるように格納する。
【０４４４】
オブジェクトのＸＭＬ表現の逆コンパイルにおけるセキュリティ問題
スペースは、ここで説明しているように、分散コンピューティング環境でファイル・システムとして使用できる。システム内のファイルに対してはセキュリティをアクセス権限の形で提供する。アクセス権限は、ファイルのアクセス（開く、読み込む、書き出すの操作）ごとにチェックされる。したがって、分散コンピューティング環境でファイルのアクセス・セキュリティを実現する方法が望まれる。この方法はさらに、スペースに格納され、分散コンピューティング環境内のクライアントとサービスとの間で送られるＪａｖａオブジェクトのＸＭＬ表現に適用できる。
【０４４５】
一実施形態では、分散コンピューティング環境のデバイスのクライアントのユーザは、最初にクライアントにアクセスしたときに識別され、認証される。一実施形態では、ユーザは、識別と承認のためにスマート・カードなどの物理的識別機能を提供することができる。他の実施形態では、チャレンジ応答メカニズム（ユーザＩＤとパスワードなど）を使用して、識別と承認を行うことができる。さらに他の実施形態では、識別と承認に電子シグネチャなどの電子識別を使用する。識別と承認に他の方法を使用することもできる。識別されて承認されると、ユーザは、分散コンピューティング環境で１つまたは複数のサービスにアクセスすることを含む、クライアント上のさまざまな操作を実行できる。これらの操作のときに、上述のように、１つまたは複数のオブジェクトを作成する（ローカルで）か、またはどこか他のところ（たとえば、サービスまたはスペース）から取得することができる。オブジェクトは、修正して、オブジェクトのＸＭＬ表現にコンパイルし、ローカルで、クライアントによって格納するか、または（遷移的または永続的）ストアのためスペース・サービスに送ることができる。オブジェクトのいくつかはサービスからオブジェクトのＸＭＬ表現の形式で（サービスまたは他のサービスで格納）受取され、これは、ＸＭＬコンパイラ／逆コンパイラによって逆コンパイルされ、クライアント上にオブジェクトを再作成することができる。
【０４４６】
一実施形態では、オブジェクトのＸＭＬ表現を逆コンパイルするときに、それぞれのＸＭＬメッセージをチェックし、ユーザがそのオブジェクトに対するアクセス権限を持っていることを検証する。ユーザが適切なアクセス権限を持っていない場合、ＸＭＬコンパイラ／逆コンパイラはそのユーザに対してオブジェクトを逆コンパイルしない。一実施形態では、ＸＭＬコンパイラ／逆コンパイラによってセキュリティ例外がスローされる。一実施形態では、ユーザに対しアクセス違反が知らされる。
【０４４７】
オブジェクトに対し許されている作成者およびアクセス・レベル（作成者のみアクセス、読み取り専用、読み書き、削除、コピーなど）などのアクセス権限情報は、オブジェクトのＸＭＬ表現を含むＸＭＬメッセージ内に埋め込むことができる。アクセスの承認は、ユーザの識別と承認を行う際に決定される。たとえば、オブジェクトは、ほとんどのユーザに対し「読み取り専用」アクセスを許可し、オブジェクトの作成者には「読み書き」アクセスを許可する。ユーザが読み書きアクセス権限を使用してオブジェクトにアクセスしようとし、ユーザがオブジェクトを作成していなかった場合、逆コンパイル・プロセスにより、これがアクセス違反として検出され、アクセスが不許可になり、ユーザは通知を受ける。
【０４４８】
一実施形態では、ユーザがクライアントを使用して完了した場合、ユーザはログオフするか、またはそうでなければ、ユーザがクライアントを終了した（たとえば、スマート・カードを削除した）ことを通知する。逆コンパイルによりクライアント上に作成されたオブジェクトは、ユーザは終了したことをクライアントが検出したときに、自動的に検出される。このため、後からのユーザが故意にまたはうっかりそのユーザのオブジェクトにアクセスしようとしてもできない。一実施形態では、逆コンパイルによって作成されたすべてのオブジェクトは、ユーザが終了したことが検出されたときに削除される。他の実施形態では、クライアント上に永続的に作成されたオブジェクトの少なくとも一部を格納する方法が用意され（たとえば、アクセス権限情報を使用して）、これによりクライアントが後でオブジェクトにアクセスしたり、オブジェクトを他のユーザに提供してアクセスできるようにする。一実施形態では、ユーザは「スマート・カード」またはその他の物理的デバイスを使用し、クライアントへのアクセス権を取得する。ユーザは、スマート・カードをクライアント・デバイスに差し込んで、セッションを開始することができる。クライアントは、終了すると、スマート・カードを取り出す。クライアントは、スマート・カードが取り出されたことを検出し、クライアントが終了していることを検出し、その後、ＸＭＬ表現の逆コンパイルによって作成されたオブジェクトの削除へ進む。
【０４４９】
図４７は、クライアント・デバイスでセキュリティで保護されたオブジェクト逆コンパイルのメカニズムを示す。ステップ２２４０で、ユーザはクライアント・デバイスにアクセスする。一実施形態では、ユーザはクライアントに識別情報を送る。一実施形態では、ユーザは、たとえば、ユーザ名とパスワードを使用してクライアントにログオンする。一実施形態では、ユーザは物理的識別方法、たとえばスマート・カードをクライアント・デバイスに提供し、デバイスによりユーザの素性を確定する。
【０４５０】
ユーザ認証された後、クライアントはユーザによるアクセス中に１つまたは複数のサービスに１つまたは複数のオブジェクトを要求することができる。一実施形態では、オブジェクトはＪａｖａオブジェクトである。一実施形態では、クライアントは、メッセージ（たとえば、ＸＭＬメッセージ）を、オブジェクトを要求しているサービスに送る。サービスは、要求を受け取った後、オブジェクトのデータ表現言語表現をクライアントに送る。一実施形態では、この表現はメッセージにパッケージされる。別のところで説明したように、メッセージ・ゲートをクライアントとサービスとの間で受け渡しされるメッセージに使用される。
【０４５１】
ステップ２２４２で、クライアントはオブジェクトのデータ表現言語表現を受け取り、その表現を逆コンパイル・プロセスに送る。一実施形態では、逆コンパイル・プロセスはクライアントが実行されている仮想マシン内に組み込まれる。一実施形態では、仮想マシンはＪａｖａ仮想マシン（ＪＶＭ）である。逆コンパイルでは、オブジェクトのコピーをオブジェクトのデータ表現言語表現から生成する。一実施形態では、メッセージをチェックして、クライアントが要求されたオブジェクトへのアクセス特権を持つことを確認する。その後、オブジェクトがクライアントに送られ、ユーザによるアクセス時に使用することができる。
【０４５２】
ステップ２２４４で、ユーザはクライアント・デバイスへのアクセスを終了する。たとえば、ユーザはログオフするか、またはスマート・カードなどの識別デバイスを使用していた場合には、それを削除してユーザがクライアントのアクセスを終了していることをクライアント・デバイスに通知する。クライアントはアクセスを終了したことが検出された後、クライアント・デバイスは、ユーザがアクセスしているときにユーザのために逆コンパイルしたオブジェクトを自動的に削除する。オブジェクトを削除すると、デバイスの後のユーザがうっかりまたは故意にアクセスする可能性のあるクライアント・デバイスにオブジェクトが残らない。
【０４５３】
それとは別に、ユーザはアクセスを終了したときに、オブジェクトのうち１つまたは複数が削除されない場合もある。その代わりに、ユーザが後でアクセスできるようにオブジェクトが格納される（ローカルにまたは分散コンピューティング環境内のどこかに）。一実施形態では、クライアントのアクセス情報はオブジェクトとともに格納され、無許可ユーザがオブジェクトにアクセスできないようにする。
【０４５４】
ＸＭＬベースのオブジェクト・リポジトリ
分散コンピューティング環境では、プロセス（サービスおよび／またはクライアント）には、ＸＭＬスキーマ、サービス通知、サービスによって生成された結果、ＪａｖａオブジェクトのＸＭＬ表現、および／または他の言語で実施されたオブジェクトなどの一時的および／または永続的記憶域があると望ましい場合がある。既存のオブジェクト記憶技術は、言語および／またはオペレーティング・システム固有のものになりがちである。これらの記憶域システムは、また、組み込み型システムなどの省スペース・システムで使用するには複雑すぎる傾向もある。
【０４５５】
ＪｉｎｉのＪａｖａＳｐａｃｅｓは、既存のオブジェクト・リポジトリ・メカニズムである。ＪａｖａＳｐａｃｅｓは、Ｊａｖａオブジェクトを格納することしかできず、メモリ容量に制限のある小型デバイスには大きすぎて実装できない。ＪａｖａＳｐａｃｅの各オブジェクトは、前記のようにシリアライズされ、そのため、リフレクションおよびシリアライゼーション手法について前述したのと同じ制限がある。
【０４５６】
異機種混在の（言語またはオペレーティング・システム依存でない）、小型デバイスから大型デバイスまで拡張性のある、オブジェクトの一時的記憶域または永続的記憶域を提供できる分散コンピューティング環境向けのストア・メカニズムを提示する。一実施形態では、分散コンピューティング環境でのストア・メカニズムは、ＸＭＬマークアップ言語で定義されているインターネットＷｅｂページまたはページ・セットとして実装することができる。ＸＭＬは、言語独立およびプラットフォーム独立のオブジェクト表現形式を用意し、Ｊａｖａおよび非Ｊａｖａソフトウェアが言語独立オブジェクトを格納し、取り出すことができるようにしている。ストア・メカニズムはＷｅｂ上にあるため、すべての型およびサイズ（小型から大型まで）のデバイスでストア・メカニズムにアクセスできる。Ｗｅｂブラウザーを使用して、Ｗｅｂページとして実装されているストア・メカニズムを表示することができる。Ｗｅｂサーチ・エンジンを使用して、Ｗｅｂページとして実装されているストア・メカニズム内のコンテンツをコンテンツすることができる。インターネット管理メカニズム（既存および将来の）およびＸＭＬツールを使用して、ＸＭＬベースのストア・メカニズムを管理することができる。
【０４５７】
一実施形態では、ストア・メカニズムを使用して、ＸＭＬで作成され、表現され、またはカプセル化されたオブジェクトを格納することができる。ストア・メカニズムに格納できるオブジェクトの例として、それには限定されないが、ＸＭＬスキーマ、オブジェクトのＸＭＬ表現（たとえば、上述のようにＸＭＬ表現にコンパイルされたＪａｖａオブジェクト）、サービス通知、およびＸＭＬでカプセル化されたサービス結果（データ）がある。一実施形態では、ＸＭＬオブジェクトの無許可アクセスを防止するために、電子シグネチャや証明書などの承認証明書をＸＭＬオブジェクトに付属させ、ＸＭＬオブジェクトにアクセスすることを望んでいるクライアントがＸＭＬオブジェクトにアクセスするための適切な承認証明書を持つことを義務づける。一実施形態では、ストア・メカニズムは、「スペース」の項で説明したようにスペースであってもよい。
【０４５８】
分散コンピューティング環境では、ストア・メカニズムはサービスである。サービスとして実装されたストア・メカニズムは、「ストア・サービス」と呼ばれる。ストア・サービスは、スペース内で通知をパブリッシュする。スペース自体はストア・サービスの一例である。一部のストア・サービスは一時的である。たとえば、サービス通知を格納するスペース・サービスは一時的ストアである。他のストア・サービスは永続的である。たとえば、サービスからの結果を格納するストア・サービスは永続的ストアである。
【０４５９】
図３６は、一実施形態により分散コンピューティング環境でストア・メカニズム１６００および１６０２にアクセスするクライアント１６０４およびサービスＡ　１６０６の図である。この図は、例示を目的としており、本発明の範囲に限定することを求めていない。一実施形態では、ストア・メカニズム１６００および１６０２はそれぞれ、ウェブ・ブラウザおよび他のインターネット・ツールによってアクセス可能なインターネット・ウェブ・ページまたはＸＭＬで定義されるウェブ・ページの集合である。ストア・メカニズム１６００は、ＸＭＬを使用して実装されたオブジェクトを格納できる一時的ストアである。ストア・メカニズム１６０２は、これもまたＸＭＬを使用して実装されたオブジェクトを格納できる永続的ストアである。サービスＡ　１６０６は、一時的ストア１６００でＸＭＬサービス通知１６０８をパブリッシュする。永続的ストアは、さらに、一時的ストア１６００に（または分散コンピューティング環境内の他の一時的ストアに）ＸＭＬサービス通知をパブリッシュすることもできる。ある時点で、クライアント１６０４は、サービスＡ　１６０６によって提供される機能を必要とする。クライアント１６０４は、発見および／またはルックアップ・サービスを使用して、サービス通知１６０８を特定する。クライアント１６０４は、ここで説明しているように、メッセージ・ゲートを構築し、サービスＡ　１６０６との通信を開始する。クライアント１６０４は、１つまたは複数のＸＭＬ要求メッセージをサービスＡ　１６０６に送る。サービスＡ　１６０６は、その１つまたは複数の要求メッセージに応答して１つまたは複数の機能を実行する。サービスＡ　１６０６によって実行される機能の１つまたは複数により、クライアント１６０４に送る結果を出力する。
【０４６０】
一時的結果１６１０については、サービスＡ　１６０６は、ＸＭＬ通知１６１２で結果をカプセル化し、通知１６１２を一時的ストア１６００に（または分散コンピューティング環境内の他の一時的ストアに）パブリッシュする。その後、サービスＡ　１６０６は、結果１６１０が一時的ストア１６００の通知１６１２に格納されることをクライアント１６０４に通知するか、またはここで述べたように他のメカニズムによりクライアント１６０４に通知することができる。クライアント１６０４は、その後、通知１６１２から一時的結果１６１０を取り出す。通知１６１２は、一時的結果１６１０のフォーマット、コンテンツ、型などを記述するＸＭＬスキーマを含む。結果は、ＸＭＬでカプセル化される。たとえば、ＸＭＬタグを使用して、次のようにデータの一部を記述することができる。
Figure 2004504657
【０４６１】
永続的結果１６１８については、サービスＡ　１６０６はサービスまたはここで説明されているようなその他のメカニズムを使用して、永続的ストア１６０２のＸＭＬサービス通知１６１６を特定し、永続的結果を格納するため永続的ストア１６０２を特定する。それとは別に、クライアント１６０４は、サービス通知１６１６を特定することにより、すでに永続的ストア１６０２を特定しており、永続的結果１６１８の記憶場所のＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）をＸＭＬメッセージでサービスＡに送る。一実施形態では、永続的結果１６１８は、ＸＭＬで定義され、Ｗｅｂブラウザによりアクセス可能なインターネットＷｅｂページまたはＷｅｂページ・セットに格納される。その後、サービスＡ　１６０６は、永続的ストア１６０２に永続的結果１６１８を格納する。続いてサービスＡ　１６０６は、永続的結果１６１８のＸＭＬ通知１６１６を一時的ストア１６００に（または分散コンピューティング環境内の他の一時的ストアに）パブリッシュし、通知１６１６の位置をクライアント１６０４に返す。通知１６１６は、永続的結果１６１８のフォーマット、コンテンツ、型などを記述するＸＭＬスキーマを含む。結果は、前述のようにＸＭＬでカプセル化される。通知はさらに、永続的結果１６１８のＵＲＩを含む。クライアント１６０４は、次に、通知１６１６を取り出し、これを使用して永続的結果１６１８を特定し、取り出す。それとは別に、サービスＡ　１６０６は、永続的結果１６１８の通知をパブリッシュせず、その代わりに、クライアント１６０４が通知をルックアップせずに結果にアクセスできるように、永続的結果１６１８のＵＲＩをクライアント１６０４に返す。いくつかの実施形態では、一時的ストア１６００に示されるさまざまな通知はそれぞれ、異なる一時的ストアまたはスペースに格納できることに注意されたい。
【０４６２】
したがって、ストア・メカニズムは、分散コンピューティング環境内でＸＭＬベースのインターネットＷｅｂページとして実装することができる。これらのストア・メカニズムは、分散コンピューティング環境内のさまざまなデバイスに実装され、クライアント（他のサービスでもよい）がストア・メカニズムを特定し使用できるようにするサービス通知を実現する。ストア・メカニズムを管理するために使用できるＷｅｂおよびＸＭＬツールは既存のものでもこれからのものでもよい。ストア・メカニズムは、ＸＭＬで実装されたまたはカプセル化されたさまざまな型のオブジェクトを格納できる。クライアントは、省スペース・デバイスからスーパー・コンピュータに至るまで実質的にいかなるサイズのデバイスのクライアントであっても、ストア・メカニズムにアクセスして、インターネット上でさまざまなオブジェクトを格納し取り出すことができる。クライアントは、ＸＭＬによって定められている言語独立の記憶形式であれば、Ｊａｖａアプリケーションでも非Ｊａｖａアプリケーションでもよい。一時的または永続的オブジェクト・リポジトリは、分散コンピューティング環境内のファイル・システムに対応しており、ここで説明しているように、アクセス・チェックおよびその他のセキュリティ・メカニズムの機能を備える。
【０４６３】
ＪａｖａオブジェクトをＸＭＬドキュメントに動的に変換する
一実施形態では、分散コンピューティング環境はオブジェクト・クラス・インスタンスをＸＭＬドキュメントに変換しそれを表現するメカニズムを備える。クラス・インスタンスの表現を他のサービスに送るために、オブジェクトは変換されＸＭＬドキュメントとして表現される。一実施形態では、ＸＭＬドキュメントを受け取ると、プログラムがドキュメントによって表現されたオブジェクトに対応するクラス・インスタンスをインスタンス化する。一実施形態では、オブジェクトはＪａｖａオブジェクトであり、プログラムはＪａｖａプログラムである。
【０４６４】
一実施形態では、中間形式を使用してＸＭＬドキュメントを表現し、この中間形式を動的に処理して、ＸＭＬドキュメントを表現するクラス・インスタンスを生成することができる。クラスによって、一組のインスタンス変数とインスタンス変数にアクセスするための「セットアンドゲット」メソッドを定義する。対応するＸＭＬドキュメントを一組のタグとして定義し、インスタンス変数ごとに１つのタグを割り当てることができる。ドキュメントの解析を行うときに、ハッシュ可能な表現を構築し、ハッシュ鍵にインスタンス変数名を含め、値にインスタンス変数値を入れる。複合インスタンス変数が複数出現する場合、列挙型値をそのハッシュ・テーブルに格納することができる。一実施形態では、プロセスをインスタンス変数について複合型のうちただ１つのレベルに制限し、要素を均質的なものとすることができる。
【０４６５】
一実施形態では、保護されたインスタンス変数を、対応するクラスの名前を含めることができるクラス定義に追加することができる。ＸＭＬドキュメント表現ではクラス名をドキュメント型として使用できる。ドキュメントにクラス名を埋め込むと、オブジェクトを再構築するときに、正しいクラス・インスタンスのインスタンス化を動的に行うことができる。
【０４６６】
一実施形態では、ドキュメントを受け取った後、クラス・インスタンス・ジェネレータ・メソッドを使用して、クラス型を抽出し、ドキュメントを解析して中間ハッシュ・テーブル表現を生成することができる。ジェネレータ・メソッドは、新しいクラス・インスタンスをインスタンス化し、セット・メソッドを使用してハッシュ・テーブル値からインスタンス・オブジェクトを初期化することができる。一実施形態では、クラス型が定義され、ハッシュ・テーブルは汎用なので、このプロセスは、上のクラス定義にマッチするクラスに対して実行される。一実施形態では、反転プロセスも実行することができ、クラス・インスタンスを処理して中間ハッシュ・テーブルの表現にし、ジェネレータ・メソッドを使用してハッシュ・テーブル表現からＸＭＬドキュメントを出力することができる。このプロセスはさらに、上の指定にマッチするＸＭＬドキュメントについて実行できるように汎用なものとすることもできる。
【０４６７】
このメソッドは、Ｊａｖａクラス・オブジェクトに制限する意図はなく、他のプログラミング言語のクラス・オブジェクト・インスタンスを含む、他のコンピュータベースのオブジェクトにも適用される。さらに、このメソッドは、オブジェクト・インスタンスのＸＭＬ表現に制限する意図はなく、他のデータ表現言語（ＨＴＭＬなど）など他の表現形式をＸＭＬの代わりに使用することもできる。
【０４６８】
ＸＭＬベースのプロセスの移行
分散コンピューティング環境では、配布されるアプリケーションの配布および管理を行える。たとえば、分散コンピューティング環境には、モニタ、プリンタ、キーボード、およびＰＤＡ、携帯電話などのモバイル・デバイスには通常装備されないさまざまなその他の入出力デバイスを備えるステーションとドッキング可能なモバイル・クライアントが含まれる。これらのモバイル・クライアントは、１つまたは複数のアプリケーションを実行し、分散コンピューティング環境において、一方のステーションから他方のステーションに移行することができる。したがって、分散コンピューティング環境の一実施形態では、分散コンピューティング環境内の一方のノードのモバイル・クライアントから他方のノードの同じモバイル・クライアントまたは他方のモバイル・クライアントに現在状態全体を保持したまま実行中アプリケーション（プロセス）を移行する方法を提示する。
【０４６９】
一実施形態では、クライアントまたはサービス上で実行しているプロセスの状態のＸＭＬ表現を作成する。一実施形態では、プロセスの状態のＸＭＬ表現は、プロセスが実行されているデバイスおよび／または仮想マシンの計算状態を含み、デバイスおよび／または仮想マシンの計算状態はデバイスおよび／または仮想マシン上のプロセスの実行状態に関する情報を含む。プロセス状態は、それに限定されないが、スレッド、スレッドによって参照されているすべてのオブジェクト、プロセスの実行中に作成される一時的変数、オブジェクト、およびそのデータなどである。一実施形態では、プロセスによってスペースから得られ、プロセスが実行されているデバイスおよび／または仮想マシンの外部にある外部サービスへのアクセス権の付与を表す１つまたは複数のリースを記述するデータは、ＸＭＬで表され、プロセス状態とともに格納される。リースについては、本書の「リース」の項で詳述する。
【０４７０】
ここで説明しているようにＸＭＬおよびメッセージング・システムを使用すると、プロセスの状態のＸＭＬ表現を分散コンピューティング環境内のノードからノードへ、たとえばインターネット上のノードからノードへ移動することができる。プロセスの状態のＸＭＬ表現はさらに、上述のようにＸＭＬベースのストア・メカニズムによりＸＭＬオブジェクトとして格納することができ、後から、ストア・メカニズムから取り出して、同じノード上、または分散コンピューティング環境内の異なるノード上でプロセスの実行を再開することができる。一実施形態では、ここで説明しているようにＸＭＬオブジェクトのコンパイル／逆コンパイル・プロセスを使用して、プロセスの状態のＸＭＬ表現を作成（コンパイル）し、プロセスの状態のＸＭＬ表現を逆コンパイルすることによりプロセスの状態を再生成することができる。
【０４７１】
このメカニズムを使用することにより、プロセスの状態のＸＭＬ表現を初期ノードから、スペースなどのＸＭＬベースのストア・メカニズムに格納することができる。それ以降、他のノードでプロセスの格納済みの状態を特定し、プロセスの状態をダウンロードし、状態が格納されたときに実行されていた時点のダウンロードされた格納済みの状態からプロセスを再開できる。プロセス状態はＸＭＬ形式で格納されるので、ここで説明しているＸＭＬベースのストア・メカニズムでＸＭＬオブジェクトを格納し、特定し、取り出すためのツールおよびサーチ機能を使用して、プロセスの移行を可能にすることができる。プロセスの状態の格納されているＸＭＬ表現の通知をパブリッシュする際に、同じノードまたは別のノード上で実行されているプロセスの再開するクライアントが格納されている状態を特定し、アクセスできるようにする。
【０４７２】
プロセスの状態のＸＭＬ表現をＸＭＬベースの永続的ストア・メカニズムに格納し、プロセスの永続的スナップショットを作成できる。これは、たとえば、ノードを故意にシャットダウンしたり、または故意でなくシャットダウンをしたためノード上のプロセスが中断した後、ノード上のプロセス実行を再開するための方法として使用できる。プロセスの格納されている状態の通知をパブリッシュし、クライアントが分散コンピューティング環境内の格納されている状態を特定できるようにする。一実施形態では、プロセスの格納されている状態のＸＭＬ表現の無許可アクセスを防止するために、電子シグネチャや証明書などの承認証明書を格納されている状態に付属させ、格納されている状態からプロセスを再開することを望んでいるクライアントが格納されている状態にアクセスするための適切な承認証明書を持つことを義務づける。
【０４７３】
図３７は、一実施形態によりプロセスの状態のＸＭＬ表現を使用するプロセス移行を示す図である。プロセスＡ　１６３６ａが、ノード１６３０上で実行されている。プロセスＡ　１６３６ａは、クライアントまたはサービスである。プロセスＡ　１６３６ａの実行中のある時点に、プロセスＡ　１６３６ａの実行の状態を捕捉し、プロセスＡ　１６３８のＸＭＬでカプセル化された状態で格納する。ノード１６３０上のプロセスＡ　１６３６ａの実行は停止させられる。後で、ノード１６３２は、プロセスＡ　１６３８のＸＭＬでカプセル化された状態を特定し、ノード１６３２上でプロセスＡ　１６３６ｂを再開するためにそれを使用する。プロセスＡを再開するには、格納されている状態１６３８を使用してスレッド実行を再開し、一時変数を再計算し、リースされているリソースを再確立し、プロセス１６３８の格納されているＸＭＬ状態で記録されているとおりに実行を再開するのに必要な他の機能を実行する。
【０４７４】
分散コンピューティング環境でＸＭＬベースのプロセス移行を使用する一例を以下に示すが、制限することを意図していない。モバイル・クライアント・デバイスは、ノード１６３０に接続され、プロセスＡ　１６３６ａを実行している。モバイル・クライアント・デバイスのユーザは、ノード１６３０でプロセスＡ　１６３６ａの実行を停止し、後で、別の（または同じ）ノードから実行を再開しようと考えている。一実施形態では、ユーザは、プロセスＡ　１６３６ａの状態を格納し、後で実行再開すること望んでいるかどうかを判別するよう求められることがある。ユーザが肯定的に答えた場合、プロセスのＸＭＬでカプセル化された状態を捕捉し、永続的ストア１６３４に格納する。後から、ユーザはノード１６３２でモバイル・コンピューティング・デバイスに接続する。一実施形態では、ユーザはプロセス１６３６ｂを実行し、［Ｒｅｓｕｍｅ　ｆｒｏｍ　Ｓｔｏｒｅｄ　Ｓｔａｔｅ］オプションを選択する。次に、ノード１６３２は、プロセスＡ　１６３８のＸＭＬでカプセル化された状態をサーチして特定し、ダウンロードし、それを使用してプロセスＡ　１６３６ｂを再開する。それとは別に、プロセスはそれ自体、他のノード上で「サスペンド」していたことを認識し、ユーザの入力がなくても格納された状態から再開する。
【０４７５】
図４８は、分散コンピューティング環境でプロセスのデータ表現言語（ＸＭＬなど）表現を使用してプロセスを移行するメカニズムを示す。ステップ２２６０で、プロセスは第１のデバイス内で実行中である。ステップ２２６２で、プロセスの現在の計算状態が現在の計算状態のデータ表現言語表現に変換され、プロセスの計算状態には、第１のデバイス内のプロセスの実行状態に関する情報が含まれる。この情報は、それに限定されないが、プロセスの１つまたは複数のスレッドに関する情報、プロセスによって保持されているサービスに対する１つまたは複数のリースに関する情報、およびプロセス（スレッドによって保持されているオブジェクトなど）の１つまたは複数のオブジェクトに関する情報を含み、オブジェクトはコンピュータ・プログラミング言語（Ｊａｖａプログラミング言語など）によるクラスのインスタンスである。
【０４７６】
ステップ２２６４で、プロセスの現在の計算状態のデータ表現言語表現を格納する。一実施形態では、この表現はローカルに格納される。一実施形態では、スペース・サービスを使用してプロセスの現在の計算状態のデータ表現言語表現をスペースに格納する。一実施形態では、プロセスの現在の計算状態のデータ表現言語表現を１つまたは複数のメッセージでスペース・サービスに送る。
【０４７７】
ステップ２２６６で、第２のデバイスは、プロセスの現在の計算状態の格納されているデータ表現言語表現にアクセスする。一実施形態では、格納されているデータ表現言語表現について通知を送り、第２のデバイスはその通知を受け取るかまたはその通知にアクセスし、その通知内の情報を使用して、格納されているデータ表現言語表現を特定しアクセスする。ステップ２２６８で、プロセスは、プロセスの現在の計算状態のアクセスされたデータ表現言語表現から第２のデバイス内の現在の計算状態で再構成される。プロセスは、次に、現在の計算状態から第２のデバイス内で実行を再開する。
【０４７８】
それとは別に、プロセスの実行は、ステップ２２６４の後に第１のデバイスで終了する。その後、第１のデバイスは、続いて、プロセスの現在の計算状態の格納されているデータ表現言語表現にアクセスする。プロセスは次に、プロセスの現在の計算状態のデータ表現言語表現から第１のデバイス内の現在の計算状態で再構成され、プロセスの実行は現在の計算状態から第１のデバイス内で再開される。
【０４７９】
他の実施形態では、ステップ２２６２で生成されたプロセスの現在の計算状態のデータ表現言語表現を第２のデバイスに（たとえば、メッセージ・ゲートによる１つまたは複数のデータ表現言語メッセージで）直接送る。その後、プロセスは、プロセスの現在の計算状態の受け取られたデータ表現言語表現から第２のデバイス内の現在の計算状態で再構成される。プロセスは、次に、現在の計算状態から第２のデバイス内で実行を再開する。
【０４８０】
アプリケーション
ユーザがリモートの場所からネットワーク・データにアクセスし、ユーザがブラウザにアクセスした場合にリモート・データをユーザにローカル・データのように見せかける技術が存在する。ただし、このような技術では、クライアント・デバイスの位置近くのネットワークにクエリを実行する自動的インフラストラクチャが実現されない。クライアント・デバイス近くにあるネットワークおよびサービスに関する情報を発見するメカニズムがあることが望ましい。たとえば、このようなメカニズムを使用する際に、クライアント・デバイスの一定距離範囲（半径）内にあるレストラン、天候、地図、交通、映画情報などに関する情報を特定し、目的の情報をクライアント・デバイスに表示することができる。このメカニズムを使用する例として、ローカル環境、たとえば映画館の中で現在上映中作品のタイトルや上演時間を表示したり、レストランでメニュー選択と価格を表示するために、サービスを自動的に特定することができる携帯電話が考えられる。ここで説明しているような分散コンピューティング環境では、このようなメカニズムを使用してクライアント・デバイスに近接するローカル情報および／またはサービスを含むスペースを発見することができる。このメカニズムはさらに、他の分散コンピューティング環境、たとえば、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．のＪｉｎｉシステムで応用することができる。
【０４８１】
一実施形態では、モバイル・クライアント・デバイスは、グローバル・ポジショニング・システム（ＧＰＳ）機能と無線接続技術を備える。ローカル分散コンピューティング・ネットワークを実現できる。たとえば、都市に、全市内分散コンピューティング環境を築くことができる。他の例としては、ローカル分散コンピューティング環境を備えるショッピング・モールがある。ローカル分散コンピューティング・ネットワークは、クライアント・デバイスが分散コンピューティング環境に接続し、ローカル環境内でサービスおよびデータを発見することができる発見メカニズムを備える。たとえば、環境内の１つまたは複数のデバイスが無線接続技術を備え、これによりモバイル・クライアント・デバイスはネットワークに接続し、前述のＸＭＬメッセージング・システムを介して発見メカニズムにアクセスすることができる。ローカル分散コンピューティング環境は、サービスおよび／またはデータをモバイル・クライアントから利用できるようにするための通知を使用する１つまたは複数のスペースを備える。たとえば、全市内分散コンピューティング環境は、モール、映画館、ローカル・ニュース、ローカルの天候、交通などのエンティティを表すスペースを含む。スペースは、スペースが表すエンティティのサービスおよびそれに関する情報にアクセスするための個々のサービスおよび／またはデータ通知を含む。発見メカニズムは、ローカル分散コンピューティング環境、環境内のスペース・サービスによって表されるエンティティ、および／または環境内のスペースで通知されるさまざまなサービスの１つまたは複数のＧＰＳ位置測定機能を含む。
【０４８２】
一実施形態では、ローカル分散コンピューティング・ネットワークへの有線接続が提供される。この環境では、モバイル・クライアント・デバイスを使用するユーザは、有線接続の「ドッキング・ステーション」を使用してネットワークに直接「プラグイン」することができる。有線接続の例としては、これらに限定されないが、ユニバーサル・シリアル・バス（ＵＳＢ）、ＦｉｒｅＷｉｒｅ、およびツイストペア・インターネットなどがある。一実施形態では、トーキング・ステーションはさらに、モバイル・クライアント・デバイス用のキーボード、マウス、およびディスプレイなどの入出力機能を備える。この実施形態では、モバイル・クライアント・デバイスの位置が、ドッキング・ステーションによりルックアップ・メカニズム又は発見メカニズムに送られる。
【０４８３】
一実施形態では、モバイル・クライアント・デバイスは、分散コンピューティング・ネットワークに接続する。モバイル・クライアント・デバイスのユーザが分散コンピューティング・ネットワークの無線通信到達範囲内でナビゲートするときに、モバイル・クライアント・デバイスは、常時、またはさまざまな間隔で、ローカル・ルックアップ・メカニズム又は発見メカニズムへの入力として位置ベクトルを供給する。モバイル・クライアント・デバイスは、モバイル・クライアントに組み込まれている、または関連付けられているＧＰＳシステムから位置ベクトルを取得する。一実施形態では、クライアントは位置情報を（たとえば、ＸＭＬメッセージングを介して）ここで説明したスペース特定メカニズムなどのローカル・サービス発見メカニズムに送る。たとえば、クライアントは、クライアントの位置の特定の範囲内でサービスを提供するスペースの発見を指定するスペース発見プロトコルを実行するか、またはクライアントはクライアントの近傍に対して提供されるサービスを通知するスペースをサーチするためのスペース・サーチ・サービスをインスタンス化する。
【０４８４】
モバイル・クライアント・デバイスが分散コンピューティング環境内のスペースの指定された範囲内に移動したときに、そのスペース内に格納されているサービスおよび／またはデータをモバイル・クライアント・デバイスから利用できるようにする。クライアント・デバイスが定期的にその位置を発見メカニズムに伝える実施形態では、ローカル・サービスおよび／またはデータは自動的に、クライアントのユーザから利用できるようになる。一実施形態では、モバイル・クライアント・デバイスのユーザは、スペースの指定された範囲を調べる。たとえば、ユーザは選択により、現在の位置から１マイルの範囲内にあるすべてのレストランを表示することができる。それとは別に、ローカル分散コンピューティング・ネットワークの構成で範囲を指定することもできる。たとえば、市境から３マイル以内にいるすべてのユーザにそのサービスを提供するように、全市内分散コンピューティング・ネットワークを構成することができる。一実施形態では、スペースによって提供されるさまざまなサービスおよび／またはデータを表す視覚的インジケータ、たとえば、アイコンをモバイル・クライアント・デバイスに表示することができる。そこで、クライアントは、表示されているサービスおよび／またはデータの１つまたは複数にアクセスすることができる。一実施形態では、２つまたはそれ以上のスペースから得た情報を同時に、モバイル・クライアント・デバイスに表示することができる。一実施形態では、ユーザは検出するサービスおよび／またはデータを選択することができる。たとえば、ショッピング・モールでは、モバイル・クライアント・デバイスを携帯するユーザは選択により、モール内のすべての靴屋を表示することができる。
【０４８５】
一実施形態では、コードの実行で使用される実行可能コードおよび／またはデータをモバイル・クライアント・デバイスにダウンロードし、ユーザがスペース内のサービスによって提供されるアプリケーションを実行するようにできる。たとえば、映画を見に行く人は、モバイル・クライアント・デバイスがあれば、映画館のスペース内のサービスから対話的な映画レビューをダウンロードし、自分が見ている映画に関するフィードバックをリアルタイムで送り返すことができる。一実施形態では、別のところで説明しているように、ＸＭＬオブジェクト・コンパイル／逆コンパイル・メカニズムを使用し、コードおよび／またはデータをコンパイルしてコードおよび／またはデータのＸＭＬ表現を出力したり、ＸＭＬ表現を逆コンパイルしてコードおよび／またはデータをモバイル・クライアント・デバイスに再現することができる。一実施形態では、プロセスの実行可能バージョンがすでにモバイル・クライアント・デバイスに存在し、プロセスの格納された状態をモバイル・クライアント・デバイスにダウンロードすることにより、ユーザが格納されている状態を使用してプロセスを実行することができる。一実施形態では、プロセスの実行可能バージョンがすでにモバイル・クライアント・デバイスに存在し、プロセスのデータをモバイル・クライアント・デバイスにダウンロードできる。たとえば、データをダウンロードして、モバイル・クライアント・デバイスのビューア・プログラムで表示することができる。一実施形態では、プロセスを実行するためのコードおよびデータを含むプロセスの実行可能バージョンをダウンロードして、モバイル・クライアント・デバイスで実行することができる。一実施形態では、モバイル・クライアント・デバイスに代わってサービスがリモートからアプリケーションを実行し、サービスとクライアントが、データおよびオプションでデータを記述するＸＭＬスキーマを含むＸＭＬメッセージを互いにやり取りすることができる。一実施形態では、サービス上で一部のコードを実行し、クライアント上で一部のコードを実行することができる。たとえば、サービスは、数値計算などのデータ・セットに対する演算を行うコードを実行することができる。モバイル・クライアント・デバイスは、ＸＭＬメッセージでサービスからクライアントに渡されたデータの一部を表示し、モバイル・クライアント・デバイスのユーザがデータを入力したり選択したり、またデータをサービスに送ってデータに対し１つまたは複数の演算を実行できるようにするコードを実行する。
【０４８６】
一実施形態では、モバイル・クライアント・デバイスは、分散コンピューティング・ネットワーク内で２つまたはそれ以上のサービスに同時に接続することができる。これらのサービスは、独立に使用することも、また一連のタスクを実行するのと合わせて使用することもできる。たとえば、１つのサービスをリモート・クライアント・デバイスが使用してデータ・セットに対する演算を特定しかつ／または実行し、第２のサービスを使用してデータ・セットを印刷する。
【０４８７】
図３８は、一実施形態によりローカルの分散コンピューティング・ネットワークでスペースにアクセスするモバイル・クライアント・デバイスの図である。ＧＰＳ対応モバイル・コンピューティング・デバイス１７００のユーザは、ローカル分散コンピューティング環境の近傍内に移動する。モバイル・クライアント・デバイス１７００は、ＧＰＳ１７０２によって提供される位置をローカル分散コンピューティング・ネットワーク内の１つまたは複数の発見メカニズム１７０６に送る。発見メカニズム１７０６は、モバイル・クライアント・デバイスの提供されたＧＰＳ位置と環境内のスペースの所定の位置を使用して、ユーザがいつ１つまたは複数のスペースの指定された範囲内または環境内の１つまたは複数のスペースが対応する近傍内を移動するかを判別する。たとえば、発見メカニズム１７０６は、モバイル・クライアント・デバイス１７００がスペース１７０４の範囲内を移動したことを判別できる。発見メカニズム１７０６は、そこで、スペース１７０４からモバイル・クライアント・デバイス１７００に１つまたは複数の通知１７１０を送る。それとは別に、発見メカニズム１７０６は、スペース１７０４またはスペース１７０４内の１つまたは複数の通知のＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）をモバイル・クライアント・デバイス１７００に送る。サービス通知１７０８で通知されるさまざまなサービスおよび／またはコンテンツ通知１７１０で表されるデータを表すアイコンを、モバイル・クライアント・デバイス１７００に表示することができる。そこで、ユーザはモバイル・クライアント・デバイスで実行するかつ／または表示するため通知されたサービスおよび／またはデータのうち１つまたは複数を選択できる。モバイル・コンピューティング・デバイス１７００は、サービスを提供するデバイスと無線接続を確立し、そのデバイスと通信して、前述のようにＸＭＬベースのメッセージング・システムを使用してサービスを実行する。それとは別に、モバイル・コンピューティング・デバイス１７００のユーザはドッキング・ステーションでデバイスに接続する。ドッキング・ステーションの位置は、ユーザがルックアップ・メカニズムまたは発見メカニズム１７０６と、ドッキング・ステーションの通知を含むスペースを使用してユーザの指定範囲内にあるストッキング・ステーションの位置を発見し利用できるかどうかを判別することにより、発見される。発見メカニズム１７０６は、さらに、モバイル・クライアント・デバイス１７００がスペース１７１４の選択された範囲内に移動したときにそのことを検出できる。さまざまなサービス通知１７１８およびコンテンツ通知１７２０をモバイル・クライアント・デバイス１７００のユーザから利用できるようにする。モバイル・クライアント・デバイスがスペースの１つの指定範囲の外に出たときに、そのスペースによって提供される通知はモバイル・クライアント・デバイス１７００のディスプレイから削除される。一実施形態では、スペース上の通知は、提供されるサービスまたはデータの位置情報を含む。したがって、発見メカニズム１７０６は、モバイル・クライアント・デバイス１７００がスペース１７１８上で通知された特定のサービスの指定範囲内をいつ移動したかを判別し、モバイル・クライアント・デバイス１７００の位置に基づいてサービス通知を送る（または削除する）。
【０４８８】
コンピューティング・デバイスは、同時にパワーと機能を獲得する一方でダウンサイジングを進めている。ストレージ・デバイス、ＣＰＵ、ＲＡＭ、Ｉ／Ｏ　ＡＳＩＣＳ、電源など、サイズが小さくなり、小型のモバイル・クライアント・デバイスにフルサイズのパソコンの機能の多くを搭載できる。しかし、コンピュータ・システムのコンポーネントのいくつかは、人的要因およびその他の要因のせいで簡単には縮小できない。こうしたコンポーネントとしては、それらに限定されないが、キーボード、モニタ、スキャナ、およびプリンタがある。一部のコンポーネントのサイズを縮小することに限度があるため、モバイル・クライアント・デバイスはパソコンの役割を真に肩代わりすることはできない。
【０４８９】
一実施形態では、ユーザがモバイル・クライアント・デバイスを使い、人的要因やその他の要因によりモバイル・クライアント・デバイスでは利用できないコンポーネントに接続し使用できるようにするドッキング・ステーションが提示されている。たとえば、ドッキング・ステーションは、空港や図書館などの公共の場所に備えることができる。ドッキング・ステーションは、モニタ、キーボード、プリンタ、またはモバイル・クライアント・デバイスを使用するユーザ用のその他のデバイスを備える。一実施形態では、ドッキング・ステーションは、ユーザが接続しているモバイル・クライアント・デバイスなどの実際のコンピューティング・デバイスの助けがないと完全には機能しない。ドッキング・ステーションは、さまざまな入出力機能などのサービスを、モバイル・クライアント・デバイスの計算能力を使用するクライアントに提供する。
【０４９０】
ドッキング・ステーションは、１つまたは複数の接続用オプションをモバイル・クライアント・デバイスに提供する。接続オプションには、無線接続や有線接続がある。無線接続の例としては、それらに限定されないが、ノートブック・コンピュータのネットワーク・インターフェース・カード（ＮＩＣ）で提供されるようなＩｒＤＡなどの赤外線や、無線ネットワーク接続がある。有線接続の例としては、それらに限定されないが、ＵＳＢ、ＦｉｒｅＷｉｒｅ、およびツイストペアＥｔｈｅｒｎｅｔなどがある。
【０４９１】
モバイル・クライアント・デバイスは、モバイル・クライアント・デバイスについて上述したものに実質的に似た方法を使用してドッキング・ステーションの位置を発見する。ローカル分散コンピューティング・ネットワーク内の１つまたは複数のドッキング・ステーションの位置を発見するには、発見メカニズムを使用して、ドッキング・ステーションの通知があるスペースを発見する。モバイル・クライアント・デバイスは、位置を発見メカニズムに送る。一実施形態では、発見メカニズムまたはルックアップ・メカニズムは、モバイル・クライアント・デバイスの位置に最も近い１つまたは複数のドッキング・ステーションの位置を返す。それとは別に、発見メカニズムまたはルックアップ・メカニズムはドッキング・ステーションの通知を含むスペースのＵＲＩを返し、その後、モバイル・クライアント・デバイスはスペースに接続して、デバイスに近いところにある１つまたは複数のドッキング・ステーションの位置を送る。一実施形態では、モバイル・クライアント・デバイスは、ルックアップ・メカニズム又は発見メカニズムに情報を供給し、モニタの解像度、画面サイズ、グラフィック能力、プリンタやスキャナなどの使用可能なデバイスなどの要求条件を指定することができる。一実施形態では、さまざまなドッキング・ステーションの使用可能性（ドッキング・ステーションを使用する他のユーザから）、コンポーネント、および能力などの１つまたは複数のドッキング・ステーションに関する情報をモバイル・クライアント・デバイスのユーザに提供する。
【０４９２】
ユーザがドッキング・ステーションに接近すると請求プロトコルが開始する。ドッキング・ステーションがその請求を受理すると、セキュリティで保護された入出力接続が、モバイル・クライアント・デバイスとドッキング・ステーションとの間で確立される。それとは別に、ユーザはモバイル・クライアント・デバイスに表示されるルックアップ・メカニズム又は発見メカニズムを使用して発見された１つまたは複数のドッキング・ステーションのうちからドッキング・ステーションを選択する。ユーザがドッキング・ステーションを選択すると請求プロトコルが開始し請求の持続時間中、ユーザに、ドッキング・ステーションへのセキュリティで保護された排他的接続が与えられる。ユーザがドッキング・ステーション上のセッションを終了し、ドッキング・ステーションを開放して他のユーザが利用できるようにするドッキング・ステーションの解放方法も定める。一実施形態では請求プロトコルは、前述のようにドッキング・ステーション・サービス上のリースとすることができる。
【０４９３】
図３９ａは、一実施形態により、モバイル・デバイスのユーザがドッキング・ステーションの場所を発見することを示す図である。モバイル・クライアント・デバイス１７５０は、発見メカニズム１７５６と接続する。モバイル・クライアント・デバイス１７５０は、ＧＰＳ　１７５２を使用して得られた位置を発見メカニズム１７５６に送る。モバイル・クライアント・デバイス１７５０は、さらに、ドッキング・ステーションの要求条件を発見メカニズム１７５６に送る。発見メカニズム１７５６は、モバイル・クライアント・デバイス１７５０の要求条件を満たすドッキング・ステーション１７５８の通知に対して１つまたは複数のスペース１７５４をサーチする。一実施形態では、ルックアップ・メカニズム又は発見メカニズムが、通知１７５８に格納されている位置情報をモバイル・デバイス１７５０の与えられた位置と比較してモバイル・デバイス１７５０の指定範囲内にある１つまたは複数のドッキング・ステーションを特定する。発見メカニズム１７５６は、そこで、モバイル・クライアント・デバイス１７５０の指定範囲内にある１つまたは複数のドッキング・ステーションの位置を与える。それとは別に、発見メカニズム１７５６はモバイル・クライアント・デバイス１７５０に最も近いドッキング・ステーションを特定し、その位置をモバイル・クライアント・デバイス１７５０に送る。
【０４９４】
図３９ｂは、一実施形態によるドッキング・ステーション１７６０に接続するモバイル・クライアント・デバイス１７５０の図である。一実施形態では、ユーザはモバイル・クライアント・デバイス１７５０をドッキング・ステーション１７６０に無線で接続する。他の実施形態では、ユーザはドッキング・ステーション１７６０とモバイル・クライアント・デバイス１７５０とを１つまたは複数のケーブルで接続してクッキング・ステーション１７６０との有線接続を確立する。一実施形態では、モバイル・クライアント・デバイス１７５０のユーザはドッキング・ステーション１７６０への請求を確立する。この請求により、接続時間中、ドッキング・ステーションへのセキュリティで保護された排他的権限を確立する。一実施形態では請求メカニズムは、前述のようにリソース（ドッキング・ステーション）のリース・メカニズムである。一実施形態では、ユーザは、ドッキング・ステーションの使用に対し対価支払いを請求される。たとえば、ユーザは、ドッキング・ステーションを請求するプロセスの一部としてクレジット・カード番号を指定する。「メッセージ・ゲート」の項の請求書ゲートの説明を参照のこと。いったん接続されると、ユーザはキーボード、モニタ、プリンタなど、ドッキング・ステーション１７６０によって提供されるさまざまな機能を使用できる。ドッキング・ステーション１７６０はさらに、ローカル分散コンピューティング・ネットワークへの接続も含み、ドッキング・ステーション１７６０に接続されているモバイル・クライアント・デバイス１７５０のユーザに対しネットワーク内の他のデバイスのサービスおよびコンテンツ通知を特定する発見サービスを提供しているため、ユーザは前述のように、分散コンピューティング環境内のさまざまなサービスおよびコンテンツを特定し、使用することができる。
【０４９５】
ユーザは、終了すると、モバイル・クライアント・デバイス１７５０をドッキング・ステーション１７６０から切断する。一実施形態ではドッキング・ステーションの解放メカニズムは、モバイル・クライアント・デバイス１７５０がドッキング・ステーション１７５０から切断されると自動的に開始する。この解放メカニズムにより、モバイル・クライアント・デバイス１７５０のユーザが確立したドッキング・ステーション１７６０の請求がクリアされる。一実施形態では、この解放メカニズムは、ドッキング・ステーションが利用できることを発見メカニズムに１７５６および／またはドッキング・ステーション通知１７５８に通知する。
【０４９６】
一実施形態では、ユーザは発見メカニズムを使用せずにモバイル・クライアント・デバイスをドッキング・ステーションに接続することができる。たとえば、空港内にいるユーザは、ドッキング・ステーションで目で見て見つけ、モバイル・クライアント・デバイスを接続する。他の例としては、複数のドッキング・ステーションを配置したドッキング・ステーション室を備える図書館が考えられ、ユーザはそこで利用可能なドッキング・ステーションにアクセスすることができる。
【０４９７】
省スペースおよび／または組み込み型デバイス
単純な組み込み型または省スペース・デバイスでは、プログラムの命令を格納し実行しようにもメモリ容量が限られている場合がある。単純な組み込み型デバイスは、デバイスの機能を開始するための制御入力とデバイスのステータスを報告するための出力に制限があることを認識する必要がある。単純な組み込み型デバイスの一例として、スイッチとそのスイッチにより制御されるデバイスを制御するための回路を組み込んだ「スマート」スイッチ（照明スイッチなど）がある。スマート・スイッチは、２つの制御要求（デバイスの状態を変更する、デバイスの状態を要求する）を認識し、１つのステータス・メッセージ（デバイスの状態）を送るだけでよい。スマート・スイッチは、１つまたは複数の制御システムから制御要求を受け取り、その１つまたは複数の制御システムにステータス・メッセージを報告することにより、接続されているデバイスを管理することができる。
【０４９８】
一実施形態では、分散コンピューティング環境は、分散コンピューティング環境の完全なプロトコルを実装するのに必要なリソース（メモリなど）が足りない小型デバイスを含めるためのフレームワーク（プロトコル）を提供する。一実施形態では、小型デバイス対応プロトコルと完全なプロトコルとの間にブリッジとしてエージェントを用意する。このエージェントは、小型デバイスのために完全なプロトコルの発見を実行するので、デバイスは完全な発見プロトコルおよびサービス・アクティブ化を実行する必要がない。一実施形態では、小型デバイスはサービス特有のメッセージを送るだけでよい。一実施形態では、これらのメッセージは、小型デバイスで事前に加工され、小型デバイスはサービス・アクティブ化の一部であるメッセージをエージェントに送るだけである。エージェントは、サービスに対し完全なプロトコルを介してサービス・アクティブ化を実行し、サービスからサービスへ着信メッセージを転送したり、サービス化がクライアントへ返信を転送したりすることができる。したがって、エージェントは小型クライアントのサービス・コネクタとして機能する。分散コンピューティング環境の一実施形態では、特定の制御要求セットをＸＭＬメッセージの形式で受け取り、要求、報告ステータスなどを作成する特定のＸＭＬメッセージ・セットを送るように組み込み型デバイスを構成することができる。一実施形態では、制御システムは、制御される各デバイスまたはデバイスのカテゴリに固有のＸＭＬ要求メッセージを送り、デバイスからＸＭＬメッセージを受け取ることによりさまざまなデバイスを管理するように構成できる。一実施形態では、１つまたは複数のＸＭＬスキーマを使用して、組み込み型デバイスの固有のＸＭＬメッセージ・セットを定義することができ、スキーマは、ＸＭＬメッセージを送受される際に組み込み型デバイスおよび／または制御システムによって使用される。
【０４９９】
組み込み型デバイスは、単純な組み込み型デバイスを制御し監視するための特定のメッセージ・セットをサポートする前述のようなＸＭＬメッセージング・システムの「軽量（シン）」実装を含む。ＸＭＬメッセージング・システムの実装は、省スペースの単純な組み込み型デバイスで使用できるように手直しされ、省スペース・デバイスの限られたメモリにも適合する。一実施形態では、ＸＭＬメッセージング・システムは、省スペース組み込み型デバイスをターゲットとする仮想マシン（たとえば、ＫＶＭ）を備える省スペース・デバイスに実装することができる。ネットワーキング・スタック（１つまたは複数の制御システムとの通信のためのトランスポート・プロトコルをサポートする）は、仮想マシンと関連付けられ、ＸＭＬメッセージング・レイヤはネットワーキング・スタックの「上に置かれる」。メッセージング・システムのこのような実装は、省スペース・デバイスや組み込み型デバイス以外のデバイスでも使用できることに注意されたい。
【０５００】
一実施形態では、静的メッセージまたは事前に生成されたメッセージを、制御システムから組み込み型デバイスへの要求に使用する。静的メッセージは、プリコンパイルされ、組み込み型デバイス内に格納される。着信メッセージを格納されている静的メッセージと比較し、メッセージのマッチがないか調べてメッセージで要求された機能を実行するので、着信メッセージを解析するためのコードの必要性が減じられるか、またはその必要がない。発送メッセージは、格納されている静的メッセージから直接読み取られるため、発送メッセージを動的にコンパイル必要は少ないか、またはその必要がない。したがって、静的メッセージは、組み込み型システムのメッセージング・レイヤのコード量を減らすために使用される。たとえば、静的なＪａｖａオブジェクト（Ｊａｖａ　ｏｐコード）を要求メッセージとステータス・メッセージに使用できる。
【０５０１】
図４０ａは、一実施形態により、制御システム１８００により制御される組み込み型デバイス１８０４ａと１８０４ｂの一実施形態を示す。制御システム１８００は、そのシステムが制御するデバイス１８０４ａおよび１８０４ｂとさまざまな方法でネットワークにつながっている。ネットワーク１８１０は有線（Ｅｔｈｅｒｎｅｔ、同軸、ツイストペア、電力網など）および／または無線（ＩｒＤＡ、マイクロ波など）を利用できる。一実施形態では、組み込み型デバイス１８０４ａおよび１８０４ｂは、ネットワーク１８１０上で制御システム１８００と通信するためＸＭＬメッセージング・システムのシン実装を備える。制御システム１８００は、組み込み型デバイス１８０４ａおよび１８０４ｂに要求を送り、そこから応答を受け取るためのＸＭＬメッセージング・システムの実装を用意する。一実施形態では、制御システム１８００は、ユーザが組み込み型デバイス１８０４ａと１８０４ｂのステータスを表示し、遠隔制御するためのインターフェースを備えるように構成されたソフトウェアおよびハードウェアを搭載する。一実施形態では、制御システム１８００は、組み込み型デバイス１８０４ａおよび１８０４ｂの自動制御を行うためのソフトウェアおよび／またはハードウェアを備える。
【０５０２】
一実施形態では、組み込み型デバイス１８０４ａと１８０４ｂは、他の環境の一部である。それらのデバイスは、分散ネットワーク環境で実装されているメッセージ通信モデルをサポートしていない。たとえば、これらのデバイスは、ＬｏｎＷｏｒｋｓネットワークなどのネットワークで接続されたオートメーションおよび制御システム内のノードである。制御システム１８００は、他の環境内のデバイスを制御するための制御システムのハードウェアおよび／またはソフトウェアを含む。制御システム１８００は、分散コンピューティング環境と他の環境との間のブリッジとして使用される。分散コンピューティング環境ではさらに、分散コンピューティング環境からアクセスするデバイスを発見するため既存のデバイス発見プロトコルをラップする１つまたは複数の方法も備える。ブリッジおよびラップを行うプロトコルについては「ブリッジ」の項で詳述する。
【０５０３】
制御システム１８００は、リモートまたはローカルで、分散コンピューティング環境内の１つまたは複数の他のシステムに接続する。図４０ａは、インターネット１８０２を介してクライアント１８０６に接続されている制御システム１８００を示している。クライアント１８０６は、制御システム１８００を通じて、組み込み型デバイス１８０４ａおよび１８０４ｂのステータスを間接的に要求し、その制御要求を送る。したがって、制御システム１８００は、組み込み型デバイス１８０４ａおよび１８０４ｂのプロキシまたはブリッジとして使用される。「ブリッジ」の項を参照されたい。クライアント１８０６と制御システム１８００との間の高度な通信を有効にするために、クライアントと制御システムは、組み込み型デバイス１８０４ａおよび１８０４ｂ上のシン実装と異なるＸＭＬメッセージング・システムの実装を備える。一実施形態では、クライアント１８０６は、ユーザが組み込み型デバイス１８０４ａと１８０４ｂのステータスを表示し、遠隔制御するためのインターフェースを備えるように構成されたソフトウェアおよびハードウェアを搭載する。一実施形態では、クライアント１８０６は、正しい承認証明書を制御システム１８００に提示し、クライアント１８０６が組み込み型デバイス１８０４ａおよび１８０４ｂにアクセスできるようにする必要がある。一実施形態では、クライアント１８０６は、異なるレベルのアクセス権を与えられる。たとえば、クライアント１８０６は、組み込み型デバイス１８０４ａおよび１８０４ｂのステータスを表示することしかできず、デバイスを遠隔制御することはできない。一実施形態では、制御システム１８００はサービスであり、分散コンピューティング環境でサービス通知がパブリッシュされ、そのため、クライアント１８０６は前述のようにクライアント−サービス手法を使用してアクセスできる。一実施形態では、クライアント１８０６は制御システム１８００のステータスを表示し、遠隔制御することができる。
【０５０４】
図４０ｂは、一実施形態により、インターネット１８０２を介して組み込み型デバイス１８０４ｃおよび１８０４ｄに接続されているクライアント制御システム１８０８を示している。一実施形態では、組み込み型デバイス１８０４ｃおよび１８０４ｄは、ネットワーク１８０２上でクライアント制御システム１８０８と通信するためＸＭＬメッセージング・システムのシン実装を備える。クライアント制御システム１８０８は、組み込み型デバイス１８０４ｃおよび１８０４ｄに要求を送り、そこから応答受け取るためのＸＭＬメッセージング・システムの実装を用意する。一実施形態では、クライアント制御システム１８０８は、ユーザが組み込み型デバイス１８０４ｃと１８０４ｄのステータスを表示し、遠隔制御するためのインターフェースを備えるように構成されたソフトウェアおよびハードウェアを搭載する。一実施形態では、クライアント制御システム１８００は、組み込み型デバイス１８０４ｃおよび１８０４ｄの自動制御を行うためのソフトウェアおよび／またはハードウェアを備える。
【０５０５】
図４０ａと図４０ｂとの違いは、図４０ｂに示されている実施形態では、組み込み型デバイス１８０４ｃと１８０４ｄは、プロキシ（たとえば、制御システム）なしで分散コンピューティング環境内の１つまたは複数のクライアントによりアクセスされるという点である。組み込み型デバイス１８０４ｃおよび１８０４ｄは、デバイスの機能にアクセスするためのサービスを備え、分散コンピューティング環境内でサービス通知をパブリッシュし、前述のようにクライアント−サービス手法を介してアクセスされる。
【０５０６】
分散コンピューティング環境は、リソースが制限されているクライアントがＵｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）アドレス指定リソースを取り出すためのメカニズムを備える。たとえば、ＩｒＤＡ接続を介してでないとメッセージを送受できないクライアントは、ＵＲＩ接続を確立して、結果スペースから結果を取り出すことができない。一実施形態では、クライアントとＵＲＩリソースとの間のブリッジとしてサービスを提供する。ブリッジ・サービスは、ＸＭＬメッセージを介してクライアントと対話し、入力パラメータを集める。以下に、ＸＭＬ入力メッセージシンタックスの一例を示したが、何らかの形で制限することを意図していない。
Figure 2004504657
【０５０７】
次に、分散コンピューティング環境の外部で、ブリッジ・サービスはＵＲＩ接続を確立し、リソースを取り出す。リソースは、１つまたは複数のＸＭＬメッセージでペイロードとしてカプセル化され、ブリッジ・サービスによってクライアントに送られる。
【０５０８】
ＸＭＬメッセージング・システムのシン実装を備える組み込み型デバイスの可能な使い方の一例を説明のため掲載しているが、制限することを意図していない。建物には、エネルギーを消費する複数のエレクトロニクス・デバイス（たとえば、照明、空調、事務機器）が置かれているため、最適なエネルギー消費レベルを維持するためのシステムを必要とする。このような複数のデバイスはそれぞれ、エレクトロニクス・デバイスを制御するための組み込み型デバイスを備える。これらの組み込み型デバイスは、ＸＭＬメッセージング・システムのシン実装を備える。１つまたは複数の制御システムを、ネットワーク、たとえば、建物内ＬＡＮやさらにはインターネット内のデバイスに結合する。制御システムでは、建物管理ソフトウェア・パッケージおよびデバイスを監視し制御するためソフトウェア・パッケージによって使用されるように構成されているＸＭＬメッセージング・システムの実装を格納し、実行する。制御システムは、ユーザからの入力を受け付け、複数のデバイスのそれぞれのステータス情報はじめとする、建物内エネルギー消費システムのステータス情報を表示し、他の何らかの方法で出力する。エネルギー消費は、複数のデバイスのそれぞれからＸＭＬステータス・メッセージを受け取ることにより監視する。エネルギー消費レベルを調整する必要がある場合、ＸＭＬ制御メッセージを１つまたは複数のデバイスに送ってエネルギー消費を変更させる。
【０５０９】
サービスの実装
一実施形態では、分散コンピューティング環境はサービスをサーブレットとして実装するためのメカニズムを備える。このメカニズムは、分散コンピューティング環境向けにサービスを開発するための機能を備える。
【０５１０】
一実施形態では、スペース内でサービスを初期化し登録するための機能を備えるアプリケーション・プログラミング・インターフェース（ＡＰＩ）が提供される。一実施形態では、このＡＰＩを使用して、サービスの初期化機能を呼び出し、サービスのステータスを定義する初期化ステータス・ページ、たとえば、ＨＴＭＬページを生成することができる。ユーザは、ブラウザからステータス・ページにアクセスすることによりサービスのステータスにアクセスできる。一実施形態では、ＡＰＩを使用して、着信メッセージを処理し、そのメッセージに応答してドキュメントを生成する。
サーブレット・メカニズムの実施形態では、それに限定されないが、以下のような複数の機能を提供する。
サービスへのクライアント接続の管理（一意的なセッションＩＤ）
結果通知を格納するために使用されるアクティブ化スペースの管理
アクティブ化スペースの接続セッションおよび結果に対するリースの管理
セッションおよび結果のガベージ・コレクション
クライアントの認証
セッションごとのクライアント機能の生成
【０５１１】
一実施形態では、分散コンピューティング環境は、新しい複雑なサービスを他の既存のサービスから構築するためのサービス・カスケード接続メカニズムを備える。たとえば、ＪＰＥＧ−ＰｏｓｔＳｃｒｉｐｔ変換サービスおよび印刷サービスから、変換および印刷サービスを組み合わせることで、第３のカスケード接続されたサービスを作成する。一実施形態では、２つまたはそれ以上のサービスのアクセス・メソッドをカスケード接続されたサービスのアクセス・メソッドとして定義することにより２つまたはそれ以上のサービスを組み合わせて１つの複雑なサービスを作る。カスケード接続サービスに対する以下のサービス通知は、説明のため掲載したものであり、いかなる形でも制限することを意図していない。
Figure 2004504657
【０５１２】
結論
さまざまな実施形態はさらに、キャリア媒体に関する前述の説明により実装された命令および／またはデータを受け取り、送り、または格納することを含む。一般に、キャリア媒体には、磁気または光媒体などの記憶媒体やメモリ媒体、たとえば、ディスクやＣＤ−ＲＯＭ、ＲＡＭ（ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性または不揮発性媒体、さらに、ネットワークおよび／または無線リンクなどの通信媒体を介して伝達される電気信号、電磁信号、またはデジタル信号などの伝送媒体または信号が含まれる。
【０５１３】
本開示を利用しようとする当業者には明白なように、さまざまな修正および変更が可能である。本発明はそのような全ての修正および変更を包括的に取り入れることを意図しており、したがって、明細書、付録、および図面は、制限のためではなく、説明のためであるとみなすべきである。
【図面の簡単な説明】
【図１】
従来の分散コンピューティング技術の積み重ねの図である。
【図２】
一実施形態による分散コンピューティング環境プログラミング・モデルの図である。
【図３】
一実施形態による分散コンピューティング環境のメッセージング・レイヤおよびネットワーキング・レイヤの図である。
【図４】
一実施形態により分散コンピューティング環境でオブジェクトまたはサービスを通知するスペースを見つけるための発見サービスの図である。
【図５】
一実施形態による分散コンピューティング環境の静的メッセージおよび書式付きメッセージをサポートするクライアント・プロファイルの図である。
【図６】
一実施形態によるＸＭＬメッセージングを採用する分散コンピューティング・モデルの図である。
【図７】
一実施形態によるプラットフォーム独立の分散コンピューティング環境の図である。
【図８】
一実施形態によりスペース内でサービスが通知される分散コンピューティング・モデルの図である。
【図９】
一実施形態によりスペース内に結果が格納される分散コンピューティング・モデルの図である。
【図１０】
ａ：一実施形態による分散コンピューティング・モデル内のメッセージング・エンドポイントとしてのクライアントおよびサービス・ゲートの図である。
ｂ：　一実施形態によりサービスにアクセスするためスキーマに従ってメッセージ・エンドポイントを生成することを示す図である。
【図１１】
ａ：一実施形態による分散コンピューティング環境におけるゲート作成の図である。
ｂ：一実施形態による分散コンピューティング環境におけるゲート作成とゲート・ペアの図である。
【図１２】
一実施形態による分散コンピューティング環境での可能なゲート構成要素の図である。
【図１３】
一実施形態による分散コンピューティング環境に参加する従来のプラウザ用のプロキシ・クライアントの図である。
【図１４】
一実施形態により分散コンピューティング環境でメソッド・ゲートを使用してリモート・メソッド呼び出しインターフェースをサービスに提供する方法を示す図である。
【図１５】
一実施形態により分散コンピューティング環境でスペースを使用する方法を示す図である。
【図１６】
一実施形態による通知構造を示す図である。
【図１７】
一実施形態により通知がその存続期間中に置かれる通知状態遷移の一例を示す図である
【図１８】
一実施形態による分散コンピューティング環境でのさまざまなスペース特定メカニズムの図である。
【図１９】
一実施形態による分散コンピューティング環境でのスペース連合の図である。
【図２０】
一実施形態により分散コンピューティング環境でクライアントがスペース・サービスによりセッションを形成する方法を示す流れ図である。
【図２１】
一実施形態のスペース・イベント型階層の図である。
【図２２】
一実施形態による分散コンピューティング環境でのサービス・インスタンス化を示す流れ図である。
【図２３】
一実施形態による分散コンピューティング環境でのデフォルトのスペースの図である。
【図２４】
一実施形態により、近傍ベースのデバイスから提供されるサービスをデバイスの近傍の範囲外にあるデバイスでアクセスできるようにする近傍ベースのデバイスを他のトランスポート・メカニズムにブリッジするデバイスの一例を示す図である。
【図２５】
一実施形態により分散コンピューティング環境でリース更新メッセージを使用する方法を示す図である。
【図２６】
ａ：一実施形態により、認証証明書をクライアントに提供する認証サービスを示す流れ図である。
ｂ：一実施形態により、図２６ａのステップ１００２上で展開し、認証証明書を生成する認証サービスを示す流れ図である。
【図２７】
ブリッジ・メカニズムの一実施形態の図である。
【図２８】
一実施形態により外部発見サービスにマップされるスペース発見プロトコルの一例の図である。
【図２９】
一実施形態により、分散コンピューティング環境の外部にあるクライアントを分散コンピューティング環境内のスペースにブリッジする方法を示す図である。
【図３０】
一実施形態によるプロキシ・メカニズムの図である。
【図３１】
一実施形態による関連するディスプレイおよび表示サービスを備えるクライアントの一実施形態の図である。
【図３２】
一実施形態により動的表示オブジェクトのスキーマを使用する例を示す図である。
【図３３】
Ａ：Ｃプログラミング言語による代表的文字列表現の図である。
Ｂ：従来の文字列関数の例を示す図である。
Ｃ：一実施形態により、一般には文字列を、具体的には組み込み型システムなどの省スペース・システムを表現し管理する効率的な方法を示す図である。
【図３４】
一実施形態により、クライアントとサービスの間でオブジェクトを移動するプロセスを示す図である。
【図３５】
仮想マシン（たとえば、ＪＶＭ）がオブジェクト（たとえば、Ｊａｖａオブジェクト）をオブジェクトのＸＭＬ表現にコンパイルする拡張機能および（Ｊａｖａ）オブジェクトのＸＭＬ表現を（Ｊａｖａ）オブジェクトに逆コンパイルする拡張機能を含む実施形態を示すデータ流れ図である。
【図３６】
一実施形態により分散コンピューティング環境でストア・メカニズムにアクセスするクライアントおよびサービスの図である。
【図３７】
一実施形態によりプロセスの状態のＸＭＬ表現を使用するプロセス移行を示す図である。
【図３８】
一実施形態によりローカルの分散コンピューティング・ネットワークでスペースにアクセスするモバイル・クライアント・デバイスの図である。
【図３９】
ａ：一実施形態により、モバイルデバイスのユーザがドッキング・ステーションの場所を発見すること示す図である。
ｂ：一実施形態によるドッキング・ステーションに接続するモバイル・クライアント・デバイスの図である。
【図４０】
ａ：一実施形態により、制御システムにより制御され、分散コンピューティング環境内でアクセス可能な組み込み型デバイスの一実施形態を示す図である。
ｂ：一実施形態により、ネットワーク（たとえば、インターネット）を介して分散コンピューティング環境内でアクセス可能な組み込み型デバイスに接続するデバイス制御システムの図である。
【図４１】
一実施形態によるゲートを作成する方法を示す流れ図である。
【図４２ａ】
一実施形態によりクライアントがメッセージをサービスに送る方法を示す流れ図である。
【図４２ｂ】
一実施形態によりクライアントからメッセージ受け取り、認証サービスを使用してメッセージを認証するサービスを示す流れ図である。
【図４２ｃ】
一実施形態によりクライアントおよびサービスがメッセージを埋め込まれた認証証明書と交換する一般的プロセスを示す流れ図である。
【図４３】
一実施形態によりメッセージの完全性を確認するメカニズムを示す流れ図である。
【図４４】
一実施形態によるリソースをリースするメカニズムを示す流れ図である。
【図４５ａ】
メソッド・ゲートを使用するクライアントとサービスとの間の通信のメカニズムのさまざまな実施形態を示す流れ図である。
【図４５ｂ】
メソッド・ゲートを使用するクライアントとサービスとの間の通信のメカニズムのさまざまな実施形態を示す流れ図である。
【図４５ｃ】
メソッド・ゲートを使用するクライアントとサービスとの間の通信のメカニズムのさまざまな実施形態を示す流れ図である。
【図４５ｄ】
メソッド・ゲートを使用するクライアントとサービスとの間の通信のメカニズムのさまざまな実施形態を示す流れ図である。
【図４５ｅ】
メソッド・ゲートを使用するクライアントとサービスとの間の通信のメカニズムのさまざまな実施形態を示す流れ図である。
【図４６】
オブジェクトのＸＭＬ表現を使用してサービスからクライアントにオブジェクトを送るメカニズムを示す流れ図である。
【図４７】
クライアント・デバイスでセキュリティで保護されたオブジェクト逆コンパイルのメカニズムを示す流れ図である。
【図４８】
分散コンピューティング環境でプロセスのデータ表現言語表現を使用してプロセスを移行するメカニズムを示す流れ図である。

Claims (68)

  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. クライアント・コンポーネントと、
    メソッド・ゲートと
    を含むデバイスであって、
    クライアント・コンポーネントが、コンピュータ・プログラミング言語のメソッド・コールを生成するように構成され、
    メソッド・ゲートが、
    クライアント・コンポーネントによって生成されたコンピュータ・プログラミング言語のメソッド・コールにアクセスすること、
    コンピュータ・プログラミング言語のメソッド・コールを表す情報を含むメッセージをデータ表現言語で生成することであって、メッセージが、さらに、クライアント・デバイスが分散コンピューティング環境内のサービスにアクセスできるようにする証明書を含むこと、および、
    メッセージをサーバに送ることを行うように構成され、
    サービスが、メッセージに含まれる証明書を検査することによってメッセージを真正として認証し、メッセージが真正として認証される場合に、メッセージに含まれるコンピュータ・プログラミング言語のメッセージ呼出しを表す情報に従って、クライアント・コンポーネントに代わって関数を実行するように動作可能であるデバイス。
  46. メソッド・ゲートが、デバイスがサービスに送ることを許可されるデータ表現言語のメッセージの記述を含むデータ表現言語のメッセージ・スキーマを含み、メッセージの前記生成が、メッセージ・スキーマに含まれるメッセージの記述に従って実行される請求項４５に記載のデバイス。
  47. サービスが、さらに、関数によって生成される結果データを分散コンピューティング環境内のスペース・サービスに格納するように動作可能であり、クライアント・コンポーネントが、さらに、
    結果データに関するデータ表現言語の通知にアクセスし、通知が、結果データへのクライアント・コンポーネントによるアクセスを可能にする情報を含むこと、
    格納された結果データに関する供給された通知内の情報に従って、スペース・サービスから結果データにアクセスすること
    を行うように構成される請求項４５に記載のデバイス。
  48. 前記コンピュータ・プログラミング言語が、Ｊａｖａプログラミング言語であり、メッセージ内でメソッド・コールを表す情報が、サービス側で実装されるＪａｖａメソッドへのＪａｖａメソッド・コールを表す請求項４５に記載のデバイス。
  49. コンピュータ・プログラミング言語のメソッド・コールを表す情報を含むメッセージをデータ表現言語で生成するように構成されたクライアント・コンポーネントと、
    クライアント・コンポーネントが分散コンピューティング環境内のサービスにアクセスできるようにするためにメッセージに証明書を付加すること、および、
    メッセージを分散コンピューティング環境内のサービスに送ること
    を行うように構成されたメッセージ・エンドポイントと
    を含むデバイスであって、
    サービスが、メッセージに含まれる証明書を検査することによってメッセージを真正として認証し、メッセージが真正である場合に、メッセージに含まれるコンピュータ・プログラミング言語のメッセージ呼出しを表す情報に従って、クライアント・コンポーネントに代わって関数を実行するように動作可能であるデバイス。
  50. クライアント・コンポーネントが、さらに、コンピュータ・プログラミング言語のメソッド・コールを生成するように構成され、メッセージの前記生成が、コンピュータ・プログラミング言語のメソッド・コールの前記生成に応答して実行される請求項４９に記載のデバイス。
  51. デバイスが、さらに、デバイス内で実行可能な仮想マシンを含み、クライアント・コンポーネントおよびメッセージ・エンドポイントが仮想マシン内で実行可能である請求項４９に記載のデバイス。
  52. 仮想マシンが、Ｊａｖａ仮想マシン（ＪＶＭ）である請求項５１に記載のデバイス。
  53. サービスが、さらに、関数によって生成された結果データを、分散コンピューティング環境内のスペース・サービスに格納するように動作可能であり、クライアント・コンポーネントが、さらに、
    結果データに関するデータ表現言語の通知にアクセスすること、その際、通知が、結果データへのクライアント・コンポーネントによるアクセスを可能にする情報を含み、および
    格納された結果データに関する供給された通知内の情報に従って、スペース・サービスから結果データにアクセスすること
    を行うように構成される請求項４９に記載のデバイス。
  54. 前記コンピュータ・プログラミング言語が、Ｊａｖａプログラミング言語であり、メッセージ内のメソッド・コールを表す情報が、サービス側で実装されるＪａｖａメソッドへのＪａｖａメソッド・コールを表す請求項４９に記載のデバイス。
  55. 分散コンピューティング環境内のデバイスのクライアントによって発送され、コンピュータ・プログラミング言語のメソッド・コールを表す情報を含み、さらに、デバイスへのクライアント・アクセスを可能にする証明書を含むメッセージをデータ表現言語で受け取ること、および、
    メッセージに含まれる証明書を検査することによってメッセージを真正として検証すること
    を行うように構成されたメッセージ・エンドポイントと、
    メッセージがメッセージ・エンドポイントによって真正として検証される場合に、メッセージに含まれるコンピュータ・プログラミング言語のメソッド・コールを表す情報に従って、クライアントに代わって関数を実行すること、
    関数の前記実行によって生成された結果データを、分散コンピューティング環境内のスペース・サービスに格納すること、および、
    格納された結果データに関する通知をクライアントに供給し、通知が、格納された結果データへのクライアントによるアクセスを可能にする情報を含むこと
    を行うように構成されたサービス・コンポーネントとを含むデバイス。
  56. サービス・コンポーネントが、コンピュータ・プログラミング言語のメソッドを含み、
    メッセージ・エンドポイントが、さらに、
    メッセージに含まれるメソッド・コールの識別子に従って、コンピュータ・プログラミング言語のメソッド・コールを再生成し、
    再生成されたメソッド・コールを用いて、サービス・コンポーネントのコンピュータ・プログラミング言語のメソッドを呼び出すように構成され、
    関数の前記実行の際に、サービス・コンポーネントが、さらに、前記呼び出しに応答して、再生成されたメソッド・コールに従ってコンピュータ・プログラミング言語のメソッドを実行するように構成される請求項５５に記載のデバイス。
  57. コンピュータ・プログラミング言語のメソッドの前記呼出しにおいて、メッセージ・エンドポイントが、さらに、メソッド・コールのパラメータ値として、メッセージに含まれる１つまたは複数のパラメータ値を供給するように構成される請求項５６に記載のデバイス。
  58. 前記コンピュータ・プログラミング言語が、Ｊａｖａプログラミング言語である請求項５５に記載のデバイス。
  59. クライアントが、コンピュータ・プログラミング言語のメソッド・コールを含むメッセージをデータ表現言語で生成することであって、メッセージが、さらに、分散コンピューティング環境でクライアントに代わって関数を実行するように構成されたサービスにクライアントがアクセスできるようにする証明書を含み、
    クライアントが、サービスにメッセージを送ること、
    サービスが、メッセージに含まれる証明書を検査すること
    前記検査によって証明書が真正であると判定される場合に、サービスが、メッセージに含まれるコンピュータ・プログラミング言語のメソッド・コールを表す情報に従って、クライアントに代わって関数を実行すること、および、
    前記検査によって証明書が真正でないと判定される場合に、サービスが、クライアントに代わって関数を実行しないこと
    を実施するためにコンピュータ実行可能であるプログラム命令を含む担体媒体。
  60. プログラム命令が、さらに
    クライアントがサービスに送ることを許可されるデータ表現言語のメッセージの記述を含むデータ表現言語のメッセージ・スキーマを含むサービス通知をクライアントに提供するサービスを実施するためにコンピュータ実行可能であり、
    メッセージの前記生成が、メッセージ・スキーマに含まれるメッセージの記述に従って実行される請求項５９に記載の担体媒体。
  61. プログラム命令が、さらに、
    メッセージ・スキーマに記述されたデータ表現言語のメッセージを生成することによってサービスへのインターフェースをクライアントに提供するように構成されるクライアント・メソッド・ゲートを、サービス通知に従って生成するクライアントを実施するためにコンピュータ実行可能であり、
    メッセージの前記生成が、クライアント・メソッド・ゲートによって実行される請求項６０に記載の担体媒体。
  62. プログラム命令が、さらに、
    サービス通知に含まれるサービスのアドレスにデータ表現言語のメッセージを送るように構成されるクライアント・メッセージ・エンドポイントを、クライアントがサービス通知に従って生成すること、
    クライアント・メッセージ・エンドポイントが、生成されたメッセージをクライアント・メソッド・ゲートから受け取ること、
    クライアント・メッセージ・エンドポイントが、メッセージに証明書を付加することを実施するためにコンピュータ実行可能であり、
    サービスへのメッセージの前記発送が、クライアント・メッセージ・エンドポイントによって実行される請求項６１に記載の担体媒体。
  63. サービスが、サービス内で実行可能な１つまたは複数のコンピュータ・プログラミング言語のメソッドを含み、コンピュータ・プログラミング言語のメソッド・コールを表す情報が、メソッド・コールの識別子を含み、関数の前記実行において、プログラム命令が、さらに、
    メソッド・コールを表す情報に含まれるメソッド・コールの識別子に従ってメソッド・コールを再生成すること、および、
    再生成されたメソッド・コールに従って、サービスのコンピュータ・プログラミング言語のメソッドを実行すること
    を実施するためにコンピュータ実行可能である請求項５９に記載の担体媒体。
  64. コンピュータ・プログラミング言語のメソッド・コールを表す情報が、さらに、メソッド・コールの１つまたは複数のパラメータ値を含み、再生成されたメソッド・コールに従うコンピュータ・プログラミング言語のメソッドの前記実行において、プログラム命令が、さらに、メソッド・コールのパラメータ値として、メソッド・コールを表す情報からの１つまたは複数のパラメータ値を供給することを実施するためにコンピュータ実行可能である請求項６３に記載の担体媒体。
  65. サービスが、さらに、データ表現言語のメッセージを受け取り、メッセージによって指定されるコンピュータ・プログラミング言語のメソッドを呼び出すことによって、サービスの１つまたは複数のコンピュータ・プログラミング言語のメソッドへのインターフェースを提供するように構成されたサービス・メソッド・ゲートを含み、メソッド・コールの前記再生成が、サービス・メソッド・ゲートによって実行される請求項６３に記載の担体媒体。
  66. 関数の前記実行が、結果データを生成し、プログラム命令が、さらに、
    生成された結果データを、分散コンピューティング環境内のスペース・サービスに格納すること、
    格納された結果データに関する通知をクライアントに供給し、通知が、クライアントによる格納された結果データへのアクセスを可能にする情報を含むこと、　クライアントが、供給された通知内の情報に従ってスペース・サービスから格納された結果データにアクセスすること
    を実施するためにコンピュータ実行可能である請求項５９に記載の担体媒体。
  67. 前記データ表現言語が、拡張マークアップ言語（ＸＭＬ）である請求項５９に記載の担体媒体。
  68. 前記コンピュータ・プログラミング言語が、Ｊａｖａプログラミング言語であり、メッセージ内でメソッド・コールを表す情報が、サービス側で実装されるＪａｖａメソッドへのＪａｖａメソッド・コールを表し関数の前記実行において、プログラム命令が、さらに、メッセージに含まれるＪａｖａメソッド・コールを表す情報に従ってサービス側のＪａｖａメソッドを呼び出すこと実施するためにコンピュータ実行可能である請求項５９に記載の担体媒体。
JP2001583282A 2000-05-09 2001-05-09 分散コンピューティング環境でのセキュア・メッセージングを用いるリモート・メソッド・コール Pending JP2004504657A (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US20297500P 2000-05-09 2000-05-09
US20801100P 2000-05-26 2000-05-26
US20914000P 2000-06-02 2000-06-02
US20943000P 2000-06-02 2000-06-02
US20952500P 2000-06-05 2000-06-05
US09/672,145 US7243356B1 (en) 2000-05-09 2000-09-27 Remote method invocation with secure messaging in a distributed computing environment
PCT/US2001/015277 WO2001086395A2 (en) 2000-05-09 2001-05-09 Remote method invocation with secure messaging in a distributed computing environment

Publications (1)

Publication Number Publication Date
JP2004504657A true JP2004504657A (ja) 2004-02-12

Family

ID=27558952

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001583282A Pending JP2004504657A (ja) 2000-05-09 2001-05-09 分散コンピューティング環境でのセキュア・メッセージングを用いるリモート・メソッド・コール

Country Status (5)

Country Link
US (1) US7243356B1 (ja)
EP (1) EP1285323A2 (ja)
JP (1) JP2004504657A (ja)
AU (1) AU2001263065A1 (ja)
WO (1) WO2001086395A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008165340A (ja) * 2006-12-27 2008-07-17 Fujitsu Ltd 遠隔手続呼出方式
KR101168544B1 (ko) * 2009-06-26 2012-07-27 인텔 코포레이션 원격 아토믹 실행의 적응적 처리 방법, 장치 및 시스템

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7117239B1 (en) * 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US6842460B1 (en) * 2001-06-27 2005-01-11 Nokia Corporation Ad hoc network discovery menu
US20030051029A1 (en) * 2001-09-07 2003-03-13 Reedy Dennis G. Dynamic provisioning of sevice components in a distributed system
US20050091376A1 (en) * 2001-10-12 2005-04-28 Helfman Nadav B. Apparatus and method for optimized and secured reflection of network services to remote locations
US7305469B2 (en) 2001-12-18 2007-12-04 Ebay Inc. Prioritization of third party access to an online commerce site
US8042189B2 (en) 2002-03-20 2011-10-18 Research In Motion Limited System and method to force a mobile device into a secure state
JP2005521133A (ja) 2002-03-20 2005-07-14 リサーチ イン モーション リミテッド 移動装置における機密保護ガーベージコレクション・システムおよび方法
AU2003250498A1 (en) * 2002-08-23 2004-03-11 International Business Machines Corporation Processing application data
US7774831B2 (en) * 2002-12-24 2010-08-10 International Business Machines Corporation Methods and apparatus for processing markup language messages in a network
JP4165747B2 (ja) * 2003-03-20 2008-10-15 株式会社日立製作所 記憶システム、制御装置及び制御装置のプログラム
JP2005102133A (ja) * 2003-04-28 2005-04-14 Ricoh Co Ltd 画像形成装置及び宛先情報参照方法
US20050071419A1 (en) * 2003-09-26 2005-03-31 Lewontin Stephen Paul System, apparatus, and method for providing Web services using wireless push
KR100560424B1 (ko) * 2003-11-05 2006-03-13 한국전자통신연구원 접근이 제한되는 고비도 검증키를 갖는 변형된 디지털서명을 이용한 안전한 프로그래머블 패킷 전송 방법
FR2864871A1 (fr) * 2004-01-06 2005-07-08 Thomson Licensing Sa Methode de decouverte d'un reseau domestique et appareil implementant la methode
US20060167981A1 (en) * 2005-01-04 2006-07-27 Microsoft Corporation Web application architecture
US20060149746A1 (en) * 2005-01-04 2006-07-06 Microsoft Corporation Web application communication protocol
US20060239190A1 (en) * 2005-04-25 2006-10-26 Matsushita Electric Industrial Co., Ltd. Policy-based device/service discovery and dissemination of device profile and capability information for P2P networking
US7788243B2 (en) * 2006-09-08 2010-08-31 Sybase, Inc. System and methods for optimizing data transfer among various resources in a distributed environment
US7831772B2 (en) * 2006-12-12 2010-11-09 Sybase, Inc. System and methodology providing multiple heterogeneous buffer caches
US8065688B2 (en) 2007-01-23 2011-11-22 Microsoft Corporation Transparently capturing the causal relationships between requests across distributed applications
US8266630B2 (en) * 2007-09-03 2012-09-11 International Business Machines Corporation High-performance XML processing in a common event infrastructure
US8359582B2 (en) * 2007-12-31 2013-01-22 Hewlett-Packard Development Company, L.P. Compiling and inserting code snippets at runtime
US8560713B2 (en) * 2008-07-31 2013-10-15 Sap Ag Method and system for mediating enterprise service access for smart devices
JP5682996B2 (ja) * 2010-02-04 2015-03-11 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ クライアントプログラム、端末、サーバ装置、サーバプログラム、システムおよび方法
US8782434B1 (en) 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
JP5936103B2 (ja) 2011-10-04 2016-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ クライアントでＪａｖａメソッドを呼び出すシステム、コンピュータ、方法及びプログラム
US9063721B2 (en) 2012-09-14 2015-06-23 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
US9215075B1 (en) 2013-03-15 2015-12-15 Poltorak Technologies Llc System and method for secure relayed communications from an implantable medical device
US9483997B2 (en) 2014-03-10 2016-11-01 Sony Corporation Proximity detection of candidate companion display device in same room as primary display using infrared signaling
JP6078688B2 (ja) * 2014-04-22 2017-02-08 株式会社日立製作所 データ処理システム、データ処理方法
US9696414B2 (en) 2014-05-15 2017-07-04 Sony Corporation Proximity detection of candidate companion display device in same room as primary display using sonic signaling
US10070291B2 (en) 2014-05-19 2018-09-04 Sony Corporation Proximity detection of candidate companion display device in same room as primary display using low energy bluetooth
WO2017218154A1 (en) * 2016-06-17 2017-12-21 MobileIron, Inc. Leveraging and extending mobile operating system mdm protocol
US10089235B1 (en) 2017-07-28 2018-10-02 Citrix Systems, Inc. Dynamic trim processing with disk caching
CN113612679B (zh) * 2021-07-29 2023-02-24 百度在线网络技术（北京）有限公司 一种消息验证方法、装置、电子设备及存储介质
US11809839B2 (en) 2022-01-18 2023-11-07 Robert Lyden Computer language and code for application development and electronic and optical communication
US12368610B2 (en) 2022-02-25 2025-07-22 Insight Direct Usa, Inc. Scalable cross-boundary edge framework
US12265809B2 (en) * 2022-09-27 2025-04-01 Insight Direct Usa, Inc. Scalable cross-boundary edge framework
US12026486B2 (en) 2022-09-27 2024-07-02 Insight Direct Usa, Inc. Scalable cross-boundary edge framework

Family Cites Families (161)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4491946A (en) 1981-03-09 1985-01-01 Gould Inc. Multi-station token pass communication system
AU556499B2 (en) 1981-05-22 1986-11-06 Data General Corporation Data processing system
JPH0640302B2 (ja) 1984-01-30 1994-05-25 株式会社日立製作所 図式・ソ−スプログラム自動生成方法
US4823122A (en) 1984-06-01 1989-04-18 Digital Equipment Corporation Local area network for digital data processing system
US4809160A (en) 1985-10-28 1989-02-28 Hewlett-Packard Company Privilege level checking instruction for implementing a secure hierarchical computer system
US4713806A (en) 1986-03-14 1987-12-15 American Telephone And Telegraph Company, At&T Bell Laboratories Communication system control arrangement
US4939638A (en) 1988-02-23 1990-07-03 Stellar Computer Inc. Time sliced vector processing
US5287511A (en) 1988-07-11 1994-02-15 Star Semiconductor Corporation Architectures and methods for dividing processing tasks into tasks for a programmable real time signal processor and tasks for a decision making microprocessor interfacing therewith
US4979105A (en) 1988-07-19 1990-12-18 International Business Machines Method and apparatus for automatic recovery from excessive spin loops in an N-way multiprocessing system
US5133075A (en) 1988-12-19 1992-07-21 Hewlett-Packard Company Method of monitoring changes in attribute values of object in an object-oriented database
US5109486A (en) 1989-01-06 1992-04-28 Motorola, Inc. Distributed computer system with network and resource status monitoring
US5088036A (en) 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
ATE151183T1 (de) 1989-02-24 1997-04-15 Digital Equipment Corp Makler für die auswahl von rechnernetzwerkservern
US5560008A (en) 1989-05-15 1996-09-24 International Business Machines Corporation Remote authentication and authorization in a distributed data processing system
US5297283A (en) 1989-06-29 1994-03-22 Digital Equipment Corporation Object transferring system and method in an object based computer operating system
US5187787B1 (en) 1989-07-27 1996-05-07 Teknekron Software Systems Inc Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5257369A (en) 1990-10-22 1993-10-26 Skeen Marion D Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5557798A (en) 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5218699A (en) 1989-08-24 1993-06-08 International Business Machines Corporation Remote procedure calls in heterogeneous systems
WO1991010191A1 (en) 1989-12-26 1991-07-11 Fujitsu Limited Object oriented distributed processing system
GB2242293A (en) 1990-01-05 1991-09-25 Apple Computer Apparatus and method for dynamic linking of computer software components
AU628753B2 (en) 1990-08-14 1992-09-17 Digital Equipment Corporation Method and apparatus for implementing server functions in a distributed heterogeneous environment
AU639802B2 (en) 1990-08-14 1993-08-05 Oracle International Corporation Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment
US5446897A (en) 1990-08-31 1995-08-29 International Business Machines Corporation Automated address discovery method and apparatus for local area networks
AU659101B2 (en) 1990-09-17 1995-05-11 Aprisma Management Technologies, Inc. Network management system using model-based intelligence
JPH06502033A (ja) 1990-10-19 1994-03-03 クレイ・リサーチ・インコーポレイテッド スカラブル　パラレル　ベクトル　コンピュータシステム
WO1992009948A1 (en) 1990-11-30 1992-06-11 Vpl Research, Inc. Improved method and apparatus for creating virtual worlds
JPH0799497B2 (ja) 1990-12-14 1995-10-25 インターナショナル・ビジネス・マシーンズ・コーポレイション ソフトウェアの使用を管理するための装置及び方法
EP0497022B1 (en) 1991-01-31 1999-04-07 Hewlett-Packard Company Conference system
IE910553A1 (en) 1991-02-19 1992-08-26 Tolsys Ltd Improvements in and relating to stable memory circuits
DE69228621T2 (de) 1991-02-25 1999-07-22 Hewlett-Packard Co., Palo Alto, Calif. Objektorientiertes verteiltes Rechnersystem
EP0501613A3 (en) 1991-02-28 1993-09-01 Hewlett-Packard Company Heterogeneous software configuration management apparatus
US5293614A (en) 1991-04-08 1994-03-08 Texas Instruments Incorporated System and method for hard real-time garbage collection requiring a write barrier but no read barrier
US5481721A (en) 1991-07-17 1996-01-02 Next Computer, Inc. Method for providing automatic and dynamic translation of object oriented programming language-based message passing into operation system message passing using proxy objects
DE4131380A1 (de) 1991-09-20 1993-03-25 Siemens Ag Verfahren zur adaption einer objektorientierten applikation
US5319751A (en) 1991-12-27 1994-06-07 Intel Corporation Device driver configuration in a computer system
US5826017A (en) 1992-02-10 1998-10-20 Lucent Technologies Apparatus and method for communicating data between elements of a distributed system using a general protocol
US5390328A (en) 1992-03-30 1995-02-14 International Business Machines Corporation Data processing system and method for providing notification in a central processor of state changes for shared data structure on external storage
US5553305A (en) 1992-04-14 1996-09-03 International Business Machines Corporation System for synchronizing execution by a processing element of threads within a process using a state indicator
US5353343A (en) 1992-04-30 1994-10-04 Rockwell International Corporation Telephonic switching system with a user controlled data memory access system and method
US5412717A (en) 1992-05-15 1995-05-02 Fischer; Addison M. Computer system security method and apparatus having program authorization information data structures
DE69220093T2 (de) 1992-06-18 1997-12-04 Ibm Verarbeitungsnetzwerk für verteilte anwendungsprogramme.
EP0930566A3 (en) 1992-07-06 2006-07-05 Microsoft Corporation Method and system for composing objects
FI91456C (fi) 1992-07-29 1994-06-27 Nokia Telecommunications Oy Menetelmä tietokoneessa varattujen resurssien hallitsemiseksi
US5307490A (en) 1992-08-28 1994-04-26 Tandem Computers, Inc. Method and system for implementing remote procedure calls in a distributed computer system
JP2524472B2 (ja) 1992-09-21 1996-08-14 インターナショナル・ビジネス・マシーンズ・コーポレイション 電話回線利用の音声認識システムを訓練する方法
US5423042A (en) 1992-10-23 1995-06-06 International Business Machines Corporation Remote procedure execution
US5561785A (en) 1992-10-29 1996-10-01 International Business Machines Corporation System for allocating and returning storage and collecting garbage using subpool of available blocks
JPH09502547A (ja) 1992-11-13 1997-03-11 マイクロソフト コーポレイション 遠隔手続き呼び出しのためのインターフェイスポインタをマーシャリングする方法及びシステム
US5515536A (en) 1992-11-13 1996-05-07 Microsoft Corporation Method and system for invoking methods of an object through a dispatching interface
US5386568A (en) 1992-12-01 1995-01-31 Yamaha Corporation Apparatus and method for linking software modules
EP0602263A1 (en) 1992-12-15 1994-06-22 International Business Machines Corporation User interface program generator
US5560003A (en) 1992-12-21 1996-09-24 Iowa State University Research Foundation, Inc. System and hardware module for incremental real time garbage collection and memory management
US5452459A (en) 1993-01-08 1995-09-19 Digital Equipment Corporation Method and apparatus for allocating server access in a distributed computing environment
EP0613083B1 (en) 1993-02-25 2002-01-23 Sun Microsystems, Inc. Transaction management in object oriented systems
US5832593A (en) 1993-04-14 1998-11-10 Minnesota Mining And Manufacturing Company Splice head for insulated telecommunication wires
CA2121612A1 (en) 1993-05-21 1994-11-22 Chung-Hwa Herman Rao Methods and apparatus for making and using distributed applications
US5603031A (en) 1993-07-08 1997-02-11 General Magic, Inc. System and method for distributed computation based upon the movement, execution, and interaction of processes in a network
US5844553A (en) 1993-08-30 1998-12-01 Hewlett-Packard Company Mechanism to control and use window events among applications in concurrent computing
US5617537A (en) 1993-10-05 1997-04-01 Nippon Telegraph And Telephone Corporation Message passing system for distributed shared memory multiprocessor system and message passing method using the same
CA2118169A1 (en) 1993-10-27 1995-04-28 Michael R.C. Seaman Event architecture for system management in an operating system
US5455952A (en) 1993-11-03 1995-10-03 Cardinal Vision, Inc. Method of computing based on networks of dependent objects
US5742848A (en) 1993-11-16 1998-04-21 Microsoft Corp. System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions
US5581704A (en) 1993-12-06 1996-12-03 Panasonic Technologies, Inc. System for maintaining data coherency in cache memory by periodically broadcasting invalidation reports from server to client
US5485617A (en) 1993-12-13 1996-01-16 Microsoft Corporation Method and system for dynamically generating object connections
AU6702594A (en) 1993-12-17 1995-07-03 Taligent, Inc. Object-oriented distributed communications directory service
US5594921A (en) 1993-12-17 1997-01-14 Object Technology Licensing Corp. Authentication of users with dynamically configurable protocol stack
AU1522095A (en) 1994-01-05 1995-08-01 Peter J. Covey Dynamic-state, multi-dimensional, multi-media database
US5832219A (en) 1994-02-08 1998-11-03 Object Technology Licensing Corp. Distributed object networking service
US5675796A (en) 1994-04-08 1997-10-07 Microsoft Corporation Concurrency management component for use by a computer program during the transfer of a message
US5680617A (en) 1994-05-16 1997-10-21 Apple Computer, Inc. Computer-human interface which provides for user customization of object behavior
EP0684553B1 (en) 1994-05-26 2004-06-16 Sun Microsystems, Inc. Method and apparatus for generating and using short operation identifiers in object oriented systems
US5655148A (en) 1994-05-27 1997-08-05 Microsoft Corporation Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
US5680573A (en) 1994-07-12 1997-10-21 Sybase, Inc. Method of buffering data objects in a database
GB9414951D0 (en) 1994-07-25 1994-09-14 British Telecomm Computer system having client-server architecture
US5778228A (en) * 1994-08-16 1998-07-07 International Business Machines Corporation Method and system for transferring remote procedure calls and responses over a network
US5922054A (en) 1994-08-19 1999-07-13 Canon Kabushiki Kaisha System for managing external applications and files
US5555367A (en) 1994-09-30 1996-09-10 General Electric Company Method and system for generating computer programs for queries formed by manipulating object-oriented diagrams
WO1996010787A1 (en) 1994-10-04 1996-04-11 Banctec, Inc. An object-oriented computer environment and related method
JP4058118B2 (ja) 1994-11-15 2008-03-05 株式会社日立製作所 プログラム生成システム及び方法
US5577231A (en) 1994-12-06 1996-11-19 International Business Machines Corporation Storage access authorization controls in a computer system using dynamic translation of large addresses
US5644768A (en) 1994-12-09 1997-07-01 Borland International, Inc. Systems and methods for sharing resources in a multi-user environment
US5553282A (en) 1994-12-09 1996-09-03 Taligent, Inc. Software project history database and method of operation
US6108715A (en) * 1994-12-13 2000-08-22 Microsoft Corporation Method and system for invoking remote procedure calls
JP2000503785A (ja) 1994-12-13 2000-03-28 ノベル，インコーポレイテッド ネットワークディレクトリを更新または変更するための方法ならびにその装置
DE69521977T2 (de) 1994-12-13 2002-04-04 International Business Machines Corp., Armonk Verfahren und System zur gesicherten Programmenverteilung
US5630066A (en) 1994-12-20 1997-05-13 Sun Microsystems, Inc. System and method for locating object view and platform independent object
US5687370A (en) 1995-01-31 1997-11-11 Next Software, Inc. Transparent local and distributed memory management system
US5872928A (en) 1995-02-24 1999-02-16 Cabletron Systems, Inc. Method and apparatus for defining and enforcing policies for configuration management in communications networks
US5727203A (en) 1995-03-31 1998-03-10 Sun Microsystems, Inc. Methods and apparatus for managing a database in a distributed object operating environment using persistent and transient cache
EP0735472A3 (en) 1995-03-31 2000-01-19 Sun Microsystems, Inc. Method and apparatus for conspiracy among objects
US6249822B1 (en) * 1995-04-24 2001-06-19 Microsoft Corporation Remote procedure call method
US5628005A (en) 1995-06-07 1997-05-06 Microsoft Corporation System and method for providing opportunistic file access in a network environment
US5761656A (en) 1995-06-26 1998-06-02 Netdynamics, Inc. Interaction between databases and graphical user interfaces
US5802367A (en) 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
US5745703A (en) 1995-07-18 1998-04-28 Nec Research Institute, Inc. Transmission of higher-order objects across a network of heterogeneous machines
US5774551A (en) 1995-08-07 1998-06-30 Sun Microsystems, Inc. Pluggable account management interface with unified login and logout and multiple user authentication services
JPH0962526A (ja) 1995-08-28 1997-03-07 Fujitsu Ltd 耐故障型ｒｐｃシステムおよび方法
JP2964926B2 (ja) 1995-08-29 1999-10-18 富士ゼロックス株式会社 データベース管理装置及び方法
US5671225A (en) 1995-09-01 1997-09-23 Digital Equipment Corporation Distributed interactive multimedia service system
US5737607A (en) 1995-09-28 1998-04-07 Sun Microsystems, Inc. Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats
US5765174A (en) 1995-10-06 1998-06-09 Sun Microsystems, Inc. System amd method for distributed object resource management
US5864862A (en) 1996-09-30 1999-01-26 Telefonaktiebolaget Lm Ericsson (Publ) System and method for creating reusable components in an object-oriented programming environment
US5872973A (en) 1995-10-26 1999-02-16 Viewsoft, Inc. Method for managing dynamic relations between objects in dynamic object-oriented languages
US5996075A (en) * 1995-11-02 1999-11-30 Sun Microsystems, Inc. Method and apparatus for reliable disk fencing in a multicomputer system
US5860153A (en) 1995-11-22 1999-01-12 Sun Microsystems, Inc. Memory efficient directory coherency maintenance
US5692047A (en) 1995-12-08 1997-11-25 Sun Microsystems, Inc. System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources
US6003763A (en) 1995-12-29 1999-12-21 Visa International Service Method and apparatus for recording magnetic information on traveler's checks
US5745695A (en) 1996-01-16 1998-04-28 Motorola Inc. Radio system with suspension of packet data service during non-data service connection
US5754849A (en) 1996-01-30 1998-05-19 Wayfarer Communications, Inc. Self-describing object providing dynamic manipulation of heterogeneous data values and semantic identity between memory and transmission representations
US5946485A (en) 1996-02-09 1999-08-31 Intervoice Limited Partnership Enhanced graphical development environment for controlling program flow
CA2199108C (en) 1996-03-05 2002-04-23 Hirotoshi Maegawa Parallel distributed processing system and method of same
US5845129A (en) 1996-03-22 1998-12-01 Philips Electronics North America Corporation Protection domains in a single address space
US5706502A (en) 1996-03-25 1998-01-06 Sun Microsystems, Inc. Internet-enabled portfolio manager system and method
US5790548A (en) 1996-04-18 1998-08-04 Bell Atlantic Network Services, Inc. Universal access multimedia data network
US6938263B2 (en) 1996-04-23 2005-08-30 Sun Microsystems, Inc. System and method for facilitating dynamic loading of “stub” information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space
US5815709A (en) 1996-04-23 1998-09-29 San Microsystems, Inc. System and method for generating identifiers for uniquely identifying object types for objects used in processing of object-oriented programs and the like
EP0805393B1 (en) 1996-04-30 2011-11-09 International Business Machines Corporation Method and apparatus for managing membership of a group of processors in a distributed computing environment
US5778368A (en) 1996-05-03 1998-07-07 Telogy Networks, Inc. Real-time embedded software respository with attribute searching apparatus and method
US5778187A (en) 1996-05-09 1998-07-07 Netcast Communications Corp. Multicasting method and apparatus
US5835737A (en) 1996-05-10 1998-11-10 Apple Computer, Inc. Method and apparatus for arbitrating access to selected computer system devices
US5928323A (en) 1996-05-30 1999-07-27 Sun Microsystems, Inc. Apparatus and method for dynamically generating information with server-side software objects
US5813013A (en) 1996-06-06 1998-09-22 Microsoft Corporation Representing recurring events
JP3488019B2 (ja) 1996-06-17 2004-01-19 株式会社山武 制御設計用コンフィギュレーション・ツールの部品再利用方法
US5768532A (en) 1996-06-17 1998-06-16 International Business Machines Corporation Method and distributed database file system for implementing self-describing distributed file objects
US6044409A (en) 1996-06-26 2000-03-28 Sun Microsystems, Inc. Framework for marshaling and unmarshaling argument object references
US5991823A (en) 1996-06-26 1999-11-23 Sun Microsystems, Inc. Low overhead object adaptor
US5727145A (en) 1996-06-26 1998-03-10 Sun Microsystems, Inc. Mechanism for locating objects in a secure fashion
US5809507A (en) 1996-07-01 1998-09-15 Sun Microsystems, Inc. Method and apparatus for storing persistent objects on a distributed object network using a marshaling framework
US6360256B1 (en) 1996-07-01 2002-03-19 Sun Microsystems, Inc. Name service for a redundant array of internet servers
US5748897A (en) 1996-07-02 1998-05-05 Sun Microsystems, Inc. Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer
US5818448A (en) 1996-07-02 1998-10-06 Sun Microsystems, Inc. Apparatus and method for identifying server computer aggregation topologies
US5860004A (en) 1996-07-03 1999-01-12 Sun Microsystems, Inc. Code generator for applications in distributed object systems
US6347342B1 (en) 1996-07-15 2002-02-12 Next Software, Inc. Method and apparatus for dynamically brokering object messages among object models
US5757925A (en) 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
WO1998004971A1 (en) 1996-07-25 1998-02-05 Tradewave Corporation Method and system for generalized protocol implementation on client/server communications connections
US5875335A (en) 1996-09-30 1999-02-23 Apple Computer, Inc. Parameter marshaling techniques for dynamic object-oriented programming languages
US5787425A (en) 1996-10-01 1998-07-28 International Business Machines Corporation Object-oriented data mining framework mechanism
US5832529A (en) 1996-10-11 1998-11-03 Sun Microsystems, Inc. Methods, apparatus, and product for distributed garbage collection
US5944793A (en) 1996-11-21 1999-08-31 International Business Machines Corporation Computerized resource name resolution mechanism
US5987506A (en) 1996-11-22 1999-11-16 Mangosoft Corporation Remote access and geographically distributed computers in a globally addressable storage environment
US5892904A (en) 1996-12-06 1999-04-06 Microsoft Corporation Code certification for network transmission
US5884024A (en) 1996-12-09 1999-03-16 Sun Microsystems, Inc. Secure DHCP server
US5787431A (en) 1996-12-16 1998-07-28 Borland International, Inc. Database development system with methods for java-string reference lookups of column names
US5815149A (en) 1997-02-19 1998-09-29 Unisys Corp. Method for generating code for modifying existing event routines for controls on a form
US5935249A (en) 1997-02-26 1999-08-10 Sun Microsystems, Inc. Mechanism for embedding network based control systems in a local network interface device
US6061713A (en) 1997-03-12 2000-05-09 Fujitsu Limited Communications system for client-server data processing systems
US5864866A (en) 1997-03-26 1999-01-26 International Business Machines Corporation Apparatus and method for providing externalization in an object-oriented environment
US5890158A (en) 1997-03-31 1999-03-30 International Business Machines Corporation Method, apparatus, and program storage device for sharing objects with a network server and a database server using a common object model
US5808911A (en) 1997-06-19 1998-09-15 Sun Microsystems, Inc. System and method for remote object resource management
US5878411A (en) 1997-06-27 1999-03-02 International Business Machines Corporation Dependent object class and subclass mapping to relational data store
US5887134A (en) 1997-06-30 1999-03-23 Sun Microsystems System and method for preserving message order while employing both programmed I/O and DMA operations
US5946694A (en) 1997-09-29 1999-08-31 International Business Machines Corporation Apparatus and method for transparent application of service to business objects
US6061699A (en) 1997-11-03 2000-05-09 International Business Machines Corporation Method and computer program product for extracting translatable material from browser program function codes using variables for displaying MRI
US5999179A (en) 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6016496A (en) 1997-11-20 2000-01-18 International Business Machines Corporation Method and apparatus for an object-oriented object for retrieving information from local and remote databases
US6009103A (en) 1997-12-23 1999-12-28 Mediaone Group, Inc. Method and system for automatic allocation of resources in a network
US6026414A (en) 1998-03-05 2000-02-15 International Business Machines Corporation System including a proxy client to backup files in a distributed computing environment
US6131165A (en) 1998-06-18 2000-10-10 Sun Microsystems, Inc. Permit for controlling access to services in protected memory systems
US6138235A (en) 1998-06-29 2000-10-24 Sun Microsystems, Inc. Controlling access to services between modular applications
US6453362B1 (en) * 1998-08-12 2002-09-17 International Business Machines Corporation Systems, methods and computer program products for invoking server applications using tickets registered in client-side remote object registries

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008165340A (ja) * 2006-12-27 2008-07-17 Fujitsu Ltd 遠隔手続呼出方式
KR101168544B1 (ko) * 2009-06-26 2012-07-27 인텔 코포레이션 원격 아토믹 실행의 적응적 처리 방법, 장치 및 시스템
US8533436B2 (en) 2009-06-26 2013-09-10 Intel Corporation Adaptively handling remote atomic execution based upon contention prediction

Also Published As

Publication number Publication date
WO2001086395A2 (en) 2001-11-15
AU2001263065A1 (en) 2001-11-20
EP1285323A2 (en) 2003-02-26
WO2001086395A3 (en) 2002-12-19
US7243356B1 (en) 2007-07-10

Similar Documents

Publication Publication Date Title
US6789126B1 (en) Addressing message gates in a distributed computing environment
US6850979B1 (en) Message gates in a distributed computing environment
US7577834B1 (en) Message authentication using message gates in a distributed computing environment
US7016966B1 (en) Generating results gates in a distributed computing environment
US7200848B1 (en) Migrating processes using data representation language representations of the processes in a distributed computing environment
US8001232B1 (en) Event message endpoints in a distributed computing environment
US6950875B1 (en) Message conductors in a distributed computing environment
US7243356B1 (en) Remote method invocation with secure messaging in a distributed computing environment
EP1285334B1 (en) Mechanism and apparatus for accessing and addressing services in a distributed computing environment
US8082491B1 (en) Dynamic displays in a distributed computing environment
EP1281119B1 (en) Mechanism and apparatus for returning results of services in a distributed computing environment
US6898618B1 (en) Client-specified display services in a distributed computing environment
US7010573B1 (en) Message gates using a shared transport in a distributed computing environment
US7188251B1 (en) System and method for secure message-based leasing of resources in a distributed computing environment
US7065574B1 (en) Messaging system using pairs of message gates in a distributed computing environment
JP2004501428A (ja) サービスの近接発見の方法および装置
EP1380941A2 (en) Tranformation of objects between a computer programming language and data representation language
EP1314085B1 (en) Remote function invocation with messaging in a distributed computing environment
EP1290547B1 (en) Transformation of objects between a computer programming language and a data representation language
EP1384142B1 (en) Bridging between a data representation language message-based distributed computing environment and other environments
JP2003533767A (ja) コンピュータ・プログラミング言語とデータ表現言語との間のオブジェクトの変換