わたしも若干似たようなことを考えていたのだが、　やや細かなことが気になってしまった。それは、メッセージング・フォーマットがJSONであること。
※ちょっとした話題になっているらしい、本筋の似非MVCの件はさておく
[こちらはこちらで、OSGi+JSONという組み合わせについて別途調査予定]。

JSONは、オープンななデータ・フォーマットではあるがXMLと比べるとマイナーで、Google Protocol Bufferなどのバイナリ形式に比べると、(まともにオブジェクトの永続化をしようとする際に)パフォーマンスに劣ると考え、二の足を踏んでいたのだ(ということで、わたしは、文書形式のデータの扱いにはXMLを、オブジェクトの永続化にはProtocol Bufferを好んで使ってきている)。アップルがリーダーシップを発揮するWebkitを絶賛している氏が、その名の通りJavaScriptのオブジェクト表記に端を発するJSON(JavaScript Object Notation)を推すのは理解できるにしても。

JSONは、調べてもらえはすぐわかるとおり、実に簡易でゆるいデータ・フォーマットである。そのため、JavaScript以外のオブジェクトを永続化するために、JSONの「オレオレ拡張」がいくつも登場している。XMLでは、メッセージング・フォーマットがさまざまに「標準化」(SOAPからSAML/XACML、さらには近時のAtomPubまで)されている。それを多少なりともかじった身としては、JSONのオレオレ拡張にいささか不安を覚えてきた。

だが、マイ言語であるScalaでの、同趣のアーキテクチャ提案といえるJOSHを見ながら、近時の状況を思い返すうちに考えが変わりはじめた。わたしは、近時、Scalaベースの分散メッセージング環境Akkaと、JSONデータ(正確にはJSONに制約を加えたBSONデータ)を扱うMongoDBに注目している。AkkaやMongoDBは「まだまだこれから」のフレームワークである(両者が、いかなるものであるかについては別にエントリーする)。こうした「まだまだこれから」の対象を扱おうとするとき、やり取りするデータフォーマットが「たかがJSON」であることは、心強いことなのだ(いざとなれば、「まだまだこれから」なフレームワークを置き換えることも、自前でパッチをあてることもできそうである)。ゆるく簡易なデータフォーマットであるJSONならである。XMLではオーバーヘッドが気になる世界、Protocol Bufferではテストに不安がある場合に、まずは使って見るというはリーズナブルに思えた。

JavaはXML webサービスをそれなりに普及させてきた。.NETは、イントラネットに閉じてはいるが便利な世界をMS仕様で普及させてきた。こうした世界からすると、JSONは頼りない簡易なフォーマットである。だが、オープンで簡易であることは、スピードが求められる開発においては、「今ここ」のニーズを満たす限りにおいて正義なのだ。

そう理解したわたしは、JSONに頭から猜疑の目を向けることをやめることとした。実際にXML+Protocol Bufferで確立させつつあった俺流RESTfulサービスにJSONを組み込むことがあるのか、はたまた全てのデータをJSONで扱うサービスを作ることがあるかはさておいて。