BlazeDS 入門記（Using the Remoting Service）

RPC services / Using the Remoting Service

以下、特に気になった点

RemoteObject component

• Remoting Service destination はデフォルトコンストラクタが必要。
• Remoting Service のオブジェクトはステートレスでもステートフルでもOK。
  クラウドを意識するならば、アプリケーションスコープの状態は BigTable、セッションレベルの状態なら Session に格納すべきですね。普通にヒープに入れると大変なことに、、、。
• RemoteObjectの予約メソッド名に注意しましょう。予約メソッド名にカブった場合、以下のメソッドでワークアラウンド可能。

public function getOperation(name:String):Operation

Configuring a destination

• destination のスコープとして、request, application, session の３つの選択肢がある。デフォルトは request スコープ。
  ってことは、デフォルト設定だと、毎回インスタンス生成するということか。通常のサービスの場合はきちんとスレッドセーフに作成して application スコープで対応かな。サーバー間レプリケーション不要のキャッシュとか使いたいし。レプリケーションが必要なら memcache 使うべきだけど、その必要のないリードオンリーのキャッシュって結構あるからなぁ。
• Remoting Service destination のホワイトリストの作成が可能。その他、メソッドレベルの細かな制約もつけられるらしい。詳細は Configuring a destination to use a security constraint 参照のこと。
  この考え方は地味に重要ですね。手動でxmlに指定するのではなく、特定の java インタフェースをホワイトリストとしてくれるような機能があればいいのですが、あるのかな？
  

Calling a service

• RemoteObject の作成や設定は、ActionScript でも MXML でもOK。
• concurrency property の設定が可能。
• multiple : デフォルト。すべての呼び出しが普通に実行される。
• single : 既に実行中の場合は、それ以降の呼び出しは瞬時に fault 扱いとなって、サーバ側への呼び出しは行われない。これは連打防止に使えますね。
• last : 呼び出しはすべて行われるが、最後の呼び出し結果だけが利用される。長時間かかる処理なので、UI 的には途中で処理を abort して新規に処理を行いたいようなケースで利用できそうですね。利用箇所はかなり慎重に決定する必要がありそうです。

RemoteObject のインスタンスは、リモートオブジェクトをあらわしているのではなく、リモートオブジェクトと後処理の組み合わせを表したものという理解でいいのかな？　混乱しやすいポイントかもしれませんね。


Handling events

Remote Service の呼び出しが完了すると、result と fault のどちらかのイベントが発生するという話。詳細は Handling service events 参照のこと。


Passing parameters

パラメータの渡し方に、明示的に渡す方法と、事前にバインディングしておくものがあるという話。

何気に showBusyCursor="true" とか設定してますね。

明示的に渡したほうが分かりやすいような気がしますが、事前にバインディングしたほうがよいケースってどんな場合なんでしょう？


Handling results

リモート呼び出しの結果が、Operation.lastResult か ResultEvent.result から取得するという話。

その他の話は HttpService や WebService 以外では関係なさそうなので割愛。


Accessing EJBs and other objects in JNDI

EJB や JNDI 経由でオブジェクトにアクセスする場合の話。