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

Description

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

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

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

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

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

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

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

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

［発明の好ましい実施例］ 第１図には、LANやWANなどのネットワークでリンク11
によって接続された２台のプログラマブル・ワークステ
ーション10および12が示されている。ワークステーショ
ンの主要な構成要素は従来、ハードウェア13から始まる
層として説明されている。詳細に図示していないハード
ウェアは、メイン・メモリをもつプロセッサ装置と、デ
ィスク・ファイルなどの二次記憶域と、表示装置と、キ
ーボードやマウスなどの入出力装置から構成される。装
置サポート・ソフトウェア14は、ハードウェア装置がIB
Mのオペレーティング・システム/2（OS/2）などの周知
のオペレーティング・システム15内で機能できるように
する。

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

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

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

アプリケーション・プログラミング・インタフェース
20によって、アプリケーション18はサポート・サービス
を要求することができる。装置ドライバ・インタフェー
ス21によって、システムは、トークン・リング・ドライ
バ25、ISDNドライバ26、RS232ドライバ27、その他の装
置ドライバ28などの装置ドライバを介して広範囲なソフ
トウェアおよびハードウェア通信サブシステムをサポー
トすることができる。リンク・サポート・モジュール22
8、229は装置ドライバとのインタフェースをとる。これ
らは、ワークステーションで利用可能なハードウェア・
オプションに応じて交換可能であり（第10図は、可能な
選択だけを示す）、どのハードウェアが存在するのかを
サポート・システムが正確に知らなくて済むように働
く。暗示的な資源インタフェース（図示せず）を介し
て、サポート・システムでも、アプリケーションでも、
装置ドライバでも、資源ファイル29に、ノード・アドレ
スやディレクトリ・データなどの通信ネットワークの詳
細を要求することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

通信、チャネル、およびポート 第５図の概略例に示すように、40、41、42などの共用
セット中のアプリケーションは、チャネルといわれるデ
ータ通信リンクを相互に確立することができる。43、44
などのチャネルは、論理的に専用の単一方向パイプであ
り、アプリケーションで指定された送信特性を有する。
チャネルは常に、送信側アプリケーションによって定義
され、送信側アプリケーションから受信側アプリケーシ
ョンに向かう。チャネルの端部はポートといわれる。し
たがって、チャネルはすべて、１つの送信側ポートと１
つの受信側ポートを有する。45などの送信側ポートは、
チャネルを介してパケット・データを送信する。46など
の受信側ポートはチャネルからのデータ・パケットを、
それらが送信された順序で受信する。awareアプリケー
ションに見える論理チャネル構造と、ノードの間に存在
する物理通信ネットワークの間に直接マッピングがない
場合がある。

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

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

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

標準、組合せ、同期、および直列化の４つのチャネル
・タイプがサポートされる。標準チャネルはデフォルト
・ケースである。他のタイプは、チャネル・セットとい
われるチャネルの集合に関連して使用される。組合せチ
ャネル・セットを介して、複数のチャネルからのデータ
・パケットが組み合わされ、単一のポートを介して各受
信側アプリケーションに送られる。各アプリケーション
がすべてのデータ・パケットを同じシーケンスで受信す
ることは保証されず、各アプリケーションがすべてのパ
ケットを受信することだけが保証される。直列化チャネ
ル・セットを介して、異なるチャネルからのデータ・パ
ケットが組み合わされ、直列化され、各受信側ポートが
同じシーケンスのデータを受信するように各アプリケー
ションに送られる。同期チャネル・セットを介して、デ
ータが同期され、それによって、別々のチャネル上のデ
ータ・パケットが調子を合わせて結合される（たとえ
ば、音声とビデオ）が、そのチャネルに属するそれぞれ
のポートを介して送られる。

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

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

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

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

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

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

標準送信側コマンド・ポートの全体的な構造を第８図
に示す。データは、アプリケーションからの“send_dat
a"コマンドに応答して、ポート70のバッファ71中で待機
する。アプリケーションは、バッファを空にして、ユー
ザ出口72とチャネル73を介して非同期的にデータを送信
する。着信した“signal_port"コマンドは、回線75上で
チャネル73とは独立に、ポート事象ハンドラ74によって
受信され、回線76上で外部に再伝送することができる。

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

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

同期は論理的に、すべての事象を中央点に集合させる
ことと、その後に、各事象を、その事象のすべての宛先
に同報通信することを伴う。図では、チャネル80および
81上の２つのポートＡおよびＢの場合に関する第９図で
これを表す。この図では、直列化プロセス85で、82およ
び83でのポートＡおよびＢの出力が、ポートＣ（84）お
よび他のポート（図示せず）に対して直列化される。直
列化は、すべてのデータを、直列化し、その後に分散す
るために単一の中央点に送信することによって、該中央
点で実施することができる。直列化プロセス自体を分散
することもできる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プリンタ装置によって、データをシステム・プリンタ
に送信することができる。送信側ポートは１つしか許可
されない。

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

ビデオ・ディスプレイ・プレイバック装置（IBM/イン
テル・アクションメディアIIアダプタ/A（IBM/IntelAct
ionMedia II Adapter/A）をサポートする）、ビデオ・
キャプチャ装置（IBM Mビデオ・キャプチャ・アダプタ/
A（IBM M−Video Capture Adapter/A）をサポートす
る）、オーディオ・キャプチャ・プレイバック装置（IB
M Mオーディオ・キャプチャ・プレイバック・アダプタ/
A（IBM M−Audio Capture and Playback Adapter/A）を
サポートする）、およびその他の特殊オーディオ／ビデ
オ装置（H320準拠符復号器などの）を含む、多数のビデ
オおよびオーディオ装置が存在する。

awareアプリケーションの多くはシステム・ユーティ
リティとして出荷されており、これらの装置を利用し
て、ネットワークを介した協調作業のための汎用エンド
・ユーザ機能を提供する。

カストマイズ サポート・システム17用のカストマイズ情報は、適切
なプラットフォーム指定リポジトリに記憶される。Wind
owsおよびOS/2の場合、この情報は、LAKES.INIおよびLA
KESQOS.INIと呼ばれるファイルである。これらのファイ
ルは、キーワードとその値が維持される、識別子で始ま
るセクションを含む標準ASCIIファイルとしてフォーマ
ットされる。アプリケーションは、それ自体の追加初期
設定フィールドを有することもできる。LAKES.INIは、
構成および始動オプション、awareアプリケーション、
装置、および物理通信リンクに関する情報を含む標準セ
クションを含む。そのようなアプリケーションに特有の
データを含むアプリケーション・セクションを存在させ
ることもできる。LAKEQOS.INIは、物理リンクおよびデ
ータ・クラスに関するサービス品質情報を含む。これら
のファイルにアクセスし、それらを更新するための呼出
しはAPIに提供されている。

資源管理 協調作業では多くの場合、ノードが所有する資源、た
とえばプリンタ装置を他のノードと共用できることが必
要になる。そのような資源は、グローバル資源とみなさ
れ、アクセスはグローバル・トークンを介して制御され
る。その他の資源、たとえば共用ポインタは、アプリケ
ーション共用セットにローカルであり、これへのアクセ
スはアプリケーション・トークンを介して管理される。

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

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

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

初期設定および終了 サポート・システムは、LAKES.EXEファイルを動作さ
せることによって始動される。このファイルは、ファイ
ルLAKES.INIからプロファイル・データを読み取る。指
定された呼出しマネージャが、サポート・システムによ
って始動され、次いで、それ自体をawareアプリケーシ
ョンとして登録する。次いで、“set_call_manager"コ
マンドがこの特定のアプリケーションをそのノード用の
呼出しマネージャとして確立する。このコマンドの後
に、サポート・システムはそのノードで完全に活動状態
になり、着信事象および要求を処理できるようになる。

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

アプリケーションは、登録が取り消され、呼出しマネ
ージャが通知を受けることによってunawareアプリケー
ション状況に戻ることができる。保持されているすべて
のトークンが解除され、トークン所有者が通知を受け、
所有されているすべてのトークンが無効になる。アプリ
ケーションがアプリケーション共用セットのメンバであ
る場合は削除され、該アプリケーションが前記セットを
抜けたことが他のメンバに通知される。アプリケーショ
ンによって作成されたすべてのポートが破壊され、影響
を受けるチャネルへのポートを所有する他のアプリケー
ションが通知を受ける。終了するアプリケーションによ
って接続されたすべてのチャネルがウェルドされ、端末
チャネル・ポートで適切な事象がレイズされる。適切な
事象をレイズすることは、ローカル呼出しマネージャ
と、登録を取り消す側のアプリケーションに代わって、
ウェルドされたチャネルをサポートするあらゆるノード
の呼出しマネージャに必要である。オープンしている論
理装置はすべてクローズされる。ポートに接続された論
理装置がある場合は登録取消しプロセスの一部として破
壊され、次いで、接続されたチャネル全体が破壊され、
適当な事象がレイズされる。

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

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

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

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

アプリケーションはローンチされるとき、アプリケー
ション共用セットのメンバではない。発信元アプリケー
ションは、“share_app"要求を発行するとき、その結果
得られる共用セットを命名するオプションを有する。共
用セットを命名しない場合、ターゲットが名前を供給し
なければならない。共用を行った後、ターゲットと発信
元は共に、この名前の新しい共用セットに加わる。発信
元またはターゲット、あるいはその両方がすでに、これ
と同じ名前の共用セットのメンバだった場合、それらの
共用セットは新たに作成された共用セットと組合わされ
る。アプリケーションは、“unshare_app"要求を使用し
て共用セットを抜けることができる。

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

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

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

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

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

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

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

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

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

ある種のアプリケーションは、他のアプリケーション
と通信するのに必要なチャネルの固定サービズ品質要件
を有する。このような場合には“create_channel"要求
を使用してチャネルを直接確立することができる。この
要求上のパラメータは、受信側アプリケーションと、チ
ャネルと送信側ポートとの特性を識別する。資源が利用
可能であり、受信側アプリケーションが要求を受け入れ
る場合、チャネルが作成される。

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

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

これは、資源セット識別子、サービス品質、およびタ
ーゲット・ノードを指定する“claim_resource"コマン
ドによって行う。このコマンドは、その資源を予約し
て、指定された識別子と関連付ける効果を有する。この
識別子は次いで、その後の“create_channel"コマンド
で指定することができ、この場合、そのようなリザーブ
から資源が割り振られる。“query_resource"コマンド
を使用して、資源セット中の残りの資源を判定すること
ができる。

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

資源セット識別子は、アプリケーション・インスタン
スにローカルであり、１つの特定のサービス品質に適し
た資源を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ｄ）交換アナログ・ネットワーク 公衆交換網に接続されたアナログ電話およびその他の
機器は、ディジタル電話と同様に、仮想ノードで実行す
る仮想電話アプリケーションとして、または論理装置を
介してアクセスすることができる。PSTN電話論理装置を
オープンして、空接続タイプのポートを提供することが
できる。すなわち、該ポートはアプリケーションにデー
タを供給することも、アプリケーションからデータを受
信することもできない。“signal_port"コマンドは、装
置を制御するために使用される。ファースト・パーティ
接続は、ローカル回線にダイアリング・トーンを挿入す
るモデム、サード・パーティ接続、およびローカル・ス
イッチへのコマンドを介する多方向呼出しを介して実施
することができる。

unawareアプリケーションとのインタフェース サポート・システムは、unawareアプリケーションを
協調作業に使用できるようにする機能を提供する。awar
eアプリケーションは、ユーザ・インタフェース・ダイ
アログを供給し、仮想装置を介して特定のunawareアプ
リケーションと対話する。この同じawareアプリケーシ
ョンは次いで、リモート・ノードにある関連awareアプ
リケーションと通信し、リモート・ユーザに情報を渡
す。そのようなアプリケーションの幾つかは、汎用ユー
ティリティとして含められている。

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

unawareアプリケーションU_Xの共用ウィンドウ上のリ
モート・ポインタをA_XおよびA_Yで処理し、対話型データ
・クラスに適したチャネルをセット・アップすることが
できる。次いで、各ノード上の実際のポインタを使用し
て、共用ウィンドウ中の機能を識別する。これは、指示
したい各ユーザがポインタを共用ウィンドウ内に移動す
る、などのアルゴリズムによって行うことができる。ポ
インタが共用ウィンドウ中にあるとき、その座標が共用
アプリケーションに送信される。次いで、組合わされた
座標を使用して、ポインタが制御される。この結果、だ
れであれ、最後にカーソルを移動した人が、すべてのリ
ンクされたポイントを位置決めすることになる。

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

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

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

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

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

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

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

ｃ）事象クラスおよび事象ハンドラ API要求は、事象および呼出し制御を援助するために
提供される。“begin_monitor"要求によって、アプリケ
ーションはノードでの要求および事象を監視することが
できる。監視の範囲は、以下のものの１つから監視クラ
スを選択することによって制御される。

All:すべての事象またはAPI呼出し Application Signalling:信号事象/API呼出し Call_manager:呼出しマネージャ事象/API呼出し Data:データ送信事象/API呼出し Device:装置事象/API呼出し Monitor:モニタ事象/API呼出し Port:ポートおよびチャネル事象/API呼出し Profile:プロファイル事象/API呼出し Share:共用および非共用事象/API呼出し Synchronisation:同期事象/API呼出し Token:トークン事象/API呼出し 監視の範囲は事象クラス・レベルまたはAPIクラス・
レベルで制御される。事象は、データがあってもなくて
も監視することができる。監視は、“end_monitor"コマ
ンドによって終了する。アプリケーションは、“enable
_events"コマンドおよび“disable_events"コマンドを
使用して、どの事象を受信すべきかも決定する。有効な
事象クラスは以下のとおりである。

All:すべての事象 Device:装置事象 Port:ポートおよびチャネル事象 Profile:プロファイル事象またはAPI呼出し Sharing:共用要求事象またはAPI呼出し デフォルトの事象ハンドラは、アプリケーションを介
して明示的に処理されないすべての事象に対する応答を
生成する。事象は、登録された事象ハンドルによって処
理される。

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

Application:これは、一時事象ハンドラであり、awar
eアプリケーションの一般動作に関連する主な事象を処
理する。この事象ハンドラは、呼出しマネージャを含む
すべてのawareアプリケーションに存在しなければなら
ない。

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

Port_event handler:複数のポート事象ハンドラが存
在でき、それぞれがデータ通信関連事象を処理する。

Monitor:これは任意選択で存在し、すべての事象監視
を処理する。

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

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

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

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

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

すべてのユーティリティは交換可能なアプリケーショ
ン・プログラムである。提供したユーティリティの構造
を第13図に示す。供給したユーティリティは、プログラ
ム・グループとしてインストールされ、協調する一連の
アプリケーションとして設計されている。主要なユーテ
ィリティ機能は、ユーザが直接呼び出すだけでなく、
“signal"コマンドによって他のアプリケーション・プ
ログラムから呼び出すこともできる。

ａ）ディレクトリおよび呼出し管理 ｉ）アドレス・ブック アドレス・ブック・ユーティリティ100によって、エ
ンド・ユーザはディレクトリおよび接続性情報を追加
し、削除し、更新することができる。データは、標準プ
ログラムで容易に編集される簡単なファイル構造に記憶
される。ただし、他の潜在的により広範囲で複雑なアド
レス・データベースとのインタフェースをとるための機
構が提供されている。ユーザ・データをフォーン・ブッ
クという論理集合にグループ化することができる。ユー
ティリティ・インタフェースは直接、呼出しマネージャ
とのインタフェースをとる。また、資源インタフェース
を介して照会に応答する。

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

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

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

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

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

iii）ファイル転送 ファイル転送104によって、呼出し中のユーザの間の
ファイルの送信が可能になる。１つまたは複数のファイ
ルを転送することができ、ファイルをコメントと共に送
信することができ、元のファイル名を宛先が利用できる
ようになる。受信側ノードはファイル受信およびファイ
ル命名を完全に制御する。

iv）メッセージ行 メッセージ行105は、呼出し中のユーザの間でテキス
ト・データを直接共用できるようにする。複数の同期ユ
ーザが許可され、各参加者はすべての交換されるメッセ
ージを同じシーケンスで見る。メッセージ・ユーティリ
ティは、呼出しセット・アップおよび終了、ファイル転
送などの、呼出し時の活動も記録する。実際の実施例で
は、このユーティリティを呼出しマネージャの一部とし
て提供している。

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

規格 全体的なアーキテクチャは、広範囲の協調アプリケー
ションをサポートするものである。インタフェースは、
実施できるアプリケーション・モデルの範囲に対して重
大な制限を課さないように、できるだけ高いレベルにセ
ットされている。関与する透過ネットワークの性質は完
全にAPIより下位に隠されている。これは、アプリケー
ションがネットワーク経路指定（たとえば直接または間
接）と関与するネットワーク・タイプ（たとえば、単一
リンクまたは複数リンク、交換接続または固定接続）を
完全に知っていることを意味する。この手法の結果、た
とえば特定の通信サービス品質を求める要求が失敗する
恐れがあることを予期してアプリケーションを書かなけ
ればならない。なぜなら、基礎ネットワークが必要な機
能を有していないことがあるからである。

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

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

アプリケーション共用セットの他に、チャネルもアー
キテクチャの基本概念である。同報通信と２方向通信を
共に効率的にサポートするための基礎通信ビルディング
・ブロックとして１方向チャネルを使用している。チャ
ネルは、送信側アプリケーションによって確立され、受
信側アプリケーションによって受け入れられる。という
のは、データをどのように送信すべきかを示すデータの
特性を知っているのは送信側アプリケーションだけだか
らである。２つのアプリケーションは共に、それぞれの
ポートに供給し、あるいは前記ポートから受信すべきフ
ォーマットを独立に制御することができる。各種のデー
タ・フロー用の複数の論理チャネルによって、サポート
・システムは基礎転送ネットワークにトラフィックを正
しく割り振ることができる。さらに、サポート・システ
ムは、データが、それぞれが別々に記述された別々の同
種フローで他のアプリケーションに提供されるようにす
る。このようにアプリケーション間のトラフィックを別
々のデータ・タイプに分割することによって、サポート
・システムはデータ変換機能を提供することができる。

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

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

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

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

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

API機能要求 セッションおよびアプリケーション共用 cancel_request:前の非同期要求がまだ満たされていな
い場合にその要求を取り消す。

deregister_app:アプリケーション・インスタンスによ
って、APIの使用を終了するために発行される。

launch_app:あるアプリケーションによって、他のアプ
リケーションを呼び出すために発行される。

register_app:発行側アプリケーション・インスタンス
をワイヤとして識別し、アプリケーション事象ハンドラ
を確立する。

set_call_manager:そのノード用の呼出しマネージャを
識別し、呼出マネージャ事象ハンドラを確立する。

share_app:アプリケーション・インスタンスが、あるア
プリケーションと他のアプリケーションの共用を要求す
るために発行する。

shutdown_node:アプリケーション・インスタンスによっ
て、そのローカル・ノードにあるサポート・システムの
遮断を要求するために発行される。

unshare_app:アプリケーション・インスタンスによっ
て、あるアプリケーションと他のアプリケーションの共
用を終了するために発行される。

装置およびポート add_channel:指定されたアプリケーション・インスタン
ス中で、指定された送信側ポートに他のチャネルを追加
する。

change_channel:指定されたチャネル特性を変更する。

change_device_characteristics:指定された装置特性を
変更する。

change_port:指定されたポート特性を変更する。

claim_resource:特定のサービス品質に関連する資源の
資源マネージャに対する呼出し close_device_port:定義された装置上の関連するポート
をクローズする。

connect_ports:指定された受信側ポートを指定された送
信側ポートに接続する。

create_channel:発行側アプリケーションにある送信側
ポートと、指定されたターゲット・アプリケーションに
ある受信側ポートから成るデータ送信チャネルを作成す
る。

disconnect_ports:指定された送信側ポートから指定さ
れた受信側ポートを切断する。

open_device_port:定義された装置上のポートをオープ
ンする。

remove_channel:指定された受信側ポートと指定された
送信側ポートに関連するチャネルを削除する。

request_resource:特定のサービス品質に関連する資源
の資源マネージャに対する照会 resume_port:指定されたポートを介してデータ送信を再
開する。

signal_port:指定されたポートを介して制御文字列を送
信する。

suspend_port:まだ受信されていないデータをドレーン
またはフラッシュした後に、指定されたポートを介する
データ送信を中断する。

weld_connection:指定された受信側ポートと送信側ポー
トの接続を永続的にする。

データ送信および受信 receive_data:指定された受信側コマンド・ポートから
データを受信する。

send_data:指定された送信側ポートを介してデータを非
同期的に送信する。様々な送信肯定応答を要求すること
ができる。

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

signal_app_with_reply:サポート・システムが確立した
制御チャネルを介して、サポート・システムまたはアプ
リケーションが定義した制御データを、指定されたアプ
リケーション・インスタンスに送信し、応答データを返
す。

start_sync:指定されたチャネル・セットに関連する受
信側ポートを介して受信されたデータの同期を開始す
る。

stop_sync:指定されたチャネル・セットに関連するすべ
ての受信側ポートのデータの同期を停止する。

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

give_token:指定された要求元に、指定されたトークン
を与える。

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

reclaim_token:指定されたアプリケーション・インスタ
ンスが保持している指定されたトークンをただちにトー
クンの現所有者に返すことを強制する。

refuse_token:指定された要求元に、指定されたトーク
ンを与えることを拒否する。

release_token:指定された保持しているトークンを現所
有者に返す。

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

set_token_owner:指定されたアプリケーション・インス
タンスに指定されたトークンの所有者をセットする。

事象制御 begin_monitor:API呼出しの各オカレンスを識別する特
殊監視事象を発生させ、または指定された監視事象ハン
ドラに標準事象を提供する。

default_event_handler:アプリケーション・プログラム
が明示的に処理することを所望しないすべての事象に対
してデフォルト応答を返す。

disable_events:指定された事象クラスの事象が発行側
アプリケーション・インスタンスの事象ハンドラに渡さ
れるのを停止する。

enable_events:指定された事象クラスの事象が発行側ア
プリケーション・インスタンスの事象ハンドラに渡され
るようにする。

end_monitor:API呼出しの各オカレンスを識別する特殊
監視事象、または提供中の標準事象を停止する。

プロファイル管理 read_profile_string:プロファイル・ファイルの指定さ
れたセクション中の指定されたキーワードの文字列を返
す。

wtrite_profile_string:プロファイル・ファイルの指定
されたセクション中の指定されたキーワードに文字列を
コピーする。

API照会 query_address:指定された共用セットに属するアプリケ
ーション・インスタンスの完全なフル・アドレスを返
す。

query_application_status:アプリケーションの状況（u
naware、aware、または呼出しマネージャ）を返す。

query_channel_characteristics:指定された送信側ポー
トおよび受信側ポートに関連するチャネルのチャネル特
性を返す。

query_channel_set:指定されたチャネル・セット中のす
べてのポートのハンドルを返す。

query_device_characteristics:指定された装置の装置
特性を返す。

query_device_status:指定された装置の状況を返す。

query_monitor:現在モニタ事象ハンドラに渡されている
機能または事象のクラスを返す。

query_port_characteristics:指定されたポートの特性
を返す。

query_port_status:指定されたポートの状況を返す。

query_resource:指定された資源セット中で利用可能な
資源を返す。

query_sharing_set:アプリケーション・インスタンス用
の共用セット識別子を返す。

query_token_holder:トークンの所有者（アプリケーシ
ョン・トークンのみ）および保持者を返す。

query_token_state:指定されたトークンの状態を返す。

API事象 呼出しマネージャ事象 APP_DEREGISTERED:アプリケーション・インスタンスがA
PIの使用を終了するときの、ローカル呼出しマネージャ
への事象。

APP_REGISTERED:アプリケーションがAPIの使用を初期設
定するときの、ローカル呼出しマネージャへの事象 CALL_MANAGER_ERROR:呼出しマネージャに影響を及ぼす
エラーが発生した。

CALL_MANAGER_REQUEST:他のローカル・アプリケーショ
ンがset_call_manager機能要求を発行したことを示す、
ローカル呼出しマネージャへの事象 NODE_SHUTDOWN_REQUEST:サポート・システムの遮断を求
める要求 PASSIVE_NODE_RELEASED:ノードが受動要求をサポートで
きるようにするために割り振られた資源の解除を求める
指示。

PASSIVE_NODE_REQUEST:ノードが受動要求をサポートす
るために資源を割り振ることを求める要求 SHARE_REQUEST:指定されたアプリケーションとの共用を
求める要求 TOKEN_STATUS_REQUEST:グローバル・トークンの状況を
求める要求 アプリケーション事象 APP_SIGNAL:信号が受信された。

APP_SIGNAL_REJECTED:信号が拒否された。

APP_SIGNAL_WITH_REPLY:signal_with_replyが受信され
た。

APP_SIGNAL_TRANSFERRED:信号が転送された。

APP_UNSHARE_REQUEST:受信側がアプリケーション共用セ
ットを抜けることをサード・パーティ・アプリケーショ
ンが要求した。

APP_UNSHARED:発行側がアプリケーション共用セットを
抜けるという通知が受信された。

APP_ERROR:関連アプリケーション・エラーが検出され
た。

NODE_SHUTDOWN:遮断が開始された。

PORT_REMOVED:ポートが削除されたことの確認 PORT_REQUEST:受信側ポートの追加を求める要求 RESOURCE_CLAIM:アプリケーションがサービス品質資源
を請求すると必ずレイズされる。

RESOURCE_REQUEST:アプリケーションがサービス品質資
源を要求すると必ずレイズされる。

PROFILE_CHANGED:LAKES.INIファイルまたはLAKESQOS.IN
Iファイルの変更を求める指示 SHARE_CONFIRMED:共用要求が処理されたことの確認が受
信された。

SHARE_REJECTED:共用要求が拒否された。

SHARE_REQUEST:共用要求が受信された。

SHARE_TRANSFERRED:共用要求が転送された。

TOKEN_CANCEL_REQUEST:待機中のトークン要求の取消し
を求める要求が受信された。

TOKEN_GIVEN:要求元にトークンが与えられた。

TOKEN_QREQUEST:トークンを保持し、あるいはトークン
が得られない場合は待ち行列に参加することを求める要
求 TOKEN_RECLAIMED:トークンが所有者によって取り去られ
た。

TOKEN_RECLAIMED:トークンが所有者によって取り去られ
た。

TOKEN_REFUSED:トークンを求める要求が拒否された。

TOKEN_REQUEST:トークンの保持を求める要求 TOKEN_RETURN_REQUEST:トークンの所有者が、トークン
をできるだけ早く返すことを要求している。

装置事象およびポート事象 CHANNEL_CHANGED:一部のチャネル特性が変更された。

CHANNEL_CONFIRMED:新しいチャネルが作成された。

CHANNEL_DESTROYED:チャネルが破壊された。

CHANNEL_REJECTED:チャネルが作成されなかった。

CONNECTION_WELDED:ウェル接続通知が受信された。

DATA_AVAILABLE:受信側ポートでデータが利用可能であ
る。

DATA_CONFIRMED:データ送信の確認またはデータ送信の
進行の推定が受信された。

DATA_REQUESTED:送信側ポートからデータが要求されて
いる。

DEVICE_INFORMATION:装置情報を供給する予定のアプリ
ケーション・インスタンスの送信側ポート事象ハンドラ
にレイズされる事象 PORT_ERROR:ポート・エラーが検出された。

PORT_RESUME_REQUEST:ポート再開要求が受信された。

PORT_SIGNALLED:信号ポート事象が受信された。

PORT_SUSPEND_REQUEST:ポート中断要求が受信された。

PORT_SYNC_REQUEST:同期制御の調整を求める要求が受信
された。

モニタ制御事象 EVENT_MONITORED:機能要求および事象活動の通知が受信
された。

チャネル、ポート、およびリンクの特性 チャネルの特性 以下のパラメータは、チャネルと関連しており、create
_channel要求およびadd_channel要求で設定される。

quality_of_service: 信号タイプ（アナログまたはディジタル） スループット 待ち時間 ジッタ 遅延 優先順位 圧縮ヒント 暗号化 セービス品質特性は、LAKESQOS.INIファイル中のデー
タ・タイプおよびサブタイプを介して関連付けられる
が、明示的に指定することができる。この特性は、未定
義のままにすることができる。これによって、データが
チャネルを介して送信されるときに、動作特性が、利用
可能な資源に依存するチャネルを作成することができ
る。

channel_type: 標準 組合せ 直列化 同期 channel_set_id: 識別子 ポート特性 以下のパラメータは、ポートと関連している。ポート
・タイプを除くすべてのパラメータは明示的に定義され
る。送信側ポートは、create_channel要求でこれらのパ
ラメータを指定し、受信側ポートはPORT_REQUEST応答で
これらのパラメータを指定する。

connect_type: コマンド 事象 空 event_handler: port_type: 送信 受信 data_class: データ・タイプ データ・サブタイプ user_exit: user_information: リンクの特性 以下のサービス品質パラメータは、物理リンクに関連
しており、リンク・ロケータを介してアクセスされるデ
ータベースに指定するか、あるいはデフォルトとしてLA
KESQOS.INIファイルから得られる。

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

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

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

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

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

共用呼出しマネージャの導入 協調サポート・システムの全体的な動作について説明
したので、ここで、様々な共用呼出しマネージャ・セッ
トアップ動作について詳細に説明する。呼出しマネージ
ャを確立するAPIコマンドはset_call_managerである。

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

set_call_manager関数が必要とするパラメータは以下
のとおりである。

event_handler呼出しマネージャ事象のために呼び出
すべき事象ハドラ event_wordすべての呼出しマネージャ事象上で呼出し
マネージャ事象ハンドラに渡されるユーザ指定データ・
ポインタ call_manager_info（返される）SET_CALL_MANAGER事
象に応答して現呼出しマネージャが返す値 set_call_manager（）関数は、非アプリケーション特
有性の事象、すなわち、特有のアプリケーション・イン
スタンスを識別しないネットワークからの着信事象を受
信する予定の事象ハンドラをサブシステムに対して識別
する（注：この事象は宛先アプリケーション名を指定す
ることができ、この場合、名前を特定のインスタンスに
帰着させるのは呼出しマネージャの機能である）。

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

アプリケーションは、set_call_manager（）関数呼出
しを発行する前に、register_app（）関数呼出しを発行
してアプリケーション自体をローカル・システムに対し
て識別しておかなければならない。

新しいアプリケーションがset_call_manager（）関数
呼出しを発行するとき、処理は、呼出しマネージャがす
でに存在しているかどうかに依存する。

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

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

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

LAKES.INIファイルは、呼出しマネージャになること
を許可されたアプリケーションの名前を指定するセクシ
ョンを有することができる。このため、現呼出しマネー
ジャでSET_CALL_MANAGER事象がレイズされると、呼出し
マネージャは、アプリケーションが許可されているかど
うかを調べるために、get_profile_string関数呼出しを
介してこのファイルを検査する。

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

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

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

application_name、event_handler、およびevent_wor
dを供給しなければならない。node_handleおよびapplic
ation_handleはシステムによって返される。これらは、
ノード内で特有のハンドラを定義し、ローカル・ノード
外では有効範囲や意味をもたない。

register_app関数呼出しの結果、呼出しマネージャ事
象ハンドラが存在する場合は該ハンドラでAPP_REGISTER
事象がレイズされる。呼出しマネージャが存在しない場
合、事象はレイズされず、register_app関数呼出しの発
行元は戻りコードRC_NO_CALL_MANAGERを受信する。発行
元は次いで、set_call_manager（）関数呼出しを発行す
ることによって呼出しマネージャになり、あるいはdere
gister_app（）関数呼出しを発行することによって終了
すべきである。

これは、set_call_manager（）が発行される前、すな
わち、有効な呼出しマネージャが識別される前に有効な
唯一の関数呼出しである。

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

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

target_applicationターゲット・アドレスの完全アド
レスを含む構造を指すポインタ。完全アドレス構造タイ
プは以下のように定義される。

target_exe_stringターゲット・アプリケーションの
実行可能ファイルの完全修飾名（完全経路を含む）を指
定する文字列を指すポインタ working_directoryディレクトリを指定する文字列を
指すポインタ。working_directoryが空の場合、カレン
ト・ディレクトリが仮定される。

parametersローンチされたアプリケーションに与えら
れるユーザ指定文字列 application_handle（返される）ローンチされたアプ
リケーションのアプリケーション・インスタンス・ハン
ドル この関数は、他のアプリケーション・インスタンスの
開始をシステムに要求するために使用される。新しいア
プリケーションが正常に起動すると、target_applicati
onにアプリケーション・ハンドルが挿入され、呼出し側
アプリケーションに返される。

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

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

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

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

source_application発信元アプリケーションの完全ア
ドレスを含む構造を指すポインタ target_applicationターゲット・アプリケーションの
完全アドレスを含む構造を指すポインタ user_infoこの共用によって生成されるすべての事象
上で返されるユーザ指定文字列 可能性のある戻りコードは以下のとおりである。

RC_OK動作が首尾よく完了した。

RC_FAIL LAKES環境が確立されなかった。

RC_SHARE_CONFIRMED共用が受け入れられたことを確認
するために同期share（）に返される。

RC_SHARE_REJECTED共用が拒否されたことを確認する
ために非同期share（）に返される。

RC_INVALID_ADDRESS無効なアドレス構造 share関数は、発信元アプリケーションとターゲット
・アプリケーションが「アプリケーション・セット」に
なる（または「アプリケーション・セット」に追加され
る）ことを要求する。

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

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

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

適切な戻りコード（RC_SHARE_CONFIRMEDまたはRC_SHA
RE_REJECTED）が返される。ローカル・システムがその
後、ターゲット・アプリケーションからSHAERE_CONFIRM
ED事象を受信した場合、この事象はshare関数呼出しの
発行元にレイズされず、適切なUNSHARE事象を生成する
システムによって処理される。ローカル・システムがそ
の後、ターゲット・アプリケーションからSHARE_REJECT
ED事象を受信した場合、この事象は無視される。

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

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

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

○shareを既存のインスタンスに送る。

○shareを異なるインスタンスにリダイレクトする。

○shareを完全に呼出しマネージャ内で処理する。

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

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

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

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

source_application発信元アプリケーションの完全ア
ドレスを含む構造を指すポインタ。短アドレス構造は以
下のように定義される。

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

user_infoパラメータは、なぜunshareを実行するかを
アプリケーション中の他のインスタンスに通知するため
に使用すべきである。

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

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

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

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

ステップ２で Ｙの呼出しマネージャは多数のオプショ
ンを有する。該呼出しマネージャは、共用要求を拒否す
る（RC_SHARE_REJECTED）ことも、共用要求自体を満た
す（RC_SHARE_CONFIRMED）ことも、共用要求をアプリケ
ーションＹの新しいインスタンスに渡す（RC_SHARE_NO_
CONFIRM）こともできる。

ステップ３で 呼出しマネージャがRC_SHARE_REJECTE
DまたはRC_SHARE_CONFIRMED）を返した場合、サブシス
テムは要求元でSHARE_REJECTED事象またはSHARE_CONFIR
MED事象をレイズする。

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

ステップ５で register_appの結果、サブシステムは
ノード２の呼出しマネージャにAPP_REGISTERED事象をレ
イズする。

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

ステップ７で アプリケーションＹは次いで、Ｘを要
求元として識別するSHARE_REQUEST事象を受信する。Ｙ
は次いで、共用を拒否し（RC_SHARE_REJECTED）、ある
いは受け入れる（RC_SHARE_CONFIRMED）ことができる。

ステップ８で Ｘは適切なSHARE_REJECTED事象または
SHARE_CONFIRMED事象を受信する。

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

最後にステップ10で Ｘは後で、共用セットを抜ける
ためちunshare（）を発行することができる。セット中
の残りのアプリケーションもすべて、UNSHARE事象を受
信する。

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

供給された呼出しマネージャ・ユーティリティによっ
て、呼出し管理とアプリケーション・プリミティブを明
確に分離することができる。したがって、付属の呼出し
マネージャを使用すると、awareアプリケーションが呼
出しのセットアップやたはテアダウンに関与する必要は
なくなる。この呼出しマネージャは、ユーザがアドレス
・ブックから名前を選択し、分岐呼出しを論理的に確立
するためのダイアログを提供する。セットにパーティを
追加することができ、パーティはセットを動的に抜ける
ことができ、いくつかの呼出しが同時に進行することが
できる。提供されたオプションは、自動応答と呼出し禁
止を含む。

呼出しマネージャのルック・アンド・フィールを機能
から分離するために、呼出しマネージャは実際には、エ
ンジンおよびユーザ・インタフェースの２つの別々のプ
ログラムとして実施される。エンジンは、呼出し管理機
能を提供し、ユーザ・インタフェースはルック・アンド
・フィールを決定する。呼出しマネージャ・エンジン
は、それを他のアプリケーションが制御できるようにす
るコマンド・インタフェースを有する（実際には、これ
は、ユーザ・インタフェース部分がエンジンをどのよう
に制御するかということである）。エンジンは、現在作
動中の各ローカル・アプリケーション・インスタンスご
とのアプリケーション・テーブルと、各呼出しごとの呼
出しマネージャと、現在コマンド共用セットにある（し
たがって、エンジンにコマンドを送信する資格がある）
各アプリケーションごとのコマンド・テーブルと、現在
有効な各受動リンクをリストするリンク・テーブルとを
維持する。

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

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

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

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

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

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

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

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

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

○Call ○New 新しい呼出しを開始する。

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

○Hang Up 現行呼出しを終了する。

○Cacel AddまたはNewを取り消す。

○Shutdown 呼出しマネージャ（およびすべての呼出
し）を終了する。

○Share ○Share 現行呼出しに既存の非共用アプリケーション
を追加する。

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

○Launch 新しいアプリケーションをローンチする。

○Options ○Auto 応答が自動的に受け入れられる。

○Passive この機械を他のユーザによるゲートウェイ
として使用できるかどうか ○Sound ティックされた場合、着信呼出しは「リン
グ」を伴う。

○Windw ○Log ログ・ビューを表示し、または隠す。

○Windowlist すべての子ビューおよびログ・ビューの
リスト ○Cascade 子ビューを連鎖する。

○Tile 子ビューをタイル表示する。

○Arrange icons 子ビューのアイコンを整理する。

表示できる他のウィンドウは、呼出し中の、共用され
ない現在作動中のawareアプリケーションのUnsharedビ
ュー、呼出し中のノードのリストと、各ノードごとの、
ノードで走行中の共用アプリケーションのリストである
Callウィンドウ、制御ウィンドウの子ウィンドウでない
別のウィンドウであり、タイムスタンプ付き事象の記録
を含むLogウィンドウである。

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

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

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

第17図に示すように、呼出しマネージャには６つの主
要な状態がある。これらは、開始、準備完了、接続、処
理、終了、およびレザインである。開始は、エンジンが
ローンチされた点から、エンジンが初期設定を完了する
まで発生する。エンジンは次いで、準備完了状態に入
り、エンジンと共用を行っている他のアプリケーション
のユーザ・インタフェースからのコマンドを待つ。サポ
ート・システムからエンジンの事象ハンドラに渡される
一部の事象によって、ユーザ・インタフェース構成要素
に信号が送信され、それによって、ユーザが通知を受
け、必要に応じて、コマンドを介してエンジンにフィー
ドバックできる応答を得ることができる。エンジンは、
呼出しが進行を開始するのと同時に接続状態に入る。エ
ンジンは、進行中の呼出しがなくなるのと同時に準備完
了状態に戻る。エンジンは、この状態の間、１つの例外
であるshutdownコマンドを除き、準備完了状態と同じ１
組のコマンドを受け入れる。エンジンは、ユーザ・イン
タフェースが応答し、あるいはサポート・システム事象
が発生するのを待つときは必ず処理状態に入る。この状
態の間、呼出しなどのある種のコマンドは拒否され、
“engine is busy"指示が表示される。SHARE_REQUESTな
どのある種のサポート・システム事象も拒否される。

エンジンは、NODE_SHUT_DOWN_REQUEST事象が受信され
受け入れられるのと同時に終了状態に入る。遮断を進行
させるにはエンジンが準備完了状態でなければならず、
呼出しが進行中の場合はまずそれを終了しなければなら
ないことに留意されたい。エンジンは、CALL_MANAGER_R
EQUESTを受け入れるのと同時にレザイン状態に入る。こ
の状態は、エンジンが終了するという点で終了状態に類
似しているが、サポート・システムの残りは終了しな
い。エンジンは、準備完了状態の場合にだけレザイン
し、呼出しが進行中の場合はまずそれを終了しなければ
ならない。

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

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

○APP_REGISTERED これは、（ローカル）アプリケーシ
ョンがregister_app呼出しを発行するときにレイズされ
る。

○MONITOR_EVENTS 非共用のローカル効果とリモート効
果とを見るには、呼出しマネージャがこれらの事象を監
視しなければならない。

○PASSIVE_LINK_REQUEST これは、システムがこのノー
ドにある資源を使用して他のノードのニーズをサポート
したいときにレイズされる。

○PASSIVE_LINS_RELEASE これは、このノードにある資
源がもはや、他のノードのニーズをサポートするために
システムによって必要とされないときにレイズされる。

○SET_CALL_MANAGER これは、他のアプリケーションが
set_call_manager呼出しを発行したときにレイズされ
る。

○SHARE_REQUEST これは、指定されたアプリケーショ
ンとの共用を求める、他のノードからの要求が受信され
たたきにレイズされる。

○SHARE_REJECTED これは、ローカル・アプリケーショ
ンが共用要求を拒否したときにレイズされる（通常、あ
る種のエラーの結果として）。

○SHUT_DOWN_REQUEST これは、このノードにあるシス
テムの遮断を求める、ユーザまたはアプリケーションに
よる要求が出されたときにレイズされる。

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

○APP_DEREGISTERED これは、awareアプリケーション
が終了したときにレイズされる。

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

Register_app 呼出しマネージャは、始動するアプリケーションの名
前を、適切な呼出し用の共用セット中のアプリケーショ
ンのリストと非共用リストのうちの活動状況の方に追加
して記録する。呼出しが活動状況でありアプリケーショ
ンがユーザによって始動された場合、呼出しマネージャ
は、アプリケーションが呼出し全体にわたって共用され
るように、呼出し中の各リモート・ノードに、指定され
た共用呼出しを発行する。アプリケーションが着信共用
要求の結果として呼出しマネージャによってローンチさ
れた場合、呼出しマネージャはリモート・ノード／アプ
リケーションに代わってローカルshareを発行すること
によってshareを完了する。

アプリケーションが終了すると、その名前が適切なリ
ストから削除される（以下のAPP_DEREGISTEREDの項参
照）。

呼出しマネージャは常に、APP_REGISTERED事象に対し
てRC_OKを返す。

PASSIVE_LINK_REQUEST この事象は、簡単な方法で処理される。呼出しマネー
ジャは、Passive Workingオプションの状態を検査す
る。該状態がpermitの場合、要求は受け入れられるが、
denyの場合は拒否される。askの場合、呼出しマネージ
ャは、要求が得け入れられるかどうかをユーザに尋ねる
ダイアログ・ボックスを表示して（パネルは、要求に関
するできる限り多くの情報を表示する）、次いでユーザ
の応答に応じて（RC_OKまたはRC_FAILを返すことによっ
て）要求を受け入れ、または拒否する。

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

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

呼出しマネージャは、すべての事象に対してRC_OKを
返す。

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

SET_CALL_MANAGER 呼出しマネージャは、RC_OKを返すことによってこの
事象に応答する。これによって、呼出しマネージャの役
割を新しいアプリケーションに移すことができる。

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

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

要求が呼出しマネージャからのものでない場合、間違
いなく、すでに既存の呼出しのパーティとなっているノ
ードからのものである。このため、着信共用要求は常に
受け入れられる。着信共用要求が呼出しIDを含むことに
留意されたい。これは、所与の１対のノードが複数の呼
出しを共有することができ、その結果得られるあいまい
さを解消することができるからである。呼出しマネージ
ャは、共用要求を受け入れるために、対応するアプリケ
ーションをローンチしようとする。呼出しマネージャ
は、共用要求で使用されたターゲット・アプリケーショ
ンとKEYWORDが一致するAPPLICATIONSセクション中の項
目をLAKES.INIファイルで探す。１つも見つからない場
合、エラーが報告される。項目が見つかった場合、プロ
ファイル項目中の値を使用して、ローンチ呼出しのフィ
ールドが埋められ、次いで該呼出しが実行される。APPL
ICATIONSセクションの例を以下に示す。

［applications］ chat＝c:＼lakes＼apps＼chat.exe,c:＼lakes＼work,… chalkboard＝c:＼lakes＼apps＼chalk.exe,c:＼lakes＼
work,… filetransfer＝c:＼lakes＼apps＼xfer.exe,c:＼lakes
＼work,… 呼出しマネージャは、対応するRegistetr_app事象が
発生したときに、ローンチされたプログラムを再び共用
しようとしない（前述のAPP_REGISTERED事象の項参照）
ように、該プログラムのハンドルを記録する。ローンチ
が失敗すると、RC_SHARE_REJECTEDが返される。一方、
ローンチが成功した場合、呼出しマネージャはRC_SHARE
_NO_CONFIRMを返す。ローンチされたアプリケーション
が後でregister_appを発行すると、呼出しマネージャは
共用呼出しを発行する。次いで、アプリケーションはRC
_SHARE_CONFIRMEDを返すべきである。

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

SHARE_REJECTED 上述のように、呼出しマネージャによってローンチさ
れたアプリケーションは、登録されると、呼出しマネー
ジャによって発行されたshareのターゲットになる。通
常、該アプリケーションは、呼出しマネージャがすでに
呼出しを受け入れているのでRC_SHARE_CONFIRMEDで応答
すべきである。アプリケーションが共用を受け入れるこ
とができない場合（たとえば、資源不足のために）、呼
出しマネージャと最初のリモート・アプリケーションと
に拒否が送信される。呼出しマネージャは、最初の共用
を「忘れて」RC_OKを返すことによって応答する。

SHUT_DOWN_REQUEST 呼出しマネージャはRC_OKを返すことによってこの事
象に応答する。これによって遮断を続行することができ
る。これによって、さらに、システムが実際に遮断する
際に、すべてのアプリケーション（呼出しマネージャを
含む）がSHUT_DOWN事象を受信する。呼出しマネージャ
は、他の供給されたアプリケーションと同様に、登録を
取り消すことによってこの事象に応答する。

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

1.target_appliacationパラメータが空の信号。そのよ
うな事象はCall Managerコマンドとみなされる。

2.target_applicationパラメータがアプリケーションを
ハンドルでなく名前で表す信号。呼出しマネージャはこ
の名前を以下のように処理する。

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

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

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

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

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

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

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

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

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

5.ユーザＡが呼出しを切る。

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

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

2.Aにいるユーザがチャット・アプリケーションを始動
すると、Ａにある呼出しマネージャ（register_app事象
を調べる）がshareを発行する。Ｂで、呼出しマネージ
ャが、対応するアプリケーションに対するlaunchを発行
することによって共用要求を受け入れる。

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

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

5.最後に、ユーザＡが通話を切り、Ａにある呼出しマネ
ージャがunshareを発行し、したがって呼出しが終了す
る。

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

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

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

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

○終了を要求されたときに、まずremove_ports、次いで
任意選択でunshare、次いでderegister_app 通常、アプリケーションがshareまたはunshareを発行
することは必要とされない。なぜなら、呼出しマネージ
ャがこれらを処理するからである。

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

○SHARE_REQUESTでは、SHARE_CONFIRMEDが返されるべき
である。というのは、この事象は、すでに呼出しを受け
入れることを決定した呼出しマネージャからのローカル
shareの結果だからである。他の処理を行う必要はな
い。

○SHARE_CONFIRMEDの結果はRC_OKになるべきであるが、
そうでない場合、SHARE_CONFIRMEDを無視することがで
きる。

○SHARE_REJECTEDは発生してはならない（すべてのSHAR
E_REQUESTを受け入れるべきであるから）。

○SHUT_DOWNの結果はRC_OKになるべきであり、アプリケ
ーションは次いで、終了すべきであり（たとえば、OS/2
PM環境では、それ自体にWM_QUITメッセージを通知する
ことによって）、あるいは少なくとももはやAPI呼出し
を発行してはならない。

○UNSHAREの結果はRC_OKになるべきであるが、そうでな
い場合、UNSHAREを無視することができる。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ミッチェル、ハリー、デヴィッド イギリス国サーレイ、リッチモンド・ア ポン・テイームズ、ザ・ハーミテイジ18 (72)発明者 ランバート、ハワード イギリス国ハンプシャー、サザンプト ン、ヘッジ・エンド、ノルデック・ガー デンズ22

Claims (8)

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