JDO APIとLow-Level APIの違いと基本CRUD処理

2010年10月21日(木)
清野 克行

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の詳しい内容については、筆者が書いた、

などを参照してください。

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のように表示されます。書き込まれた内容は、クラウド上にあるデータ・ストアで永続化された後、検索・表示されるようになっています。

有限会社サイバースペース
慶應義塾大学工学部電気科卒。日本IBM、日本HPなどにおいて、製造装置業を中心とした業務系/基幹業務系システムのSE/マーケティングや、3階層C/Sアーキテクチャによる社内業務システム開発などに携わる。現在は、Ajax/Web 2.0関連のセミナー講師/コンサルティング、書籍執筆などを行っている。情報処理学会会員。http://www.at21.net/

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています