S はシンプルの S

» Permanent link | |

This entry is a Japanese transration of Pete Lacey's "The S stands for Simple".

Burton グループのアプリケーションプラットフォームサービスグループでは、 REST派とSOAP派の間でずっと継続中の議論がある。 その大部分は外部での議論によく似ている。 最近のやりとりの一つ、 SOAP と Web サービスフレームワークの複雑さの議論で、 SOAP 側は「WS-* の前は、SOAP は実際にシンプルだった。S はシンプルの略だ」といった。

さあ歴史を学ぼう。 2000年、悩める開発者が問題をかかえている。

開発者: うちの上司が先週末ゴルフをやってきて、 いわゆる SOAP なエンタープライズをやる必用があるんです。 でも私は SOAP が何なのか知りません。 教えてもください、 SOAP の人。

SOAP の人: もちろんです。 まず、SOAP は「シンプル・オブジェクト・アクセス・プロトコル」の略なんです。

開発者 シンプルなんですね?

SOAP の人: 日曜日のようにシンプルですよ

開発者 オーケー、教えてください。

SOAP の人 はい、その名前のとおり、SOAP はリモートオブジェクトにアクセスするのに使います。

開発者 CORBA みたいなもの?

SOAP の人 シンプルなこと以外はまさに CORBA に似ています。 ファイアーウォールを通過できない複雑なトランスポートプロトコルの代りにHTTP を使います。 そして、バイナリメッセージフォーマットの代りに XML を使うのです。

開発者 面白いですね。どのように動作するのか教えてもらえますか?

SOAP の人 もちろんです。 まず、SOAP エンベロープというのがあります。 これは非常にシンプルです。 SOAP エンベロープはヘッダとボディで構成される XML 文書なんです。 そしてボディには RPC コールが書けます。

開発者 SOAP は RPC なんですか?

SOAP の人 そのとおりです。 さきほど述べた通り、SOAP ボディにメソッド名と引数を埋め込むことで PRC コールが作れます。 メソッド名は一番外側の要素でその子要素がパラメータです。 そして全てのパラメータはこの仕様書の第5節の定義に従って型を持ちます。

開発者 (第5節を読む) オーケー、悪くないですね。

SOAP の人 そして、サービスを配備したら、エンドポイントを指定します。

開発者 エンドポイント?

SOAP の人 エンドポイントはサービスのアドレスですよ. SOAP エンベロープをエンドポイントの URL に POST するんです。

開発者 エンドポイントの URL を GET したらどうなるんですか?

SOAP の人 わかりません。GET の利用は定義されていないんです。

開発者 ふーむ。でももしサービスのエンドポイントを別のエンドポイントに移動したらどうなるんですか? 301 が返されるんですか?

SOAP の人 違います。SOAP は実際には HTTP のレスポンスコードは使っていないんです。

開発者 つまり、SOAP が HTTP を使っているというのは、 HTTP 上をトンネルしているという意味ですか?

SOAP の人 はい、トンネルはちょっと悪い言葉ですけどね。SOAP はトランスポートを意識しない(transport agnostic)と言った方が良いですね。

開発者 でも HTTP はトランスポートじゃなくてアプリケーションプロトコルですよね。まあとにかく、SOAP がサポートしている他の「トランスポート」には何があるんですか?

SOAP の人 えーとですね、公式にはありません。 ただ、どんなトランスポートも潜在的にはサポート可能です。 そして、JMS や FTP や SMTP をサポートしたプラットフォームがたくさんあります。

開発者 誰かそれらのトランスポートを使っている人はいるんですか?

SOAP の人 うーん、いません。でも重要なのはそれができる、ってことなんですよ。

開発者 そうですか。ところでこの SOAPAction ヘッダというのは何のためにあるんですか?

SOAP の人 正直に言えば、誰も知りません。

開発者 じゃ、この "actor" とか "mustUnderstand" 属性というのは? 誰かこれを使っている人はいますか?

SOAP の人 いいえ。誰も使ってません。とりあえず無視してください。

開発者 わかりました。やってみます。

(時間の経過)

開発者 えーと、一つの SOAP スタック上だけでなら、だいたい動くようになりました。 あと RPC とオブジェクトのシリアライズはどうも好きになれません。

SOAP の人 RPC! オブジェクトのシリアライズですって! SOAP が RPC だなんてどこで影響を受けたんですか? SOAP はドキュメントベースのメッセージングですよ!

開発者 え、でもたしかあなたがそう…

SOAP の人 私が何て言ったかなんて忘れてください。 これからは 大粒度メッセージ をやりとりするんです。 いいでしょ? 大粒度って言葉。 メッセージは XML スキーマに従ったものです。 この新しいスタイルは document/literal って言うんです。 あ、古いのは RPC/encoded ね。

開発者 XML スキーマ?

SOAP の人 大流行してるんです。次はこれですよ。見てみてください。

開発者 (XMLスキーマ仕様を読む)。 天よ、お助けください! アレクサンドロス大王でも解けないよ、こんなの。

SOAP の人 心配しないでください。ツールがあなたのためにスキーマを作ってくれるんです。本当ですよ。これは全部ツールがやってくれるんです。

開発者 ツールはどうやってスキーマを作るんですか?

SOAP の人 はい、 ツールは(可能なら)あなたのコードを反映したスキーマを自動的生成します。

開発者 私のコードを反映するんですか? オブジェクトのシリアライズではなくて、ドキュメントなんじゃないんですか?

SOAP の人 私の話を聞いてなかったんですか? 全部ツールがやってくれるんです。 とにかく、あなたが手で XML スキーマと WSDL (ウィズドゥール)を書くとは期待していません。さらに、これは配管工事なんです。これを見る必用はないんです。

開発者 ちょっとまったー。ウィズドゥール? 何それ?

SOAP の人 あれ、まだ WSDL の説明をしてませんでしたっけ? ダブリュ・エス・ディー・エル、Web サービス記述言語です。 クライアント開発者がアクセスするサービスのデータ型やパラメータ、オペレーション名、トランスポートバインディング、エンドポイント URI を指定できるんです。 ほら見てください。

開発者 (WSDL 仕様を読む) これ書いたやつ逝ってよし。 内部矛盾してるよ。 あとこの HTTP GET バインディングって何さ。 GET は未定義じゃなかったの?

SOAP の人 気にしないでください。 誰も使ってませんから。 とにかく、ツールが WSDL を生成してくれて、WSDL に XML スキーマも含まれているんです。

開発者 しかしそれは逆であるべきじゃないんですか? 最初にコントラクトを設計してそれからコードを生成するべきではないんですか?

SOAP の人 はい、ええ、原理上はそうだと思います。 でも、それをやるのは簡単ではないんです。 それと WSDL を最初に作る開発手法をサポートしている SOAP スタックは少いんです。 それはツールにやらせてください

開発者 もう一つ質問。 XML スキーマに適合したメッセージをやりとりするなら、 オペレーション名はどこで指定するんですか?

SOAP の人 はい、SOAPAction HTTP ヘッダは覚えておられますか? みんなそこにオペレーション名を書いています。

開発者 みんな?

SOAP の人 はい、この新しいスタイルは実はまだどこにも記載されていないんです。

開発者 うーん おたくの業界はしょっちゅうあいまいで間違ってて確実に標準化されていない仕様で構築されてるのに注意しないとなー。 実際、SOAP と WSDL 仕様はただの W3C Note であってワーキングドラフトでもないじゃないですか。

SOAP の人 今頑張っているところです。

開発者 これで相互運用性が得られるんですか? 約束してもらえますか?

SOAP の人 もちろんです。

開発者 試してみます。

(時間の経過)

開発者 なんてこった。 俺のツールで生成した WSDL はお客様が使っているツールでは読み込めなかったよ。 それだけじゃない、スキーマはわけかわらないし再利用できないじゃないか。 それに SOAPAction ヘッダの扱いを合意しているツールなんてないみたいだし。

SOAP の人 御愁傷様です。 ただ救われるのは、もうだれも doc/lit スタイルを使っていないことです。 トランスポート独立にするために、wrapped-doc/lit をみんな使っているところです。 wrapped-doc/lit ってかっこよくないですか?

開発者 何それ?

SOAP の人 はい、wrapped-doc/lit は doc/lit に似ているんですが、メッセージ全体をオペレーション名と同じ要素でラップするんです。 オペレーション名はメッセージに戻ってきました。

開発者 オーケイ、仕様はどこですか?

SOAP の人 あ、仕様はありません。 これはマイクロソフトがやろうとしているらしいことです。 いいアイデアなので、賢い子たちはみんなこうやってますよ。 それに、新しい話もあるんです。きっと気に入ると思います。 Web Service Interoperability Group、またの名を WS-I って言うんです。 彼らがやろうとしているのは SOAP と WSDL 仕様のあいまいな部分をとりのぞくことです。 仕様がお好きなことは知ってますよ。

開発者 それは言い換えると、仕様が非常に悪かったので、標準を標準化するための標準化団体が必用だったということですね。なんつーか。 で、WS-I は相互運用性問題を解決してくれるんですか?

SOAP の人 ええ、そうです。 WS-I に適合した SOAP スタックを使って、 XML スキーマの80%を回避して、変なデータ型を使わずに、そして WebSphere と Apache Axis での動作を考えなければね。

開発者 つーか wrapped-doc/lit はそこで説明されてるんですか?

SOAP の人 えー、されないです。 でも問題ないです。ツールは理解してくれますから。とにかく、ほとんどは。

開発者 まとめるとこうですか。 SOAP の定義は不安定で、SOAP は全然シンプルじゃなくて、 それは全てのツールがまだしていることだけれど、 もはやオブジェクトにアクセスという意味はないってことですね。

SOAP の人 だいたい正しいです。 ただ我々は一歩先を行っています。 SOAP の略語の意味を廃止したんです。

開発者 えー! 何の略になったんですか?

SOAP の人 何の略でもないんです。

開発者 (ﾟДﾟ)ハア?

SOAP の人 UDDI について説明させてもらえますか?

Duncan Cragg の最近の REST/SOAP 関係のポスト に、対話形式を使うのを先を越されてしまった。 このうぬぼれはソクラテスの時代から使われてきたという事実を勇気を持つ材料にしよう。

Webサービスプラットフォームアーキテクチャ

» Permanent link | |

という本が2月に出ていたらしい(結構分厚いので読むのに時間がかかる)。

Webサービスプラットフォームアーキテクチャ
Sanjiva Weerawarana Frank Leymann Donald F. Ferguson

原著の著者はみなさんは WS-* の著者欄に名前を連ねている方々(特にIBM)で、 仕様策定のバックグラウンドを語らせたら右に出るものはいないと思われる。 本書ではその著者達が WS-* の各仕様を設計思想から解説しているので 仕様書を読むよりも楽にその背景思想を理解できる、と思う。

ちなみに REST もしっかりとアーキテクチャスタイルとして紹介されていて、 その最大の特徴(Uniform Interface)と WS-* の interface 中心主義との違いが簡単に述べられていた。

さらに、実は本書はエンタープライズ環境の分散コンピューティングの技術の基本をざっと概観するのに適しているのではないかとも思う。 目次を見てもらうとわかるけれど、メッセージングの基礎から、discovery, description, reliability, security 等一通りのことは書いてある。 WS-* からより抽象的な概念に変換する能力は必要だが、このあたりに興味のある方にはお勧めである。

カミングアウト。

» Permanent link | |

Tim Bray の WS-Crossroads から REST 関連のブログエントリが凄いことになってます。 Tim のエントリはガートナーの group VP で chief fellow な Daryl Plummer の Web Services At A Crossroads という記事を受けてのもの。 Plummer の文章はツッコミどころがあるものの、いいこといっているのも事実だと。

Tim のエントリは最後の段落がとてもいいです。

Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.

これを受けたのがマイクロソフトの Don Box です。 まず Going Down To The Crossroads... というエントリで、 Tim の上記の段落を受けて、マイクロソフトの環境・ツールがどれくらい HTTP/XML/REST をサポートしているかをまとめてくれています。

さらに Don の次のエントリでは HTTP, XML, REST, and $100 と題して、もし $100 あったら、HTTP/XML/REST 関係の開発の何にどれくらいを費やしてほしいか、の意見を求めています。 このコメントやトラックバックが面白いんですが、Dare Obasanjo の反応がまじめにいいです。 いわく $40 を IE での XML サポート強化(E4Xとか)に、$30 を WCF での RESTful サービスサポートに、 $20 が C# と VB.NET での XLinq サポート、最後の $10 は W3C じゃない XML 技術(RELAX NG や Schematron)のサポートと。

その後はlesscord での勝利宣言(いくつか心配もありますが)があったり、 Mix06 でビルゲイツが "We need microformats" と言ったり、時代が確実に動いているという感じですね。

最後に僕もいちおうカミングアウトしておこうかな。

I'm a Restafarian.

REST は難しい、だからこそ面白い

» Permanent link | |

知り合いに教えてもらって知ったのだが、今月の日経ソフトウエアは Web プログラミングの特集である。 ちょっと立ち読みしたところ、内容は Web 2.0 まわりの記事だった。 その特集の中の囲み記事で REST と僕の名前が出てくるところがある。 「わかりづらい REST という言葉」というタイトルで、 REST がアーキテクチャスタイルであること、 一方で REST API は「ホームページ」のような誤用であるが、そちらの方が一般的になってしまっていること、 が簡単に記述されていた。

REST == HTTP GET+XML のような紹介よりも1万倍よかったし、 何よりこういう初心者向けのメジャー(?)な雑誌記事で REST に言及するよ うになって、本当によかったと思う。1年前には考えられなかったことだ。

ただ、気になったのは REST が難しくてわかりづらい、という話だ。

そりゃ確かに REST は難しい。RoyF の論文を読みこなすには相当知識が必用だし、僕の REST 入門もやっぱり難しいと思います。コンテキストを共有していないと。 僕自身、SOAP で Web サービスを一通りやって、その長所短所がわかってからやっと、REST の良さを認識できた。

でも一方で本当に難しいのかな、とも思う。 いや、なんというか、「難しさの質」の問題とでもいうか。 たとえば XML Schema の複雑怪奇でどこから手をつけていいのかわからないような難しさ、あるいは BK 的な奥が深い難しさ、とは性格が違うんじゃないだろうか。

そしてさらに思うのは、そういう難しさの質が違うものに対して、単に難しくてわかりづらいから、楽でわかりやすい方に流れるというのは技術者としてどうなんだろう、ということ。 難しくてもシンプルだったり、美しかったり、論理的に納得させてくれたりするものの方が、 複雑なものを上辺だけ楽そうに見えるカワを被せて隠蔽しているものよりも ずっと本質的で面白いのではないだろうか。

REST は難しい。でも、ただそれだけの理由で REST がバズワード化して誤解されてしまうのはなんだか悲しい。

REST 入門(その9) REST と SOAP

» Permanent link | |

» REST 入門 目次

前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。 今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。

Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、 たくさんの Web ページが見つかります。 いろいろな立場の人が、それぞれの意見を述べ合っていて、 ここで全ての主張や意見を解説するのは不可能です。 これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。

ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。 一方で SOAP はプロトコル、あるいはメッセージのエンベロープ形式です。 二つを比べようにもあまりに次元が違い過ぎます。 この二つが並べて議論されるとき、たいていは SOAP を拡大意解釈するか、 あるいは REST を縮小解釈しています。 たとえば Amazon Web サービスの SOAP API と REST API を比べたり(REST の縮小解釈)、 あるいは SOA と REST を比べたり(SOAP の拡大解釈)。 これには歴史的理由がいろいろあって、紆余曲折してきているというのが真相です。 ここでは時系列に沿って、REST vs SOAP を振り返ってみたいと思います。

SOAP RPC と REST

2000年ごろ、Web サービスといえば SOAP/WSDL/UDDI でした。 SOAP には何種類かの使い方があるのですが、 このころは SOAP エンコーディングを使った RPC (SOAP-RPC)が主流の使い方でした。 SOAP-RPC がやりたいこと(できること)は非常に単純です。 異なるプラットフォーム同士で RPC をすることです。

プラットフォームが異なる場合、標準的なデータフォーマットが必要となり、そこに SOAP エンコーディングという XML を採用したプログラム言語のデータ構造のシリアライズ形式が使われました。 SOAP エンコーディングを使った RPC は WSDL の記述の仕方から rpc/encoded と呼ばれます。

SOAP-RPC は便利です。それまで RPC がなかなか実現できなかったところで RPC が可能になりました(たとえば UPnP)。 しかし、SOAP-RPC は結局のところ RPC ですから、それ以前の RPC や DCOM, CORBA などの分散オブジェクト技術が持っていた問題をそのまま受け継ぐことになります。 サービスの呼び出し単位は細かく、オブジェクトが状態を持ちがちなので、スケーラビリティが問題になります。 そのような理由から SOAP のトレンドは SOAP-RPC から別のものに移っていくことになります。

WS-*/SOA

rpc/encoded よりも粒度が粗く、RPC でなく XML をそのままメッセージとして送信する、 そんな SOAP のやり取りを document/literal 形式といいます。 これは引数が DOM の Document オブジェクトひとつのメソッドを思い浮かべればいいでしょう。 XML を DOM でそのまま渡して、結果も DOM で返ってくる。 非常に単純化するとそんな形式です。

一方で SOAP の世界には WS-* と呼ばれる仕様群が登場します。 SOAP 自身は前にも述べたとおり単なるメッセージエンベロープ形式であり、 実際の運用ではさまざまな機能をその上に実装する必要があります。 各社バラバラにそれらの機能を作っていってもいいのですが、 ある程度共通化して使える機能に関して WS- という接頭辞をつけた名前の仕様書がさまざまなベンダから提案されました(されています)。 具体的な仕様書名を挙げれば、たとえば WS-Security や WS-Addressing などです。

この WS-* 仕様群には、ベンダ各社の標準化競争だとか、 オーバースペックだとか CORBA の再来だとか、 さまざまな問題が指摘されています。 が、まあここではそういう話はおいておいて、純粋に技術的にどうなのかという議論をしたいと思います。

REST と SOAP

ここでは SOAP といったときに単純に SOAP エンベロープ形式を指すわけではありません。 SOAP というのはその周囲の WS-* だとか SOA だとかを含んだ一連のコンセプトを指すと考えます。

SOAP 的な考え方と REST 的な考え方(というか REST は考え方そのもの)の一番の大きな違いは、 プロトコル独立を重視するかどうかです。 SOAP 的考え方はプロトコル独立を重視します。 たとえば SOAP メッセージは HTTP でも SMTP でも UDP でも直接 TCP でも送れるように設計されています。 一方で REST には HTTP しかありません。 この両者の差は何なのでしょうか。

この差はインターフェースがどこに含まれるかの違いです。 REST では uniform interface 制約ということで HTTP が統一のインターフェースとなります。 HTTP の上をデータ(XML)が流れます。 一方で SOAP ではトランスポート独立ということで TCP, UDP, SMTP, そして HTTP の上に getX, startY などのインターフェース付きのデータ(SOAP メッセージ)が流れます。

REST と SOAP 的考え方の違い、少しだけですが雰囲気はつかめたでしょうか。 このテの話題は純粋に技術的ではなく、他の要素が絡むので語りにくいのですが、 技術者の皆さんに言いたいのは REST でも SOAP でも、 せめて技術的にはニュートラルに評価しましょう、ということです。 今日のこのポストもかなり端折って書いているので、 このまま鵜呑みにするんじゃなくて自分で調べてくださいね。

この REST 入門シリーズも次回はとうとう最終回です。