BlazeDS: фільтрування повідомлень, що передаються клієнтові

Останні два тижні знашовся час трохи побавитися із Flex та BlazeDS. Основна задача - знайти способи передачі повідомлень від сервера до клієнта, так, щоб клієнт отримував тільки повідомлення, на які він підписався.
Задача - розглянути можливі варіанти. Можливі варіанти були вибрані, а саме:

• Subtopics


• Selectors


• Adaptive polling


• Dynamic destinations

Може є більше, але це ті, до яких я добрався і з якими я погрався.

Взагалі то, subtopics та selectors можна би було об'єднати, от тільки між ними є невеличка різниця. Використовуючи selectors, можна задати більш гнучку умову вибору повідомлень, які повинень отримувати consumer. Але зрешту, є така річ як MultiTopicsConsumer. Перевірка на те, чи слід віправляти повідомленння клієнту в залежності від підписки на сабтопік чи вибірку по хедерах, виконується на стороні сервера. Іншими словами, до клієнта приходять тільки окремі повідомлення із тих, що вислані на підписаний ним destination. Клієнт отримує повідомлення, що задовільняють необхідну умову.

Adaptive polling дозволяє розширювати функціональність BlazeDS, що відповідає за відправлення повідомлення клієнтові. Тут також слід правильно вибрати, який саме із двох презавантажених методів використовувати у вашому випадку.
Цей метод, дозволяє виконувати необхідну вам дію на повідомленнями, що передаються клієнтові. Тут ми і можемо виконувати гнучку і складну вибірку повідомлень, що ми будемо відправляти клієнтові.

За останнім способом (dynamic destinations) я виконував динамічне створення окремого destination на ту чи іншу розсилку в процесі роботи сервера. А клієнти вже підписувалися на динамічну розсилку. Явні мінуси: це ресурси на створення нової підписки (які не є вже аж такими великими, щоб вважати це проблемою), а також необхідність відстежувати життя підписки та знищувати її якщо вона вже непотрібна.