「Bindows」というAjaxベースのリッチクライアント開発環境
が日本に上陸したというニュースが取り上げられています。
http://www.bindows.net(本家)
http://www.bindows.jp(日本)
注目すべきなのはリッチなUIを実現するための高水準なAPIが
揃っている点です。
http://www.bindows.jp/tech/api/index.html
例えばドラッグ&ドロップですが、単なる紙芝居的なD&Dではなく
SWTでDragSourceやDropTargetに対してsetTransfer()メソッド
で処理対象となるデータタイプを指定するのと同じようなことを
setDropDataTypes()メソッドで行なうことができます。見た目
だけでなく、きちんとデータまで意識したD&Dといえますね。
日本語サイトのコンテンツも充実していますので、有償ライセンス
ではありますが、業務向けアプリケーションを中心に今後国内でも
普及する可能性を秘めているように感じます。
リッチクライアント技術の中でもAjaxについてはHowsやZimbra
など技術的な先進性を誇る新興ベンチャーの活躍が目立ちますが
Bindowsについてもリッチクライアント技術競争の新手として、
今後も要注目ということになりそうです。
個人的にはこうして様々な技術やそれを提供するベンダーが登場
して、互いに切磋琢磨しながらリッチクライアント技術全体が洗練
されていくことが望ましいと考えています。
リッチクライアントについて最近良く考えるのは「クライアント
でのデータ保持」についてです。DWRのようにサーバー側のAPIを
透過的に呼び出す仕組みを作り、クライアント側に下手にデータ
を置かないというスタンスもありますし、逆にIBM WorkPlaceの
ようにプチJ2EE的な仕組みを持ち込んで、データベースレベルで
レプリケーションを取るというスタンスもあります。
どちらが良いとは一概には言えませんが、FlashやAjaxのように
ブラウザをベースとしたリッチクライアントでは前者、Eclipse
RCPやスマートクライアントのようにクライアントアプリをWeb
越しに(Java Web StartやClick Onceなどを使って)導入・更新
できるスタイルのリッチクライアントでは後者という使い分けが
されているように思います。後者の場合はオフラインでの利用を
求められるケースが多いですから、上記のようなアーキテクチャ
になるのはある意味必然と言えるでしょう。
気をつけないといけないのはこの両者のパターンの中間を選択
する場合です。大きなデータグリッドなどはページングするか
あるいはローカルにJavaScriptデータベースを作ってしまうか
して非同期にデータを取得し、それをローカルに保持することで
レスポンスを向上させるといったことを行なうことがありますが
こうした仕組みをコンポーネント毎にバラバラにやってしまうと
サーバー側との同期処理に支障をきたす恐れがあります。
どのリッチクライアント技術もローカルにデータをストアする
ための仕組みを持っており、いずれも結構使い易いので個々の
開発者が個別に自分のやり方でクライアントキャッシュを実装
してしまうといったこともなきにしもあらずです。
そうしたことがないようにローカルデータキャッシュの仕組みは
全体のアーキテクチャ策定の段階である程度の詳細までしっかり
詰めておかないといけないだろうなと思っています。
