木曜日 12 13, 2007

Google Gearsについて考えてみる

DSC_8407.JPG
先週の金曜日はGoogleデベロッパー交流会に行ってきました。今回のテーマはGoogle Gearsだったんですが、実は事前まで知っていたのは名前と概要ぐらいで実際に触ったことはありませんでした。パネルディスカッションできちんとしたことが言えるようにチュートリアルなどいくつかドキュメントはなんとか読むことができたので、あまり的外れなことはいわなかっただろうと思っています (\^\^ゞ
さて、チュートリアル等いくつかドキュメントを読むことはできたものの、実際にサンプルを動かしたり自分でプログラムを作るところのレベルまでは準備ができなかったので、どちらかというとGearsを使った場合にシステム全体のアーキテクチャがどうなるだろうかということを中心に考えていました。まず一つ目は既存のWebアプリケーションとどのようにアーキテクチャ上、融合していくかです。現状のWebアプリケーションは、分け方は様々であるにしても、HTMLを生成する層、ビジネスロジックを処理する層、データを管理しておく層など幾つかの層に分けて設計することが一般的です。ここではCore J2EE Patternsで紹介されているように次のような層を想定しておきましょう。
  • クライアント層 ... ブラウザなどユーザとのインタフェース
  • プレゼンテーション層 ... JSPやPHP等を使って画面を生成する
  • ビジネス層 ... ビジネスロジックやトランザクションの処理等
  • インテグレーション層 ... リソース層との橋渡しをする層。JDBCやJMS等で通信手続きなどを抽象化する
  • リソース層 ... データの管理を行うデータベースやERPなどのシステム
ここでGearsを使ったアプリケーションのことを思い浮かべてみることにしましょう。GearsはFirefoxやIE、Safariといったブラウザに導入するプラグインで、上記で言うクライアント層をターゲットとしているのは間違いありません。ただ、Gearsはそのアーキテクチャの説明にもあるように、クライアント層の中でもアプリケーションUIとデータを分離するために層をもうけるべきだとしています。
Gears and Multi tier architecture
これらの層をふまえてアプリケーションを設計する場合、多くの点では今までと同じように設計をして、Gearsを活用したリッチなユーザエクスペリエンスを提供するようにJavaScriptを駆使することになると思います。まとめるとだいたい次のようなアーキテクチャになるでしょうか。
Gears and Multi tier architecture
おそらくGearsを使った場合、結果的にはだいたいこのようなアーキテクチャになると思いますが、今回は「考えてみる」とまで題しているのでもう少し話を進めてみたいと思います。Gearsにしても、それ以外の技術が出てくるにしても、Webアプリケーションのユーザエクスペリエンスの改善という点から考察すると、クライアント側のデータベースや非同期処理、キャッシュといった技術は欠かせない要素です。では、最もアグレッシブにGearsの機能を使った場合を考えてみます。Gearsには指定したURLのデータをキャッシュする機能、ローカルに持つことができるデータベース、また主にオフライン/オンラインきり代わり時などにデータをサーバに同期させることを目的としたワーカプールというスレッド管理の機能があります。このワーカプールを使えば、ある意味で何でも処理ができてしまう訳で、場合によってはビジネスロジックまで記述することができるかもしれません。それ以外にもローカルのデータベースに何でもかんでもデータを記録してしまうということもできるでしょう。
ただ、一方ではローカルだけでは処理できないビジネス処理はいくつかあると思います。例えば、ショッピングサイトの買い物確定はローカルだけでは処理できないでしょう。ローカル側で確定した、ということを記録しておいてオンライン化した際に買い物の確定データを同期するという手段で、見せかけ上ローカル側で処理したようにすることもできるかもしれませんが、オフライン化している間に在庫や価格など条件が変わってしまうことがあることを考えればそこまで踏み込んだロジックをGears等を使って実装することはやや非現実的です。また一方、データベースに関しても、お店側の在庫データや価格データをすべてクライアント側に持っておくことはナンセンスです。 それらを考えれば、クライアント側で処理すべき部分と、サーバ側で処理すべき部分は依然としてある程度明確に分類することができそうです。
Gears and Multi tier architecture
上図はそれらの分類を基にもう少し考えを進めてみたアーキテクチャです。今までのアーキテクチャと違い、プレゼンテーション層(この場合、名前は もう少しかえた方がいいかもしれません)はサーバとクライアントをまたいで存在するようになり、プレゼンテーション層内部でも役割別にある程度機能をグループ化することができるようになると思います。ここであえてクライアント/サーバをまたいで層を描いてみた理由は、クライアント側で実行されるJavaScriptのロジックも結局はサーバ側で生成しているためです。また、さらにあえてその辺りを意識しなくてもアプリケーションが設計できるようにjMakiのようなラッパーライブラリはこれからもどんどん成長していくと思います。
さて、処理の役割に注目していきます。たとえばクライアント側で処理すべき役割はユーザインタフェースそのものの実現や、表示用のデータの管理です。一方、サーバ側では画面遷移や画面自体の生成が主な役割になります。画面遷移や画面生成をクライアント側に持っていくこともできなくはないですが、システムによっては画面要素に対してそれぞれ権限のチェックなどが必要だったりすることとから考えてサーバ側に置かれているべきでしょう。
データベースはGearsを使えばローカル側にも設置される訳ですが、保存されるデータは表示用のキャッシュデータや、ユーザ自信が作成しする未確定のデータに限られると思います。ユーザ自身が作成する未確定のデータとはSNS上での自分自身のプロフィールや書きかけの日記などです(当然ながらそれらのデータを常にサーバ側に同期することは必要に応じて実施する)。一方、確定済みのトランザクションやデータはすべてサーバ側で管理されているべきでしょう。
さて、以上のように少し自分の中ではGearsの位置づけがようやくすっきりしました。こういった話もこの間のデベロッパー交流会でしようかと思っていましたが、どちらかというと交流会ではどう使っていくか、がメインだったので今回はあきらめました。また、どこかでディスカッションする機会があればいいなと思います。

金曜日 11 16, 2007

昨日のHot Topic Seminar: jMaki開発者Gregによるセミナー「jMaki and Ajax」

昨日は急なアナウンスにも関わらず会場もほぼ満員御礼となりましたホットトピックセミナーの特別編として、jMakiの開発者Greg Murrayさんによるセミナーを行いました。今回はセミナーの様子をWeb中継しようと思っていたのですが、ちょっと準備が足らずリアルタイム配信できず、録画をお送りしようと思います。ただ、今回Ustream.tvで配信しようとしたものの、音がとぎれとぎれになってしまい、まだうまく行っていません・・・。
ひとまず録画したQuick Time形式のものはダウンロードできる状態に準備ができましたのでご興味のある方はぜひダウンロードして、Quick Time Playerを使ってご覧ください。 またうまくストリーミングができるようになればそちらも追ってご案内させていただこうと思います。
さて、実は昨日のセミナーではGregによるjMakiの紹介の他にも、jMakiの日本語ドキュメントプロジェクトをはじめます!というアナウンスをさせていただきました。実のところ本当にまだやろう!と思ったぐらいで、運営方法等は早急に準備しているところですが、もし翻訳やあるいはレビューだけでもご参加いただける方はぜひとも岡崎(takayukiどっとokazakiあっとsunどっとcom)までメールをいただければ幸いです。ちなみに、昨日のセミナーでは4名の方に参加の申し込みをいただきました!すばらしい。
ちなみにこの日本語ドキュメントプロジェクトですが、なんとなくロゴと名前を考えてみたのですがいかがでしょうか?
jMusu
jMakiが巻きなので、こっちは結びかな。とか。モデルは天むすです (\^\^;;
他にもjNigiriとか、jTebento、jMusubiなどの候補があります。もしデザインセンスのある方がいらっしゃいましたらロゴデザインなどでもご参加いただけると思います。ぜひともよろしくお願いいたします。いま有力なのはjMusuですが、英語的な発音できくとJames GoslingのJamesにしかきこえません (\^\^;;
About

okazaki

Search

Archives
« 4月 2014
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今日