独自に開発されたアプリケーションが同時に動作することを要求するコンピュータ・ユーザが増えてきているため、相互運用はソフトウェア開発者にとって重要なテーマになってきています。お互いの機能を共同で使用することにより、相互運用アプリケーションは、単一のアプリケーションが提供するには難しい機能をユーザに提供します。ToolTalk サービスは、個人やワーク・グループで利用される相互運用アプリケーションの開発を簡単に行えるように設計されています。
ToolTalk サービスを使用すると、独立したアプリケーションが互いに直接認識していなくても通信できます。アプリケーションは ToolTalk メッセージを作成し、送信することで相互に通信します。ToolTalk サービスは、これらのメッセージを受信し、受信先を決定してから、そのメッセージを適切なアプリケーションに配信します。この通信の様子を図 1-1 に示します。
この節では、ToolTalk サービスが解決する相互運用に関する問題について説明します。ToolTalk サービスは、アプリケーションが次のようなことを必要とする場合に使用するのに適切な技術です。
ツール互換性
制御統合
ごく一般的なサーバ (たとえば X サーバ) では所有しておらず、予想可能なリスナの集合がないネットワーク透過イベント
自動ツール起動機能
広範囲で使用可能な分散オブジェクトシステム
固定表示オブジェクト
もちろん、相互運用の問題に対して ToolTalk サービスを使用するのは適切でない場合もあります。しかし、アプリケーションが両方の問題 (つまり、ToolTalk サービスが解決するようになっている相互運用に関する問題と ToolTalk サービスが解決するのではない問題) の解決を必要としている場合は、ToolTalk サービスを他の技術と組み合わせて使用できます。
プラグ・アンド・プレイ機能を必要とする場合は、ToolTalk サービスを使用してください。プラグ・アンド・プレイという語は、ツールを同じプロトコルを提供する他のツールと交換可能であることを意味します。つまり、ToolTalk によって与えられるプロトコルをまねするツールをコンピューティング環境に配置 (プラグ) し、プロトコルが示す関数を実行 (プレイ) できます。ツールを変更することなく、お互いに特定の組み込み知識を持っていなくてもツールを併用できます。
アプリケーションが制御統合を要求する場合、ToolTalk サービスを使用してください。制御統合という語は、ユーザの直接介入がなくても共通の目的に向かって一緒に動作するツールのグループを示します。ToolTalk サービスを使うと、簡単で柔軟性のある機能により特定のツール・インスタンスか不特定のサービス・プロバイダに対して任意の要求を発行する制御統合が可能になります。
アプリケーションがネットワーク透過イベントの生成や受信を必要とする場合は、ToolTalk サービスを使用してください。従来のイベント機構 (シグナルやウィンドウ・システム・イベントなど) を使用するには、特別な環境を必要とします。たとえば、プロセスやウィンドウ ID を認識していることなどです。ToolTalk サービスにより、イベントが参照するファイルや、イベントを適用できるネットワーク上のプロセスのグループに関してイベントは自然に記述されます。ToolTalk サービスは、ネットワーク上のいたる所にある配信対象プロセスにイベント (通知と呼ぶ) を配信します。
アプリケーションがネットワーク透過な自動起動機能を必要とする場合は、ToolTalk サービスを使用してください。ToolTalk サービスは、メッセージがネットワークから送信されると、ツールを起動させるメッセージを記述させます。ToolTalk 自動起動機能の使用は簡単で、従来の inetd(1) 機能ほどホストに固有のものではありません。
さまざまなプラットフォームにまたがって使用可能である分散オブジェクト・システムでアプリケーションを作成する必要がある場合は、ToolTalk を使用してください。ToolTalk のオブジェクト・システムは、一般的な UNIX プラットフォームにあるアプリケーションで使用できます。次のアプリケーションでも使用できます。
シングル・スレッドまたはマルチ・スレッドである
コマンド行またはグラフィカル・ユーザ・インタフェースを持っている
独自のイベント・ループ、またはウィンドウ・システムのツールキットのイベント・ループを使用している
ToolTalk のオブジェクト指向メッセージ・インタフェース用にコーディングされたプログラムは、ソースコードを変更をしなければ CORBA 準拠のシステムに移植できません。
アプリケーションが UNIX ファイル・システムでオブジェクトを目立たないように配置する必要がある場合は、ToolTalk サービスを使用してください。
この節にあるシナリオは、ToolTalk サービスを利用することによって、業務上の問題をどのように解決できるかを示しています。これらのシナリオで使用するメッセージ・プロトコルは架空のものです。
ToolTalk デスクトップ・サービス・メッセージ・セットを使用することにより、アプリケーションは、ユーザの介入がなくても他のアプリケーションを統合およびコントロールできます。この節では、デスクトップ・サービス・メッセージ・セットの実行方法を示す 2 つのシナリオ (「スマート・デスクトップ」と 「統合ツールセット」) について説明します。
この節のシナリオは、ユーザの要求を翻訳するアプリケーション・レベルのプログラムで ToolTalk サービスを使用する方法を示すためのものです。共通デスクトップ環境プロダクトにより ToolTalk サービスにユーザの要求を翻訳させる方法を示すためのものではありません。
グラフィカル・ユーザ・インタフェース (GUI) のフロント・エンドに対するユーザの共通した要求は、データ・ファイルがアプリケーションに気づく (または「知っている」) ようにできることにあります。これを行うには、アプリケーション・レベルのプログラムがユーザの要求を翻訳する必要があります。このアプリケーション・レベルのプログラム (スマート・デスクトップという) には、アップル社の Macintosh ファインダ、マイクロソフト社の Windows ファイル・マネージャ、共通デスクトップ環境のファイル・マネージャなどがあります。スマート・デスクトップの主な共通要件は、次のとおりです。
ファイルを取得する
アプリケーションを決定する
アプリケーションを起動する
ToolTalk サービスは、ツールのクラスが特定のデータ型を編集できるようにすることによって柔軟性が増します。次のシナリオでは、デスクトップ・サービス・メッセージ・セットをエンドユーザに対して透過的なスマート・デスクトップとして実行する方法を説明します。
ダイアンが [ファイルマネージャ] アイコンをダブルクリックします。
ファイル・マネージャが開き、ダイアンの現在のディレクトリ内のファイルを表示します。
ダイアンは、データ・ファイルのアイコンをダブルクリックします。
ファイル・マネージャは、アイコンで表現されているファイルの表示を要求します。また、表示メッセージ内のファイル・タイプを符号化します。
ToolTalk セッション・マネージャは、登録されたアプリケーション (この場合はアイコン・エディタ) に表示メッセージ内のパターンを照合して、ダイアンのデスクトップ上で実行中のアプリケーションのインスタンスを見つけます。
ToolTalk セッション・マネージャがアプリケーションの実行中のインスタンスを見つけられない場合は、静的に定義した ptype をチェックし、メッセージ内のパターンに最も一致するアプリケーションを起動します。一致する ptype がないと、ファイル・マネージャに異常終了を返します。
アイコン・エディタは表示メッセージを受け取り、自分のアイコン化を解除し、自分を一番上に表示します。
ダイアンは、ファイルを手動で編集します。
デスクトップ・サービス・メッセージ・セットを実行できるもう 1 つの重要なアプリケーションは、統合ツールセットです。これらの環境は、垂直のアプリケーション (CASE ソフトウェア開発者用ツールセットなど) または水平の環境 (複合ドキュメントなど) に適用できます。その両方のアプリケーションの共通点は、総合的な解決法が 1 つの特定のタスクをうまく実行するように設計されている専門のアプリケーションから構築されたという前提があることです。統合ツールセット・アプリケーションには、テキスト・エディタ、描画パッケージ、ビデオ・ディスプレイ・ツール、オーディオ・ディスプレイ・ツール、コンパイラのフロント・エンド、デバッガなどがあります。統合ツールセット環境には、相互に呼び出して対話し、ユーザからの要求を処理するアプリケーションが必要です。たとえば、ビデオを表示するには、エディタがビデオ・ディスプレイ・プログラムを呼び出します。完成したコードのブロックを確認するには、エディタがコンパイラを呼び出します。
次のシナリオでは、デスクトップ・サービス・メッセージ・セットを統合ツールセットとして実行する方法を説明します。
ブルースはエディタを使用して複合ドキュメントを扱う作業をしています。
ソースコード・テキストの一部を変更することにします。
ブルースは、ソースコード・テキストをダブルクリックします。
ドキュメント・エディタは、まずソースコードが表すテキストを判別し、その後そのソースコードがどのファイルに入っているかを判別します。
ドキュメント・エディタは、ファイル名をメッセージのパラメータとして使用し、編集メッセージ要求を送信します。
ToolTalk セッション・マネージャは、登録されたアプリケーション (この場合はソースコード・エディタ) に編集メッセージ内のパターンを照合して、ブルースのデスクトップ上で実行中のアプリケーションのインスタンスを見つけます。
ToolTalk セッション・マネージャがアプリケーションの実行中のインスタンスを見つけられない場合は、静的に定義した ptype をチェックし、メッセージ内のパターンに最も一致するアプリケーションを起動します。一致する ptype がないと、ドキュメント・エディタ・アプリケーションに異常終了を返します。
ソースコード・エディタが編集メッセージ要求を受け取ります。
ソースコード・エディタは、ソースコード・ファイルが構成コントロールを受けていると判別し、ファイルをチェックするためのメッセージを送信します。
そのメッセージをソースコード制御アプリケーションが受け取り、要求されたファイルの読み取り書き込み用コピーを作成します。その後、ファイル名をソースコード・エディタに戻します。
ソースコード・エディタは、ソース・ファイルが入っているウィンドウを開きます。
ブルースは、ソースコード・テキストを編集します。
ToolTalk ドキュメント・メディア交換メッセージ・セットは、非常に柔軟性があり、強力です。この節では、次のような ToolTalk ドキュメント・メディア交換メッセージ・セットの 3 つの使用方法について説明します。
マルチメディアのオーサリング・アプリケーションへの統合
既存のアプリケーションへのマルチメディア拡張機能の追加
メディア変換機能の追加による X のカット&ペースト機能の拡張
マルチメディア機能をアプリケーションに統合することによって、アプリケーションのエンド・ユーザは、さまざまなメディアの型をそれらのドキュメントに埋め込むことができます。
通常、メディア・オブジェクトを表すアイコンは、ドキュメントに埋め込まれます。埋め込まれたオブジェクトを選択すると、ToolTalk サービスは自動的に適切な外部メディア・アプリケーションを起動し、オブジェクトは次のシナリオで説明するように処理されます。
ダニエルがマルチメディア・オブジェクトが入っているドキュメントを開きます。
ウィンドウがさまざまなメディアの種類 (音声、画像、グラフィックなど) を表す複数のアイコンでドキュメントを表示します。
ダニエルは、 [音声] アイコンをダブルクリックします。
音声アプリケーション (プレイヤと呼ぶ) が起動され、録音済みの音声が再生されます。)
録音状態を編集するために、ダニエルはアイコンを 1 回クリックして選択し、3 番目のマウス・ボタンを使用して [編集] メニューを表示します。
編集アプリケーションが起動され、ダニエルはメディア・オブジェクトを編集します。
ToolTalk ドキュメント・メディア交換メッセージ・セットによって、アプリケーションは他のマルチメディア・アプリケーションを使用して、その機能または性能を拡張することもできます。たとえば、次のシナリオで示すように、カレンダ・マネージャを拡張し、オーディオ・ツールを使って、音声ファイルをアポイントメントの覚え書きとして再生することもできます。
シェルビーは、自分のカレンダ・マネージャを開き、アポイントメントを設定します。
シェルビーが [音声応答] ボタンをクリックすると、オーディオ・ツールが起動します。
シェルビーは、たとえば「レポートを持ってくる」といったようなメッセージを記録します。
シェルビーがアポイントの覚え書きを実行すると、カレンダ・マネージャはオーディオ・ツールを起動し、シェルビーが録音した覚え書きを再生します。
ToolTalk ドキュメント・メディア変換メッセージ・セットは、拡張可能なオープン・エンドの変換機能をサポートできます。次のシナリオは、拡張可能なマルチメディアのカット&ペースト機能の動作を示します。
マリアがメディア型が異なる 2 つのドキュメントを開きます。
マリアがドキュメント A の一部分を選択し、標準の X Window System のカット機能を使用して、その部分をカットします。
マリアは、そのカットした部分をドキュメント B にペーストします。
アプリケーションは、ToolTalk メッセージを作成、送信、および受信することによって、他のアプリケーションと通信します。送信側は、メッセージを作成、書き込み、および送信します。ToolTalk サービスは受信側を判別し、そのメッセージを受信側に配信します。受信側はメッセージを検出してメッセージ内の情報をチェックし、メッセージを破棄するか、オペレーションを実行してその結果を応答します。
ToolTalk メッセージの構造は簡単で、アドレス、サブジェクト、および配信情報のフィールドを含みます。ToolTalk メッセージを送信するため、アプリケーションは空のメッセージを取得し、メッセージ属性を書き込んだ後、メッセージを送信します。送信を行うアプリケーションは、次の情報を提供する必要があります。
通知用メッセージか要求用メッセージか (つまり、受信側がメッセージに応答する必要があるかどうか)
受信側と送信側は、どのような処理対象を共有しているか (たとえば、受信側は特定のユーザ・セッションで実行されているものか、または特定のファイルを処理対象としているものか)
メッセージ配信の範囲を限定するために、送信側アプリケーションはメッセージ内にさらに情報を指定できます。
ToolTalk の重要な特徴は、送信側が受信側について何も認識していなくてもかまわないことです。これは、メッセージを受信したいアプリケーション側が、受け取りたいメッセージの種類を明示的に示すからです。この情報は、メッセージ・パターンとして ToolTalk サービスに登録されます。
アプリケーションは、そのインストール時または実行時にメッセージ・パターンを ToolTalk サービスに指定できます。メッセージ・パターンは、メッセージと同じ方法で作成します。つまり、どちらの場合も同じ型の情報を使用します。アプリケーションは受信したいそれぞれの型のメッセージについて、空のメッセージ・パターンを取得し、属性を書き込み、そのパターンを ToolTalk サービスに登録します。これらのメッセージ・パターンは通常、アプリケーションが相互に使用することにしたメッセージ・プロトコルと一致します。アプリケーションは、個々の使用に応じてさらにパターンを追加できます。
ToolTalk サービスは、送信側アプリケーションからメッセージを受信すると、メッセージ内の情報と登録されているパターンとを比較します。一致するものが見つかると、ToolTalk サービスは、受信側アプリケーションすべてにメッセージのコピーを配信します。
アプリケーションは受信を希望するメッセージを記述したパターンごとに、メッセージを処理または監視できるかどうかを宣言しています。多数のアプリケーションがメッセージを監視できますが、メッセージを処理できるアプリケーションは 1 つだけです。これは、要求されたオペレーションが確実に 1 回だけ実行されるようにするためです。ToolTalk サービスが要求に対するハンドラを見つけだせなかった場合は、そのメッセージを送信側アプリケーションに返し、配信が失敗したことを示します。
ToolTalk サービスは、メッセージを特定のプロセスに配信する必要があると判断すると、メッセージのコピーを作成し、受信待ちメッセージがあることをそのプロセスに通知します。受信側アプリケーションが実行中でない場合、ToolTalk サービスは、アプリケーションの起動方法に関する指示 (インストール時にアプリケーションが指定したもの) を検索します。
プロセスは、メッセージを検索し、その内容をチェックします。
オペレーションが実行されたという情報がメッセージに含まれている場合、プロセスはその情報を読み取ってから、メッセージを破棄します。
オペレーションの実行要求がメッセージに含まれている場合、プロセスはそのオペレーションを実行し、元のメッセージへの応答という形でオペレーションの結果を返します。応答が送信されると、プロセスは元のメッセージを破棄します。
ToolTalk サービスは、メッセージを配布する 2 つの方式を提供します。プロセス指向メッセージ方式とオブジェクト指向メッセージ方式です。
プロセス指向メッセージとは、プロセスにアドレス指定されたメッセージです。プロセス指向メッセージを作成するアプリケーションは、指定されたプロセスか特定の型のプロセスのどちらかにそのメッセージをアドレス指定します。プロセス指向メッセージ方式は、既存のアプリケーションが他のアプリケーションと通信するのに便利な方法です。プロセス指向メッセージ方式をサポートするための修正は簡単で、通常は実行するのにもあまり時間はかかりません。
オブジェクト指向メッセージは、アプリケーションが管理するオブジェクトにアドレス指定されます。オブジェクト指向メッセージを作成するアプリケーションは、指定されたオブジェクトか特定の型のオブジェクトのどちらかにそのメッセージをアドレス指定します。オブジェクト指向メッセージ方式は、現在オブジェクトを使用しているアプリケーション、またはオブジェクトを対象として設計されたアプリケーションに対して特に便利です。既存のアプリケーションがオブジェクト指向でない場合は、ToolTalk サービスを使うと、アプリケーションがアプリケーションのデータの一部をオブジェクトとして識別するので、これらのオブジェクトに関する通信ができるようになります。
ToolTalk オブジェクト指向メッセージ・インタフェース用にコーディングされたプログラムは、ソースコードを変更しなければ CORBA 準拠のシステムに移植できません。
メッセージを受信するグループを判別するために、メッセージの配信範囲を指定します。配信範囲を指定することにより、メッセージの配信を特定のセッションまたはファイルに限定します。
セッションとは、同じ ToolTalk メッセージ・サーバのインスタンスを持つプロセスのグループのことです。プロセスが ToolTalk サービスとの通信を開始すると、デフォルトのセッションが配置され (または、セッションが存在していない場合は作成され)、プロセスにはプロセス識別子 (procid) が割り当てられます。デフォルト・セッションは、環境変数 (「プロセス・ツリー・セッション」と呼ぶ)、または X ディスプレイ (「X セッション」と呼ぶ) によって配置されます。
セッションの概念は、メッセージの配信において重要です。送信側は、あるセッションをメッセージの配信範囲にできます。ToolTalk サービスは、現在のセッションを参照するメッセージ・パターンを持つすべてのプロセスにメッセージを配信します。現在のセッション識別子 (sessid) でメッセージ・パターンを更新するときは、アプリケーションはそのセッションを結合します。
このマニュアルでは、アプリケーションの処理対象であるデータを入れるコンテナのことをファイルと呼びます。
ファイルの概念は、メッセージの配信において重要です。送信側は、あるファイルをメッセージの配信範囲にできます。また、ToolTalk サービスは、プロセスのデフォルト・セッションに関係なく、そのファイルを参照するメッセージ・パターンを持つすべてのプロセスにメッセージを配信します。現在のファイルのパス名でメッセージ・パターンを更新するときは、アプリケーションはそのファイルを結合します。
また、1 つのセッション内にあるファイルをメッセージの配信範囲とすることもできます。ToolTalk サービスは、そのメッセージ・パターン内にあるファイルとセッションの両方を参照するすべてのプロセスにメッセージを配信します。
ファイルの配信範囲指定機能が使用できるのは、NFSTM ファイル・システムと UFS ファイル・システムだけです。
ToolTalk サービスを使用できるようにアプリケーションを変更する前に、ToolTalk メッセージ・プロトコルを定義 (または配置) する必要があります。メッセージ・プロトコルとは、アプリケーションが実行を認めたオペレーションについて記述した ToolTalk メッセージの集合です。メッセージ・プロトコル仕様の内容は、メッセージの設定およびアプリケーションがメッセージを受信したときの動作です。
ToolTalk サービスを使用するために、アプリケーションは ToolTalk アプリケーション・プログラミング・インタフェース (API) から ToolTalk 関数を呼び出します。ToolTalk API には、ToolTalk サービスに登録する機能、メッセージ・パターンを作成する機能、メッセージを送信する機能、メッセージを受信する機能、メッセージ情報をチェックする機能などがあります。ToolTalk サービスを使用できるようにアプリケーションを変更するには、まずプログラムに ToolTalk API のヘッダ・ファイルを組み込まなければなりません。また、次のことを実現するためにアプリケーションを変更する必要があります。
ToolTalk サービスを初期化し、セッションに参加する
メッセージ・パターンを ToolTalk サービスに登録する
メッセージを送信および受信する
メッセージ・パターンを登録解除し、ToolTalk セッションを終了する