Было бы хорошо, если бы вы явно обозначили преимущества перед тем же XMPP. Это не просто прихоть, а желание понять, когда следует использовать данных подход и какой профит он принесет.
честно говоря, я не вдавался в подробности Джаббер протокола
могу ошибаться
но у них разные немного задачи,
XMPP — ориентирован чисто на сообщения, поверх XML
AMQP — бинарный протокол, кроме сообщений возможен обмен файлами и таблицами данных (у меня эти фичи пока не реализованны), ориантирован на широкое вещание — подписка на новости, оповещение о событиях и тд.
Так как XMPP является, по сути, одним длинным XML документом, невозможно передать немодифицированную двоичную информацию. В результате этого, для передачи файлов стараются использовать дополнительные протоколы, например HTTP. Для передачи же файлов и другой бинарной информации непосредственно в XMPP потоке используется base64-кодирование.
AMQP — это бинарный протокол, можно передавать файлы и потоки (видео/аудио)
Единственноее применение возможности передавать бинарные данные не средствами HTTP, как мне кажется, это толстые клиенты. Например, flash игрушки. Для остального (в том числе и для web-чата как в примере) хватит HTTP + какой-нибудь формат передачи (XMPP, JSON etc)
для прямого общения AMQP брокер и WEB приложения разрабатывается REST модуль для nginx (готовности 80% но есть спорные моменты)
можно использовать REST-MQ (форман общения JSON) но оказалось геморойно, мне не понравилось
это возможно будет один из следующих топиков
Я предполагал, что клиентская часть приложения будет обмениваться сообщениями непосредственно с брокером посредством постоянного соединения.
Опять таки, если я правильно понял, то приложение, которое вы разрабатываете, будет похоже на текстовый чат. Т.е. большинство сообщений между сервером и клиентом могут ходить текстом а не бинарными пакетами.
Если планируется использовать AJAX, то смысла поднимать «внутри» очень быстрый AMQP брокер, скрывая его за nginx-ом, вообще-то говоря мало. Фронтенд скорей умрет от огромного количества соединений, создаваемых клиентами, которые poll-ят сервер.
>Я предполагал, что клиентская часть приложения будет обмениваться сообщениями непосредственно с брокером посредством постоянного соединения.
это как это?
ява-скрипт пока не умеет работать с сокетами и разбирать двоичные данные на нем — расточительно (хотя можно.)
ява-аплеты ?? — у многих они запрещены, и это правильно.
Стандартная на текущий момент связка javascript + flash sockets. Конечно, не самый идеальный вариант. Ждем html5 web sockets :)
>ява-скрипт пока не умеет работать разбирать двоичные данные
Поэтому текст явно лучше именно в подобных случаях, где можно обойтись без бинарного кодирования.
А вообще, если всё так это чат (кстати, вы так и не ответили, что же это за приложение такое), я бы сначала глянул на jabber-related технологии. Например на BOSH. Выглядит многообещающим, но к сожалению, погонять нету времени и возможности.
AMQP-PHP чат