Warstwy systemu Mercury DB (HgDB) 3.0

 W produkcie zdefiniowano szereg warstw, pośród których należy wyróżnić. 

• Core – zbiór mechanizmów wewnętrznych, abstrakcje i implementacje opisujące definicje danych (model ENCJI), ich zależności i przepływy, zbiory interfejsów opisujących akcje na danych.
• DAO – warstwa dostępu do danych. Implementacje mechanizmów utrwalania danych w relacyjnej bazie danych, której silnikiem może być PostgreSQL, MySQL, Oracle, DB2 i inne.
• Logic – warstwa przetwarzania obiektów. Implementacje operacji na obiektach reprezentujących encje. Na poziomie warstwy logicznej łączony jest świat relacyjnej bazy danych z wyszukiwaniem w indeksie Lucene.
• Business – warstwa przetwarzania obiektów operująca na obiektach świata zewnętrznego. W tej warstwie następuje transformacja dowolnego obiektu do obiektów modelu pozwalającego na jego przechowywanie w bazie Mercury DB (HgDB).

Usługi SOAP, REST  są wystawione na poziomie dwóch warstw:

• API Logic – usługi operujące na obiektach encji. Aby korzystać z tych usług należ być świadomym w jakim formacie przechowywane są dane. Trzeba znać zależności pomiędzy encjami tak aby zapewnić ich spójność. Trzeba wiedzieć jak zdefiniować typ sprawy, jakie można ustawić jego parametry, jakie dane są danymi sterującymi. Trzeba wiedzieć jak zdefiniowane są typy proste, w jaki sposób są reprezentowane w odpowiednich kontrolkach HTML podczas generowania dynamicznych formularzy edycji danych. Usługi wykorzystywane są np. do tworzenia aplikacji GUI do prezentacji przechowywanych w bazie danych lub do dodatkowej konfiguracji gromadzonych typów jak np. uzupełnienie definicji typu o wartości słownikowe, uprawnienia do poszczególnych pól, powiązywanie pól typów nazwami alternatywnymi.
• API Business – usługi operujące na obiektach spraw. Nie jest wymagana szczegółowa wiedza na temat tego w jaki sposób przechowywane są dane. Nie jest wymagana szczegółów wiedza na temat jak zdefiniować typ obiektu. Mechanizmy warstwy biznesowej starają się zapewnić spójność danych, automatycznie zidentyfikować obiekt zewnętrzny, kategoryzować i zapisać w odpowiedniej formie. Oczywiście trzeba znać kilka zasad, które warunkują optymalne gromadzenie danych.

Architektura klastrowa

Diagram prezentuje sposób połączenia komponentów systemu w konfiguracji klastra.

• NGINX- zaprojektowany z myślą o wysokiej dostępności i silnie obciążonych serwisach (nacisk na skalowalność i niską zajętość zasobów). Wydawany jest na licencji BSD.
• Według raportu Netcraft z czerwca 2016 serwer NGiNX wykorzystywany był przez ponad 169 mln domen, co klasyfikuje go na trzecim miejscu wśród serwerów WWW, w czerwcu 2018, NGiNX był wykorzystywany przez 18,45% wszystkich zarejestrowanych polskich domen.
• Prosta konfiguracja.
• Rekomendowana jest instalacja NGiNX na osobnych serwerach.

• EhCache jest rozproszoną pamięcią podręczną Java do przechowywania i ogólnego buforowania obiektów Java EE. EhCache jest dostępny na licencji Open Source Apache 2.0.
• Możliwość konfiguracji klastra HA – jeden z node jest zawsze aktywny, pozostałe pracują w trybie oczekiwania (standby).
• Każdy node serwera usług wykorzystuje swoją lokalną pamięć podręczną. Server EhCache służy do synchronizacji danych pomiędzy poszczególnymi członkami klastra.
• Wykorzystywany przez framework Hibernate do zarządzania encjami (danymi przechowywanymi w relacyjnej bazie danych).

• Apache ActiveMQ ™ jest najpopularniejszym i najbardziej wydajnym serwerem Open Source dla obsługi kolejek komunikatów.
• Apache ActiveMQ jest szybki, pozwala na obsługę wielu klientów i protokoły różnych języków programowania. Jest wyposażony w łatwe w użyciu wzorce integracji i posiada wiele zaawansowanych funkcji. W pełni wspiera standard JMS 1.1 i J2EE 1.4. Apache ActiveMQ jest wydany na licencji Apache 2.0.
• W klastrze Mercury 3.0 wykorzystywany jest do wymiany danych pomiędzy poszczególnymi członkami klastra takie jak stan serwera (heartbeat), informowanie o konieczności odświeżenia pamięci podręcznych, czy też konieczności operacji indeksowania dokumentu po realizacji zadania aktualizacji danych.

Server SQL

• Relacyjna baza danych przechowuje dane obiektów i ich metadane.
• Rolę serwera SQL mogą pełnić produkty: Oracle, MySQL, PostgreSQL, DB2, MSSQL.
• Każdy ze wspieranych przez serwer usług Mercury 3.0 silnik relacyjny posiada własne wsparcie dla architektury klastrowej.

Mapa przepływów w klastrze

Poniżej przedstawiono przykładową mapę przepływów danych sporządzoną na podstawie narzędzia monitorującego AppDynamics.

Integracja z Iron POI Excel Server

IRON Poi Server, to serwer usług REST pozwalających na obsługę plików Excel.

• Prezentację danych składowanych w plikach Excel
• Utworzenie plików Excel na podstawie danych wysłanych do serwera

IRON Poi Server posiada integrację z bibliotekami JasperReports®Library.

• Łatwe budowanie szablonów dokumentów, które są podstawą do raportowania. Dostępne jest narzędzie Jaspersoft®Studio pozwalające na szybką edycję wyglądu szablonu.
• Generacja raportów w formacie plików: *.docx (dokument Word), *.xlsx (dokument Excel), *.pdf (dokument PDF) i inne….
• Integracja Mercury DB z IRON Poi Server pozwala na definiowanie i generowanie raportów opartych o dane składowane  w Mercury DB.

Artykuły dotyczące opisu architektury Mercury DB (HgDB) 3.0