Jak w świecie ruby’ego realizuje się następujący scenariusz:
Jest sobie aplikacja która oprócz tego że obsługuje ruch po HTTP działa również jako listener podpięty do jakiegoś zewnętrznego brokera msg.
W javie (sorry, ale to moja dziedzina, więc łatwiej mi się odnieść) jest możliwość postawienia takiej aplikacji w jednym klocku na jednym serwerze jako całość, a jak to jest w Ruby?
Z tego co zdążyłem się zorientować nie ma takiej możliwości żeby mieć np appkę w Sinatrze, która poza http będzie gadała jeszcze jakoś inaczej.
Przyjmijmy, że odebranie msg z tego brokera ma skutkowac wykonaniem logiki podobnej do tej w appce Sinatry przy obsłudze requesta HTTP.
Czy rozwiązaniem jest tu odpalenie osobnego procesu, który będzie słuchał na zewnętrznym brokerze, odbierał msg a następnie wołał po HTTP Sinatrę do wykonania tego co trzeba?
Jak to się realizuje od strony architektury i od strony deploymentu?
Ale to ma być po zupełnie innym protokole? Znaczy chcesz, żeby serwer aplikacji bindował do więcej niż jednego portu?
(ja wiem że w Javie możesz mieć jeden kontener, a w nim kilka osobnych aplikacji, ale Java jest tutaj dość… wyjątkowa, mówiąc delikatnie i nieflejmogennie)
Pomijając czy, co, i jak może zostać zrobione - ostatnio na srugu była fajna prezentacja na temat TorqueBox - jeśli więc tęsknisz za JMS, to możesz śmiało, praktycznie bezbolesnie go użyć pisząc w rubym
EventMachine pozwala różne rzeczy zbindować i na różne eventy mógłbys tak samo reagować ale to specyficzne środowisko pracy. Mongrel2 zdaje się jest pisany w oparciu o zeromq i może tam jakoś łatwo się by to dało osiągnąć. Ja bym poszedł w stronę warstwy pośredniej która z innego protokołu na http request by zamieniała i odwrotnie w drugą stronę po uzyskaniu odpowiedzi by jakoś ją przesyłała tym innym protokołem. Same railsy są chyba za bardzo przywiązane do warstwy http. Mógłbyś wziąć active model, active record itp z nich za to jeśli Ci to pomoże.
Spróbuję wyjaśnić bardziej o co mi chodzi (używając analogią do javy).
W javie na jednym serwerze aplikacyjnym można odpalić jedną aplikację, która funkcjonuje zarówno jako aplikacja webowa, ale też inne jej elementy mogą działać chociażby jako consumer/producer wiadomości z JMS używając później wspólnej części logiki.
Teraz gdybym chciał w Ruby (bez Torqueboxa i JRuby) napisać coś podobnego, to jak by to wyglądało z punktu widzenia komponentów i architektury?
Wydaje mi się, że nie ma serwera, ktory umie takie coś zrobić, bo to nie ten model (a jak Tomash napisał, java jest tutaj “wyjątkowa”).
Czy w związku z tym rozwiązaniem jest postawienie osobnej aplikacji webowej w czymkolwiek, a osobno klocka który zajmuje się komunikacją np. po JMS, appka webowa gada dopiero z tym klockiem?
Znalazłem coś takiego jak ActiveMessaging do Railsów i tam właśnie z palca odpala się osobny skrypt poller.rb jako daemon.
Dodatkowo zastanawiam się jak jest z pulą połączeń do zewnętrznego brokera w takich wypadkach? Połączenia chyba nie są nawiązywane ad-hoc? Gdzieś to musi być wszytko wystartowane i ustawione.
Widzę, że java zrobiła mocne spustoszenie w moim rozumowaniu i nie bardzo mogę teraz przestawić się na innego rodzaju środowiska.
A jaki jest powód konieczności odpalania obu listenerów na jednym procesie?
Gdybym miał coś takiego robić w ruby to rozważyłbym 2 opcje:
Listener + REST interface
Osobny proces słuchający brokera. Proces ten po odebraniu danych pakuje je do modelu ActiveResource i wypycha je do naszej głównej aplikacji przez JSON.
Listener + Redis + Resque
Jeśli warunki na pozwalają i jeśli już bym używał jakiegoś background workera, to możnaby go też wykorzystać do tego celu. Listener po odebraniu danych z brokera, wrzuca je do kolejki do przetworzenia do Redisa. Osobny worker przetwarza te dane. Serwer HTTP (aplikacyjny) jest trzecim procesem.
