Architektura warstwowa aplikacji internetowych

Jzef E. Sienkiewicz1,2, Pawe Syty2

1 2

Instytut Informatyki Stosowanej, Pastwowa Wysza Szkoa Zawodowa w Elblgu Katedra Fizyki Teoretycznej i Informatyki Kwantowej, Wydzia Fizyki Technicznej i Matematyki Stosowanej, Politechnika Gdaska

Wstp Historia Internetu i WWW zacza si na przeomie lat osiemdziesitych i dziewidziesitych, jako paszczyzna wymiany informacji pomidzy naukowcami zatrudnionymi w Europejskim Centrum Bada Jdrowych CERN. W prowadzonych tam badaniach z zakresu fizyki wysokich energii brao i bierze udzia wiele osb z rnych krajw. W 1989 fizyk Tim BernersLee przedstawi pomys sieci powizanych ze sob dokumentw opisujcych m.in. projekty i wyniki prowadzonych bada. Pierwszy prototyp takiej sieci, bazujcy na trybie tekstowym powsta dwa lata pniej. W 1999 roku MIT i CERN podpisay porozumienie w celu zaoenia organizacji pod nazw World Wide Web Consortium, dajce pocztek oglnowiatowej sieci, do ktrej pocztkowo doczyy jedynie uniwersytety i firmy z brany informatycznej [1]. Obecnie Internet jest potn sieci czc olbrzymi ilo nowoczesnych i dostarczajcych caego szeregu usug aplikacji WWW uywanych przez indywidualnych klientw, mae i rednie przedsibiorstwa jak rwnie cae koncerny. Niektrzy uwaaj oglnowiatow struktur WWW jako pewnego rodzaju oprogramowanie znajdujce si w poowie drogi pomidzy systemem informatycznym a systemem hipermedialnym [1, 2] . Najwaniejsze cechy takiej hybrydy sprowadzaj si do zarzdzania ustalonymi strukturami danych w bazach danych jak i danymi typowymi dla multimediw, gdzie kompresja i efektywne przesyanie odgrywaj zasadnicz rol. Prcz tego nawet si specjalnie nad tym nie zastanawiajc, wymagamy od aplikacji internetowych uytecznej i na wysokim poziomie grafiki oraz aktywnego wspomagania naszych dziaa. Wraz z nowym znaczeniem Internetu i aplikacji webowych ronie te potrzeba rozwoju efektywnych metod wytwarzania tych aplikacji. Co prawda uywa si tutaj tych samych technologii jak przy budowie innych produktw inynierii oprogramowania, jednak pewne specyficzne wymagania, jak wyjtkowo silny nacisk na szybkie dostarczanie prototypw, a pniej oczekiwania niezawodnego dziaania w cigu penych 24 godzin na dob powoduj, e pewne podejcia inynierii oprogramowania jak budowanie przyrostowe i korzystanie ze wzorcw architektonicznych s bardzo pomocne [3, 4]. W szczeglnoci gotowe wzorce architektoniczne lub ich zrby znacznie przyspieszaj przejcie do nastpnych etapw budowy oprogramowania. Uatwiaj te szacowanie kosztw wytwarzania aplikacji metodami od ogu do szczegu (np. przy uyciu metody COCOMO) i od szczegu do ogu po rozpisaniu zada dla czonkw zespou. W dalszym toku prac, te oszacowania staj si podstaw realistycznego harmonogramu przedsiwzicia. W pracy przedstawiono wybrane abstrakcyjne podejcie do wzorcw architektonicznych opartych o modele warstwowe. W zalenoci od przeznaczenia aplikacji internetowej, a tym samym jej zoonoci, s modele dwu-, trzy- i czterowarstwowe.

1. Podstawowe pojcia i przykady nowoczesnych aplikacji internetowych WWW (ang. World Wide Web) - architektoniczna podstawa dostpu do powizanych ze sob dokumentw umiejscowionych na komputerze podczonym do Internetu. Kady taki dokument nosi nazw strony WWW. URL (ang. Uniform Resource Locator) schemat jednoznacznego identyfikowania adresw komputerowych (IP), co w przypadku systemw rozproszonych posiada fundamentalne znaczenie. Odpowiedzi systemu na wezwania poszczeglnych obiektw pozwalaj na ich jednoznaczn identyfikacj. URL jest szczeglnym przypadkiem nadrzdnego standardu identyfikowania dokumentw w sieci URI (ang. Uniform Resource Identifier). HTML (ang. HyperText Markup Language ) suy do pisania dokumentw, zawiera instrukcje formatowania na podstawie ktrych przegldarka przetwarza zawarto dokumentw oraz wie je z innymi dokumentami. Rozwj HTML -a jest nierozcznie zwizany z rozwojem przegldarek. HTML najpierw zawiera jedynie instrukcje dotyczce sposobw prezentacji dokumentw. Obecnie pod nazw XHTML oprcz wszystkich opcji HTML-a kryj si inne wyspecjalizowane znaczeniowo jzyki. HTTP (ang. TyperText Transmission Protocol) jest protokoem komunikowania si pomidzy stronami WWW, pozwala on komputerowi klienta zada przesania danych i dokumentw znajdujcych si na serwerze. Najczciej uywanymi operacjami s Get, ktra umoliwia przesyanie danych z wybranego adresu URL, oraz Post, umoliwiajca przesyanie danych do wybranego adresu URL. Google Docs przeszukuje strony WWW w celu znalezienia danych sw kluczowych, wspomaga przetwarzanie tekstw, ktre przechowuje w odpowiednich formatach na serwerach Googlea. Teksty s zrnicowane pod wzgldem rnego stopnia udostpniania innym uytkownikom. Wikipedia staa si jedn z najpopularniejszych stron WWW i obecnie stanowi rdo wielu poytecznych informacji od cile naukowych do wszelkich biecych. Zasadnicz cech Wikipedii jest to, e jest redagowana przez swoich uytkownikw. Flickr jest stron WWW umoliwiajc wymian fotografii. Zasada rozwoju jak w Wikipedii, im wicej uytkownikw tym wikszy rozwj strony. Nasza Klasa jako forum wymiany informacji pomidzy zainteresowanymi uytkownikami. Swj sukces zawdzicza pomysowi. Przestrze utworzona przez jednego uytkownika jest otwarta dla innych. Allegro serwis aukcyjny, umoliwiajcy handel towarami i usugami w Internecie.

2. Model architektoniczny aplikacji WWW dla systemu klient-serwer Architektura systemu klientserwer opiera si na dwch zbiorach obiektw rozproszonych czyli serwerach [5], ktre oferuj rne usugi i klientach, ktrzy z tych usug korzystaj. Klienci znaj adresy potrzebnych im serwerw. Na rys. 1 pokazalimy ogln warstwow architektur systemu klient-serwer z dwoma rnymi podziaami warstw na procesy klienta i serwera. Najbardziej wewntrzna warstwa odpowiada wszystkim operacjom serwera wykonanym na bazie danych. Warstwa rodkowa jest odpowiedzialna za takie przetwarzanie danych, aby mogy by przeniesione do zewntrznej warstwy w celu ich prezentacji na monitorze klienta. Warstwa zawierajca oprogramowanie przetwarzajce moe nalee do serwera (por. lewa strona rysunku) lub do klienta (por. prawa strona rysunku). Mamy wtedy odpowiednio do czynienia z modelem tzw. klienta cienkiego lub klienta grubego.

Klient

Prezentacja Przetwarzanie Dane

Serwer

Klient

} Serwer

Rys. 1 Reprezentacja warstwowa modelu klient-serwer z rnymi podziaami warstw pomidzy klientem a serwerem

Pomimo cigego rozwoju, podstawowe zasady dziaania modelu klient-serwer pozostaj praktycznie bez zmian. czy on rozproszone obiekty speniajce tradycyjne funkcje klientw lub serwerw, przy czym moliwa jest czsta zmiana tych funkcji bd te jednoczesne penienie obu. Obecnie, coraz czciej aplikacje oparte o model cienkiego klienta ustpuj powoli modelowi klienta grubego. Powoli odchodzi si od klienta wyposaonego jedynie w przegldark, ktra otrzymuje dane gotowe do prezentacji, a ktre ju poprzednio zostay przetworzone przez serwer. W tym przypadku oprogramowanie klienta suy jedynie do interpretacji HTML-a. Jednake coraz wiksze obcienie serwerw i zwizany z tym niedogodnoci powoduj przechodzenie w kierunku modelu klienta grubego. Szczegln tutaj rol odgrywa rozwj jzyka JavaScript, umoliwiajcego dokonanie szeregu operacji po stronie klienta a wykorzystywanych dotychczas po stronie serwera i jednoczenie pozwalajcego na rozwj interakcji. Ponadto, rozwj nowych technologii opartych na jzyku JavaScript jak np. AJAX (ang. Asynchronous JavaScript and XML) pozwala na przeprowadzanie szeregu operacji w tle na komputerze klienta, co zapewnia zwikszon pynno interakcji z serwerem oraz dostosowanie do indywidualnych potrzeb klienta. Samo dostarczania usug klientowi jest przedstawione na rys. 2 i 3 gdzie wymieniono jedynie przykadowe komponenty aplikacji internetowej. Do ich napisania czsto wykorzystuje si rne jzyki programowania i s one wykonane na rnych maszynach. Wewntrzna warstwa technologiczna (por. rys. 2) oferuje usugi przetwarzanieprzechowywanie i dostarcza kanaw informacyjnych potrzebnych do uruchomienia aplikacji znajdujcych si w wyszej warstwie. Warstwa technologiczna jest oparta o sprzt

komputerowy i specjalistyczne oprogramowanie. Warstwa aplikacji w bezporedni sposb wspomaga warstwy biznesowej i jest realizowana przez oprogramowanie uytkowe (aplikacyjne) [6, 7]. Najbardziej zewntrzna warstwa usugowa bd biznesowa oferuje potencjalnym klientom produkty i usugi majce wpyw na przebieg dotyczcych ich procesw ekonomicznych. Warstw aplikacyjn mona podda dalszej analizie i rozrni dwie podwarstwy (rys. 3), z ktrych jedna jest zbudowana z okrelonych komponentw bd podsystemw, co moe sugerowa przy budowie takiej aplikacji gotowych moduw [8]. Druga warstwa reprezentuje zbir interfejsw do tych komponentw, przez ktre nastpuje moliwo dostarczania usug zainteresowanym klientom.

Usugi

(3)

Aplikacje

(2)

Technologie

(1)

Rys. 2 Oglny model warstwowy serwisu internetowego: (1) warstwa technologiczna, (2) warstwa aplikacyjna, (3) warstwa usugowa

Interfejs uytkownikw
(2b)

komponent 1

komponent 2

komponent 3

(2a)

Rys. 3 Podzia warstwy aplikacyjnej z rys. 2 na warstw komponentow (2a) i warstw interfejsu uytkownikw (2b)

3. Wymagania funkcjonalne i niefunkcjonalne. lady wymaga w planach testw Wymagania funkcjonalne zale w cisy sposb od przeznaczenia aplikacji, ktre mog by typowymi aplikacjami do zarzdzania stronami WWW, aplikacjami typu bazodanowego, w tym hurtowniami wiedzy i wczeniej wspomnianymi aplikacjami

biznesowymi. W czasie sporzdzania listy wymaga funkcjonalnych przygotowujemy odpowiednie plany testw zatwierdzajcych, gdzie naley uwzgldni specyfikacje aplikacji internetowych. Mona tutaj wyrni rne modele testw np. testy modeli architektonicznych, testy poszczeglnych komponentw i ich grup czyli podsystemw oraz typowe testy przebiegu procesw [9]. Gwne wymagania niefunkcjonalne wobec aplikacji WWW dotycz takich wasnoci jak efektywno, skalowalno, kompatybilno, dostpno, uyteczno, bezpieczestwo i ochrona przed ingerencj osb niepodanych. Rwnie tutaj weryfikacja kadego wymagania niefunkcjonalnego prowadzi do sporzdzenia odpowiednich planw testw. Testy sprawdzajce kompatybilno dotycz uruchamiania aplikacji pod rnymi systemami oprogramowania oraz przy wykorzystaniu rnych przegldarek internetowych. Testy dostpnoci sprawdzaj, jakie typy uytecznoci aplikacji s utrzymane przy redukcji konfiguracji sprztowej. 4. Architektoniczne modele warstwowe aplikacji webowych W zalenoci od przeznaczenia systemu naley dobra odpowiedni model warstwowy przygotowywanej aplikacji [10]. Model ten powinien zalee od stawianych wymaga funkcjonalnych. W najprostszym przypadku mamy do czynienia z aplikacj, ktrej zadanie bdzie polegao jedynie na przechowywaniu zawartoci stron WWW z ewentualn ich aktualizacj. Architektura takiej aplikacji jest przedstawiona na rys. 4, gdzie te strony s tworzone i przechowywane w postaci plikw HTML. W przypadku potrzeby aktualizacji stron dokonujemy odpowiedniej modyfikacji tych plikw. Tego rodzaju architektur mona nazwa architektur statyczna i dwuwarstwowa reprezentacja tej architektury jest jak najbardziej odpowiednia.

serwer

k l i e n t

URL

strony WWW
HTTP

HTML

Rys. 4 Dwuwarstwowa architektura aplikacji dostarczajcej strony WWW

W przypadku bardziej rozbudowanych wymaga takich jak dynamiczno stron WWW, zwikszona ich elastyczno i skalowalno, przechowywanie informacji w bazach danych bardziej stosowny jest model trzywarstwowy (rys. 5). Wida tutaj wan rol bazy danych wypeniajcej jedn warstw architektoniczn, ktra moe by posadowiona na oddzielnym serwerze. Trzeba jednak zauway, e mona t warstw i warstw przetwarzania 5

umieci na jednym serwerze. Idea tego typu architektury polega na tym, e dynamiczne strony WWW s za kadym razem tworzone na podstawie informacji przechowywanych w bazie danych.

URL

serwer statyczne strony WWW dynamiczne strony WWW Java Programy CGI pliki ASP hipermedia inne usugi

serwer

k l i e n t

HTTP

bazy danych

HTML

Rys. 5 Trzywarstwowa architektura aplikacji do przetwarzania danych

Warstwa przetwarzania odbiera zgoszenia (czyli np. adres URL) od przegldarki WWW umieszczonej po stronie klienta. W przypadku strony statycznej zapisanej w postaci jzyka HTML, po prostu odsya j do przegldarki, a w przypadku zoonych serwisw najpierw nastpuje proces generowania strony. Najczciej odbywa si to poprzez wypenienie wczeniej przygotowanych szablonw HTML odpowiedni treci, przy zastosowaniu wybranego skryptowego jzyka programowania (najpopularniejsze: PHP, Python, Ruby, ASP). Dodatkowo, w warstwie tej nastpuje komunikacja z serwerem bazy danych przesanie zapytania, odebranie danych wynikowych, ich obrbka i wygenerowanie na ich podstawie kodu HTML, przesyanego nastpnie do przegldarki. Transmisja pomidzy klientem (przegldark) a warstw przetwarzania odbywa si przy uyciu protokou HTTP. Ostatnia warstwa, w ktrej umieszczona jest baza danych, realizuje otrzymane zapytania (np. przekazane za pomoc jzyka SQL). Gwn zalet architektury trzywarstwowej (inaczej trjwarstwowej) jest to, e pen logik aplikacji (czyli przetwarzanie danych) oraz komunikacj ze stacjami klienckimi moe realizowa wanie wydzielony serwer (czasem nazywany serwerem aplikacji), odciajc w ten sposb serwer bazy danych. Ponadto, serwer aplikacji moe rwnie wspomaga samo zarzdzanie transakcjami bazodanowymi (tak si dzieje np. w platformie Tuxedo). Dla kadej aplikacji naley bardzo starannie rozplanowa podzia zada pomidzy serwery, dziki czemu mona zapewni jej efektywn skalowalno i w przyszoci unikn problemw z wydajnoci. O tym, jak jest to wane, przekonali si w ostatnim czasie twrcy i uytkownicy serwisu Nasza Klasa, ktry wskutek nie zoptymalizowanego podziau zada cigle boryka si z problemem niedostatecznej wydajnoci, mimo ogromnego potencjau serwerw, na ktrych serwis umieszczono. Programici portalu nie przewidzieli tak ogromnej jego popularnoci i nie przerzucili odpowiedniej liczby zada na serwery bazy danych, wskutek czego serwery aplikacji nie s stanie jednoczenie obsugiwa ogromnej liczby jednoczesnych pocze ze stacji klienckich, komunikujc si przy tym z baz danych i otrzymujc z niej gigabajty danych do przetworzenia i wysania klientom. Z kolei serwis Allegro, rwnie popularny jak Nasza Klasa, jest przykadem dobrze zaprojektowanej architektury trzywarstwowej. Jego 6

znakomit wydajno zapewniono poprzez starannie zaprojektowan warstw bazy danych, ktra realizuje wstpn obrbk danych przekazywanych serwerowi aplikacji, odciajc go i tym samym umoliwiajc mu bardzo efektywn komunikacj z klientami. Naley w tym miejscu zauway, e zarwno Allegro jak i Nasza Klasa s posadowione na niemal identycznych platformach sprztowych.

serwer

serwer

serwer

k l i e n t

URL statyczne strony WWW HTTP programy zarzdzajce zleceniami i ich wynikami aplikacje do realizacji zlece i zarzdzania ich wynikami baza danych

HTML generator stron WWW

Rys. 6 Czterowarstwowa architektura aplikacji WWW do celw biznesowych

W przypadku bardziej rozbudowanych webowych aplikacji biznesowych, naley przeznaczy dodatkow warstw na oprogramowanie obsugujce procesy ekonomiczne. Warstw t, zgodnie z rys. 3 mona dodatkowo podzieli na podwarstwy komponentow i interfejsow. W tym sensie nawizuje ona do bardziej klasycznych architektur rozwaanych w tradycyjnej inynierii oprogramowania. W warstwie tej mog si znajdowa bardziej skomplikowane aplikacje biznesowe umoliwiajce sprawne poruszanie si danej firmy w sferze ekonomicznej. W tym przypadku logiczne jest przedstawienie architektury jako modelu czterowarstwowego (rys.6). Wyrane oddzielenie warstwy aplikacji biznesowych od pozostaych warstw pozwala na atwiejsz ewolucj tego typu aplikacji. Np. dodajc pewne oprogramowanie obsugujce procesy biznesowe pozostae warstwy czyli prezentacji, przetwarzania danych i bazy danych pozostaj nie zmienione. 5. Bezpieczestwo warstwowych aplikacji webowych Aby zapewni bezpieczestwo danych w internetowym systemie wielowarstwowym, naley zwrci szczegln uwag na autentykacj i autoryzacj uytkownikw we wszystkich zastosowanych warstwach aplikacji, w szczeglnoci w warstwie bazy danych. Autentykacja polega na identyfikacji oraz weryfikacji uytkownika, autoryzacja za na nadaniu uytkownikowi okrelonych uprawnie. Naley ponadto zapewni transmisj danych midzy warstwami kanaami zapewniajcymi jej poufno, np. przy uyciu protokou SSL (ang. Secure Socket Layer) czy te IPSec. Ju na etapie projektowania naley zwrci szczegln uwag na wraliwe na atak rozwizania i technologie, ktre maj by zastosowane w budowanej aplikacji, w celu minimalizacji ewentualnego zagroenia. Przykadowo, naley starannie przemyle i zaplanowa uycie kodu JavaScript na komputerze klienckim. Z jednej strony jest on bardzo prosty do przechwycenia (nie powinien zawiera wic jakichkolwiek 7

informacji zwizanych z bezpieczestwem systemu nazw uytkownikw czy te hase), z drugiej za strony moe zosta uyty do wstrzyknicia niepodanego kodu do serwera aplikacji (np. za porednictwem formularza). Podobnie, le zaprojektowany i zaimplementowany kod PHP moe zosta uyty do uzyskania nieuprawnionego dostpu do informacji przechowywanych w bazie danych. Podsumowanie W pracy przedstawilimy trzy podstawowe wzorce architektoniczne dla aplikacji webowych. Uyty abstrakcyjny model warstwowy zosta przedstawiony dla trzech rodzajw aplikacji. Pierwsza aplikacja dostarczajca klientowi statyczne strony WWW posiada jedynie dwie warstwy. Bardziej skomplikowana trzywarstwowa architektura aplikacji dostarcza klientowi przetworzone dane przechowywane w warstwie bazodanowej. Wyrniamy tutaj trzy warstwy: prezentacji, przetwarzania i bazy danych. Najbardziej skomplikowany wzorzec czterowarstwowy jest przeznaczony do projektowania aplikacji webowych majcych na celu wspomaganie procesw ekonomicznych w firmach. Tutaj dodatkowa warstwa jest przeznaczona na oprogramowanie sterujce procesami ekonomicznymi.

Spis literatury [1] M. Jazayeri, Some Trends in web Application Development, Future of Software Engineering (FOSE07) [2] A. E. Hassan and R. C. Holt, Architecture Recovery of Web Applications, Software Architecture Group (SWAG) Department of Computer Science University of Waterloo, Canada [3] C. Standing, Methodologies for developing Web applications, Information and Software Technology 44 (2002) 151 [4] G. Neumann and U. Zdun, High-level design and architecture of an HTTP-based infrastructure for web applications, Word Wide Web 3 (2000) 13 [5] Sommerville, Inynieria oprogramowania, WNT, Warszawa (2003) [6] R. Kempkens, P. Rosch, L. Scott, J. Zettel, A multi-layer multi-view architecture for software engineering environments, Information and Software Technology 42 (2000) 141 [7] M. M. Lankhorst, Enterprise architecture modelling-the issue of integration, Advanced Engineering Informatics 18 (2004) 205 [8] C. Atkinson, Ch. Bunse and H.-Gerhard Grob, T. Kuhne, Towards a General Component Model for Web-Based Applications, Annals of Software Engineering 13 (2002) 3569 [9] G. A. Di Lucca, A. R. Fasolino, Testing Web-based applications: The state of the art and future trends, Information and Software Technology 48 (2006) 1172 [10] Li Jing-Feng, Li Yan, Chen Ping, A Unifield Architecture Model of Web Applications, Journal of Shanghai University (English Edition), 6 (2002) 221