JDO APIとLow-Level APIの違いと基本CRUD処理
（2）DWRを使ったUI操作と表示
DWRを使うと、HTMLやJavaScriptを使ったWeb UIを作成することなく、プログラム機能を確認できます。
例えば、前ページの図1に示した画面表示では、クラウド上のURLである
をアクセスしています。これに「dwr/」を追加して、
というURLにアクセスすれば、下記のようなDWRのクラス選択画面が表示されます。
|
|
| 図4: DWRクラス選択画面 |
図4は、DWRクラスの選択画面です。図4の例では、登録されているビーンズ・クラスが1個だけですが、登録されているクラスの数だけ列記されます。
この画面で「msgBean」のリンクをクリックすると、図5の画面表示に変わります。この画面上から、コメント登録や参照用のメソッドを実行して、動作の確認ができます。
|
|
| 図5: DWRデバッグ画面（クリックで拡大） |
【コメント情報登録】
図5に示したDWRデバッグ画面には、addMsgとrevMsgという2種類のメソッドが登録されています。このうちaddMsgは、図2のBBS画面から送られてきた書き込み情報をデータ・ストアに永続化するときに使う、Java Beansのメソッドです。図6のようにDWRデバッグ画面から直接登録できます。
|
|
| 図6: DWRデバッグ画面からの直接書き込み（「Execute」クリックで書き込み実行）（クリックで拡大） |
【コメント情報参照】
もう1つのrevMsgは、BBS情報を表示するときに使うメソッドです。BigTableに書き込まれている内容を参照しています（図7）。
|
|
| 図7: DWRデバッグ画面で登録済みデータ参照 |
このように、DWRを使うことによって、Webクライアントの画面を作成することなく、Javaで作成したデータ・ストアの操作プログラムを実行・確認できます。また、必要な場合は、参照内容が実際に登録されたデータと一致しているかどうかの確認も可能です。図8に示したGAEの管理者画面から「Datastore Viewer」を介して確認できます。
|
|
| 図8: Datastore Viewerによる、登録（永続化）データの確認（クリックで拡大） |
このように、DWRとGAEの管理者画面を組み合わせることで、サーバー側だけで、プログラムの動作とデータの確認が可能です。データ操作の確認に関しては、ここまで説明した内容だけで、ほとんどの場合は問題ないでしょう。
【ローカル環境での動作・データ確認】
これまで説明してきた動作確認の対象は、アプリケーションをデプロイ（配備）した後のクラウド環境ですが、開発環境であるEclipseの上でも同様の確認が可能です。Eclipse環境でプログラムを実行した後、ブラウザからURLで、
を入力すれば、図5と類似の画面が表示されます。あとは、クラウド環境と同様の手順で、プログラム（メソッド）の動作を確認できます。
3.2. プロジェクト構成の比較
次に、サンプル・プログラムを題材に、JDOとLow-Level APIのプロジェクト構成を比較します。サンプル・プログラムは、JDOによるAPIとLow-Level APIの2種類のAPIを使って、データ・ストアにアクセスします。Eclipse上でのプロジェクト構成は、それぞれ次の通りです。
（1）JDOを使った場合のプロジェクト構成
|
|
| 図9: JDOでのプロジェクト構成（クリックで拡大） |
（2）Low-Level APIを使った場合のプロジェクト構成
|
|
| 図10: Low-Level APIでのプロジェクト構成（クリックで拡大） |
図9は、JDOを使用した場合のプロジェクト構成です。図10は、Low-Level APIを使用した場合のプロジェクト構成です。
JDO（図9）では、src/jdoajaxの下に、3種類のファイル（msg.java、msgBean.java、PMF.java）があります。これに対して、Low-Level API（図10）では、1種類のファイル（msgBean.java）だけです。つまり、JDOには、Low-Levelにはないファイルが2種類追加されていることになります。
JDOだけが備えているファイルのうち、PMF.javaは、データの永続化用クラスです。もう1つのmsg.javaは、アクセスするデータ・ストアのデータ項目定義、コンストラクタ、アクセサ・メソッドから構成されています。msg.javaの内容は、リスト1の通りです。
3.3. データ・クラスの定義
リスト1: データ・クラス定義（msg.java）
package jdoajax;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class msg {
// 永続化対象プロパティ定義部分（ここから）
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long uid;
@Persistent
private String uname;
@Persistent
private String uemail;
@Persistent
private String umsg;
@Persistent
private String udate;
// 永続化対象プロパティ定義部分（ここまで）
public msg(String uname, String uemail, String umsg, String udate) {
this.uname = uname;
this.uemail = uemail;
this.umsg = umsg;
this.udate = udate;
}
public Long getId() { return uid;}
public String getUname() { return uname;}
public String getUemail() { return uemail;}
public String getUmsg() { return umsg;}
public String getUdate() { return udate;}
public void setUname(String uname) { this.uname = uname;}
public void setUemail(String uemail) { this.uemail = uemail;}
public void setUmsg(String umsg) { this.umsg = umsg;}
public void setUdate(String udate) { this.udate = udate;}
}
リスト1の中の、永続化対象プロパティ定義部分は、RDBにおけるスキーマ定義に類似しています。このような定義があることにより、初めてBigTableなどのKVSを扱うプログラマは「KVSもRDBとあまり違わない」という誤解を持ってしまう場合があるようです。
KVSの場合も、あらかじめデータを格納するkind（≒テーブル）のデータ定義を行ってから、READ/WRITEなどでデータにアクセスします。こうした手順を踏むことが理由となり、「RDBと似ている」という印象を受けることになります。
しかし、このサンプルにLow-Level APIを適用することによって「KVSはRDBとは全く異なっている」ことを実感できます。図10に示したLow-Level APIのプロジェクト構成には、リスト1のようなデータ・クラス定義ファイルはありません。分散KVSのBigTableは、スキーマレスなデータ・ストアであり、永続化用のデータ（プロパティ）項目をあらかじめ定義しておく必要がないのです。
