Praca dyplomowa - magisterska Web frameworks do budowy aplikacji zgodnych z J2EE

99 Pages·2007·1.01 MB·Polish

Wydział Informatyki i Zarządzania
kierunek studiów: Informatyka
specjalność: Systemy Informacyjne
Praca dyplomowa - magisterska
Web frameworks do budowy aplikacji
zgodnych z J2EE
Jacek Panachida
słowa kluczowe:
Spring MVC
JavaServer Faces
internetowe szkielety programistyczne
krótkie streszczenie:
Praca stanowi analizę porównawczą najpopularniejszych internetowych
szkieletów programistycznych dostępnych dla platformy Java. Celem
pracy jest przedstawienie nowoczesnego środowiska pracy dostosowa-
nego do wytwarzania aplikacji internetowych oraz umożliwienie doko-
nania wyboru odnośnie używanej ramy projektowej.
Promotor: dr Dariusz Król
............................................ ...................... .......................
imię i nazwisko ocena podpis
Wrocław 2007
Spis treści
Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Wstęp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Ewolucja szkieletów programistycznych . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1. Historia i rozwój . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.2. Wzorce projektowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.3. Rozwiązania alternatywne . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1. Model 1 – strona JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.2. Model 2 – centralny kontroler . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.3. Model komponentowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3. Zadania szkieletów programistycznych . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Nowoczesne środowisko pracy programisty . . . . . . . . . . . . . . . . . . . . . 22
2.1. Narzędzia integrujące . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1. Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2. Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.3. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4. Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.5. Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2. Narzędzia testujące . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.1. Spring Mock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.2. EasyMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.3. JUnit 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.4. Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3. Przegląd internetowych szkieletów programistycznych . . . . . . . . . . . . . . 43
3.1. Struts 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2. Znaczniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.3. Interceptory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.4. Implementacja wzorca MVC . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.1. Obiekt nadzorujący . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2. Znaczniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.3. Zasada konwencji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3. Tapestry 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1. Zasady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2. Moduły . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.1. Specyfikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.2. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.3. Składowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.4. Implementacja wzorca MVC . . . . . . . . . . . . . . . . . . . . . . . . . 54
4. Porównanie Spring MVC oraz JavaServer Faces . . . . . . . . . . . . . . . . . . 55
1
4.1. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2. Model programistyczny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3. Cykl życia żądania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4. Walidacja i konwersja typów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5. Internacjonalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5. Aplikacja Peclinic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1. Opis aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.1. Wykorzystane technologie . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.2. Encje bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2. Moduły aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1. Petclinic-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.2. Petclinic-core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.3. Petclinic-web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3. Zaimplementowana funkcjonalność . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6. Eksperymenty z wykorzystaniem aplikacji Petclinic . . . . . . . . . . . . . . . 76
6.1. Przebieg badania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.1. Fazy implementacji aplikacji Petclinic . . . . . . . . . . . . . . . . . . . . 76
6.1.2. Badanie wydajności . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.3. Pomiar metryk kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.1.4. Badanie łatwości wprowadzania zmian . . . . . . . . . . . . . . . . . . . 80
6.1.5. Badanie dostępności komponentów Triniad . . . . . . . . . . . . . . . . . 81
6.2. Analiza wyników . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.2.1. Wydajność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.2.2. Metryki kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2.3. Dostępność komponentów Trinidad . . . . . . . . . . . . . . . . . . . . . 88
6.2.4. Łatwość wprowadzania zmian . . . . . . . . . . . . . . . . . . . . . . . . 90
7. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2
Streszczenie
Praca stanowi analizę porównawczą najpopularniejszych internetowych szkieletów
programistycznych o otwartym kodzie źródłowym, dostępnych dla platformy Java.
Celem pracy jest przedstawienie nowoczesnego środowiska pracy dostosowanego do
wytwarzaniaaplikacjiinternetowychorazumożliwieniedokonaniawyboruodnośnie
używanejramyprojektowej.AnaliziezostałypoddaneframeworkiSpringMVCoraz
JavaServer Faces. Uzyskane wyniki bazują na analizie teoretycznej udostępnionych
przez szkielety rozwiązań oraz eksperymentach dokonanych na zaimplementowanej
aplikacji służącej do zarządzania kliniką weterynaryjną. Praca zaleca stosowanie
Spring MVC w tradycyjnych aplikacjach do zarządzania danymi.
Abstract
A comaparative analysis of chosen open source web frameworks for Java platform
is done. The aim of the thesis is to present modern software enviroment designed
for implementing web applications and also to enable making final choice about
web framework, which is to be used in developing web application. The subjects of
the analysis are Spring MVC and JavaServer Faces. The solution of the problem
reliesupontheoreticalanalysisofavailableframeworkfeaturesanduponunderwent
experiments on implemented application designed to support managing pet clinic.
The thesis indicates Spring MVC application in traditional CRUD web systems.
3
Wprowadzenie
Jednym z najpopularniejszych zastosowań języka Java jest tworzenie aplikacji interne-
towych. Początkowo wystarczyły rozwiązania ograniczające się jedynie do zastosowania
serwletów1 w połączeniu ze stronami JavaServer Pages. Szybko okazało się jednak że
wzrastające potrzeby rynku wymagają zastosowania bardziej kompleksowych rozwiązań,
pozwalających na odciążeniu programisty w wielu aspektach związanych z tworzeniem
aplikacji internetowych.
Odpowiedzią na rosnące potrzeby rynku oraz chęci uproszczenia procesu wytwarza-
nia aplikacji internetowych stało się stworzenie wielu tzw. ram projektowych (ang. web
frameworks). Głównym zadaniem stawianym ramom projektowym jest pomoc programi-
ście w tworzeniu, rozwoju i testowaniu powstającej aplikacji. Aktualnie istnieje ponad 40
szkieletów programistycznych z otwartym kodem dostępnych dla platformy Java,2 nowe
wciąż powstają.
Wybór spośród wielu dostępnych ram projektowych nie jest z pewnością prosty. Pod-
czas przeglądu dostępnych opracowań nie napotkałem takiego, które omawia w przedsta-
wionym w pracy zakresie wybrane przeze mnie biblioteki. Niniejsza praca ma za zadanie
ułatwićdokonaniewłaściwegowyborupoprzezprzedstawienieorazporównaniewybranych
szkieletów programistycznych.
Programista stojący przed wyborem nowego narzędzia pracy zwraca uwagę na wie-
le aspektów z nim związanych. Zbiera informacje między innymi na temat dojrzałości,
dostępności wsparcia społeczności czy popularności rozwiązania. Niniejsza praca stanowi
wsparcie w ostatnim stadium podejmowania decyzji, w momencie w którym programista
stoi przed wyborem dwóch spośród nich Spring MVC bądź JavaServer Faces. Poprzez
analizę teoretyczną wsparcia oferowanego przez wspomniane frameworki autor bada ich
przydatność podczas tworzenia aplikacji typu CRUD (ang. create, read, update and dele-
te).
W związku z mnogością dostępnych opcji dokonano zawężenia liczby badanych projek-
tów do aplikacji o otwartym kodzie źródłowym, których licencja jest zaaprobowana przez
organizację Open Source Initiative3. Na ostateczny kształt listy miała również wpływ
popularność wybranej ramy projektowej, jej dojrzałość oraz dostępność mechanizmów
umożliwiających integrację ze Spring Framework4.
Porównanie wybranych ram projektowych zostało dokonane z wykorzystaniem przy-
kładowej aplikacji internetowej zaimplementowanej specjalnie na potrzeby niniejszej pra-
cy magisterskiej. Na jej podstawie został zbadany praktyczny aspekt użycia wybranego
szkieletu programistycznego.
Praca została podzielona na dwie części, poprzedzone wprowadzeniem. Pierwsza z czę-
1 Komponenty działające po stronie serwera. Specyfikacja dostępna na stronie http://java.sun.
com/products/servlet.
2 Dane według serwisu Java-Source.net (marzec 2007) dostępnego pod adresem http://www.
java-source.net.
3 Organizacja zajmująca się promocją oprogramowania open source.
4 Szkielet wytwarzania aplikacji w języku Java dla platformy J2EE.
4
ści opisuje teoretyczną stronę związaną z zastosowaniem i działaniem poszczególnych ram
projektowych. Druga omawia przebieg oraz wyniki badań przeprowadzonych z zastosowa-
niem przykładowej aplikacji.
Rozdziałwprowadzającymazazadaniezapoznanieczytelnikazhistoriąrozwojuszkie-
letów programistycznych, wyjaśnia podstawowe pojęcia wykorzystywane w dalszej czę-
ści pracy. Opisuje stosowane architektury aplikacji internetowych oraz funkcje oferowane
przez ramy projektowe.
Pierwszyrozdziałczęściteoretycznejzostałpoświęconyzagadnieniomzwiązanymzno-
woczesnym środowiskiem pracy programisty aplikacji internetowych z podziałem na na-
rzędzia służące do wytwarzania oraz testowania aplikacji. W kolejnym został dokonany
przegląd czterech popularnych szkieletów programistycznych. W następnym rozdziale po-
równującym wybrane ramy projektowe, Spring MVC oraz JavaServer Faces, zwrócono
uwagę na ich architekturę, model programistyczny, cykl życia żądania bądź zdarzenia
(w przypadku aplikacji opartej o JavaServer Faces), walidację wraz z konwersją typów
wprowadzanych przez użytkownika danych. Ostatnia cześć dotyczy procesu związanego
z lokalizacją aplikacji.
Część praktyczną rozpoczyna opis przykładowej aplikacji internetowej, jej modułów
oraz zaimplementowanej funkcjonalności. Następny rozdział składający sie z dwóch czę-
ści przedstawia trzy fazy implementacji przykładowej aplikacji, sposób przeprowadzenia
eksperymentów oraz wyniki badań wraz ich analizą.
Ostatnią część pracy stanowi podsumowanie badań dwóch wybranych szkieletów pro-
gramistycznych.
Mam nadzieję, iż wysiłek włożony przeze mnie w realizację pracy, pozwoli osobą sto-
jącym przed dylematem wyboru właściwej dla nich ramy projektowej na podjęcie prawi-
dłowej decyzji.
5
1. Wstęp
Niniejszy rozdział stanowi wprowadzenie do tematu szkieletów programistycznych do-
stępnych dla platformy Java. Pierwsza część przedstawia ewolucję oraz rozwój ram pro-
jektowych jak i samych aplikacji internetowych związanych nierozerwalnie z tworzeniem
aplikacji internetowych od początków ich istnienia. Dodatkowo prezentuje alternatywne
rozwiązania internetowe dostępne dla platformy Java. Następny rozdział stanowi prze-
gląd i opis stosowanych architektur programistycznych, wraz z przedstawieniem jedenego
z fundamentalnych wzorców projektowych związanych z internetowymi szkieletami pro-
gramistycznymi, wzorca Model-Widok-Kontroler. W ostatniej z części opisano podstawo-
we funkcjonalności, realizowane przez twórców ram projektowych.
1.1. Ewolucja szkieletów programistycznych
WrazzrozwojemtechnologiWorldWideWebokazałosięiżstatycznieserwowanestro-
ny nie spełniają oczekiwań użytkowników. W odpowiedzi powstawały różnorodne techno-
logie umożliwiające zwiększenie dynamizmu prezentowanej treści. Pierwsze rozwiązania
wykorzystywały interfejs Common Gateway Interface (CGI), w połączeniu z popularny-
mi ówcześnie językami programowania, takimi jak C czy Perl. Niewystarczające interfejsy
programistyczne (API) dostarczane przez wspomniane opcje czy zbyt mała wydajność
działających w ten sposób aplikacji doprowadziły do powstawania nowych, ulepszonych
rozwiązań. Równocześnie rosnące potrzeby dotyczące aplikacji, wykorzystującej sieć In-
ternet do swojego działania spowodowała, iż obecnie istnieje wiele gotowych rozwiązań
umożliwiających serwowanie dynamicznej treści. Język Java jest tylko jednym z alterna-
tyw pośród stron tworzonych w technologiach takich jak ASP.NET [58], Adobe Flash [1]
czy PHP [44].
1.1.1. Historia i rozwój
Początki istnienia ram projektowych sięgają początków pierwszych aplikacji inter-
netowych [42]. Podstawą działania wszystkich aplikacji napisanych przy wykorzystaniu
platformy Java w środowisku webowym są serwlety – niewielkie programy działające po
stronie serwera, nadające dynamiczny charakter działającej aplikacji.
Idea serwletów zrodziła się w 1995 roku, czyli rok przed wydaniem pierwszej wersji
języka Java [12]. Pomysłodawcami i pierwszymi realizatorami technologi serwletów byli
JamesGoslingorazPavaniDiwanji.PierwszaspecyfikacjaJavaServletAPInoszącawersję
1.0 powstała w maju 1997 roku. Dwa lata później, wydano specyfikację JavaServer Pages
mająca również zastosowanie przy tworzeniu aplikacji internetowych. Różnica pomiędzy
serwletami a stronami JSP polega na tym, iż w przypadku serwletów programista skupia
się na kodzie języka Java generując odpowiedź w postaci tworzonych, często konkatenowa-
nych napisów, w przypadku stron wykonanych w technologi JavaServer Pages użytkownik
tworzy odpowiedź, najczęściej stronę HTML, w której używa wstawek języka Java. Osta-
6
tecznie strony JSP są kompilowane do serwletów, zatem jedyna różnica dotyczy sposobu
ich tworzenia.
Szybko okazało się iż dla wielu programistów, ustandaryzowane rozwiązania są niewy-
starczające. Jednym z powodów był zbyt mały poziom abstrakcji w stosunku do warstwy
protokołuHTTP.Powstałaspecyfikacjawprowadziłapojęcieżądania(ang.request),odpo-
wiedzi(ang.response)orazobiektuzwanegoserwletem(ang.servlet),odpowiedzialnegoza
interakcję z użytkownikiem. Dodatkowo wprowadzono do bezstanowego protokołu jakim
jest HTTP pojęcie stanowości za pomocą obiektu sesji (ang. session). Możliwe się stało
wypisanie odpowiedzi użytkownika wprost z poziomu serwletu wykorzystując odpowied-
nie metody, fragment przykładowego kodu został przedstawiony na listingu 1.1. Tworzy
on odpowiedź o charakterze powitalnym na stronie zatytułowanej „Prosty serwlet”. Dla
przejrzystości kodu zrezygnowano z wymaganej, w poprawnej aplikacji SGML, deklaracji
DOCTYPE.
(cid:7)
public class SimpleServlet extends HttpServlet {
1
public void doGet(HttpServletRequest req, HttpServletResponse res)
2
throws ServletException, IOException {
3
4
// Ustawiamy typ zwracanego dokumentu (strona HTML)
5
res.setContentType("text/html");
6
7
// Pobieramy strumien do zapisu
8
PrintWriter out = res.getWriter();
9
10
// Zapisujemy odpowiedz na wyjscie
11
out.println("<html>");
12
out.println("<head><title> Prosty serwlet </title></head>");
13
out.println("<body>");
14
out.println("<h1> Witaj </h1>");
15
out.println("</body>");
16
out.println("</html>");
17
18
// Zamykamy strumien, zwracamy odpowiedz
19
out.close();
20
}
21
}
22
(cid:10)(cid:6) (cid:5)
Listing 1.1: Serwlet wysyłający odpowiedź do klienta
Zastosowanieserwletówpostronieserweraumożliwiagenerowaniedynamicznejzawar-
tości w zależności od odebranego żądania skierowanego przez przeglądarkę użytkownika.
Zwyczajowo generowaną zawartością jest HTML, ale nie istnieją techniczne ograniczenia
do zwracania dowolnej zawartości, takiej jak XML.
Serwlety działają w środowisku określanym mianem kontenera serwletów. Kontener
serwletów stanowi element pośredniczący pomiędzy serwletem a serwerem internetowym.
Zarządzacyklemżyciaserwletów.MapujeadresyURLżądańdoposzczególnychserwletów
w celu ich obsłużenia. Ostatnią z ważniejszych funkcji kontenera jest dbałość o bezpie-
czeństwo aplikacji internetowej poprzez autoryzację żądań użytkownika.
Implementacja serwletu wymaga rozszerzenia abstrakcyjnej klasy HttpServlet z pa-
kietu javax.servlet.http oraz nadpisania co najmniej jednej z jej metod w zależności
7
od używanych metod. Prezentowany przykład nadpisuje w klasie SimpleServlet metodę
o nazwie doGet, zatem serwlet wspiera żądania wysłane z użyciem metody HTTP GET.
Listing 1.1 prezentuje działanie serwletu, generującego odpowiedź w postaci kodu
HTML. Możemy wyróżnić cztery etapy odpowiedzi:
1. Ustalenie typu zwracanego dokumentu (typ mediów), w naszym przypadku text/html,
który jest używany przy zwracaniu dokumentu HTML.
2. Utworzenia strumienia do którego nastąpi zapis zwracanego wyniku.
3. Zapis odpowiedzi do strumienia.
4. Zamknięcie strumienia, czyli wysłanie odpowiedzi o ustalonym typie mediów do klien-
ta.
Zamieszczony przykład dobrze obrazuje następujące cechy serwletów w kontekście
użycia ich do bezpośredniego wygenerowania odpowiedzi:
— kod serwletu to kod języka Java pomimo że formatem wyjściowym jest HTML,
— generacja kodu HTML została rozrzucona po różnych miejscach w pliku, rezultat za-
stosowania obiektu PrintWriter,
— sposób formatowania charakterystyczny dla kodu Javy sprawia trudności w zoriento-
waniu się w strukturze dokumentu i wyklucza zastosowanie edytorów szablonów,
— następuje wymieszanie kodu odpowiedzialnego za logikę aplikacji z kodem odpowie-
dzialnym za stworzenie wyglądu strony.
W odpowiedzi na zaprezentowane powyżej braki serwletów, opracowano specyfikację Ja-
vaServer Pages, która stanowi niejako odwrócenie zasady działania serwletów. Zamiast
wśrodowiskudynamicznym(kodzieJavy)tworzyćstatycznązawartośćznacznikówHTML,
postanowiono zawartość dynamiczną zanurzyć w statycznym języku np. HTML. Listing
1.2prezentujeróżnemożliwościzanurzeniakoduJavywstronieJSP.Liniapierwszaprzed-
stawia definicję zmiennej var. W linii drugiej umieszczono przykład wstawki języka Java
(ang. scriptlet), która zostanie wykonana w momencie obsługi żądania. Ostatnia linia
prezentujewyrażenie,którezostanieodzwierciedlonebezpośredniowgenerowanymkodzie
strony (brak znaku średnika na końcu wyrażenia).
(cid:7)
<%! int var = 1; %>
1
<% int var1 = 1; int var = 2; int var3 = var1 + var2 %>
2
<%= "numer wizyty " + 1 %>
3
(cid:10)(cid:6) (cid:5)
Listing 1.2: Zanurzanie elementów języka Java w stronie JSP
Pomimo wprowadzenia technologi JavaServer Pages generowanie widoku wciąż po-
siadało wadę związaną z przemieszaniem logiki biznesowej z kodem odpowiedzialnym za
prezentacjędanych.Ponadtozawieraniekodujęzykaprogramowania,takiegojaknp.Java,
w znacznikach powodowało, iż twórcy szablonów musieli być obeznani z jego stosowaniem,
co często okazywało się niepraktyczne.
Wyjściem z sytuacji stało się opracowanie, w wersji JSP 1.1, biblioteki tzw. custom
tags, których zadaniem było wydzielenie kodu aplikacji z warstwy widoku i zamknięcie jej
w specjalne znaczniki. Najpowszechniej używaną biblioteką znaczników jest JavaServer
Pages Standard Tag Library (JSTL), która zawiera w sobie wsparcie między innymi dla:
— wyrażeń warunkowych,
— iteracji,
— internalizacji i lokalizacji,
— języka zapytań SQL,
— języka znaczników XML,
8
— walidacji.
Biblioteka JSTL stanowi część platformy J2EE i została opracowana pod nadzorem Java
Community Process (JCP). Aktualna wersja wydana w maju 2006 roku nosi numer 1.2.
Obecna specyfikacja JEE w wersji 5.0 nie posiada w swoich zasobach opisu ustan-
daryzowanej ramy projektowej, służącej do budowy aplikacji biznesowych. Jednym ze
sposobów pisania aplikacji internetowych z użyciem prostej abstrakcji jest bezpośrednie
wykorzystanie serwletów i stron JSP w połączeniu z biblioteką znaczników. Takie podej-
ście ma wiele zalet, jeżeli budujemy prostą aplikację webową. Podczas pracy z większymi
systemami wydaje się konieczne skorzystanie z jednego ze szkieletów programistycznych.
Opisywane w pracy szkielety programistyczne należą do najliczniejszej grupy tzw.
szkieletów specjalizowanych, gdyż skupiają w sobie jedynie wsparcie przy tworzeniu war-
stwy kodu widoku, pozostawiając pozostałe warstwy tradycyjnej aplikacji trójwarstwowej
do dyspozycji programisty. Do frameworków próbujących scalić w sobie wiele warstw
należy np. biblioteka Rife [47] czy Roma [52].
Na osobną uwagę zasługuje framework Seam, opracowany przez firmę JBoss, który
nazywany jest „zaginionym Gralem platformy JEE”. Łączy w sobie biblioteki JavaServer
Faces (JSF), Facelets, Enterprise Java Beans (EJB3), Java Persistence API (JPA). Ze
względu na jego odrębność w stosunku do najpopularniejszych szkieletów specjalizowa-
nych, nie został opisany w pracy.
1.1.2. Wzorce projektowe
Trudność w zarządzaniu kodu nieczytelnego, korzystającego z niejasnych rozwiązań
architektonicznych oraz chęć wprowadzenia uniwersalnych, sprawdzonych w praktyce roz-
wiązań, doprowadziła do stworzenia wzorców projektowych [19]. Wzorce projektowe mają
zastosowanie w wielu dziedzinach informatyki, takich jak programowanie aplikacji mobil-
nych czy sieciowych. Poniższe dwa podrozdziały opisują jedynie najczęściej stosowane
wzorce wykorzystywane przy projektowaniu szkieletów programistycznych dla platformy
JavawtechnologiJ2EE[40].WzorcowiModel-Widok-Kontroler,zewzględunajegoszcze-
gólne znaczenie, został poświęcony osobny rozdział 1.2.2.
Front Controller
Aplikacje działające w sieci Internet zmuszone są, ze swojej natury, obsługiwać wielu
użytkowników jednocześnie. W jednym czasie do systemu napływają żądania klientów
realizujących swoje, często odmienne, potrzeby biznesowe. Wzorzec Front Controller [19,
strony 145-157] stanowi element, który w sposób scentralizowany nadzoruje napływające
żądania do aplikacji.
Istnieje również rozwiązanie alternatywne, które stosuje zdecentralizowany sposób ob-
sługi żądań. Przedstawione podejście wprowadza jednak do aplikacji zbędną duplikację
kodu związaną z tym, iż każdy widok systemu zmuszony jest do implementacji swojego
modułu odpowiedzialnego za przetwarzanie nadchodzących żądań. Ponadto opisywane
rozwiązanie komplikuje kwestię nawigacji, gdyż brak jest nadrzędnego elementu, który
zarządzaposzczególnymiwidokamiiprzełączaużytkownikamiędzynimi.Ostatniąsprawą
jest zmniejszona zarządzalność kodu powstałego w ten sposób spowodowana bezpośrednio
duplikacją kodu.
Zadaniem Front Controllera zaimplementowanego w postaci serwletu, może być mię-
dzy innymi zapewnienie wsparcia dla integracji usług systemowych, pomoc w pozyski-
waniu treści czy zarządzanie samymi widokami i nawigacją między nimi. Zastosowanie
elementu centralnego pozwala w elegancki sposób rozwiązać kwestię autoryzacji i uwie-
9