AMF、BlazeDSまたはGraniteDSによる、Adobe FlexアプリケーションのRPC

作者 Jon Rose , 翻訳者 佐野 徹郎 投稿日 2008年1月7日

セクション

エンタープライズ・アーキテクチャ,

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

Ruby ,

メッセージング ,

Flex ,

Java ,

Flash ,

動的言語 ,

Webサービス ,

ライセンス ,

SOA ,

言語 ,

エンタープライズアーキテクチャ ,

オープンソース ,

Adobe ,

Architecture ,

プログラミング ,

RIA ,

Adobe Integrated Runtime ,

リッチクライアント/デスクトップ ,

ビジネス ,

Apollo

先日、AdobeがAMFの仕様やコードを含むLiveCycle Data Servicesの大部分を、BlazeDSプロジェクトとしてオープンソース化すると発表(サイト・英語)したことで、Adobe Flexプラットフォームは大きく変化した。この変化はFlexプラットフォームの採用を検討している人々から、最終的なコストやライセンシングの障壁を取り除くだろう。

Adobe Flexアプリケーションは、Flash Playerにデプロイされ、クライアントサーバアーキテクチャのように、RPCによってバックグラウンドのロジックにアクセスする。WebサービスやHTTPを含むFlexのRPCオプションと、AMF/Data Servicesには、多くの違いがある。AMFはより伝統的なRPCメソッドの上で、多くのメリットを提供するバイナリプロトコルだ。AdobeのJames Ward氏は「BlazeBench: Why you want AMF and BlazeDS.(source)」というブログの投稿で、AMFのパフォーマンスと処理能力のメリットについて強調する。

AdobeのTed Patrick氏は「The ABC's of AMF.(source)」という投稿で、以下のようなメリットの概要を含む、AMFの基本について詳述する。

1. ファイルサイズ - AMFのオブジェクトはzlibを利用してとても小さく圧縮される。

2. 高速なシリアライズとデシリアライズ - AMFはFlash Player内のネイティブなCのコードを利用してとても高速に変換される。AMFフォーマットは、解釈や解析による遅延をなくし、オブジェクトの生成を単一のパス上で行うことで、少ないメモリや低速なCPUの下でも、高速にシリアライズとデシリアライズできるように設計されている。

3. ネイティブな型とカスタムクラスのサポート - ディスプレイオブジェクトを除く、Flash Player内のあらゆるオブジェクトをシリアライズできる。またデシリアライズのためのカスタムクラスをFlash Playerに提供して、シリアライズされたオブジェクトをカスタムクラスのインスタンスに戻すこともできる。

AdobeがAMFとBlazeDSのオープンソース化を発表する前から、開発者がAMFプロトコルを利用するために、コミュニティによってリバースエンジニアリングされた、いくつかのオープンソースの選択肢があった。オープンソースプロジェクトにはRubyAMF(source)、AMFPHP(source)、SabreAMF(source)、OpenAMF(source)、およびGranite Data Services(GraniteDS)(サイト・英語)がある。公開されたAMFの仕様は、これらの実装を改善するのに役立つだろう。RubyやPHPのプロジェクトはいまだに、JavaアプリケーションのためのBlazeDSのように、リモーティングとメッセージングの技術を利用するアプリケーションでAMFを利用するための第一の選択肢だ。

今までGraniteDSは、AMFプロトコルを利用するJava開発者にとって、第一のオープンソースの選択肢だった。木曜日にBlazeDSが発表されたとき、GraniteDSの創設者であるFranck Wolff氏は、すこし不意を突かれ、GraniteDSの将来に不安があるように見えた。彼はGraniteDSのメーリングリスト上で彼の考えを発表(source)した。

やあ。

ええと...これは大きなニュースです(たとえ私がすこし奇妙に感じるとしても)!

GDSにできる唯一のことは、BlazeDSに欠けている機能のために、いくつかのコード(私が主に考えているのは、透過的な外部化(externalization)、レイジーローディングのサポート、コードの生成)を提供することです。

今のところ、私はさらなるGDSの開発を中止しようと考えています...(この件についての)コメントを歓迎します。

それでは。
Franck.

その後、Wolff氏はGraniteDSの将来(source)について、すこし考えを変えた。オープンソース事業の手本として、彼はBlazeDSプロジェクトに多くの機能を寄贈できる、あるいはGrainteDSプロジェクトを独立して継続できると信じている。

やあ、みんな(私に新しい考えがあります)。

1. ちょっとした歴史。: GDSを作成したのは、FDSがとても高価であったのと、さらに重要なのは、よく知られた永続化のためのAPI(EJB3/Hibernate)と統合されておらず、レイジーローディングの仕組みも提供されていなかったからです。なので私は最初から、シリアライズおよび、関連するビーンのすべてのフィールド(id、version、など)を永続化する「透過的な外部化」の機能(特にHibernateExternalizer)を作成しました。それから、gas3(GDSコードジェネレータ)は、手作業でExternalizableインタフェースを実装したAS3ビーンを書くという、退屈な作業を避けるために設計されました。
   
   
2. どうBlazeDSをGDSと比較するか。: 意外にも、厳密なリモーティングの観点からは、BlazeDSはGDSが常に望むとおりに正確です。リモートオブジェクトによる古典的なAMF3リモーティングと、AMF3オブジェクトによる新しいCometベースのチャネルは、(RTMP上ではなく)HTTP上のプロデューサとコンシューマの間で変換されます。その一方で、永続化の観点からは、BlazeDSはいかなるデータ管理の機能も含まないので、GDSはレイジーローディングによるEJB3の永続化のように、とても重要な欠けた機能を提供します。
   
3. ちょっとした戦略。:  BlazeDSの最初のリリース(ソース付きのLGPL3)は、2008年の初め(正確なスケジュールではありませんが...)に発表されます。私たちにとって最善の戦略は、可能な限り早く(1月末より前に)GDS 1.0をリリースして、BlazeDSのソースが公開されるのを待つことです。そうすれば私たちは、BlazeDSのいくつかの良いコードを(同様にライセンスも!)GDSにコピー&ペーストするか、外部化とレイジーローディングとgas3の機能を(AdobeがOKすれば)BlazeDSに寄贈するか、あるいはGDSを(実現可能か分かりませんが)BlazeDSのプラグインみたいなかんじでリリースするかを選択できるでしょう。(この件についての)コメントを(とても)歓迎します。

ありがとう。
Franck.

GraniteDSには、FlexアプリケーションとJavaを統合するのに有利な、いくつかの興味深い機能がある。加えて、BlazeDSは単にAMFの仕様を実装するだけでなく、GraniteDSに欠けているプッシュやメッセージングの機能を提供する。実装はどうあれ、Flex開発者がAdobeのFlexプラットフォームから、よりメリットのあるオープンソースに移行するのは明らかだ。

原文はこちらです：http://www.infoq.com/news/2007/12/more-on-rpc-in-flex-with-amf