Granite Data Services は先週，バックエンドに JavaEE を使用する Flex リッチインターネットアプリケーションを構築する 独自のエンタープライズプラットフォームを発表した。この Granite DS フレームワークは LGPL v2 ライセンスの下，そのすべてがオープンソースとしてリリースされている。
Granite DS のクライアント開発フレームワークである Tide は，依存性注入やコンテキスト管理， 認証処理，セキュアなアクセス，Bean Validation など JavaEE でなじみの深いコンセプトを，クライアントの Flex 側で実現する。また Granite DS は，JBoss や GlassFish，WebLogic，WebSphere，Tomcat，Jetty など主要な JavaEE アプリケーションサーバ，Hibernate や EclipseLink などのフレームワーク，OpenJPA や DataNucleus など JPA エンジンのすべてに統合可能である。加えて，Comet の実装をベースとしてスケーラブルなデータプッシュを実現する，効率性の高いリアルタイムモジュールである Gravity もバンドルされている。
Granite DS がリッチインターネットアプリケーションをどのように見ているかを理解するため，同社の CEO で共同設立者でもある Frank Wolff 氏に話を聞いた。
InfoQ: エンタープライズソフトウェアスタック，特に RIA は近年，急激な発展を見せています。新たなレベルのスケーラビリティ，モビリティ，HTML5 など ... その中で Granite DS は，どのような立場にあるのでしょうか？
Frank: Web アプリケーションにおけるスケーラビリティは，クラスタ環境のロードバランシングを使って実現するのが一般的です。新しい GraniteDS Enterprise Platform では JBoss 5.1 (Community あるいは EAP) を使用した，アウトオブボックスで利用可能なクラスタリングサポート (ロードバランシングとフェールオーバー) をバンドルしています。クラスタノード間でのセッションと認証のレプリケーションは，現時点では JBoss を使って開発されていますが，他のアプリケーションサーバ (WebLogic，GlassFish，Tomcat，Jetty，その他) にそれを再利用するのは簡単なことです。スケーラビリティの面についてはもうひとつ，コネクション／スレッドの管理もあります。Granite DS では非同期サーブレット (Comet と呼ばれます) を利用してリアルタイムメッセージングを行うことによって，従来の同期型サーブレットモデルよりもはるかに改善されたスケーラビリティを実現しています。
Flex 開発におけるモビリティは，Adobe が先日リリースした新 Flex と Flash Builder リリース 4.5 で取り組んできた課題です。これは基本的には，モバイル機器の小さなスクリーンにフィットする Flex スキンを作成して，Flex/Flash ソフトウェアを Android あるいは iOS プラットフォーム用の Air アプリケーションとしてコンパイルするものです。これ (iPhone/iPad がサポートされたこと) は大きなニュースですが，同時にいくつかの制限もあります。まずアプリケーションは Flash アプリであって，Flash 仮想マシン上で動作していることには変わりありません。そのためネイティブな Android / iOS アプリとは外見が違うだけでなく，ターゲットプラットフォームのネイティブな機能のすべてを利用することができないのです。Granite DS では先日，これらの制限を克服するネイティブライブラリ (Java/Objective-C 用) をリリースしました。これによって，GraniteDS サーバに接続して AFM3 フォーマットでデータを交換する，ネイティブな Android / iOS アプリケーションが開発可能になります (AMF3 はFlex アプリで用いられている，非常にコンパクトなバイナリ形式のシリアライゼーションフォーマットです)。現在はまだ開発中 (どちらのライブラリもベータ版) ですが，すでにそれぞれのプラットフォームおよび開発言語用の AMF3 リモーティング機能を提供しています。
HTML5 は，エンタープライズクラスのアプリケーションで使用するレベルに達していません。仕様全体が 2012 年までリリースされないので，ブラウザプロバイダによる完全なサポートも当分期待できそうにありません。さらに，この仕様を取り巻いて新たなブラウザ戦争が起きるのでは，という心配も，極端に悲観的な考え方とは言えないでしょう。この分野の主要なプレーヤたちはまだ，仕様の第１ステップであるビデオフォーマットにさえ合意できていないのですから ... このブラウザの互換性問題に加えて，HTML 開発者ならば誰でも知っていることですが，HTML5 に対応するタイプセーフな言語が存在していないことも問題です。現時点では現行の JavaScript を使う以外に選択肢がないのですが，大規模なクライアントサイドアプリケーションを開発するには，JavaScript は非常に脆弱で制限の多い言語なのです。そして最後に問題となるのは，このタイプの開発者に適した本当の IDE がまだ存在しないことです (ただし GWT は例外で，Java コードから JavaScript を生成するという巧妙なトリックを使って，このギャップを回避しています)。それに比較すると，Flex / ActionScript3 / Flash Builder の組み合わせは，HTML の開発にはまったく比類するもののない程，強力な開発環境を提供します。一方で HTML5 も順調に進化を続けていますから，今後10年の間には強大な技術シフトとして現れてくることでしょう。GraniteDS では，サーバに接続可能な HTML5 アプリケーションの構築と，プラットフォームの備える AFM3 フォーマット，リアルタイムメッセージング，さらには先進的なデータ管理機能を活用するための JavaScript ライブラリをリリースする予定です。
InfoQ: 永続性は 90 年代中頃の ORM の初期時代から延々と続いている問題です。 JPA は誰もが待ち望んだ，その解決策のようにも思えます。この点についてはどのように考えていますか？
Frank: GraniteDS の初期の目標のひとつとして，遅延ロードや Hibernate といった JPA エンジンの全機能を活用することがありました。GraniteDS が開発されてきた5年間には，TopLink/EclipseLink，OpenJPA，DataNucleus など，主要なエンジンのすべてが JPA をフルサポートするようになっています。GraniteDS の JPA サポートは広範に利用されてきたため，現在では十分に成熟したものになっています。Tide クライアントフレームワークを通じた透過的遅延ローディングも利用可能です。データは (Flex バインディングなどを通じて) クライアント側で最初にアクセスする時点で遅延的に初期化され，自動的にフェッチされます。
GraniteDS 全体としては，EJB3，Spring および JBoss/Seam，JPA エンジン，Bean Validation など，すべての主要な JavaEE フレームワークや機能との統合を目指しています。最大の目標は Flex を Java 開発者の間で広めることで，そのために Java 開発者の好むフレームワークへの統合，あるいは依存性注入やクライアント側のエンティティマネージャ，オブザーバ形式のイベントバスといった JavaEE のコンセプトを取り入れたいと思っています。
InfoQ: RIA およびモバイルアプリケーションでは，双方向あるいはリアルタイムなプロトコルの重要性が高まっています。複合アプリケーション (Composite Application) におけるリモーティングの将来をどのように考えますか？
Frank: リアルタイムプロトコルには新しく，興味深い可能性が備わっています。Web 開発者たちの利用度も，ここ 10 年間で増してきました。ユーザエクスペリエンスに対して有益なソリューションであり，人々がどこからでもアプリケーションやデータにアクセス可能になるという意味で，これはもちろん素晴らしいことですが，一方で Web 開発者とフレームワーク提供者たちは２つの大きな課題に対処しなければなりません。
1. サーバのスケーラビリティ： HTTP には "データプッシュ" といったものが存在しません。クライアントアプリケーションがリクエストを送信して，データが利用可能になるまでサーバ側に保留されなければならないのです。サーバは同時に数万 (場合によっては数十万) の永続的な接続を同時に処理する必要がありますが，非同期モデル (Servlet 3.0 仕様で標準化されたものです) は，このリソース消費を削減するのに非常に有効な手段です。ただし HTTP プロトコルそのものが拡張されてクライアントがサーバのように動作し，サーバが本当のデータプッシュを実行できるようになるならば，それはそれで大きな進化であると言えるでしょう。
2. ネットワークの輻輳: 携帯電話のネットワークは，複数の永続的 HTTP 接続を扱うにはほど遠いものです。ですからスマートフォンアプリの開発で利用されるリモーティング API では，同時接続数に何らかの制限を設けなければなりませんし，リアルタイムメッセージングは可能な限りプラットフォーム独自の通知機構に依存する必要があります。そうしなければ，これらのアプリケーションは 3G (あるいは 4G)ネットワークには手に余るものになってしまいます。
私たちのプラットフォーム開発では，これらの問題を認識しています。例えばネイティブな (Java あるいは Objective-C の) モバイルライブラリの開発では，すべてのリモートコールを特定の HTTP 接続にキューするように配慮しました。そうであっても，この新しい複合アプリケーションの世界において，すべてのデバイスに適合する汎用性と一貫性を持ったリモートソリューションに到達するには，まだまだ多くの作業と研究が残っているのです。