Webサービスの概念を必要以上に複雑にしている力の話

正直、中島聡さんともあろう人がこんなエントリーを書くなんて。
SOAPは必要で使いやすい場面もあれば必要もない場面もある。JSONだって使いやすい場面と使いにくい場面がそれぞれたくさんある。

"Hello World"という一文を表示するプログラムを書くとき、JavaやC#は行数が増えてしまう。じゃぁLLだけでいいよね？といってるのと同じ。くだらない。

おいらがApacheSOAPで昔実装したときはXMLを扱うパフォーマンスも遅かったし、XPathも標準で扱えなかったりと結構大変だった。ベースがXML-RPCということで非常にシンプルな実装だった。プリミティブな引数と戻り値を使う場合何も難しいことはなかった。シンプルさで言えばXML-RPCのほうが上だったが、面倒な記述をすることによってクラスのインスタンスを丸ごと送ることは一応出来た。あくまでも面倒な記述はオプションであって必須ではなかった。

結局、十分なパフォーマンスが得られないことで、HTTPと自前のXMLによるRPCを実装することになった。XMLは拡張性に優れるのも売りにしていたわけで、野良XMLいわゆるJSONみたいな手軽な感覚のものを転送していた。十分なパフォーマンスがでていたらSOAPそのまま使っていたと思う。

その後Apache Axisが開発されることになる。使ってみてげんなりした。面倒くさすぎる。XML-RPCをベースにシンプルなままな実装だったSOAPは消えた。WSDLの生成やそこからのクラス生成など手順の逆転もあったがとにかく全てが大変だった。SOAPの最初のSがシンプルという意味ではなくなった瞬間だ。

その後印象が悪いままずっとSOAPからはしばらく離れていた。JavaEE5で簡単に開発できるようになるまでは。たぶんみんなが思っているSOAPってこの状態なんだと思う。XMLスキーマも面倒だしWSDLも面倒だし、XMLってシンプルさが売りだったのにいったいなんなの？と。

面倒なWSDlやXMLスキーマはツールによるサポートを期待していて、これをサポートしない環境からは地獄になる。Javaの生産性の高さがIDEとセットになっていてはじめて現れるというのに似ている。そしてツールやライブラリのサポートの状態が数年間よくなかった。

少なくとも型が重要なJavaにおいてはJSONよりJAX-WSのほうがはるかに開発効率も安定性もいい。おそらくC#も同じだろう。これら型の強い言語はツールやライブラリのサポートもあってカンタンにサービスの実装やクライアントの実装ができる。WSDLまわりもすべて全自動。publicなクラスを作ってこれはWEBサービスですよ、と指定するだけですべてが終わる。単純な値の転送であればXML-RPCやJSONでいいのだろうが、複雑に絡み合ったクラスを手軽に転送するのはSOAPでしかない。むしろマッピングの作業をしなくてはいけない分作業が増える。

AmazonやGoogleといったB2Cといったサービスだとクライアントの手軽さを重視するのがいい。B2Bで複雑なGUIが必要ならば、リッチクライアント、通信にSOAPといった形が開発効率や運用面デメリットが大きいはずだ。

RESTにしてもそうだが、一般ユーザーの目に付きやすいオープンなコンテンツ（いわゆる動的Webサイト）はブックマーカブルな実装はメリットが多い場合もあるが、これがログイン必須でブックマークをされると困るようなシステム（いわゆるWebアプリ）ではJSFのようなイベント駆動による開発効率を重視したほうがいい、というのに似ている。

JavaからJSONを使う場合、シンプルな通信を期待しているためクラスにマッピングしないほうがいいかもしれない。EL式を文字列に渡せばオブジェクトが帰ってくる実装だけでいいはずだ。つまりJavaからみたらXML-RPCの完全下位のようなもん。

UDDIのほうはもうばんばん捨てちゃっていい。というか、UDDIが発表されたときから「いいものだ」と言った人を誰一人としてみたことがない。