test

ToolTalk ユーザーズガイド

付録 C ToolTalk の標準メッセージセット

標準のメッセージセットは、同じメッセージプロトコルに準拠して自分以外の人が開発したアプリケーションを自動的に統合するようなアプリケーションを開発するためのものです。標準のメッセージセットを定義するために、主要なソフトウェアベンダやエンドユーザーの協力を得て、さまざまな作業が行なわれてきました。ToolTalk の標準メッセージセットは、ToolTalk API の高水準インタフェースで、複数のアプリケーションの制御とアプリケーション間でのデータの統合を簡単に行うための共通の定義と規約を提供します。

この付録で示す標準の ToolTalk メッセージセットについては、『ToolTalk リファレンスマニュアル』を参照してください。

ToolTalk デスクトップサービスメッセージセット

デスクトップを根本的に統合するには、アプリケーション間を制御する基本メッセージセットをアプリケーションでサポートする必要があります。「ToolTalk デスクトップサービスメッセージセット」は、すべてのアプリケーションにこの機能を提供する共通のメッセージセットです。このメッセージセットは、デスクトップアプリケーションの開発者とユーザーのどちらにも役立つ強力なメッセージ処理用プロトコルです。これを使用するとアプリケーションは、他のデスクトップアプリケーションと容易にやり取りできます。また、ローカルでもネットワーク経由でも、透過的な方法で相互に通信できます。

開発目的

アプリケーションを統合的に制御するには、起動、停止、表示制御、入出力データ情報の受け渡しを行うために一定の基本機能が必要です。この機能は、ツールセット中の他のアプリケーションと基本的な制御情報を交換できるよう、すべてのアプリケーションでサポートする必要があります。このような機能を使用すれば、スマートデスクトップや統合スマートツールセットを開発できます。アプリケーション同士でグループを組むことにより、互いに呼び合ってタスクを処理したりやり取りしたりできるため、1 つの統合環境をエンドユーザーに提供できます。

特長

ToolTalk デスクトップサービスメッセージセットは、開発者にとって次の 2 つの利点があります。

  1. ユーザーが直接的に介入しなくても、アプリケーションの基本的な制御を行うことができる。ユーザーの便宜を図るため、ルーチンや共通プロシージャを自動化できる。

  2. 共通の情報交換セットを使用するため、ツールを限定できる。ToolTalk 対応のアプリケーションはすべて、これらの機能を実行できる。

ToolTalk 文書メディア交換メッセージセット

マルチメディアは、今後重要になる技術です。マルチメディア対応のアプリケーション数が増えているにもかかわらず、今日のマーケットの複雑なニーズに応える完全統合型ソリューションを提供しているベンダは 1 つもありません。この「ToolTalk 文書メディア交換メッセージセット」は、マルチメディア技術を真に打開するものです。

このメッセージセットは、マルチメディア技術の開発者とユーザーのどちらにも役立つよう設計した強力なメッセージ処理プロトコルです。これを使用すれば、アプリケーションでお互いのマルチメディア機能を容易に共有できます。また、マルチメディアアプリケーションは、データフォーマットや圧縮方法、従来は制約となっていた技術上の問題点などに関係なく、ローカルでもネットワーク経由でも、透過的な方法でお互いに通信できます。

開発目的

いくつかのベンダがアプリケーション間通信のために協力関係を結んでいますが、エンドユーザーで解決できる範囲は限られています。しかし、ToolTalk 文書メディア交換メッセージセットを使用すれば、どのようなアプリケーションでも一連のマルチメディア機能を、他のどのようなアプリケーションとも透過的な方法で共有できます。

このマニュアルでは、Sun Microsystems® と、マルチメディアハードウェアやマルチメディアソフトウェアを開発している主要な独立ベンダーの協力によって開発した規格を紹介しています。

アプリケーションは、この簡単なプロトコルを使用することにより、個々のサービス提供者を気にすることなく、数多くのマルチメディアサービス用の ToolTalk インタフェースをすぐに、しかも簡単に作成できます。アプリケーションのグループ全体で互いに「プラグアンドプレイ」できるため、音声、ビデオ、グラフィックス、電話、その他のメディアソースを、新規および既存のアプリケーションに統合できます。

「プラグアンドプレイ」とは、同じプロトコルに準拠するツールであれば、他のどのツールとでも交換できることを意味します。つまり、一定の ToolTalk プロトコルに準拠したツールであれば、ユーザーのコンピュータ環境に搭載 (plug) でき、プロトコルが指示する機能を実行 (play) できます。それぞれのツールは変更する必要はなく、互いに個々の機能をあらかじめ知らなくても、一緒に協力して動作できます。たとえば、文書の一部にビデオを入れ、そのビデオを他のアプリケーションに再生させるような文書処理アプリケーションも作成できます。

ToolTalk 文書メディア交換メッセージセットは、効率のよい汎用メッセージセットを定義したもので、メディア制御とデータ交換の機能があります。このプロトコルは、メディアプレイヤ用、エディタ用、ユーザー用のエディタメッセージから構成されています。

特長

ToolTalk 文書メディア交換メッセージセットは、開発者にとって次の 2 つの利点があります。

  1. 新規および既存ソフトウェアへのマルチメディアの組み込みが簡単

    マルチメディアの機能をどのアプリケーションにも簡単に追加できます。ToolTalk 文書メディア交換メッセージセットを使用すれば、他の開発者のマルチメディア技術を利用できるため、システムの機能を向上させながら、開発に要する時間やコストを低減できます。

  2. エンドユーザーの戦略範囲を拡大するフレームワークの作成

    ToolTalk 文書メディア交換メッセージセットを使用すれば、アプリケーションの連携が促進されるため、エンドユーザーや開発者は得意分野に的を絞った戦略を新しく立てることができます。これにより、以前は対象外であったマーケットを開拓できるため、ユーザーの製品を新たに展開できます。

ToolTalk メッセージの一般的な定義と表記法

ToolTalk メッセージには、ToolTalk 独自の定義で使用する用語があります。この節では、これらの用語と ToolTalk メッセージのマニュアルページで使用している表記法を定義します。

表 C-1 文書メディア交換メッセージセットの用語

情報の種類 

説明 

ヘッダー 

次のフォーマットでメッセージを 1 行で説明したもの。 

MsgName (Tt_class)

MsgName はメッセージ名、Tt_class は要求か通知を表す。

名前 

メッセージ名と 1 行のメッセージの説明 

説明 

メッセージの要求操作または通知イベントについての説明 

フォーマット 

 

メッセージを次のようなフォーマットの ToolTalk 型ファイル構文 (ToolTalk 型コンパイラ tt_type_comp が処理する構文に似ている) で表記したもの。

<fileAttrib> <opName> (<requiredArgs> [<optionalArgs>]); 

フォーマットは、メッセージの種類ごとに示される。 

<fileAttrib>: メッセージのファイル属性。必須、オプション、指定不可のいずれかを示す。 

<opName>: 操作やイベント名を「op name」または「op」と呼ぶ。ツールが異なっても、同じ opName で異なるものを表さないことが重要である。このため、標準以外のメッセージの opName は一意にしなければならない。たとえば、「Acme_Hoarktool_My_Frammistat」のように、<会社名><製品名> という接頭辞を付けるのは良い方法である。 

<requiredArgs>、<optionalArgs>: メッセージに常に指定しなければならない引数。個々の引数は、次のフォーマットで表される。 

<mode> <vtype> <argument name> 

mode には in、out、inout のどれか 1 つを指定する。vtype はメッセージ引数のデータの種類を記述する文字列であり、プログラマが定義する。argument name は引数名を表す。

ToolTalk サービスは vtype を使用して、送信メッセージのインスタンスと登録済みメッセージパターンを照合する。通常、vtype は単一の決まったデータ型に対応する。 

必須引数 

メッセージに常に指定しなければならない引数。 

<vtype> <argumentName> 

「vtype」は、メッセージ引数のデータの種類を記述する文字列であり、プログラマが定義する。ToolTalk が vtype を使用するのは、送信メッセージのインスタンスと登録済みメッセージパターンの照合を行うためだけである。 

通常、vtype はすべて単一の決まったデータ型に対応させる。ToolTalk 引数のデータ型は、整数、文字列、バイトのいずれかである。メッセージ引数やパターン引数のデータ型は、その値を設定する ToolTalk API 関数で決まる。 

引数名は、C の typedef でのパラメタ名と同様、引数の構文の意味を分かりやすくするコメントである。 

オプション引数 

メッセージに指定してもよい引数。特に断らないかぎり、必須引数の後であれば、オプション引数をどのように組み合わせても、どのような順序で追加してもよい。 

説明 

要求が意味する操作や、通知が知らせるイベントについての説明 

エラー 

要求のハンドラや通知の送信側が設定できるエラーコードの一覧 

通達 - 要求に似た通知です。要求がデータを返さない (または、データが返されても送信側が見ない) 場合、その要求を一連のツールに送る方が便利なことがあります。通達は一種の通知であるため、どのツールがそのメッセージを入手してもデータや応答は得られず、送信側は何も知らされません。

ハンドラ - 要求を受け取る者の procid です。この procid のプロセスは、指示された操作を完了する義務があります。

通知 - イベントを知らせるメッセージです。通知を受信するツールがない場合も複数ある場合もあります。送信側は、ツールが通知を受信したかどうかは分かりません。通知に対して応答できません。

procid - ToolTalk メッセージを送受信する主体を表します。procid は ToolTalk サービスが (tt_open 時に) 作成して渡す身元です。プロセスはメッセージを送受信する際に procid を指定しなければなりません。1 つのプロセスで複数個の procid を使用することも、連携プロセスの 1 グループで 1 つの procid を使用することもできます。)

要求 - 操作を実行するよう要求するメッセージです。要求は、指示された操作を完了する義務のある、ハンドラという受け取る者を 1 つ持ちます。要求に対してハンドラは、異常終了、拒否、または応答が可能です。要求を拒否するハンドラはいくつあってもかまいません。最終的に要求に対して、異常終了させるか応答できるのは 1 つのハンドラだけです。要求を受け取るハンドラが動作していない場合、ToolTalk サービスはハンドラを 1 つ自動的に起動できます。要求を受け取るハンドラが見つからなかった場合やハンドラが要求を異常終了させた場合、その要求は「失敗」という状態で送信側に戻されます。

エラー

tt_message_status を使用すると、応答から Tt_status コードを読み取ることができます。この状態のデフォルトは TT_OK ですが、tt_message_status_set を使用すればハンドラが設定することもできます。異常な状況下 (対応するハンドラがない場合など) では、ToolTalk サービス自身がこのメッセージ状態を設定します。

ToolTalk API が定義する Tt_status 値以外に、メッセージセットごとに定義されるエラー条件があります。それらについては、各メッセージセットの概要を記述した個所に一覧を掲載してあります。そこでは、各エラー条件について次の項目を記述してあります。

ToolTalk 開発の一般的な指針と表記法

Sun では、「開放型プロトコル」を推奨しています。プロトコルは一般に開放的なものであり、「相手を特定しないメッセージ」(つまり、誰がそれを受け取るかを知らずに送信するメッセージ) をサポートしています。この節では、この開放型メッセージプロトコルをサポートするものであれば、どのようなアプリケーションともうまくやり取できるアプリケーションを独自に開発する際の指針を示します。ここで示す指針と原則に従えば、独自に開発した別々のアプリケーションでもさまざまな基準を考案して運用でき、互いにやり取りできます。また、アプリケーションのユーザーはその環境をより細かく制御でき、カスタム化できます。

ToolTalk のアプリケーションを作成する際は、次の原則に従ってください。

  1. 要求相手を特定しない

  2. ツールは必要なときだけ起動する

  3. 要求した操作が完了してから要求に応答する

  4. できるだけ内部状態を持たないようにする

  5. ツールの役割ごとに ptype を 1 つ宣言する

要求相手を特定しない

アプリケーションを完全に開放的な設計にするには、要求の受け取り者を指定しないでください。つまり、要求側のプロセスでは、要求した操作を処理するツールのインスタンスやツールの型も指定しないでください。要求を特定のプロセスに送信すると、ユーザーのリソースや、メッセージを受け取る可能性のあるプロセスのリソースの利用を不要に制限することになります。また、要求を特定の型のツールに送信すると、やり取りできるツールを必要ないのに制限することになります。

メッセージには、要求する操作か通知するイベントを指定してください。メッセージを受け取るプロセスを、メッセージに記述してはいけません。やり取りする相手を各ツールで限定しないほど、ユーザーにとって柔軟なシステムになります。

開放型プロトコルの詳細は、『Designing and Writing a ToolTalk Procedural Protocol』 (Sun Part No. 801-3592-01) を参照してください。

ツールは必要なときだけ起動する

プロトコルを完全に開放型の設計にするには、必要なときだけツールを起動してください。ツールのインスタンスを必要なときだけ起動すると、ユーザーは CPU、画面領域、スワップ空間などをより柔軟に効率よく使用できます。ToolTalk サービスには、ツールのインスタンスの起動時期を決定するための機能として、次のようなものがあります。

操作が完了したら応答する

アプリケーションを完全に開放的な設計にするには、送信側プロセスの要求した操作を完了したら、送信側プロセスにその旨を通知してください。ただし、要求メッセージの送信が非常に短時間で終わるのに比べ、その操作の完了には長時間かかることがあります。送信側プロセスへは、次のどちらかの方法で応答できます。

ToolTalk メッセージはまったく非同期であるため、後者の方法を推奨します。ツールやツールのセッションは、未処理の要求を少なくとも 1 つかかえることになるため、ブロックしてはいけません。

できるだけ内部状態を持たないようにする

アプリケーションを開放的な設計にするには、各メッセージをできるだけそれ自身で完結させてください。プロトコルの状態の数を少なくすると、メッセージは、以前のメッセージや指定した受信側の状態に頼らなくても済みます。

役割ごとにプロセス型を 1 つ宣言する

ToolTalk プロトコルは、各ツールが果たす「役割」(つまり、各ツールが実行するタスクの種類) で表現されます。ToolTalk の ptype は、ツールが動作していないときに処理対象のメッセージを受け取ったらどう処理するかを ToolTalk サービスに指示します。プロトコルを開放的にするには、プロトコルの中の役割ごとに ptype を 1 つ宣言してください。こうすると、ユーザーはそのニーズに応じて、ツールを自由に交換できます。たとえば、録音用には洗練されたサウンドオーサリングツールを使用したいが、再生用には簡単なオーディオツールでかまわないというユーザーもいます。

ptype ごとにメッセージシグニチャを 1 つだけ指定する必要もあります。同一の ptype にメッセージシグニチャを 2 つ以上指定すると、片方のメッセージを処理できるプログラムならすべて、もう一方のメッセージも処理できなければならないと要求することになります。たとえば、「UWriteIt」という ptype には「Display」と「Edit」という 2 つのメッセージシグニチャを指定できます。これは UWriteIt のドキュメントフォーマットを理解するものであれば、どのようなツールでも両方の操作を実行できると思われるからです。

ToolTalk アプリケーションの開発

この節では、設計プロセスを説明します。アプリケーションでは、次の 3 つの手順で簡単に ToolTalk メッセージを送受信できます。

  1. 他のアプリケーションやユーザーとやり取りする方法を決定する

  2. メッセージを選択し、アプリケーションのコンテキスト内での使用方法を定義する

  3. ToolTalk の呼び出しとメッセージをアプリケーションのコードに組み込む

    注 -

    ToolTalk ソフトウェア製品には、既存のアプリケーションに ToolTalk 機能を簡単に追加する方法を示すデモンストレーションが入っています。このデモンストレーションは、『Tool Inter-Operability: A Hands On Demonstration』 (Sun Part No. 801-3593-01) に掲載されています。

    各ツールが連携動作する方法と実行する必要がある操作を定義する

アプリケーションにどのような種類のやり取りが必要か明確に理解することは、アプリケーションの統合を成功させるための必須条件です。これを解析するのに最もよい方法は、アプリケーションの使用方法を示すシナリオを定義することです。このシナリオから、実行する必要のあるやり取りや交換する必要のある情報を定義できます。どのような情報や状態をやり取りするのかを詳細にシナリオに記述しておくと、アプリケーションにメッセージを組み込む際に役立ちます。

    タスクを実現するのに適切なメッセージを選択する

アプリケーションが他のアプリケーションやユーザーとやり取りする方法が決まると、必要なタスクを実現するための各メッセージを決定しなければなりません。

まず、Sun、ANSI、X3H6、CFI などの産業グループから入手できる標準メッセージセットを参照してください。これらのメッセージを使用するよう強く推奨するのは、次の 2 つの理由からです。

  1. 標準メッセージにより標準のインタフェースを文書として入手できます。このインタフェースを使用すれば、他の開発者も連携するアプリケーションを独自に開発できます。カスタマが統合システムを構築する際の関連インタフェースも入手できます。

  2. この標準メッセージセットは、アプリケーションに「汎用プラグアンドプレイ」機能を提供します。この機能を使用すれば、カスタマは複数のアプリケーションを自由に使用してサービスを受けられます。カスタマが自由に使用するアプリケーションを選択して個々のジョブに最適なツールを使用できるため、アプリケーションの開発者は不要な機能を製品でサポートするよう強要されません。

    この標準メッセージセットが設計に役立たない場合は、カスタムメッセージを開発する必要があります。

    標準メッセージにないものを使用する場合は、「media_exchange@sun.com」の文書メディア交換メッセージ協会にお問い合わせください。そのメッセージを標準メッセージセットに追加するかどうかを協会で検討いたします。

    ToolTalk 呼び出しとメッセージをアプリケーションに組み込む

設計段階が完了すると、ToolTalk 機能をアプリケーションに組み込む段階です。

まず、ToolTalk API 呼び出しを使用するすべてのファイルに、ToolTalk ヘッダーファイルをインクルードする必要があります。また、送受信機能を制御するためのパターンの登録と初期設定を行う必要もあります。パターンの登録と初期設定の詳細は、『The ToolTalk Service: An Inter-Operability Solution』(SunSoft Press / Prentice Hall 社発行) を参照してください。

次に、ToolTalk メッセージを送信する機能をアプリケーションに追加します。設計時のシナリオを基にすれば、どのルーチンがどのメッセージを送信するか、各メッセージの引数をどのようにするかは簡単に決定できます。

ToolTalk サービスの初期設定が完了すると、アプリケーションは ToolTalk API でメッセージを作成し、その内容を書き込んで、他のアプリケーションに送信できます。

メッセージ方式に関する問い合わせ先

文書メディア交換メッセージセットに関する質問、コメント、情報の請求は、media_exchange@sun.com の文書メディア交換メッセージ協会までご連絡ください。