JDO APIとLow-Level APIの違いと基本CRUD処理
1. Google App Engine Low-level API
この連載では、「Google App Engine for Java」(GAE、GAEj)が用意しているデータ格納領域(データ・ストア)の使い方を解説します。
GAEjでは、データ・ストアにアクセスするための標準APIとして、JDO(Java Data Objects)を用意しています。標準APIには、このほかにJPA(Java Persistence API)もあります。ほとんどの場合は、JDOが使われます。
この一方で、標準APIとは別に、Low-level APIと呼ばれるAPIが用意されています。この連載では、このLow-level APIについて解説します。
JDOのような標準APIがある中で、なぜLow-level APIを用意しているのか。まずは、この理由と、Low-level APIのメリットを説明します。
Low-level APIのメリット
(1)GAEで使われる分散KVSとRDBの違いが理解できる
GAEで使われる分散キー・バリュー・ストア(KVS)のデータ構造は、従来のRDB(リレーショナル・データベース)とは全く異なります。しかし、JDOは、RDBなど従来型のデータベースに対するAPIとして設計されているため、KVSに対してもRDBと類似の方式でアクセスします。
JDOがKVSとRDBを明確に区別しないことから、プログラマはKVSとRDBの違いをよく理解できません。「GAEのデータ・ストアは、RDBとあまり違いがない」という誤解も生まれます。
一方、Low-level APIは、JDOとは異なり、KVSとRDBを明確に区別します。これにより、KVSとRDBの違いが、プログラマにも理解できます。
(2)データ・アクセス用プログラムを簡単に作成できる
Low-level APIは、GAEのデータ・ストア専用のAPIです。このため、GAEのデータ・ストア構造に沿ったデータ・アクセスでは、JDOよりもプログラミングが簡単です。かつ、分かりやすいプログラム・コードにすることができます。
Low-level APIという言葉から「コーディングが難しいのではないか」という先入観を持つ人がいるかも知れませんが、実際にはLow-level APIの方が簡単です。また、JDOにはできないアクセスのやり方も、Low-level APIでは可能です。
(3)アクセス性能が高い
Low-level APIは、JDOのような標準APIよりもアクセス性能が高くなると言われています。無駄なAPIプログラム処理が存在しないため、当然かも知れません。ただ、ネット情報の中には、性能の違いを過大に評価していると思われるものもあるので、注意が必要です。この連載の最後では、JDOとLow-level APIのパフォーマンス比較を行う予定です。
2. プログラミング環境
ここからは、GAEでのデータ・ストア機能を、サンプル・プログラムを参考に解説します。まずは、サンプルを作成する環境を説明します。
(1)Eclipseを使ったプログラム作成
サンプル・プログラムの開発にはJavaを使います。GAEjでは、Eclipse用のプラグインが用意されているので、これを使います。プロジェクトの生成からローカル環境での動作確認、クラウド環境へのデプロイまで、効率的に進めることができます。
(2)DWR(フレームワーク)を使った開発と動作確認
サンプル・プログラムの作成には、開発用フレームワークとして、DWR(Direct Web Remoting)を使います。これは、サンプルにとって大きな特徴となっています。
- (a)プログラム動作の検証がサーバー側だけでできる(DWRデバッグ)
- DWRでは、DWRデバッグ画面を使うことによって、クライアント側のHTMLやJavaScriptなどを用意することなく、サーバー側だけで動作確認と結果の表示を行えます。データ・ストアへのアクセス動作を検証する際に、余分なプログラムを作成する必要がありません。効率的に開発を進められます。
- (b)ビーンズでプログラムを記述できる(専用サーブレット)
- DWRでは、専用のサーブレット(Java Servlet)を使います。このため、サーブレットを記述する必要がありません。ユーザーは、ビーンズ(Java Beans)にメソッド単位で処理ロジックを記述します。1つのプロジェクトに複数のアプリケーションを記述するのが容易であるため、GAEのようにアプリケーション数に制限(10個まで)がある環境には大変有効です。
なお、DWRの設定や使い方など、DWRの詳しい内容については、筆者が書いた、
- 『Ajaxによる業務アプリケーション開発』(秀和システム)
などを参照してください。
3. KVSの特徴: スキーマレス・データ・ストア
以下では、実際にプログラムを使って検証していきます。まずは、GAEのKVSがスキーマレスなデータ・ストアであることを、JDOとLow-Level APIのプロジェクト構成を比較することによって確認します。その後で、実際にデータ・ストアへの書き込みを行います。
3.1. 画面イメージ
(1)Web UIでの画面操作
この連載で扱うサンプル・プログラムは、すべてDWRを使っています。このため、サーバー側だけで、KVS(BigTable)の機能確認が可能です。ただし、ここではUIイメージを確認するため、画面サンプルを載せます。
図1: BBS登録画面1 |
図2: 「書き込む」ボタンをクリックした後のBBS画面 |
図3: 「書き込む」ボタンをクリックした後のBBS画面 |
このサンプルは、データ・ストアにアクセスする簡単な例です。図2のBBS(電子掲示板)画面で「書き込む」ボタンをクリックすると、書き込まれた内容が図3のように表示されます。書き込まれた内容は、クラウド上にあるデータ・ストアで永続化された後、検索・表示されるようになっています。