読者です 読者をやめる 読者になる 読者になる

uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかFregeとかJavaとか -

Slim3 for GAE/J ひがさん

Slim3 GAE

本エントリは、エントリ「JJUG CCCいってきました」の一つです。

(補足)のところが主に自分で考えたところ。でも他にも暗に補完してると思うのでそこんとこよろしくお願いいたします。

はじめに

  • Amazon EC2は仮想化サービスであり既存技術と連続
  • Google AppEngineは既存技術に対する制約が大きく連続性がない

制約とは

  • Threadが使えない
  • ContextClassLoaderが使えない
  • セキュリティが厳しい。seculity.policyの設定が厳しい。
    • → Spring 2.5からコンポーネントスキャンというのをやってアノテーションを読み取るのだがそれは動かない。
    • Struts2の式言語はOGNLを使うがセキュリティマネージャを設定していると駄目
      • → nullにすれば良い
  • ファイルに書き込みできない
    • Apache Commonsのファイルアップロードはテンポラリファイル書き込みがデフォルトなので動かない。Commons upload 1.2.1では、なんとかイテレータ使えばメモリ上でストリーミング取得できる。

常識もかわってくる

  • 従来、セッションはメモリを食うから多用するなというのが常識だったが、GAEのセッションはMemcacheサービスを介してBigTableに保存される。ので、どしどし使っていい(かも)。

GAE登場に伴うフレームワークの位置づけの変化

  • 高度なことをやればやるほどローカルと本サーバの違いに遭遇しやすい。
  • DIもなくていい
    • でもテストは?
      • → アプリのレイヤで試験の仕組みを作り込まなくてもGAEがある程度サポートするのでDIがなくても試験はやりやすい。たとえばGAEでは
        • ローカルでクエリできる。
        • スタブ(モック)の仕組みをGAEが既に持っている。
        • BigTableはローカルではある種のメモリ上DBで動作するのでデータの消去が簡単。
        • 実環境上ではGoogleアカウント、ローカル環境ではあるアカウントを表すクラスにスタブ(モック)される。
  • スキーママイグレーションはいらない。なぜならスキーマがないから。(補足)
  • ORマッピングやDBの差異に関する相当な問題が解決される。(補足)
  • FWないので見通しが良くなる
  • FWなしでも生産性低くならない。
  • ただ、上記は「現在の」GAE/Jが、プレビュー段階でありドキュメンテーションおよび機能が成熟していないことによる。現状では高機能なFWではまって問題追求するようなコストがかかるので、それをさけるための判断として、である(長期的にもこうであるとは限らない。)

Slim Struts

  • Slim3はSpring対応だったが、Slim3 for GAEはSpring使用しない。
  • AOPなし、DIなし。
  • (ローカル実行時の)ホットデプロイはコントローラのクラス(ActionClass)のみに限る。(ユーザ定義クラスのホットデプロイはContextClassLoaderの制限があるのでできない)
  • 設定ファイルレスでアノテーションベースでサクサク開発できる

JDOとJPA

  • JPAは、RDBMSを抽象化して差異を吸収する。対象はRDBMS
  • JDOは、永続化を抽象化する。いままでもRDBMSに限定されていなかった (実体としては主にRDBMSを対象としていたが)。今回、DataNucleousの人たちがBigTableに対応させた。
  • なのでBigTableにはJDOが向いている。現状のJPAはほんとに「似せただけレベル」にちかい。いずれにせよごく一部しか使ってない。

JDOについて

  • JDOはいままでマイナーなものであった。
  • JDOの仕様は結構大きい(JPAと同じぐらい)が、GAEで使う限り、知るべきことは限定的(APIを10個ぐらい覚えておけば用が足りる)。
  • JDOメソッドの基本(主に使うものはこんだけ)
    • makePersistant(INNSERT/UPDATE)
    • deletePersistant(DELETE)
    • query(クエリによる検索)
    • get(キーによる検索)
  • JDOアノテーション。こんだけですよこんだけ(主に使うのは)。
    • @PersistanceCapable
    • @PrimaryKey
    • @Persistant
    • @NotPersistant
  • 永続化対象
    • 数値はプリミティブも可だがnullになれるのでWrapperおすすめ。
    • char型だめ。String使う。Unicode2.0のサロゲートペアの関係か?(補足)
    • BigDecimal, BigIntegerだめ。
    • enum全然おっけー。ちと意外。
    • 日付に関しては、java.sql.*はだめ。JDBCがサポートされてない。
      • → H2の人たちがJDBC/BigTableを作ってる。
        • → でも、その上にORマッピングを動かすのはいかがなものか?

BigTable

  • 複雑なクエリは使えない(ORとIN、NOT EQUALが使えないよ)
  • なので自然とJavaで処理することになる。その結果見通しは良くなる。
    • CPUパワーはスケールする。複雑なクエリはスケールしない。(補足)
  • トランザクションは親子関係を持ったエンティティ間のみ

Slim3JDO

  • LocalJDOTestCase
    • GAE提供のテストクラスのサブクラス
    • DBの後始末処理をしてくれる。
  • JDOTemplate
    • 宣言的トランザクションではなく、インナークラス定義を持ったメソッドで実装する。
      • toLong()といったnullを考慮した変換メソッドなどもあるよ
    • 流れるようなインターフェース
      • JavaによるDSL
      • aptをうまく使ってコンパイル時にメタデータを生成(補完にも利用)。
      • タイプセーフ。IDEでメソッド名補完。

GAE/Jでの開発の仕方

  • ERモデリングはいらなくなる(スキーマないので)。
  • コードがJavaに集約される。
  • 快適。
  • シンプルなFWでよい。FWなくてもいいぐらい。
  • FWの意義が減る。GAEプラットフォームの機能で代替されるということか(補足)

その他TIPS

  • Eclipseプラグイン使うべき。
    • → 「ホワイトリスト」という機能がありGAEで使えないクラスを使うと警告してくれる。 (こんだけのためでも使う価値あり)
  • GAEアプリはディレクトリ構成が決まっている(src/,war/)。Mavenを使うとはまりがちなので正式サポートされるまで待った方がいいかも。でも、Googleの人はmavenが嫌いかも。antとかシンプルなのが好きかも。
 [感想] 興味の主眼であります。
今、GAEのドキュメント読みはじめたんですが、
水先案内的実用情報として役立つことこの上無し。
Slim3 for GAEについては便利なライブラリ的に
つかえそうに思った。
広告を非表示にする