Adobe Developer Connection（AD）

Google App Engine for Java ＋ BlazeDSでハマらない方法
～Flex/AIRハマり帳（前編）～

2009/11/25 14:00

ポスト

　Flex/AIR開発には、ところどころに「落とし穴」があります。過去3年間のFlex/AIR開発を通じて、筆者は「落とし穴」にことごとくハマり、「二度と繰り返すまい」と要点をメモしてきました。本連載では、筆者の「Flex/AIRハマり帳」から、Flex/AIR開発を始める方へ同じ過ちを繰り返さないためのtipsを2回に分けて紹介します。

ポスト

この記事は、2009年5月28日にAdobe Developer Connectionにて公開されたものです。

はじめに

　Flex/AIR開発には、ところどころに「落とし穴」があります。過去3年間のFlex/AIR開発を通じて、筆者はそうした「落とし穴」にことごとくハマり、そのたびに「二度と繰り返すまい」との思いで要点をメモしてきました。本連載では、その筆者の「Flex/AIRハマり帳」をもとに、これからFlex/AIR開発を始める方が同じ過ちを繰り返さないためのささやかなtipsを紹介していきたいと思います（なお、ここで紹介するtipsは、あくまで筆者の経験に基づいて得られたものであり、アドビシステムズの公式な提供情報ではないことにご留意ください）。

Google App Engine for Javaと「ご都合.com」

　第1回は、つい最近のメモからです。この連休中に筆者は、「Google App Engine for Java（GAE/J）とFlexでスケジュール共有ツールを作る」ことを思い立ちました。およそ5日間かけて開発を進めたのち、5月6日に「ご都合.com」を公開しました。その後、はてなブックマークやニュースサイト等でご紹介いただいたおかげで、公開後5日で約1500名の方にご利用いただいています。

「ご都合.com」

「ご都合.com」

　このサイトの大きな特徴は、「GAE/JとBlazeDSで動作しているRIA」という点です。では改めて、GAE/Jとは何かを簡単に紹介します。

　Googleが2008年4月に発表したGoogle App Engineは、「自分が開発したWebアプリをGoogleのデータセンターで運用できるクラウドコンピューティングサービス」です。当初は利用可能な言語がPythonのみに限定されていましたが、2009年4月よりJavaに対応するGAE/Jが公開されました。以下に、GAEのおもな特徴をまとめます。

無償で始められる
Googleのインフラを使える
サーバ構築作業が不要、デプロイが簡単

Google App Engine

図：Google App Engineのホームページ

「無償で始められる」

　GAE/Jは、一定のサーバリソースを無償で利用でき、初期コストは一切かかりません。もちろん無償で使えるサーバリソースには上限があり、以下の「無償提供分」に示す値に制限されています（なお、以下の各情報は5月10日現在のものです）。これらの値を超える分については、「有償提供分の単価」に基づく従量課金となります。

	無償提供分	有償提供分の単価
ストレージ容量	1GB	$0.005／1GB×1日
ネットワーク帯域（上り）	10GB／1日	$0.10／1GB
ネットワーク帯域（下り）	10GB／1日	$0.12／1GB
CPU時間	6.5時間／1日	$0.10／1時間
メール受信件数	2000件／1日	$0.0001／1件

　無償とはいっても、1GBのストレージがあれば、テキスト情報中心の中小規模のWebアプリには十分な容量です。ネットワーク帯域やCPU時間も十分と言えます。

Googleのインフラを使える

　GAE/Jのもうひとつのメリットは、「Googleインフラの圧倒的なスケーラビリティ・高信頼性をお手軽に利用できる」という点です。GAE/Jでは、データを保存・検索する手段として一般的なRDBは利用できない代わりに、Google独自のデータストア「BigTable」を利用します。このBigTableは、Google検索エンジンの非常に高いスケーラビリティと可用性を実現する中核技術です。GAE/Jで書いたWebアプリは、その恩恵を簡単に受けることができます。

サーバ構築作業が不要、デプロイが簡単

　3つめのメリットは、「サーバ構築作業が不要、デプロイが簡単」という点です。ここでは細かな手順の説明は省略しますが、GAE/Jによるシステム開発は、以下の流れとなります。

GAE/Jにサインアップする
GAE/JのEclipseプラグイン（Google Plugin for Eclipse for App Engine development）をインストールする
Eclipse上でGAE/JのAPIに基づくJavaアプリケーションを開発、テストする
EclipseからGAE/Jへデプロイする

　GAE/Jは、他のクラウドサービスや通常のサーバホスティングサービスとは異なり、「サーバ環境」ではなく「Webアプリの実行環境」を提供するサービスです。TomcatやJBossに相当するGoogle独自のアプリケーションサーバがすでに稼働している環境があり、そこに利用者のWebアプリをデプロイして利用します。

　開発者は、GAE/JのEclipseプラグイン「Google Plugin for Eclipse for App Engine development」をインストールすることで、これらのAPIによるコーディングとビルド、テストをローカル環境で実施し、ボタンクリック1つで WebアプリをGAE/Jの実運用環境にデプロイできます。

図：EclipseによるGAE/J対応Webアプリの開発

GAE/JにBlazeDSを組み込む

　さて筆者が「ご都合.com」の実装に際して最初に考えたことは、「GAE/Jの上でBlazeDSは動くのかな？」ということです。GAE/Jでは通常のサーブレットやJSPが動作しますので、Flexクライアントとサーバ間でXMLやJSON形式でデータをやりとりすることは難しくありません。とはいえ、使ったことのある方ならおわかりのとおり、FlexのRemoteObjectによるAMF通信のお手軽さは、一度経験するとやみつきになります（人間、どんどんラクな方へと堕落してしまうものです．．．）。

　JavaベースのWebアプリとの間でRemoteObjectを用いるもっとも簡単かつ低コスト（無償）な方法は、Adobeが提供するBlazeDSを利用することです。そこでまずは、BlazeDSの「blazeds.war」に含まれるライブラリファイル（JARファイル）や設定ファイルを、GAE/Jで作成したプロジェクトの「WEB-INFフォルダ」にコピーしました。

図：blazeds.war内の各ファイルをコピーしたところ

　つづいて、BlazeDSの通常通りのリモーティング設定を行います。設定ファイルである「remoting-config.xml」にてデスティネーションを設定したのち、サーバ側JavaクラスにてHello World的メソッドを作成しておきます。ご都合.comでは、サーバ側の「Main」クラスに接続するデスティネーション「Main」を以下のように定義しました。

class="flex.messaging.services.RemotingService">
 
（中略）
 
<destination id="Main">
<properties>
<source>jp.co.sth.gotsugo.server.Main</source>
</properties>
</destination>
 
</service>

　さらに、Flexクライアントからのリクエストを受け付けるBlazeDSのMessageBrokerServletをweb.xmlにて登録しておきます。

<!-- MessageBroker Servlet -->
<servlet>
<servlet-name>MessageBrokerServlet</servlet-name>
<display-name>MessageBrokerServlet</display-name>
<servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
<init-param>
<param-name>services.configuration.file</param-name>
<param-value>/WEB-INF/flex/services-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
 
<servlet-mapping>
<servlet-name>MessageBrokerServlet</servlet-name>
<url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>

　一方、Flex側でも同デスティネーションに接続するためのservices-config.xmlを以下のように記述します。

<services-config>
 
<services>
<service id="remoting-service"
class="flex.messaging.services.RemotingService"
messageTypes="flex.messaging.messages.RemotingMessage">
<destination id="Main">
<channels>
<channel ref="ch-blazeds" />
</channels>
<properties>
<source>*</source>
</properties>
</destination>
</service>
</services>
 
<channels>
<channel-definition id="ch-blazeds" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://ホスト名/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>
</channel-definition>
</channels>
 
</services-config>

　また、Flexクライアントのプロジェクトプロパティの「Flexコンパイラ」設定画面にて、「追加コンパイラ引数」として以下のように記述し、上記services-config.xmlを参照するようにします。

-services "services-config.xml"

　そしてFlexクライアントでは、RemoteObjectから上記の「Main」デスティネーションを呼び出すコードを記述します。

// 初期化
mainService = new RemoteObject("Main");
mainService.addEventListener(ResultEvent.RESULT, onResult);
mainService.addEventListener(FaultEvent.FAULT, onFault);
 
...
 
// メソッド呼び出し
var token:AsyncToken = mainService.getOperation("sayHello").send({msg: "hello");

　以上で準備は完了です。ここまでの手順は、BlazeDSの通常の設定作業であり、特別なことはなにもしていません。

　GAE/JプラグインにはローカルのEclipse上でコードをテストできるデバッガ機能がありますので、それを用いてローカル環境でテストサーバを起動します。つづいてFlexクライアントから上記のメソッド呼び出しを実行し、テストサーバへリモート呼び出しを実行します。これは問題なく動作させることができました。

　しかし、実のところ「落とし穴」はこの後に（たくさん）待っていました。その詳細と回避方法については、次回に紹介したいと思います。