Wykłady > Wzorce projektowe 2 > Wielopoziomowa architektura aplikacji

9.9 Wielopoziomowa architektura aplikacji



Pisanie aplikacji działających na serwerze wymaga wzięcia pod uwagę wiele czynników, przede wszystkim w środowisku wielozadaniowym liczą się :
  • Niezawodność;
  • Bezpieczeństwo;
  • Wydajność.
Klientami takich systemów są na przykład banki, agencje ubezpieczeniowe, serwisy informacyjne oraz internetowi doradcy. Znając zakres działalności tych firm, staje się jasne, jak trudno napisać dobrą aplikację, spełniającą wcześniej wymienione czynniki.

Każda dobrze napisana aplikacja posiada logiczny podział kodu na warstwy. Każda z warstw ma swoje osobne zadanie w gotowej aplikacji. Z kolei poszczególne warstwy składają się z jednego lub kilku komponentów programistycznych. Podział kodu na warstwy jest bardzo wydajnym sposobem, gdyż każda z nich realizuje oddzielne funkcje wykonywane przez system. Poniżej przedstawiono typowy podział aplikacji na warstwy.

Warstwa prezentacji: zawiera komponenty odpowiedzialne za wygląd aplikacji na monitorze klienta. Prezentacja sieciowa może składać się ze stron WWW, wykorzystujących techniki: JSP, ASP, PHP, serwlety oraz applety języka Java.

Warstwa logiczna: zawiera komponenty zajmujące się rozwiązywaniem konkretnych problemów programistycznych. Wymagania względem tych komponentów są największe. Najczęściej komponenty implementowane są językach Java lub C++.

Warstwa danych: warstwa wykorzystywana przez warstwę logiczną do zachowywania informacji. Najczęściej warstwa ta składa się z systemów baz danych.


Podział aplikacji na warstwy pozwala na odizolowanie każdej z nich, tak aby zmiany dokonywane w jednej z nich miały jak najmniejszy wpływ na pozostałe. Projektowanie aplikacji z uwzględnieniem warstw umożliwia bardzo efektywne ich modyfikowanie, co jest istotną zaletą w systemach e-biznesowych.

Znając logiczny podział systemów na warstwy, pojawia się problem jak fizycznie stworzyć aplikację o architekturze wielopoziomowej. Istnieją dwie główne metody tworzenia tego rodzaju aplikacji:
  • metoda dwupoziomowa (ang. Two-tier),
  • metoda trójpoziomowa (N-tier),
Granicami rozdzielającymi warstwy mogą być granice procesu, maszyny lub korporacji. Nie jest istotne, które z nich będą zastosowane ważna jest użyta technologia.

Architektura dwupoziomowa

W tego typu architekturze wyróżnić można dwa rodzaje aplikacji. Pierwsza z nich łączy warstwę logiczną z warstwą prezentacji, natomiast druga niektóre elementy warstwy logicznej przesuwa na stronę warstwy danych.

Łączenie warstwy logicznej z warstwą prezentacji

W tym rozwiązaniu część logiczna jest oddzielona od warstwy danych. Połączone warstwy tworzą jedną całość. W tego rodzaju aplikacji typu klient-server, zasadnicza część sytemu (warstwa logiczna i prezentacji) zgromadzona jest po stronie klienta, z tego też powodu przyjęło się mówić, że klient jest gruby (ang. fat), a serwer szczupły (ang. thin). Na Rysunku 9.9.1. przedstawiono schemat takiego rozwiązania.


Rys. 9.9.1 Architektura dwupoziomowa typu gruby klient

Architektura ta charakteryzuje się kilkoma niepożądanymi cechami:
  • wysokie koszty instalacji, każda maszyna klienta musi zostać wyposażona w sterownik baz danych,
  • aktualizacja sterowników jest kosztowna, zmiana sterowników baz danych wymaga zmiany sterowników na każdej maszynie,
  • zmiana schematu bazy danych jest kosztowna, klienci korzystają bezpośrednio z bazy danych,
  • wysokie koszty zmiany motoru baz danych,
  • wysokie koszty związane z aktualizacją warstwy logicznej na każdej maszynie klienta,
  • spadek wydajności sieci, generowanych jest duży ruch na łączach, każde żądanie od klienta musi "przejść" przez granicę oddzielającą warstwę logiczną i danych.

Łączenie warstwy logicznej z warstwą danych

Takie rozwiązanie pozwala ominąć wiele wad występujących w rozwiązaniu omówionym powyżej.

Zasadniczą zaletą przesunięcia części warstwy logicznej na stronę danych, jest zmniejszenie obciążenia sieci. Przechowywane procedury po stronie danych pozwalają wykonać naraz kilka zapytań i oddać wynik w postaci jednego zbioru rekordów, co wydatnie zwiększa wydajność.

Zwiększono skalowalność instalacji aplikacji.

Niestety, w dalszym ciągu istnieją problemy związane z instalacją części warstwy logicznej po stronie klienta. Rysunek 9.9.2. pokazuje realizację takiej architektury.


Rys. 9.9.2 Architektura dwupoziomowa, połączenie logiki z danymi

Architektura wielopoziomowa

Obecnie najefektywniejszym rozwiązaniem jest fizyczne oddzielenie poszczególnych warstw logicznych aplikacji. Rozwiązanie trójpoziomowe sprowadza się do zainstalowania po stronie klienta jedynie interfejsu obsługującego pozostałe warstwy. Z tego też powodu mówi się o tzw. Cienkim kliencie (ang. thin). Logika aplikacji oraz dane zostają zgromadzone po stronie serwera. Rysunek 9.9.3. przedstawia uproszczoną architekturę trójpoziomową.


Rys. 9.9.3 Architektura trójpoziomowa typu cienki klient

Zalety projektowania aplikacji trójpoziomowych:

Redukcja kosztów kupna i instalacji, sterowniki baz danych i jądro aplikacji jest instalowane po stronie serwera. Zmniejsza się nakład pracy.

Aktualizacja systemu baz danych lub warstwy logicznej jest znacznie uproszczona. Klient nie korzysta bezpośrednio z bazy danych co pozwala na migrację i zmianę bazy danych bez wiedzy, i potrzeby zmiany interfejsu po stronie klienta.

Zwiększenie bezpieczeństwa systemu poprzez zastosowaniu usługi firewall. Dzięki temu można ograniczyć dostęp do zasobów aplikacji znajdujących się po stronie chronionej.

Zasoby serwera mogą być udostępniane przez tzw. pulę zasobów (ang. resource pooling). Pula zasobów jest mechanizmem wydatnie zwiększającym wydajność aplikacji.

Zastosowanie jej do baz danych zmniejsza ilość jednoczesnych połączeń z motorem bazy i pozwala zmniejszyć ilość licencji dla klientów.

Każda warstwę można zmieniać niezależnie od pozostałych.

Proste monitorowanie działania systemu. Łatwo zlokalizować wystąpienie błędów krytycznych lub tzw. wąskich gardeł (ang. bottleneck). Obciążenie jednej z warstw nie wpływa na pozostałe.

Niedogodności aplikacji trójpoziomowych:

Duże obciążenie komunikacji. Fizyczne rozdzielenie warstw wymusza dodatkowe sposoby komunikowania się między nimi. W efekcie czego w sieci generowany jest nadmiar informacji przesyłanych między poszczególnymi maszynami, sieciami lub procesami wykonującymi zadania.

Zwiększone koszty utrzymania aplikacji.

Większa ilość kodu do napisania przez programistę.

Ostatnia z wymienionych wad wiąże się z konieczności zaimplementowania komunikacji pomiędzy warstwami. Dodatkowo wymagany jest moduł autoryzacji użytkowników, oprogramowanie wielozadaniowości oraz monitorowanie i wysyłanie komunikatów do administratora w razie wystąpienia nieprawidłowego stanu aplikacji.

Wszystkie wymienione wyżej zadania są bardzo pracochłonne i kosztowne. Implementowanie dla każdej aplikacji poszczególnych modułów jest bardzo nie efektywne. Z tego też powodu powstały serwery aplikacji.

Serwery Aplikacji - zadania i rola

Serwery aplikacji zwalniają programistów z konieczności pisania modułów obsługujących poszczególne aplikacje. Stanowią platformę, która pozwala bezpośrednio obsługiwać systemy, w szczególności aplikacje e-biznes. Platforma ta pozwala na przechowywanie logiki biznesowej, całego modelu aplikacji dodatkowo oferuje usługi dostępne dla warstwy prezentacji oraz metody dostępu do baz danych. Zadaniem ich jest również zapewnienie integracji z innymi usługami, często dostarczanymi przez inne firmy, takimi jak: serwery WWW, bazy danych. Zasadnicza rola serwerów aplikacji związana jest z:
  • zapewnieniem standardów bezpieczeństwa,
  • przydzielaniem zasobów sieciowych,
  • obsługą wielozadaniowości,
  • obsługą obiektów rozproszonych.
Są integralnym elementem architektury wielopoziomowej - poziom pośredni. Większość dostępnych na rynku serwerów aplikacji głównie wspiera technologię tworzenia programowania opartą na komponentach. W takim przypadku serwer stanowi kontener dla komponentów. W Tabeli 9.9.4. przedstawiono kilka popularnych serwerów aplikacji.


Tabela 9.9.4 Serwery aplikacji


Przejdź dalej



Wykłady > Wzorce projektowe 2 > Wielopoziomowa architektura aplikacji