Flex/AIRハマり帳 ～第1回：Google App Engine for Java＋BlazeDSでハマらない方法・前編～
必要条件
ユーザーレベル
すべて
はじめに
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名の方にご利用いただいています。
このサイトの大きな特徴は、「GAE/JとBlazeDSで動作しているRIA」という点です。では改めて、GAE/Jとは何かを簡単に紹介します。
Googleが2008年4月に発表したGoogle App Engineは、「自分が開発したWebアプリをGoogleのデータセンターで運用できるクラウドコンピューティングサービス」です。当初は利用可能な言語がPythonのみに限定されていましたが、2009年4月よりJavaに対応するGAE/Jが公開されました。以下に、GAEのおもな特徴をまとめます。
- 無償で始められる
- Googleのインフラを使える
- サーバ構築作業が不要、デプロイが簡単
「無償で始められる」
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の実運用環境にデプロイできます。
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の通常通りのリモーティング設定を行います。設定ファイルである「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クライアントから上記のメソッド呼び出しを実行し、テストサーバへリモート呼び出しを実行します。これは問題なく動作させることができました。
しかし、実のところ「落とし穴」はこの後に（たくさん）待っていました。その詳細と回避方法については、次回に紹介したいと思います。
