Tweet

AIR＋SQLiteで実現するGTDアプリ

リアルタイムDB同期のアーキテクチャ

　ColaboloのリアルタイムDB同期は、以下の2種類のサーバによって実現されています。

• DB同期サーバ
• メッセージングサーバ

バックグラウンドでDB同期処理を行う

　DB同期サーバは、各メンバーのColaboloクライアントに内蔵されたSQLiteの内容を相互に同期する役割を担います。Colaboloクライアント上のユーザー操作によって何らかのデータが更新されると、DB同期サーバに対して更新データが送信される仕組みです。

　この同期処理はColaboloクライアントのバックグラウンドで実行されるため、サーバのレスポンス時間がUIのレスポンスに影響を与えることはありません。このリアルタイムDB同期のメリットはほかにもあります。

　例えば、DB同期サーバが「デスクトップアプリケーションのバックアップサーバ」としても機能する点。すべてのデータがサーバ側にも保存されているため、もしクライアントPCがクラッシュした場合でも、Colaboloを再インストールするだけですべてのデータをクライアントへダウンロード可能となっており、単純なWordやExcelのファイルをベースに業務を行うよりもずっと可用性が高いことが分かるでしょう。

　また、AIR 1.5以降ではSQLiteのデータベースファイルは暗号化されており、かつデータ同期やメッセージングの内容も暗号化します。こうした特徴は、Webアプリケーション譲りのメリットといえるでしょう。

いまのAIR＋SQLiteがまだ出していない答えと「その先」

　ColaboloのリアルタイムDB同期実装には、AIR＋SQLiteが「ここまで使える」という実例を示す目的もありました。ローカルDBやオフライン機能の積極的な利用は、Google Gearsを筆頭にAjax分野でも注目されているトレンドだからです。

　今後は、現在のローカルDBが抱える課題と「その先」に技術的関心の焦点が移っていくだろうと筆者は考えています。

クライアントアプリ組み込み型DB開発の負担を隠ぺいするには？

　その際に課題となるだろう問題の1つが、ローカルDBに対するDBプログラミングの負担です。

　Webアプリケーション開発では、JavaのHibernateやRuby on RailsのActiveRecordに代表されるO／Rマッパーが市民権を得て久しく、低レベルなDBプログラミングに費やす時間は大幅に短縮されています。

　その一方で、いまAIRクライアント上でColaboloのようにSQLiteをフルに使いこなすアプリケーションを書こうとすれば、再び低レベルでリソースをいじりまわすようなDBプログラミングに拘泥されてしまいます。

　例えばSQL実行をはじめ、オブジェクトとレコードの相互変換、キャッシュ管理、トランザクション管理、遅延ロードといった（Webアプリケーションではおなじみの）課題を、すべて自前のDAOクラスなどであらためて実装する必要があります。

　こういった問題への回避策として、ActionScriptやJavaScriptによる本格的なO／Rマッパーの実装の登場に期待したいところです。

リアルタイムでのデータの相互同期をどう実現するか？

　もう1つの問題は、AIRやAjaxなどのRIAに固有の問題である「UI―データモデル―DBの相互同期」方法です。

　Webアプリケーションの場合は、HTTPリクエストが届くたびに「DB→データモデル（オブジェクト）→UI」という単方向でUIを作り直すので、相互同期を考える必要はあまりありません。

　これに対しRIAでは、一度構築したUIやデータモデルを作り直すことはなく、UI内容やDB内容の変化に応じてリアルタイムに相互同期を取る必要があります。

　その実現には従来のWebアプリケーションのフレームワーク（例えばStruts）とはまったく異なるMVCアーキテクチャが求められることはいうまでもありません。

2/3

Index
AIR＋SQLiteで実現するGTDアプリ
	Page1 Colaboloって？ 「リアルタイムDB同期」がカギ SQLiteプログラミングは意外と簡単！ SQLiteのパワーをいかに引き出すか
	Page2 リアルタイムDB同期のアーキテクチャ バックグラウンドでDB同期処理を行う いまのAIR＋SQLiteがまだ出していない答え クライアントアプリ組み込み型DB開発の負担を隠ぺいするには？ リアルタイムでのデータの相互同期をどう実現するか？
	Page3 RIA向けのフレームワークは群雄割拠

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード