複数の技術をScalaで統合する

要件定義検証ツール SCALA

最近少し時間が出来たので要件定義用のツールをまた開発している。
Webベースのクラサバ構成とし、不要なデータ交換を極力避けるためにオブジェクトテクノロジーで通せるアーキテクチャとして以下の構成にした。

　 クライアント
Flex
サーバー
DB：NeoDatis オブジェクト指向のDB
言語：Scala
通信：BlazeDS Flexとサーバーサイドの通信手段
コンテナ：Jetty HttpServer

クライアントはJavaFXが使えればJavaVMで固められるので、可能性を少し探ったが大きな障害が２つあった。
ビジュアルな図をプログラムと統合するツールが無い、イラストレーターやフォトショップからの変換ツールはあるが、どちらのツールも使い慣れていないので使えない。
それでもNetBeansでコードガリガリでも我慢できたが、もう一つの問題が致命的だった。それはGUIコンポーネントが未整備でとてもFalshプラットフォームやSilverlightと比較にならない貧弱さだった。
まあ最後発なので今後に期待するしかないのだろう。
FlexもFlashと組み合わせることでビジュアル表現が格段に向上する。Flex単独だとjavaFXとあまり変わらないのだが、Flashで動きのあるコンポーネントを作成し、それをFlexに持ってくることでGUIツールの組み合わせでは表現できないことが簡単に実現出来る。

次はSilverlightもかなり魅力的だった。プラットフォームとしてはマルチスレッドが使える分だけ、Flashよりもしっかりしている印象を受ける。また、開発言語も選べるのは魅力的ではある。
しかしScalaを使い慣れてしまうと、他の言語はどれもいまいち使いにくい。
F#もいいが、これも３年ほど前に１週間くらい使ってみたがいまいち感覚が合わなかった。
一番違和感を感じたのは手続き的なプログラミングスタイルが「in」でつないでインデントしていくことだった。
これは関数型プログラミングから見るとスマートなのかもしれないが、手続き型言語から来た私にはちょっと違和感があった。
Scalaの.NET版があれば間違いなくSilverlightを選択していると思う。

結局クライアントはFlexにした。
今年に入ってFlashの使い方を覚え、Flash＋ActionScriptでプロトタイプをつくってみたが、グラフィカルツールと言語が緊密につながり、コンポーネントが簡単に作成できるのには驚きだった。
VisualStudioやNetBeansなどでもビジュアルコンポーネントを作りツールに組み込めるが、レベルが違っている印象を受けた。
非常に直感的な操作でコンポーネントを作りツールに組み込める。
しかし、そもそもアニメーションツールから来ているFlashでTextAreaやCombBoxなど普通のGUIコンポーネントを扱う操作はあまり直感的ではない操作感（ListやTreeがただの四角しか表示されない）であった。
それでもGUIコンポーネントがFlexなみに整備されていたら、Flash＋ActionScriptでクライアントを作ろうかと思ったが、Flexをちょっと使ってみてその簡単さと簡潔さにやはり、Flexで作成することにした。
それにGUIコンポーネントもそれなりに充実しているのも決め手の一つになっている。


サーバー側の組み合わせは割と簡単に決まった。
基本的に言語はScalaを使いたかったので、そこから以下の非機能要求で決めた。

　・Scalaが使えること
　・各種コンポーネントを使う上でデータ変換が不要なコンポーネントを採用する
　・ドメイン分析したオブジェクトがそのまま動くこと
　・組み込みのサーバー機能が使えること
　・クラウドへの移行がしやすいこと

そこで先にあげた構成とした。

○永続化
RDBということも考えたが折角だからオブジェクト指向DBを使うことにした。
最初はDB4Oを試したが、ライセンスがGPLで購入も料金がはっきりしないことから他のものにした。
丁度DB4Oと同じインターフェースでNeoDatisというのがあるのでそれを使うことにした。

DB4Oと同じネイティブクエリーを使えるし、APIも似ている。実際DB4OからNeoDatisへの移行は２，３時間でできた。
違いはチューニングのためのパラメータがDB4Oの方が多いことではないだろうか。当然そこから機能性に違いがでるがデータ量が少なければチューニングが必要ないのではないかと考えている。

Scalaとの親和性では２点問題があった、Scalaの「case class」が使えなかったこととHashcodeが使えないオブジェクトは格納できないことが少し残念である。

また、当初はGoogle App Engineに載せたいと思ったが、永続化の仕組みをラップしているのでNeoDatisの部分をBigTableに置き換えることで対応しようと考えている。

○通信
通信はBlazeDSかWebOrbのどちらにしようかと考えたが、情報量が多いBlazeDSにした。
それにFlexとの親和性の高さでも同じ会社の方がいいだろうと考えた。
まずは通常のFlexとJavaでの接続を試し、次にScalaとFlex（ActionScript）でのシリアライズの関係を調べた。
基本的にはScalaのクラスはそのままJavaのクラスとして評価してくれるのだが、コレクションがJavaとScalaでは全然違うので、Javaのコレクションを使う必要があった。
これは割り切りでNeoDatisとの親和性の件もあるのでEntity内のコレクションはJavaのコレクションを使った。
Scalaで操作するときはScalaのコレクションでラップして使えばサーバー側のプログラムも楽なので、この選択が安全なのだと思う。

BlazeDSはたいしたものである。
これも一種の分散オブジェクトの技術であるが、その使いやすさは段違いである。
CORBAは死ぬほど大変　　DCOMはVBで使うとレジストリが汚れまくり
EJBは大げさすぎで　　RMIも簡単とはいえ面倒くさい

BlazeDSはほんとに簡単である。
またFlexとの親和性も高いのでMXMLから直にサーバー上のScalaのクラスが呼べる。
設定はDestnation名と対応するクラス名を設定ファイルに記述するだけである。
コネクションの確立みたいなこともないので突然のコネクション断で変なことになってしまうことも無い。
それにクライアントを立ち上げたまま、サーバー側のプログラムを修正し再起動できるし、逆もまた可能である。
Scalaの強力なプログラム機能でクライアントの情報を作成し、クライアント側では極力プログラムを書かないようにしている。
しかし、プログラム量はどうしてもクライアント側がふくらんでしまう。
いずれにしてもFlex+BlazeDSはScalaのFront endにはもってこいである。

○Webコンテナ
これは組み込みが容易なJettyにした。昔から組み込み用途にはJettyと決めていたので簡単に決まったが、問題はBlazeDSを組み込みJettyの上で動かすことが出来るかがポイントだった。
そもそもWebプログラミングを忘れていたので、WarやWEB-INFなどの構成から勉強し直しとなった。
また、クライアントの開発もFlexBuilderを使えば簡単なのだろうが、オープンソースのFlashDevelopを使って開発している。
Flex4（FlashBuilder4）が出たら買おうと思っているので今はオープンソースで我慢。
そのことからJettyの組み込み環境とBlazeDSの環境設定では時間を取られてしまった。
組み込みサーバーの利点は普通にソースコードデバッガーが使えることである。
そして、クライアントを立ち上げたままサーバーだけ再起動できるので楽である。

つながってしまうと非常にスムーズにクライアントからサーバーのDBまでつながる。
ドメイン構造がそのままクライアントからサーバーまで貫けるのは快適である。
スタンドアロンではドメイン構造をそのままプログラムに持ち込むことを行っていたが、サーバーサイドではそれが難しかった。
しかし、サーバーサイドでDDDが簡単に実現出来るのはほんとに快適である。

これで要件定義本来の機能に集中できる。