【sMash】 なぜReflexとsMashの組み合わせがよいのか

　今回は、先日の記事、ReflexとsMashによるソリューションの提案 の構成をなぜ考えたかについて説明する。最初はあまり深く考えず、直感的に、両者を組み合わせることで強みと弱みをお互いに補完しあえるペアになればいいな（オグシオ？）、ぐらいに考えていたのだが、デモを作っているうちに本当にそうだと確信できるようになってきたので具体的に説明したい。





　まず、sMashについては、こちらで説明したとおり、Controlの役割に使うことで真価を発揮する、と私は信じている。Reflexについては、Entity設計を基本に考えていることは時折述べているとおりである。つまり、この絵にあるように、sMashはControlに重きを置き、reflexはresourceに重きを置いている。もちろん、sMashだけでアプリケーションを作ることは可能である。Reflexもしかりなのだが、要は組み合わせによる相乗効果を期待できて、かつ、それが単体で作るよりも生産性が高くなるかどうかが判断基準となる。相乗効果と思えるものは具体的には以下のとおりである。まず、Reflexから。

＜Reflexのメリット＞

１．System-iからデータをXML/JSON化して簡単に取り出せる（JDK1.4ベースでTomcat4.1が動作するSystem-iで稼動実績がある）
２．Reflexを使うことでPDFを簡単に出力できる
３．リソースの統一したデータ表現が使用できる
４．トランザクションを明示的にコードに記述しなくてもよい

　Reflexのメリットのうち、最も効果が大きいと考えているのが、リソースの統一したデータ表現が可能になることである。この資料のP80を見ていただきたい。リレーショナルモデルは表形式、リソースモデルは自由とある。このリソースモデルは自由というのが曲者で、複雑なリソースをRDBにどうマッピングすればいいか、いつも問題になる。AXISでもwsdl2Javaに限界があり、複雑な入れ子のスキーマに対応できていなかった。それがAXIS2になっても改善されなかったのは酷い話である。AXIS2のデータバインディング能力

sMashではこの問題についてイベントを複数実装することで解決しようとしている。（資料P81）。でも、こうやってしまうとリソースが多い場合にマッピングだけで多くの労力をつかってしまうはめになる。「MVCモデルは進化する」でも述べたが、O/Rマッピングにかかる工数はバカにできない。
　そこで、Reflexの登場となる。Reflexでは、WSDLの代わりにReflex表現を使って自動生成したJavaBeanを使用する。Reflex表現を使えば複雑な入れ子のJavaBeanを生成できる。そもそもこの問題に対応することがReflex開発の動機であったのでできて当然である。あとは、それぞれのJavaBeanをDBのResultSetとして使用すればよい。ちなみにReflex表現はスキーマ言語の一種で、Reflex Entity Editorを使えばビジュアルに作成できる。

Reflex Entity Editor

次に、sMash。

＜sMashのメリット＞

１．外部リソースのデータに簡単にアクセスできる。（Integration FablicによるConnectionとMediation）
２．リクエストに応じて適切な場所に処理を振り分けることができる。(GlobalContextとEvent Handler)
３．処理や画面を簡単に開発することができる(GroovyとGroovy template)
４．コンポーネントを簡単にアセンブルできる(FlowとFlowEditor)

　一方、sMashのメリットは４のFlowによるアセンブル機能である。Integration Fablicにより、外部リソースを抽象化し、コンポーネントとして扱うことができる。また同時に、イベントハンドラーによるコンポーネントの呼び出しを可能にしている。これにより、Flow定義を記述するだけで開発できるようになる。後は出力用のデータを変換（マッシュアップ）を行えばよい。
　Flowのビジネスロジックからの外だしは長年にわたって革命的であると言われつづけ、ワークフローエンジンも多数商品化されたが、BreakThroghはできなかった。sMashでここまで簡単にやられると受け入れられる可能性がかなり高くなったのではないかと感じている。この資料より引用（P29)

最後に、補足として以前書いた記事を紹介しておきたい。

マッシュアップはサーバでいいんですか。いいんですよ。からの引用

それから、sMashで最も重要だと思う点は、サーバサイド Mashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの３つに依存した密結合開発であったものを、 RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。