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 関係のポスト に、対話形式を使うのを先を越されてしまった。 このうぬぼれはソクラテスの時代から使われてきたという事実を勇気を持つ材料にしよう。