Java Cloud Meeting Tokyo 2010に行ってきたメモ

Java Cloud Meeting Tokyo 2010
自分が参加させていただいたもの

Seasar3はSpring+HotReloading（の予定）

ひがさんによる、今のJava Cloudをとりまく情勢を踏まえた、現段階でのSeasar3の構想について。

  • ベンダーロックインはなるべく避けるべきだけど、クラウド上でのポータビリティは、現実的ではない。
    • GAEを例にとっても、表面上はJDO/JPAであっても、内部的には全く違う。誤った理解やパフォーマンスを犠牲にするリスク。
  • 2011年からエンタープライズクラウドが本格的になる。
  • エンタープライズクラウド上のFWは、Springが主流になるであろう。（政治的な理由で）
  • それをふまえ、Seasar3はどうあるべきか。
    • 1) S2のまま現状維持。
    • 2) S2.5として生産性の改良。
    • 3) S3として互換性を失うことと引き換えに、画期的な機能を盛り込む。
  • ひがさんの答えは、1〜３のどれでもない。
    • 4)Springをベースに、HotReloadingやS2Struts、S2JDBCを搭載する。
  • 理由は、SI受託開発において、上司や顧客を説得することが不可欠なため。公式にSpringが提供されているのに、あえて異なるFWを選択することを説得することは困難である。
  • FWは、同じものをずっと使い続けると、生産性があがる。（使い始めはむしろ下がる。）
  • 今のSpringはかなり改良されて、あとはHotReloadingがつけば、ほぼS２。
  • S3では新しいHotReloadingを作る予定。Class Cast Exceptionが発生しない、トラブルレスなもの

GWTならJavaオンリーでAjax開発できる

2010/06/14追記 発表者のid:kaisehさんが資料を公開されています。
Java Cloud Meeting Tokyo 2010: 『Google Web Toolkitのすすめ』発表資料 - kaisehのブログ
JavaだけでAjax開発を可能にするGoogle Web Toolkitについて。

  • ajax開発の問題点
  • GWTコンパイラのうれしいところ
    • 圧縮、難読化
    • クロスブラウザ対応（UserAgentみて適切なコードを返す）
    • バラバラで用意した画像を勝手に連結して、CSS Spriteしてくれる
    • 上記により、自作jsよりよっぽどハイパフォーマンスになる。
  • GWTはクラウドに向いてる
    • サーバで処理すると、CPUやトラフィックの課金が生じる。
    • jsにロジックを押し込めば、クライアントでの処理になり、課金が抑制できる！
  • 開発環境も完成度が高い
  • 通信方法
    • RemoteServiceの実装クラスと対になるなんたらAsyncとか。（※GWTコンパイルによって自動生成されたりするのかな？よくわからなかったので、サンプルプロジェクトで要確認）
  • jsを直接いじりたいならJSNI
    • JSNI(javascript native interface)
    • nativeキーワードとコメントで記述
  • 国際化のpropertiesファイル記述もコンパイル時にエラー検出可能
  • 開発者がjsファイルの分割をコード指定可能
  • ブラウザの履歴を管理可能
    • ブラウザの「戻る」ボタン対策が出来る
    • GWTではURLのフラグメント部（hoge.html#bar）で実現
    • 開発者は変更処理をアプリケーションに記述
  • 実行とテスト
    • 開発モードは、jsへのコンパイル不要。ブラウザの再読み込みだけで最新のJavaコードが反映される
  • Chromeのアドオンでボトルネック分析
    • Speed Tracerというアドオン
    • Firebugのすごい版みたいなもの
  • mavenプラグインもある
  • css bundleを使えば、柔軟に見た目を制御できる
  • デザイナとの協業は課題である。UI Binderはひとつの解決策だが、基本的に難しい。

SeasarをふんだんにつかったWebサービス「Cacoo」

あとで資料を公開いただけるそうです。

  • アーキテクチャ
  • シンプルなWebAppFW Cubby
    • 脱Struts。t2と同じ路線
    • 設定ファイルを全然使わない
    • RESTっぽいURIサポート（CacooのURLは結構気を使ってる）
    • コミッターがnulabにいる
    • 拡張のためのインターフェースが提供されている。これによりAOPを使わず拡張
      • @Auth
      • @Protocolで柔軟にURL変更に対応
    • JSONを返すAPIを簡単に作成できる
  • テンプレートエンジンMayaaで、デザイナーと協業
    • テンプレートきりかえ機能で、他国語対応
    • CubbyカスタムタグとMayaaの拡張
  • 物理的な距離による遅延対策
  • サーバキャッシュEhcache
  • ブラウザキャッシュ。タイムスタンプをアイコン画像とかjsファイルとかにつける。ブラウザのサーバ通信を抑止
  • Mayaa応用
    • InjectionResolverを拡張してpom.xmlのバージョン設定
    • Hudsonでバージョン上げ漏れを防止

GAEの勘所

@shin1ogawaさんによるGAEの解説。

  • 障害によるサービス停止や、定期メンテナンスがある。なのでクリティカルなアプリケーションへの適用は難しい。
  • TaskQueue、ScheduledTaskサービス
  • DatastoreServiceの特徴
    • BigTableは早いと思われがちだけど、遅い。書き込みで80msかかったりする。
    • Bigtableは行単位でしかACID特性がない。
  • Entity Group
    • リレーションではない。keyをプロパティに保持するのはリレーションであってEGではない
  • Key

Keyのid/nameはKind内でユニークな訳じゃなく、EG内でユニーク。

  • 学習
    • JPA/JDOはインポーダンスミスマッチ

。ネット上にはたくさんの屍が。。。

    • まずはLLAPI
    • Shardingカウンタ、ページングなどのパターンが公開されている。
  • スキーマ設計について
    • 安易にEGを構成すると性能が落ちる。

GAEの本質

  • クラウドのすごさはスケーラビリティのように言われるけど、果たしてそうなのか。
    • SI受託開発において、スケーラビリティな要件ってそんなにない。
  • 本質は、コストダウン。
  • 大規模なリソースを多くのユーザでシェアすることで、コストダウンをはかる。
    • GAEは、必要なときだけサーバを立ち上げる。なので、少ないリソースを多くの人で使える。
    • amazon AWSやAzureは、使おうと使うまいと課金される。
    • リソースの管理が柔軟であることが、ほかのクラウドと違うGAEの大きな特徴（あんまり言及されないけど）
  • 上記を実現するために、すぐ立ち上がる必要があるので、仮想マシンじゃだめ。プロセスを立ち上げる。
    • プロセスを立ち上げると、セキュリティの問題が生じる。
  • セキュリティ対策としての制限
    • Sandboxモデルにより、よそのプロセスに悪影響を与えない。ひとつのプロセスに、リソースを占有させない。
  • そのための制限
    • 30秒制限
    • ソケットだめ
    • スレッド駄目
    • リモートでバッグできない
  • 安いコンピュータを横並びにした構成
    • そのために、処理を各PCに分散させて、どれかが死んでも処理が続くようにする必要がある。これこそがスケールアウト。
  • つまり、スケールアウトはコストダウンのための手段だ。

感想

Java Cloudの現在の情勢がざっくりわかってとてもためになりました。スタッフの皆様お疲れ様でした。
Swingっぽく書けて、強力な機構をたくさん備えたGWTはすごく魅力的でした。いつもTwitterでお世話になっている方にも、何人かご挨拶できてよかったです。
ちなみにじゃんけん大会は惨敗でした。