先週の金曜日はGoogleデベロッパー交流会に行ってきました。今回のテーマはGoogle Gearsだったんですが、実は事前まで知っていたのは名前と概要ぐらいで実際に触ったことはありませんでした。パネルディスカッションできちんとしたことが言えるようにチュートリアルなどいくつかドキュメントはなんとか読むことができたので、あまり的外れなことはいわなかっただろうと思っています (^^ゞ
さて、チュートリアル等いくつかドキュメントを読むことはできたものの、実際にサンプルを動かしたり自分でプログラムを作るところのレベルまでは準備ができなかったので、どちらかというとGearsを使った場合にシステム全体のアーキテクチャがどうなるだろうかということを中心に考えていました。まず一つ目は既存のWebアプリケーションとどのようにアーキテクチャ上、融合していくかです。現状のWebアプリケーションは、分け方は様々であるにしても、HTMLを生成する層、ビジネスロジックを処理する層、データを管理しておく層など幾つかの層に分けて設計することが一般的です。ここではCore J2EE Patternsで紹介されているように次のような層を想定しておきましょう。

• クライアント層 ... ブラウザなどユーザとのインタフェース
• プレゼンテーション層 ... JSPやPHP等を使って画面を生成する
• ビジネス層 ... ビジネスロジックやトランザクションの処理等
• インテグレーション層 ... リソース層との橋渡しをする層。JDBCやJMS等で通信手続きなどを抽象化する
• リソース層 ... データの管理を行うデータベースやERPなどのシステム

ここでGearsを使ったアプリケーションのことを思い浮かべてみることにしましょう。GearsはFirefoxやIE、Safariといったブラウザに導入するプラグインで、上記で言うクライアント層をターゲットとしているのは間違いありません。ただ、Gearsはそのアーキテクチャの説明にもあるように、クライアント層の中でもアプリケーションUIとデータを分離するために層をもうけるべきだとしています。

これらの層をふまえてアプリケーションを設計する場合、多くの点では今までと同じように設計をして、Gearsを活用したリッチなユーザエクスペリエンスを提供するようにJavaScriptを駆使することになると思います。まとめるとだいたい次のようなアーキテクチャになるでしょうか。

おそらくGearsを使った場合、結果的にはだいたいこのようなアーキテクチャになると思いますが、今回は「考えてみる」とまで題しているのでもう少し話を進めてみたいと思います。Gearsにしても、それ以外の技術が出てくるにしても、Webアプリケーションのユーザエクスペリエンスの改善という点から考察すると、クライアント側のデータベースや非同期処理、キャッシュといった技術は欠かせない要素です。では、最もアグレッシブにGearsの機能を使った場合を考えてみます。Gearsには指定したURLのデータをキャッシュする機能、ローカルに持つことができるデータベース、また主にオフライン／オンラインきり代わり時などにデータをサーバに同期させることを目的としたワーカプールというスレッド管理の機能があります。このワーカプールを使えば、ある意味で何でも処理ができてしまう訳で、場合によってはビジネスロジックまで記述することができるかもしれません。それ以外にもローカルのデータベースに何でもかんでもデータを記録してしまうということもできるでしょう。
ただ、一方ではローカルだけでは処理できないビジネス処理はいくつかあると思います。例えば、ショッピングサイトの買い物確定はローカルだけでは処理できないでしょう。ローカル側で確定した、ということを記録しておいてオンライン化した際に買い物の確定データを同期するという手段で、見せかけ上ローカル側で処理したようにすることもできるかもしれませんが、オフライン化している間に在庫や価格など条件が変わってしまうことがあることを考えればそこまで踏み込んだロジックをGears等を使って実装することはやや非現実的です。また一方、データベースに関しても、お店側の在庫データや価格データをすべてクライアント側に持っておくことはナンセンスです。 それらを考えれば、クライアント側で処理すべき部分と、サーバ側で処理すべき部分は依然としてある程度明確に分類することができそうです。

上図はそれらの分類を基にもう少し考えを進めてみたアーキテクチャです。今までのアーキテクチャと違い、プレゼンテーション層(この場合、名前は もう少しかえた方がいいかもしれません)はサーバとクライアントをまたいで存在するようになり、プレゼンテーション層内部でも役割別にある程度機能をグループ化することができるようになると思います。ここであえてクライアント／サーバをまたいで層を描いてみた理由は、クライアント側で実行されるJavaScriptのロジックも結局はサーバ側で生成しているためです。また、さらにあえてその辺りを意識しなくてもアプリケーションが設計できるようにjMakiのようなラッパーライブラリはこれからもどんどん成長していくと思います。
さて、処理の役割に注目していきます。たとえばクライアント側で処理すべき役割はユーザインタフェースそのものの実現や、表示用のデータの管理です。一方、サーバ側では画面遷移や画面自体の生成が主な役割になります。画面遷移や画面生成をクライアント側に持っていくこともできなくはないですが、システムによっては画面要素に対してそれぞれ権限のチェックなどが必要だったりすることとから考えてサーバ側に置かれているべきでしょう。
データベースはGearsを使えばローカル側にも設置される訳ですが、保存されるデータは表示用のキャッシュデータや、ユーザ自信が作成しする未確定のデータに限られると思います。ユーザ自身が作成する未確定のデータとはSNS上での自分自身のプロフィールや書きかけの日記などです(当然ながらそれらのデータを常にサーバ側に同期することは必要に応じて実施する)。一方、確定済みのトランザクションやデータはすべてサーバ側で管理されているべきでしょう。
さて、以上のように少し自分の中ではGearsの位置づけがようやくすっきりしました。こういった話もこの間のデベロッパー交流会でしようかと思っていましたが、どちらかというと交流会ではどう使っていくか、がメインだったので今回はあきらめました。また、どこかでディスカッションする機会があればいいなと思います。