トップ «前の日記(2009-12-12) 最新 次の日記(2009-12-14)» 編集

日々の破片

Subscribe with livedoor Reader
著作一覧

2009-12-13

_ 手作りでSOAPしますか?

O'REILLYにJava Seb Services: Up and Runningという本がある。

Java Web Services: Up and Running(Martin Kalin)

オライリーの動物クォリティーだけあって、良い本だ。

では、万人にお勧めできる、あるいは千人がこぞって買うか? と訊かれると悲観的な感じになる。

おもに2つの観点からだ。

この本は特にJAX-WSに焦点を当てたSOAPベースのWebサービスについて書かれている。

もし、SOAベースのシステムでSOAP連携を前提にアーキテクチャを考えるとなったら、この本は必携……となるはずだが、おれにはそうは考えられない。

つまり1つ目の観点は、JAX-WSというミドルェアを直接利用した連携にどれほどの需要があるか、ということだ。おれがこの観点から否定的なのは、IBMやMS(をインフラとしてSIするSIer)の選択肢に、JAX-WSを利用したベンダー非依存なJava中心のシステム構築というのは存在しえないのではないかと考えているからだ。

しかし本書はUSでは結構売れているとは聞く。でもそれは、比較的小規模なシステム部門であってもCTOがいて、ベンダー非依存のシステムを構築するような土台があるからではないか? あるいは巨大ベンダー非依存のシステムを構築することを特徴とする独立系ソフトウェアベンダがあるからだと考えるほうが自然だ。

2つ目の観点は、より下位のレベルで、つまり実装時点でクライアントをJAX-WSを直接利用するようにシステム開発を行うか、という点だ。もしそうであれば、本書はJAX-WSの利用(WSDLの使い方を当然含む)についてきちんと解説しているため、必携と言える。

しかし、これについても全く悲観的だ。JAX-WSを生で利用するのはおそらく趣味のレベルと評価されてもおかしくない。

本書にはWeb Serviceのセキュリティ確保手法について1章を割いている。これはきちんとしたまとめで、この章の内容程度が身についていることは常識の範疇とも言えるのだが、その反面、何も考えずにHTTPS+まっとうな認証さえ用意すれば企業システムであれば十分とも言える程度にミドルウェアは枯れてきているので、そこに学習時間を使うのは無駄と言えなくもない。(と考えている人が多数を占めているのではないかと想像する)

本書にはREST+SOAPの論点まとめ(最終章)や、JAX-WSからのREST利用についての(やや偏った)説明とサンプルもあるが、これもどうなのだろうか?

別の切り口として、企業システムを考えた場合のトレンドはクラウドで、クラウドでのストレージはKVSを前提として……と考えると、いかにもSOAPは筋が悪い。KVSを前提とした時点で、RESTに軍配を上げることができる(原理的に)はずだ。

この観点からは、(現時点での必要性からではなく)中期的な将来性からJAX-WSベースでシステム連携を考えるために本書を読むということも考え難い。

同様な理由から学生にとって魅力的な学習内容とは考えにくい。

Java Web Services: Up and Runningについて(詳細)

追記:るいもさんの全体最適化しないためのSOA(SOAP連携)は興味深い。企業内システム連携の疎結合アーキテクチャパターンの実装手段としてのSOAPという観点からは(JAX-WSへの具体的言及が多いとは言え)この本は具体性があるだけに読む意義はある。

本日のツッコミ(全13件) [ツッコミを入れる]
_ rokugen (2009-12-13 11:38)

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

_ arton (2009-12-13 13:02)

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

_ masayh (2009-12-14 14:34)

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

_ arton (2009-12-14 14:51)

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

_ masayh (2009-12-14 16:06)

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

_ arton (2009-12-14 16:52)

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

_ masayh (2009-12-14 17:23)

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

_ arton (2009-12-14 17:35)

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

_ masayh (2009-12-14 17:55)

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

_ arton (2009-12-14 21:08)

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

_ masayh (2009-12-15 11:43)

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

_ masayh (2009-12-15 11:46)

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

_ arton (2009-12-15 23:29)

セキュリティについては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なのかな)が使えたほうが(あまり考えなくて済むので)便利だとは思います。だから無くてよいかどうかは判断は保留。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|

ジェズイットを見習え