Komunikacja pomiędzy procesami

Dyskusje
1

Hej,
mam taki problem. Używam pewnego protokołu do komunikacji z bankami, i chcę zrobić przelew. Problem w tym, że w jednym cyklu protokołu muszę zrobić 3 cykle aplikacji. Protokół wymaga implementacji klasy z metodą callback, która to metoda jest wywoływana kilka razy, i za każdym razem oczekuje innej reakcji użytkownika. Wygląda to mniej więcej tak:

[code]
nr |Rails | callback

1 |start połączenia | wybierz metodę autentykacji

2 |wyświetl metody autentykacji i | przyjmij wybraną metodę informacji / wyślij informacje na temat wybranej metody autentykacji (np 3,5,7 cyfra z smsa)
|wyślij wybraną |

3 |wyświetl informację i wyślij | przyjmij kod bezpieczeństwa / wyświetl rezultat
|kod autentykacyjny |[/code]
Tutaj mały pseudokod obrazujący pracę protokołu:

[code=ruby]# to implementuje ja, potrzebuję tu jakoś łączyć się z railsami
class MyCallback < BaseCallback
def callback(reason, message)
case reason
when :choose_auth_method
# tu powiemy railsom o możliwych metodach autentykacji i będziemy czekac na to co użytkownik odpowie,
# potem wyślemy railsom informacje który kod trzeba podać ( Rails nr 1 i 2)
process_auth_method_choosing(message)
when :get_auth_method_security_code
# tu przyjmiemy kod wysłany przez railsy (Rails nr 3)
end
end

conn = BankConnection.new(auth_params, BaseCallback)

#wykonujemy transfer, teraz nam się wywoła callback z argumentami reason i message w zależności od progressu połączenia
conn.preform_transfer(transfer_data)

a to też musimy wysłać railsom

conn.result.get_message

ufff![/code]

Jako że railsy wymagają kilka cykli, to połączenie muszę odpalić w osobnym procesie (ewentualnie wątku kontenera, bo applikacja jest na jruby, ale chyba mniej kłopotów stworzyć process). I teraz pytanie do Was, jak to wszystko ogarnąć? Na czym odpalić prodes do tworzenia transferów, jak się komunikować? Co jest obecnie w najlepsze do rozwiązania tego typu problemu?

PS. Nie jest to pewnie precyzyjnie napisane, ale pytajcie jak coś jest nie jasne. Za trochę to znów przeczytam i doprecyzuję.

2

Wygląda na to, że potrzebujesz dodać model w stylu PaymentProcess i callbackiem w nim mieszać a na podstawie jego “stanu” serwować strony.

3

przypomina mi to troszkę ‘oauth dance’ - próbowałeś patrzeć na to w ten sposób?

a mógłbyś napisać troszkę jeszcze jak ma wyglądać separacja tego co widzi user, od tego co jest wysyłane do api? bo to jest dla mnie troszkę niejasne - czy wszystko jest w 100 % synchroniczne (czyli user klika coś co leci do railsów i jest forwardowane z automatu do api)?

“w jednym cyklu protokołu muszę zrobić 3 cykle aplikacji (…) wymaga implementacji klasy z metodą callback, która to metoda jest wywoływana kilka razy” - i jakoś nie jestem w stanie powiązać tego z tabelką niżej :slight_smile:

4

Z mojej strony jedynie minimalna uwaga dotycząca JVM. Odpalenie nowego wątku jest zdecydowanie tańsze niż odpalenie nowego procesu - zarówno z punktu widzenia czasu i pamięci. Przyczyna to brak Kernel.fork w JRuby, a co za tym idzie odpalenie nowego procesu to odpalenie od zera nowej VM. Jeśli liczysz na równoległość, postaw na wątki.

Jeśli się mylę, będę bardzo wdzięczny za uwagi.

5

Ja się zgadzam z takim podejściem, ale raczej zakładając, że aplikacja nie będzie generowała dużego ruchu. Problem z większym ruchem jest taki, że może być potrzeba odpalenia tego na kilku maszynach i wtedy już nie jest tak różowo, bo 2 requesty od tego samego użytkownika mogą pójść do 2 różnych serwerów aplikacyjnych. Nie demonizowałbym też tych 2 procesów zamiast jednego. Railsy żrą dużo pamięci, ale podejrzewam, że kod, który zajmuje się tylko jedną stosunkowo prostą rzeczą raczej nie będzie zjadał kilkuset megabajtów.

No ale tak jak napisałem, to przy dużym ruchu, więc pewnie nie ma co się przejmować na wczesnych etapach rozwoju aplikacji.

Gdybym miał się do tego zabierać, to pewnie eksperymentowałbym też z celluloid/dcell i wtedy odchodzi też w jakimś stopniu problem wyboru komunikacji - dcell może się komunikować zarówno w tym samym procesie jak i pomiędzy różnymi maszynami.

6

Trudno było sparsować o co chodzi, jeśli dobrze rozumiem to może postaw sobie mały serwerek w racku na każdym z serwerów aplikacyjnych i wystaw Railsom cały ten proces jako web-service po localhoście, albo ew. skorzystaj z http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html