BlazeDS 入門記（About channels and endpoints）

BlazeDS architecture / Channels and endpoints / About channels and endpoints

以下、特に気になった点。

• channel はクライアント側のオブジェクト。
• channel は BlazeDS server の endpoint と通信する。
• channel の設定は services-config.xml に記述する。
• endpoiint のURLの指定方法が気になる。url="http://servername:8400/myapp/messagebroker/amf" のような感じの指定のうち、myapp はコンテキストパスで messagebroker は web.xml MessageBroker の servlet-mapping から自明ですよね。となると、最後の amf の部分がどのようにして決定されるのか知りたい。何でもいいのかな？ということで、実際に試してみた。結論としては何でもOKでした。サーバ側にデプロイされている設定と、flash がコンパイルされた時点の設定が同一であればOKです。もちろん、全 endpoint でユニークである必要はありますが。
• Flex コンポーネントは channel set が使える。
• flex のコンパイル時に -services オプションによって services-config.xml を指定する。flash builder でプロジェクトを作成すると、プロジェクト作成時に設定した情報を元に勝手に -services オプションが付与される。compiler のオプション設定で手動で変更可能。
• アプリケーションで動的に destination を作成する場合、application-level default channel というのが使えるらしい。
• channel set で fallback 用の設定が可能。（でも、正直言って、自社案件ではこの機能をつかってうれしい状況が思い浮かばない。）
• HTTPS を使う endpoint は、クラス名の先頭に Secure が付く。
• Piggybacking provides lightweight pseudo polling。えせポーリングですねｗ。使いたいけど、ユーザー数が多い場合に topic や queue の管理がどうなるんだろ？要確認ですね。
• Piggybacking は、polling enabled になっている channel でも利用可能。インターバルを長めに設定しておいて、アクセスがなければそのインターバルでポーリングして、アクセスがあればそのデータに相乗りするという形。これも便利そうだ。GAEとの親和性の高い JMS のようなサービスがあれば完璧ですね。ないのかな？要調査ですね。
• polling と　piggybacking を組み合わせる際、piggyback でデータを取得した際に、そこからポーリング時間がリセットされるのかそうじゃないのかは、要確認ですね。
• long polling も使える。これはポーリングをかけたときにデータがなければそのまま待機するという仕組みだが、GAE 環境では不可ですね。残念。
• streaming も GAE 環境では不可ですね。