【IBM sMash】 マッシュアップはサーバでいいんですか。いいんですよ。

　先日、IBM@渋谷マークシティでsMashの話を伺う機会があった。sMashは、RESTful SOAということで、いわゆるWeb2.0的な今どきのコンテナである。sMashの主な特長は以下のとおりだ。（今回はsMashについて説明するが、私の主観がかなり入っており、IBMの戦略や意図とは異なる部分があることをご容赦願いたい。断定的な言い方にはすべて「～のような気がする」を追加して読むぐらいがちょうどよいだろう。）

* JVMで動作するGroovyとPHPをサポート
* 軽量(LightWeight)なコア
* RESTfulなSOA設計。
* サーバサイドMashup
* クライアントはDoJoだが強要するわけではない
* オープンプロセスで開発されている（オープンソースに近い)
* オープンレポジトリ　(by Ivy,Maven2）
* デュアルライセンス（大規模に利用するときに限り有償）

まず、RESTfulについて、URIの設計がリソース中心できれいに設計されている。とてもシンプルで分かりやすい。今流行りつつある、URItemplatesは提案してみたものの、意識すべきかどうか微妙だと思った。必要があればquery parameterを追加すれば十分かな。
クライアントでDoJoを強要するわけではないに同意。リソースから簡単にPDFを作成できる弊社のReflexiTextやクライアント設計モデル（JavaScript版Strutsのようなもの）と組み合わせるといいものができそうだと思った。ivy,maven2レポジトリの採用はとてもいい。
　それから目に付いたのは、JVMで動作するGroovyとPHPのサポート。そして、軽量であること。これには今のLL時代にどう対応するかというIBMの苦悩と戦略を感じる。Project ZEROといわれるように、Web開発のあり方を根本から見直すことで、重厚長大なJava文化を払拭して、スクリプト言語の高い生産性を取り入れる一方、これまで培ったJavaの資産を活用する戦略である。なかには、これまでのJava戦略を覆すとか、SCA・SDOの立場はどうなるとか、疑問・不信を感じられる方もいるかもしれないが、元IBMerである私は、これがとてもIBMらしい一貫した戦略であることが理解できた。なので、ちょっとここで説明させてもらいたい。
　IBMが十数年前から貫いているソフトウェア戦略の一つに、お客様のソフトウェア資産をマルチプラットフォームでサポートするということがある。小さなPCで始めた業務アプリがスケールアップしたときに、メインフレームほどの大きな環境を用意できるのはIBMだけだから、安心してIBMに任せなさいと。しかし、かつてのOS構想(OS/2、OS/400、OS/390)では、統一したAPIでそれを実現しようとしたがうまくいかなかった。ところがJavaはうまくいった。WebSphereとDB2により、すべてのプラットフォームで一度書いたアプリが動くようになった。
　お客様資産の活用とは、お客様自身のデータおよび既存アプリケーションの活用である。それをサクサクとインターネットなどへ適用できれば大きな価値を生み出せる。実際にY社の荷物追跡システムはそうだった。今でこそ一般的に使われているが、当時はお客様自身、その価値に気づいていなかった。これは、お客様資産の活用が困難で、時間やコストがかかっていたなら実現できなかっただろうと思える。
　そこで、さらに一歩すすんだことを考える。マルチプラットフォームでサポートすることがお客様へのコミットメントであるなら何もJavaにこだわる必要はないわけだ。要は、JVMを活用しながら他の言語でもサポートできるようにすることが、お客様資産を活用することにもなる。Javaが敬遠される理由には、納期が長い、融通がきかない（仕様に準拠しないと怒られる）、開発費が高いなどがあるが、LLで解決できるなら、それでよいのではないだろうか。

　また、GroovyとPHPが必要な理由と、サーバサイドWebアプリの否定ではないことを付け加えたい。ブラウザから直接サービスを実行するスタイルが主流になることは認めるが、この記事の後半でも触れているように、XMLを仲介する変換サービスや、ちょっとしたHTMLをサーバサイドで行う必要がどうしてもでてくる。このちょっとしたコーディングはスクリプト言語が最も得意とするところである。

　それから、sMashで最も重要だと思う点は、サーバサイドMashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの３つに依存した密結合開発であったものを、RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。分業のメリットがいかに大きいかは、この記事で説明したとおりである。
　また、Controlに位置するものは、今どきの言葉でMashupといったが、これには違和感を覚える方もいると思う。私は、Mashupをただの変換・編集とするのは間違いだと考えている。ビジネスロジックを含み、また、マッシュアップしたコンポーネントがさらにリソースと同等になるとさらによい。データ更新にはトランザクション管理を伴い難しいので、現在はまだ変換・編集が多いのも事実だが、今後はビジネスロジック中心に組み込まれていくのは明らかである。私は、Mashupが単なる変換・編集からビジネスロジックを含むControlに役割が変わったときに、本当の意味でオブジェクト指向設計の次の段階に進むことができると信じている。
　これまでにも、ワークフロー設計は、ESBやワークフロー製品で採用されてはきたが、往々にして重厚長大になり、コスト面で引き合わなかった。このような統一したアーキテクチャーのもとではどうしても重厚長大になってしまう。それがRESTful SOAにより疎結合開発が可能になろうとしている。これには統一したアーキテクチャーはいらない。リソースの設計において、コンベンション（規約）を重んじることでインターオペラビリティ向上が図れるからだ。リソースを積み木のように組み合わせて開発する。本当にそれが実現できれば、RESTful SOAは、進化ではなく革命に近いものになるだろう。
　
　最後に当面の課題について触れたい。
　まず、Webアプリ開発者にとっては、どうやってシステムを設計、実装していけばよいか、イメージが伝わりにくい。先に述べたように、Webアプリではそもそもワークフロー的に作る文化がなく、サービス志向、REST志向で作る文化もない。SOAPは古くからあるが少数だ。また、更新系の設計をどうするかも課題だ。コンポーネント間の2phaseコミットは大変かもしれないが、トランザクションスクリプトでシンプルな設計にすべきだと思う。とにかくシンプルにして多くの開発者に支持されないと、SCA、SDO、ESBといったManagedなアーキテクチャスタイルで陥ったように、シュリンクを経験するはめになる。

　Project ZEROは、Incubator Project（将来的に有効に活用できそうな新しいアイディアや技術を模索するプロジェクト）の一つで、Don Fergusonの発案らしい。
Managedなアーキテクチャスタイルに背を向け、IBMを全速力で飛び出してRESTを志向した私であるが、そこで書いた絵はsMashと瓜二つ。お釈迦様（Ferguson）の指に書いた孫悟空、といったところかな。

＜追記＞
こちらに提案を書きました。
ReflexとsMashによるソリューションの提案