Jaki jest najlepszy sposób na przełączenie awaryjne offline klienta stacjonarnego korzystającego z usługi internetowej?

Mam trzy nadchodzące projekty, które mają wspólny problem:

muszą mieć logikę w systemie internetowym i potrzebują aplikacji lokalnej (np. punktu sprzedaży), która komunikuje się z takim systemem za pośrednictwem usługi internetowej RESTful.

Moje rozwiązanie

Rozwiązaniem, które udało mi się wymyślić, jest zaimplementowanie w kolejce komunikatów aplikacji komputerowej do przechowywania operacji, gdy usługa jest offline, a dokładniej, asynchroniczne kolejkowanie wiadomości . Jest to jednak łatwa część (jeśli takie jest najlepsze rozwiązanie). Zajmuję się również synchronizacją danych i rozwiązywaniem konfliktów.

Główny system musi być oparty na sieci, ponieważ do raportów i monitorowania przez zainteresowane strony wymagana jest aplikacja internetowa, a usługi sieciowe obsługiwałyby żądania dotyczące kilku zakładów.

Klienty stacjonarne (najlepiej cienkie) zostaną zaimplementowane w Javie (a dokładniej Netbeans), a system WWW w Symfony2. Dwa z tych projektów wymagają integracji sprzętowej dla klienta, więc wykonanie aplikacji komputerowej za pomocą technologii internetowej (np. Appcelerator Titanium) może być poważnym problemem.

Moje pytanie

1. Jakie jest lepsze rozwiązanie, które można skalować, co oznacza maksymalną wydajność przy minimalnym wysiłku (a najlepiej bez dodatkowych kosztów, takich jak zakup serwera zapasowego do pracy lokalnej)?

2. Kto jeszcze miał z tym do czynienia? Jak rozwiązałeś swój problem? Jakie lekcje możesz udostępnić?

3. Jak poradziłeś sobie z synchronizacją?

Edycja: Dodano brakującą część do mojego pytania w punkcie # 3

Wiem, że pytanie to jest Java, ale bardzo podoba mi się ten styl architektury magistrali komunikatów na tego typu rzeczy.

Zasadniczo po wysłaniu wiadomości uzyskują potencjalnie dwie odpowiedzi. Pierwszy pochodzi z lokalnej pamięci podręcznej, drugi pochodzi z serwera po podłączeniu.

Jestem pewien, że możesz łatwo dostosować tę architekturę (nosorożec i nhib) do swojej (MQ i hib).

Rób wszystko lokalnie i okresowo synchronizuj .

Oto, co bym zrobił, gdybym był tobą (nie znam struktury synchronizacji w Javie, tak jak w .NET).

Zachowaj znacznik czasu w lokalnej aplikacji, który będzie przechowywał ostatnie udane połączenie.

Niezależnie od tego, kiedy ponownie się połączysz, znacznik czasu zostanie wykorzystany do pobrania nowych danych, a następnie wysłania nowych zamówień wygenerowanych lokalnie.

Następnie utrzymasz dwa znaczniki czasu. Jeden do określenia, kiedy zamówienie zostało utworzone (lokalnie lub online), a drugi, kiedy zostało zarejestrowane przez serwer.

Nie polecam do tego kolejkowania wiadomości. W przeszłości korzystałem z MQ jako strony e-commerce, która musiała być połączona z Navision. Wszystko działało w systemie Navision, a zmiany wysyłane do witryny e-commerce za pośrednictwem MQ, w tym status zamówienia i wszystko, w tym opisy produktów, ceny itp. Nowe zamówienia zostały również wysłane do Navision za pośrednictwem MQ.

Lub powinieneś przyjrzeć się implementacjom baz danych systemów podłączonych od czasu do czasu, które wykonują chropowatą synchronizację zdalnych klientów z serwerem. (SQL Server ma to do pewnego stopnia z SQL CE, Outlook to robi).

W ten sposób możesz wprowadzać wszystkie zmiany lokalnie w małej bazie danych (zachowuje wersje / logiczne znaczniki czasu itp., Dzięki czemu nie musisz się martwić o zegary na komputerze itp.), A po przejściu do trybu online synchronizujesz to z głównym serwer.

Nie wybrałbym rozwiązania REST, gdy system nie może być online przez większość czasu.