Доброго времени суток!
Есть веб-приложение. Есть модуль на С, который пишет в БД. Есть клиентская часть на Javascipt, которая опрашивает серверную часть на java, которая опрашивает БД. То есть сишный модуль и клиент общаются через БД. 
Сейчас данные на клиенте обновляются по запросу. То есть каждые N секунд клиент посылает http-запрос на сервер, сервер посылает запрос к БД и обратно идут ответы. 
Хотелось бы добавить в приложение асинхронность. Чтобы клиенты висели постоянно на сервере и получали обновленные данные по факту. На сервере придется сделать пересылку данных с сишного модуля напрямую на java-сервер, а java-сервер, в свою очередь, будет отправлять это определенному клиенту, который висит на сервере.
Как реализовать асинхронность между js-клиентом и java-сервером понятно. Это comet или websocket. Так как стоит Tomcat7, можно использовать его API. Или можно использовать Servlet 3.0. Или atmosphere. Или что-то еще.
Как реализовать асинхронность между сишным модулем и java-сервером тоже понятно. RPC (protocol buffers, например) или сообщения (AMQP, ZeroMQ).
Но непонятно, как связать прием сообщения на java-сервере и передачу его определенному клиенту, висящему на сервере.
Если кто реализовывало подобные решения, подскажите пожалуйста, можно ли такое сделать, и если можно, то как?

В комет тоже возобновляемые запросы. 
Если не переходить на комет, а сначала только исключить базу данных из цепи? Если и в этом случае непонятно как делать, то комет здесь не при чем.  


очевидно, у каждого клиента есть уникальный id, и они при соединении укладываются в Мар, где key=id

Это сообщение отредактировал(а) COVD - 1.8.2011, 14:09

Так ведь у тебя и так асинхронность...
"То есть каждые N секунд клиент посылает http-запрос на сервер, сервер посылает запрос к БД и обратно идут ответы. " 
Это нормально будет работать, если ты кэш здесь запользуешь и не будешь так часто базу мучить запросами. Правду тебе говорю)


"Хотелось бы добавить в приложение асинхронность. Чтобы клиенты висели постоянно на сервере и получали обновленные данные по факту. " 
JMS  "topic"? Или как там это зовётся... Короче, есть такой паттерн "список рассылки". Загугли.


Да, если ты что-то высокопроизводительное и асинхронное мутишь, то я б посоветовал пролистать книгу: G. Hohpe, B. Woolf. Enterprise Integration Patterns
Вот там по асинхронной разработке много чего есть интересного, "в шаблонах".

Из фреймворков для асинхронной разработки есть Camel и ActiveMQ...

Основная проблема в том, как стандартными средствами передать принятое сообщение от службы обмена сообщениями определенному клиенту, висящему на веб-сервере. 

пусть клиент сам присосётся к шине обмена сообщениями

Добавлено через 1 минуту и 13 секунд
либо сделай что-то типа ящика для сообщений, который клиент будет время от времени опрашивать(почти тоже самое, что у тебя есть)

В том то и дело, что не хотелось бы делать опрос. Мне кажется, что можно сделать свой веб-сервер, который будет принимать подключения по websocket от клиентов, принимать сообщения от middleware и роутить их на определенного клиента

Можно и такой роутер запилить... С ящиком как-то проще AJAX-у работать будет... Не факт что WebSocket'ы у тебя браузером сейчас будут поддерживаться.

Это понятно, что сейчас только Хром их поддерживает официально. А будущее вебсокетов туманно. Но можно и comet-streaming  попробовать сделать.

Последовательные http опросы (ajax, comet) работают везде. А long polling (бесконечный ответ) может быть заблокирован антивирусом, который буферизирует ответ и ждет его окончания.

long polling - это не бесконечный ответ. это как раз последовательный опрос, но долго висящий на сервере. а бесконечный ответ - это бесконечный iframe.

Если это не Comet, то что такое Comet?

чистящее средство для унитаза