Architektura aplikacji internetowej

Omawiane zagadnienia:

- kontener
- nazwy serwletu
- deskryptor rozmieszczenia
- wzorzec projektowy MVC

Kontener

- tworzenie egzemplarza serwletu, wywołanie wątku obsługującego nowe żą-
danie, wywoływanie metody doPost, doGet - zarządzanie życiem, śmiercią i
zasobami serwletu

Przykład: Tomcat

Co zrobić, jeśli mamy odpowiedni kod Javy, ale nie mamy ani serwletów,

ani kontenerów?

Czyli mamy tylko standardowe biblioteki J2SE. Przyjmujemy wtedy, że

możemy tak skonfigurować aplikację serwera WWW, aby wywołał on naszą
aplikację napisaną w Javie.

Co daje kontener?

1. Obsługa komunikacji (między serwletami a serwerem). Kontener zna
odpowiedni protokół porozumiewania się z serwerem WWW, więc nasze
serwlety nie muszą się martwić o zapewnienie interfejsu API pomiędzy np.
serwerem Apache a kodem naszej aplikacji internetowej.
2. Zarządzanie cyklem życia. Wczytywanie niezbędnych klas, tworzenie
egzemplarzy i inicjalizację serwletów, wywoływanie metod oraz przystosowanie
serwletów do współpracy z mechanizmami odśmiecania pamięci. My nie tra-
cimy na to czasu.
3. Obsługa wielowątkowości. Automatyczne tworzenie nowego wątku Javy.
Po zakończeniu wykonywania metody serwlet zamyka odpowiedni wątek.
Uwaga: nie możemy zapominać o synchronizacji.
4. Bezpieczeństwo deklaratywne. Stosowanie deskryptora rozmieszczenia,
który konfiguruje i modyfikuje mechanizmy zabezpieczeń bez konieczności
trwałego umieszczania odpowiednich instrukcji w kodzie klasy serwletu.
5. Obsługa JSP. Tłumaczenie kodu JSP do postaci właściwego kodu pro-
gramowania.

1

Jak kontener obsługuje żądanie http?

2

Jak kontener znajduje odpowiedni serwlet?
Adres URL, który dociera do serwera WWW jako część żądania klienta,

jest w jakiś sposób odwzorowywany na odwołanie do konkretnego serwera.
To odwzorowanie może się odbywać na wiele sposobów - jest to jedno z
podstawowych zagadnień.

Serwlet może mieć aż 3 nazwy.

- nazwa ścieżki do pliku klasy (konieczna). Twórca wybiera nazwę, reszta
zależy od położenia pliku klasy na serwerze.
- nazwa wdrożenia (poufna nazwa wew.) - może być taka jak nazwa ścieżki,
ale nie musi
- publiczna nazwa URL - o niej wie klient, jest kodowana w HTML

Dlaczego nie opłaca korzystać z jednej, prawdziwej i jednoznacznej nazwy

pliku?

Przy reorganizacji aplikacji nie musimy wyszukiwać i aktualizować kodu

klienta, użytkownicy nie znają całej struktury katalogów - bezpieczeństwo.

Deskryptor rozmieszczenia

Dokument tworzony podczas wdrażania serwletu. Zawiera dwa elementy - za
ich pomocą definiuje odwzorowanie adresów URL na serwlety:
<servlet> - odwzorowuje nazwę wewnętrzną do postaci w pełni kwalifikowanej
nazwy
<servlet-mapping> - odwzorowuje nazwę wewnętrzną w publiczną nazwę
ULR

Także: dostosowanie innych aspektów aplikacji internetowej np. bezpie-

czeństwo, strony o błędach, biblioteki znaczników, informacje o konfiguracji
początkowej itp. Uwaga: możemy modyfikować aplikację na poziomie des-
kryptora zamiast w kodzie źródłowym (bez kompilacji :-) ).

Zalety deskryptora:

1. Minimalizuje liczbę operacji na kodzie źródłowym, który przeszedł niez-
będne testy.
2. Umożliwia nam dostosowanie możliwości aplikacji (bez dostępu do kodu
źródłowego)
3. Dostosowanie do różnych zasobów (m.in. baz danych) bez konieczności
ponownego kompilowania i testowania
4. Ułatwia zarządzanie dynamicznymi regułami bezpieczeństwa.
5. Osoby nie będące programistami mogą modyfikować i wdrażać aplikacje
same.

3

Bob buduje witrynę randkową

- zna kilka pojęć, niektóre konstrukcję języka Java, poczytał trochę o serw-
letach
- tworzy wiele osobnych serwletów, każdy generuje i obsługuje jedną stronę
- wywoływania metody println() irytowały, poczytał więc o JSP i przemode-
lował aplikację: serwer realizuje teraz odpowiedni fragment logiki biznesowej
(np. zapytania do bazę danych), po czym przekazuje żądanie do odpowiedniej
strony JSP, która wygeneruje stronę html. Oddzielił zatem logikę biznesową
od prezentacji.
- co z uzyskaniem dostępu do serwisu randkowego z poziomu innej aplikacji?
Wzorzec projektowy MVC - logika biznesowa nie wie, że istnieje prezentacja
(o tym niżej)
- pytanie o jeden serwlet - na razie bez odpowiedzi

Wzorzec projektowy MVC (Model - Widok - Kontroler)

Wyciągnięcie logiki biznesowej poza serwlet i umieszczenie jej w ”Modelu”,
czyli starych prostych klasach Javy przeznaczonych do wielokrotnego użytku.
Nigdy nie należy zakładać, że nasza logika biznesowa będzie udostępniana
wyłącznie za pośrednictwem stron WWW, dlatego podział odpowiedzialności
jest tak istotny.

4

Widok:

Odpowiada za prezentację. Otrzymuje od Kontrolera stan modelu (przekazy-
wanie stanu nie odbywa się jednak bezpośrednio - Kontroler umieszcza dane
modelu w miejscu, z którego dane te mogą być odczytane przez Widok).
Widok jest także tą częścią aplikacji, która pobiera zwracane do kontenera
dane wejściowe użytkownika.

Kontroler:

Pobiera żądane dane wejściowe od użytkownika i określa, co te dane oznaczają
dla bieżącego modelu. Nakazuje modelowi samoaktualizację i sprawia, że stan
nowego modelu jest dostępny dla widoku (w tym przypadku stron JSP).

Model:

Przechowuje rzeczywistą logikę biznesową oraz stan aplikacji. Innymi słowy,
zna reguły uzyskiwania i aktualizowania tego stanu. Częścią Modelu we
wzorcu projektowym MVC będzie np. zawartość koszyków z zakupami (wraz
z regułami określającymi możliwe działania na tej zawartości). Model jest
jedyną częścią systemu współpracującą z bazą danych (chociaż w wielu przy-
padkach wykorzystuje się inny obiekt do faktycznej komunikacji z bazą danych
- omówienie tego wzorca później).

5