僕の場合、Grailsを選択することになりました。
すでにGrailsで構築し、稼動し始めていたアプリケーションを、GAEにのせることにしたからです。
Grailsは優れたフレームワークです。
しかし、それでもGAEとまったく関係なく作ったシステムを、後からGAEに適合させるためには、それなりの変更が必要でした。
原因は
- GAEのAPI仕様
- RDBとGAEのデータストアの違い
- Grails、またはそのプラグインの仕様
- それらが合わさったもの
そこで、GAEアプリケーション開発の一例として、今回必要になった主な変更を、このカテゴリにまとめていきたいと思います。
さて、最初の大きな変更点は、ORマッパーの代わりに永続化APIを採用することです。
GAEのデータストアはRDBではないので、ORマッパーは使えません。
ということは、そのままではGORMが使えないということになります。
そこで、GAEのJava APIが対応している2つのJava標準永続化API ー JDOとJPAのうちどちらかを選択して、それに対応したGrailsプラグインをインストールする必要があります。
JPAとJDO、どちらを選択しても、たいした違いはないようです。
ただ、JPAは、永続化システムがなんらかのRDBであることを前提としていますが、App EngineデータストアはRDBではないので、いくつかサポートされていない機能があります。
実際、GAEのドキュメントを見ると、どちらかというとGoogleはJDOを薦めてるような気配があります。
まぁ、それが自然でしょう。
GAEによりマッチしてるっぽいJDOか、GORMが使えるJPAか...というあたりが選択のポイントかもしれません。
で、今回はJPAを選択しました。
JPAなら、gorm-jpaプラグインを使うことで、普通のGrailsっぽい部分を少しでも多く残せると思ったからです。(ほんとうに少しですが)
GAE上で動かすためだけに追加/変更するコードの量を、抑えたかったわけです。
どちらを選択したかによって、必要になる設定ファイルとかが違ってくるわけですが、そのへんはapp-engineプラグインとかが面倒みてくれるので、心配いりません。
さて、Grailsアプリケーションは既に作ってあり、GAEのSDKはインストールし、Grailsにはapp-engineプラグインと共に、gorm-jpaプラグインもインストールしました。
しかし、まだGAE上では動きません。
なぜなんでしょうか。
Grailsアプリケーションを、GAEにのせるためのTODOリストは、はるか彼方までつづきます。
0 件のコメント:
コメントを投稿