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

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

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

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

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

My developerWorks：

通知：

サイン・アウト

言語を選択する：

XML ウォッチ: ダッシュボードによるデスクトップ XML メッセージ交換

オープン・ソースのアプリケーションでデスクトップ情報の連続的なリアルタイム検索が可能に

Edd Dumbill (edd@usefulinc.com), Chair, XTech Conference

Edd Dumbill氏はXML.com の編集長であり、XMLデベロッパのためのニュース・サイトXMLhackの編集者兼発行者でもあります。O'Reilly's Programming Web Services with XML-RPC の著者の1人であり、生命科学の知的財産を交換するPharmalicensing の共同設立者兼アドバイザーです。EddはXML Europe コンファレンスのプログラム司会者でもあります。Edd Dumbill氏の連絡先はedd@xml.com です。

概要： Edd Dumbillは今回の記事で、ダッシュボードに目を向けています。ダッシュボードは、デスクトップ上に各種の情報を表示するリアルタイムで連続的な検索エンジンであり、急速にサードパーティ開発者の関心を集めつつあるものです。ダッシュボードでは、簡単なXMLメッセージ交換を使っているため、すぐに他のアプリケーションとの統合ができます。

このシリーズの他の記事を見る

タグを付ける!

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

読者は、企業内またはインターネット経由でのXMLメッセージ交換についていろいろ耳にしているかもしれませんが、デスクトップ上での使用については、あまり聞こえてこないのではないでしょうか。オペレーティング・システムで使われている各種のRPC （remote procedure call）システムがある程度定着していることを考えれば、それも意外なことではないかもしれません。そのために、そうした状況を変えようという声もそれほど大きくありません。さらに、オペレーティング・システムでのメッセージ交換機能に関係している開発者は、XMLの冗長性を疑わしいと思いがちなものです。

では、あるアプリケーションが他のアプリケーションと通信しなければならず、なおかつ相互運用性をごく短期間に達成しなければならないとしたらどうでしょう。こういう場合には、XMLに突然多くの利点が出てくるのです。つまり、サポートするツールはどこにでもあり、許容されるメッセージの定義をスキーマで簡単に共有でき、またXMLはプレーン・テキスト形式なので仕様書も簡単に書けるというわけです。

Nat Friedmanとそのメンバー（参考文献参照）がダッシュボード開発の際にとった道のりは正にそうしたものです。ダッシュボードは、デスクトップ情報の連続的なリアルタイム検索ができるオープン・ソースのアプリケーションで、任意の瞬間において、そのコンピュータで行われていることに関する情報を適切に示すことができます。ダッシュボードが他のアプリケーションと統合できるのは、ダッシュボードと通信できるようにアプリケーションを変更するのが容易だということが大きな理由と言えます。

ダッシュボードは何をするのか？

ダッシュボードは、対象のアプリケーションから動作状況を示す情報を受け取り、その情報を使って、選択されたバックエンドのストアに問い合わせを行います。例えば電子メールを読む時には、メール・クライアントがダッシュボードに対し、メールのタイトル行と本文と共にメール送信者の電子メール・アドレスを送ります。そして、バックエンド・ストアが、関連情報を検索します。例えばアドレス帳のバックエンドは、メール送信者のアドレス情報カードを抜き出して、ダッシュボードのユーザ・インターフェースに渡します。図1に示すように、ユーザの携帯電話がEdd Dumbillからのテキスト・メッセージを受信すると、ダッシュボードはその送信者に関して保存されている関連情報をユーザに表示します。

図1. ダッシュボードの動作例

XML error: The image is not displayed because the width is greater than the maximum of 580 pixels. Please decrease the image width.

ダッシュボードを使った便利なアプリケーションがどんなものかは簡単に分かります。現在ユーザの多くは、デスクトップ上に散在する（それぞれのアプリケーションに限定された）データの収集に当惑しています。ダッシュボードは、こうしたアプリケーションに統一した道筋を示し、その結果ユーザは各アプリケーションのデータから、より多くの価値を見いだすことができるようになるのです。またビジネスの面では、日々の作業は情報の内容とその関係に大きく依存しています。例えばCRM （顧客関係管理）では、セールス担当者のすぐ手元に顧客に関係するすべての情報があることは非常に重要なことです。

ダッシュボードで重要なのは、デスクトップのアプリケーションがダッシュボードにヒントを送れるかどうか（ダッシュボードの用語で言えばアプリケーションが何をしているかという clue が送れるかどうか）、に依存するという点です。この点から言えば、ダッシュボードが実用的なのは、（Mac OS Xのように）全デスクトップに強い影響力を持っている場合、またはオープン・ソースの世界で、対応するアプリケーションを自分で手直しできる場合ということになります。ダッシュボードは現在、後者の範疇になるGNOMEオープン・ソース・デスクトップをターゲットにしています。これはうまくいっており、（著者を含め）多くの人々が、デスクトップとインターフェースを取るために新しいコードを書くという、取り組みを始めています。

図2は、ダッシュボードのアーキテクチャの概要を示した図で、ユーザ・アプリケーションとメインとなるダッシュボードのエンジン、および個々の問い合わせ可能なバックエンドのデータ・ストア間でのデータの流れを示しています。

図2. ダッシュボードのアーキテクチャ

ダッシュボードは現在x86 Linux上で、Ximian のMono .NETランタイム（参考文献参照）の下で動作し、C#で書かれています。ダッシュボードは、実験的なソフトウェアで、まだリリースされていません（アーキテクチャの詳細を批判する前に了解しておくべきです）。すでに多くの開発者や業界関係者の想像力をかき立てており、今年のO'Reilly Open Source Conventionでダッシュボードがデモされると会場は騒然となりました。Linuxのデスクトップには懐疑的なTim O'Reillyまで、なぜMac OS Xでダッシュボードのような製品が出てこないのか不思議がったのです。

上に戻る

ダッシュボードのcluepacket

アプリケーションがしていることを、どのようにしてダッシュボードに伝えるのでしょうか。それには、状況を示す情報が記述されたXML文書 " cluepacket " を入力することになります。Cluepacketは、ユーザ・アプリケーションから送信され、ダッシュボードのエンジンによって各バックエンドに分配されます。バックエンドのデータのいずれかがcluepacketのデータと一致すると、バックエンドはその結果をHTMLで返します。バックエンドはまた、他のバックエンドが効果的に動作するために新しいメタデータを使って、cluepacketを任意に拡張することができます。

リスト1は、上記の図1 に示したPhone Managerにおけるcluepacketの例です。Phone Managerは、私が書いたアプリケーションで、携帯電話でテキスト・メッセージを送受信するものです（参考文献を見てください）。

リスト1. cluepacketの例

                
    <CluePacket>
        <Frontend>Phone Manager</Frontend>
        <Context>Text Message</Context>
        <Focused>True</Focused>
            <Clue Type="phone" Relevance="10">+447867093093</Clue>
            <Clue Type="textblock" Relevance="10">
            Will you email john@smith.com with today's
            schedule?  Thanks.
        </Clue>
    </CluePacket>

ご覧のように、cluepacketが運ぶメタデータの主な部分は、そのメタデータの情報源と、各clueに対する型式（Type）、重要度（Relevance）、および名称です。いわゆる cluetype は、現在のところ特に項目数の制限がないリストで、次のようなものを含んでいます。

日付
フルネーム
電子メール・アドレス
チャットのID ( aim_name , yahoo_name , msn_name , icq_name , jabber_name , ・・・)
組織名
住所
url

より完全なリストについては、参考文献にあるリンクを見てください。

これらの型式の一部は非常に自由な形式であり、そのために（物事をスキーマで取りまとめることに慣れている）、XML開発者にとって不満の種になっています。しかしながら、デスクトップ・アプリケーション間の情報構造を一晩で統合できると思うのは認識が甘すぎるでしょうし、そんなことをしようとする間にも人は、一貫性の無い情報を入れてくるものです。ダッシュボードの手法は、ごく大まかな型式だけを決めて、何が重要かの判断は、バックエンドの問い合わせエンジンに任せる、というものです。これは十分論理的で、GoogleがWebに対してとった手法の成功例から多少ヒントを得ているものです。ただし私のように、メタデータに取り付かれた人にしてみると、扱い得る最高のメタデータが実際そこにあるにもかかわらず、それが利用できないのはちょっと残念です。

こうしたcluepacketメッセージに使われる通信プロトコルは、現在のところ単純なTCP/IPソケットです。アプリケーションは localhost のソケットに接続してXMLを吐き出し、そしてソケットを閉じるだけです。こうした簡単な方法をとっている理由は、実装が楽だからのようです。どんな種類の情報集約ソフト（アグリゲータ）を書く上でも、一番の問題はデータの提供元から情報を取り込むことです。ダッシュボードでは、このためのサンプルをいくつか用意しています。例えばPhone Managerで、ダッシュボードの便利な機能を利用するために、私は数行のCコードを付け足すだけでした。

図3は、ダッシュボードを使っている時の画面の例で、Webのブラウジングがいかに強化されるかを示すものです。ブラウザで、私個人のWeblogを見ており、URLとHTMLの内容をダッシュボードに送信します。バックエンドの一つが、そのHTMLをスキャンし、 <head> 部分にキーワードがいくつかあるのを見つけ、RSS （RDF Site Summary）と FOAF （friend-of-a-friend）ファイルに関連づけます。そして入力されたclueに、 keyword 、 rss 、 foafid それに rdfurl 型式のclueが追加され、他のバックエンドは、今度はそのclueを使うことになります。ブックマークのバックエンドは、私のブックマークとの一致を調べ、RSSバックエンドは、私のサイトから最新の4つの記事を取り出し、FOAFバックエンドが私の個人情報を表示するのです。

図3.Epiphany Webブラウザとダッシュボードで機能強化されたWebのブラウズ

XML error: The image is not displayed because the width is greater than the maximum of 580 pixels. Please decrease the image width.

上に戻る

バックエンドとブリッジ

図2 の左側で行われる通信は、図の右側で行われる通信とは異なる方法で行われます。ユーザ・アプリケーションとダッシュボード間の通信は、単純なXMLメッセージ交換で一方通行で行われるのに対して、右側の通信はC#のメソッド呼び出しで行われます。つまり、すべてのバックエンドは .NET （今のところ、これはC#を指しています）で実装されていなければならないということです。ダッシュボードの稼働中に必要となる各バックエンドをインスタンス化して呼び出すために、実行時リフレクションが使われます。バックエンドへの問い合せは、スレッドでパラレルに実行されますが、これは作業が完了するまでに少し時間がかかる場合（特に複雑な検索や、結果を取り出すのにネットワーク・アクセスが必要な場合）があるためです。

先に説明したように、ダッシュボードにはアンバランスなところがあります。どの言語でもcluepacketを送れるのに、.NET言語しかバックエンドに成り得ません。これを解決しWebアプリケーションとインターフェースをとるために、小さなブリッジ・クラスを書いてみました。これはHTTP POSTを使ってHTTPサーバにcluepacketを再送するものです。CluepacketはPOSTのパラメータとして送信され、HTMLまたはXMLどちらかの戻り値が返ることになります（現時点では、私が書いたコードは効率が悪く、POSTを2回・・・HTMLの結果で1回、XMLのclue拡張に1回・・・実行するようになっています）。ブリッジのコードは、GNOME CVS （参考文献参照）で公開しています。私は、ブリッジを使って、うまくダッシュボードとFOAFbotを統合できました。FOAFbotは、FOAFファイルを収集するスパイダーで、私が以前のXML Watch コラムで何度か紹介したものです（参考文献参照）。多くのアプリケーション・フレームワークは、HTTPサーバ・インターフェースを公開できるので、このHTTPブリッジは、旧来の技術との統合に役立つと思います。

上に戻る

まとめ

ダッシュボードは、デスクトップ上に散在する雑多なデータを取りまとめる最初の試みとして、非常に優れたものと言えます。XMLが使われているのは、XMLによって将来さらにデスクトップ・データが開放されると言う前触れなのかもしれません。ダッシュボードの設計者達は、ダッシュボードが極力採用され得るように、いくつかの興味深い選択をしています。

完璧を狙わず、実験的な開発手法を採った。
過剰設計を避け、実際に動作する単純な手段を選んだ。名前空間、RDF、URIなども含め得るが最初からそこまで網羅してしまうと、肝心なユーザ・アプリケーションとの連携がむしろ疎かになってしまう。
XMLを使っていること、またごく単純なネットワーク・プロトコルの採用で、すぐに多くの人がダッシュボードを使うようになる。またダッシュボードのエンジンが必要とするアーキテクチャがどんなものかを調べる上で、ソース・データを利用可能にしておくことは極めて重要である。

デスクトップの統一という未成熟な分野では、ダッシュボードもさんざん実験された挙げ句、結局大したことがないので捨て去るべきもの、となってしまうかもしれません。しかし今のところは、オープン・ソースで簡単な構造、XMLという組み合わせで大いに注目を集め、貢献者も増え続けています。

参考文献

ダッシュボードの現状と最新情報についてはNat Friedmanが維持管理する Dashboard weblog を見てください。
ダッシュボードはLinux用の Mono .NET 実装を使って書かれています。
ダッシュボードは GNOME オープン・ソース・デスクトップの下で実行されます。
著者の Phone Manager アプリケーションは、テキスト・メッセージを受信した時、ダッシュボードに通知を送ります。
FOAFについてさらに詳しくは、 XMLウォッチ: XMLとRDFによる友達の検索（developerWorks 2002年６月）と XMLウォッチ: FOAFによるオンライン・コミュニティーのサポート（developerWorks 2002年8月）を見てください。
developerWorks の XMLゾーンで、その他のXML参考資料を探してみてください。
Edd Dumbill's の、「XML ウォッチ」シリーズの記事をご覧下さい。
IBMの DB2 データベースでは、リレーショナル・データベース・ストレージだけでなくXMLとリレーショナル・システム間のブリッジを提供する DB2 XML Extender のようなXMLに関連するツールも提供しています。DB2に関してより深く学習するために、 Information Management を見てください。
XMLおよび関連技術においてIBM認定開発者になる方法についてはこちらを参照してください。