Komunikacja między aplikacjami. Remoting, bazy danych, czy też inne rozwiązanie?

0

Witam,

mam do zbudowania poniżej opisana architekturę.

  • 1-* aplikacja kliencka nadrzędna, tzw aktor
  • kilka aplikacji klienckich podrzędnych (agent)
  • każda z aplikacji znajduje się na osobnym pc
  • każda z aplikacji komunikuje się z baza danych (obecnie jest to Access, docelowo może MS SQL server) i przetwarza dane.
  • aktor dokonuje zmian na bazie, na co maja reagują agenci
  • czasem agenci są w stanie spoczynku czekając aż aktor dokona modyfikacji danych

jak to ugryźć?
myślałem nad 2 rozwiązaniami:

  1. odpisywanie danych do wykonania dla agentów na tabeli i w momencie wykonania ustawieni flagi rekordu na wykonane
    agenci w osobnym wątku sprawdzaliby dostępne zadania
  2. wykorzystanie modelu klient server. zaprojektowanie modelu 1 server, klient-aktor, klient agent. W remotingu nie odnajduje się póki co, zaledwie wiem co to jest

może macie lepsze rozwiązanie pasujące do opisu?

0

Możesz też tą "baze" założyć na komputerze aktora i łączyc się z agentami przez sockety, chociaż z nimi różnie bywa.
Nie wiem czy chodzi ci o sprawdzone komputery, czy o przypadkowa kompy z sieci.

0

Z góry określone komputery w sieci lokalnej.
Baza danych znajduje się na wspólnej lokalizacji sieciowej.
Agenci muszą mieć również dostęp do bazy i korzystać z danych.

0

Sieć lokalna, pewnie w szkole. Tu akurat sockety to doskonałe wyjscie. "Baza" (to nawet może być plik *.INI) może być na kompie nauczyciela (czy też aktora) a agenci łączą się z nią. Szybsze i wygodniejsze moim zdaniem niż baza MySQL.

Ja bym to zrobił tak, że agenci wysyłają zapytania do aktora, on wczytuje informacje z bazy i odsyła.

Jakbyś nie wiedział to ogólna zasada socketów jest taka:
Klient łączy się z serverem przez IP.
Wysyła mu polecenia
Server je wykonuje, ewentualnie odpowiada...

W programie Agenta umieść komponent Klienta, a w programie aktora komponent Servera.
Klient przy starcie się łączy (w sieci lokalnej potrwa to mniej niż sekunda) i można mu wsyłac polecenia, aktor je odbieże, wczyta dane z bazy, prześle do agenta i już.

0

Baza accessa która zaproponowałem pełni funkcję docelowej bazy danych dla owego systemu.
Chciałem jej "dorzucić" funkcje opisana powyzej.
Wazna jest tez kwestia reguł bezpieczeństwa, aby komunikacja była możliwa przy restrykcyjnych ustawieniach sys. operacyjnego.

0

Ponadto aktor dziedziczy po agencie, więc czasem będzie pełnił jego funkcje.
Agent ma prawo wykonywać swoje zadnania nawet jak w danym momencie nie ma zalogowanego żadnego aktora.

0

Dodam, ze wszystko kręci się wokół bazy danych accessa. To tam wszelkich operacji dokonują aktorzy (może być wiele, więc wg powyższej koncepcji = wiele serverów).
Praca agentów to rezultat docelowy przetwarzania danych.

0

To jak Ty chcesz to zrobić? Chcesz wczytać dane z komputera który jest wyłączony?

wait, wait... Dalej nie rozumiem sensu tego tematu. To jest jakieś zadanie do szkoły? Musisz mieć tego accesa? Ja bym to zrobił inaczej, ale już trudno

0

Przykładowy scenariusz.

  1. odpalamy server
  2. odpalamy 3 app agentów (póki co bezczynne)
  3. włącza się aktor, kolejkuje zadania do wykonania
  4. wykrywają to agenci, zaczynają wykonywać swoje zadania (tra to przypuśćmy kilkadziesiąt minut)
  5. w trakcie aktor zamyka aplikacje, agenci nadal dostępni i wykonują zadania
0

Po krótce sprawa wygląda tak. Projektuję system do zarządzania testami automatycznymi bazującymi na silniku selenium.
Wszystkie dane odpisują się w bazie accessa (kilkanaście tabel). Będzie kilku aktorów, osoby sterujące wykonywaniem testów ze swojego komputera.
Będzie kilka komputerów w sieci, do których aktorzy będą mieli dostęp zdalny, albo po prostu będą uruchomione.
Docelowo nikt na nich nie będzie pracował, tylko aplikacja agencka będzie wykonywała zadania na rzecz testów.
Jeśli agenci skończą wykonywanie zadań, przechodzą w stan oczekiwania na kolejne zadania. W momencie kiedy użytkownicy zakolejkują kolejne zadania, agenci biorą się do roboty i odpisują rezultaty w bazie accessa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1