XML、データ、コード、そして Chimaira

» Permanent link | |

XML guy としての、最近の心境です。

そもそも XML とは何なのか、について考えさせられることが多くなりました。

一つはまつもとゆきひろさんの「私はなぜ XML を愛していないか」という日記です。ここで、まつもとさんはデータ記述言語としての XML の存在意義に疑問を投げかけられています。「XML を愛する人」と自己紹介している身としては、この日記に反論? しておきたかったのですが、考えをうまく文章化することができず、時機を逸してしまいました。

もう一つは檜山さんの一連の記事(Java World の連載および chimaira.org)です。どちらの記事においても、檜山さんは一貫して XML タグ構文とソフトウェアコンポーネントを統合的に取り扱うアーキテクチャ(の土台となるべき議論)について論じられています。

まつもとさんの指摘を一言で言い表すと「XML ってそんなにイイの? 使いやすいの?」となるのではないでしょうか。まつもとさんの側(プログラミング言語設計者、OOP の視点?)から見ると XML は冗長で回りくどくてスマートでなく、しかもデータ型など細かいところに手が届かない中途半端なデータ形式、と思われているようです。

XML は本当に使いやすいのでしょうか。

結論から先に言うと、ある視点からみれば全くそのとおり、使いにくいです。以下では僕が感じていることをもう少し書き綴ってみます。

まつもとさんの日記のコメントでは Relaxer が話題に上っていました。関連した話として、川俣さんが chimaira.org に言及した記事で Relaxer に疑問を投げかけられています。僕は Relaxer を有効活用していますが、Relaxer が XML を扱う最適な処理形態ではないと感じています。Java (あるいはプログラミング言語)の世界のデータモデルに合致したスキーマを利用する限りにおいては Relaxer は有効ですが、XML 特有のモデルが出現したとたん、バインディングが複雑になってしまいます。Relaxer を使っている現場では、ラベルを駆使したスキーマや choice などは使っていないのではないかと想像しますが、どうなのでしょうね。

しかしなぜ Relaxer は人気があるのでしょうか。なぜ人々は Java の世界で閉じずに、あえて RELAX NG(XML)という別の世界に流れるのでしょうか。まず考えられるのは、Relaxer がいろいろな雑誌に紹介記事が載っていて、かつインストールが簡単、比較的安定しているなどマーケティングのうまさとツールとしての出来のよさです。雑誌に書いてあって何か使えそうだ→インストールも簡単だった→いっぱい Java のコードを生成してくれる(感動!)という流れです。

それからもう一つ、実はこれが結構重要だと思いますが、Relaxer を使うと Java オブジェクトの永続化が簡単に行えるということも挙げられるのではないかと感じています。逆に言うと Java ではオブジェクト永続化が難しい、ということです。ツリーで表現できるデータ構造を Java で設計し、アクセッサを用意して、かつ入出力のコードも書き、というようなコーディングを手で一からやっていると、非常に手間がかかります。一般論として、プログラマはデータ構造の設計に集中したいのです。Relaxer を使えば、これが実現できます。すなわち RELAX NG スキーマの設計(=データ構造の設計)に集中すれば、その他の雑多なコードは全てツール(Relaxer)が自動生成してくれるのです。これは特に Java のような堅い言語で威力を発揮するのではないでしょうか。

さらにいうと、その永続化したデータが、Java 以外の言語やツール、たとえば XSLT などからアクセス可能である、というところがシステム設計者にとっても大きなメリットとなっているのではないでしょうか。ここはまさに XML の持つインターオペラビリティの本領発揮というところでしょう。

僕自身は Ruby に関して何も知らないので推測ですが、堅い Java に対して軟らかい Ruby では Relaxer のようなツールがあったとしても Java 版ほど利用されないのではないかと感じ(あくまでも感じるだけ)ます。

さて、ここまでは Java, OOP などの視点で語ってきました。しかし、世の中には別の視点もあります。それは、構造化文書、ハイパーテキスト、などいわゆるボヘミアンの視点です。ボヘミアンにとって一番大切なのは XML の構文とデータモデル(普通は? Infoset、でも檜山さんは DOM のようですね)です。彼らがプログラミング言語に期待するのは、自分の XML データをいかに効率的に扱えるか、処理できるかということです。そのような立場の人間からしてみると、既存のプログラミング言語(というよりは XML 処理ライブラリか)は中途半端で出来が悪く感じます。XML データを処理するコードを書こうとすると、とたんに冗長で回りくどくてスマートでなく、しかも混在内容など細かいところに手が届かない中途半端なプログラムになってしまいます。プログラミングの視点から見れば、そんなデータ形式のほうが悪い、となるのかもしれませんが、ボヘミアンからしてみれば、なんで俺のデータをこのプログラミング言語(ライブラリ)は扱えないのだ、となります。すなわち、興味の対象がコードなのかデータなのか、ということです。

プログラマの視点から見る世界は圧倒的にコード重視の世界でした。プログラムが真ん中にいて、その周りをデータが回っている世界です。ところが、Web 環境ではデータの価値が上がり、相対的にコードの価値が下がりました。データが中心にいて、その周りを複数のコードが回っているような状況です。XML 2004 のキーノートで、Michael Daconta がこれをコペルニクスの天動説と地動説になぞらえていました。

XML をインターオペラビリティのためだけにあると捉える人々は、天動説主義者ではないでしょうか。そしてボヘミアンは地動説主義者であるといえます。

ただ、データを中心に捉える考え方は、別に新しい物ではありません。たとえば Unix でおなじみの行指向のデータはどうでしょうか。Unix で伝統のある行指向のテキストデータは、それを扱う小さいプログラムがたくさん揃っています。そしてそれらをパイプとフィルタで自由自在に結合し、処理することが出来ます。フィルタは cat, sort など基本的なコマンド以外に、適当なスクリプト言語のワンライナー(使い捨て)をその場で作ってしまうことも出来ます。これはまさに行指向のテキスト(データ)の周りを小さいフィルタプログラム(コード)が回っている世界ではないでしょうか。

だいぶ昔、確かユニマガだったと思いますが、ラリーウォールがインタビューで perl の今後を聞かれたときに、これまで行指向のテキストデータが対象だったものを XML のようなツリー構造も対象にしていきたい、というようなことを返答していたと記憶しています。そして今、檜山さんが chimaira アーキテクチャでやろうとしている Janus はまさにこのパイプ&フィルタを XML の世界に拡張しようとする試みです。

XML の本領発揮はこれからではないでしょうか。まだ僕たちには見えていない世界があるようです。

こんな感覚が分散システムのアーキテクチャである REST と相関して自分の中になんともいえないモヤモヤを作っています。ここで述べた見解以外にも、他方では document vs object, rpc vs messaging, そして messaging コミュニティにおいても WS-* スタック vs REST など、問題のドメインは微妙に異なっていても実は課題は同じなのではないかと思えることがたくさんあります。継続して考えていかないといけないですね。

RESTful ツールキット

» Permanent link | |

昨年11月に Amazon Web Service から Simple Queue Service がリリースされた。

このサービスの持つインパクトについては江島健太郎氏の blog が最もよく記述されている。

いわく、エンタープライズ市場で醸成されてきたキューイング技術がAmazon によって非対称ポーリングモデルという形でパーソナルユースに取り込まれることにより、B2C ならずとも B2B の世界にも大きなインパクトをもたらすであろう、ということだ。この考察は素晴しいと思う。トラックバックを見ると、そのように感じた人も多いようだ。

Amazon のこのサービスがアルファギークの興味とうまく連携してこれまで想像もつかなかった応用を生めば、確かにとても面白い。

ところで Amazon Web Service の常だが、この Simple Queue Service も二つの API を持っている。一つは SOAP/WSDL であり、もうひとつが REST API だ。ただし、この REST API は肝心の REST 陣営からは評判が悪い。

BitWorking の Joe Gregorio が xml.com で SQS REST API の批判記事を書いている。

SQS REST API の最大の問題点は、オペレーション名を URI に埋め込んでおり、全ての操作を HTTP GET で実現しているところだ。REST では HTTP の GET オペレーションはリソースの状態変更してはならないのだが、SQS ではキューの削除まで GET でできてしまう。

ただし、Amazon 側からしてみると、そんなことは百も承知で全てのメソッドを HTTP GET で実現しているのだろう。彼らが GET を採用している本当の理由は、それが一番クライアントを作りやすいからだと思う。

GET ならブラウザさえあれば簡単に試すことができる。XSLT/XPath の document() 関数も URI を GET してくれる。wget を使えばコマンドラインからでもできる。ある URL を簡単に GET するための仕組みはすでに十分用意されているのだ。perl も ruby も python も知らないけど、おそらく GET が一番簡単だろう。

REST の概念は美しいし、共感するけれど、いざ実装となるととたんに難しい。それは現状で用意されているツール、ライブラリ、フレームワークのしがらみや制約からくるものだ。では、そこをサポートするツールがあったらどうだろう。具体的には任意の XML やバイナリを任意の URI に GET, POST, DELETE, PUT できる簡易ブラウザのようなイメージである。

RESTful なサーバ側フレームワークも重要だが、クライアントライブラリも同じように重要だと思う。

ブログなどについて

» Permanent link | |

あけましておめでとうございます。

今年も昨年同様に日記を書いていくつもりです。ここでなぜ僕が日記を書いているかについて、一度簡単に説明しておきます。

僕の現在の仕事は Web 技術、特に Web サービスにかかわる研究開発です。この日記で書いている WS-* などの情報収集は個人的な興味もありますが、業務的な側面が強いです。XML スキーマのバージョニングになると個人的興味が強く、REST は完全に自分の趣味です。まあ WS-* 関連のトピックにしても、会社で話せる範囲のことではなく、自分の脳内に滞留してどうしようもないような考えをほとんど自分のためにブログに書いてます。会社では誰にも話しようがない話題を日記に書いているので、悲しいかな扱う内容はマイナーで、結局誰にも相手にされません。ただ、自分の好きなことを自由に書けるので、ストレス解消にはなります:-)

1年前、僕はブログについて懐疑的でした。学生時代に Web 日記を書いていて、これは社会人になってからも続けていましたが、かなり不毛であることに気づいてやめました。やがて仕事が忙しくなり、Web については仕事としてかかわっているものの、昔のように先端技術を追いかけることは少なくなっていました。どちらかというと目の前にある実装技術を追いかけるほうが楽しくなったからです。でも、昨年 XML 白書を読んでいわゆる blog に興味が出て、いろいろと調べているうちに、blog 技術に限らずそれ以外でも Web 技術の応用はいろいろな分野で進んでいそうだと感じるようになりました。たとえば blog についても、技術的なバックグラウンドはわかっているのですが、しかし実際に使ってみないとわからないことも多いのです。僕が最初ははてなで日記を書いていたのに、今は blogger に移った理由の一つはより新しい・楽しい技術が体験できそうだったからです。blogger もはてなも利用することで、最新の技術をより多く実体験することができると考えたからです。なので、blogger よりも面白そうな blog サービスが始まったら、またそちらに移ってしまうかもしれません。

はてなと blogger で日記を書いてみて、最新の Web のトレンドを実体験する楽しさが少しよみがえりました。技術的な考察も進みます。たとえば blogger とはてなのインターフェースを比べると、いろいろ面白い知見が得られます。アーキテクチャ的にも非常に興味深いですね。

半年ほどはてなで遊んで、blogger を調べて、引越ししてみて感じたことは、やっぱり何事も使ってみないとわからない、ということです。ということで昨年の後半は gmail のアカウントを取得したり、mixi をはじめたり Google adsense を付けてみたりしています。表面上は単なるミーハーですが、どれからも自分の知らなかったり気づかなかったりしていた知見が得られて非常に有意義です。

ブログが食わず嫌いの人にはぜひ一度 blog システムやその他のサービスを体験してみることをお勧めします。