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.
0
1
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ł.
0
Czyli JMSy nie służą do wymiany wiadomości w aplikacjach czatowych?
0
A można by wykorzystać message brokery ?
2
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.
4
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:
0
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:
@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.
0
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?
0
A co z websocketem?
0
@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ć.