Architektura systemu
- Henryk Rybinski
Analytics
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
Poziom architektury C2
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:
kompletny System OMEGA-PSIR,
moduł optymalizacji koszyka osiągnięć na potrzeby ewaluacji,
moduł komunikacji z PBN i POL-ONem,
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.