Granite Data Service：オープンソースのFlex向けData Service

Granite Data Services (GDS：Granite は花崗岩の意味）(source)はAdobeのLiveCycle Data Servcices（LCDS：Adobeのデータサービス技術）やBlaze Data Sercvices（LCDSのリモート技術やメッセージ技術などをオープンソース化したもの）の代替となるオープンソースデータサービスだ。GDSは LGPLライセンスの下で使用でき、2008年1月30日にはプロダクション版であるGDS 1.0がリリースされた。InfoQ.comはGDSプロジェクトを立ち上げたFranck Wolff氏にこのオープンソースプロジェクトについての詳しい話を聞いた。

GDSの概要について。

Granite Data ServicesはAdobe LiveCycle Data Servicesの代わりとなるもので、JEEテクノロジーへの適用を特に重視しています。EJB3/Hibernateのような代表的なJava EE永続化システムを、遅延ロードも含めて全てサポートします。GDSではFlex2/3で標準のRemoteObjectを扱えるので、AMF3 （RemoteObjectで用いられるデータフォーマット）の利点を全て得ることができます。さらにGDSは多くのテクノロジーをサポートしています。

• ポピュラーなウェブフレームワークサービスとの相互運用性
• サーバーサイドのEJB3セッションビーンの呼び出し（これはJBoss Seam（JSF、EJBなどを統合するWebアプリフレームワーク）による拡張があってもなくても構いません）
• Acegi（Spring向けセキュリティフレームワーク）によるセキュリティを備えたSpringビーン
• Google Guice（GoogleのDIコンテナ、ジュースと発音）サービスとWarp（コンポーネントベースのWebアプリフレームワーク）の永続化
• POJOサービスのサポート

データプッシュのサポートはGDS 1.0での新しい機能です。そしてGDSでActionScript3のコード生成（Gas3）も出来るようになり、Flexアプリケーション開発を大いに支援します。Flex Builder IDE、あるいはフリーのFlex SDKと一緒にGDSを使うと、Flexアプリケーションの開発とデプロイを完全にかつ強力に支援するフレームワークになります。

GDSプロジェクトについて。

EJB、 Spring、POJO、そしてGas3でのGDSの利用はこれまで広く行われてきましたし、プロダクション版としていい段階になりました。バージョン 0.4から1.0へ一気に上がったのもそのためです。ただGDSに最近取り入れられた新しい機能（Seam、Guiceサービス、データプッシュ）はまだベータ版のレベルと考えた方がいいでしょう。

GDSは主にAdequate Systems(source)のWilliam Draiと私によって開発が進んでいます。1年前の公開（GDSのドキュメント参照(source)）からはオープンソースコミュニティの多くの開発者も加わってくれています。当社としてはGDSを将来のFlexソリューションのアーキテクチャのサーバーサイドにおけるコア技術にしたいと考えています。

GDSのロードマップとRIAアーキテクチャについて。

今はクライアントサイドのエンティティレポジトリに取り組んでいるところです。これはFlash VM上でそれぞれのエンティティに一つのインスタンスだけ存在することを保証するものです。このレポジトリの重要な役割の一つは、関連するオブジェクトを Flexサイドで必要になった時に初期化するという遅延操作を透過的に行うことにあります。この機能はCairngorm(source)（Flexアプリケーション用のフレームワーク）からインスパイアを受けました。

ロードマップに関してもう一つ重要なのは、GDSとJBoss Seamの統合を改善することです。アーキテクチャの観点からすると、私たちが目の前にしている新しいRIA開発には、15年前に逆戻りしてしまうリスクがあるように思います。つまりクライアント/サーバー型の考え方が再び支配的になってしまうのではということです。この傾向はステートフルなクライアントとステートレスサーバー（シンプルなデータベースのフロントエンドがそうです）へと私たちを連れ戻してしまいかねません。このアーキテクチャは小規模な Flexアプリケーションでは可能で有効かもしれませんが、大規模アプリケーションでは最善の選択とは言えないと思います。GDSで取り組みたいと考えているのは、Seamが持つ対話とタスクのというコンセプトによって、言うなればステートフルサーバーコンポーネントのコンセプトを形にすることです。

我々のゴールはFlex上ですべてのデータマネジメントシステムを構築することです。これには自動的なフォーム作成機能（エンティティを編集するパネル）や検証機能(クライアント側でのHibernateのアノテーション検証機能を複製する）も入っています。

GDSにおけるデータプッシュについて。

GDSにおけるデータプッシュ（Gravity：重力と呼ばれる）はComet（データプッシュ技法のひとつ）的なサービスとして実装されています。HTTP（RTMPでなく、特定のインターネットポートを使うのでもなく）で送信されるAMF3メッセージを使用し、Bayeuxプロトコル（非同期メッセージングをHTTPオーバー等で行うためのプロトコル）を標準的に用いています。このデータプッシュの実装はTomcat 6.0.14以上、JBoss4.2.2以上、Jetty Continuations 6.1.15以上で利用可能です。Gravityはここ(source)のFlexドキュメントにも書かれているようにJMS（JavaのメッセージングサービスAPI）アダプタもサポートします。

Flex 3 SDKからConsumerクラスがなくなってしまったので、クライアントのコードでmx.messaging.Consumer や mx.messaging.Producerを使用することができませんでした。そのため、自分たちで同じプロパティとメソッドを持った Consumer/ProducerのActionScriptクラスを書き上げました。ただし、Flex 2とFlex 3の両方の互換性を保つためにsubtopicプロパティだけはtopicという名前に変更しました。また、データ送信先を記述するservices- config.xmlというファイルの中で使用するためのGravityChannel （org.granite.gravity.channels.GravityChannel）というチャネルクラスも作りました。これは簡単にいうと、 flash.net.URLStreamクラスのコマンド用とトンネル用のインスタンスをカプセル化し、ロングポーリングをサポートします。

もしあなたがmx.messagingパッケージのクラスを使っているのなら、若干修正が必要になります。

1. 全てのmx.messaging.Consumerクラスのimport文をorg.granite.gravity.Consumerのに変更する（Producerクラスについても同様）
2. 全てのtopic参照をsubtopicへの参照に変更する
3. services-config.xmlファイル中のチャネル宣言を変更する
   

Gas3の機能について。

Gas3を使った方法は次のようになります。

1. まずEJB3エンティティビーンズを書くことでデータベースモデルを設計する
2. Gas3でエンティティビーンのプロパティをコピーしたActionScript3ビーンを生成させ（これらはFlexのクライアント側のモデルビーンになる）、またHibernateツールでデータベーススキーマを生成させる（テーブルとインデックスの作成のため）
3. ビジネスロジックをセッションビーン、Spring、Guice、あるいはPOJOサービスに記述する
4. MXMLでFlexアプリケーションをつくる

また、Gas3のコード生成用テンプレートを独自に定義もできますし、生成されるActionScript3クラスを好きにカスタマイズすることもできます。

GDSとBlazeDSを比較して。

BlazeDSは基本的にLCDSのサブセットで、直接的にはデータ管理機能を提供しません（この図(source)を参照）。GDSはEJBの永続化レイヤを完全に統合するようにデザインされていて、LCDSにはないと思われる大変重要でユニークな機能を持っています。それはプロキシ（単一端関連）と遅延フェッチです。このことで最悪データベース全体を読み込まないといけないようなリスクを回避できます。


この機能はまた別のユニークなシリアライズ機能であるExternalizer(source)（外部化機能）をベースにしています。Flex標準（つまりBlazeDSやLCDS標準）であるAMF3のシリアル化では、一時的なプロパティや publicな静的プロパティ以外もシリアル化されてしまいます。バージョン管理ナンバーのようなprivateにしておきたい ActionScript3ビーンは、シリアル化しないでprivateにしておきたいこともあるでしょう。BlazeDSあるいはLCDSでこれを実現するにはエンティティビーンズをExternalizable（外部化可能）にしないといけませんが、それにはJavaとAS3の両方に、きちんと対応したreadExternalメソッドとwriteExternalメソッドを実装する必要があります（参照）(source)。これはとても退屈な作業です。そしてソースコードはエラーが入りやすく、かつエラーが見つけにくいものになるでしょう。そもそもエンティティビーンのコードが自分のものでなかったら、これを行うのは不可能です。GDSのExternalizerを使えばJavaビーンをExternalizableにコーディングする必要はなくなり、AS3ビーンをGas3に生成させることもできるのです。生成されたAS3ビーンは強い型付けがされ、Javaビーンで privateだったプロパティはAS3でもprivateですし、遅延ロードもサポートします。

BlazeDSのドキュメントには、 BlazaDSが「オープンなアダプタアーキテクチャ（外部サービスの接続を容易に行うアダプタを利用したアーキテクチャ）」で「JMS、EJB、 ColdFusionコンポーネント、その他データソースとの統合を容易に行う」と書かれています。この観点からいえば、GraniteDSと BlazeDSに大差はありません。GDSも「オープンなアダプタアーキテクチャ」に基づいているのですから。GDSの開発者たちはSpringや Seam、Guiceのサービスアダプタに貢献してきた人たちなのです。ただGDSは他にも、シリアル化の全てのプロセスをコントロールできたり、独自のデータ型をサポートするなど、多くのことをカスタマイズを加えることができるのです。

驚くべきことに、BlazeDS及びGDSのデータプッシュの実装は、両方ともCometによく似たアーキ テクチャをベースにしています。GDSはあらゆるBlazeDSのアナウンスの前である2007年の夏に、この実装の選択を発表しました。ということで、 データプッシュの実装はよく似ている可能性はありますが（BlazeDSのソースコードはまだ公開されていません）、BlazeDSが私の知る限りTomcatoのみサポートしているのに対して、GDSはJettyのサポートも行っています。

BlazeDSでなくGDSを使った方がいいケースについて。

もしHibernateのようなJava EEの永続化機構を利用したソフトウェアのプロバイダであれば、きっと遅延フェッチを使った方法を十分に考慮したフレームワークの重要性を理解してくれるはずです。GDSの最も重要な機能の一つ（それはGDSの開発を始めた主な理由の一つでもあります）は、クライアントサイドのActionScript3 でHibernateの分離オブジェクトのコピーを使用できることです。まるでクライアントがJava EEアプリケーションのウェブ層にあるようにです。BlazeDSではこれを完全にすることはできないようですので、BlazeDSを使うだけではGDS と同じことはできません。さらに、Gas3のコード生成機能を使えば時間もかなり節約できますよ。

BlazeDSプロジェクトと統合する可能性について。

そのことについてAdobeと話を持ったことはありません。多分AdobeはBlazeDSとLCDSとの切り分けを明確にし続けたい、BlazeDSではデータ管理は行わない、と考えているのではないでしょうか。一方GDSではJava EEに採用されている代表的な技術をベースに、BlazeDSやLCDSと代替可能かつそれらにはない機能も備えた実装を行おうとしています。私が今言えるのは、もしAdobeがGDSにある機能の一部または全てをBlazeDSにも加えたいと思うなら、GDSとの統合も選択肢の一つになりえるだろうということです。ただしその場合でも、その先のBlazeDS開発が私たちのニーズと一致するものになるという何らかの保証が得られるかが問題になるでしょうね。

終わりに、Wolff氏よりオープンソースコミュニティへ。

GDSに素晴らしい貢献をしてくれたオープンソースコミュニティのみなさんに改めて感謝したいと思います。 

GDSについてのより詳しい情報はGDSのサイトで得られる: http://www.graniteds.org/

原文はこちらです：http://www.infoq.com/news/2008/02/granite-data-services