QBS >> Elementy standardowe >> QS-DistributedDataSynchronizer

QS-Distributed
DataSynchronizer

System QS-DistributedDataSynchronizer rozwiązuje

  • problem synchronizacji pomiędzy bazami danych należącymi do jednego systemu informacyjnego
  • problem obiegu informacji pomiędzy elementami systemu
  • replikację danych

Jeżeli chcą się Państwo dowiedzieć dla kogo system jest przeznaczony proszę kliknąć w Przeznaczenie. Opis systemu pozwoli na szybką ocenę czy ten program jest właśnie tym czego Państwo potrzebują. Proszę zobaczyć także co jest potrzebne do zrealizowania systemu.

Jeżeli mają Państwo pytania prosimy napisać do nas.

Winieta rozwiązania QS-DDS

Przeznaczenie

QS-DistributedDataSynchronizer jest dodatkowym modułem do aplikacji opartych o technologię Q-Line 3000. Znajduje zastosowanie w systemach baz danych, których części są od siebie fizycznie oddalone lub też z innych przyczyn nie chcemy lub nie możemy umieścić ich na jednym serwerze baz danych.

Opis rozwiązania

Trzymanie wszystkich danych na jednym serwerze z dostępem przez Internet jest rozwiązaniem drogim i często niemożliwym do zrealizowania. Alternatywę stanowi system, w którym poszczególne części posiadają własne bazy danych i co jakiś czas komunikują się między sobą w celu uaktualnienia swoich danych. Rozwiazanie QS-DistributedDataSynchronizer umożliwia łatwe stworzenie takiego właśnie systemu.

Uaktualnianie danych odbywa się według zdefiniowanych dla konkretnego systemu zasad, dzięki czemu nie musi ono polegać na doprowadzeniu wszystkich lokalnych baz danych do posiadania tej samej zawartości. Projektant systemu określa jaki rodzaj danych gdzie ma być przechowywany i kto jakie operacje może na tych danych wykonywać.

U podstaw stworzenia QS-DDS stały następujące założenia:

  1. istnieje jakiekolwiek medium pozwalające na przesyłanie plików (internet, współdzielona przestrzeń dyskowa, poczta pantoflowa).
  2. synchronizacji podlegają tabele o identycznych strukturach.
  3. jeżeli korzystamy z internetu to łącze może być również komutowane (modem telefoniczny) i poprzez publiczny dostęp do sieci.
  4. minimalizujemy ilość przesyłanych informacji - przesyłanie wyłącznie zmian.
  5. możemy synchronizować dowolną liczbę tabel z dowolną zawartością.
  6. dowolna topologia połączeń pomiędzy węzłami; wszystkie węzłu są równouprawnione.
  7. synchronizacja może następować co dowolnych okres czasu
  8. informacja (rekord) ma przypisanego jednego właściciela, record może zmieniać własciciela
  9. właściciel recordu odpowiada za niego
Jak widzimy nie są to szczególnie "mocne" założenia a co zatym idzie zakres możliwych zastosowań jest bardzo duży.

Warianty rozwiązania

W zależności od potrzeb i warunków technicznych można zrealizować trzy podstawowe warianty rozwiązania:
wariant wymagana infrastruktura możliwości/cechy
"skrzynka pocztowa"
  • minimum komutowany (modemowy) dostęp do internetu,
  • wykupiona u prowidera strona WWW i trochę przestrzeni dyskowej
  • przesyłanie danych
  • synchronizowanie danych
  • replikację danych
  • synchronizowanie na rządanie użytkownika (modem) lub automatyczne ( stałe łącze), okresowe
"szybka synchronizacja"
  • stały dostęp do internetu ze zmiennym IP w filliach,
  • własny serwer w centrali podłączony do internetu, posiadający własne stałe IP, najlepiej Linux'owy, obsługa http i php
  • przesyłanie danych
  • synchronizowanie danych
  • replikację danych
  • natychmiastowa automatyczna synchronizacja
"zdalna praca"
  • stały dostęp do internetu ze stałym IP we wszystkich filiach, serwery w filiach- najlepiej Linux'owe
  • w każdej filii serwer udostępniający możliwość zdalnego dostepu do wybranych zasobów dyskowych, najlepiej Linux'owy
  • przesyłanie danych
  • synchronizowanie danych
  • replikację danych
  • natychmiastowa automatyczna synchronizacja
  • zdalna praca na danych należących innej filli
  • możliwość modyfikowania danych należących do innej filli

Ogólny opis działania

Każdy element systemu operuje niezależnie na swojej bazie danych. Moduł QS-DistributedDataSynchronizer, znając zdefiniowane wcześniej zasady obiegu danych w systemie, śledzi wszystkie operacje użytkownika aplikacji i zapamiętuje te, o których należy poinformować inne elementy systemu.

Wariant "skrzynka pocztowa"

Na żądanie przygotowuje "paczki" zmian informacji i wysyła je na serwer WWW, z którego zostaną odebrane. Serwer WWW pilnuje by zostały one odebrane przez właściwe elementy systemu i o właściwej porze. Dostęp do WWW jest autoryzowany.

Wariant "szybka synchronizacja"

W chwili pojawiania się wymajającej przesłania informacji komputer w filli łączy się z serwerem w centrali i przekazuje mu informacje - odpowiednio przygotowane rekordy danych. Dodatkowo odbiera adresowane do siebie zmiany w danych. Wszystko następuje automatycznie bez udziału człowieka. Wykożystywany jest protokół http + PHP - identycznie jak u providera.

Wariant "zdalna praca"

W chwili pojawiania się wymajającej przesłania informacji komputer w filli łączy się z serwerem w centrali i przekazuje mu informacje - odpowiednio przygotowane rekordy danych. Dodatkowo odbiera adresowane do siebie zmiany w danych. Wszystko następuje automatycznie bez udziału człowieka. Wykożystywany jest jeden z protokół http, ftp lub zdalny szyfrowany i autoryzawany dostęp do zasobów serwera. Dodatkowo poprzez mechanizmy RMI zezwalamy na zdalna pracę na danych innej filii a w szczególności modyfikowanie "nie swoich" danych czy zdalne procesy.

Bardziej szczegółowo

Wariant "skrzynka pocztowa"

Elementy systemu


Logiczny element systemu, zawierający własną bazę danych, nazwiemy jednostką lub węzłem. Bazy danych skojarzone z poszczególnymi jednostkami muszą mieć zgodną strukturę przynajmniej dla synchronizowanych tabel. Podstawową ilością danych przesyłaną w systemie jest rekord. Każdy rekord posiada, unikalną w skali całego systemu, tożsamość. Jednostki komunikują się poprzez bufor - serwer WWW. Komunikatami są zestawy rekordów wraz z informacją o rodzaju dokonanej na nich operacji (modyfikacja/usuwanie). W danej chwili czasu co najwyżej jedna jednostka ma prawo modyfikować rekord.

Mechanizm komunikacji między jednostkami ma strukturę warstwową:
1. logika danych (filtr, bufor wyjściowy)
2. mechanizm exportu i importu zmian
3. przesyłanie plików między jednostkami (fileEx)
4. komunikacja z serwerem przez HTTP

Co przesyłamy?

W rzeczywistym systemie istnieją pewne zasady obiegu informacji. Określają one gdzie poszczególne rodzaje danych mogą powstać i gdzie powinny zostać dalej przesłane. Zasady te zapisane są w QS-DDS w postaci filtrów umieszczonych w jednostkach. Przez takie filtry "przepuszczane" są informacje o wszystkich operacjach wykonywanych na bazie danych, w wyniku czego uzyskuje się zestaw zaadresowanych rekordów do przesłania. Rekordy te składowane są w specjalnym buforze wyjściowym.

Jak przesyłamy?

Gdy wystąpi żądanie wysłania danych z zawartości bufora wyjściowego tworzone są pliki (paczki) z rekordami o wspólnym miejscu docelowym. Mechanizmu do ich przesłania dostarcza warstwa niższa - fileEx (od fileExchange). Zapewnia ona także autentykację jednostek oraz przestrzeganie terminarza synchronizacji. Terminarz określa kto do/od kogo może wysyłać/odbierać pliki. Warstwa FileEx sprawdza również czy na serwerze oczekują paczki adresowane "do mnie" i pobiera je. Warstwa importująca dokona aktualiwacji baz danych.

Cały mechanizm może byc wywoływany przez użytkownika lub okresowo automatycznie. W tym drugim jednak przypadku potrzebny jest stały dostęp do internetu.

Jedynym skutkiem braku łącza jest opóźnienie synchronizacji i koniecznośc jednorazowego przesłania większej ilości informacji.

Wariant "szybka synchronizacja"

Wariant inaczej realizuje proces przesyłu samych danych. O ile w punktu widzenia filii warian nie różni się niczym od "skrzynki pacztowej" o tyle na serwerze w centrali dodatkowo "pracuje" program Q-Receiver pozwalający na natychmiastowe "naniesienie" odpowiednie zmiany na serwerze baz danych tak szybka jak tylko się ona pojawi pojawi w buforze odbiorczym.

Jedynym skutkiem braku łącza jest opóźnienie synchronizacji i koniecznośc jednorazowego przesłania większej ilości informacji.

Wariant "zdalna praca"



Jest on zdecydowanie najciekawszy i najbardziej zaawansowany technologicznie. Korzysta on mocno z mechanizmów RMI (Remote Method Invocation). Serwery we wszystkich filiach są identyczne i najlepiej jak udostępniają sobie wzajemnie zasoby. W zależnościod specyfiki przesyłu informacji, udostępnienie może być typu gwiazdy lub każdy z każdym. Na serwerach "chodzą" dodatkowe procesy:

  • RMIServer - realizuje mechanizmy zdalnego wywoływania procedur ( Java, Sun)
  • Q-RMIServices - realizuje procedury zdalnego dostępu do danych, udostępniania recordów, zdalnych procesów.
  • Q-Sender - monitoruje dane i jak tylko istnieje potrzeba przesłania danych pobiera je z serwera baz danych, tworzy z nich paczkę do wysłania i zapisuje w buforze nadawczym
  • Q-FileExSender - monitoruje bufor nadawczy i przesyła dane na odpowiedni odległy serwer. Przeslanie może następić poprzez ftp lub http , jednak najwygodniej poprzez zdalne szyfrowane i autoryzowane udostępnienie zasobu. Po przesłaniu dane dane oczkują w buforze odbiorczym odległej filii.
  • Q-Receiver - monitoruje bufor odbiorczy i jak tylko pojawi się nowa paczka uaktualnia dane na serwerze baz danych.

Skutkiem braku łącza jest opóźnienie synchronizacji, koniecznośc jednorazowego przesłania większej ilości informacji i zablokowanie mechanizmów udostępniania rekordów i zdalnej pracy.

Pytania użytkowników

Lp.
Pytanie
Odpowiedź
1. Wasz system działa w dwóch filiach: "LAN-Radom" i "LAN-Warszawa". Obie instalacje synchronizowane są modułem QS-DDS. Wyobraźmy sobie, że połączenie internetowe zostało chwilowo przerwane, ten sam rekord jest modyfikowany zarówno w Warszawie i w Radomiu. Jak zachowa się system po usunięciu awarii łącz internetowych?
  • Zachowanie standardowe
    • Połączenia nie ma wówczas modyfikacji rekordu może dokonać tylko jego "prawny właściciel". Tak więc zrobi to tylko filia Radom albo filia Warszawa. System nie dopuści by modyfikacji dokonał "niewłaściciel";
    • Połączenie jest modyfikacja odbywa się na zasadzie uzyskania autoryzacji u właściciela. W momencie gdy właściciel rekordu zezwoli na jego modyfikację nikt inny nie będzie mógł rekordu zmienić... do momentu zakończenia modyfikacji
  • Zachowanie niestandardowe
    Firma nasza implementuje różnego rodzaju rozwiązania. Jeżeli w Państwa systemie istnieje konieczność wspólnego modyfikowania tego samego rekordu nawet podczas przerwanego łącza - możemy tak skonstruowac system by to było możliwe. Tylko od razu należy zaprojektować w jaki sposób system ma się zachować po nawiązaniu połączenia?
    • Odrzucić jedną z modyfikacji? Rozwiązanie bezsensowne, ale jeżeli tak to którą?
    • Zaalarmować obu autorów modyfikacji i poprosić jednego z nich o uzgodnienie? Rozwiązanie ryzykowne bo autorzy modyfikacji mogą byc nieosiągalni, ale jeżeli tak to jak ma wyglądać uzgodnienie?
    • ...
    Możemy zaimplementować każde zachowanie systemu. Tymniemniej z naszego doświadczenia wynika, że rozwiązanie niestandardowe musi być bardzo dobrze przemyślane tak by nie generowało bałaganu organizacyjnego.