BlazeDS 消息机制 subtopic和selector的区别

http://www.insideria.com/2009/02/lcds-data-push-subscription-sc.html
If you have ever worked with LiveCycle Data Services or BlazeDS in a data-broadcast (data-push) scenario, there's no doubt know about using Consumer objects to receive streams of data. When messages are received, MessageEvent.MESSAGE events are dispatched, and your application can respond to the incoming data as it is received.

If you are working with subscription based scenarios (meaning that you only want to receive specific messages based on some sort of criteria), there are a few things that you can do.

And no, receiving all messages on every client, and handling them as a client side filter is not a good solution.

【Selector based filtering】
One option that you can do is to use the selector property on a consumer object. The selector property allows you to build filters that resemble a SQL where clause.

myHeader > 0 OR myHeader < 10

These filters examine the headers of each message coming from the LCDS server, and are filtered on the server-side. Messages that do not fulfill the subscript filter are not sent to the client.

Reducing the number of messages sent to each client reduces network bandwidth utilization and increases throughput. Selector filters are created on the client, and can be changed at any time during the life of a Flex application.

The drawback with this approach is that it is expensive and potentially insecure. It is expensive in that every message coming through the LCDS messaging bus needs to have its headers examined, and it loops through all subscribed consumers to see if it should be sent to that consumer. Put thousands of messages per minute into this scenario, with thousands of consumers, and it will back up eventually, and it is not fun to debug.

It is potentially insecure in that if you subscribe to that messaging channel without specifying a selector, then you get every message coming across the messaging channel. If you are working with sensitive data, this could be an issue.

【Subtopics】
Rather than using a selector property, you can also filter messages coming through a messaging channel using subtopics. When you connect, you connect to a specific subtopic, and any messages that are not within that subtopic are not sent to the consumer instance. There can be many subtopics per messaging channel, and subtopic message delivery is much faster on the server side. Subtopics provide a filtering mechanism similar to that of selectors where messages are filtered on the server side, however they are much faster, as there is a direct mapping of subtopic and subscribed consumers. The "expensive" analysis of a selector query does not need to be executed for each consumer instance. Instead, each message is directly routed to the appropriate consumer based on mappings in-memory in the LCDS instance.

Subtopics are also more secure than selector queries because if you subscribe to a messaging channel without specifying a subtopic (and incoming messages have a subtopic specified) then you will not receive any messages from the server.

Each message can only have one subtopic, however you can subscribe to multiple suptopics using a MultiTopicConsumer component. MultiTopicConsumers are used in the same manner as "regular" Consumer objects, except that they are able to subscribe to more than one subtopic per messaging channel. This is very helpful in broadcast scenarios.

Think about a real-time stock tracking application -- Your server is dispatching messages for each stock symbol. For this example, let's just examine "ADBE", "GOOG" and "MSFT". You only want to receive messages for "ADBE" and "MSFT". There can be a subtopic for ADBE, and a subtopic for MSFT. With a "regular" Consumer object, you would only be able to subscribe to one. With a MultiTopicConsumer, you could subscribe to incoming messages on both the ADBE and MSFT subtopics. This approach enables each individual client connection to subscribe for a different set of updates on different subtopics -- essentially providing the same capability as a selector filter of stockSymbol='ADBE' or stockSymbol='MSFT', execpt that it is faster and more secure.