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

日経SYSTEMS。

» Permanent link | |

日経SYSTEMS 5月号で Web 2.0 関連技術(特にREST)がシステム開発に与える影響についての取材を受けました。 P60に数行だけ僕の発言が引用されていました(下記に引用したので全文)。 僕がしゃべったこととはちょっと違ったのでここで訂正しておきます。

コンテンツを読むだけでなく、簡単に書き込めることが重要。

これはそのとおり。

REST では GET に PUT と DELETE を加えれば Web ブラウザだけでそれが簡単に実現できる。

これは言ってないよー。ブラウザだけで簡単に実現はできないっしょ。少くとも現時点では。

新たに SOAP を覚える必用がない

まあそうかもしれない。ただ、これに相当することを言った覚えはないんですが…。

カミングアウト。

» 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 入門(その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 入門シリーズも次回はとうとう最終回です。

Java SOAP スタックの再考

» Permanent link | |

とても興味深い論文を読んだ。 Steve Loughran と Edmund Smith の "Rethinking the Java SOAP Stack" だ。 この論文は現在の Java の SOAP 実装スタック、特に JAX-RPC の問題点を XML セントリックな視点から明確に指摘している。 また、最後の部分で Alpine という新しい SOAP スタックのコンセプトを提案している。

Alpine の方はまだどんなものかわからないので、これからに期待したいが、 JAX-RPC の問題点の方はとても面白い。 雰囲気を伝えるために論文の第二章 "基本的な JAX-RPC の欠陥(The Fundamental Flaws of JAX-RPC)" の見出しを日本語で引用する。

1. オブジェクト/XML のインピーダンスミスマッチ
   1. XML 要素の Java クラスへのバインディング
   2. XML の名前(Names)の Java 識別子へのマッピング
   3. Enumeration
   4. ポータブルでない型
   5. オブジェクトのグラフの直列化
   6. XML メタデータと名前空間
   7. メッセージ妥当性検証
   8. XML と直列化データの不適切な混和
   9. フォールト処理
2. SOAP は RPC ではない
3. SOAP は RMI ではない
4. WSDL: 別の複雑さ

このように論文で指摘されている問題点はいくつもあるのだが、基本的には SOAP/XML Web サービスを Java 世代のプログラミング言語(Java に加えて C#, VB.NET も)にネイティブにマッピングしてしまうことへの批判となっている。 その中でも特に大きいのが XML と オブジェクトのデータモデルの違いに起因するインピーダンスミスマッチだ。 ここで指摘されている各事項は、XML をオブジェクトにマッピングしたり、 オブジェクトを XML にマッピングしたりすることが本質的に難しいことを示している。

上でも述べたとおり、この論文は XML セントリックな視点から記述されているので、 逆に RPC/RMI/Object セントリックな視点から見るとまったく許容できない内容なのかもしれない。 そういう意味で面白い文(Don Box も引用している)がある。

我々は Web サービス開発者にはただ二つの分類があると考える。 XML に満足していてそれを扱う仕事をしたいと願っている人々と、満足していないのに結局はなんだかんだいってそれを扱う人々だ。

(We believe that only two categories of web service developer exist: those who are comfortable with XML and want to work with it, and those who aren’t but end up doing so anyway.)

明らかに僕は前者だ :-)

疎結合と XML

» Permanent link | |

疎結合(loosely-coupled)って何でしょう?

僕自身、適当に疎結合という言葉を使ってしまいがちですが、 ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。 いいかげんな定義で話をはじめると、 各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。 ということで今回は僕なりに疎結合ってこんなもの、 というのを考えてみます。

ものすごく一般化してしまうと、 疎結合というのは複数のコンポーネント間の結び付きが ゆるいことを指すんでしょうね。 たぶん、ここまでは誰でも同意してくれるはず。 ただこれだけでは議論ができなくて、 このコンポーネントに何をもってくるかを決めて、 はじめて具体的な話ができます。

僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、 コンポーネントは Web サービスになります。 コンポーネントがオブジェクトだとかもっと細かいレベルの話もあると思いますけど、 ここではしません。

あ、Web サービスという言葉も危いですね。 ここでは Web 上で機械(プログラム)可読なフォーマットで情報を提供するもの、 だとします(実際、僕の Web サース感はこれに近い)。 SOAP インターフェースの株価サービスかもしれないし、 AtomAPI のはてなブックマークかもしれない。 RSS フィードも含みます。

ところで、この「疎結合」をもろに扱った本があります。 タイトルがずばり「疎結合」です。 SOAP よりの Web サービスの文脈での疎結合を扱っている本です。 この本は10章で疎結合とは何かを解説しているんですが、 そこにはこんなことが書いてあります。

(前略) 多くの人々が「疎結合」という言葉を口にしますが、 その意味を正確に説明できる人はほとんどいません。 これは、疎結合が方法論もしくは作法であり、 確立された規則や仕様ではないからです。

疎結合は、俊敏性(アジリティ)、すなわち変化に適応する能力を重要視する 分散アプリケーション設計へのアプローチの一種です。 (後略)

つまり疎結合というのは分散アプリケーションの作り方、 設計の仕方に関する考え方のひとつであり、 特に決った規則や仕様はないってことです。 これは逆の意味でしっくりきました(僕には)。 これだけ曖昧な定義なら、議論の方向性が定まらないのも仕方ないですね。

僕が今考える疎結合システムのイメージはこんな感じです。

まず、サービス(コンポーネント)間のインターフェースは統一し、 半永久的に変更しません。 サービスのインターフェースに少しでも修正が入ると、 旧インターフェースを利用していたクライアントを修正しなければならないからです。

インターフェースを統一して不変にしたときに、 ではいったいどこでサービス同士の機能を差別化するのか。 それはサービス間でやり取りするデータで行います。 データ形式を思いっきり自由に拡張可能にして、 どんな種類のデータでも統一インターフェースで受け渡し可能にします。 オブジェクトだとこの拡張性が厳しいのですが、 XML と名前空間の組み合わせならぜんぜん問題ありません(ちょっと言い過ぎか)。

XML が拡張可能ということは、自分が知らない要素や属性が出てくる可能性があるということです。 でも、そんな拡張された未知のデータでもエラーにせずに、使えなければなりません。 そのために、知らない要素は無視する、という動作をデフォルトで行わなければならないのです。 SOAP の mustUnderstand 属性がデフォルトで false なのは、こういう理由からではないかと思います、たぶん。

で、このデフォルトで無視という動作は、 吉松さんがこのポストで言っている 「無邪気なまでにデータの読み手に解釈をゆだねる姿勢」 のデータの読み手側の一番簡単な実践なんだと思うのです。 本当はさらに吉松さんのポストのコメントで萩原正義さん(らしき人)が言っている「semantics を重視した…」 というのも直感的にわかりそうなのだけれど、今の僕には残念ながら理解しきれません。 だからとりあえず、 XPath なりで知ってる要素と属性をパターンマッチして知らないやつは無視、からやってみるしかないんだな、 というなんだか当たり前の結論になっちゃったなあ。

Google Fight : Make this fight with googleFight rest VS soap

» Permanent link | |

Google Fight というサイトがある。

使ってみればわかるが、要は二つのキーワードの Google での検索件数を戦わせるというジョークサイトだ。で、真っ先に思いついたのが REST vs SOAP。やってみたら REST の圧勝だった。

で、この Google Fight は RESTful に作ってあって、それぞれの対戦がブックマーク可能である。

そこで REST vs SOAP を del.icio.us に登録してみた。

登録したときの下心は http://del.icio.us/tag/rest を bloglines でチェックしている某Restafarianがこれを見つけてくれるのではないかということ。

そしたら見事に引っかかって :) ブックマークしてくれた。

ちょっと嬉しい。

Service Oriented の正体

» Permanent link | |

Newcastle upon Tyne 大学の Savas Parastatidis のこのポストが面白い。いや面白いというか感動した。ここ最近 Web サービス、REST などに関して混乱している僕に一筋の光明を照らしてくれたような気がする。Savas いわく分散システムの実現手法には以下の三つがある。

1. オブジェクト指向
2. リソース指向
3. サービス指向

彼はこれらの手法を、それらが採用する building block で特徴付けている。

オブジェクト指向の building block はインターフェースとオブジェクトだ。コミュニケーション抽象化はメソッド呼び出しの粒度で行われる。たとえば以下のような例が挙げられている

interface Calendar {
    Appointment CreateAppointement(Person, DateTime);
    void Cancel(Appointment);
}

リソース指向(REST)の building block はリソースと統一されたインターフェースである。オブジェクトとリソースの最大の違いはリソースそれ自身がメソッドを持たないところにある。リソース指向ではリソースの操作は統一されたインターフェースだけを介して行われ、それ以外の方法では操作されない。この統一されたインターフェースを、セマンティクスによって呼び分けるのも大きな特徴である。すなわち、オブジェクトは呼び出し可能な実体であるが、リソースはそうではないということだ。上記の例はリソース指向(REST)で書きなおすと以下のようになる。

POST InformationAboutNewAppointment 
TO http://calendar.com/appointments AND 
SEND created, http://calendar.com/appointments/123

これらに対してサービス指向ではどうか。サービス指向のにおける biulding block はサービスとメッセージである。ここで Savas が持ち出す記法はすごい。まずは以下の例を見てほしい。

AppointmentRequestMsg TO CalendarService FROM sender
AppointmentInformationMsg TO sender FROM CalendarService

AppointmentCancellationMsg TO CalendarService FROM sender

この記法の意味するところは次のようなものだ。まず AppointmentRequest メッセージが送信者から Calendar サービスに送られる。次に Calendar サービスから送信者に AppointmentInformation メッセージが送られる。見方によってはこれはリクエスト・レスポンスになるが、メッセージが送信・処理される、という一方向の組み合わせに過ぎない。それは Cancel の方を見るとよくわかる。 Cancel ではメッセージは送信者からサービスに送られるのみである。サービスから送信者には何もメッセージが送られない。オブジェクト指向や REST では一方向を実装規約で乗り切っていたことを思い出してほしい。オブジェクト指向では void という戻り値で、REST では空のメッセージを返すことで、一方向メッセージを実現していた。しかし、サービス指向では全ては一方向メッセージ交換、とその組み合わせで実現される。

Savas はこれを ProcessMessage Architectural Style と呼んでいる。そう、これは一つの Architectural Style なのだ。このスタイルではオペレーションはこの「メッセージを処理する」という意味の ProcessMessage しか存在しない。

このほかにもこのポストでは興味深い考察がいくつも挙げられている。WS-Transfer の位置づけや、サービス指向における verb の扱いについて、さらに WS-Addressing における wsa:Action の存在についてだ。

最後に彼は WSDL を IDL として使うことや、CORBA のオブジェクトをそのまま Web サービスとして出すことに反対している。これに通じる流れとして WSDL 2.0 に明確に反対する記事も出てきている。こちらも見逃せない。