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

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?

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.

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.

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ż.

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.

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.

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.

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

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

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.

Dobra, rozumiem.
Dalej sądzę że najlepszym wyjściem są sockety.
Agenci w tym przypadku powinni być programami-serverami, a aktorzy programami-klientami.
Aktorzy łączą swoje prgroamy z agentami, wysyłają im polecenia. Agenci robią swoje, i odpisują.
Aktorzy zapisują wynik w bazie.

TomRiddle napisał(a)

Dobra, rozumiem.
Dalej sądzę że najlepszym wyjściem są sockety.
Agenci w tym przypadku powinni być programami-serverami, a aktorzy programami-klientami.
Aktorzy łączą swoje prgroamy z agentami, wysyłają im polecenia. Agenci robią swoje, i odpisują.
Aktorzy zapisują wynik w bazie.

Ewentualnie ja bym dodał u agentów klase odpowiedzialna za komunikacje z baza danych.
Dlaczego? agent pobiera cały zestaw danych do testu. karkołomne byłoby przekazywanie danych prez aktora do klienta.
W takim razie poczytam o socketach bo nie wiem z czym to sie je.

Dzieki za rady

ps, czy owa komunikacja klient-server wymaga jakiś specjalnych uprawnien, odblokowania portów etc? jak wspomniałem, nałożone są duże ograniczenia na system operacyjny

Generalnie raczej nie prześlesz danych po zablokowanym porcie. Ale nie wiem czy jest sens zniżać się do socketów, moim zdaniem można to wszystko oprzeć na zwykłym remotingu.

Teraz sobie zdałem sprawę, skoro triggerem dla agenta jest zadanie na bazie a nie sygnal od aktora, to jest sens implementowac mechanizm klient server? moze lepiej zbudowac aplikacje agent i aplikacje aktor i aktor tworzy zlecenia w bazie a agent je realizuje? tylko fajnie by było mieć informację o aktywnych agentach etc, więc może mechanizm komunikacji aktor-agent oprzeć tylko na monitowaniu aktywnych agentów

Przesylanie obiektow przez MSMQ