Architektura systemu

Owned by Henryk Rybinski
Mar 20, 2024
3 min read

Informacja ogólna

Z punktu widzenia architektury System Ω-ΨR jest monolitycznym i “nierozkładalnym” oprogramowaniem.  Można mówić o modułach Systemu jedynie w aspekcie funkcjonalności. W ujęciu funkcjonalnym można wyróżnić moduł publikacji, moduł projektów, moduł multimediów, itp.. Można też patrzeć na System w ujęciu technicznym, wyróżniając moduł utrwalania danych (pojemnik danych), front-end z podziałem na interfejs publiczny i po zalogowaniu, czy też moduł kontroli dostępu. W opisie architektury posłużymy się metodyką C4, która prezentuje 4 poziomy szczegółowości.

W wyniku projektu SYNAT powstała wersja 1.0 Systemu, która była monolitem nie tylko funkcjonalnym, ale również na poziomie komponentów kodu źródłowego, (projekt budowany w Systemie ANT). Przed rozpoczęciem projektu PPM OMEGA-PSIR była podniesiona do wersji 2.0. Wersja 2.0 wprowadzała zgrubną modularyzacje “techniczną” na poziomie kodu źródłowego (system budowania Maven). W trakcie realizacji PPM powstała wersja 3.0, w trakcie utrzymania PPM powstała wersja 3.1 (system budowania Gradle). W trakcie pojawiania się nowych wersji architektura Systemu była zmieniana (refactoring) celem osiągnięcia większej wydajności I lepszej modularyzacji.

Diagramy prezentują stan architektury do wersji na dzień obecny.

Poziom architektury C1

image-20240320-133642.png

Poziom architektury C2

 

image-20240320-133735.png

 

 

Poziom architektury c3

 

 

Poziom architektury c4

 

 

Moduły niezbędne do funkcjonowania Systemu OMEGA-PSIR ale nie stanowiące Systemu

Jak podkreślono wyżej, z punktu widzenia architektury System OMEGA-PSIR jest monolitycznym i “nierozkładalnym” oprogramowaniem.  Oznacza to, że nawet jeśli wydzielimy moduły, które chcielibyśmy przekazać użytkownikowi, to nie ma możliwości dostarczania Systemu OMEGA-PISR z “wybranymi modułami”. Zasadniczym elementem “konfigurowania funkcjonalności” jest mechanizm przełączników (toggle), który pozwala bardzo elastycznie konfigurować zakres i sposób działania Systemu.

W ostatnim okresie pojawiły się tendencje do budowania nowych bloków (modułów) Systemu. Uzasadnieniem tego jest zredukowanie obciążenia głównego serwera Systemu (inne moduły mogą być posadowione na innych niezależnych serwerach). W sposób wyraźny oddzielone są:

o   moduł optymalizacji koszyka osiągnięć,

o   Moduł komunikacji z PBNem i z POLONem

o   Moduły komunikacji z systemami zewnętrznymi (ORCID, DataCite, WoS,  itp.)

o   Moduły integracji z systemami wewnętrznymi na uczelniach (SAP, USOS, Aleph, Dspace itp.)

Umowy licencyjna i subskrypcji nie definiują, jakie moduły budują System, a jakie są odrębne.  Aktualnie przekazywany jest:

  1. kompletny System OMEGA-PSIR,

  1. moduł optymalizacji koszyka osiągnięć na potrzeby ewaluacji,

  1. moduł komunikacji z PBN i POL-ONem,

  1. Wszystkie moduły komunikacji zewnętrznej (za wyjątkiem płatnego API WoS ,  płatnego DataCite, płatnego ORCID  - płatne moduły wymagają wykupienia  w WoS, DataCite lub ORCID płatnych subskrypcji i nie muszą być domyślnie instalowane wszystkim, a jedynie zainteresowanym uczelniom).

Nie są przekazywane w chwili obecnej moduły integracji z systemami wewnętrznymi (np. SAP). Są one instalowane w trakcie wdrożeń - w zależności od tego, jakie systemy u danego klienta występują.

Jeśli idzie o inne składowe otoczenia Systemu, które są niezbędne do jego poprawnego działania, a nie są dostarczane w ramach subskrypcji, to jest to oprogramowanie open-source, produkowane przez inne podmioty niż PW czy SAGES. Są to składowe, z których zbudowana jest OMEGA-PSIR (biblioteki), bądź oprogramowanie niezbędne do uruchomienia OMEGA-PSIR. Są to m.in.: MongoDB , serwer Wildfly, serwer Apache, serwer Solr  i wiele innych o mniejszym znaczeniu.  Komponenty te wymagają dostarczania / zainstalowania, ale w sensie prawnym nie są produktem ani SAGES ani PW.