レベル: 中級 Dan Orlando, Enterprise RIA Consultant, Consultant
2009年 8月 18日 Adobe® Flex を使う場合と OpenLaszlo を使う場合の長所と短所について学びましょう。Flex と OpenLaszlo はクライアントサイドの RIA (Rich Internet Application) を開発するための主要な 2 つの言語であり、クラウド用に SaaS アプリケーションを構築する上では特に有用です。
リッチな SaaS (Software as a Service) アプリケーションを構築する方法を学ぶことは、明らかに価値があることです。しかし、そうしたタイプのソフトウェアを構築するのに必要なスキルを身に付けるには、どのような方法を選択すればよいのでしょう。従来、SaaS の開発と言えば、対象の URL が呼び出された場合にブラウザー上で必要な HTML を描画するための言語を選択すること、そして必要に応じてデータを保存するためのデータベースを選択することを意味していました。それとは対照的に、最近の SaaS アプリケーションの開発では、それら以外にも無数の判断をしなければなりません (図 1)。そうした判断項目の 1 つが、クライアントサイドの言語、つまり RIA に焦点を当てたフレームワークをどれにするか、という点です。クライアントサイドの言語とサーバーサイドのプラットフォームとの間には通信が必要ですが、クライアントサイドはサーバーサイドのアプリケーションとは独立して実行されます。
図 1. SaaS の 4 つのレイヤーと、各レベルでの技術
 |
よく使われる頭字語
- API: Application Programming Interface
- DTD: Document Type Definition
- FAQ: Frequently Asked Questions
- HTML: HyperText Markup Language
- HTTP: HyperText Transfer Protocol
- SDK: Software Development Kit
- UI: User Interface
- URL: Uniform Resource Locator
- XML: Extensible Markup Language
|
|
Software as a Service という用語は、大まかに言えば RIA と同義語です。結局のところ、現在 SaaS として提供されているものの大部分は RIA 技術を使用して構築されています。実際、最近のコンピューティングでは RIA 技術を使用しない限り SaaS として満足いくものを提供することはできませんが、これは RIA の手法が UXD (ユーザー・エクスペリエンス・デザイン) の概念を中心としているためです。そこで、この記事では満足のいく SaaS というものを、リッチでユーザーフレンドリーなエクスペリエンスを実現するもの、そして究極的には、より多くのことをより少ない時間で行えるようにするものと定義することにします。
評価の基準
RIA や SaaS に利用できるクライアントサイドの主な開発フレームワークには、それぞれ特有の短所と長所があります。従って、それぞれのフレームワークを評価するための一連の指針と基準を確立する必要があります。重要なことは、評価に際して偏りのない手法を採用し、事実と数字を考慮することであり、個人的な好みを基にすべきではありません。
第 1 の基準として、フレームワークはオープンソースでなければなりません。JavaFX が真のオープンソースであるかどうかに関してはさまざまな議論があり、JavaFX FAQ には明確な答えが提供されていないようです。ただし 1 つ明確なことがあり、Sun Microsystems はこの技術を未来形で表現しています (例えば「JavaFX はやがて完全にオープンソースになります」など)。Sun がオープンなプラットフォームを強力にサポートしていることを考えると、おそらく Sun はこの約束を実現するでしょう。JavaFX はコミュニティーからの貢献を受け付けていますが、JavaFX 技術はおそらく 2010年まで、完全にはオープンにならないと思われます。
したがって、この 1 番目の基準から、選択肢は Adobe Flex、そして Laszlo System の OpenLaszlo という 2 つの主なフレームワークに絞られます。興味深いことに、どちらの場合もコンパイルすると SWF フォーマットになり、主な違いは、Flex は Adobe ActionScript をベースとする点、一方 OpenLaszlo は JavaScript/Ajax (Asynchronous JavaScript + XML) をベースにしている点です。重要な注意点として、OpenLaszlo をコンパイルすると SWF フォーマットになりますが、コンパイルしたものを標準的な DHTML (Dynamic HTML) 対応のブラウザーでも実行することができ、SWF から実行する必要はありません。
Flex と OpenLaszlo を上位レベルで比較したものが図 2 です。皆さんの目標は、SaaS 開発のための 2 つの主要なクライアントサイド RIA フレームワークのうち、どれが優れているかを判断することです。
図 2. オープンソースの開発フレームワークの基本的な比較チャート
これらのクライアントサイド開発フレームワークを評価するためには、上記以外にも下記の基準を使用する必要があります。
- 成熟度
- Web サービスのサポート
- 開発作業の量
- コミュニティーの関与
- ソフトウェア要件
成熟度
フレームワークの成熟度は、そのフレームワークの最新バージョンと、その開発に費やされた時間の長さを組み合わせて測られます。
Flex
Flex フレームワークの開発は Macromedia によって 2002年に始められました。Adobe は 2004年に Macromedia を買収した際に Flex を継承しました。Flex SDK は 2006年に Flex V2 としてオープンソース・コミュニティーにリリースされました。Flex V4 SDK のベータ版は 2009年1月に入手可能となり、この記事の執筆時点では 2009年末までにベータ版を終了する予定です。
OpenLaszlo
OpenLaszlo の開発は Laszlo Systems Inc. が作成した LPS (Laszlo Presentation Server) の開発と共に 2001年に開始されました。2004年10月、Laszlo Systems は LPS のソースコードを GPL (GNU Public License) の下でリリースし、OpenLaszlo プロジェクトを開始しました。2005年の V3 のリリースと共に LPS という名前が OpenLaszlo に変更されました。OpenLaszlo の最新の安定版は V4.4 です。
より成熟しているのは OpenLaszlo
OpenLaszlo は、実際には Flex よりも前に開発が始められており (ただし名前は別でした)、また Laszlo Systems は OpenLaszlo のリリースに関して常に Adobe よりも先行してきました。Flex SDK は、4 番目となるメジャー・リリースが相変わらずベータ版である一方、OpenLaszlo は一貫したリリース・スケジュールを維持しています (現在は V4.4)。そのため OpenLaszlo は明らかに Flex よりも先行していますが、その差はあまり大きくありません。
Web サービスのサポート
Web サービスのサポートは、クライアントサイドの開発技術を比較する際の重要なカテゴリーです。なぜなら、サポートされる通信プロトコルが、ユーザーが実感する UI の応答速度に大きな影響を与えるからです。例えば、通常は JSON (JavaScript Object Notation) メッセージや AMF (Action Message Format) メッセージの方が REST (Representational State Transfer) ベースのサービスや SOAP ベースのサービスよりも高速に送信されますが、これはデータがバイナリー・フォーマットに圧縮されるためです。その結果、データの取得や処理が高速になり、ユーザーがパフォーマンスの向上を実感するようになるのです。そうは言っても、さまざまな通信プロトコルがクライアントサイドの開発技術でサポートされていることは重要です。
もう 1 つ、通信に関して頭に入れておく必要のある点として、クライアントサイドの開発者が必ずしもデータの送受信方法を制御できるとは限らないということがあります。非常によくある例として、送受信方法がサーバーサイドの開発者によって事前に決められているケースや、特定のプロトコルのみをサポートする既存の Web サービスに接続することによって、送受信方法が決められてしまうケース (このケースはよくあります) があります。この点からも、クライアントサイド開発ツールは、既存のありとあらゆる通信プロトコルをサポートすることが理想的です。
Flex
Flex では、ほとんどすべての Web サービス・プロトコルをサポートするために、莫大な時間が検討に費やされ、膨大な開発が行われました。Adobe 自身の AMF と RTMP (Real Time Message Protocol) は AVM (ActionScript Virtual Machine) でネイティブ・サポートされています。そのため、いずれかのプロトコルをサポートする任意のサーバーサイド言語と Flex アプリケーションとの間でのバイナリー・データの転送が迅速で簡単に行えるようになっています。プロジェクトの中に AS3CoreLib ActionScript ライブラリーを含めれば JSON もサポートされます。また、注目すべき点として AMF と RTMP はオープンなプロトコルであるため、大部分のサーバーサイド言語は、プラグイン、ライブラリー、API などを使うことで AMF をサポートしています。Flex はさらに、標準的な HTTP サービスや XML over HTTP もサポートしています。Flex は真の RESTful なサービスを内部でサポートするという点ではいくらか制約がありますが、一般的には、ほとんどすべての通信プロトコルを問題なく統合することができます。
OpenLaszlo
OpenLaszlo は Proxied モードと SOLO という 2 つのモードで実行されます。Proxied モードでは、クライアントサイドは Java™ サーブレットと直接接続され、サーブレット・コンテナーまたは J2EE (Java 2 Platform, Enterprise Edition) アプリケーション・サーバー (Apache Tomcat、IBM® WebSphere®、JBoss など) の内部で実行されます。このモードでは、SOAP、XML-RPC、Java DTO (Data Transfer Object) によるマッピングが可能です。2 番目のモード (SOLO) では、クライアント・アプリケーションは OpenLaszlo のプロキシー・サーバーとは独立に実行されます。データ転送は XML over HTTP のみがサポートされています。
Web サービスのサポートの面で優れているのは Flex
Web サービスのサポートの領域では、OpenLaszlo は残念ながら Flex よりも劣っています。これは OpenLaszlo の場合、SOAP と XML-RPC をサポートするだけのために OpenLaszlo の Java サーブレットと接続する必要があるためです。OpenLaszlo は Ajax がベースになっているため、SOLO モードで実行する場合には、Web サービスに対して XMLHTTPRequest オブジェクトを使用する前提の上に構築されています。残念ながらこの方式は、ほとんどすべてのサーバーサイド言語で採用されている Adobe のバイナリー AMF と比較して、リクエストに対するレスポンスが返ってくるまでの時間は、極めて長くなっています。そのため、このカテゴリーでは明らかに Flex が優れていると言わざるを得ません。
開発作業の量
Flex フレームワークと OpenLaszlo フレームワークは、宣言型の XML をベースにした独自のオブジェクト宣言言語をそれぞれ実装しています。もっと具体的に言えば、Flex は MXML を使って ActionScript オブジェクトと属性を宣言し、OpenLaszlo は LZX を使って JavaScript オブジェクトと属性を宣言します。MXML と LZX では、基本となる XML オブジェクトの記述方法は同じであり、異なるのは、使用される DTD 構造と XML スキーマのみです。どちらも主たる目的はまったく同じであり、クライアントサイドのアプリケーションと UI の開発を迅速に行えるようにすることです。
Flex
Flex は宣言型のマークアップ言語として MXML を使用しています。MXML は (すべての宣言型言語と同様) XML の基本的な原則に従います。ほとんどの場合、Flex アプリケーションは MXML クラスと ActionScript クラスの両方で構成されます。ただし MXML ファイルをコンパイルすると、宣言されたオブジェクトは ActionScript に変換されてから 1 つのバイナリー SWF ファイルへとコンパイルされます。リスト 1 のコード・サンプルは Flex の DataGrid コンポーネントの MXML マークアップを示しています。興味深いことに、dataProvider プロパティーを見るとわかるように、オブジェクト属性用の引用符ペアの内側にある中括弧 ({}) の中に ActionScript コードを配置することができます。
リスト 1. Flex の DataGridコンポーネントに対する MXML のサンプル・コード
<mx:DataGrid id="peopleGrid"
dataProvider="{_controller.contactData}" editable="false"
itemClick="dispatchItemClick(event);" >
<mx:columns>
<mx:DataGridColumn id="contact_id" headerText="ID" dataField="id" width="50" />
<mx:DataGridColumn id="last_name" headerText="Last Name" dataField="last_name" />
<mx:DataGridColumn id="first_name" headerText="First Name" dataField="first_name" />
<mx:DataGridColumn id="grid_email" headerText="Email" dataField="grid_email" />
</mx:columns>
</mx:DataGrid>
|
OpenLaszlo
OpenLaszlo が宣言型マークアップ言語として LZX を使用していることを思い出してください。LZX も、すべての整形式 XML と同じ基本的な原則に従います。LZX の場合、JavaScript 関数を <method /> タグの中に配置することができ、このメソッドに独自の ID を割り当てることができます。リスト 2 のコードはリスト 1 の Flex コードとほとんど同じことを行っており、表のデータを表示するためのグリッドを作成します。
リスト 2. OpenLaszlo のグリッド・コンポーネントに対する LZX のサンプル・コード
<canvas width="800" bgcolor="0xeaeaea">
<bluestyle name="bluecolors"/>
<dataset name="contactsData" request="true"
type="http" src="http:contactsdata.xml"/>
<grid datapath="contactsData:/*" sizetoheader="false">
<gridtext editable="false" width="50"
datapath="position()" resizable="false"
sortable="false"> ID </gridtext>
<gridtext datapath="@firstname"> First </gridtext>
<gridtext datapath="@lastname">Last </gridtext>
<gridtext datapath="@displayname"> Fullname </gridtext>
</grid>
</canvas>
|
開発作業の量に関して優劣はありません
どちらの技術も成熟を続けていますが、それぞれのフレームワークの開発を続ける上での基本原則は同じままであり、より多くのことをより少ない時間で実現することです。言い換えれば、より多くのことを MXML で行えるということは、必要な ActionScript コードは少なくなるということです。同様に、より多くのことを LZX 表記で行えるということは、これまでほど大量の JavaScript コードを作成する必要がないということです。これは開発者の作業が減るということです。現状では、ほとんどの場合、アプリケーションを OpenLaszlo で作成しても Flex で作成しても、必要な時間はほぼ同じです。この点と、2 つのプラットフォームの間に無数の類似点があることを併せて考えると、優劣をつけることはほとんど不可能です。つまり、開発作業の量に関しては、優劣はないと私は判断します。
コミュニティーの関与
どのようなオープソース技術の場合も同じですが、通常、その技術の採用を決める重要な要素として、その技術の進化の速さのほかに、コミュニティーが関与するレベルがあります。ある技術がコミュニティーから強力にサポートされているかどうかは、そのコード・ベースにコントリビュートする人の数からは必ずしも判断できません。実際、コミュニティーの関与という面は、あちこちにいる「オープン・ジャーナリスト」の数で容易に判断することができます。そうした「オープン・ジャーナリスト」は、その技術の初心者を対象にしたブログの中で、チュートリアルや特別なハウ・ツー資料を公開しています。また、強力なコミュニティーには品質保証アナリストの大きなグループがあり、そのプロジェクトのバグ・データベースをとおしてバグをレポートしています。
Flex
Flex は V2 よりも前に、既に大きな注目を集めていました。これは主に、Adobe が Macromedia を買収した後に強力なマーケティング活動を行ったことによるものです。その結果、2006年に Flex SDK がオープンソースとしてリリースされると同時に、Flex コミュニティーは指数関数的に拡大したようです。この、Flex SDK の進化を話題の中心とするコミュニティーの規模は、これまでと同じ速いペースで拡大を続けています。
OpenLaszlo
OpenLaszlo は、Pandora、YouTube、Amazon をはじめとする、数々の製品を手がける多数の企業で採用され、成功しているにもかかわらず、OpenLaszlo を取り巻くコミュニティーの規模は比較的小さいままです。これはマーケティングと大きく関係しているかもしれませんが、純粋な規模とマーケティング予算の面で、Adobe が Laszlo Systems と比較して圧倒的に優勢であることは疑問の余地がありません。
コミュニティーの関与の面で優れているのは Flex
コミュニティーの関与という面では、Flex が明らかに優っています。Adobe のニュース・アグリゲーターは Flex のカテゴリーのみで 2,370 のフィードを集めます。さらに、Flex.org とオンラインの Flex Cookbook から、オープンなコミュニティーに対して大量のリソースが公開されています (Flex Cookbook は、コミュニティーによって公開されてきた Flexの「コード・レシピ」の百科事典のようなものです)。
ソフトウェア要件
このカテゴリーには、それぞれの技術を使用して作成したアプリケーションを実行する前にインストールが必要な、すべてのプラグインやソフトウェアが含まれます。これは通常、技術を採用する際の大きな障害になります。ユーザーは、彼らのマシンにインストールが必要と言われるものを信用するのをためらうからです。特に、それが予想外のものである場合には信用しようとしません。また一部のユーザーは、ある特別なソフトウェアがないと何かが実行できないと言われると、何が起きているのかと混乱してしまいます。そうしたことが起こると、ユーザーは、その Web サイトから完全に立ち去ってしまう場合さえあります。
Flex
Flex アプリケーションは Adobe Flash® Player で実行されます。Flash Player は現在、すべてのソフトウェア・アプリケーションやプラグインの中で最も高い普及率を誇っています。2009年6月時点の全世界での Flash Player の普及率は記録的な 98.8 パーセントに達し、新興市場では 97.1 パーセントに達しています。特に注目すべき点として、最新バージョンの Flash Player V10 の普及率は 2008年12月の 55.9 パーセントから 2009年6月には 86.7 パーセントに上昇しています。
OpenLaszlo
OpenLaszlo の特に興味深い点として、OpenLaszlo をコンパイルすると、Flash Player で再生できる SWF ファイルと DHTML の両方が生成されます。OpenLaszlo の開発予定表に示されている OpenLaszlo フレームワークの究極的な目的は、Web ブラウザーで実行する任意のフォーマットにコンパイルできることであり、そのフォーマットの中には Java アプレットも含まれています (これは JavaFX の場合も同じです)。ただし 1 つの領域で、OpenLaszlo には大きな問題が起きています。この記事の執筆時点で、LZX アプリケーションを Flash Player V10 で実行することができず、いつ実行できるようになるかはまだわかりません。OpenLaszlo アプリケーションは Flash Player のバージョン 7、8、9 には対応しています。
ソフトウェア要件の面で優れているのは OpenLaszlo
OpenLaszlo をコンパイルすると複数のファイル・フォーマットをサポートできるという事実は、それ自体が大きな成果であり、他のすべてのクライアントサイド RIA フレームワークから OpenLaszlo を差別化するものです。クライアントの最大限の互換性という面では、OpenLaszlo が優れています。
まとめ
RIA コミュニティーで Flex を取り巻くさまざまな話題を見ると、OpenLaszlo と真正面から比較した場合に Flex が圧倒的に優れていると主張することは、最初は論理的に思えるかもしれません。しかし私は、決してそんなことはないことに気付きました。この 2 つの RIA 開発技術を比較した結果、優劣を付けられずに終わったという単純な事実は、「最高の」言語やフレームワークはないことを示しています。この記事での教訓はおそらく、最適な開発技術はビジネスのニーズに焦点を絞ることで自ずと判明する、ということだと思います。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Dan Orlando はエンタープライズ規模の Flash プラットフォームに関するアーキテクト兼コンサルタントとして広く認められています。彼は RIA 支持者として、さまざまな雑誌や Web サイトに記事を発表しています (PHP Architect、Flash and Flex Developer Magazine、IBM developerWorks、Amazon Web Services、Adobe Developer Connection など)。また彼は『Flex 4 in Action』(Manning Press 刊) の共著者でもあります。 |
記事の評価
| 
