The following figure shows the main features of BlazeDS:
上の図が BlazeDS の主な特徴を示しているとのことです。
BlazeDS core features
The BlazeDS core features include the RPC services and the Messaging Service.
RPC services と Messaging Service が core features らしい。ということは、図中の Service Adapters と Proxy Service は異なる位置づけを持つということですね。どう違うのかな？
RPC services
The Remote Procedure Call (RPC) services are designed for applications in which a call and response model is a good choice for accessing external data. RPC services let a client application make asynchronous requests to remote services that process the requests and then return data directly to the client. You can access data through client-side RPC components that include HTTP GET or POST (HTTP services), SOAP (web services), or Java objects (remote object services).
普通にRPCですが、コールバック形式というのがポイントですね。同期呼び出しはサポートしなさそうです。ActionScript や JavaScript から利用されることを考えれば、特に違和感はありません。
クライアント側では、RPC用のコンポーネントとして HTTP GET or POST (HTTP services), SOAP (web services), Java objects (remote object services) の３種類が用意されているとのこと。REST につなぐ場合、Web Service につなぐ場合、BlazeDS につなぐ場合で使い分けるという感じでしょうか。
Use RPC components when you want to provide enterprise functionality, such as proxying of service traffic from different domains, client authentication, whitelists of permitted RPC service URLs, server-side logging, localization support, and centralized management of RPC services. BlazeDS lets you use RemoteObject components to access remote Java objects without configuring them as SOAP-compliant web services.
異なるドメインからのトラフィックのプロキシ、クライアント認証、許可されたRPCサービスURLのホワイトリスト、サーバサイドロギング、ローカライゼーション、RCP サービスの中央管理等に RPC を使うらしい。
プロキシはクロスドメインへの対応かな。さまざまなドメインの REST サービスを多用する場合などには重宝するかも。
クライアント認証はセッション単位とクライアント単位が使えるらしい。HttpSession がレプリケーションされていないサーバ環境でも使えるかどうかが気になるところですね。
許可されたRPCサービスURLのホワイトリストは、普通に crossdomain.xml を使うことを指しているのかな？
サーバサイドロギングは、log4j のような感じの機能を独自に持っているということっぽい。
ローカライゼーションは、locale 毎のリソースを用意する方法っぽい。
RCP サービスの中央管理というのは、destination を利用することらしい。クライアントは destination を設定するだけで RPC サービスにアクセスできる。サーバ側でどのようなメソッドに関連付けられているかとか、プロキシ経由でほかのドメインのRESTサービスにアクセスしているとか、クライアント側では一切考えなくていいということですね。
クライアント側で RemoteObject コンポーネントを使うと、SOAP準拠の Web Service として設定しなくてもリモートの Java オブジェクトにアクセスできるらしい。
ここら辺の各特長については、後の章の詳しい説明に期待しましょう。
A client-side RPC component calls a remote service. The component then stores the response data from the service in an ActionScript object from which you can easily obtain the data. The client-side RPC components are the HTTPService, WebService, and RemoteObject components.
クライアント側には HTTPService, WebService, RemoteObject 用の RPC コンポーネントがあって、リモートサービスから取得したデータを ActionScript object に格納してくれるらしい。そういう低レベルの処理を自動でやってくれるのは楽でいいですね。
Note: You can use Flex SDK without the BlazeDS proxy service to call HTTP services or web services directly. You cannot use RemoteObject components without BlazeDS or ColdFusion.
BlazeDS proxy service を利用しなくても Flex SDK を利用して HTTP services や web services を直接呼び出せるらしい。しかし、BlazeDS もしくは ColdFusion 無しでは RemoteObject コンポーネントとしてアクセスすることはできないとのこと。
詳細は Using HTTP and web services 参照のこと。
Messaging Service
The Messaging Service lets client applications communicate asynchronously by passing messages back and forth through the server. A message defines properties such as a unique identifier, BlazeDS headers, any custom headers, and a message body.
Messaging Service では、クライアントとサーバ間で相互にメッセージのやり取りができるらしい。メッセージはユニーク ID や BlazeDS ヘッダやカスタムヘッダやメッセージボディによって定義されるらしい。決められたヘッダがあってカスタムヘッダがあってデータ本体がある点は、普通のHTTPアクセスに似てますね。
Client applications that send messages are called message producers. You define a producer in a Flex application by using the Producer component. Client applications that receive messages are called message consumers. You define a consumer in a Flex application by using the Consumer component. A Consumer component subscribes to a server-side destination and receives messages that a Producer component sends to that destination. For more information on messaging, see Using the Messaging Service.
メッセージを送信するクライアントアプリケーションをプロデューサと呼び、Flex アプリケーション内で Producer コンポーネントを使用することによって定義するらしい。
メッセージを受信するクライアントアプリケーションをコンシューマと呼び、Flex アプリケーション内で Consumer コンポーネントを使用することによって定義するらしい。
Consumer コンポーネントはサーバ側の destination にサブスクライブして、Producer コンポーネントがその destination に送信したメッセージを受け取るらしい。
ひとことで言うと、JMS のようなメッセージングサービスが使えるということですね。
詳細は Using the Messaging Service 参照のこと。
The Messaging Service also supports bridging to JMS topics and queues on an embedded or external JMS server by using the JMSAdapter. Bridging lets Flex client applications exchange messages with Java client applications. For more information, see Connecting to the Java Message Service (JMS).
JMS の topic と queue へのブリッジ機能も持っているらしい。
詳細は Connecting to the Java Message Service (JMS) 参照のこと。
Service adapters
BlazeDS lets you access many different persistent data stores and databases including JMS, and other data persistence mechanisms. A service adapter is responsible for updating the persistent data store on the server in a manner appropriate to the specific data store type. The adapter architecture is customizable to let you integrate with any type of messaging or back-end persistence system.
DB や JMS やその他の永続化メカニズムを使用するためのアダプタが用意されているという話ですね。たとえば、RemotingService 用には flex.messaging.services.remoting.adapters.JavaAdapter が用意されているみたいな感じかな。どんなバックエンドだろうとカスタマイズ可能らしい。
The message-based framework
BlazeDS uses a message-based framework to send data back and forth between the client and server. BlazeDS uses two primary exchange patterns between server and client. In the first pattern, the request-response pattern, the client sends a request to the server to be processed. The server returns a response to the client containing the processing outcome. The RPC services use this pattern.
The second pattern is the publish-subscribe pattern where the server routes published messages to the set of clients that have subscribed to receive them. The Messaging Service uses this pattern to push data to interested clients. The Messaging Service also uses the request-response pattern to issue commands, publish messages, and interact with data on the server.
メッセージングには request-response と publish-subscribe の２つのパターンがあり、RPC では前者を使用していて、Messaging Service では用途に応じて両方のパターンを使い分けているらしい。
ここら辺は、JMS とか使ってた人にはおなじみの内容ですね。
Channels and endpoints
To send messages across the network, the client uses channels. A channel encapsulates message formats, network protocols, and network behaviors to decouple them from services, destinations, and application code. A channel formats and translates messages into a network-specific form and delivers them to an endpoint on the server.
Channel は、メッセージフォーマットとネットワークプロトコルとネットワークの振る舞いをカプセル化し、サービスや destination やアプリのコードと切り離す役割を持っているらしい。
Channels also impose an order to the flow of messages sent to the server and the order of corresponding responses. Order is important to ensure that interactions between the client and server occur in a consistent, predictable fashion.
Channel はメッセージの順序保証もしているらしい。これは重要ですね。自前で順序保証のコードとか書きたくないですから。
Channels communicate with Java-based endpoints on the server. An endpoint unmarshals messages in a protocol-specific manner and then passes the messages in generic Java form to the message broker. The message broker determines where to send messages, and routes them to the appropriate service destination.
Channel はサーバ上にある java ベースの endpoint と通信するらしい。endpoint がメッセージのアンマーシャリングをしてメッセージを Java のオブジェクトに戻し、そのオブジェクトを message broker に送るらしい。ではその message broker とは何かというと、どの destination に送るかをけっている人らしい。
まとめると、Channel は電文を送信するレイヤであり、endpoint が電文を java のオブジェクトに変換し、message broker が java のオブジェクトを適切な destination に送るということかな。
詳細は BlazeDS architecture 参照のこと。
Channel types
BlazeDS includes several types of channels, including standard and secure Action Message Format (AMF) channels and HTTP (AMFX) channels. AMF and HTTP channels support non-polling request-response patterns and client polling patterns to simulate real-time messaging. The streaming AMF and HTTP channels provide true data streaming for real-time messaging.
チャネルには複数のタイプがあるという話。
standard AMF channel と secure AMF channel と HTTP channel は polling 無しの request-response パターンとポーリングによりリアルタイムメッセージングをシミュレートするパターンをサポートし、streaming AMF channel と streaming HTTP channel はシミュレートではなく本当のリアルタイムストリーミングを提供するとのこと。
BlazeDS summary of features
Proxy service については、クライアントの変わりにサーバが代行して他のドメインにアクセスすることにより、クロスドメインのセキュリティ制約をかわすということですね。
Publish and subscribe messaging については、JMSのようなメッセージングが簡単に使えるということですね。
Software clustering については、、、。一切説明されてない話が、突然まとめとして出てきてますね、、、。詳細は Clustering 参照ですね。
0 件のコメント:
コメントを投稿