週末の号外BPMオフ-flowrフェスティバルでしゃべらせてもらう内容の一部を先出し的に書いてみる。
「Webアプリケーションの連携において、コストを下げるために疎結合」というとSOAPがあった。
2000年から2001年頃にかけてSOAP関連技術の喧伝する内容に夢を抱いた人も少なからずいたことだろう。恥ずかしながら*1自分もその一人だった。
そして実際にSOAPでアプリケーション連携を行ってみると(互換性のことはとりあえずおいといても)思った通りにいかない部分があれこれあることがわかる。
確かに通信は疎結合になるのだが、多くの場合に仕様が密結合してしまう。それを避けるためには余程うまくアプリケーションを設計しなければならない。
つまり、通信層を疎結合にするだけでは駄目で、アプリケーションのデザインを疎結合にしなければならない、ということをSOAPから学んだ。
最近、RESTへの注目が高まってきているのを感じるが、個人的にはそういう分脈の中でそれを捉えている。
RESTはまさにアプリケーションのデザインを疎結合化するアーキテクチャスタイルであり、その問題の解となる可能性を持っていると思うが、まだいくつかの課題も抱えている。
それは次の３つだと考えている。
- (1) RESTfulなアプリケーションを開発するためのコストが高い
- (2) RESTに対応したフレームワークを(効果的に)使うためには、RESTやROAの知識や理解が不可欠
- (3) 「キラーアプリ」の不在(RESTにするとこんなにいいことがある等)
まだ今は「うまく設計すればちゃんと効果的なRESTful」という状態に近く、それはSOAPとほぼ同じ状況だ。Webアプリを作るのにHTTPプロトコルの理解が必須なような状態、と言い変えてもいいかもしれない*2。
でもSOAPとの一番大きな違いは、SOAPは意識せずに使えるようになっても問題の解決には全くつながらなかった*3が、RESTがそうなれば一気に状況が変わる可能性があるということだ。
つまり「REST/ROAの知識や理解がなくても使えるRESTなフレームワーク」があれば先の課題の (1) と (2) は解決できるのではないだろうか。Railsのようなスタイルごと強制するフレームワークは一つの方法かもしれない(実際、Rails2.0 はかなり頑張っている)。(3) の「キラーアプリ」はそれとはまた別に必要だが……。
そういうフレームワークを作るにはまだいくつかブレイクスルーが必要だろうが、自分でそれを提示できるようにはまだなっていない……
ので、必ずしも REST までいかないけど「(連携において)アプリケーションのデザインを疎結合」にする別のアプローチが無いだろうかと考えたのが flowr なわけだ。続きは web で、じゃなかった、号外BPMオフ で(笑)。
オフには REST に一家言ありそうな人もあれこれ来てくれるんじゃないかなあと期待していて、上述の REST の捉え方も含め、そのあたりのご意見・感想を伺えたら、と思っている。
