Projektujesz kolejny system internetowy w architekturze wielowarstwowej? Obiecujesz sobie, że tym razem wszystko będzie uporządkowane i przemyślane? W głowie klarują się Tobie pakiety i komponenty i wszystko ma swoje miejsce dopóki nie przyjdą ludzie z biznesu i wywrócą świat do góry nogami?

Okazuje się, że w przypadku większości systemów internetowych pewne ramy architektoniczne są powtarzalne i nie ma co odkrywać koła na nowo zaczynając kolejny projekt. Niezależnie, czy budujemy system rezerwacji, portal internetowy, system obiegu dokumentów, system bankowości elektronicznej, to część elementów pozostaje na pewnym poziomie ogólności wspólnych dla każdego z nich. W tym wpisie pomiędzy trzecią, a czwartą kawą spróbujemy zidentyfikować owe wspólne elementy i przedstawić propozycję bibliotek do ich realizacji w środowisku Java / J2EE.

Słowem wstępu, nawiązujac do wystąpienia Teda Newarda na 33-rd degree w Warszawie dla każdego projektanta systemów informatycznych znajomym jest obrazek poniżej, czyli uniwersalna architektura systemów internetowych.

Rys. 1 Uniwersalna architektura aplikacji warstwowej

Oczywiście zgodnie z obowiązującymi trendami w IT powyższy obrazek transformuje się do takiego gdzie kwadraty i walce zastąpuje się wszechobecną chmurą, która jest znacznie bardziej elastyczna, ale też i efemeryczna.

Rys. 2 Uniwersalna architektura aplikacji warstwowej w chmurze

Na szczęście zanim zrobimy pierwszy krok w chmurach, warto jest nauczyć się stąpać twardo po ziemi. W tym celu spróbujmy określić z jakich komponentów w ujęciu o jeden poziom szczegółowości wyżej składa się typowa aplikacja internetowa.

Widok logiczny komponentów

Rys. 3 Wspólna architektura typowej aplikacji warstwowej

Frontend – warstwa odpowiedzialna za logikę obsługującą warstwę prezentacji

• User Interface  – realizuje logikę związaną z obsługą warstwy prezentacji dla użytkownika – zazwyczaj zgodnie ze wzorecem MVC

• Integration Gateway – udostępnia usługi i wywołuje usługi dla systemów zewnętrznych (najczęściej opartych o WebServices takie jak SOAP/REST etc.)

• Admin Interface – realizuje logikę związaną z obsługą warstwy prezentacji dla administratora

Backend – warstwa odpowiedzialna za logikę obsługującą warstwę logiki aplikacyjnej

• Commons – obsługuje wspólną logikę – np. obsługa list wartości, obsługa komunikatów , obsługa parametrów systemowych

• Scheduler – odpowiada za procesy uruchamiane cyklicznie

• Security Management – odpowiada za zarządzanie uprawnieniami i uwierzytelnianiem

• Workflow & Process Management – pozwala na uruchamianie długotrwałych procesów z koniecznością utrzymania stanu i interakcją z użytkownikiem

• Domain Specific Components – wszystkie komponenty wymagane do realizacji logiki specyficznej dla aplikacji – dla przykładu rezerwacja miejsc w kinie, obsługa płatności, obsługa zamówień

• Persistance – komponent odpowiedzialny za utrwalanie i dostęp do obiektów

Database – relacyjna baza danych

Bardzo istotnym, aczkolwiek oczywistym, jest założenie, że komunikacja zawsze odbywa się w jednym kierunku i unikamy cyklicznych zależności między poszczególnymi komponentami. Dodatkowo komponenty posiadają również architekturę warstwową dzieląc się na fasadę, domenę, logikę i dao.

Czasami można dodać do powyższego zestawu kilka dodatkowych komponentów:

• Reporting – do generowania raportów on-line (np. przy użyciu Jesper Reports)

• Notification – do wysyłania różnego rodzaju powiadomień (e-mail, sms)

• Export/Import – przetwarzanie danych wsadowych i eksport danych

• Attachments – w celu składowania załączników powiązanych z danymi operacynymi

• File Transfering – dla przesyłania eksportowanych i importowanych danych via FTP/SFTP/SCP (chociaż  tu lepiej posłużyć się rozwiązaniami dedykowanymi)

Widok osadzania w kontekście bezpieczeństwa

Rys. 4 Widok osadzania w kontekście bezpieczeństwa typowej aplikacji wielowarstwowej

Red Zone – świat jest niebezpieczny – nie ufamy żadnemu połączeniu i wywołaniu – stosujemy najwyży poziom kontroli dla komunikacji – każda operacja jest dodatkowo autoryzowana – komunikujemy się z otwartym i wrogim internetem.

Blue Zone – świat jest bezpieczniejszy – sprawdzamy połączenia, ale możemy np. nie weryfikować uprawnień dla każdego wywołania.

Green Zone – świat jest bezpieczny – komunikacja może być bez dodatkowych metod uwierzytelniania i szyfrowania

Każdy ze wskazanych komponentów może być klastrowany, rozlokowany razem / osobno, ale istotnym założeniem jest, że w ramach każdej warstwy logicznej jak również strefy bezpieczeństwa maszyny są odseparowane fizycznie.

Kolejnym założeniem jest, że komunikacja pomiędzy strefami bezpieczeństwa jest rozdzielona i kontrolowana przez dedykowane urządzenia sieciowe / bezpieczeństwa typu FireWall i IDS.

Technologie

Poniżej przykładowy dobór technologii dla realizacji wyżej proponowanej architektury przy użyciu oprogramowania w języku Java na licencji OpenSource.

Frontend

• User Interface – jQuery i Apache Tapestry 5/JSF2 J2EE , Spring MVC

• Integration Gateway – Apache CXF i HornetQ

• Admin Interface – jQuery i Apache Tapestry 5, Spring MVC

Backend

• Scheduler – Quartz/Java Scheduler J2EE

• Security Management – Spring Security

• Workflow & Process Management – Activiti

• Persistence – JPA/EclipseLink

Do komunikacji między poszczególnymi komponentami możemy posłużyć się EJB w ramach J2EE.

Podsumowanie

Oczywiście nie ma czegoś takiego jak uniwersalny młotek, którym da się wbić wszystkie gwoździe i śrubki. ;-)

Z drugiej strony budowanie systemów nie rózni się tak bardzo od budowania domów, tzn. każdy dom ma fundament, ściany i dach, tak i prawie każda aplikacja internetowa ma interfejs użytkownika, dostęp do bazy danych etc. Oczywiście tak jak nie znajdziemy dwóch takich samych domów, tak też nie ma dwóch jednakowych systemów informatycznych.

Projektując rozwiązanie warto sięgnąć do sprawdzonych wzorców architektonicznych zamiast wymyślać je kolejny raz od zera.