MSMaR na ratunek

MSMaR to akronim od „Module, Service, Model and Runtime”, a to z kolei jest nazwą architektury systemów informatycznych, której początkowo poszukiwaliśmy, potem staraliśmy się zdefiniować, a obecnie staramy się wdrażać i używać.

Tytułowy „ratunek” bierze się z tego, że znaczną skalę charakteryzującą duże systemy informatyczne, można postrzegać jako ocean złożoności, w którym można „utonąć” a dobra architektura może dać nam szanse przeżycia, przetrwania i osiągnięcia sukcesu. A więc po kolei:

Module

• system powinien składać się z całkowicie 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.

MSMaR jako architektura nie powstała w oderwaniu od świata zewnętrznego, na jej kształt miało i ma wpływ wiele dostępnych obecnie reguł projektowych, wzorców, technologii, narzędzi. Z najważniejszych należy wymienić: „Oddzielaj to, co zmienne od tego, co niezmienne”, „Przedkładaj kompozycję nad dziedziczenie”, „Dziel i zwyciężaj”, Maven, Jigsaw, Eclipse RCP, EJB, Spring, SOA, MicroServices, MDA, REST. Idąc po linii zgodności z tym, co pisałem we wcześniejszych artykułach, trzeba postawić pytanie o kontekst. Kiedy MSMaR daje więcej korzyści, niż powoduje kosztów, kiedy bilans jej zastosowania jest dodatni. MSMaR jest architekturą dla dużych, rozległych systemów o znacznej złożoności i takich, które pokrywają wiele obszarów merytorycznych, wtedy kiedy mamy duży „ocean”, do „szklanki wody” MSMaR to za duży kaliber.