JPH07503568A - 協調作業ネットワークでの呼出し管理ワークステーション及び方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 協調作業ネットワークでの呼出し管理ワークステーション及び方法 ［技術分野］ 本発明は、協調作業ネットワークでの呼出し管理に関し、さらに具体的には、プ ログラマブル・ワークステーションと、そのような協調作業環境で使用する方法 に関する。

［背景技術］ パーソナル・コンピュータは現在、実業界全体に広く普及しており、その多くは 、固定接続、たとえばローカル・エリア・ネットワークを介して、あるいは動的 に確立されるリンク、たとえば公衆交換電話網のＩ　ＳＤＮや非同期回線を介し て相互に通信することができる。これらの接続されたパーソナル・コンピュータ を使用して、遠（離れた個人の間の協調作業を拡大できることが増加してきてい る。典型的な例は、デスク・トップ会議ソフトウェアを使用することである。協 調作業を成功させるには一般に、参加者の間に簡単なデータ・リンク以上のもの が必要である。通常、音声機能が必須であり、しばしば、ビデオ・リンクが必要 になる。したがって、リモート協調作業は従来の電話呼出しの拡張とみなせるこ とが多い。従来の電話呼出しが、パーソナル・コンピュータを介して机上で利用 可能なデータおよびプログラムによって拡張され、時にはビデオ・サービスによ って拡張されているものとみなされる。

ワークステーションのデータおよびアプリケーションを利用するユーティリティ 、たとえば画面ウィンドウおよびファイルの共用から、特有のクラスのリモート ・ユーザのニーズを満たすように設計された新しい協調アプリケーション、たと えばジャストインタイム・エジュヶーション、リモート・プレゼンテーション、 エグゼグティブ・ブロードキャスト、ヘルプ・デスクまで、広い範囲の協調アプ リケーションを構想することができる。これらの例の共通の要件を以下に示す。

Ｏハードウェアとソフトウェアを共に含む広範囲のパーソナル・コンピュータ・ プラットフォームのサポート○既存の通信ネットワークを介した運用○グループ 通信およびマルチメディア・データ・サービスデスクトップ会議システムの動作 、特にシステムが着信呼出しに応答する方法は通常、システム・ソフトウェアの 供給業者によって決定される。リアルタイム・デスクトップ会議の従来の考え方 では、呼出しのセットアツプおよびテアダウンなどのシステム機能とデータの送 受信などのアプリケーション機能が区別されている。したがって、アプリケーシ ョン（共用電子チョークボードなどの）は呼出しの開始および終了などの事象を 知ることができるが、これらの事象が具体的に処理される方法に影響を及ぼすこ とはできない。たとえば、着信呼出しの禁止は通常、ユーザによって、そしてお そらくＡＰＩ呼出しを介してアプリケーション・プログラムによって、オンとオ フを切り替えることができるシステム機能とみなされている。

［発明の開示］ したがって、本発明は、ノードの間でデータを送信するための物理リンクによっ て接続されたネットワークのノードを形成するワークステーションのネットワー クでの協調作業用のプログラマブル・ワークステーションを提供する。

このワークステーションは、オペレーティング・システムと、 ノードの間のマルチメディア・データの物理経路指定を制御するための、オペレ ーティング・システム上で動作するネットワーク制御プログラム層と、 ワークステーション上で作動し、協調呼出しマネージャ・プログラムからの所定 のアプリケーション・プログラム呼出しに応答して、ノードで協調呼出しマネー ジャ・プログラムを確立し、ノードにあるどのアプリケーション・プログラム・ インスタンスにも特有でない着信事象を処理する協調アプリケーション・プログ ラム・サブシステムとを備えている。

本発明はさらに、ノードの間のデータ送信用の物理リンクによって接続されたネ ットワークのノードを形成するプログラマブル・ワークステーションのネットワ ークにおいて、ワークステーション上で作動する協調呼出しマネージャ・プログ ラムからの所定のアプリケーション・プログラム呼出しに応答して、ノードで協 調呼出しマネージャ・プログラムを確立し、ノードにあるどのアプリケーション ・プログラム・インスタンスにも特有でない着信事象を処理することから成る協 調作業方法を提供する。

ここで、本発明の１例として、添付図面の第１図ないし第１６図を参照して説明 する。

［発明の釘ましい実施例］ 第１図には、ＬＡＮ’ＰＷＡＮなどのネットワークでリンク１１によって接続さ れた２台のプログラマブル・ワークステーション１０および１２が示されている 。ワークステーションの主要な構成要素は従来、ハードウェア１３から始まる層 として説明されている。詳細に図示していないハードウェアは、メイン・メモリ をもつプロセッサ装置と、ディスク・ファイルなどの二次記憶域と、表示装置と 、キーボードやマウスなどの入出力装置から構成される装置サポート・ソフトウ ェア１４は、ハードウェア装置がＩＢＭのオペレーティング・システム／２　（ Ｏ８／２）などの周知のオペレーティング・システム１５内で機能できるように する。

従来のワークステーションをネットワークで使用する際、前記ワークステーショ ンの一部になるのは、ネットワーク１１との接続と、ネットワークを介したワー クステーションの間の通信をサポートするためのネットワーキング・ソフトウェ ア１６である。典型的なネットワーキング・ソフトウェア１６は、ＩＢＭのＮｅ ｔｂｉｏｓプログラム製品である。ここまでで説明したものは、アプリケーショ ン・プログラム１８を実行することができる従来のネットワーキング・ワークス テーションだけである。

本発明を実施するために、各ワークステーションは、分散協調作業環境を作成す るためのアプリケーション・プログラムの開発を容易にする協調アプリケーショ ン・サポート・システム・ソフトウェア１７も含む。この環境では、ワークステ ーションのエンドユーザは、マルチメディア・チャネルを介してネットワーク中 の他のワークステーションのユーザと通信し、かつ共用データおよびタスクに関 して協調作業を行うことができる。

サポート・システム１７の全体的な構造を、前記システム１７が直接インタフェ ースをとるワークステーションの他のソフトウェア構成要素と関連付けて第２図 に示す。サポート・システム１７の内部構造の詳細は、第１０図に示す。大まか に言って、システム１７の主機能構成要素は、点線で示した２つのインタフェー ス２ｏと２１の間にある。

アプリケーション・プログラミング・インタフェース２゜によって、アプリケー ション１８はサポート・サービスを要求することができる。装置ドライバ・イン タフェース２１によって、システムは、トークン・リング・ドライバ２５、工Ｓ ＤＮドライバ２６、Ｒ３２３２Ｆライム２フ、ソノ他ノ装置ドライバ２８などの 装置ドライバを介して広範囲なソフトウェアおよびハードウェア通信サブシステ ムをサポートすることができる。リンク・サポート・モジュール２２８．２２９ は装置ドライバとのインタフェースをとる。これらは、ワークステーションで利 用可能なハードウェア・オプションに応じて交換可能であり（第１０図は、可能 な選択だけを示す）、どのハードウェアが存在するのかをサポート・システムが 正確に知らなくて済むように働く。暗示的な資源インタフェース（図示せず）を 介して、サポート・システムでも、アプリケーションでも、装置ドライバでも、 資源ファイル２９に、ノード・アドレスやディレクトリ・データなどの通信ネッ トワークの詳細を要求することができる。

ＡＰＩ２０によって、アプリケーション１８は、多様で複雑な通信ネットワーク を介して、ノード上に配置された様々なハードウェアおよびソフトウェア・プラ ットフォーム上で、対等アプリケーションを開始し、資源を共用することができ る。ＡＰＩ２０によって、アプリケーションは、基礎物理ネットワークの構造と は独立に、広範囲のマルチメディア・トラフィックに適した、共用アプリケーシ ョン間の複数の専用論理データ・チャネルを定義することができる。

ＡＰＩ２０によって、アプリケーションは共用アプリケーション間のデータ・ス トリーミングを直列化し、同期化し、組み合わせ、またはコピーすることができ る。ＡＰＩ２０によって、アプリケーションは一連の接続された装置をサポート することができ、装置データのインターセプトおよびリダイレクトを可能にする 。

サポート・システムは、外部アプリケーションおよび装置とのインタフェースを とる拡張可能な１組の論理装置３０などのアプリケーション開発を助けるための 他の構成要素を含む。ＡＰＩに書き込まれた、アプリケーションからコマンド・ インタフェースを介して呼び出すこともできる１組のエンドユーザ・インタフェ ース（図示せず）も、設けられている。

ネットワーク、ノード、およびアプリケーション最高レベルでは、ＡＰＩによっ て提供されるプログラミング・モデルは通信ノード・セットから構成される。ノ ードとは、ユーザを表すアドレス可能なエンティティであり、サポート・システ ム・ソフトウェアのインスタンスと、アプリケーション・プログラム、データな どの１組の資源を備えている。通常、ノードは、その対等サブシステムと通信で きる専用プログラムマブル・ワークステーション１０である。マルチユーザ・シ ステムでは、ノードは各ユーザに関連づけられる。

ノードは、サポート・ノードまたは非サポート・ノードである。サポート・ノー ドは、サポート・システム・ソフトウェア１７が実行されるものである。相互通 信サポート・ノードの集合をサポート・ネットワークと呼ぶ。

ノードは名前で識別される。理想的には、ノード名はすべて特有のものであるべ きだが、関連するノードが相互通信する必要がないかぎり重複が許容される。ノ ード命名方式の選択は、本発明に直接関連していない。ただし、インタネット・ プロトコルによって定義されたような階層システムは多数の利点を有する。ノー ドがネットワークに動的に参加し、あるいはネットワークを動的に抜けられるこ とが、アーキテクチャの基本である。

ノードは、論理装置３０を含むことができる。論理装置とは、アプリケーション がアーキテクチャ中の他のエンティティと矛盾せずにソフトウェアまたは装置を 操作または管理できるようにするサポート・システムのソフトウェア拡張機能で ある。プレゼンテーション・ウィンドウ、プリンタ、ディスク・ドライバ、モデ ム、およびアプリケーション・プログラムを含む広範囲の論理装置がある。

ノードでは、オペレーティング・システムおよびウィンドウ・システムによって ノードに課される制限に従って、複数のアプリケーションを実行することができ る。アプリケーションは、ａｗａｒｅまたはｕｎａｗａｒｅであり、ａｗａｒｅ アプリケーションはＡＰＩのサービスを使用し、ｕｎａｗａｒｅアプリケーショ ンは使用しない。ａｗａｒｅアプリケーションとｕｎａｗａｒｅアプリケーショ ンは共に、一般に、ノードで同時に実行する。

あるノードでサポート・システムが完全に活動状態のとき、そのノードでは１つ の特定のａｗａｒｅアプリケーションが動作しなければならない。このアプリケ ーションは、そのノードで特有の役割を果たし、呼出しマネージャ３２といわれ る・特定のノードでは、多数の呼出しマネージャを実行することができるが、１ 度に１つしか実行できない。呼出しマネージャの特別な機能は、サポート・シス テムが生成するある種の事象に応答することである。たとえば、呼出しマネージ ャはアプリケーションのインスタンスに特定的に向けられていない要求を解決し 、かつ任意選択でノードの資源管理を処理することもできる。呼出しマネージャ の責任は、１つの呼出しマネージャから他の呼出しマネージャに移すことができ る。適宜、役割をユーザ・アプリケーション機能と組み合わせることもできる。

サポート・システム１７は、あるノードの資源を他の２つのノードの間の通信に 利用するよう要求することができる。

これを受動命令と呼び、許可は受動ノードにある呼出しマネージャによって制御 される。−例として、ＬＡＮ上の２っのノードＡおよびＢがあり、第３のノード Ｃが非同期通信リンクによってＢに接続されているものとする。ＡとＣにあるア プリケーションが通信を望む場合、トラフィックをＢを介して経路指定する必要 がある。Ｂのノードをこのように使用するには、Ｂにある呼出しマネージャの同 意が必要である。

ａｗａｒｅアプリケーションは、データおよび資源を、同じノードまたは異なる ノードにある他のａｗａｒｅアプリケーションと共用することができる。共用を 行うアプリケーションの集合を共用セットと呼ぶ。ａｗａｒｅアプリケーション は、共用要求を開始し、アプリケーション共用セット、ターゲット・アプリケー ション、および宛先ノードを指定する。この要求はまず、サポート・ソフトウェ アによって、送信側ノードにある呼出しマネージャに渡される。該呼出しマネー ジャは通常、宛先ノードにある呼出しマネージャに要求を転送する。通常、この 第２の呼出しマネージャは、要求されたアプリケーションをローンチし、発信元 アプリケーションは通知を受ける。このプロセスに呼出しマネージャが参加する ことによって、共用プロセスのローカル制御と、必要に応じて開始すべきその他 のアクションが共に可能になる。呼出しマネージャは、アプリケーションが他の ノードおよびアプリケーションを識別するために使用する名前を処理する上で重 大な役割を果たす。

共用機構は連鎖することができる。たとえば、２つのアプリケーションがすでに 共用を行っている場合、それらの一方が、同じ共用セットを指定する第３のアプ リケーションとの共用を開始することができ、その結果、３つのアプリケーショ ンはすべて、相互に共用を行うことになる。

アプリケーションは、他のアプリケーションに代わってローカル共用要求を行う ことができ、それによって、代行すべき共用セットのメンバシップ制御を可能に する。共用要求の発行側またはターゲットがアプリケーション共用セットを指定 するための機能が存在する。このような名前は、特有のものである必要はない。

したがって、同じ名前の共用セットが複数存在できる。

それぞれのアプリケーションは、いつでも共用を終了し、共用セットを抜けるこ とができる。共用セット中の他のアプリケーションには、このことが通知される 。第３図は、多数のアプリケーションＡないしＥの共用を示す。この結果、第４ 図に示すように、共用が要求された順序にかかわらず２つの共用セットが生成さ れる。

通信、チャネル、およびポート 第５図の概略例に示すように、４ｏ、４１．４２などの共用セット中のアプリケ ーションは、チャネルといわれるデータ通信リンクを相互に確立することができ る。４３．４４などのチャネルは、論理的に専用の単一方向バイブであり、アプ リケーションで指定された送信特性を有する。チャネルは常に、送信側アプリケ ーションによって定義され、送信側アプリケーションから受信側アプリケーショ ンに向かう。チャネルの端部はポートといわれる。したがって、チャネルはすべ て、１つの送信側ボートと１つの受信側ポートを有する。

４５などの送信側ポートは、チャネルを介してパケット・データを送信する。４ ６などの受信側ボートはチャネルからのデータ・パケットを、それらが送信され た順序で受信する。

ａｗａｒｅアプリケーションに見える論理チャネル構造と、ノードの間に存在す る物理通信ネットワークの間に直接マツピングがない場合がある。

アプリケーションは、他のアプリケーションへの複数のチャネルを、異なるタイ プのデータ・トラフィックを分離する好都合な方法として確立することができる 。第２図のシステム・ネットワーク・マネージャ３１は、論理チャネルの一部ま たはすべてを、第１図のリンク１１などの単一の物理リンク上にマツプすること ができるが、これはアプリケーションには見えない。

チャネルは、多数のサービス品質特性を有する。これらの特性に作成プロセス中 にサポート・システム１７がまず交渉する。これによって、データ伝送特性を、 予期されるトラフィックの要件に合わせて調整することができる。これらの特性 は、暗号化、圧縮ヒントを含む。暗号化によって、チャネルに沿った伝送時にデ ータを暗号化することができる。圧縮ヒントによって、狭い帯域幅のリンクを介 してデータを圧縮するオプションがシステムに与えられる。

サービス品質パラメータは、アナログ・データとディジタル・データを区別する 信号タイプによって定義される。サービス・パラメータは、明示的に指定しなく てよいが、データ・クラスに関してはサポート・システムに通知することができ る。この機構によって、ビデオ・チャネル、音声チャネル、およびその他のデー タ・チャネルを都合よく確立することができる。チャネルの特性は、チャネルを 作成した後に再折衝することができる。データ送信特性は、ＡＰＩを介するチャ ネル作成呼出しで指定された特性に応じて、第２図のデータ送信マネージャ３２ によって実際のネットワークで実施される。

標準、組合せ、同期、および直列化の４つのチャネル・タイプがサポートされる 。標準チャネルはデフォルト・ケースである。他のタイプは、チャネル・セット といわれるチャネルの集合に関連して使用される。組合せチャネル・セットを介 して、複数のチャネルからのデータ・パケットが組み合わされ、単一のポートを 介して各受信側アプリケーションに送られる。各アプリケーションがすべてのデ ータ・パケットを同じシーケンスで受信することは保証されず、各アプリケーシ ョンがすべてのパケットを受信することだけが保証される。

直列化チャネル・セットを介して、異なるチャネルからのデータ・パケットが組 み合わされ、直列化され、各受信側ボートが同じシーケンスのデータを受信する ように各アプリケーションに送られる。同期チャネル・セットを介して、データ が同期され、それによって、別々のチャネル上のデータ・パケットが調子を合わ せて結合される（たとえば、音声とビデオ）が、そのチャネルに属するそれぞれ のポートを介して送られる。

データ直列化の一例を第６図に示した共用ドローイング・ボード・アプリケーシ ョンによって示す。２つの同じアプリケーションＡおよびＢ（５０および５２） によって、ユーザは単一の共用表面上で描画することができる。ＡおよびＢにい るユーザが同じ結果を見るには、ＡとＢで処理されるシーケンスが同じになるよ うに、Ａにあるすべての描画命令をポート５３および５４を介してＢに送り、Ｂ にあるすべての描画命令をボート５５および５６を介してＡに送らなければなら ない。これは、それぞれのアプリケーションが、共通の直列化チャネル・セット ５９のメンバである２つのチャネル５７および５８を介して、相互にかつそれ自 体にそれ自体のデータを伝送することによって行われる。

第４図を参照すると、リップ同期されたビデオと音声をアプリケーションＢ（６ １）に送信する必要があるアプリケーションＡ（６０）によってデータ同期が示 されている。２つのチャネル６２および６３は送信に使用され、それぞれが同じ 同期チャネル・セット６４のメンバである。

必要なチャネル特性を指定するサポート・システムへのＡＰＩ呼出しによってチ ャネルを明示的に作成することができ、既存のボートに新しいチャネルを追加す ることもできる。後者の機構によって、異なるチャネル・セットに属するチャネ ルを介してボートを共用することができる。たとえば、単一のボートから、組合 せチャネル・セットに属する１組の宛先、および直列化チャネル・セットに属す る第２の組みの宛先にデータを送信することができる。ディジタル・チャネルと アナログ・チャネルが同じチャネル・セットのメンバになることはできない。チ ャネルは削除することができ、送信側ボートと受信側ボートを指定することによ って固有に識別される。

チャネルは、アプリケーション共用セットのメンバである、または該メンバにな るアプリケーションの結果として暗示的に作成することができる。たとえば、未 共用アプリケーションがすでに、組合せチャネルまたは直列化チャネルを有する 場合、使用されるチャネル・セット名はこれらのアプリケーションのどれでも同 じであり、アプリケーションが相互に共用を行うと、必要な追加チャネルが自動 的に作成される。アプリケーションには、このように暗示的に作成されたチャネ ルが通知される。

ボートは、事象、コマンド、または空の割り当てられた接続タイプを有する。事 象ボートは、データが利用可能か、または必要なときに事象を生成する。コマン ド・ボートによって、アプリケーションはデータの受信またはボートへの供給を 駆動することができる。空ボートは、データをアプリケーションに供給できない ボート、すなわち、ビデオ・カメラの送信側ボートなどの、アナログ・チャネル に関連するボートのために予約される。ボートは、ボート事象ハンドラに送信さ れる“ｓｉｇｎａｌ　ｐｏｒｔ”コマンドを介して制御することができる。この コマンドは、ローカル・ボートに発行し、チャネル中の他のボートに渡すことが できる。通常、チャネル・ボート用のｓ　ｉ　ｇｎａ　ｌコマンドは、データを 供給または受信するアプリケーションのボート事象ハンドラに送信され、たとえ ば、データ・フローを停止、開始、削減、または増加するために使用できる。発 信元とターゲットの間の信号の順序は維持される。直列化チャネル・セット中の 受信側ボートに送信される信号は、それ自体が直列化され、それによって、すべ ての発信元が同じシーケンスのコマンドを受信する。他の典型的な信号はテープ ・ドライブに対する“ｒｅｗｉｎｄ”または”ｐａｕｓｅ”　、あるいはプリン タ装置に対する”ｃｈａｎｇｅ　ｐａｐｅｒｓｉｚｅ”である。

ユーザ出口は、任意選択でボートに関連付けることができる。これによって、デ ータが送信側ボートに供給された後、または受信側ポートによって供給される前 に、データを監視、または操作することができる。同期チャネルの場合、同期は 、データが送信側ボート・ユーザ出口を離れてから、受信側ポート・ユーザ出口 に供給されるまで実行される。

標準送信側コマンド・ボートの全体的な構造を第８図に示す。データは、アプリ ケーションからの”５ｅｎｄ　ｄａｔａ’″コマンドに応答して、ボート７０の バッファ７１中で待機する。アプリケーションは、バッファを空にして、ユーザ 出ロア２とチャネル７３を介して非同期的にデータを送信する。着信した’ｓｉ ｇｎａｌ　ｐｏｒｔ”コマンドは、回線７５上でチャネル７３とは独立に、ボー ト事象ハンドラ７４によって受信され、回線７６上で外部に再伝送することがで きる。

受信側ボートは実際上、対応する送信側ボートのミラー・イメージである。標準 受信側事象ボートの場合、構造が類似しているが、この場合、事象ハンドラはデ ータとｐｏｒｔコマンドを共に処理する。

同期を呼び出すときには状況はより複雑である。この場合、ユーザ出口およびバ ッファの前に、着信側チャネル上に同期プロセスを含めることによって、標準受 信側バッファ・ボートを修正しておかなければならない。

同期は論理的に、すべての事象を中央点に集合させることと、その後に、各事象 を、その事象のすべての宛先に同報通信することを伴う。図では、チャネル８０ および８１上の２つのボートＡおよびＢの場合に関する第９図でこれを表す。

この図では、直列化プロセス８５で、８２および８３でのボートＡおよびＢの出 力が、ボートＣ（８４）および他のボート（図示せず）に対して直列化される。

直列化は、すべてのデータを、直列化し、その後に分散するために単一の中央点 に送信することによって、該中央点で実施することができる。

直列化プロセス自体を分散することもできる。

受信側ボートは、送信側ボートに、チャネルに沿ったデータの送信を停止させ、 チャネル中の残りのデータを破棄するか、送るかのオプションを与える。後で、 中断されたデータ伝送を再開することができる。

チャネルとボートの使用を不要にするアプリケーション相互通信の代替方法は、 アプリケーションの間で制御情報を送信できるようにする”ｓｉｇｎａｌ”コマ ンドを介して提供される。

ボートは、データ・タイプおよびデータ・サブタイプを指定するデータ・クラス に関連している。データ・タイプはデータの性質、たとえば音声、ビデオ、ファ イルなどを識別し、アナログ・データとディジタル・データも区別する。データ ・タイプはさらに、データの厳密なフォーマットによって細分される。したがっ て、音声サブタイプの例はＧ、７１１、Ｇ、７２１、Ｇ、７２２である。

データ・クラスは、他のアプリケーションに依存せずに、データ・ストリーム自 体とは独立に、データ・フォーマットを得るためにアプリケーションによって照 会することができる。ＡＰＩより下位でＬａｋｅｓが変換を実行すれば、データ ・タイプは、送信側ボートと受信側ボートで異なってもよい。

ボートおよびチャネルのある種の特性、たとえばサービス品質、データ・クラス 、圧縮ヒントは、最初に確立した後に変更することができる。これによって、ア プリケーションが実行時に通信使用法を修正するための柔軟性が提供される。

−例は、ビデオ品質を一時的に低下させ、ファイル交換性能を高めることである 。

アプリケーションが、処理のために、入力を他のアプリケーションに経路指定で きるように、拡張通信リンクを確立するようにボートを接続することができる。

ボートをこのように接続し、ユーザ出口を確立していない場合、経路指定を確立 した後、それ以上アプリケーションを関与させる必要はない。これによって、ア プリケーションと装置の間のデータのストリーム化が可能になる。１つのボート が送信側であり、１つのボートが受信側でありさえすれば、異なるデータ・クラ スまたは異なる接続タイプの、異なるサービス品質特性を有する、異なるタイプ の異なるチャネル・セット中のチャネルの間で（１つのボートが空であるかぎり ）接続が許可される。接続が永続的になり、ローカル・アプリケーションを終了 したときでも持続するように、接続したボートをウェルドすることもできる。チ ャネルは、すべての点で、最初から、発信元から直接宛先まで作成された場合と 同様に動作する。

存在するすべてのユーザ出口は削除することができる。

論理装置 論理装置３０（第２図）は、（ｉ）クリップボード、ＤＤＥ、プリンタ、ビデオ 装置などのシステム資源および装置へのより容易なアクセス、（ｉｉ）たとえば 、ｕｎａｗａｒｅアプリケーションのウィンドウ内容およびファイル活動へのア クセスを与えることによって、ｕｎａｗａｒｅアプリケーションを協調作業に使 用すること、および（ｉｉｉ）アプリケーションの関与しない端末間データ・ス トリーム化、をイネーブルにするためにサポート・システムによってサポートさ れる。頻繁に使用される装置は、ビデオ・キャプチャ、ビデオ・プレイバック、 オーディオ・プレイバックなどを含み、追加装置を定義するために機能が提供さ れる。

論理装置はタイプによって識別される。タイプ名は、ノードに対してローカルで ある。論理装置はオープンされると、アプリケーションにボートを提供する。単 一の論理装置が複数のボートを有することができ、さらに、装置は同じノードに ある異なるアプリケーションに同時にボートを提供することができる。ボートを オープンするための関連ＡＰＩ呼出しによって、その装置に特有の特性、たとえ ば使用すべきデータ・フォーマットを設定することができる。オープンされた論 理装置は、単一のボートに送信される、特定の論理装置に特有のコマンドを介し て制御することができる。装置ボートへの典型的なコマンドは、テープ・ドライ ブへのリワインドまたはポーズである。装置の状況、たとえばデータが利用可能 かどうかを照会することもできる。

装置は、ユーザ出口が存在しないことを除き、チャネル・ボートによく似ている 。アプリケーションは、論理装置上のボートをチャネル・ボートに接続すること ができる。これによって、データは、装置との間を流れ、かつチャネルを介して 流れることができる。このデータ・フローは、接続が確立された後、それ以上ア プリケーションを関与させることを必要としない。たとえば、データをチャネル を介してカメラからカメラ論理装置までストリーム化し、ウィンドウ論理装置に よって表示することができる。アプリケーションは２つの論理装置をそれらの信 号ボートを介して制御することができる。もはや伝送が必要ないとき、アプリケ ーションはボートを切断し、装置をクローズし、チャネルを削除することができ る。

装置ボートをチャネル・ボートにウェルドすることはできない。なぜなら、こう すると、装置がローカル・アプリケーションの制御外に存在できるようになるか らである。論理装置は、サポート・システムにＡＰＩ呼出しを発行することを許 可されており、この点では、所有アプリケーション（すなわち、装置をオープン したアプリケーション）の代わりに働く。装置はたとえば、その所有アプリケー ションに、他のアプリケーションと共用を行わせ、チャネルを作成させ、かつデ ータを送受信させることができる。

潜在的な装置には以下のようなものがある。

−システム・クリップボード　−ＬＰＴｘ−ＤＤＥ　−ウィンドウ −共用クリップボード　−プリンタ ー直列エミュレータ　−ファイル ービデオ　−符復号器 −オーディオ　−電話 クリップボードの共用は、システム・クリップボード装置および共用クリップボ ード装置によって容易になる。システム・クリップボード装置をアプリケーショ ンによってオープンして、そのノードでのウィンドウ・システム・クリップボー ドへのアクセスを与える送信側ボートおよび受信側ポートを提供することができ る。いつでも送信側ボートは１つしか存在できないが、そのノードにあるどのア プリケーションでも受信側ポートをオープンすることができる。チャネルを使用 すると、あるノードからのシステム・クリップボード・データを単純に、アプリ ケーション共用セットの他のメンバに経路指定することができる。

他の装置、共用クリップボードは、データ共用を容易にするために提供されてい る。共用クリップボードは共用セットに特有のものである。送信側ボートは１つ しか許可されないが、複数の受信側ポートがサポートされる。これらの違いは別 として、共用クリップボードは、システム・クリップボードと同様に動作し、ア プリケーションが共通データを共用するための単純な機構を提供する。

ウィンドウ装置によって、画面上に定義されたウィンドウを送信側ポートまたは 受信側ボート（状況によってはその両方）と関連付けることができる。送信側ボ ートをチャネル・ボートに接続することができ、データをウィンドウにストリー ム化して表示することができる。様々なデータ・フォーマットがサポートされる 。

ＤＤＥ装置をオーブンして、動的データ交換機構に結合された送信側ポートおよ び受信側ポートを提供することができる。ａｗａｒｅアプリケーションは、この 装置を介して、ＤＤＥをサポートするアプリケーションを制御し、あるいはそれ 自体を制御することができる。さらに、適切なチャネルを確立することによって 、２つのリモートＤＤＥアプリケーションをリンクすることができる。

プリンタ装置によって、データをシステム・プリンタに送信することができる。

送信側ポートは１つしか許可されない。

非同期直列装置は、１つの送信側ポートと複数の受信側ポートをサポートし、Ｒ ８２３２、Ｒ３４２２、およびその他の直列通信とのインタフェースをとる。

ビデオ・ディスプレイ・プレイバック装置（Ｉ　ＢＭ／インテル・アクションメ ディアＩＩアダプタ／Ａ　（ＩＢＭ／ＩｎｔｅｌＡｃｔｉｏｎＭｅｄｉａ　ＩＩ 　Ａｄａｐｔｅｒ／Ａ）をサポートする）、ビデオ・キャプチャ装置（ＩＢＭ　 Ｍビデオ・キャプチャ・アダプタ／Ａ　（ＩＢＭ　Ｍ−Ｖｉｄｅｏ　Ｃａｐｔｕ ｒｅ　Ａｄａｐｔｅｒ／Ａ）をサポートする）、オーディオ・キャプチャ・プレ イバック装置（ＩＢＭ　Ｍオーディオ・キャプチャ・プレイバック・アダプタ／ Ａ　（ＩＢＭ　Ｍ−Ａｕｄｉｏ　Ｃａｐｔｕｒｅ　ａｎｄ　Ｐｌａｙｂａｃｋ　 Ａｄａｐｔｅｒ／Ａ）　をサポートする）、およびその他の特殊オーディオ／ビ デオ装置（Ｈ３２０準拠符復号器などの）を含む、多数のビデオおよびオーディ オ装置が存在する。

ａｗａｒｅアプリケーションの多くはシステム・ユーティリティとして出荷され ており、これらの装置を利用して、ネットワークを介した協調作業のための汎用 エンド・ユーザ機能を提サポート・システム１７用のカストマイズ情報は、適切 なプラットフォーム指定リポジトリに記憶される。ＷｉｎｄｏｗｓおよびＯ５／ ２の場合、この情報は、ＬＡＫＥＳ、　ＩＮＩおよびＬＡＫＥＳＱＯ３，ＩＮＩ と呼ばれるファイルである。これらのファイルは、キーワードとその値が維持さ れる、識別子で始まるセクションを含む標準ＡＳＣＩＩファイルとしてフォーマ ットされる。アプリケーションは、それ自体の追加初期設定フィールドを有する こともできる。ＬＡＫＥＳ、　ＩＮＩは、構成および始動オプション、ａｗａｒ ｅアプリケーション、装置、および物理通信リンクに関する情報を含む標準セク ションを含む。そのようなアプリケーションに特有のデータを含むアプリケーシ ョン・セクションを存在させることもできる。ＬＡＫＥＱＯ３，ＩＮＩは、物理 リンクおよびデータ・クラスに関するサービス品質情報を含む。これらのファイ ルにアクセスし、それらを更新するための呼出しはＡＰＩに提供されている。

資源管理 協調作業では多（の場合、ノードが所有する資源、たとえばプリンタ装置を他の ノードと共用できることが必要になる。

そのような資源は、グローバル資源とみなされ、アクセスはグローバル・トーク ンを介して制御される。その他の資源、たとえば共用ポインタは、アプリケーシ ョン共用セットにローカルであり、これへのアクセスはアプリケーション・トー クンを介して管理される。

トークン所有者は、トークンの重要度を判定し、それを要求上に割り振る。所有 者の裁量で、待機中の要求を許可することができ、特定のトークンの複数の同時 保持者を許可することができる。トークン所有者は、任意選択で、保持者にトー クンを戻させることができる。

グローバル・トークンは、ネットワーク全域にわたって共通名前空間を共用する が、アプリケーションは、それが必要とするグローバルに利用可能な資源の位置 を知っているとみなされるので、重複グローバル・トークン名が許可される。

可用性情報を回報通信するための機能は提供されない。その代わり、グローバル 資源をもつノードにある呼出しマネージャは、資源管理の責任を負い、したがっ て、あらゆるグローバル・トークンを保持する。グローバル・トークンは、アプ リケーション・インスタンスによって排他的に保持し、あるいは共用することが できる。しかし、トークン所有権をアプリケーションに移すことはできない。グ ローバル・トークンをめる要求は、ＡＰＩより上位で保持され、ノード呼出しマ ネージャによって管理される待ち行列によって待機させることができる。グロー バル・トークンへのアクセスは共用アプリケーション・セットだけに制限されな い。

アプリケーション・トークン名空間は、アプリケーション共用セットだけに制限 されない。トークンはどのメンバ・アプリケーションでも所有することができ、 所有権を移すことができる。アプリケーション・トークンは排他的に保持し、あ るいは共用することができ、トークンに対する要求は、ＡＰＩより上位で保持さ れ、現アプリケーション・トークン保持者によって管理される待ち行列で待機す ることができる。

初期設定および終了 サポート・システムは、ＬＡＮＥＳ、ＥＸＥファイルを動作させることによって 始動される。このファイルは、ファイルＬＡＫＥＳ。

ＩＮＩからプロファイル・データを読み取る。指定された呼出しマネージャが、 サポート・システムによって始動され、次いで、それ自体をａｗａｒｅアプリケ ーションとして登録する。次いで、”ｓｅｔ　ｃａｌｊｍａｎａｇｅｒ”コマン ドがこの特定のアプリケーションをそのノード用の呼出しマネージャとして確立 する。

このコマンドの後に、サポート・システムはそのノードで完全に活動状態になり 、着信事象および要求を処理できるようになる。

ａｗａｒｅアプリケーションは、アイコンのダブル・クリックなどの通常のオペ レーティング・システム手順、または”　１ａｕｎｃｈ”コマンドによって開始 することができる。前者の場合、アプリケーションはサポート・システムに登録 され、リターン・データで、アプリケーション・ハンドルおよびノード・ハンド ルを受信する。呼出しマネージャにこの登録のことが通知され、アプリケーショ ンへのハンドルが供給される。後者の場合、ローンチする側のアプリケーション にアプリケーションへのハンドルが返される。ローンチされる側のアプリケーシ ョンがサポート・システムに登録されるまで、このハンドルは非常に限られた状 況でしか有効ではない。リターン・データは、ローンチされる側のアプリケーシ ョンにアプリケーション・ハンドルとノード・ハンドルを提供する。

呼出しマネージャと、ローンチを指定したアプリケーション（呼出しマネージャ と異なる場合）は共に、適宜、通知を受ける。

アプリケーションは、登録が取り消され、呼出しマネージャが通知を受けること によってｕｎａｗａｒｅアプリケーション状況に戻ることができる。保持されて いるすべてのトークンが解除され、トークン所有者が通知を受け、所有されてい るすべてのトークンが無効になる。アプリケーションがアプリケーション共用セ ットのメンバである場合は削除され、該アプリケーションが前記セットを抜けた ことが他のメンバに通知される。アプリケーションによって作成されたすべての ボートが破壊され、影響を受けるチャネルへのボートを所有する他のアプリケー ションが通知を受ける。終了するアプリケーションによって接続されたすべての チャネルがウェルドされ、端末チャネル・ボートで適切な事象がレイズされる。

適切な事象をレイズすることは、ローカル呼出しマネージャと、登録を取り消す 側のアプリケーションに代わって、ウェルドされたチャネルをサポートするあら ゆるノードの呼出しマネージャに必要である。オープンしている論理装置はすべ てクローズされる。ボートに接続された論理装置がある場合は登録取消しプロセ スの一部として破壊され、次いで、接続されたチャネル全体が破壊され、適当な 事象がレイズされる。

ノードしあるサポート・システムを通常の方法でクローズするために、アプリケ ーションによって遮断要求を発行することができる。これによって、ローカル呼 出しマネージャで事象がレイズされ、呼出しマネージャが要求を受け入れる場合 は、他のアプリケーションで対応する遮断事象がレイズされる。次いで、これら のアプリケーションは閉止し登録を取り消す準備をして、各登録取消しが呼出し マネージャに通知される。すべてのアプリケーションが登録を取り消したことが 呼出しマネージャに通知された後、前記呼出しマネージャも登録を取り消して遮 断を完了する。

サポート・システムの通常の操作は、呼出しマネージャの存在によって変化する 。既存の呼出しマネージャを他の呼出しマネージャと交換することが可能である が、既存の呼出しマネージャは、その要求を拒否することができる。

アプリケーションは、”５ｈａｒｅ　ａｐｐ”要求を発行してアプリケーション 共用セットを指定することによって、共用セット中の他のアプリケーションに加 わることができる。通常の場合には、ターゲット・アプリケーションとノードを 共に名前で指定する。あるノードにあるアプリケーションが他のノードにすでに 存在するアプリケーション・インスタンスと名前によって共用を行いたい場合の 手順は次のとおりである。ノード１にあるａｐｐ　１が、それ自体のアプリケー ション・ハンドルおよびノード・ハンドルを発信元として、ａｐｐ　２およびノ ード２の名前をターゲットとして指定した”５ｈａｒｅ　ａｐｐ”要求を発行す る。ノード１にある呼出しマネージャによる検証の後、サポート・システムによ って、ノード２にある呼出しマネージャに適切な要求が送信される。この呼出し マネージャが要求を受け入れる場合、要求はａｐｐ　Ｚ上に渡され、ａｐｐ　２ は、それが共用の受入れを希望していることを示す確認を返すことができる。こ の方式は、アプリケーション共用においてかなりの柔軟性を提供する。各呼出し マネージャは、アプリケーションが”５ｈａｒｅ　ａｐｐ”要求の発信元であれ 、ターゲットであれ、そのノードでの共用活動を知る。

呼出しマネージャは、共用要求の受信時に、（ｉ）共用自体を処理する、（ｉｉ ）共用要求を転送する、（ｉｉｉ）共用を拒否する、（ｉｖ）共用を処理する新 しいアプリケーションをローンチする、（Ｖ）アプリケーションおよびノード名 を変更するというオプションを有する。

アプリケーションは、ローンチされるとき、アプリケーション共用セットのメン バではない。発信元アプリケーションは、”　５ｈａｒｅ−ａｐｐ”要求を発行 するとき、その結果得られる共用セットを命名するオプションを有する。共用セ ットを命名しない場合、ターゲットが名前を供給しなければならない。

共用を行った後、ターゲットと発信元は共に、この名前の新しい共用セットに加 わる。発信元またはターゲット、あるいはその両方がすでに、これと同じ名前の 共用セットのメンバだった場合、それらの共用セットは新たに作成された共用セ ットと組合わされる。アプリケーションは、”ｕｎｓｈａｒｅ、、−ａｐｐ”要 求を使用して共用セットを抜けることができる。

データ送信および受信 アプリケーションがデータを交換するための機構が４つある。

（ｉ）ユーザ情報文字列 これは実際上、ＡＰＩ呼出し中のパラメータとしてサポート・システムに渡され 、次いでターゲット・アプリケーションに渡される文字列である。

（ｉｉ）信号関数呼出し このコマンドは、アプリケーションの間で制御情報を送信できるようにし、単一 の共用セット内のアプリケーションだけに制限されない。使用されるＡＰＩ呼出 しに応じて、応答が提供されることも、提供されないこともある。この方法が異 なるノード自体のデータ制御フローのために該ノード上のサポート・システムの 間に確立された通信経路を使用するため、この技術は、軽いデータ・トラフィッ クに制限されることに留意されたい。

（ｉｉｉ）チャネル送信 チャネルは、アプリケーションの間のボリューム・データの転送をサポートする ものである。チャネルは、転送特性を制御する手段だけを提供する。チャネルの 使用は、同じアプリケーション共用セット内のアプリケーションだけに制限され る。チャネルの作成を要求する際は、ターゲット・アプリケーション・ハンドル 、チャネル・セット・タイプおよび識別子、データ・クラス、最大バッファ・サ イズ、ユーザ出口、ノード・ハンドル、サービス品質、接続タイプ、ボート事象 ハンドラ、ユーザ情報の情報を指定する。チャネル作成の代替手法は、既存の組 合せチャネル・セットまたは直列化チャネル・セットをもつアプリケーションが アプリケーション共用に関与しているときに作成されたチャネルを利用すること である。

データは、アプリケーションによってチャネルを介してデータ単位で送信される 。物理レベルでは、データ送信の単位はフレームである。ある種のデータはスポ イル可能である。

すなわち、ある状況の下では、サービス品質要件を満たすようにデータを送れな い場合、そのデータを破棄することができる。パケットによっては、スポイル可 能とマーク付けできるものと、そうできないものがある。スポイラ・パケットは 、存在する場合、それに関連するスポイル可能パケットを削除する。この技術は たとえば、あるパケットがデルタ・フレーム・パケットで、他のパケットが完全 フレーム・パケットである、ビデオ用のバッファ管理方式の実施態様をサポート する。完全フレームが利用できる場合、選択されたデルタ・フレーム・パケット ・シーケンスを削除することができ、かつ削除しなければならない。

（ｉ　ｖ）論理装置 ある特殊な状況では、論理装置を使用してデータを交換するのが妥当である。単 一の論理装置が、複数のアプリケーションにボートを提供することができる。論 理装置は次いで、ポートの間でデータを移動することができる。この転送機構は 、同じ共用セット内のアプリケーションだけに制限されず、したがってチャネル に課された限界を解消する。しかし、論理装置は複数のノードをカバーすること はできない。さらに、必要なサービス品質サポートは、特定の論理装置によって 明示的に提供しなければならない。

サービス品質の折衝 アプリケーションは、サービス品質および帯域幅の折衝および制御に関して異な るニーズを有する。たとえば、以下のものが必要になることがある。

Ｏ事前に決定された一定のサービス品質、たとえば０．７１１音声 Ｏチャネル作成時に柔軟であり、その後は一定である要件、たとえばファイル転 送 Ｏチャネル資源の単一アプリケーション管理、たとえば、制限された帯域幅条件 の下で、すなわち、データ・トラフィックを許可するためにビデオ品質を間欠的 に低下させなければならない場合に、アプリケーションがビデオ、音声、データ などの複数のデータ・タイプを伝達する。

Ｏチャネル資源のアプリケーション間管理、たとえば、一群のアプリケーション が、制限された帯域幅条件の下で複数のデータ・タイプを伝達し、該データ・タ イプの活動を、異なるタイプのデータ・トラフィックのための優先順位変更とし て調整する。

ある種のアプリケーションは、他のアプリケーションと通信するのに必要なチャ ネルの固定サービス品質要件を有する。

このような場合には、”ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”要求を使用してチャネ ルを直接確立することができる。この要求上のパラメータは、受信側アプリケー ションと、チャネルと送信側ポートとの特性を識別する。資源が利用可能であり 、受信側アプリケーションが要求を受け入れる場合、チャネルが作成される。

一部のアプリケーションは、サービス品質要件がより柔軟であり、特定のノード に何が利用可能かを判定し、次いで”ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”要求のパ ラメータを設定する際にこの情報を使用する必要がある。これは、ターゲット・ ノードを指定する”ｑｕｅｒＪｒｅｓｏｕｒｃｅ”コマンドを介して行う。この 後の”ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”は、通信資源をめる競争がない場合、前 と等しいか前よりも低いサービス品質を要求して、要求を満たしてもらうことが できる。

他のアプリケーションは、柔軟なサービス品質要件を有するが、多数のチャネル に対して指定を行う必要がある。このためには、アプリケーションが資源を予約 し、次いでこの予約されたプールから割振りを行う必要がある。

これは、資源セット識別子、サービス品質、およびターゲット・ノードを指定す る”ｃｌａｉｍ　ｒｅｓｏｕｒｃｅ″′コマンドによって行う。このコマンドは 、その資源を予約して、指定された識別子と関連付ける効果を有する。この識別 子は次いで、その後の”ｃｒｅａｔｅ　ｃｈａｎｎｅｌ”コマンドで指定するこ とができ、この場合、そのようなリザーブから資源が割り振られる。

”　ｑｕｅｒｙ　ｒｅｓｏｕｒｃｅ”コマンドを使用して、資源セット中の残り の資源を判定することができる。

ある種のアプリケーションは、実行時にチャネル特性を動的に変更する必要があ る。たとえば、利用可能な帯域幅をチャネルごとに再割振りしなければならない 。これは、資源セット識別子を指定する”　ｃｈａｎｇｅ　ｃｈａｎｎｅｌ　” 要求を介して行うことができる。資源は、その識別子に関連する資源に与えられ 、あるいは後者の資源から取られる。この技術によって、たとえば、固定資源を アプリケーション間通信用に確保し、次いで、トラフィックに応じて動的に再割 振りすることができる。たとえば、ビデオ帯域幅を一時的に削減して、より高速 のファイル転送を可能にすることができる。

資源セット識別子は、アプリケーション・インスタンスにローカルであり、１つ の特定のサービス品質に適した資源をアプリケーションは、チャネルを作成する 際に、あるいは後でチャネルに割り振るために資源を予約する際に、サービス品 質特性を指定することができる。この場合、チャネルは物理リンク上にマツプさ れる。論理チャネルを介してアプリケーションによって送信されるデータ・パケ ットは、リンクを介して送信されるデータ・フレームとして実施される。

リンクは交換リンクであれ固定リンクであれ、順序と、タイムアウト・パラメー タと、サービス品質特性によって特徴付けられる。順序は、サポート・システム が、適切なデータ送信特性があればリンクの選択が可能であると仮定して、リン クをデータ送信に使用しようとする順序を決定する。交換リンクであれ、固定リ ンクであれ、順序とタイムアウト・パラメータは初期設定ファイルに指定する。

任意選択でサービス品質特性を含むリンク記述は、サポート・システムの外部の リンク・データベースに記憶される。

サービス品質情報用のデフォルトは初期設定ファイルに含まれている。データベ ースは、サポート・プログラムによって呼び出される、導入先が供給した実行可 能ファイルによってアクセスされる。ディジタル・リンクに関連するサービス品 質パラメータは、スループット、待ち時間、ジッタ、フレーム・サイズ、フレー ム・エラー・レート、フレーム再伝送時間、圧縮ヒント、暗号化である。

アプリケーションが論理チャネルを介して必要とするサービス品質を特徴付ける ために使用される主要パラメータは、スループット、待ち時間、ジッタ、パケッ ト・サイズ、パケット・エラー・レート、暗号化、圧縮ヒント、優先順位である 。サポート・システムが、チャネルの間に資源競合が存在すると仮定して、その ノードにあるすべてのチャネルを介したデータ送信を実行しようとする順序を指 定するチャネル優先順位と、送信の損失またはエラーのために送る必要のない受 入れ可能なランダム比率のパケットを指定するパケット・エラー・レート（サポ ート・システムがこのような限定に従うという保証はない。ここでゼロを指定す ると、アプリケーションにあらゆる失敗が通知される）を除き、これらのパラメ ータの大部分は、対となるリンクを反映する。

上記の情報は、アプリケーション間通信にどのリンクを使用すべきかを判定する ために使用される。リンクのタイプやサービス特性などの情報を含むデータベー スは資源インタフェースを介してアクセスできるが、チャネル情報はアプリケー ションから得られる。サポート・システムは次いで、（ａ）異なるノードにある サポート・システムの間で制御情報を交換する必要と、（ｂ）　リンクに関連す る順序値とを考慮に入れて、完全に満たされたチャネル要件と、完全に満たされ た利用可能リンク情報との一致に基づいて、使用するのにふされしいリンクを選 択する。

ソフトウェアおよびハードウェアの圧縮と暗号化が共にサポートされる。物理リ ンク上のハードウェア機構は、オプションの様々な組合せを、それぞれが特定の 転送特性に関連する異なる利用可能リンク・タイプとみなすことによって収容さ れる。ソフトウェア・ルーチンも使用できるが、特定の待ち時間要件およびジッ タ要件を設定していない場合は呼び出されない。

リンク情報を検索するために使用されるＲＬＩ呼出しも、必要に応じて、サポー ト・システムの外部で複雑な経路選択プロセスを実行できるようにするために、 すべての必要なチャネル・サービス品質特性を供給する。この機構を介して、外 部ルーチン自体が、適切な経路を決定し、その経路をサポート・システムに返す ことができる。この必要がある例は、送信コストが時刻によって変わることであ ろう。

チャネルをもつアプリケーションが相互に共用を行うとき、アプリケーションの 既存のチャネルが同じ名前の組合せチャネル・セットまたは直列化チャネル・セ ットに属する場合、サポート・システムは追加チャネルを作成する。そのポート にふされしいサービス品質によって、各送信側ポートからこのような新しいチャ ネルを確立することが試みられる。すなわち、暗示的に作成されたチャネルが、 そのポートから１つの既存のチャネルを介して送信する予定のデータ・パケット を首尾よく転送できるような特性をもとうとする。場合によっては、利用可能な 物理リンクの機能によって課される制限のために、そのような特性をもつチャネ ルを作成できないこともある。しかし、すべての場合に、チャネルが作成され、 チャネル機能が重要である可能性が大きい場合、それを照会することは、アプリ ケーション・プログラムの責任である。

ノードの間のチャネルは、単一の物理リンクまたは複数の直列接続リンクを介し て実現することができる。２つのノードの間に存在する物理接続を経路と呼ぶ。

ａ）永続ディジタル・ネットワーク サポート・システムは、専用リンクであれ、共用リンクであれ、交換リンクであ れ、永続リンクであれ、ノードの間のディジタル・リンクと共に動作する。共用 リンクは、帯域幅管理機能を使用しないかぎり、予測できない待ち時間特性およ び帯域幅特性を有する。そのような特徴によって、永続リンクには交換接続の特 性が多数与えられている。

ｂ）永続アナログ・ネットワーク サポート・システムは、以下の状況で、ディジタル通信と非常に類似した方法で アナログ通信をサポートする。

○ノードの間にアナログ・リンクが存在する。

○各ノードでの接続性および経路指定を、そのノードにあるシステムによって制 御することができる。

○ノードの間にディジタル制御チャネルが存在する。

アナログ・チャネルは、送信側アプリケーションによって確立される論理的に専 用の単一方向通信リンクであり、複数の受信側アプリケーションで終了すること ができる。このチャネルは、そのサービス品質特性によってディジタル・チャネ ルと区別することができる。このアナログ・チャネルを終了するポートは、アプ リケーションにデータを供給することも、アプリケーションからデータを受信す ることもできないので、空接続タイプを有する。標準チャネルまたは組合せチャ ネルだけしか確立できず、直列化チャネルおよび同期チャネルは許可されない。

論理装置は、オープンされると、アナログ・ポートを提供することができる。し たがって、ビデオ・プレーヤ装置をアナログ・ビデオの発信元として使用するこ とができ、ＡＰＩコマンドを介してアナログ・チャネルに接続することができる 。アナログ・チャネルとディジタル・チャネルの直接接続は許可されない。しか し、ある装置、たとえば符複合器は、オープンされるとアナログ・ポートとディ ジタル・ポートを共に提供し、そのような結合を有効化するために使用すること ができる。

Ｃ）交換ディジタル・ネットワーク 交換ディジタル・ネットワークは、接続の交換性の影響を受けずに、サポート・ システムによってノード間通信に使用することができる。資源インタフェースを 介してアクセスされた情報は、非活動状態の交換接続をいつ終了すべきかを決定 するためにシステムによって使用される。

交換ネットワークに接続された、ディジタル電話などの機器は、アプリケーショ ンによって２つの方法のうちの１つでアクセスされる。簡単な接続だけが必要な 場合、電話を仮想ノードで実行する仮想電話アプリケーションとみなすことがで きる。電話との接続は、仮想ノードをターゲットとして指定する共用要求によっ て開始され、ローカル・ノードに関連する電話とリモート電話の間に電話呼出し が確立される。着信電話呼出しは同じように、すなわち共用要求として処理する ことができる。

電話を論理装置としてアクセスすることもできる。したがって、Ｉ　ＳＤＮ電話 装置をオープンして、関連する事象接続タイプまたはコマンド接続タイプの受信 側ポートおよび送信側ポートを提供することができる。ダイアリングおよびその 他の制御機能は、”ｓｉｇｎａｌ　ｐｏｒｔ”コマンドを介して実施される。デ ィジタル電話機器の間のサード・パーティ接続は同様に、該当する装置へのコマ ンドによって影響を受ける。これは、ローカル・スイッチへのコマンドを介して 物理的に実施される。

データまたは経路指定を動的に修正する潜在的に活動状況の分岐制御装置、たと えばオーディオ・ビジュアル通信用のＣＣＩＴＴ勧告を実施するＭＣＵをアプリ ケーションに対する装置として使用することもできる。

ｄ）交換アナログ・ネットワーク 公衆交換網に接続されたアナログ電話およびその他の機器は、ディジタル電話と 同様に、仮想ノードで実行する仮想電話アプリケーションとして、または論理装 置を介してアクセスすることができる。ＰＳＴＮ電話論理装置をオープンして、 空接続タイプのポートを提供することができる。すなわち、該ポートはアプリケ ーションにデータを供給することも、アプリケーションからデータを受信するこ ともできない。

”ｓｉｇｎａｌ　ｐｏｒｔ”コマンドは、装置を制御するために使用される。フ ァースト・パーティ接続は、ローカル回線にダイアリング・トーンを挿入するモ デム、サード・パーティ接続、およびローカル・スイッチへのコマンドを介する 多方向呼出しを介して実施することができる。

ｕｎａｗａｒｅアプリケーションとのインタフェース　。

サポート・システムは、ｕｎａｗａｒｅアプリケーションを協調作業に使用でき るようにする機能を提供する。ａｗａｒｅアプリケーションは、ユーザ・インタ フェース・ダイアログを供給し、仮想装置を介して特定のｕｎａｗａｒｅアプリ ケーションと対話する。

この同じａｗａｒｅアプリケーションは次いで、リモート・ノードにある関連ａ ｗａｒｅアプリケーションと通信し、リモート・ユーザに情報を渡す。そのよう なアプリケーションの幾っがは、汎用ユーティリティとして含められている。

共通要件は、第１１図に示すように、ｕｎａｗａｒｅアプリケーションのアプリ ケーション・ウィンドウをリモート・ノードで表示することである。実施態様は 次のとおりである。ノードＸにあるａｗａｒｅアプリケーションＡ８がユーザと 対話して、ここではｕｎａｗａｒｅアプリケーションＵｘと仮定された必要なウ ィンドウを識別する。ＡＸは次いで、適切なパラメータによってウィンドウ表示 論理装置をオープンする。この効果は、ウィンドウ・データのコピーを得るため のポートを生成することである。Ａｘは、宛先ノードＹにあるａｗａｒｅアプリ ケーションＡＹに至るチャネル上のポートにこれを接続する。ＡＹは次いで、実 際のウィンドウ論理装置をオープンして、作成されたポートを受信側チャネル・ ポートに接続する。データが、ノードの間を流れ、それ以上アプリケーションＡ ８にもＡＹにも干渉されずにＹで表示される。ウィンドウ論理装置オープン要求 で利用可能なオプションによって、アプリケーションはビット／ピクセル、更新 の頻度、データ・フォーマット（たとえば、テキスト、ビット・マツプ、および 組込みポインタ位置のオプション）などのパラメータを指定することができる。

ｕｎａｗａｒｅアプリケーションＵつの共用ウィンドウ上のリモート・ポインタ をＡＸおよびＡＹで処理し、対話型データ・クラスに適したチャネルをセット・ アップすることができる。次いで、各ノード上の実際のポインタを使用して、共 用ウィンドウ中の機能を識別する。これは、指示したい各ユーザがポインタを共 用ウィンドウ内に移動する、などのアルゴリズムによって行うことができる。ポ インタが共用ウィンドウ中にあるとき、その座標が共用アプリケーションに送信 される。

次いで、組合わされた座標を使用して、ポインタが制御される。この結果、だれ であれ、最後にカーソルを移動した人が、すべてのリンクされたポイントを位置 決めすることになる。

リモート印刷とリモート・ファイル生成は同様に、論理装置を介して行う。印刷 の場合、発信元ノードにプリンタ・エミュレータ装置を設置する。この装置がユ ーザによってプリンタ装置として選択されると、その結果、プリンタ・データ・ ストリームがボートにリダイレクトされる。このストリームは次いで、ａｗａｒ ｅアプリケーションを介して、宛先ノードにある実際のプリンタ装置に接続され る。この汎用技術は、動的データ交換（ＤＤＥ）やシステム・クリップボードな どの他の機能の範囲で拡張される。

アプリケーションまたはシステムのリモート制御は直接には供給されない。しか し、リモート制御を実行するアプリケーションをＡＰＩより上位で実現すること ができ、Ｌａｋｅｓはグループ通信およびマルチメディア・データ送信機能を提 供する。

プログラミングの留意事項 ａ）プログラム呼出しタイプおよび構造ＡＰＩへのプログラム呼出しは一般に、 要求、指示、応答、確認シーケンスになる。サービスを必要とするアプリケーシ ョンＡは、適切なパラメータを供給してそのサービスを要求する。要求は通常、 他のアプリケーション已にその要求を認識させることを必要とする。このための 機構は、アプリケーションＢで指示として出現する非送信請求事象である。この 指示事象に対してＢが取るアクションは、適切なデータをもつ応答としてサポー ト・システムに与えられる。システムは、この情報を確認事象として再びアプリ ケーションＡに渡す。

これを、チャネルにボートを追加する上で関与するシーケンスの例を使用して第 １２図に示す（図を単純にするために、パラメータはいっさい示さない）。

ＡＰＩ呼出しは、特定の機能に応じて、同期呼出しでも非同期呼出しでもよい。

同期呼出しは、要求が完了すると制御を戻す。非同期呼出しはただちに制御を戻 す。アプリケーションが非同期呼出しの進行を監視できるようにするために、こ れらの呼出しは参照識別子を含む。この識別子は、要求が満たされ、状況を得る ために照会を発行できるようになるまで、有効である。この同じ識別子を使用し て、保留中の要求を取り消すこともできる。呼出しはすべて、呼出し状況を示す リターン・コードを返す。

ｂ）アドレス可能性 アプリケーションは、ノード名を使用してノードへのアドレス可能性を要求する 。この名前はまず、それを修正するオプションを有するローカル呼出しマネージ ャに渡される。その結果得られる名前は次いで、接続性情報を判定するためにサ ポート・システムによって使用される。接続性情報の判定は、資源インタフェー スを使用する、外部に保持されたネットワークおよびユーザ・データベースへの アクセスを必要とする。したがって、サポート・システムは、第２図の資源イン タフェース２９を介するネットワーク構成への照会を介してその名前に関する物 理アドレス可能性を判定する。このノード名の分解能を反映するノード・ハンド ルがアプリケーションに返される。１つのアプリケーションから他のアプリケー ションへのアドレス可能性にはアプリケーション名の分解能が必要である。両方 のアプリケーションが同じノードにある場合、ローカル呼出しマネージャがこの 分解能を実行することができ、そうでない場合は、両方の呼出しマネージャが関 与しなければならない。この分解能の結果、アプリケーション・ハンドルによっ て、ターゲット・アプリケーションが発信元アプリケーションに対して識別され る。アプリケーション名を使用する呼出しは常に、分解能のために呼出しマネー ジャに渡される。アプリケーション・ハンドルを使用する呼出しは、指定された アプリケーションに直接向かう。

アプリケーションがチャネルを作成するとき、チャネル・ボートへのアドレス可 能性が、ボート・ハンドルを返すシステムを介して提供される。同様に、論理装 置をオープンすると、装置ボート・ハンドルが得られる。

すべてのハンドルは、使用する側のアプリケーションに特有のものであるが、他 のアプリケーションまたはノードに渡される場合は有効でな（なる。

Ｃ）事象クラスおよび事象ハンドラ ＡＰＩ要求は、事象および呼出し制御を援助するために提供される。”ｂｅｇｉ ｎ　ｍｏｎｉｔｏｒ”要求によって、アプリケーションはノードでの要求および 事象を監視することができる。監視の範囲は、以下のものの１つから監視クラス を選択することによって制御される。

Ａｌｌ：すべでの事象またはＡＰＩ呼出しＡｐｐｌｉｃａｔｉｏｎ　Ｓｉｇｎａ ｌｌｉｎｇ　：信号事象／ＡＰＩＡＰＩ呼出１ｌ　ｍａｎａｇｅｒ　：呼出しマ ネージャ事象／ＡＰＩ呼出しＤａｔａ　：データ送信事象／ＡＰＩ呼出しＤｅｖ ｉｃｅ　：装置事象／ＡＰＩＡＰＩ呼出ｎ１ｔｏｒ　：モニタ事象／ＡＰＩ呼出 しＰｏｒｔ　：ポートおよびチャネル事象／ＡＰＩ呼出しＰｒｏｆｉｌｅ　ニブ ０７フイル事象／ＡＰＩ呼出し５ｈａｒｅ　：共用および非共用事象／ＡＰＩ呼 出し５ｙｎｃｈｒｏｎｉｓａｔｉｏｎ　：同期事象／ＡＰＩＡＰＩ呼出ｋｅｎ　 ニド−クン事象／ＡＰＩ呼出し監視の範囲は事象クラス・レベルまたはＡＰＩク ラス・レベルで制御される。事象は、データがあってもなくても監視することが できる。監視は、”ｅｎｄ　ｍｏｎｉｔｏｒ”コマンドによって終了する。アプ リケーションは、”ｅｎａｂｌｅ−ｅｖｅｎｔｓ”コマンドおよび”ｄｉｓａｂ ｌｅ　ｅｖｅｎｔｓ’″コマンドを使用して、どの事象を受信すべきかも決定す る。有効な事象クラスは以下のとおりである。

Ａｌｌ：すべでの事象 Ｄｅｖｉｃｅ　：装置事象 Ｐｏｒｔ　：ポートおよびチャネル事象Ｐｒｏｆｉｌｅ：プロファイル事象また はＡＰＩ呼出しＳｈａｒｉｎｇ　：共用要求事象またはＡＰＩ呼出しデフォルト の事象ハンドラは、アプリケーションを介して明示的に処理されないすべての事 象に対する応答を生成する。

事象は、登録された事象ハンドルによって処理される。

ａｗａｒｅアプリケーションには４つのタイプが存在できる。

Ａｐｐｌｉｃａｔｉｏｎ　：これは、一時事象ハンドラであり、ａｗａｒｅアプ リケーションの一般動作に関連する主な事象を処理する。

この事象ハンドラは、呼出しマネージャを含むすべてのａｗａｒｅアプリケーシ ョンに存在しなければならない。

Ｃａ１ｌ　ｍａｎａｇｅｒ　：これは幾分特殊であり、アプリケーション登録、 名前分解能、遮断要求、受動ノード、呼出しマネージャ転送、およびグローバル ・トークン状況に関する事象を処理する。この事象ハンドラがすべての呼出しマ ネージャになければならない。

Ｐｏｒｔ−ｅｖｅｎｔ、　ｈａｎｄｌｅｒ　：複数のポート事象ハンドラが存在 でき、それぞれがデータ通信関連事象を処理する。

Ｍｏｎ１ｔｏｒ　：これは任意選択で存在し、すべての事象監視を処理する。

ｄ）その他のプログラミング機能 データ・トラフィックを監視し、あるいはデータを処理するように、すべてのチ ャネル・ポートをユーザ出口と関連付けることができる。送信側ポートの場合、 ユーザ出口は、データが受信側ポートに送信される直前に呼び出される。受信側 ボートの場合、ユーザ出口は、データが受信側ボートに到着した直後であるが、 受信側アプリケーションに提供される前に呼び出される。データはユーザ出口に 移動しなければならないので、接続されているポート上にユーザ出口ルーチンを 指定すると性能に影響が及ぶことがある。

アプリケーションが状況情報を追跡しなくて済むように、完全な１組の照会が提 供されている。

アプリケーション・プログラム・デバッグは、最初に単一のノードで協調アプリ ケーションを動作させることによって簡単にすることができる。これによって、 プログラム開発の初期段階で物理ネットワークが不要になる。

ＡＰＩより下位にユーザ・インタフェースは存在しない。

すべてのユーザ対話は、アプリケーション・プログラム、または資源インタフェ ースを介して要求を実行するコードの責任である。

ユーティリティ コマンド・インタフェースを介してアクセス可能な共通機能を提供することによ って、エンド・ユーザに有用な機能をただちに提供し、新しい協調アプリケーシ ョンを開発するのに必要なプログラミング作業を削減するために、多数の事前に プログラムされたユーティリティが提供されている。

スヘてのユーティリティは交換可能なアプリケーション・プログラムである。提 供したユーティリティの構造を第１３図に示す。供給したユーティリティは、プ ログラム・グループとしてインストールされ、協調する一連のアプリケーション として設計されている。主要なユーティリティ機能は、ユーザが直接呼び出すだ けでなく、”ｓｉｇｎａｌ”コマンドによって他のアプリケーション・プログラ ムから呼び出すこともでアドレス・ブック・ユーティリティ１００によって、エ ンド・ユーザはディレクトリおよび接続性情報を追加し、削除し、更新すること ができる。データは、標準プログラムで容易に編集される簡単なファイル構造に 記憶される。ただし、他の潜在的により広範囲で複雑なアドレス・データベース とのインタフェースをとるための機構が提供されている。ユーザ・データをフォ ーン・ブックという論理集合にグループ化することができる。ユーティリティ・ インタフェースは直接、呼出しマネージャとのインタフェースをとる。また、資 源インタフェースを介して照会に応答する。

ｉｉ）呼出しマネージャ 呼出しマネージャ・ユーティリティ１０１は、呼出しの概念を実施する。呼出し とは、一群のユーザが共用アプリケーションを使用することによって協調するこ とを言う。いつでも複数の呼出しが存在でき、ユーザは複数の同時呼出しに参加 することができ、同じアプリケーションを複数の呼出しで実行することができる 。たとえば、ユーザＡ１Ｂ、Ｃは文書を検討するために呼出しＸに参加すること ができる。すべてのユーザが相互に音声通信を使用することができ、ＡとＢはビ デオ・リンクも、ＡとＣは共用チョークボードも有することもできる。一方、Ａ 、Ｂ、Ｄは第２の文書を検討するために第２の呼出しｙに参加することができる 。ＡとＤはチョークボードを、ＢとＤは音声リンクを使用する。

ＡＰＩには呼出しの概念が存在しないが、アプリケーション共用セットを介して 呼出しマネージャによって実施される。

このサポートを提供することによって、呼出しセットアツプや切断にａｗａｒｅ アプリケーションを関与させる必要がな（なり、呼出し管理とアプリケーション ・プログラミングが明確に分離される。呼出しマネージャは、エンド・ユーザが アドレス・ブックから名前を選択し、分岐呼出しを論理的に確立するためのダイ アログを提供する。パーティを動的に追加し、削除することができる。提供され るオプションは、自動応答および呼出し禁止を含む。ある呼出しが現行活動呼出 しとみなされ、共用アプリケーション・セットは通常、呼び出されるところの呼 出しに追加される。現行活動呼出しは、他の呼出しがセットアツプされている間 は背景に移される。

ｂ）ユーザ・ユーティリティ ｉ）アプリケーション・アシスタント このユーティリティは、呼出し中のユーザのために以下の機能を実施する。

○既存のアプリケーション・ウィンドウをスナップショットとして、または連続 的に直接ミラーリングし、システム・ボインティング・デバイスをリモート・ポ インタとしてイネーブルにする。

○システム・クリップボード・サポート。すなわち、あるノードにあるシステム ・クリップボードの内容を任意選択で他のノードで共用し、あるいは表示する能 力Ｏ異なるノードにあるアプリケーションの間に確立できるリモートＤＤＥリン ク Ｏ他のノードにあるプリンタへの印刷のりダイレクトｉｉ）チョークボード チョークボード１０３は、２つのイメージ・プレーンをもつ共通描画領域を実施 する。この描画領域には、呼出し中のすべてのユーザがアクセスできる。背景プ レーンは、ビットマツプ・ファイル、システム・クリップボード、またはアプリ ケーション・ウィンドウの内容からロードすることができる。前景プレーンは、 一連の簡単なテキストおよびグラフィクス・ツールを使用する対話型注釈に使用 することができる。

チョークボード上のリモート・ポインタもサポートされる。

１ｉｉ）ファイル転送 ファイル転送１０４によって、呼出し中のユーザの間のファイルの送信が可能に なる。１つまたは複数のファイルを転送することができ、ファイルをコメントと 共に送信することができ、元のファイル名を宛先が利用できるようになる。受信 側ノードはファイル受信およびファイル命名を完全に制御メツセージ行１０５は 、呼出し中のユーザの間でテキスト・データを直接共用できるようにする。複数 の同期ユーザが許可され、各参加者はすべての交換されるメツセージを同じシー ケンスで見る。メツセージ・ユーティリティは、呼出しセット・アップおよび終 了、ファイル転送などの、呼出し時の活動も記録する。実際の実施例では、この ユーティリティを呼出しマネージャの一部として提供している。

■）ビデオ／音声リンク このユーティリティ１０６によって、呼出し中のユーザの間にビデオおよび音声 リンクを確立することができる。利用可能な厳密な機能は、物理ネットワークの 機能とワークステーションのハードウェア・サポートによって異なる。

規格 全体的なアーキテクチャは、広範囲の協調アプリケーションをサポートするもの である。インタフェースは、実施できるアプリケーション・モデルの範囲に対し て重大な制限を課さないように、できるだけ高いレベルにセットされている。

関与する透過ネットワークの性質は完全にＡＰＩより下位に隠されている。これ は、アプリケーションがネットワーク経路指定（たとえば直接または間接）と関 与するネットワーク・タイプ（たとえば、単一リンクまたは複数リンク、交換接 続または固定接続）を完全に知っていることを意味する。この手法の結果、たと えば特定の通信サービス品質をめる要求が失敗する恐れがあることを予期してア プリケーションを書かなければならない。なぜなら、基礎ネットワークが必要な 機能を有していないことがあるからである。

サード・パーティ・アプリケーションが他のアプリケーションの代わりに動作す ることを要求できるようにエージェント原理が実施されている。これによって、 呼出しマネージャ°アプリケーション、電話アプリケーション、および交換アプ リケーションを開発することができる。現在の技術の状態では、アナログ・ネッ トワークおよび装置をサポートすべきである。アプリケーションの移行を容易に するために、アナログ・ネットワークをディジタル・ネットワークのように扱う ことが試みられている。

ＡＰＩレベルで、使用される主要概念の１つは、アプリケーション共用セットの 概念である。アプリケーションは、他のアプリケーションと協調するとみなされ 、この協調のための機構は、アプリケーションが、指定された共用セットに相互 に参加することである。そのようなアプリケーション共用セットの肝要な点は、 すべてのセット・メンバが他のすべてのメンバの状況に関する情報を受信するこ とである。セットに参加することは、アプリケーションが関心をもつものを宣言 する方法である。これに対し、呼出しの概念は、ＡＰＩより上位、特に呼出しマ ネージャに存在する。異なる呼出しマネージャが異なる呼出しモデルを有するこ とができる。

アプリケーション共用セットの他に、チャネルもアーキテクチャの基本概念であ る。同報通信と２方向通信を共に効率的にサポートするための基礎通信ビルディ ング・ブロックとして１方向チヤネルを使用している。チャネルは、送信側アプ リケーションによって確立され、受信側アプリケーションによって受け入れられ る。というのは、データをどのように送信すべきかを示すデータの特性を知って いるのは送信側アプリケーションだけだからである。２つのアプリケーションは 共に、それぞれのボートに供給し、あるいは前記ポートから受信すべきフォーマ ットを独立に制御することができる。

各種のデータ・フロー用の複数の論理チャネルによって、サポート・システムは 基礎転送ネットワークにトラフィックを正しく割り振ることができる。さらに、 サポート・システムは、データが、それぞれが別々に記述された別々の同種フロ ーで他のアプリケーションに提供されるようにする。このようにアプリケーショ ン間のトラフィックを別々のデータ・タイプに分割することによって、サポート ・システムはデータ変換機能を提供することができる。

チャネルの接続およびウェルドによって、アプリケーションがもはやデータの移 動に関与しな（なるように、データの転送をＡＰＩより下位にすることができる 。サポート・システムは、場合によっては、そのノードにある非常に低いレベル での接続を有効化するか、フローの経路をそのノードに向かわないように変更す る接続を有効化するかのオプションを有する。

サポート・システム・アーキテクチャは、異なるコンピュータ・プラットフォー ムの間の相互作用を許可し、様々な通信ネットワークを介して動作し、関連する 通信およびデータ規格をサポートするように設計されている。

データ・トラフィックを同種データの論理１方向フローに分けることによって、 混合ネットワーク上へのマツピングが簡単になり、ノードの間で異なる機能の複 数の物理リンクを使用できるようになる。データ多重化は、アプリケーションよ り下位で処理され、基礎転送機構に応じて異なる方法で、たとえば、各論理フロ ーをそれぞれの物理リンクに割り振ることと、サポート層中のすべてのデータを 多重化することを組み合わせ、あるいは多重化の態様を装置ドライバに任せるこ とによって、実施することができる。この手段によって、複数のチャネル、１ｓ ｏ−ＬＡＮまたは１ｓｏ−Ｅｔｈｅｒｎｅｔ　、あるいはＣＣＩＴＴ　Ｈ３２０ 勧告を使用するｌ５ＤＮを介して、音声、ビデオ、およびデータ・トラフィック を送信することができる。サービス品質要件は、必要な転送機能に対して条件を 課す。したがって、音声およびビデオには通常、優先順位および帯域幅管理を伴 う方式を介して実施される、等時機能をもつ専用物理リンクまたは共用リンクが 必要である。

データ構成要素が別々に提供され、該構成要素の性質およびフォーマットが独立 に得られるので、チャネルによって提供される別々の論理データ経路は、該経路 に関連するデータ・タイプと共にアプリケーション間動作を容易にする。サポー ト・システムがネットワークでデータ変換を実行できるため、この機構を介して 、音声、ビデオ、イメージ、ファイル転送、およびコード化データに関する広範 囲の既存の規格をサポートすることができる。システムは、リモート・プリンタ 、カーソル、ジエスチャなどの、協調アプリケーションで一般に使用される対話 オブジェクト用の別々のデータ・クラスも提供する。

ＡＰＩコマンドの概要 以下で、ＡＰＩ呼出しで提供される主要な機能について詳細に説明する。この趣 旨は適用範囲の概要を述べることにすぎないので、実際の呼出しの構文およびパ ラメータについては説明しない。

ＡＰＩ機能要求 セツションおよびアプリケーション共用ｃａｎｃｅｌ　ｒｅｑｕｅｓｔ　：前の 非同期要求がまだ満たされていない場合にその要求を取り消す。

ｄｅｒｅｇｉｓｔｅｒ　ａｐｐ　：アプリケーション・インスタンスによって、 ＡＰＩの使用を終了するために発行される。

１ａｕｎｃｈ　ａｌ）Ｉ）　：あるアプリケーションによって、他のアプリケー ションを呼び出すために発行される。

ｒｅｇｉｓｔｅｒ　ａｐｐ　：　Ｑ行側アプリケーション・インスタンスをワイ ヤとして識別し、アプリケーション事象ハンドラを確立する。

５ｅｔ−ｃａｌｌ　ｍａｎａｇｅｒ　：そのノード用の呼出しマ、ネージャを識 別し、呼出しマネージャ事象ハンドラを確立する。

５ｈａｒｅ　ａｐｐ　：アプリケーション・インスタンスが、あるアプリケーシ ョンと他のアプリケーションの共用を要求するために発行する。

ｓｈｕｔｄｏｗｎ　ｎｏｄｅ　：アプリケーション・インスタンスによって、そ のローカル・ノードにあるサポート・システムの遮断を要求するために発行され る。

ｕｎｓｈａｒｅ　ａｐｐ　：アプリケーション・インスタンスによって、あるア プリケーションと他のアプリケーションの共用を終了するために発行される。

装置およびボート ａｄｄ　ｃｈａｎｎｅｌ　：指定されたアプリケーション・インスタンス中で、 指定された送信側ポートに他のチャネルを追加する。

ｃｈａｎｇｅ　ｃｈａｎｎｅｌ　：指定されたチャネル特性を変更する。

ｃｈａｎｇｅ　ｄｅｖｉｃｅ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定された 装置特性を変更する。

ｃｈａｎｇｅ　ｐｏｒｔ　：指定されたボート特性を変更する。

ｃｌａｉｍ　ｒｅｓｏｕｒｃｅ　：特定のサービス品質に関連する資源の資源マ ネージャに対する呼出し ｃｌｏｓｅ　ｄｅｖｉｃｅ　ｐｏｒｔ　：定義された装置上の関連するボートを クローズする。

ｃｏｎｎｅｃｔ　ｐｏｒｔｓ　：指定された受信側ボートを指定された送信側ボ ートに接続する。

ｃｒｅａｔｅ　ｃｈａｎｎｅｌ　：発行側アプリケーションにある送信側ボート と、指定されたターゲット・アプリケーションにある受信側ポートから成るデー タ送信チャネルを作成する。

ｄｉｓｃｏｎｎｅｃｔ　ｐｏｒｔｓ　：指定された送信側ポートから指定された 受信側ポートを切断する。

ｏｐｅｎ　ｄｅｖｉｃｅ−ｐｏｒｔ　：定義された装置上のボートをオープンす る。

ｒｅｍｏｖｅ　ｃｈａｎｎｅｌ　：指定された受信側ポートと指定された送信側 ボートに関連するチャネルを削除する。

ｒｅｑｕｅｓｔ　ｒｅｓｏｕｒｃｅ　：特定のサービス品質に関連する資源の資 源マネージャに対する照会 ｒｅｓｕｍｅ　ｐｏｒｔ　：指定されたボートを介してデータ送信を再開する。

ｓｉｇｎａｌ　ｐｏｒｔ　：指定されたボートを介して制御文字列を送信する。

５ｕｓｐｅｎｄ−ｐｏｒｔ　：まだ受信されていないデータをドレーンまたはフ ラッシュした後に、指定されたボートを介するデータ送信を中断する。

ｗｅｌｄ　ｃｏｎｎｅｃｔｉｏｎ　：指定された受信側ポートと送信側ポートの 接続を永続的にする。

データ送信および受信 ｒｅｃｅｉｖｅ　ｄａｔａ　：指定された受信側コマンド・ポートからデータを 受信する。

５ｅｎｃｊｄａｔａ　：指定された送信側ボートを介してデータを非同期的に送 信する。様々な送信肯定応答を要求することができる。

ｓｉｇｎａｌ　：サポート・システムが確立した制御チャネルを介して、サポー ト・システムまたはアプリケーションが定義した制御データを、指定されたアプ リケーション・インスタンスに送信する。

ｓｉｇｎａｌ　ａｐｐ　ｗｉｔｈ　ｒｅｐｌｙ：サポート・システムが確立した 制御チャネルを介して、サポート・システムまたはアプリケーションが定義した 制御データを、指定されたアプリケーション・インスタンスに送信し、応答デー タを返す。

５ｔａｒｔ　５ｙｎｃ：指定されたチャネル・セットに関連する受信側ボートを 介して受信されたデータの同期を開始する。

５ｔｏｐ　５ｙｎｃ　：指定されたチャネル・セットに関連するすべての受信側 ボートのデータの同期を停止する。

トークン管理 ｇｅｔ　ｔｏｋｅｎ　＋指定されたグローバル・トークンまたはアプリケーショ ン・トークンをただちに、排他的に保持し、あるいは共用することを要求する。

ｇｉｖｅ−ｔｏｋｅｎ　：指定された要求元に、指定されたｌ・−クンを与える 。

ｑｇｅｔ、ｔｏｋｅｎ　：指定されたグローバル・トークンまたはアプリケーシ ョン・トークンをただちに、排他的に保持し、あるいは共用することを要求し、 トークンが得られない場合は、現所有者が維持している要求待ち行列への参加を 要求する。

ｒｅｃｌａｉｍｊｏｋｅｎ　：指定されたアプリケーション・インスタンスが保 持している指定されたトークンをただちにトークンの現所有者に返すことを強制 する。

ｒｅｆｕｓｅ　ｔｏｋｅｎ　：指定された要求元に、指定されたトークンを与え ることを拒否する。

ｒｅｌｅａｓｅ　ｔｏｋｅｎ　：指定された保持しているトークンを現所有者に 返す。

ｒｅｔｕｒｎ　ｔｏｋｅｎ　：指定されたトークンを保持している指定されたア プリケーションがトークンをできるだけ早く現所有者に返すことを要求する。

ｓｅｔ　ｔｏｋｅｎ　ｏｗｎｅｒ　：指定されたアプリケーション・インスタン スに指定されたトークンの所有者をセットする。

事象制御 ｂｅｇｉｎ　ｍｏｎｉｔｏｒ　：　Ａ　Ｐ　Ｉ呼出しの各オカレンスを識別する 特殊監視事象を発生させ、または指定された監視事象ハンドラに標準事象を提供 する。

ｄｅｆａｕｌｔ　ｅｖｅｎｔ　ｈａｎｃｌｌｅｒ　：アプリケーション・プログ ラムが明示的に処理することを所望しないすべての事象に対してデフォルト応答 を返す。

ｄｉｓａｂｌｅ　ｅｖｅｎｔｓ　：指定された事象クラスの事象が発行側アプリ ケーション・インスタンスの事象ハンドラに渡されるのを停止する。

ｅｎａｂｌｅ　ｅｖｅｎｔｓ　：指定された事象クラスの事象が発行側アプリケ ーション・インスタンスの事象ハンドラに渡されるようにする。

ｅｎｄ　ｍｏｎｉｔｏｒ　：　Ａ　Ｐ　Ｉ呼出しの各オカレンスを識別する特殊 監視事象、または提供中の標準事象を停止する。

プロファイル管理 ｒｅａｄ　ｐｒｏｆｉｌｅ　ｓｔｒｉｎｇ　：プロファイル・ファイルの指定さ れたセクション中の指定されたキーワードの文字列を返す。

ｗｔｒｉｔｅ−ｐｒｏｆｉｌｅ　ｓｔｒｉｎｇ　：プロファイル・ファイルの指 定されたセクション中の指定されたキーワードに文字列をコピーする。

ＡＰＩ照会 ｑｕｅｒｙ　ａｄｄｒｅｓｓ　：指定された共用セットに属するアプリケーショ ン・インスタンスの完全なフル・アドレスを返す。

ｑｕｅｒｙ　ａｐｐｌｉｃａｔｉｏｎ　５ｔａｔｕｓ　：アプリケーションの状 況（ｕｎａｗａｒｅ　１ａｗａｒｅ　、または呼出しマネージャ）を返す。

ｑｕｅｒｙ　ｃｈａｎｎｅｌ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定された 送信側ボートおよび受信側ボートに関連するチャネルのチャネル特性を返す。

ｑｕｅｒｙ−ｃｈａｎｎｅｌ　ｓｅｔ　：指定されたチャネル・セット中のすべ てのポートのハンドルを返す。

ｑｕｅｒｙ　ｄｅｖｉｃｅ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定された装 置の装置特性を返す。

ｑｕｅｒｙ−ｄｅｖｉｃｅ　５ｔａｔｕｓ　：指定された装置の状況を返す。

ｑｕｅｒｙ　ｍｏｎｉｔｏｒ　：　Ｅ’Ａ在モニタ事象ハンドラに渡されている 機能または事象のクラスを返す。

ｑｕｅｒｙ　ｐｏｒｔ　ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ　：指定されたポート の特性を返す。

ｑｕｅｒｙ　ｐｏｒｔ　５ｔａｔｕｓ　：指定されたボートの状況を返す。

ｑｕｅｒｙ　ｒｅｓｏｕｒｃｅ　：指定された資源セット中で利用可能な資源を 返す。

ｑｕｅｒｙ　ｓｈａｒｉｎｇ　ｓｅｔ　：アプリケーション・インスタンス用の 共用セット識別子を返す。

ｑｕｅｒｙ　ｔｏｋｅｎ　ｈｏｌｄｅｒ　：　トークンの所有者（アプリケーシ ョン・トークンのみ）および保持者を返す。

ｑｕｅｒｙ　ｔｏｋｅｎ　５ｔａｔｅ　：指定されたトークンの状態を返す。

ＡＰＩ事象 呼出しマネージャ事象 ＡＰＰ　ＤＥＲＥＧＩＳＴＥＲＥＤ　：アプリケーション・インスタンスがＡＰ Ｉの使用を終了するときの、ローカル呼出しマネージャへの事象。

ＡＰＰ　ＲＥＧＩＳＴＥＲＥＤ　：アプリケーションがＡＰＩの使用を初期設定 するときの、ローカル呼出しマネージャへの事象ＣＡＬＬ　ＭＡＮＡＧＥＲ−Ｅ ＲＲＯＲ：呼出しマネージャに影響を及ぼすエラーが発生した。

ＣＡＬＬ　ＭＡＮＡＧＥＲＲＥＱＵＥＳＴ　：他のローカル・アプリケーション がｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ機能要求を発行したことを示す、ローカル 呼出しマネージャへの事象 Ｎ０ＤＥ　５ＨＵＴＤＯＷＮ　ＲＥＱＵＥＳＴ　：サポート・システムの遮断を める要求 ＰＡＳＳＩＶＥ　Ｎ０ＤＥ−ＲＥＬＥＡＳＥＤ　：ノードが受動要求をサポート できるようにするために割り振られた資源の解除をめる指示。

ＰＡＳＳＩＶＥ　Ｎ０ＤＥ−ＲＥＱＵＥＳＴ　：　／−ドが受動要求をサポート スルタめに資源を割り振ることをめる要求 ５ＨＡＲＥ　ＲＥＱＬＩＥＳＴ　：指定されたアプリケーションとの共用をめる 要求 ＴＯＫＥＮ　５ＴＡＴＵＳ−ＲＥＱＵＥＳＴ　ニゲローバル・トークンの状況を める要求 アプリケーション事象 ＡＰＰ　５ＩＧＮＡＬ　：信号が受信された。

ＡＰＰ　５ＩＧＮＡＬ　ＲＥＪＥＣＴＥＤ　：信号が拒否された。

ＡＰｊＳＩＧＮＡＬ−ＷＩＴＨＲＥＰＬＹ　：　ｓｉｇｎａｌ　ｗｉｔｈ　ｒｅ ｐｌｙが受信された。

ＡＰＰ　５ＩＧＮＡＬ　ＴＲＡＮＳＦＥＲＲＥＤ　：信号が転送された。

ＡＰｊＵＮＳＨＡＲＥ−ＲＥＱＵＥＳＴ　：受信側がアプリケーション共用セッ トを抜けることをサード・パーティ・アプリケーションが要求した。

ＡＰＰ　ＵＮＳＨＡＲＥＤ　：発行側がアプリケーション共用セットを抜けると いう通知が受信された。

ＡＰＰ−ＥＲＲＯＲ：関連アプリケーション・エラーが検出された。

Ｎ０ＤＥ−ＳＨＵＴＤＯＷＮ　：遮断が開始された。

ＰＯＲＴ−ＲＥＭＯＶＥＤ　：ボートが削除されたことの確認ＰＯＲＴ−ＲＥＱ ＵＥＳＴ　：受信側ポートの追加をめる要求ＲＥＳＯＵＲＣＥ−ＣＬＡＩＭ　： アプリケーションがサービス品質資源を請求すると必ずレイズされる。

ＲＥＳＯＵＲＣＥ　ＲＥＱＵＥＳＴ　：アプリケーションがサービス品質資源を 要求すると必ずレイズされる。

ＰＲＯＦＩＬＥ　ＣＨＡＮＧＥＤ　：　ＬＡＫＥＳ、　ＩＮＩファイルまたはＬ ＡＫＥＳＱＯ５，ＩＮＩファイルの変更をめる指示 ＳＨＡＲＥ−ＣＯＮＦＩＲＭＥＤ　：共用要求が処理されたことの確認が受信さ れた。

５ＨＡＲＩＩ、ＲＥＪＥＣ：ＴＥＤ　：共用要求が拒否された。

５ＨＡＲＩＩ、ＲＥＱＵＥＳＴ　：共用要求が受信された。

５ＨＡＲＥ　ＴＲＡＮＳＦＥＲＲＥＤ　：共用要求が転送された。

ＴＯＫＥＮ　ＣＡＮＣＥＬ　ＲＥＱＵＥＳＴ　：待機中のトークン要求の取消し をめる要求が受信された。

ＴＯＫＥＮ−ＧＩＶＥＮ　：要求元にトークンが与えられた。

ＴＯＫＥＮ−ＱＲＥＱＵＥＳＴ　：　）−クンを保持し、あるいはトークンが得 られない場合は待ち行列に参加することをめる要求ＴＯＫＥＮ　ＲＥＣＬＡＩＭ ＥＤ　：　トークンが所有者によって取り去られた。

ＴＯＫＥＮ　ＲＥＣＬＡＩＭＥＤ　ニド−クンが所有者によって取り去られた。

ＴＯＫＥＮ　ＲＥＦＵＳＥＤ　：　トークンをめる要求が拒否された。

ＴＯＫＥＮ　ＲＥＱｔＪＥＳＴ　ニド−クンの保持をめる要求ＴＯＫＥＮ　ＲＥ ＴＵＲＮ−ＲＥＱＵＥＳＴ　：　トークンの所有者が、トークンをできるだけ早 （返すことを要求している。

装置事象およびポート事象 ＣＨＡＮＮＥＬ　ＣＨＡＮＧＥＤ　ニ一部のチャネル特性が変更された。

ＣＨＡＮＮＥＬ　ＧＯＮＦＩＲＭＥＤ　：新しいチャネルが作成された。

ＣＨＡＮＮＥＬ　ＤＥＳＴＲＯＹＥＤ　：チャネルが破壊された。

ＣＨＡＮＮＥＬ　ＲＥＪＥＣＴＥＤ　：チャネルが作成されなかった。

Ｃ０ＮＮＥＣＴｌ０Ｎ　ＷＥＬＤＥＤ　：ウエル接続通知が受信された。

ＤＡＴＡ　ＡＶＡＩＬＡＢＬＥ　：受信側ボートでデータが利用可能である。

ＤＡＴＡ−ＣＯＮＦＩＲＭＥＤ　：データ送信の確認またはデータ送信の進行の 推定が受信された。

ＤＡＴＡ　ＲＥＱＵＥＳＴＥＤ　：送信側ポートからデータが要求されている。

ＤＥＶＩＣＥ　ＩＮＦＯＲＭＡＴＩＯＮ　：装置情報を供給する予定のアプリケ ーション・インスタンスの送信側ポート事象ハンドラにレイズされる事象 ＰＯＲＴ　ＥＲＲＯＲ：ボート・エラーが検出された。

ＰＯＲＴ　ＲＥＳＵＭＥ　ＲＥＱＵＥＳＴ　：ボート再開要求が受信された。

ＰＯＲＴ　５ＩＧＮＡＬＬＥＤ　：信号ポート事象が受信された。

ＰＯＲＴ　５ＵＳＰＥＮＩ）−ＲＥＱＵＥＳＴ　：ボート中断要求が受信された 。

ＰＯＲＴ　５ＹＮＣＲＥＱＵＥＳＴ　：同期制御の調整をめる要求が受信された 。

モニタ制御事象 ＥＶＥＮＴ　ＭＯＮＩＴＯＲＥＤ　二機能要求および事象活動の通知が受信され た。

チャネル、ポート、およびリンクの特性チャネルの特性 以下のパラメータは、チャネルと関連しており、ｃｒｅａｔｅ−ｃｈａｎｎｅｌ 要求およびａｄｄ　ｃｈａｎｎｅｌ要求で設定される。

ｑｕａｌｉｔｙ　ｏｆ　５ｅｒｖｉｃｅ　：信号タイプ（アナログまたはディジ タル）スループット 待ち時間 ジッタ 遅延 優先順位 サービス品質特性は、ＬＡＫＥＳＱＯ３，ＩＮＩファイル中のデータ・タイプお よびサブタイプを介して関連付けられるが、明示的に指定することができる。こ の特性は、未定義のままにすることができる。これによって、データがチャネル を介して送信されるときに、動作特性が、利用可能な資源に依存するチャネルを 作成することができる。

ｃｈａｎｎｅｌ　ｔｙｐｅ　： 標準 同期 以下のパラメータは、ポートと関連している。ポート・タイプを除くすべてのパ ラメータは明示的に定義される。送信側ボートは、ｃｒｅａｔｅ　ｃｈａｎｎｅ ｌ要求でこれらのパラメータを指定し、受信側ボートはＰＯＲＴ　ＲＥＱＵＥＳ Ｔ応答でこれらのパラメータを指定する。

ｃｏｎｎｅｃｔ　ｔｙｐｅ　： コマンド 事象 空 ｅｖｅｎｔ　ｈａｎｄｌｅｒ　： ｐｏｒｔ　ｔｙｐｅ　： 送信 受信 リンクの特性 以下のサービス品質パラメータは、物理リンクに関連しており、リンク・ロケー タを介してアクセスされるデータベースに指定するか、あるいはデフォルトとし てＬＡＫＥＳＱＯ３，ＩＮＩファイルから得られる。

信号タイプ（アナログまたはディジタル）スループット 待ち時間 ジッタ フレーム再送信時間 圧縮ヒント 暗号化 サポート・システム構造 再び、第１０図に示したサポート・システム構造を参照して、該構造の構成要素 の様々なタスクについて詳細に説明する。アプリケーション・マネージャ２２３ は、サポート・システムの残りとのインタフェースとして働き、ある程度のパラ メータ検証の後に適切な構成要素に分散されるすべてのＡＰＩ呼出し用の入口点 を提供する。監視が必要な場合（以下参照）、アプリケーション・マネージャ２ ２３は着信呼出し／発信事象の走査にも使用される。

アプリケーション・マネージャ２２３は、チャネルの作成時に指定された事象ハ ンドラでアプリケーションをコール・バックする責任を負う。事象は、ローカル ・アプリケーションがチャネルを作成した場合は送信側ボートで、あるいは次い でリモート・アプリケーションがチャネルを作成した場合は受信側ポートでレイ ズされるものである。アプリケーション・マネージャ２２３は、ボートを作成す る際に、特定のアプリケーションのためのすべての事象を処理し待ち行列に入れ る事象待機ハンドラのアドレスを渡す。次いで、事象を連続的に読み取るディス パッチ・スレッドなどのある種の機構がアプリケーションの事象ハンドラに事象 を送信する。

チャネル・マネージャ２２７は、他のすべての構成要素を始動し遮断する責任を 負うチャネル・スーパバイザと、異なるノードにあるサポート・システムの間の 制御チャネル通信を処理する制御チャネル副構成要素と、他のすべての非制御チ ャネル・データ通信を処理するデータ・チャネル副構成要素と、ノード・ハンド ルおよび数組のノード・ハンドルを作成し、破壊し、維持するノード・マネージ ャと、ボートを作成し、破壊し、操作し、ボート照会機能を実行するボート・マ ネージャの５つの副構成要素を有する。

資源マネージャ２２５は、サポート・システムで第１に制御を得る構成要素であ る。資源マネージャ２２５は、他のすべての構成要素を初期設定し、かつアドレ ス・ブックまたは経路選択機能とのインタフェースをとる責任を負う。トークン ・マネージャ２２４は、名前から分かるように、グローバル°トークンとアプリ ケーション・トークン（グローバル・トークンはそれぞれの呼出しマネージャ構 成要素によって所有され、これに対し、アプリケーション・トークンは共用セッ ト中のノードによって所有される）とのロギングおよび管理に責任を負う。

装置マネージャ２２４は、サポート・システムと装置の間の対話に責任を負い、 特に、装置名を完全修飾経路などに変形すること、適切な動的リンク・ライブラ リ（ＤＬＬ）のロード、ボート番号、ボート・ハンドラ、および事象ワードを含 む記録の生成、初期設定入口点の呼出し、ＤＬＬ中のすべての項目ハンドルをア プリケーション呼出しマネージャ用の物理アドレスに変形することなどの機能を 実行する。信号マネージャ２２６は、アプリケーション（応答の有無にかかわら ない）およびボートに発信する責任を負う。

共用呼出しマネージャの導入 協調サポート・システムの全体的な動作について説明したので、ここで、様々な 共用呼出しマネージャ・セットアツプ動作について詳細に説明する。呼出しマネ ージャを確立するＡＰＩコマンドはｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒである。

ｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ関数は、発行元を発行側ノードでの新しい呼 出しマネージャとして確立することを要求し、呼出しマネージャ事象のために呼 び出すべき事象ハンドラを識別する。

ｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ関数が必要とするパラメータは以下のとおり である。

ｅｖｅｎｔ　ｈａｎｄｌｅｒ　呼出しマネージャ事象のために呼び出すべき事象 ハンドラ ｅｖｅｎｊｗｏｒｄ　すべての呼出しマネージャ事象上で呼出しマネージャ事象 ハンドラに渡されるユーザ指定データ・ポインタ ｃａｌｌ　ｍａｎａｇｅｒ　１ｎｆｏ　（返される）ＳＥＴＣΔＬＬ　ＭＡＮＡ ＧＥＲ事象に応答して現呼出しマネージャが返す値 ｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ（）関数は、非アプリケーション特有性の事 象、すなわち、特有のアプリケーション・インスタンスを識別しないネットワー クからの着信事象を受信する予定の事象ハンドラをサブシステムに対して識別す る（注：この事象は宛先アプリケーション名を指定することができ、この場合、 名前を特定のインスタンスに帰着させるのは呼出しマネージャの機能である）。

どの所与のノードでもある一時点で活動状況になることができる５ｅｔ−ｃａｌ ｌ　ｍａｎａｇｅｒ□は１つだけである。所与のノードで作動するアプリケーシ ョンによって複数のｓｅｊｃａｌｌ−ｍａｎａｇｅｒＯを発行することができる が、最後に発行されたものが有効になる（すなわち、そのアプリケーション・イ ンスタンスがそのノード用の呼出しマネージャである）。

アプリケーションは、ｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ□関数呼出しを発行す る前に、ｒｅｇｉｓｔｅｒ　ａｐｐＯ関数呼出しを発行してアプリケーション自 体をローカル・システムに対して識別しておかなければならない。

新しいアプリケーションがｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒ□関数呼出しを発 行するとき、処理は、呼出しマネージャがすでに存在しているかどうかに依存す る。

呼出しマネージャが存在しない場合、事象はレイズされず、発行元が現呼出しマ ネージャになる。

呼出しマネージャがすでに存在する場合、その呼出しマネージャがＳＥＴ　ＣＡ ＬＬ　ＭＡＮＡＧＥＲ事象を受信する。この既存の呼出しマネージャは、呼出し マネージャ機能の新しいアプリケーションへの転送を許可するか、要求を拒否す るかのオプションを有する。この場合、既存の呼出しマネージャがそのまま制御 を取り、発行元はＲＣ−ＣＭ−ＲＥＱＵＥＳＴ−ＲＥＪＥＣＴＥＤ戻リコードを 受信する。これによって、アプリケーションが呼出しマネージャになるために許 可されるある種の制御が可能になる。

ｓｅｔ　ｃａｌｌ　ｍａｎａｇｅｒを発行したアプリケーション・インスタンス は常に走行していなければならない。そうでない場合、他のどのノードとも通信 を行うことはできない。

ＬＡＫＥＳ、　ＩＮＩファイルは、呼出しマネージャになることを許可されたア プリケーションの名前を指定するセクションを有することができる。このため、 現呼出しマネージャでＳＥＴ　ＣＡＬＬＭＡＮＡＧＥＲ事象がレイズされると、 呼出しマネージャは、アプリケーションが許可されているかどうかを調べるため に、ｇｅｔ　ｐｒｏｆｉｌｅ　ｓｔｒｉｎｇ関数呼出しを介してこのファイルを 検査する。

ｒｅｇｉｓｔｅｒ　ａｐｐ関数は、発行側アプリケーション・インスタンスの名 前と、着信事象を処理する事象ハンドラを登録する。

必要とされるパラメータは以下のとおりである。

ａｐｐｌｉｃａｔｉｏｎ　ｎａｍｅ　システムが発行側アプリケーションを知る ための名前 ｅｖｅｎｔ−ｈａｎｄｌｅｒ　発行側アプリケーション・インスタンスのために 着信事象を処理する、システムが呼び出すべき事象ハンドラのアドレス ｅｖｅｎｔ　ｗｏｒｄ　すべての呼出しマネージャ事象上で呼出しマネージャ事 象ハンドラに渡されるユーザ指定データ・ポインタ ｎｏｄｅ　ｈａｎｄｌｅ　（返される）発行側ノードのノード・ハンドル ａｐｐｌｉｃａｔｉｏｎ−ｈａｎｄｌｅ　（返される）発行側アプリケーション のアプリケーション・インスタンス・ハンドルアプリケーション・インスタンス がシステムとの通信の許可を得るには、ｒｅｇｉｓｔｅｒ　ａｐｐ呼出しを発行 することによってアプリケーション・インスタンス自体を識別しなければならな い。この呼出しは、このインスタンスからの他のどの呼出しよりも前に発行しな ければならない。そうでない場合、呼出しは失敗し、エラー・コードが返される 。

ａｐｐｌｉｃａｔｉｏｎ　ｎａｍｅ、　ｅｖｅｎｔ　ｈａｎｄｉｅｒ、およびｅ ｖｅｎｔ　ｗｏｒｄを供給しなければならない。ｎｏｄｅ　ｈａｎｄｌｅおよび ａｐｐｌｉｃａｔｉｏｎ−ｈａｎｄｌｅはシステムによって返される。これらは 、ノード内で特有のハンドルを定義し、ローカル・ノード外では有効範囲や意味 をもたない。

ｒｅｇｉｓｔｅｒ　ａｐｐ関数呼出しの結果、呼出しマネージャ事象ハンドラが 存在する場合は該ハンドラでＡＰＰＲＥＧＩＳＴＥＲ事象がレイズされる。呼出 しマネージャが存在しない場合、事象はレイズされず、ｒｅｇｉｓｔｅｒ−ａｐ ｐ関数呼出しの発行元は戻りコードＲＣＮｏ　ＣＡＬＬ　ＭＡＮＡＧＥＲを受信 する。発行元は次いで、ｓｅｔ　ｃａｌｌｍａｎａｇｅｒ　Ｏ関数呼出しを発行 することによって呼出しマネージャになり、あるいはｄｅｒｅｇｉｓｔｅｒ　ａ ｐｐ□関数呼出しを発行することによって終了すべきである。

これは、５ｅｔ−ｃａＨｍａｎａｇｅｒ□が発行される前、すなわち、有効な呼 出しマネージャが識別される前に有効な唯一の関数呼出しである。

１ａｕｎｃｈ関数によって、指定されたターゲット・アプリケーションが呼び出 される。

必要とされるパラメータは以下のとおりである。

ｔａｒｇｅｔ　ａｐｐｌｉｃａｔｉｏｎ　ターゲット・アドレスの完全アドレス を含む構造を指すポインタ。完全アドレス構造タイプは以下のように定義される 。

ｔａｒｇｅｔ　ｅｘｅ　ｓｔｒｉｎｇ　ターゲット・アプリケーションの実行可 能ファイルの完全修飾基（完全経路を含む）を指定する文字列を指すポインタ ｗ□ｒｋｉｎｇ−ｄｉｒｅｃｔｏｒｙ　ディレクトリを指定する文字列を指すポ インタ。ｗｏｒｋｉｎｇ−ｄｉｒｅｃｔｏｒｙが空の場合、カレント・ディレク トリが仮定される。

ｐａｒａｍｅｔｅｒｓ　ローンチされたアプリケーションに与えられるユーザ指 定文字列 ａｐｐｌｉｃａｔｉｏｎ　ｈａｎｄｌｅ　（返される）ローンチされたアプリケ ーションのアプリケーション・インスタンス・ハンドルこの関数は、他のアプリ ケーション・インスタンスの開始をシステムに要求するために使用される。新し いアプリケーションが正常に起動すると、ｔａｒｇｅｔ−ａｐｐｌｉｃａｔｉｏ ｎにアプリケーション・ハンドルが挿入され、呼出し側アプリケーションに返さ れる。

ｒｅｇｉｓｔｅｒ　ａｐｐを使用して自己をシステムに対して完全に識別するこ とは、ローンチされたアプリケーションの責任である（該アプリケーションがａ ｗａｒｅアプリケーションになる予定の場合）。１ａｕｎｃｈはどのａｗａｒｅ アプリケーションでも発行することができ、現行の活動呼出しマネージャだけに 制限されない。

５ｈａｒｅ関数は、指定されたターゲット・アプリケーションが、指定された発 信元アプリケーションと共用を行うことを要求する。

必要とされるパラメータは以下のとおりである。

ａｓｙｎｃ　ｉｄ　この呼出しと、それに関係するすべての事象を識別するため のユーザ指定参照ｉｄ０このパラメータをゼロにすることはできない。

５ｏｕｒｃｅ　ａｐｐｌｉｃａｔｉｏｎ　発信元アプリケーションの完全アドレ スを含む構造を指すポインタ ｔａｒｇｅｔ　ａｐｐｌｉｃａｔｉｏｎ　ターゲット・アプリケーションの完全 アドレスを含む構造を指すポインタ ｕｓｅｒ　１ｎｆｏ　この共用によって生成されるすべての事象上で返されるユ ーザ指定文字列 可能性のある戻りコードは以下のとおりである。

ＲＣＯＫ　動作が首尾よく完了した。

ＲＣＦＡＩＬ　ＬＡＫＥＳ環境が確立されなかった。

ＲＣ５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤ　共用が受け入れられたことを確認するだ めに同期５ｈａｒｅ□に返される。

ＲＣ５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ　共用が拒否されたことを確認するために非 同期５ｈａｒｅＯに返される。

ＲＣＩＮＶＡＬＩＤ　ＡＤＤＲＥＳＳ　無効ナアドレス構造５ｈａｒｅ関数は、 発信元アプリケーションとターゲット・アプリケーションが「アプリケーション ・セット」になる（または「アプリケーション・セット」に追加される）ことを 要求する。

ターゲット・アプリケーションを名前で指定する場合、関連するノードにある呼 出しマネージャが呼び出され、次いで、共用要求をどのように処理するかを決定 するのは、ターゲット・ノードにある呼出しマネージャの責任になる。

ターゲット・アプリケーションをインスタンス・ハンドルで指定する場合、共用 要求は、所望のアプリケーションに直接波され、呼出しマネージャを介さない。

ｕｓｅｒ　１ｎｆｏパラメータは通常、アプリケーションをなぜ、またはどのよ うに使用するかをノードに通知するために使用すべきである。

適切な戻りコード（Ｒ（、ＳＨＡＲＥ−ＣＯＮＦＩＲＭＥＤまたはＲＣ５ＨＡＲ Ｅ−ＲＥＪＥＣＴＥＤ）が返される。ローカル・システムがその後、ターゲット ・アプリケーションから５ＨＡＥＲＥ　ＣＯＮＦＩＲＭＥＤ事象を受信した場合 、この事象は５ｈａｒｅ関数呼出しの発行元にレイズされず、適切なＵＮＳＨＡ ＲＥ事象を生成するシステムによって処理される。ローカル・システムがその後 、ターゲット・アプリケーションから５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ事象を受信 した場合、この事象は無視される。

ハンドルではなくアプリケーション名を指定する共用要求は、呼出しマネージャ に送られる。これによって、呼出しマネージャは５ｈａｒｅをどのように扱うか を決定することができる。

たとえば、呼出しマネージャは以下のことを行うことができる。

○指定されたアプリケーションをローンチし、それによって新しいインスタンス を作成する。

Ｏ完全に異なるアプリケーションをローンチする。

○５ｈａｒｅを既存のインスタンスに送る。

○５ｈａｒｅを異なるインスタンスにリダイレクトする。

○５ｈａｒｅを完全に呼出しマネージャ内で処理する。

呼出しマネージャは、５ＨＡＲＥ　ＲＥＱＵＥＳＴ事象の結果としてアプリケー ションのローンチを発行した場合、最初の要求元に代わって、ローンチされたア プリケーションに共用要求を再発行しなければならない。

ｕｎｓｈａｒｅ関数は、共用セット中の発信元アプリケーションと当該アプリケ ーションの間の共用を終了する。

必要とされるパラメータは以下のとおりである。

ａｓｙｎｃ　ｉｄ　この呼出しと、それに関係するすべての事象を識別するため のユーザ供給参照１ｄ。このパラメータをゼロにすることはできない。

５ｏｕｒｃｅ　ａｐｐｌｉｃａｔｉｏｎ　発信元アプリケーションの完全アドレ スを含む構造を指すポインタ。類アドレス構造は以下のように定義される。

ｕｓｅｒ　１ｎｆｏ　このｕｎｓｈａｒｅによって生成された事象上の共用セッ トに残っているすべてのアプリケーション・インスタンスに返されるユーザ指定 文字列 この関数は、共用アプリケーション・セットからアプリケーション・インスタン スを削除するために使用され、アプリケーションを終了しない。セット中の他の すべてのアプリケーションは、このインスタンスがもはや共用セットの一部でな いことを示す事象を受信する。

ｕｓｅｒ　１ｎｆｏパラメータは、なぜｕｎｓｈａｒｅを実行するかをアプリケ ーション中の他のインスタンスに通知するために使用すべきである。

インスタンスが所有するボートは消去され、論理チャネルの他方の端で事象がレ イズされる。

ｒｅｇｉｓｔｅｒ　ａｐｐによる事象ハンドラ・セットアツプは依然として活動 状況であり、システムまたは呼出しマネージャを介して逼られる事象を受信する 。

共用の制御の典型的なフローを第１４図に示す。ターゲット・アプリケーション の名前だけが指定され、そのハンドルは指定されない共用要求の場合、最初に、 ターゲット・ノードにある呼出しマネージャで５ＨＡＲＥ　ＲＥＱＵＥＳＴ事象 がレイズされる。ターゲット・アプリケーションのハンドルが指定された共用要 求の場合、ターゲット・アプリケーションで直接５ＨＡＲＥ　ＲＥＱＵＥＳＴ事 象がレイズされる。

ステップ１で　アプリケーションＸが、アプリケーションＹとの共用を開始する ための非同期要求を発行する。要求ではＹの文字列アドレスだけしか指定されな かったので、Ｙのノード、ノード２にある呼出しマネージャに５ＨＡＲＥ　ＲＥ ＱＵＥＳＴがレイズされる。

ステップ２で　Ｙの呼出しマネージャは多数のオプションを有する。該呼出しマ ネージャは、共用要求を拒否するＣＲＣ５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ）ことも 、共用要求自体を満たす（ＲＣ，、−５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤ）ことも 、共用要求をアプリケーションＹの新しいインスタンスに渡す（ＲＣ５ＨＡＲＥ −ＮＯＣＯＮＦＩＲＭ）こともできる。

ステップ３で　呼出しマネージャがＲＣ５ＨＡＲＥ　ＲＥＪＥ（１；ＴＥＤまた はＲＣ５ＨＡＲＥ　ＣＯＮＦＴＲＭＥＤを返した場合、サブシステムは要求元で ５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ事象または５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤ事象 をレイズする。

ステップ４で　ターゲット・アプリケーションとしてＹを指定する１ａｕｎｃｈ 関数呼出しを呼出しマネージャが発行した場合、Ｙの新しいインスタンスが始動 される。サブシステムは、Ｙ用のアプリケーション・ハンドルを割り振り、呼出 しマネージャに返す。Ｙは、始動された後、ａｗａｒｅになることを所望し、し たがってそれ自体をサブシステムに対して識別するｒｅｇｉｓｔｅｒ　ａｐｐ関 数呼出しを発行する、と仮定される。サブシステムは、ローンチ時に割り振った ハンドルをＹに返す。

ステップ５で　ｒｅｇｉｓｔｅｒ　ａｐｐの結果、サブシステムはノード２の呼 出しマネージャにＡＰＰ　ＲＥＧＩＳＴＥＲＥＤ事象をレイズする。

ステップ６で　ノード２の呼出しマネージャは次いで、Ｘに代わって、Ｙのハン ドルを指定する共用要求を発行し、ＲＣ−〇にでリターンする。

ステップ７で　アプリケーションＹは次いで、Ｘを要求元として識別する５ＨＡ ＲＥ　ＲＥＱＵＥＳＴ事象を受信する。Ｙは次いで、共用を拒否しくＲＣ５ＨＡ ＲＥ　ＲＥＪＥＣＴＥＤ）　、あるいは受け入れる（ＲＣ−５ＨＡＲＥ　ＣＯＮ ＦＩＲＭＥＤ）ことができる。

ステップ８で　Ｘは適切な５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ事象または５ＨＡＲＥ 　ＣＯＮＦＩＲＭＥＤ事象を受信する。

ステップ９で　共用が受け入れられ、Ｘが他のアプリケーションとも共用を行っ ている場合、ノード１にあるサブシステムは、Ｘを発信元、Ｙをターゲットとし て指定し、Ｙを新規共用者としても指定する５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤ事 象をこれらすべてのアプリケーションに送信する。すると、これらのアプリケー ションが作動しているノードにあるサブシステムが、Ｘを発信元、Ｙをターゲッ ト、ＸおよびＹ自体を新規共用者として指定する５ＨＡＲＥ　ＣＯＮＦＩＲＭＥ Ｄ事象をＹに送信する。

最後にステップ１０で　Ｘは後で、共用セットを抜けるためにｕｎｓｈａｒｅ　 Ｏを発行することができる。セット中の残りのアプリケーションもすべて、ＵＮ ＳＨＡＲＥ事象を受信する。

呼出しマネージャは、ワークステーションにあるサブシステムの動作またはパー ソナリティを判定する上で主要な役割を果たす。ここで、サブシステムに供給さ れた呼出しマネージャ・ユーティリティ１０１　（第１３図）について詳細に説 明する。

供給された呼出しマネージャ・ユーティリティによって、呼出し管理とアプリケ ーション・プリミティブを明確に分離することができる。したがって、付属の呼 出しマネージャを使用すると、ａｗａｒｅアプリケーションが呼出しのセットア ツプまたはテアダウンに関与する必要はなくなる。この呼出しマネージャは、ユ ーザがアドレス・ブックから名前を選択し、分岐呼出しを論理的に確立するため のダイアログを提供する。

セットにパーティを追加することができ、パーティはセットを動的に抜けること ができ、いくつかの呼出しが同時に進行することができる。提供されたオプショ ンは、自動応答と呼出し禁止を含む。

呼出しマネージャのルック・アンド・フィールを機能から分離するために、呼出 しマネージャは実際には、エンジンおよびユーザ・インタフェースの２つの別々 のプログラムとして実施される。エンジンは、呼出し管理機能を提供し、ユーザ ・インタフェースはルック・アンド・フィールを決定する。

呼出しマネージャ・エンジンは、それを他のアプリケーションが制御できるよう にするコマンド・インタフェースを有する（実際には、これは、ユーザ・インタ フェース部分がエンジンをどのように制御するかということである）。エンジン は、現在作動中の各ローカル・アプリケーション・インスタンスごとのアプリケ ーション・テーブルと、各呼出しごとの呼出しテーブルと、現在コマンド共用セ ットにある（したがって、エンジンにコマンドを送信する資格がある）各アプリ ケーションごとのコマンド・テーブルと、現在有効な各受動リンクをリストする リンク・テーブルとを維持する。

供給された呼出しマネージャ・ユーティリティ呼出しマネージャによって、ユー ザは以下のアクションを開始することができる。

Ｏ新しい呼出しを開始する（ノードは、それぞれがそれ自体の１組の共用アプリ ケーションおよびその他のパーティを含むいくつかの呼出しに携わることができ ることに留意されたい） Ｏ既存の非共用アプリケーションを呼出しに追加する。

○呼出し中の既存のアプリケーションの共用を終了する。

Ｏ新しい人を追加することによって呼出しを拡張する（呼出し先が受け入れる場 合、呼出し内の現アプリケーションは呼出し先に共用される）。

Ｏ呼出しを抜ける（この場合、共用アプリケーションは引き続き作動するが、も はや共用セットの一部ではな（なる）○システムを遮断する（すべての現行呼出 しが終了し、遮断プロセスの一部としてすべてのアプリケーションが基本的にｕ ｎａｗａｒｅになる） ○アプリケーションをローンチする。

○呼出し先が応答しない場合に発信要求を取り消す。

ユーザは、たとえば、着信呼出しを自動的に受け入れるか拒否するか、受動作業 の要求をどのように処理すべきか、を示す様々なオプションをセットすることも できる。

第１５図に示すように、呼出しマネージャ・ユーザ・インタフェースは、アクシ ョン・バーおよびクライアント領域を備えたメイン・ウィンドウから構成される 。クライアント領域は、メツセージおよびその他の状況情報と、メニュー・プル ダウン用の文脈対応プロンプトを表示する情報領域を含む。

アクション・バーは、以下のオプションを提供する。

○Ｃａ１ｌ ○Ｎｅｗ　新しい呼出しを開始する。

○Ａｄｄ　呼出しに人を追加する。

ＱＨａｎｇ　Ｕｐ　現行呼出しを終了する。

０Ｃａｃｅｌ　ＡｄｄまたはＮｅｗを取り消す。

ＱＳｈｕｔｄｏｗｎ　呼出しマネージャ（およびすべての呼出し）○５ｈａｒｅ 　現行呼出しに既存の非共用アプリケーションを追加する。

○Ｕｎｓｈａｒｅ　現行呼出し中の既存のアプリケーションの共用を終了する。

○Ｌａｕｎｃｈ　新しいアプリケーションをローンチする。

○０ｐｔｉｏｎｓ ○ΔＵｔＯ応答が自動的に受け入れられる。

○Ｐａ５ｓｉｖｅ　この機械を他のユーザによるゲートウェイとして使用できる かどうか ＱＳｏｕｎｄ　ティックされた場合、着信呼出しは「リング」を伴う。

○Ｗｉｎｄｏｗ ○Ｌｏｇ　ログ・ビューを表示し、または隠す。

ＱＷｉｎｄｏｗｌｉｓｔ　すべての子ビューおよびログ・ビューのリスト ○Ｃａ５ｃａｄｅ　子ビューを連鎖する。

ＱＴｉｌｅ　子ビューをタイル表示する。

○Ａｒｒａｎｇｅ　１ｃｏｎｓ　子ビューのアイコンを整理する。

表示できる他のウィンドウは、呼出し中の、共用されない現在作動中のａＷａｒ ｅアプリケーションのＵｎｓｈａｒｅｄビュー、呼出し中のノードのリストと、 各ノードごとの、ノードで走行中の共用アプリケーションのリストであるＣａ１ ｌウインドウ、制御ウィンドウの子ウィンドウでない別のウィンドウであり、タ イムスタンプ付き事象の記録を含むＬｏｇウィンドウである。

呼出しマネージャは、ローカル・アプリケーション初期設定などの呼出しマネー ジャ事象と、他のノードからの指定された共用要求を処理するための事象ハンド ラを含む。

呼出しおよび共用セット 呼出しマネージャによって実施される呼出しの概念は、サブシステムに実際の相 当物を有していない。基本的に、呼出しは、１つまたは複数の指定された共用セ ットと、互いを知っている数組のアプリケーション・インスタンスから構成され る。各セットは、呼出し内の各ノードで作動中の単一のアプリケーションから構 成される。呼出しマネージャ自体は、各呼出しごとのそのような１つの共用セッ ト中にある。呼出しマネージャだけ（および望ましくはユーザ）が、所与のノー ドにある様々な共用セットが呼出しごとにグループ化されることを知っている。

呼出しが１つまたは複数の共用セットから構成されるので、様々な呼出しマネー ジャ機能は実際には共用セットに対する動作である。したがって、リモート・ノ ードへの新しい呼出しを開始するには、呼出しマネージャが、通常はノード名に 数値接尾部を追加し、各呼出しの後に数を増分することによって、呼出し名を作 成する。呼出しマネージャは次いで、この名前を使用して、リモート・ノードに ある呼出しマネージャと共用を行おうとする。共用が受け入れられた場合は、呼 出しが確立されている。既存の呼出しに新しレッードを追加するには、呼出しマ ネージャが、呼出し名を共用セット名として使用して、新しいノードにある呼出 しマネージャとの共用を試みるだけである。外部から既存の呼出しに参加するに は、呼出しマネージャが、加わるべき呼出しの名前を渡して、呼出し中の１つの ノードにある呼出しマネージャとの共用を試みるだけである。呼出しから抜ける ためには、呼出しマネージャが適切な共用セットがら抜ける。呼出しに新しいア プリケーションを追加するには、呼出しマネージャが、呼出し名を共用セット名 として使用して、呼出し中の各ノードへのアプリケーションに代わって順繰りに ５ｈａｒｅを発行する。呼出し中にアプリケーションが存在すれば、新しいノー ドを追加するたびに、各アプリケーションごとに該ノードに５ｈａｒｅが発行さ れることに留意されたい。

第１７図に示すように、呼出しマネージャには６つの主要な状態がある。これら は、開始、準備完了、接続、処理、終了、およびレザインである。開始は、エン ジンがローンチされた点から、エンジンが初期設定を完了するまで発生する。

エンジンは次いで、準備完了状態に入り、エンジンと共用を行っている他のアプ リケーションのユーザ・インタフェースからのコマンドを待つ。サポート・シス テムからエンジンの事象ハンドラに渡される一部の事象によって、ユーザ・イン タフェース構成要素に信号が送信され、それによって、ユーザが通知を受け、必 要に応じて、コマンドを介してエンジンにフィードバックできる応答を得ること ができる。エンジンは、呼出しが進行を開始するのと同時に接続状態に入る。エ ンジンは、進行中の呼出しがなくなるのと同時に準備完了状態に戻る。エンジン は、この状態の間、１つの例外であるｓｈｕｔｄｏｗｎコマンドを除き、準備完 了状態と同じ１組のコマンドを受け入れる。エンジンは、ユーザ・インタフェー スが応答し、あるいはサポート・システム事象が発生するのを待つときは必ず処 理状態に入る。この状態の間、呼出しなどのある種のコマンドは拒否され、”ｅ ｎｇｉｎｅ　ｉｓ　ｂｕｓｙ”指示が表示される。５ＨＡＲＥ　ＲＥＱＵＥＳＴ などのある種のサポート・システム事象も拒否される。

エンジンは、Ｎ０ＤＥ　５ＨＵＴ　ＤＯＷｔｊＲＥＱＵＥＳＴ事象が受信され受 け入れられるのと同時に終了状態に入る。遮断を進行させるにはエンジンが準備 完了状態でなければならず、呼出しが進行中の場合はまずそれを終了しなければ ならないことに留意されたい。エンジンは、ＣＡＬＬ　ＭＡＮＡＧＥＲ，−ＲＥ ＱＵＥＳＴを受け入れるのと同時にレザイン状態に入る。この状態は、エンジン が終了するという点で終了状態に類似しているが、サポート・システムの残りは 終了しない。エンジンは、準備完了状態の場合にだけレザインし、呼出しが進行 中の場合はまずそれを終了しなければならない。

第１６図は４つのノード、Ａ、Ｂ５Ｃ５Ｄを示す。ノードＣは以下の２つの呼出 しに関与する。

１．２つのアプリケーション共用セットＹおよびＺと、ノードＤを伴う呼出し ２、単一のアプリケーション共用セットＸと、ノードＡおよびＢを伴う呼出し 呼出しマネージャの事象処理 呼出しマネージャが処理する主要な事象は以下のとおりである。

〇へＰＰ−ＲＥＧ　Ｉ　５ＴＥＲＥＤ　これは、（ローカル）アプリケーション がｒｅｇｉｓｔｅｒ　ａｐｐ呼出しを発行するときにレイズされる。

０Ｍ０ＮＩＴＯＲＥＶＥＮＴＳ　非共用のローカル効果とリモート効果とを見る には、呼出しマネージャがこれらの事象を監視しなければならない。

○ＰＡＳＳＩＶＥ−目Ｎ１ｊＲＥＱＵＥＳＴ　これは、システムがこのノードに ある資源を使用して他のノードのニーズをサポートしたいときにレイズされる。

０ＰＡＳＳＩＶＥ　ＬＩＮＫ　ＲＥＬＥＡＳＥ　これは、このノードにある資源 がもはや、他のノードのニーズをサポートするためにシステムによって必要とさ れないときにレイズされる。

Ｏ５ＥＴ−ＣＡＬＬ−ＭＡＮＡＧＥＲこれは、他のアプリケーションがｓｅｔ　 ｃａｌｌ　ｍａｎａｇｅｒ呼出しを発行したときにレイズされる。

Ｑ　５ＨＡＲＥ−ＲＥＱＵＥＳＴ　これは、指定されたアプリケーションとの共 用をめる、他のノードからの要求が受信されたときにレイズされる。

ＱＳＨＡＲＥ　ＲＥＪＥＣＴＥＤ　これは、ローカル・アプリケーションが共用 要求を拒否したときにレイズされる（通常、ある種のエラーの結果として）。

○５ＨＵＴ　ＤＯＷＮ　ＲＥＱＵＥＳＴ　コれは、このノードにあるシステムの 遮断をめる、ユーザまたはアプリケーションによる要求が出されたときにレイズ される。

ＱＳＩＧＮＡＬ　これは、ターゲットが空でも名前（ハンドルではない）でもな い信号をアプリケーションが発行したときにレイズされる。

○ＡＰＰ　ＤＥＲＥＧＩＳＴＥＲＥＤ　これは、ａｗａｒｅアプリケーションが 終了したときにレイズされる。

これらの事象は、以下で定義するように処理される。

Ｒｅｇｉｓｔｅｒ　ａｐｐ 呼出しマネージャは、始動するアプリケーションの名前を、適切な呼出し用の共 用セット中のアプリケーションのリストと非共用リストのうちの活動状況の方に 追加して記録する。

呼出しが活動状況でありアプリケーションがユーザによって始動された場合、呼 出しマネージャは、アプリケーションが呼出し全体にわたって共用されるように 、呼出し中の各リモート・ノードに、指定された共用呼出しを発行する。アプリ ケーションが着信共用要求の結果として呼出しマネージャによってローンチされ た場合、呼出しマネージャはリモート・ノード／アプリケーションに代わってロ ーカル５ｈａｒｅを発行することによって５ｈａｒｅを完了する。

アプリケーションが終了すると、その名前が適切なリストから削除される（以下 のＡＰＰ　ＤＥＲＥＧＩＳＴＥＲＥＤの項参照）。

呼出しマネージャは常に、ＡＰＰ　ＲＥＧ４ＳＴＥＲＥＤ事象に対してＲＣＯＫ を返す。

ＰＡＳＳＴＶＥ　ＬＩＮＫ　ＲＥＱＵＥＳＴこの事象は、簡単な方法で処理され る。呼出しマネージャは、Ｐａ５ｓｉｖｅ　Ｗｏｒｋｉｎｇオプションの状態を 検査する。該状態がｐｅｒｍｉｔの場合、要求は受け入れられるが、ｄｅｎｙの 場合は拒否される。ａｓｋの場合、呼出しマネージャは、要求が受け入れられる かどうかをユーザに尋ねるダイアログ・ボックスを表示して（パネルは、要求に 関するできる限り多くの情報を表示する）、次いでユーザの応答に応じて（ＲＣ −ＯＫまたはＲＣＦＡＩＬを返すことによって）要求を受け入れ、または拒否す る。

ＭＯＮＩＴＯＲＥＶＥＮＴＳ 呼出しマネージャが関与する２つの事象は、非共用呼出しくローカルでレイズさ れる）と非共用事象（リモートでレイズされる）の結果である。呼出しマネージ ャは、適切なリストからアプリケーションを削除することによってこれらに応答 する。

リモート呼出しマネージャからｕｎｓｈａｒｅが届いた場合、これは、該リモー ト呼出しマネージャが呼出しを抜けたことを示し、したがって、呼出しマネージ ャは適切な呼出しリストから該リモート呼出しマネージャを消去することによっ て応答する。呼出しに２つのパーティしか入っていなかった（すなわち呼出しが 有効に終了した）場合、呼出しマネージャは、まだ呼出し内にリストされている アプリケーションを非共用にして非共用リストに移し、次いで呼出しを削除する 。

呼出しマネージャは、すべての事象に対してＲＣ−ＯＫを返す。

ＰＡＳＳＩＶＥ　ＬＩＮＫ−ＲＥＬＥＡＳＥこの事象は、受動リンクを使用する チャネルが破壊されたときに生成される。この事象が発生すると、呼出しマネー ジャは、受動リンクがもはや存在しないことを示すようにメイン・ウィンドウを 更新して、ＲＣＯＫを返すだけとなる。

ＳＥ’ｊＣＡＬＬ−ＭＡＮＡＧＥＲ 呼出しマネージャは、ＲＣＯＫを返すことによってこの事象に応答する。これに よって、呼出しマネージャの役割を新しいアプリケーションに移すことができる 。

５ＨＡＲＥ　ＲＥＱＵＥＳＴ 呼出しマネージャは、処理すべき名前を調べる。これが呼出しマネージャ名の場 合、実際には、新しい呼出しの開始をめるリモート呼出しマネージャからの要求 である。ユーザ情報は、呼出しのＩＤ（すなわち、リモート・ノードによって割 り当てられたＩＤ）を含む。これは、２つのノードが複数の相互の呼出しに関与 している場合にあいまいさを解消するために必要である。

この場合、呼出しマネージャは、Ａｎｓｗｅｒオプションの状態を検査して応答 する。該状態がｍａｎｕａｌの場合、呼出しマネージャは、要求が受け入れられ るかどうかをユーザに尋ねるダイアログ・ボックスを表示する（パネルは、要求 に関するできるだけ多くの情報を表示する）。状態がａｕｔｏ−ａｎｓｗｅｒの 場合、要求は受け入れられる。

要求が呼出しマネージャからのものでない場合、間違いなく、すでに既存の呼出 しのパーティとなっているノードからのものである。このため、着信共用要求は 常に受け入れられる。着信共用要求が呼出しＩＤを含むことに留意されたい。

これは、所与の１対のノードが複数の呼出しを共有することができ、その結果得 られるあいまいさを解消することができるからである。呼出しマネージャは、共 用要求を受け入れるために、対応するアプリケーションをローンチしようとする 。

呼出しマネージャは、共用要求で使用されたターゲット・アプリケーションとＫ ＥＹＷＯＲＤが一致するＡＰＰＬＩＣ：ＡＴＩＯＮＳセクション中の項目をＬＡ ＫＥＳ、　ＩＮＩファイルで探す。１つも見つからない場合、エラーが報告され る。項目が見つかった場合、プロファイル項目中の値を使用して、ローンチ呼出 しのフィールドが埋められ、次いで該呼出しが実行される。ＡＰＰＬＩＣＡＴＩ ＯＮＳセクションの例を以下に示す。

［ａｐｐｌ　１ｃａｔｉｏｎｓ］ ｃｈａｔ＝ｃ：＼１ａｋｅｓ＼ａｐｐｓ″Ｘｃｈａｔ、ｅｘｅ、　ｃ：＼１ａｋ ｅｓ＼ｗｏｒｋ、　、　、　。

ｃｈａｌ　ｋｂｏａｒｄ＝ｃ　：＼ｌ　ａｋｅｓＸＸａｐｐｓ＼ｃｈａｌｋ、ｅ ｘｅ、　ｃ：＼１ａｋｅｓ＼ｗｏｒｋ。

ｆｉｌｅｔｒａｎｓｆｅｒ＝ｃ：＼１ａｋｅｓ＼ａｐｐｓ″３ｘｆｅｒ、ｅｘｅ 、　ｃ：＼１ａｋｅｓ＼ｗｏｒｋ、Φ。

呼出しマネージャは、対応するＲｅｇｉｓｔｅｔｒ　ａｐｐ事象が発生したとき に、ローンチされたプログラムを再び共用しようとしない（前述のＡＰＰ　ＲＥ ＧＩＳＴＥＲＥＤ事象の項参照）ように、該プログラムのハンドルを記録する。

ローンチが失敗すると、ＲＣ−３ＨΔＲＥ　ＲＥＪＥＣＴＥＤが返される。一方 、ローンチが成功した場合、呼出しマネージャはＲＣ−３ＨＡＲＥ−Ｎｏ　ＣＯ ＮＦＩＲＭを返す。ローンチされたアプリケーションが後でｒｅｇｉｓｔｅｒ　 ａｐｐを発行すると、呼出しマネージャは共用呼出しを発行する。次いで、アプ リケーションはＲＣＳＨΔＲＥ　Ｃ：ＯＮＦＩＲＭＥＤを返すべきである。

本明細書で説明する呼出しマネージャが、すでに作動中のアプリケーションと共 用を行うことによって着信共用要求を解決するのではないことに留意されたい。

常に、新しいインスタンスがローンチされる。

５ＨＡＲＥ　ＲＥＪＥＣＴＥＤ 上述のように、呼出しマネージャによってローンチされたアプリケーションは、 登録されると、呼出しマネージャによって発行された５ｈａｒｅのターゲットに なる。通常、該アプリケーションは、呼出しマネージャがすでに呼出しを受け入 れているのでＲＣ５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤで応答すべきである。アプリ ケーションが共用を受け入れることができない場合（たとえば、資源不足のため に）、呼出しマネージャと最初のリモート・アプリケーションとに拒否が送信さ れる。呼出しマネージャは、最初の共用を「忘れてＪ　ＲＣＯＫを返すことによ って応答する。

５ＨＵＴ　ＤＯＷＮ−ＲＥＱＵＥＳＴ 呼出しマネージャはＲＣＯＫを返すことによってこの事象に応答する。これによ って遮断を続行することができる。これによって、さらに、システムが実際に遮 断する際に、すべてのアプリケーション（呼出しマネージャを含む）が５ＨＵＴ 　ＤＯＷＮ事象を受信する。呼出しマネージャは、他の供給されたアプリケーシ ョンと同様に、登録を取り消すことによってこの事象に応答する。

ＩＧＮＡＬ 以下の２つ信号タイプによって、呼出しマネージャで５ＩＧＮＡＬ事象がレイズ される。

１　、　ｔａｒｇｅｔ　ａｐｐｌｉａｃａｔｉｏｎパラメータが空の信号。その ような事象はＣａ１ｌ　Ｍａｎａｇｅｒコマンドとみなされる。

２　、　ｔａｒｇｅｔ　ａｐｐｌｉｃａｔｉｏｎパラメータがアプリケーション をハンドルでな（名前で表す信号。呼出しマネージャはこの名前を以下のように 処理する。

○その名前のアプリケーションが現在走行中かどうか（すなわち、その名前を使 用するｒｅｇｉｓｔｅｒ　ａｐｐが発行されているかどうか）を検査する。

Ｏそうである場合、信号はそのアプリケーションに転送される（アプリケーショ ンが複数の場合、信号は第１のインスタンスに送られる）。

Ｏその名前のアプリケーションが作動していない場合、呼出しマネージャは新し いインスタンスをローンチしない。その代わり、信号が無視される。

ＡＰＰ　ＤＥＲＥＧＩＳＴＥＲＥＤ この事象は、アプリケーションが終了する際に生成される。

呼出しマネージャは、適切な呼出しリストから登録取消しアプリケーションの名 前を削除し、メイン・ウィンドウを正しく更新し、ＲＣＣＫを返すことによって 、この事象に応答する。

簡単な例 １つの可能な事象シーケンスは以下のとおりである。

１、ユーザＡがユーザＢを呼び出す（その結果、呼出しマネージャが共用される ）。

２、ユーザＡがチャツト・アプリケーション（Ａの呼出しマネージャによって共 用され、したがってＢにある呼出しマネージャによってローンチされ、第１のア プリケーション共用セットを形成する）を始動する。

３、ユーザＡおよびＢはしばらくチャツトし、次いでユーザＢがチャツト・アプ リケーションを終了する（それによって共用セットが終了する）。チャツト・ア プリケーションは、Ａで引き続き作動するが、もはや呼出しの一部でないので非 共用リスト上に表示される。

４、ユーザＢがチョークボード・アプリケーションを始動する。２人のユーザは まだ呼出し中にいるので、已にある呼出しマネージャが５ｈａｒｅを発行し、し たがってＡの呼出しマネージャがＢでチョークボードをローンチし、新しい共用 セットが形成される。

５、ユーザＡが呼出しを切る。

このシーケンスをＡＰＩレベルで調べると、以下のようになる。

１、Ａにある呼出しマネージャが、Ｂとの５ｈａｒｅを発行することによってプ ロセスを開始する。Ｂで、呼出しマネージャは、共用が呼出しマネージャを伴う ことを通知する（したがって、新しい呼出しのセットアツプをめる）。呼出しマ ネージャは、呼出しが受け入れられると仮定して、呼出しマネージャ間の共用を 受け入れる。

２、Ａにいるユーザがチャツト・アプリケーションを始動すると、Ａにある呼出 しマネージャ（ｒｅｇｉｓｔｅｒ　ａｐｐ事象を調べる）が５ｈａｒｅを発行す る。Ｂで、呼出しマネージャが、対応するアプリケーションに対する１ａｕｎｃ ｈを発行することによって共用要求を受け入れる。

３、ユーザＢがチャツト・アプリケーションを終了すると、Ｂにあるサブシステ ムによって自動ｕｎｓｈａｒｅが発行される。２つ呼出しマネージャは共に、非 共用呼出しおよび非共用事象を監視するので、共にｕｎｓｈａｒｅを通知され、 したがって呼出しリストを更新することができる。Ｂにある呼出しマネージャは 、非共用呼出しを調べ、Ａにある呼出しマネージャは非共用事象を調べる。

４、チョークボード・アプリケーションが、チャツト・アプリケーションと同様 に処理される。

５、最後に、ユーザＡが通話を切り、Ａにある呼出しマネージャがｕｎｓｈａｒ ｅを発行し、したがって呼出しが終了する。

作法に従ったアプリケーションの構造 呼出しマネージャ設計の主要な目的の１つは、ａｗａｒｅアプリケーションの構 造を簡単にすることである。呼出しマネージャが呼出しの実行、共用呼出しおよ び非共用呼出しの発行などを監視するので、典型的なアプリケーションが必要と するのは以下のことだけである。

Ｏ始動時のｒｅｇｉ　５ｔｅｒ−ａｐｐ。呼出しマネージャが存在しないことを 戻りコードが示す場合、アプリケーションはユーザに通知し、次いで終了すべき である。

０首尾よく登録した後、ｃｒｅａｔｅ　ｐｏｒｔｓを使用してアプリケーション 自体へのチャネルを確立する（大部分のアプリケーションの場合、組合せチャネ ル・セットが使用される）。

Ｏ大部分の事象がデフォルトで処理できるようにする。

Ｏ終了を要求されたときに、まずｒｅｍＯＶｅＪＯｒｔｓ、次いで任意選択でｕ ｎｓｈａｒｅ、次いでｄｅｒｅｇｉｓｔｅｒ　ａｐｐ通常、アプリケーションが ５ｈａｒｅまたはｕｎｓｈａｒｅを発行することは必要とされない。なぜなら、 呼出しマネージャがこれらを処理するからである。

事象に関する限り、大部分はデフォルトで処理される。以下で例を示す。

○５ＨＡＲＥ　ＲＥＱＵＥＳＴでは、５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤが返され るべきである。というのは、この事象は、すでに呼出しを受け入れることを決定 した呼出しマネージャからのローカル５ｈａｒｅの結果だからである。他の処理 を行う必要はない。

０３ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤの結果はＲＣＯＫになるべきであるが、そう でない場合、５ＨＡＲＥ　ＣＯＮＦＩＲＭＥＤを無視することができる。

○５ｔ−ＩＡＲＥ−ＲＥＪＥＣＴＥＤは発生してはならない（すべての５ＨＡＲ Ｅ−ＲＥＱＵＥＳＴを受け入れるべきであるから）。

○５ＨＵＴ−ＤＯＷＮの結果はＲＣＯＫになるべきであり、アプリケーションは 次いで、終了すべきであり（たとえば、Ｏ３／２　ＰＭ環境では、それ自体にＷ Ｍ　ＱＵＩＴメツセージを通知することによって）、あるいは少なくとももはや ＡＰＩ呼出しを発行してはならない。

ＱＵＮＳＨＡＲＥの結果はＲＣ：　ＯＫになるべきであるが、そうでない場合、 ＵＮＳＨＡＲＥを無視することができる。

ＦＩＧ−Ｉ ＦＩＧ−４ ＦＩＧ−２ ＦＩＧ−３ ＦＩＧ−６ ＦＩＧ−７ ＦＩＧ−８ ＦＩＧ−９ システム　ボート　装置ドライバ　インタフェースＩＧ−１０ ＦＩＧ−１１ ＦＩＧ−１２ ＦＩＧ−１３ ＦＩＧ−１４ フロントページの続き （７２）発明者　ミッチェル、バリー、デヴイッドイギリス国す−レイ、リッチ モンド・アポン・テイームズ、ザ・ハーミテイジ１８（７２）発明者　ランバー ト、ハワードイギリス国ハンプシャー、サザンプトン、ヘッジ・エンド、ノルデ ック・ガーデンズ

Claims (8)

【特許請求の範囲】
1. １．ノードの間でデータを送信するための物理リンクによって接続されたネット ワークのノードを形成するワークステーションのネットワークでの協調作業用の プログラマブル・ワークステーションにおいて、 オペレーティング・システムと、 ノードの間のマルチメディア・データの物理経路指定を制御するための、オペレ ーティング・システム上で動作するネットワーク制御層と、 ワークステーション上で作動し、協調呼出しマネージャ・プログラムからの所定 のアプリケーション呼出しに応答して、ノードで協調呼出しマネージャを確立し 、ノードにあるどのアプリケーション・インスタンスにも特有でない着信事象を 処理する協調アプリケーション・サブシステムとからなることを特徴とするワー クステーション。
2. ２．ノードに協調呼出しマネージャがすでに存在する場合、それ自体の判断で着 信事象の処理を新しい呼出しマネージャに移すことができる既存の呼出しマネー ジャに所定のアプリケーション呼出しが送られることを特徴とする請求項１に記 載のワークステーション。
3. ３．アプリケーション・インスタンスに特有の着信事象がそのインスタンスに直 接渡されることを特徴とする請求項１または２に記載のワークステーション。
4. ４．協調アプリケーション・サブシステムによってそれ自体に渡され、アプリケ ーションを指定する、非アプリケーション特有事象に応じて、指定されたアプリ ケーションの既存のインスタンスに該事象を送り、指定されたアプリケーション の新しいインスタンスをローンチし、あるいは事象自体を処理するそのような協 調呼出しマネージャを含むことを特徴とする請求項１、請求項２、または請求項 ３に記載のワークステーション。
5. ５．ノードの間のデータ送信用の物理リンクによって接続されたネットワークの ノードを形成するプログラマブル・ワークステーションのネットワークでの協調 作業方法において、ワークステーション上で作動する協調呼出しマネージャから の所定のアプリケーション呼出しに応答して、ノードで協調呼出しマネージャを 確立し、ノードにあるどのアプリケーション・インスタンスにも特有でない着信 事象を処理することから成る方法。
6. ６．ノードに協調呼出しマネージャがすでに存在する場合、それ自体の判断で着 信事象の処理を新しい呼出しマネージャに移すことができる既存の呼出しマネー ジャに所定のアプリケーション呼出しが送られることを特徴とする請求項５に記 載の方法。
7. ７．アプリケーション・インスタンスに特有の着信事象がそのインスタンスに直 接渡されることを特徴とする請求項５または６に記載の方法。
8. ８．そのような協調呼出しマネージャが、指定されたアプリケーションの既存の インスタンスに、アプリケーションを指定する非アプリケーション特有事象を送 り、指定されたアプリケーションの新しいインスタンスをローンチし、あるいは 事象自体を処理することによって、該事象に応答することを特徴とする、請求項 ５、請求項６、または請求項７に記載の方法。