日々の破片

地域情報プラットフォームという自治体標準規格があるんですが、SOAPでWEBサービスI/F作れという事なので、自治体仕事をする場合は考慮しないといけないんですよねぇ・・・やってて（というかやる前から仕様読むだけで）しんどいです。やめたい・・。

なるほど、自治体仕事にもSOAPが入ってきているんですね。どうもありがとうございます。<br>SOAPのメリットって仕様を読まなくてもWSDLをツールに食わせればクライアントが得られる点だと思いますが、それだけでは済みませんからね。

統合セキュリティなど企業とクラウドのアプリケーション連携やデータ連携でもWS-*の仕様が利用されます。RESTだけではその部分は解決できません。また、ワークフローとかを想定するとBPELも入ってくるでしょう。BPEL自体普及しているとはいえませんが、なかなかRESTだけというわけにはいかない例です。

ワークフローについては判断できないのでちょっと置いておくとして、WS-*のうちクラウドと企業の連携で必要となるものは品揃えという点を抜きにすると、現実問題としてあり得ますか？ 統合セキュリティ(完全性、機密性、可用性を備えるという意味と解釈して)についてもコストパフォーマンス(ここまでやればここまで守れる)で考えるとRESTで十分実現できると思うのですけど。

RESTで実現できないというのではなくて、やるとするとSOAPでやる程度にコストがかかり複雑化するのでREST利点がなくなるということです。統合セキュリティはWS-Trust、WS-Federationをサポートしなければいかないし、基本的にマルチパーティですから。KVSのアクセス制御などを管理するにはかなり困難です。

まず、それはSOAPミドルウェアを手にしていることを前提としていますね？ したがってRESTでやるとSOAPでやる程度……という話になるわけだと解釈します。<br>すると、DCE/RPCレベルのことをHTTP＋作りこみではできないという過去の議論をしているように見えます。で、その作りこみをDCE/RPCのようにしてしまったのが今のSOAPで、それはやめておきましょうというのがRESTだと認識しています。<br>したがって、方法論のような技術的なことではなく、どのレベルまでお膳立てが必要かというプロダクトの品揃えの話に結局おちているように感じるのですけど。

抽象論ではなくてKVSでのアクセス制御をスキーマが各行で異なる、1億レコードとかを想定してRESTでやってみてください。たぶん、使えないと思います。そうすると、もっと密な結合が必要になりますね。プロトコルに非依存という点ではRESTは弱いのです。扱う状態の粒度も大きすぎる。別にSOAPがいいと言ってるのではありません。SOAPも同様なもんだいを持っているので。

その場合、むしろSOAPでどう扱えばよいのかそっちが疑問です。<br>その1億レコードがRWであるとして、かつ排他制御が必要だという前提（すでにモデルが破綻しているような気がするけど）だと、組み合わせをキーとしたタプルスペースのようなものを用意する以外にアクセス制御はできないと想います。逆にタプルスペースで管理することにすれば、PUTとDELETE（サーバに時間起動のタプル回収機構を用意すれば、書き込み前に権利を保持しているかどうか判断できる）で十分に管理できると想います。<br>というような話なのか、もっと全然別の話なのか短すぎてわからないなぁ。

もう1度、基本に戻りますがRESTはHTTP上に実装されたアプリケーション層のプロトコルです。ですから、階層レベルがそれより低位のインフラに近いレベルの機能の実現には向かないということです。たとえば、クラウドに参加するノードのジョインのプロトコルに使うことなどです。実装できるということと適切さの議論は分けて考える必要があります。なんでもRESTでできますということと、それではセキュリティのプロトコルはすべてRESTでということとは違います。現実には密結合の場合にはRESTは不適切です。異機種間接続という点と密結合という点、それから、アプリケーション層より低レベルの機能という点は分けて考える必要があります。異機種間接続だからRESTというのは適切さに欠けます。<br>.NETの型システムでスタックで動作する型とヒープで動作する型がある例と類似です。

戻った基本が間違っていますよ。まず低位のインフラを扱うのはサービスですし、密結合にRESTを使えば良いとは全く考えてもいませんし、どこからそういう話になるのかが難しい（たぶん、どこかにそういうアイディアが含まれていたのだとは想うけど、そのへんが短くてわからないということ）。というか、RESTは疎結合インターフェイスのインフラですね。<br>でも、そこに異機種間接続が出てくるということは、密結合という言葉が意味しているのは、物理的な話ではなくて論理的な話なのかな。というのを前提とした場合、現在の少なくとも（チャネルとかではなく、最低でも1台のルータが間に挟まるような）ネットワークでは、レイヤの追加は障害の発生と問題解決の困難さの指数的増大を招くというのが現状だという苦労の経験の蓄積から生まれた信念が僕にはあるのですよ(だから状況が変わればすぐにその信念は新年を迎えて消え去ります)。<br>したがって、物理的には疎結合、論理的には密結合というのは、選択肢にはありませんね。

RESTの認識については合意できていると思います。クラウドでRESTが有効なのは、インターフェイスの部分、コラボレーションの部分でしょう？それ以外のところは別のプロトコルが適切なはず。だから、セキュリティのインフラに近いサービスはSOAPないし別プロトコルが適切と考えるのです。RESTはトランザクションやセキュリティの機能を他の技術に依存しているので、それらを利用する場合には、サービスインターフェイスでも制約が出るでしょう。たとえば、マルチパーティの通信モデル。物理ルータという低レベルでないアプリケーションのプロセスを扱う場合も同様な制約を持っている。現在の仮想企業ではそうした例は増大しています。サプライチェインなど。<br><br>後、将来的なことを言えば４つのverbはいらないと思えます。２つでいい、CとR。そうなったときRESTはまた別の技術になると思えます。

>物理的には疎結合、論理的には密結合というのは、選択肢にはあ<br>りませんね。<br>現実にはこれ多いです。技術として正しくないとしても。

セキュリティについてはSOAPであればエンベロープそのものが標準的な形式でセキュアにできる（カプセルですね）メリットがあるというのは納得しました（なひさん、thanks）。それは中間的なノード（ここに対しては情報を公開するつもりはない）に一度ストアさせるような場合にはメリットですね。<br>そういうメリットは認めたうえで、しかし、論理的密結合を物理的な疎結合システム上で実装するのであれば、ロングトランザクションをまじめに実装するべきではないですか？ この場合、元のクライアントが全体の状態を管理し、通信先はその中での状態にのみ責任を持つことになります。とすれば、インターフェイスには、REST（最初のPOST、次のPOST……受信ノードはPOSTされたデータを自身の単位でトランザクションとして扱う。クライアントが途中で失敗に気づいた場合は、最初のPOSTを取り消すPOST、次のPOSTを取り消すPOST……受信ノードはPOSTされたデータによって自身がコミットした以前のトランザクションを巻き戻す（あるいは無かったことにする））とするのが良いと思います。URIによるリソースの一意指定と少ないverbによる単純な操作というアーキテクチャ（HATE……はこの場合にどう利用できるのかまだわからないです）は、ロングトランザクションに対しても有効で、かつアプリケーションの興味の中心である個々のノードの実装に対する集中を与えられると思います。<br>あと、突然出てきた4つのverbですが、GETとPOSTでカバーできるというのは、直観的には正しいと思います（なので1990年代はGETとPOSTですべてカバーできていた）。ただし、PUT（これは特殊なPOST）、DELETE（これも特殊なPOSTなのかな）が使えたほうが（あまり考えなくて済むので）便利だとは思います。だから無くてよいかどうかは判断は保留。