J2EE関連の最新トピックをわかりやすく解説
J2EE Watch ［10］

Java技術者がフロントにFlashを選択した理由とは？

---

■Java開発者から見たAjaxとFlex

　周知のとおり、いまAjaxに注目が集まっている。インタビューに参加いただいた3名ともに、プロジェクトの要件に応じてAjaxとFlexの双方を適材適所で選択している。では、この両者はどのように使い分ければよいのだろうか。

　まず公門氏は、Ajaxの優位性として、HTMLベースであることの安心感を挙げる。「Flexを提案する場合、お客様との間では『Flexはいつまでサポートされますか』といったベンダー依存についての議論が避けられません。そのため、（ある要件のもとで）AjaxでもFlexでも同じことが実現できるのであれば、やはりHTMLがもっとも堅実ではないか、という結論になることもあります」。確かに、Flexではソースコードの大部分が公開されているとはいえ、多かれ少なかれベンダへ依存することは否めない。

　それでも顧客の理解を促し、採用してもらうだけの価値がFlexにはあると、横田氏は説明する。そのひとつは開発生産性の違いである。

　「Flexを導入する前は、HTMLテーブルのレコードの動的な増減などをJavaScriptで実装していました。いまでいえばAjaxそのものです。しかし、デバッグ作業に非常に苦労しました。不具合があるとWebブラウザの左下に黄色いエラーメッセージが表示されるのですが、その原因が何なのか究明する手段がない。JavaScript によるHTMLコンテンツの動的な生成は、動作時の見た目は格好がよいのですが、開発は惨たんたる状況でした」（横田氏）。

　これに対しFlexでは、ビジュアル開発環境がEclipseプラグインとして提供されており、Flash Player内部で実行されるActionScriptコードをステップ実行できる本格的なデバッガが利用できる。Flexの登場によって、リッチクライアントの開発環境が「Java開発と同じ土俵に立った」と横田氏は述べる。

　「Flexの新バージョンFlex2のビジュアル開発ツールであるFlex Builder2は非常に敷居が低く、多彩なUIコンポーネントをポンポンと配置するだけで、すぐにその動作を確かめられます。しかもクライアントの動作スピードがとても速い。これからはFlex2を使う人がかなり増えるのではないでしょうか」（横田氏）。

日本電気株式会社 システム技術統括本部 矢野直彦氏

　コンシューマー向けWebアプリケーション開発においてFlashやFlexをいち早く採り入れてきた日本電気の矢野氏も、この意見に同意する。

　「Flex2のメリットは、まず（開発の）ハードルが低いということです。例えばお客様に見せるプロトタイプも、Flash制作の経験がない開発者でもドラッグ＆ドロップ操作ですぐ作成できます。HTMLベースの開発ですと、そこから JSPを起こす必要がありますが、Flex2ではプロトタイプをそのまま実開発にも利用できます」（矢野氏）。

　横田氏は、Ajaxに対するFlexの優位性を次のように総括する。「Ajaxは『FlashでできることをHTMLで実現する技術』と言うこともできるでしょう。Flash技術は、（開発生産性や機能性、パフォーマンスについて）常にAjaxの一歩先を進んでおり、“リッチクライアントのマイルストーン”と言えるのではないでしょうか」。

ビジュアル開発環境Flex Builder2。EclipseプラグインによりMXMLおよび ActionScriptによるビジュアル開発やデバッグが可能（クリックすると拡大）

■課題はフレームワーク

　Flex導入を考えるJava EE開発者にとって気がかりな点は、ActionScriptというスクリプト言語の習得にかかる労力だろう。しかし今回インタビューに答えていただいた3名とも、Java EE開発者であればActionScriptは容易に習得できるという意見だ。公門氏は「（Flex導入に際して）教育面ではそれほど苦労しなかった印象」と説明する。また矢野氏も次のように述べる。「Javaを知っていれば、ActionScriptは容易に書けます。もちろん、ActionScriptに固有のノウハウは必要ですが、言語習得のハードルは低いと言えます」。

　さらに横田氏は、Flex2から採用された最新版のActionScript3（ECMAScript Edition4互換）では、プログラミング言語としての成熟度が一段と高まった点を指摘する。

　「例えばActionScript3の言語仕様はC#やJavaとよく似ていて、Eclipse上でコードを見ていると『これはJava コードだったかな？』と見まちがえることもしばしばあります。実際、ActionScript3からはコンパイラによる型チェックが厳格になっており、ある意味コーディングは楽になっています」（横田氏）。

　こうしたActionScriptとJava という言語の違いよりも、むしろ「Flex開発における設計手法の変化」にとまどいを覚えたという声が多い。例えば、従来のWebアプリケーション開発ではStrutsなどのフレームワークが制御を統括するため、HTTPリクエストからHTTPレスポンスに至る処理の流れは明確であった。一方Flexでは、Visual Basicと同様に、ボタンクリックなどのイベント発生に応じて任意のロジックを実行できる「イベントドリブン設計」が可能になる。その自由度の高さゆえに、Flex特有の難しさがあると公門氏は説明する。

　「例えばフォーカス移動時のイベント発生の順序などをあまり考えずに設計していると、意図していない順序でロジックが実行されることもあります。そうしたとき、1個所を直すとほかの部分もすべて直す必要が生じたりします」（公門氏）。

　矢野氏も、公門氏と同様の問題意識を持っている。「（Flex開発の）当初はどう作っていけばよいか分からず、開発者それぞれが思い思いのソースコードを書いてしまうこともありました。 Flexにいちばん必要なのは、やはりフレームワークです。その枠組みのもとにそれぞれの開発者が記述していくことで、生産性や保守性を高められます」（矢野氏）。実際に矢野氏の部門では、上流の設計情報をもとに、FlexおよびJavaのソースコードを自動生成するフレームワークを開発中であるという。

　さらにアドビも、こうした開発者の声に応えるかたちで、オープンソースのフレームワーク「Cairngorm2」をFlex2の発表に合わせて公開している。

■Flex2＋Java EEで変わる設計手法

　現時点でのFlex開発には、こうした「手探り」な部分があるのも事実だ。しかしその一方で、これまでのJava EE開発にはなかった新発想が盛り込まれている点もある。

　その１つが、サーバサービスである「Flex Data Services 2（FDS2）」によるサーバプッシュ技術だ。FDS2では、Flashクライアントとの間でAMF（Action Message Format）と呼ばれるデータフォーマットでRTMPプロトコルを用いた通信が可能であり、HTTPでは実装の難しいサーバからのプッシュが容易に実現できる。横田氏によると、FDS について顧客がもっとも興味を示すのがプッシュ技術であるという。

　「例えば、問い合わせ件数や売上情報などをリアルタイムにWebブラウザ上に表示したい、といったニーズに応えられます。また特定グループのWebブラウザだけにメッセージを同報配信したりできます」（横田氏）。

　さらにAMFでは、Flash上のActionScriptオブジェクトとサーバ上のJavaオブジェクトを直接マッピングでき、Webサービスに比べてケタ違いのパフォーマンスを実現するという。サーバ上の例外をFlash側に伝達することもでき、これまでHTTPの制約に縛られてきたJava EEの設計手法が一変する可能性もある。

　Flex／Flashは、Java EEが直面するカベを超えるための1つの回答にすぎない。しかし、Flexが示してくれるHTMLの限界に対する打開策は、今後のJava EE開発のあるべき方向性に、多くの示唆を与えてくれているのではないだろうか。

2/2

INDEX
J2EE Watch ［10]
	Page1 「見た目、どうにかならないか」というカベ 「JavaではなくPHPでもよいのではないか」という閉塞感
	Page2 Java開発者から見たAjaxとFlex 課題はフレームワーク Flex2＋Java EEで変わる設計手法

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）