REST(参考記事・英語)に関する議論は行き詰った(参考記事・英語)、もしくは終わった(参考記事・英語)と一部の人々(source)が考えているときに、Ganesh Prasad氏(ブログ・英語)はRESTよりも根源的で (より良い) 物がある、と示唆して議論を再燃させようとした(source)。彼は、RESTに関する議論はしばらく堂々めぐりしていたという。
原文はこちらです：http://www.infoq.com/news/2007/12/rest-ws-payback
私はRESTが好きですし、SOAにおける非常にエレガントなモデルだと考えています。しかしSOAPベースのWebサービスモデルよりもどれほどエレガントか、を毎日毎日聞かされるのは少し退屈です。実際どれくらい退屈かと言うと、今まさに私がこんな辛辣な態度をRESTafarians (RESTの信奉者) に対してとろうとしているほどです。それから彼は、RESTafarianたちが自分たちの拠り所にしている中心原理をいくつか紹介した(source)。
REST は、最もスケーラブルなアプリケーションの機能を利用しています。それは - Webです。OK？RESTはWebの機能と戦うものではなく、一緒に働くものです。合ってる？HTTPは単なるトランスポートプロトコルではなく、アプリケーションプロトコルです。これでいい？URLはリソースを識別するのに最も自然な方法であり、HTTPの標準的な動詞はリソースに対して何を行うかを表すのに最も自然な方法で、ハイパーリンクはシステム全体をステートマシンとして表現し、全てのリソースを紐付けるのに最も自然な方法です。合ってるよね？しかし彼の目から見ると、RESTよりも古く、より拡張可能で、よりスケーラブルで、障害からの回復力も備えているものがあると言う。それはインターネットである。インターネットモデル ("障害回復力を提供するのに十分スマートな、ネットワークを使用したノード間のメッセージ通信。しかしそれ以上のものでは全くない) との連携が、あなたをさらに先へといざなうと言うのである。
インターネットの哲学は"間抜けなネットワーク、スマートなエンドポイント"です (もちろんネットワークが本当に"間抜け"なわけではなく、回復可能なパケットルーティング以上のことを何もしないよう、わざとその能力に制約を持たせている、というのは忘れてはいけません)。パケットルーティングのために、インターネットが使用しているプロトコルと言えばもちろんInternet Protocol (IP) です。新しい機能を追加するのも非常にシンプルである。
あなた自身がエンド・ツー・エンドのプロトコルを作り、メッセージのペイロードを運ぶ為にIPパケットを使用し、ノード (エンドポイント) 間でコミュニケーションを行うのです。あなたは誰かに"ミドル層では"などと相談したり、交渉したりする必要がありません。"ミドル層"が存在しないのですから。低レベルのコミュニケーションプロトコルと、高レベルの"アプリケーション"スタックの区別は、インターネットにおけるTCPの役割をGanesh氏が論じるところで明らかになる (UDPは歴史上のゴミ箱にまたしても放り込まれる)。
TCP はエンドポイントによって解釈されます。これが、コンピュータ上のネットワークソフトウェアが「TCPスタック」と呼ばれる理由です。IPネットワークに接続された各コンピュータはエンドポイントであり、IPアドレスによってのみ識別されます。IPメッセージの中身を処理するのは、これらエンドポイントにおいて行われます。インターネット (つまりIPネットワーク) は、ソケットやポート番号と言った概念については完全に無関係です。こうした (ソケットなどの) 概念は、IPネットワーク上でプロトコルによって作られ、使われているものです。拡張性が高い、インターネットの階層アーキテクチャは、インターネットの中核を成す、回復可能なパケットルーティング能力という基礎を変にいじることなく、より洗練されたネットワーク抽象化を可能にします。もちろんこの議論は、REST、SOA、WS-*、そしてメッセージ指向のアーキテクトたちが、疎結合とスケーラビリティを達成するいくつかの核となる原理について議論してきた(source)ものと、多くは似通っている。可能な限りサービスエンドポイントの裏にあるものを隠す、ということである。インターネットが機能要求の変更に対していかに柔軟で、回復力を備えているかの例として、Ganesh氏はIPSecを挙げ、こうしたプロトコルの追加がインターネットに大きなオーバーホールを必要としたかどうかを (レトリックを用いて) 尋ねている。
... 彼らは単にESP (Encapsulating Security Payload) と呼ばれるエンド・ツー・エンドのプロトコルと、それを理解するエンドポイントを別に作っただけです。それから彼らは、TCPとIPの間にそれを"層"として挟み込みました。さらに、いかにしてインターネットが"電話通信においてさえも、Telcoネットワークを打ち負かしたか"についても取り上げ、Ganesh氏はREST (そしてWeb) が、分散コンピューティングインフラの他の形態に比べて優れているというわけではないことを説明した。
インターネットは、分散化されたイノベーションのためのプラットフォームです(RESTafariansが注目を集めようとしているWebはまさに、インターネットにおいて可能なイノベーションの例です。HTTPはエンド・ツー・エンドのプロトコルです。覚えてます？)。しかし、WS-*はどこに忘れてきたのであろうか？今までのところはインターネット対REST (実際はWeb) についての議論であり、WebサービスやSOAPについてはしていない。しかし、SOAP-RPCを忘却の彼方に押しやった後、Ganesh氏は彼にとってのSOAPメッセージの定義を明確にした。それは"WS-Addressingヘッダ付きのSOAPメッセージ"であるというものである。WS- Addressingを使用することで、メッセージはIPパケットと同様経路と無関係になる、と言うのがその理由である。この類似性について、彼は次のように述べた。この双対性を明らかにする(source)ための分かりやすい図(source)もいくつか提示している。
「SOAP メッセージをいかにルーティングするか」を知っており、それ以上のものではない、と言うメッセージングのインフラを想像してみてください。...どうやって取り入れ、より高いレベルの機能をどう構築すれば良いのでしょうか？もちろん、インターネットモデルに従えばよいのです。各々にプロトコルを作り、それらのメッセージをSOAPメッセージ自体 (具体的にはSOAPヘッダ内) に全て埋め込むのです。それらをTCPスタックのレイヤとする必要はありません。なぜなら、信頼性のあるメッセージ伝達、セキュリティ、トランザクション・・・などは全て直行する関心事だからです。それらは全て、SOAPヘッダブロック内に同じレベルで共存することができます。このアプローチをとると、"疎結合なサービスのエコシステムに必要とされる配管"と記事中で呼ばれている物に最終的には行きつく。明らかにこれはSOAをベースとしたアプリケーションを構築するには不十分だが (他の人々と同様、Ganesh氏はSOAとWebサービスを同一視している(source)ようである)、XMLがそれを手助けする。
XML スキーマ定義言語や、あなたが選んだボキャブラリ (銀行向け、保険向け、航空会社向けなど) を用いてドキュメントを定義し、それらに適合するXMLドキュメントをSOAPメッセージのボディに格納すれば、あなたのメッセージの生産者と消費者は、そのドキュメントの規約にのみ確実に依存します。ほら！疎結合です！サービス指向アーキテクチャです！現実世界における標準と言うものがそれほど容易なら、あなたは合点がいくだろう。しかし、もしそれが容易だとすればこんな質問がすぐ浮かぶ。なぜまだそうなっていないのか？Ganesh氏は、Ganesh氏が言うには、この件の裏には6つの理由が隠れていると確信している。
- SOAP-RPCのレガシーな資産: "今日でさえ、WSDLの利用はRPCを意味する(source)、と述べる学派があります。しかし私は、図々しいとも言えるRPCエンコーディングではなく、document/literalスタイルでラップする(source)ことに満足しています。"
- HTTP以外のSOAPバインディングについての標準の欠如
- ファイアウォールを通過する必要性。これは、デフォルトのSOAP/HTTPバインディングとも関連しています。"私たちはSOAP自身のポートを定義する必要性があります。そして、そのポートがファイアウォールを通過できるようにするのです。ポート80番を飾りたてるのが好きだから、と言う理由でHTTP航空に搭乗するのをもうやめましょう。
- 中央集権型のメッセージブローカソフトウェアのベンダは、SOAP/WS-*のビジョンを採用しているふりをしています ("私たちは標準委員会に名を連ねています！")。しかし実際には、彼らはエンドポイントウェアではなく、ミドルウェアを売り歩くばかりです。
- 業界内における、クローズドソースのWS-*スタックの優位性
- 多くの重要なWS-*仕様 (トランザクション、セキュリティ、信頼性など) が、ほんの最近やっと完成したばかり (にも関わらず、5年間使われ、開発されていました)と言う事実
原文はこちらです：http://www.infoq.com/news/2007/12/rest-ws-payback