お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

W3C マルチモーダル・アーキテクチャー、第 1 回: 概要と課題

分散マルチモーダル・アプリケーションのための新しいアーキテクチャーについて知っておくべきこと

Gerald McCobb (mccobb@us.ibm.com), Advisory Software Engineer, IBM　

IBM に 15 年以上勤務している Gerald McCobb は、現在 WebSphere Business Activity Monitor 開発に取り組んでいます。W3C Multimodal Interaction Working Group にも IBM 代表として参加しています。

概要： W3C Multimodal Interaction Working Group では 2002年以来、マルチモーダル・アーキテクチャーに関する提案の改良を進めています。この 3 回連載記事の第 1 回では、IBM の Gerald McCobb が、この Working Group のここまでの進展の概要を説明します。この新しいアーキテクチャーを早速知って、Web 開発者がこのアーキテクチャーを実装するかどうかを決定する際に検討しなければならない課題について学んでください。

タグを付ける!

日付: 2007年 5月 08日
レベル: 中級
この記事の原文: 英語
アクティビティー： 2054 ビュー
お気軽にご意見・ご感想をお寄せください：

パーソナル・コンピューターや小型機器を対象としたアプリケーションは、キーボード、キーパッド、そしてスタイラスをベースとする対話動作に代わる手段を求める市場の要求に対応するため、急速に発展しています。代わりとなる対話動作のモードとしては音声、デジタル・ペンなどがあり、別々に使用されることもあれば、他のモードと組み合わせて使用されることもあります。例えば、携帯電話のユーザーがフライト情報を調べるために、受話器に向かって「12 月 23 日のボストン発ニューヨーク行きの全フライトを表示」と指示するとします。それに応じて携帯電話の画面にフライト一覧が表示され、ユーザーが口頭またはスタイラスのいずれかでフライトを選択するといったアプリケーションが考えられます。

W3C Multimodal Interaction (MMI) Working Group は 2002 年以来、このようなアプリケーションを開発するための標準フレームワークに取り組んでいます。最近このグループでは、Multimodal Architecture and Interfaces ワーキング・ドラフトの新バージョンを発表しました。この文書はワーキング・ドラフトでしかありませんが、将来的には W3C 勧告となるはずです。MMI Working Group はその目標に向けて大きな進歩を遂げています。

この 3 回連載記事の第 1 回では、MMI Working Group による現在のマルチモーダル・アーキテクチャーの構造についての概要を紹介し、このアーキテクチャーの興味深い機能、そして Web 開発者に課せられる課題を説明します。連載のなかで最も深く検討を行う第 2 回の記事では、多数の XML マークアップ言語 (W3C 勧告と初期のワーキング・ドラフトの両方) を、マルチモーダル・アーキテクチャー実装とのマークアップ・インターフェース (Markup Interface) としてどのように使用できるかという観点から検討します。そして第 3 回では、マルチモーダル・アーキテクチャーの Web サービス実装を紹介し、この実装がそれまでに説明した課題の大部分をどのように解決するかを説明します。

なぜ分散アーキテクチャーなのか

アプリケーションに別のモーダル・インターフェースを追加すればアプリケーションが使いやすくなることは確かですが、小型のクライアント機器では多くの場合、処理要件やリソース要件を到底満たすことができません。携帯電話 1 つを例に取っても、ローカルの音声認識システムを実行するだけのリソースはありません。さらにアプリケーションがカリフォルニア州ロサンゼルスに住むすべての人の名前と住所の読み書きを必要するとなったらもうお手上げです。

このような理由から、小型のクライアント機器に追加して実行するモーダル・インターフェースは、ほとんどの場合、分散されることになります。つまり、インターフェースはリモート・サーバーに常駐し、HTTP や SIP などのネットワーク・プロトコルを使ってクライアント機器と通信するということです。そのため W3C マルチモーダル・アーキテクチャーは分散モダリティー・コンポーネントをサポートし、モダリティー・コンポーネントとサーバー・サイドの対話マネージャーとのリモート・メッセージングのためにコンポーネント・ライフサイクル API を定義しています。しかし、クライアント上でモダリティー・コンポーネントを実行する実装は、マルチモーダル・アーキテクチャーでは許容されるとは言っても、この記事で説明するように Web アプリケーションには実用的ではありません。

マルチモーダル・アーキテクチャー

マルチモーダル・アーキテクチャーが指定するのは、ランタイム・フレームワーク、そしてライフサイクル・イベント API を介してランタイム・フレームワークと通信する 1 つ以上の分散されたモダリティー・コンポーネントです。図 1 に示すように、このアーキテクチャーの構成要素には以下のものがあります。

ランタイム・フレームワーク (Runtime framework): ランタイム・フレームワークはコンポーネント間の通信を制御し、対話マネージャー、配信コンテキスト、そしてデータ・コンポーネントのランタイム・サポートを提供します。
配信コンテキスト (Delivery context component): 配信コンテキストには、静的および動的な機器のプロパティー、環境条件、ユーザー設定が保管されます。配信コンテキストに保管されたこれらのプロパティーは、照会および動的に更新することが可能です。配信コンテキストとのインターフェースの標準化は、W3C Device Independence Working Group が取り組んでいます。
対話マネージャー (Interaction Manager): 対話マネージャーは、ランタイム・フレームワークとモダリティー・コンポーネント間ですべてのメッセージを送受信し、必要に応じてデータ・コンポーネントを照会して更新します。対話マネージャーはダイアログ・フロー、現在の状態、公開データを維持するため、基本的にはここにマルチモーダル・アプリケーションが含まれます。MMI Working Group では現在、対話マネージャー言語の標準化に取り組んでいます。SCXML (State Chart XML) という名前のこの言語は、David Harel によるステートチャート (Statechart、「参考文献」を参照) の XML 実装です。
データ・コンポーネント (Data Component): データ・コンポーネントには、マルチモーダル・アプリケーションの公開データ・モデルが含まれます。
モダリティー・コンポーネント: モダリティー・コンポーネントが実行するタスクは、音声入力の認識、画像の表示、マークアップ言語 (VoiceXML、XHTML、SVG など) の実行などです。モダリティー・コンポーネントは対話マネージャーとのみ直接対話し、イベント・ベースの MMI ライフサイクル API によってのみデータを共有できるため、「疎結合」されていることになります。ユーザー操作はマークアップ言語で実装する必要はありません。ユーザー操作のベースとしては、Java、C#、C++、あるいは別のプログラミング言語を使用できます。

図 1. マルチモーダル・アーキテクチャー
A diagram of the W3C Multimodal Architecture

上に戻る

The life-cycle events API

モダリティー・コンポーネントとランタイム・フレームワークとの間では、以下のイベントが送信されます。

NewContextRequest: モダリティー・コンポーネントはこのオプション・イベントをランタイム・フレームワークに送信して新規コンテキストを要求します。ランタイム・フレームワークはこのイベントに対し、NewContextResponseイベントで応答します。
Prepare: ランタイム・フレームワークはこのオプション・イベントをモダリティー・コンポーネントに送信して、コンポーネントが Start による起動に備えてリソースをプリロードできるようにします。モダリティー・コンポーネントはこのイベントに対し、PrepareResponseイベントで応答します。
Start: ランタイム・フレームワークがモダリティー・コンポーネントを起動すると、コンポーネントは StartResponse イベントで応答します。
Done: モダリティー・コンポーネントは処理を完了すると、このイベントをランタイム・フレームワークに送信します。
Cancel: ランタイム・フレームワークがモダリティー・コンポーネントの処理をキャンセルすると、コンポーネントは CancelResponse イベントで応答します。
Pause: ランタイム・フレームワークがモダリティー・コンポーネントの処理を一時停止すると、コンポーネントは PauseResponse イベントで応答します。
Resume: ランタイム・フレームワークがモダリティー・コンポーネントの処理を再開すると、コンポーネントは ResumeResponse イベントで応答します。
Data: ランタイム・フレームワークとモダリティー・コンポーネントは互いにデータを送信できます。メディエーターとしての対話マネージャーとフォーカスの同期をはじめ、このイベントがすべてのモダリティー間通信のインターフェースとなります。
ClearContext: ランタイム・フレームワークは ClearContext イベントを使用して、モダリティー・コンポーネントと共有していたコンテキストをクリアします。
StatusRequest: ランタイム・フレームワークとモダリティー・コンポーネントは互いの現行状態を要求できます。StatusResponse イベントは、この要求に対する応答として送信されます。

応答はタイムリーに受信されなければならないので、MMI ライフサイクル・イベントを配信するネットワーク・プロトコルは信頼性に優れた専用プロトコルであること、そしてイベントを確実に正しい順序で配信し、認証されたエンドポイントを持っていることが必要です。

上に戻る

Foundations of the architecture

W3C マルチモーダル・アーキテクチャーは主に、Galaxy Communicator とモデル・ビュー・コントローラー (MVC) アーキテクチャー・パターンから派生したものです。Galaxy Communicator は、米国国防総省高等研究計画局 (DARPA) が後援するオープン・ソース・プロジェクトです。分散ハブ・アンド・スポーク方式のこのアーキテクチャーでは、Text-to-Speech (音声合成) の処理を行ったり、音声認識を実行したり、あるいはダイアログを管理したりするサーバーは、スポークの末端に配置されます。サーバー間で送信されるメッセージは、すべてのデータと通信を管理する中央のハブを経由してルーティングされます。

よく知られた MVC 設計パターンは、アプリケーションをモデル、ビュー、コントローラーという 3 つの部分に区分化します。このアーキテクチャーでは通常、モデルがデータとデータ・アクセス・メソッドをカプセル化し、ユーザー・インターフェースであるビューからのイベントをコントローラーが処理します。コントローラーはイベントに応答してモデルを更新し、ビューはモデル内での変更に応じて更新されます。

W3C マルチモーダル・アーキテクチャーは Galaxy Communicator と似ています。マルチモーダルで Galaxy Communicator のハブに相当するのはランタイム・フレームワークです。同様に、マルチモーダル・アーキテクチャーで Galaxy Communicator のサーバーに相当するのは、モダリティー・コンポーネント、配信コンテキスト、そしてデータ･コンポーネントです。マルチモーダル・アーキテクチャーを MVC パターンに例えると、対話マネージャーはコントローラー、データ・コンポーネントと配信コンテキストはモデル、そしてモダリティー・コンポーネントはビューということになります。

通信およびイベント処理

上記の 2 つのアーキテクチャーに基づく W3C マルチモーダル・アーキテクチャーのランタイム・フレームワークは、通信ハブとイベント・プロセッサー両方の役割を果します。モダリティー・コンポーネントに要求されるのは、すべてのイベントとデータをフレームワークに送信し、公平かつタイムリーに他のコンポーネントにルーティングされるようにすることです。図 2 に、MVC アーキテクチャーでのコントローラーのように動作する対話マネージャーを示します。ユーザーが Submit ボタンをクリックすると、サブミット・データが対話マネージャーに送信されます (1)。対話マネージャーはデータを Web サーバーに実行依頼します (2)。対話マネージャーに対する Web サーバーの応答が処理されると (3)、データ・モデルが更新され、更新されたデータは HTML および音声モダリティー・コンポーネントに対して同時に送信されます (4)。その結果、音声コンポーネントによってクライアント機器に送信されたオーディオ・データが、Text-to-Speech (TTS) としてレンダリングされます (5)。

図 2. すべてのデータ・トランザクションを処理する対話マネージャー
The interaction manager seen as a controller and hub

どんなマルチモーダル・アーキテクチャーの実装でも、他のモダリティー・コンポーネントに関連するイベントとデータ (Web サーバーに実行依頼されたフォームも含む) は、対話マネージャーに直接送信されます。2006年12月11日付けの Multimodal Architecture and Interfaces ワーキング・ドラフトのなかで、MMI Working Group は次のように説明しています。

このような理由から適切なアプリケーション設計の慣例となるのが、データを 2 つの論理クラスに分類することです。この論理クラスの一方は特定のモダリティー・コンポーネントのみに関連する専用データ、そしてもう一方は対話マネージャーまたは複数のモダリティー・コンポーネントに関連する公開データです。専用データはモダリティー・コンポーネントがふさわしいと判断すれば管理できますが、バックエンド・サーバーへの実行依頼をはじめとする公開データの変更は、すべて対話マネージャーに委託されます。

複数の機器間での分散

マルチモーダル・アーキテクチャーでもう 1 つ興味深い機能は、アプリケーションを複数の機器で同時に共有できるという点です。マルチモーダル・コンポーネントを「ロシア人形 (Russian Doll)」式に構成することによって実現されたこの機能により、ランタイム・フレームワークはマルチモーダル・コンポーネントと通信するかのように別のランタイム・フレームワークと通信することができます。

複数の機器にまたがるアプリケーションの場合には、いずれかの機器にアプリケーションを開始させてから、すべてのデータ・モデルで同じ公開データを共有できるようにします。つまり、ある機器で実行されているアプリケーションを更新した場合、その更新が他のすべての機器にブロードキャストされるようにするということです。そのようなアプリケーションの一例は、複数のユーザーが都合のいい日時を見つけて会議を予定できるようにする共有カレンダーです。図 3 に、ロシア人形式の構成に従って 2 台の機器間でアプリケーションを共有する方法を示します。

図3. 複数の機器が同じアプリケーションを同時に共有する場合
A diagram showing how multiple devices can share the same application.

上に戻る

マルチモーダル・アーキテクチャーのマイナス面

マルチモーダル・アーキテクチャーの重要な特徴は、それぞれのモダリティー・コンポーネントが固有のマークアップ言語文書を実行するという点です。そのため、複数のモダリティー・コンポーネントが 1 つの同じクライアントに常駐している場合、そのクライアントはアプリケーションが有効な期間中、複数の文書を 1 度あるいは何度もダウンロードして分散しなければなりません。以下の 2 つの図に、なぜこれが実用的でないかを示します。

図 4 は、対話マネージャーとデータ・モデルがリモート・サーバーに常駐し、XHTML と音声モダリティー-・コンポーネントの両方が同じクライアントに常駐しているという構成です。この例では、1 つの Web サーバーが XHTML 文書と VoiceXML 文書の両方をそれぞれのコンポーネントに供給します。XHTML コンポーネントはアプリケーションの最初のページをフェッチし (1)、NewContextRequest をサーバーに送信して (2) 新しいコンテキストで対話マネージャーのインスタンスを開始します。対話マネージャーは新規 SCXML 文書を実行し、SCXML の指示に応じて Start イベントを音声コンポーネントに送信します (3)。Start イベントには実行対象の VoiceXML 文書を組み込めますが、その文書が組み込まれていなければ、音声コンポーネントが別途フェッチすることになります (4)。

図 4. 1 つのサーバーに別々に接続されたクライアント・コンポーネント
A client browser with components connected separately to the server

それぞれのモダリティー・コンポーネントが実行するマークアップ文書へのアクセスはすべて、対話マネージャーを介して行われるため、各モダリティー・コンポーネントが受信するすべてのデータ (cookie やその他のヘッダー情報を含む) は対話マネージャーを介してクライアントに戻されるようにルーティングされます。両方のモダリティー・コンポーネントが同じプロセスで実行されている場合、これでは意味がありません。さらに、キャッシュに入れられた文書のフェッチもネットワークを介して調整されることから、例えばユーザーが Back ボタンをクリックするたびに、クライアントはそれぞれのモダリティー・コンポーネントから前の文書を取得するためにリモートの対話マネージャーに要求を送信しなければならなくなります。

もう 1 つのパフォーマンス上のボトルネック

図 5 に示す構成では、対話マネージャー、データ・モデル、そして XHTML コンポーネントと音声モダリティー・コンポーネントが同じ機器に常駐しています。ランタイム･フレームワークは完全にクライアント上に含まれています。XHTML コンポーネントはマルチモーダル・アプリケーションの最初の XHTML ページをフェッチすると、ローカルにある対話マネージャーの NewContextRequest API を呼び出します (1)。ランタイム・フレームワークは SCXML 文書をフェッチし (2)、対話マネージャーを呼び出します。すると対話マネージャーが文書を実行し、SCXML による指示に応じて音声コンポーネントの Start イベントを呼び出します。Start イベントの呼び出しには、実行対象の VoiceXML 文書を組み込むこともできますが、組み込まれていない場合は、音声コンポーネントが別途、文書をフェッチする必要があります (5)。

図 5. IM を介してサーバーに接続されたクライアント・コンポーネント
Client components connected through IM to server

この構成での問題もやはりパフォーマンスです。音声合成プロンプトがユーザーに表示されるまでには、XHTML コンポーネントがアプリケーションの最初のページをフェッチして解析し、SCXML 文書がフェッチされて実行中になり、そして VoiceXML 文書もフェッチされて実行中になるという過程が必要になるからです。一般的にネットワークはパフォーマンスのボトルネックとなるので、XHTML ページが表示されてからユーザーが音声合成を耳にするまでには顕著な (それゆえに許容できない) 遅延が生じる可能性があります。この遅延を軽減する方法として考えられるのは、SCXML 文書を XHTML 文書に組み込むことです。その場合、SCXML は NewContextRequest API 呼び出しで対話マネージャーに渡されることになります (上記のシナリオは例を説明するためのものです。XHTML コンポーネントだけでなく、音声コンポーネントも最初のページを取得する可能性があります)。

私が期待するのは、このような問題を踏まえて W3C が異なるモダリティーを表す XML を 1 つの文書に合体させる方法を標準化することです。この標準化は、上記のローカル・モダリティー・コンポーネントを実用的にする上で欠かせません。

上に戻る

MMI Working Group への質問

パフォーマンス上の問題の他、W3C マルチモーダル・アーキテクチャーでは多数の課題が考慮されています。これらの課題のなかには、Multimodal Architecture and Interfaces 仕様の今後のリリースで対処されるものもあれば、対処されないものもあるでしょう。MMI Working Group の目下の課題は、以下のように要約できます。

Web の追加リファクタリングについて: レガシー・アプリケーションがマルチモーダル・アーキテクチャーを利用するには、Web サーバーへのフォーム実行依頼を含めたすべての通信を、対話マネージャーに対する Data イベントと置き換えなければなりません。実行依頼は Web サーバーから対話マネージャーに転送される場合がありますが、それによって Web サーバーが別のモダリティー・コンポーネントになってしまうことはないのかという問題があります。Ajax (Asynchronous JavaScript and XML) に関しては、XMLHTTPRequest オブジェクトに Data イベントを含めるようにして、対話マネージャーがすべてのモダリティー・コンポーネントの動的 XML データをフェッチできるようにするという要件に従います。
マルチモーダル・コンポーネントの機能について: アプリケーションに例えばフランス語を認識する音声コンポーネントが必要な場合に課題となるのは、コンポーネントの機能を照会してフランス語を認識するかどうかを調べるにはどうしたらいいのかということです。情報がデバイス・コンテキストのコンポーネントに保管されているとしたら、アプリケーションがその情報にアクセスできるようにする方法も必要になります。この問題を解決するには、デバイス・コンテキストへのインターフェースが必要です。
汎用データについて: マークアップ作成者が使用できる唯一のインターフェースは汎用 Data イベントです。マルチモーダル・アーキテクチャーのその他のライフサイクル・イベントは、モダリティー・コンポーネントをソフトウェア・コンポーネントとして操作することに関連します (開始、停止、一時停止など)。残念ながら、作成者が受信時の Data イベントがどのようにフォーマット設定されていて、送信時にはどのようにフォーマット設定するかを完全に知っていない限り、Data イベントをエンド・ツー・エンドで相互に運用することはできません。さらに、データ・フォーマットをいつでも任意に変更できるコンポーネントは 1 つもありません。

クライアントでは、受信した Data イベントの内容がクライアント上でインスタンス化されたイベントとデータ・フィールド (例えば、XHTML クライアントの場合は DOM (Document Object Model)) にマッピングされていなければなりません。それには JavaScript などのスクリプト言語で Data コンテンツを調べて処理する必要があります。
汎用ブラック・ボックスについて: モダリティー・コンポーネントはブラック・ボックスなので、そこで維持されるデータはカプセル化できます。ただし、データのカプセル化と併せて必要なのが、専用データと関連付けられた動作を表す API です。これが、すべての動作には API によってしかアクセスできない理由となっています。残念ながら Data イベント API は予測のできない振る舞いをするため、連続した Data 呼び出しはデータのほんの一部を更新することもあれば、コンポーネントが維持するデータ・モデル全体を更新することもあります。

W3C Multimodal Working Group は多種多様なマルチモーダル・コンポーネントをサポートしようとしていますが、その一部には XML 言語インターフェースあるいは DOM がないという点が問題です。Working Group がモダリティー・コンポーネントでカプセル化できるデータを標準化できなければ、関連する動作も同じく指定できません。そうなると、アプリケーション開発者がデータ・フォーマットの問題に対処しなければならなくなります。
マルチモーダル・マークアップについて: XHTML コンポーネントが NewContextRequest イベントを対話マネージャーに送信するには、まずこのイベントを何らかの手段で XHTML ページ内に示さなければなりません。NewContextRequest を示す方法、そして XHTML 内に SCXML マークアップを組み込む方法の標準化は W3C Multimodal Interaction Working Group に委ねられています。マークアップ作成者はまた、対話マネージャーへのイベント送信方法、それに対話マネージャーから送信されたメッセージをリッスンして処理する方法についても知る必要があります。
マルチモーダル・プロトコルについて: マルチモーダル・アーキテクチャーで想定されたマルチモーダル・ライフサイクル・イベントが HTTP または Ajax XMLHttpRequest オブジェクトによって Web ブラウザーから送信されることや、アプリケーションによっては SIP スタックが利用可能であれば SIP によってイベントを送受信することもあります。ただし現在の Web ブラウザーでは、対話マネージャーが「プッシュ」することになる非同期メッセージの受信はサポートしていません。このような理由から、IETF ではいくつか候補が提案されてはいるものの (「参考文献」を参照)、現時点ではまだ存在していないマルチモーダル・プロトコルが必要となります。

上に戻る

まとめ

分散アーキテクチャーである W3C マルチモーダル・アーキテクチャーは、ランタイム・フレームワーク、ライフサイクル API、そして疎結合された数々のマルチモーダル・コンポーネントを定義します。この記事では、複数のクライアントとサーバーにマルチモーダル・コンポーネントが分散しているマルチモーダル・アーキテクチャーは、主としてサーバー・サイドの対話管理をするための構成になっていることを説明しました。また、MMI Working Group が取り組まなければならない課題を明らかにし、このアーキテクチャーを使って Web アプリケーションを作成しようとしている開発者にこれらの課題がどのような影響を及ぼすかを簡単に説明しました。

この連載の次回の記事では、マルチモーダル・アーキテクチャーの少なくとも一部の課題を解決することになる XML マークアップ言語について説明します。例えば、ある仕様 (2003年に更新された W3C ワーキング・ドラフト) では、マルチモーダル・ライフサイクル API にいずれ加えられるであろう一連の目的をベースとするイベントを提案しています。SCXML (いずれは W3C 勧告になる方向) は、マルチモーダル・アーキテクチャー、そして V3 として知られる次世代 VoiceXML の中核です。これはサーバー・サイドの Web 開発にとっても一層重要性を帯びてくる可能性があります。この両方の言語が持つ潜在的な影響などについても、次回の記事で説明します。

参考文献

学ぶために