Java, Spring, Kolejki - sposób wymiany wiadomości pomiędzy klientami

Witam,
zastanawiam się w jaki sposób można zrealizować wymianę wiadomości pomiędzy użytkownikami. Jako przykład powiedzmy, że jest serwis ogłoszeniowy i jako osoba zainteresowana produktem, chciałbym skontaktować się ze sprzedającym. I jak zrealizować taką wymianę wiadomości pomiędzy 2 użytkownikami? Czy w takim przypadku dobrze jest działać na kolejkach JMS, czy po prostu zapisywana jest wiadomość do bazy bez żadnych kolejek i wysyłanie żądań na serwer w celu sprawdzenia wiadomości? Powiedzmy, że aplikacją kliencką są urządzenia mobilne z systemem Android.

JMSy służą do zupełnie czego innego - komunikacji między aplikacjami. Ja bym zrobił tak że dałbym po prostu informację w bazie danych - klucz obcy do wysyłającego, do odbiorcy, treść, datę utworzenia i ewentualnie booleana czy odbiorca odczytał.

Czyli JMSy nie służą do wymiany wiadomości w aplikacjach czatowych?

A można by wykorzystać message brokery ?

Nie bo to jest coś do ZUPEŁNIE innych zastosowań. To że jakaś technologia ma w nazwie message nie ma NIC wspólnego z żadnym czatem.

Temat rzeka. Teoretycznie mógłbyś to zrobić nawet tak, że po napisaniu wiadomości jest ona synchronicznie dostarczana do klienta. Mógłbyś też wymyślić crona/schedulera. W praktyce (czyt. na produkcji) jednak rzeczywiście będziesz potrzebował brokera, np. Redis Pub/Sub, RabbitMQ czy Kafka. Oczywiście jest jeszcze protokół XMPP.

Poczytaj:

• http://alvaro-videla.com/2011/05/rabbitmq-chat-post-mortem.html
• http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html
• https://www.simform.com/how-to-build-messaging-app-whatsapp-telegram-slack/

Charles_Ray napisał(a):

Temat rzeka. Teoretycznie mógłbyś to zrobić nawet tak, że po napisaniu wiadomości jest ona synchronicznie dostarczana do klienta. Mógłbyś też wymyślić crona/schedulera. W praktyce (czyt. na produkcji) jednak rzeczywiście będziesz potrzebował brokera, np. Redis Pub/Sub, RabbitMQ czy Kafka. Oczywiście jest jeszcze protokół XMPP.

Poczytaj:

• http://alvaro-videla.com/2011/05/rabbitmq-chat-post-mortem.html
• http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html
• https://www.simform.com/how-to-build-messaging-app-whatsapp-telegram-slack/

@Charles_Ray dzięki za artykuły, zrodziło mi się sporo pytań w tym temacie, mam nadzieję że te artykuły rozwiążą część z nich.

scibi92 napisał(a):

Ja bym zrobił tak że dałbym po prostu informację w bazie danych - klucz obcy do wysyłającego, do odbiorcy, treść, datę utworzenia i ewentualnie booleana czy odbiorca odczytał.

Czyli póki co to jest najsensowniejsze rozwiązanie?

A co z websocketem?

@mieszko30:
Jeżeli nie tworzysz czegoś dużego to na backendzie jako datasource wiadomości/eventów cokolwiek co będzie reaktywne (będziesz mógł sie zasubskrybowac). Backend z frontem websockety lub jeśli robisz na czymś starym typu jboss 6.4 co nie wspiera servelet 3.1 to po prostu long pooling.

A jeśli chodzi logikę to jeśli nie potrzebna jest historia, to zbierać wiadomości dla danego użytkownika i przy pierwszej synchronizacji brać z datasourca i od razu wyrzucać i do klienta na mobilke, jeśli historia jest potrzebna to licznik dostarczonych wiadomości i różnice wysyłać.