この章では、ToolTalk サービスの基本概念について説明します。
ToolTalk サービスを使用すると、独立したアプリケーションが、互いに直接認識していなくても通信できます。アプリケーションは、ToolTalk メッセージを作成し、送信することで相互に通信します。ToolTalk サービスは、これらのメッセージを受信し、受信側を判別してから、そのメッセージを適切なアプリケーションに配信します。この通信の様子を図 1-1 に示します。
次に示すシナリオは、ToolTalk サービスを利用することによって、業務上の問題をどのように解決できるかを示す例です。これらのシナリオで使用するプロトコルは、架空のものです。
ToolTalk デスクトップサービスメッセージセットを使用することにより、アプリケーションは、ユーザーの介入なしで他のアプリケーションを統合および制御できます。この節では、デスクトップサービスメッセージセットの実行方法を示す 2 つのシナリオを説明します。
フロントエンドのグラフィカルユーザーインタフェース (GUI) が、データファイルがアプリケーションに気づく (または「知っている」) ように要求するには、アプリケーションレベルのプログラムが、ユーザーの要求を翻訳する必要があります。このアプリケーションレベルのプログラム (「スマートデスクトップ」と言います) には、Solaris のファイルマネージャ、Apple 社の Macintosh ファインダ、Microsoft 社の 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」に貼り付けます。
「文書 B」は、カットしたデータの転送について「文書 A」と折衝します。
文書 Aが提供するデータのどの型についても「文書 B」が認識しない場合、「文書 B」は「タグ付きメディア型」を要求します。「文書 B」は、タグ付きメディア型を使用して、そのメディア型を認識可能なメディア型へ変換するように要求する ToolTalk メッセージを送ります。
登録されている変換ユーティリティはその要求を受け、変換された後のバージョンのメディア型を「文書 B」へ返します。
変換されたデータの「文書 B」へのペーストが実行されます。
CASE 連携メッセージセットによって、アプリケーションは、ユーザーの介入なしで他のアプリケーションを統合または制御できます。この節では、CASE 連携メッセージセットの使用方法を示すいくつかのシナリオを示します。
このシナリオでは、リリースされたアプリケーションに対するバグの修正方法の完全なサイクルを通して進みます。まず、バグレポートを受け取り、バグ修正に必要な処理を記述することから始まります。
自分のアプリケーションに問題があるというバグレポートを受け取ります。
自分の CASE 環境を起動します。
CASE ユーザーインタフェースが表示されます。実行したい機能は、この CASE ユーザーインタフェースで利用可能です。
バグレポートに記述されている問題点の写しとして、テストケースを書きます。
デバッグ機能を選択して、テストケースに対してアプリケーションを実行します。
デバッグ要求が送信されます。
メッセージ環境は、デバッグアプリケーションを選択します。CASE 環境で実行中のアプリケーションのインスタンスが見つけられない場合は、自動的にデバッガを起動します。
デバッグアプリケーションは、要求を受信し、バイナリをロードします。
コードをテストし、デバッグウィンドウでデバッグ状態を再検査します。
関数呼び出しが誤った引数で渡されているところを見つけます。
編集機能を選択して、このコードを編集します。
デバッグツールは、編集要求を送信します。
ソースエディタは、指定されたソースファイルを編集するようにというメッセージを受信します。
ソースコードを修正したいので、チェックアウト機能を選択します。
ソースコードエディタは、チェックアウト要求を送信します。
ソースコードエディタは、チェックアウト通知を受信し、バッファ状態を修正可能にします。
ソースコードを編集してバグを修正し、構築機能を選択して、アプリケーションを構築します。
構築要求が送信されます。
構築アプリケーションは、構築要求を受信し、構築を実行します。
構築を完了すると、構築アプリケーションは「構築完了」通知を送信します。
デバッガは、「構築完了」通知を受信し、新たに構築されたアプリケーションバイナリを再ロードします。
アプリケーションを再テストして、バグ修正がうまくいったかどうかを確認します。
CASE 環境を終了します。
終了要求は、ソースコードエディタ、デバッガ、バージョンマネージャ、および構築アプリケーションへ送信されます。
ファイル名マッピング機能は、ToolTalk APL の一部を構成するものです。ToolTalk メッセージパッシングとは、独立してこれらを使用することによって、ネットワークから見えるファイル名の標準形式のエンコードまたはデコードを行います。共通ファイルにアクセスする必要のあるアプリケーション内に、これらの標準形式を渡すことができます。ファイルの参照を行うホストによって、このファイルのパス名は異なる可能性があります。たとえば、ホスト A のファイルが /home/fred/test.c でも、他のホストでは /net/A/export/home/fred/test.c の場合もあります。ファイル名マッピング API は、NFS から見ることができるファイル名を標準的な名前に変換し (tt_host_file_netfile() で)、それが各ホストのアプリケーションに渡されます。別のホストは、その標準名を API (tt_host_netfile_file()) に渡して起動プログラムで使える UNIX パス名に戻します。
Solaris 2.6 リリースおよびその互換バージョンでは、ToolTalk ライブラリは、マルチスレッド対策が施されています。マルチスレッド環境で ToolTalk を実行したいユーザーは、そのままシングルスレッドで使用することも、必要に応じてスレッドごとのデータを提供する (たとえば、procid やセッション ID など) 複数の新規 API 呼び出しを使用することもできます。
アプリケーションは、ToolTalk メッセージを作成、送信、または受信することによって、他のアプリケーションと通信します。送信側は、メッセージを作成、書き込み、または送信します。ToolTalk サービスは受信側を判別し、そのメッセージを受信側に配信します。受信側はメッセージを検出し、メッセージ内の情報を検査してから、メッセージを破棄するか、操作を実行してその結果を応答します。
ToolTalk メッセージの構造は簡単で、アドレス、サブジェクト、および配信情報を含んでいます。ToolTalk メッセージを送信するために、アプリケーションは空のメッセージを取得し、メッセージ属性を書き込んだ後、メッセージを送信します。送信を行うアプリケーションは、次の情報を提供する必要があります。
メッセージが通知か、要求か、提供物なのか (すなわち受信側がメッセージに応答するかどうか)
受信側と送信側は、どのような処理対象を共有しているか (たとえば、受信側は、特定のユーザーセッションで実行されているか、または特定のファイルを処理の対象としているか)
送信側アプリケーションは、メッセージ配信の範囲を限定するために、メッセージ内にさらに情報を指定できます。
ToolTalk の重要な特徴は、送信側が受信側について何も知らなくてかまわないということです。これは、メッセージを受信したいアプリケーションの方が、受け取りたいメッセージがどのようなものかを明示的に示すからです。メッセージの型に関する情報は、「メッセージパターン」という形で ToolTalk サービスに登録されます。
アプリケーションはインストール時または実行時に、メッセージパターンを ToolTalk サービスに対して指定します。メッセージパターンは、メッセージと同様に作成します。つまり、どちらの場合も同種の情報を使用します。アプリケーションは受信したいそれぞれの型のメッセージについて、空のメッセージパターンを取得し、属性を書き込み、そのパターンを ToolTalk サービスに登録します。これらのメッセージパターンは通常、アプリケーションが相互に合意しているメッセージプロトコルと一致します。アプリケーションは、個々の使用に応じてさらにパターンを追加できます。
ToolTalk サービスは、送信側アプリケーションからメッセージを受信すると、メッセージ内の情報と登録されているパターンとを比較します。一致するものが見つかると、ToolTalk サービスは、パターンがメッセージと一致するすべての受信側アプリケーションにメッセージのコピーを配信します。
アプリケーションは、受信したいメッセージを記述したパターンごとに、メッセージを「処理」または「監視」できるかを宣言しています。多数のアプリケーションがメッセージを監視できますが、メッセージを処理できるアプリケーションは 1 つだけです。これは、要求された操作が確実に一度だけ行われるようにするためです。ToolTalk サービスが、メッセージを処理するハンドラを見つけ出せなかった場合は、そのメッセージを送信側アプリケーションに返し、配信が失敗したことを示します。
ToolTalk サービスは、メッセージを特定のプロセスに配信する必要があると判断すると、メッセージのコピーを作成し、受信待ちメッセージがあることをそのプロセスに通知します。受信側アプリケーションが実行中でない場合は、ToolTalk サービスは、アプリケーション起動方法に関する指示 (インストール時にアプリケーションが指定したもの) を検索します。
プロセスは、メッセージを検索し、その内容を検査します。
操作が完了したという情報がメッセージに含まれている場合は、プロセスは、その情報を読み取り、メッセージを破棄します。
操作の実行要求が含まれている場合は、プロセスはその操作を実行し、元のメッセージへの応答という形で操作の結果を返します。応答が返されると、プロセスは元のメッセージを破棄します。
ToolTalk サービスは、2 つのメッセージのアドレス方式を提供します。「プロセス指向メッセージ」方式と「オブジェクト指向メッセージ」方式です。
「プロセス指向」メッセージとは、プロセスにアドレス指定されたメッセージのことです。プロセス指向メッセージを作成するアプリケーションは、そのメッセージを指定されたプロセスまたは特定の型のプロセスのどちらかにアドレス指定します。プロセス指向メッセージ方式は、既存のアプリケーションが他のアプリケーションと通信するのに便利な方法です。プロセス指向メッセージ方式をサポートするための修正は簡単で、通常は実行するのに時間はかかりません。
「オブジェクト指向」メッセージは、アプリケーションが管理するオブジェクトにアドレス指定されます。オブジェクト指向メッセージを作成するアプリケーションは、そのメッセージを指定されたオブジェクトまたは特定の型のオブジェクトのどちらかにアドレス指定します。オブジェクト指向メッセージ方式は、特に現在オブジェクトを使用しているアプリケーションまたはオブジェクトを対象として設計されたアプリケーションに便利です。既存のアプリケーションがオブジェクト指向でない場合は、ToolTalk サービスを使えば、アプリケーションがアプリケーションのデータの一部をオブジェクトとして識別することにより、これらのオブジェクトに関する通信ができるようになります。
ToolTalk オブジェクト指向メッセージインタフェース用にコーディングされたプログラムは、ソースコードを変更しなければ CORBA 準拠のシステムに移植できません。
メッセージを受信するグループを判別するために、メッセージの配信範囲を「指定」できます。配信範囲指定を行うことにより、メッセージの配信を特定のセッションまたはファイルに限定します。
「セッション」は、同じ ToolTalk メッセージサーバーのインスタンスを持つプロセスのグループのことです。プロセスが ToolTalk サービスと通信を開始する場合、デフォルトのセッションが配置され (またはセッションが存在していない場合は作成される)、プロセスには「プロセス識別子」(procid) が割り当てられます。デフォルトセッションは、環境変数または X ディスプレイによって配置されます。前者はプロセスツリーセッション、後者は X セッションと呼ばれます。
セッションの概念は、メッセージの配信において重要です。送信側は、あるセッションをメッセージの配信範囲とすることができます。ToolTalk サービスは、現在のセッションを参照するメッセージパターンを持つすべてのプロセスにメッセージを配信します。アプリケーションは、現在の「セッション識別子」(sessid) でメッセージパターンを更新するときに、そのセッションを結合します。
このマニュアルでは、アプリケーションの処理対象であるデータを入れる入れ物のことを「ファイル」と呼びます。
ファイルの概念は、メッセージの配信において重要です。送信側は、あるファイルをメッセージの配信範囲とすることができます。また、ToolTalk サービスは、プロセスのデフォルトセッションに関わらず、そのファイルを参照するメッセージパターンを持つすべてのプロセスにメッセージを配信します。アプリケーションは、現在のファイルのパス名でメッセージパターンを更新するときに、そのファイルを結合します。
また、1 つのセッション内で、あるファイルをメッセージの配信範囲とすることもできます。ToolTalk サービスは、そのファイルとセッションの両方を参照するメッセージパターンを持つすべてのプロセスにメッセージを配信します。
ファイルの配信範囲指定機能を使用できるのは、NFSTM ファイルシステムと UFS ファイルシステムだけです。たとえば、tmpfs ファイルシステムでは、この機能は使用できません。
ToolTalk サービスを使用できるようにアプリケーションを変更する前に、ToolTalk 「メッセージプロトコル」を定義 (または配置) する必要があります。メッセージプロトコルとは、アプリケーションが実行を認めた操作を記述した ToolTalk メッセージの集合です。メッセージプロトコル仕様には、メッセージの設定とアプリケーションがメッセージを受信したときの動作が含まれます。
ToolTalk サービスを使用するために、アプリケーションは、ToolTalk アプリケーションプログラミングインタフェース (API) の ToolTalk 関数を呼び出します。ToolTalk API には、ToolTalk サービスに登録する機能、メッセージパターンを作成する機能、メッセージを送信する機能、メッセージを受信する機能、メッセージ情報を検査する機能などがあります。ToolTalk サービスを使用できるようにアプリケーションを変更するには、プログラムに ToolTalk API のヘッダーファイルを組み込む必要があります。また、アプリケーションを変更して、次のことを実現する必要があります。
ToolTalk サービスを初期化し、セッションに参加する
メッセージパターンを ToolTalk サービスに登録する
メッセージを送信する
メッセージパターンの登録を解除し ToolTalk セッションを終了する