Architektura
Streamsoft Verto „stworzony” na platformie Streamsoft Next jest systemem wielowarstwowym. Powszechnie wiadomo, że warstwy są dobre. System składa się z trzech głównych warstw fizycznych:
- Warstwa danych
- Warstwa logiki biznesowej
- Warstwa prezentacji
Komunikacja pomiędzy warstwą biznesową a warstwą danych jest bardzo wydajna i odbywa się przy użyciu bibliotek i protokołów komunikacyjnych dostarczanych przez producentów baz danych. Dużo ciekawsza jest komunikacja pomiędzy warstwą logiki biznesowej a warstwą prezentacji. Tu używany standardowych protokołów internetowych HTTP, HTTPS. Konsekwencje są oczywiste, nie ma potrzeby używania terminali, protokołu RDP, system staje się wprost systemem internetowym.
Oprócz warstw, dzielących system w poziomie, platforma Streamsoft Next, narzuca korzystanie z dwóch stosów technologicznych, w formie podziału systemu zgodnego z innowacyjnym paradygmatem CQRS na stos komend i stos zapytań. Zastosowanie podejścia CQRS poprawia architekturę systemu i porządkuje ją pod względem odmiennej specyfiki przetwarzania dla każdego z tych typów zadań oraz wpływa na zwiększenie skalowalności warstwy danych i warstwy przetwarzania.
MSMaR
MSMaR to akronim od „Module, Service, Model and Runtime”, a to z kolei jest nazwą naszej autorskiej architektury systemowej. Główne założenia tej architektury to:
Module
- System powinien składać się z odseparowanych modułów
- Granice modułów powinny być wyznaczone poprzez zamknięty i kompletny zakres funkcjonalny
- Moduły powinny dostarczać na zewnątrz wyłącznie serwisów i modeli
Service
- Cała funkcjonalność systemu w zakresie realizacji zadań powinna być realizowana w postaci usług
- Każda usługa posiada jasno zdefiniowany interfejs, stanowiący kontrakt
- Dostęp do usług powinien być zunifikowany i oparty o uniwersalne protokoły
Model
- System powinien jasno definiować własne, dziedzinowe komponenty składowe
- System dla swoich komponentów powinien definiować klasy oraz uporządkowany zbiór instancji, stanowiących łącznie model komponentów systemu
- Model systemu powinien być publiczny
- Model systemu powinien być rozszerzalny zarówno o nowe instancje, jak i klasy
Runtime
- System powinien posiadać przynajmniej jednego interpretatora modelu („runtime”)
- „Runtime” powinien dostarczać systemowi kształtu wyłącznie na podstawie modelu
- „Runtime” powinien dostarczać systemowi funkcjonalności wyłącznie na podstawie modelu i dostępnych usług
- „Runtime” powinien być rozszerzalny
Umów bezpłatną prezentację systemu
Podczas prezentacji pokażemy jak system działa w praktyce.
Przedstawimy rolę narzędzia w skutecznym zarządzaniu procesami w Twojej firmie. Powiemy m.in. o możliwościach startowych ERP oraz opcji tworzenia dedykowanych rozwiązań – dla branży czy konkretnego procesu.
