You are on page 1of 31

Eclipse Web Tools Platform.

Tworzenie aplikacji WWW


w jzyku Java
Autor: Naci Dai, Lawrence Mandel, Arthur Ryman
Tumaczenie: Przemysaw Szeremiota
ISBN: 978-83-246-1391-5
Tytu oryginau: COM+ Developer's Guide
Format: 168x237, stron: 744

Zwiksz swoj wydajno dziki platformie WTP!


Jak wykorzysta rodowisko Eclipse do tworzenia aplikacji internetowych?
W jaki sposb zorganizowa projekt aplikacji?
Jak przeprowadzi w aplikacjach testy jednostkowe?

Eclipse to zintegrowane rodowisko programistyczne. Projekt zosta zapocztkowany


przez firm IBM, natomiast aktualnie jest rozwijany przez Fundacj Eclipse. Dziki
licznym dodatkom, pluginom i podprojektom zyska on ogromn popularno i jest w tej
chwili jednym z narzdzi najczciej wybieranych do tworzenia aplikacji w jzyku Java
i nie tylko. Natomiast projekt WTP (skrt od ang. Web Tools Platform) dziki swoim
rozszerzeniom uatwia tworzenie aplikacji WWW.
Eclipse Web Tools Platform. Tworzenie aplikacji WWW w jzyku Java jest dugo
oczekiwan na polskim rynku ksik, powicon tej wanie platformie. Autorzy
przedstawiaj tu inspirujc histori tego rozwizania, struktur projektu oraz sposb
konfiguracji Web Tools Platform. Kolejne rozdziay przybli Ci zagadnienia zwizane
z warstw prezentacji, logiki biznesowej i trwaoci. Dowiesz si, w jaki sposb
wykorzysta narzdzia dostarczane przez WTP do przyspieszenia prac w kadej z tych
warstw. W zakresie podejmowanych zagadnie znajduj si rwnie tematy zwizane
z testami integracyjnymi i wydajnociowymi.

Wydawnictwo Helion
ul. Kociuszki 1c
44-100 Gliwice
tel. 032 230 98 63
e-mail: helion@helion.pl

Konfiguracja Web Tools Platform


Architektura aplikacji WWW
Podzia projektu na warstwy
Sposb wykorzystania narzdzia Maven
Wykorzystanie usug WWW
Testowanie aplikacji WWW
Rozszerzanie WTP

Poznaj jedn z najlepszych platform do tworzenia aplikacji WWW i nie tylko!

Spis treci
Przedmowa ................................................................................................................ 13
Wstp ........................................................................................................................ 15
Podzikowania ........................................................................................................... 19
O autorach ................................................................................................................. 21

Cz I

Zaczynamy ............................................................................................... 23

Rozdzia 1. Wprowadzenie ........................................................................................................... 25


Eclipse a tworzenie aplikacji WWW w Javie ................................................................. 25
Zawarto ksiki ............................................................................................................ 26
Organizacja materiau w ksice .................................................................................... 27
Kod rdowy przykadw ............................................................................................. 30
League Planet .................................................................................................................. 30
Podsumowanie ............................................................................................................... 32

Rozdzia 2. Wprowadzenie do Eclipse Web Tools Platform ........................................................... 33


Narodziny WTP ............................................................................................................. 33
Ekonomika WTP ............................................................................................................ 35
Redukcja nakadw programistycznych .................................................................. 36
Generowanie przychodu .......................................................................................... 38
Struktura WTP ............................................................................................................... 42
Przedmiot WTP ....................................................................................................... 43
Projekty skadowe WTP .......................................................................................... 44
Architektura WTP .................................................................................................... 46
Podprojekt WST ....................................................................................................... 48
Podprojekt JST ......................................................................................................... 53

Spis treci
Uczestnictwo w WTP .................................................................................................... 55
Uytkowanie ............................................................................................................ 56
Monitorowanie grup dyskusyjnych ........................................................................ 56
Zgoszenie problemu ............................................................................................... 56
Proponowanie ulepsze ........................................................................................... 57
Naprawienie bdu ................................................................................................... 57
Opublikowanie artykuu bd poradnika ............................................................... 58
Formalne doczenie do zespou ............................................................................. 58
Powikszanie spoecznoci ...................................................................................... 58
Podsumowanie ............................................................................................................... 59

Rozdzia 3. Elementarz ................................................................................................................. 61


Wprowadzenie ................................................................................................................ 61
Podejcie 1. Aplikacje WWW J2EE ................................................................................ 64
Dodawanie rodowiska wykonawczego serwera .................................................... 66
Tworzenie dynamicznego projektu WWW ............................................................ 72
Tworzenie i edycja strony JSP ................................................................................. 76
Uruchomienie JSP na serwerze .............................................................................. 76
Podsumowanie podejcia 1. ..................................................................................... 80
Podejcie 2. Serwlety i skryptlety .................................................................................. 80
Dodanie do JSP skryptletu w jzyku Java ............................................................... 80
Debugowanie JSP ..................................................................................................... 81
Tworzenie serwletu ................................................................................................. 85
Debugowanie serwletu ............................................................................................ 89
Podsumowanie podejcia 2. ..................................................................................... 90
Podejcie 3. Odwoania do bazy danych ....................................................................... 91
Nawizanie poczenia z baz danych ..................................................................... 93
Wykonywanie zapyta SQL ..................................................................................... 96
Realizowanie odwoa do bazy danych do aplikacji WWW ................................... 99
Podsumowanie podejcia 3. ................................................................................... 103
Podejcie 4. Usugi WWW ........................................................................................... 104
Instalowanie usugi Web Service ........................................................................... 104
Korzystanie z testowej aplikacji klienckiej ............................................................ 107
Monitorowanie komunikatw SOAP ................................................................... 108
Podsumowanie podejcia 4. ................................................................................... 109
Podsumowanie ............................................................................................................. 109

Rozdzia 4. Przygotowanie przestrzeni roboczej .......................................................................... 111


Instalowanie i aktualizowanie WTP ............................................................................ 111
Instalowane komponenty WTP ............................................................................. 112
Rodzaje kompilacji WTP ....................................................................................... 113
Instalacja za pomoc menedera aktualizacji ........................................................ 115
Instalowanie z archiww ZIP ................................................................................ 118
Instalowanie materiaw zewntrznych ................................................................ 120
JDK ......................................................................................................................... 123
Weryfikowanie instalacji ........................................................................................ 124
Aktualizowanie WTP ............................................................................................. 125

Spis treci

Konfigurowanie WTP .................................................................................................. 126


Preferencje kategorii Connectivity ........................................................................ 127
Preferencje kategorii Internet ................................................................................ 127
Preferencje kategorii Server ................................................................................... 128
Preferencje kategorii Validation ............................................................................ 128
Preferencje kategorii Web and XML ..................................................................... 128
Preferencje kategorii Web Services ....................................................................... 129
Preferencje kategorii XDoclet ............................................................................... 130
Wsplne ustawienia ................................................................................................ 130
Podsumowanie ............................................................................................................. 131

Cz II

Tworzenie aplikacji WWW w Javie ......................................................... 133

Rozdzia 5. Architektura i projektowanie aplikacji WWW ............................................................ 135


Krajobraz WWW ........................................................................................................... 135
Aplikacje WWW ............................................................................................................ 137
Aplikacje WWW w Javie ......................................................................................... 138
Projekt aplikacji WWW z podziaem na warstwy ................................................. 142
Wzorzec MVC w aplikacji WWW ......................................................................... 145
Szkielety aplikacyjne dla Javy ................................................................................. 149
Architektura usugowa SOA ........................................................................................ 152
Udostpnianie usug. Warstwa usugowa ............................................................. 152
Studium przypadku League Planet ........................................................................ 154
Podsumowanie ............................................................................................................. 156

Rozdzia 6. Organizacja projektu ................................................................................................ 157


Typy projektw WWW i aplikacji J2EE ...................................................................... 158
Projekty WWW ....................................................................................................... 159
Moduy J2EE .......................................................................................................... 160
Tworzenie aplikacji ................................................................................................ 160
Tworzenie aplikacji EJB ......................................................................................... 167
Tworzenie aplikacji EAR ....................................................................................... 173
Zaawansowane projekty WWW ................................................................................... 178
Modelowanie perspektywy projektowej ............................................................... 181
Przykadowe projekty ................................................................................................... 184
Prosta aplikacja korporacyjna ................................................................................. 184
Podzia moduu WWW na wiele projektw ......................................................... 190
Tworzenie aplikacji WWW a Maven ..................................................................... 199
Podsumowanie ............................................................................................................. 214

Rozdzia 7. Warstwa prezentacji ................................................................................................ 217


Wprowadzenie .............................................................................................................. 217
Projektowanie interakcji .............................................................................................. 218
Projektowanie grafiki ................................................................................................... 220
Struktura warstwy prezentacji ..................................................................................... 222

Spis treci
Podejcie 1. Projekty statycznych stron WWW, HTML i edytory
kodu rdowego .......................................................................................................... 225
Projekty statycznych aplikacji WWW .................................................................... 225
HTML .................................................................................................................... 228
Edytory kodu rdowego ..................................................................................... 236
Szablony .................................................................................................................. 239
Wstawki ................................................................................................................... 243
Podsumowanie podejcia 1. ................................................................................... 248
Podejcie 2. CSS ........................................................................................................... 248
Podsumowanie podejcia 2. ................................................................................... 253
Podejcie 3. JavaScript .................................................................................................. 253
Maskowanie adresu e-mail .................................................................................... 253
Walidacja danych wprowadzanych do formularza ............................................... 255
Podsumowanie podejcia 3. ................................................................................... 266
Podejcie 4. XML i XSLT ............................................................................................ 267
XML ........................................................................................................................ 267
XSLT ....................................................................................................................... 271
Podsumowanie podejcia 4. ................................................................................... 276
Podejcie 5. DTD ......................................................................................................... 276
Podsumowanie podejcia 5. ................................................................................... 281
Podejcie 6. Serwery, projekty dynamicznych aplikacji WWW i serwlety ................ 281
Serwery ................................................................................................................... 281
Projekty dynamicznych aplikacji WWW ............................................................... 288
Serwlety .................................................................................................................. 290
Podsumowanie podejcia 6. ................................................................................... 300
Podejcie 7. JSP ............................................................................................................ 300
Podsumowanie podejcia 7. ................................................................................... 310
Podejcie 8. Monitorowanie sesji HTTP ................................................................... 310
Sesje HTTP ............................................................................................................ 310
Monitor TCP/IP .................................................................................................... 311
Podgldanie sesji HTTP w monitorze TCP/IP ................................................... 312
Modyfikowanie i ponowne przesyanie komunikatu ........................................... 317
Podsumowanie podejcia 8. ................................................................................... 317
Podsumowanie ............................................................................................................. 317

Rozdzia 8. Warstwa logiki biznesowej ...................................................................................... 319


Typowy ukad warstwy biznesowej ............................................................................ 322
Podejcie 1. Model dziedzinowy ................................................................................. 323
Projekty pomocnicze J2EE .................................................................................... 323
Model obiektowy ................................................................................................... 325
Warstwa usugowa .................................................................................................. 332
Warstwa dostpu do danych .................................................................................. 336
Testy ........................................................................................................................ 342
Podsumowanie podejcia 1. ................................................................................... 346

Spis treci

Podejcie 2. Tworzenie sesyjnych komponentw EJB .............................................. 347


Dodawanie serwera JBoss ...................................................................................... 351
XDoclet ................................................................................................................... 354
Projekty EJB ........................................................................................................... 357
Tworzenie komponentw sesyjnych .................................................................... 360
Konstruowanie klienta WWW ............................................................................... 371
Uruchamianie aplikacji .......................................................................................... 374
WTP i komponenty EJB 3.0 .................................................................................. 377
Podsumowanie podejcia 2. ................................................................................... 379
Podejcie 3. Komponenty komunikatowe .................................................................. 380
Krtkie wprowadzenie do MDB ........................................................................... 380
Tworzenie komponentu komunikatowego .......................................................... 380
Tworzenie kolejki komunikatw w JBoss ............................................................ 384
Tworzenie klienta kolejki JMS .............................................................................. 385
Podsumowanie podejcia 3. ................................................................................... 388
Podsumowanie ............................................................................................................. 389

Rozdzia 9. Warstwa trwaoci ................................................................................................... 391


Projekty warstwy trwaoci .......................................................................................... 392
Odwzorowanie obiektw w bazie danych za pomoc interfejsu JDBC ............. 394
Odwzorowanie obiektw w bazie danych za porednictwem
komponentw encyjnych ...................................................................................... 395
Odwzorowanie obiektw w bazie danych za porednictwem
gotowych szkieletw odwzorowania obiektowo-relacyjnego .............................. 396
Przegld wicze .......................................................................................................... 397
Podejcie 1. Tworzenie bazy danych ........................................................................... 398
Podsumowanie podejcia 1. ................................................................................... 407
Podejcie 2. Warstwa danych ....................................................................................... 408
Podsumowanie podejcia 2. ................................................................................... 414
Podejcie 3. Komponenty encyjne .............................................................................. 414
Przygotowania w JBoss, Derby i XDoclet ............................................................ 415
Tworzenie komponentu CMP .............................................................................. 419
Definiowanie metody ejbCreate i metod wyszukujcych ................................... 423
Dodawanie DAO z wykorzystaniem CMP .......................................................... 430
Testowanie implementacji CMP .......................................................................... 433
Programowanie JPA w WTP ................................................................................. 437
Podsumowanie podejcia 3. ................................................................................... 441
Podsumowanie ............................................................................................................. 441

Rozdzia 10. Usugi WWW ........................................................................................................... 443


WSDL ........................................................................................................................... 444
SOAP ............................................................................................................................ 445
REST ............................................................................................................................. 446
Usugi WWW la REST .............................................................................................. 448
Przegld wicze .......................................................................................................... 449

10

Spis treci
Podejcie 1. Budowanie usugi WWW od gry ....................................................... 450
XSD ......................................................................................................................... 450
WSDL ..................................................................................................................... 456
Wdraanie usug WWW ......................................................................................... 462
Implementowanie usugi WWW ........................................................................... 469
Testowanie usugi w eksploratorze usug WWW ................................................. 474
Podsumowanie podejcia 1. ................................................................................... 475
Podejcie 2. Budowanie usugi WWW od dou ....................................................... 477
Implementacja klasy usugi .................................................................................... 478
Wdraanie usugi .................................................................................................... 483
Podsumowanie podejcia 2. ................................................................................... 487
Podejcie 3. Generowanie proxy dla klientw usugi WWW .................................... 487
Generowanie proxy klienckiego i testowej strony JSP ......................................... 488
Korzystanie z testowej klienckiej strony JSP ........................................................ 491
Podsumowanie podejcia 3. ................................................................................... 493
Podejcie 4. Kontrola interoperacyjnoci usug WWW .............................................. 494
Kontrola komunikatw pod ktem zgodnoci z WS-I ......................................... 495
Podsumowanie podejcia 4. ................................................................................... 498
Podejcie 5. Wykorzystywanie usug WWW w aplikacjach WWW ........................... 501
Generowanie klienta usugi Query ....................................................................... 501
Tworzenie serwletw ............................................................................................. 502
Importowanie kodu interfejsu uytkownika ........................................................ 504
Testowanie interfejsu uytkownika ...................................................................... 515
Podsumowanie podejcia 5. ................................................................................... 519
Podejcie 6. Wyszukiwanie i publikowanie usug WWW .......................................... 519
UDDI ..................................................................................................................... 520
WSIL ....................................................................................................................... 520
Podsumowanie podejcia 6. ................................................................................... 525
Podsumowanie ............................................................................................................. 525

Rozdzia 11. Testy ........................................................................................................................ 527


Testy zautomatyzowane ............................................................................................... 529
Przegld zada z biecego rozdziau .......................................................................... 530
Podejcie 1. Testy jednostkowe la JUnit .................................................................. 530
Tworzenie projektu dla testw .............................................................................. 532
Przypadek testowy JUnit ....................................................................................... 532
Zestaw testw JUnit .............................................................................................. 537
Podsumowanie podejcia 1. ................................................................................... 538
Podejcie 2. Testy integracyjne la Cactus ................................................................. 539
Podsumowanie podejcia 2. ................................................................................... 545
Podejcie 3. Testy systemowe la HttpUnit .............................................................. 546
Podsumowanie podejcia 3. ................................................................................... 551
Podejcie 4. Testy wydajnociowe la TPTP ............................................................. 551
Tworzenie projektu testu wydajnoci ................................................................... 554
Test rejestrowania HTTP ...................................................................................... 554
Generowanie zestawienia wynikowego ................................................................ 556
Podsumowanie podejcia 4. ................................................................................... 558

Spis treci

11

Podejcie 5. Profilowanie aplikacji z TPTP ................................................................ 558


Podsumowanie podejcia 5. ................................................................................... 563
Podsumowanie ............................................................................................................. 563

Cz III

Rozszerzanie WTP .................................................................................. 565

Rozdzia 12. Dodawanie nowych serwerw ................................................................................. 567


Oglnie o dodawaniu uniwersalnego adaptera serwera ............................................. 570

rodowisko wykonawcze GlassFish ............................................................................ 571


Wtyczki adapterw serwerw ...................................................................................... 572
Dodawanie obsugi do nowego rodowiska wykonawczego ..................................... 575
Dodawanie nowego typu serwera ............................................................................... 577
Dodawanie handlera rodowiska wykonawczego ....................................................... 578
Aspekty i komponenty rodowiska wykonawczego ................................................... 579
Rozszerzanie interfejsu narzdzi serwerowych .......................................................... 581
Definicja serwera .......................................................................................................... 583
Moduy publikacji ........................................................................................................ 587
Test adaptera serwera ................................................................................................... 590
Podsumowanie ............................................................................................................. 598

Rozdzia 13. Obsuga nowych typw plikw ................................................................................ 601


Tworzenie rozszerzenia DocBook .............................................................................. 603
Walidator DocBook ...................................................................................................... 603
Infrastruktura walidacji w WTP ............................................................................ 605
Implementacja walidatora dla DocBook ............................................................... 605
Tworzenie wasnego typu markera ............................................................................. 618
Deklarowanie typu zawartoci DocBook .................................................................... 619
Podsumowanie ............................................................................................................. 624

Rozdzia 14. Rozszerzenia dla WSDL ............................................................................................ 625


Tworzenie wtyczki rozszerzenia WSDL ..................................................................... 629
Rozszerzanie edytora WSDL ....................................................................................... 630
Dostosowywanie wygldu elementw rozszerzajcych WSDL
w panelu edycji wizualnej ...................................................................................... 632
Dodawanie elementw rozszerzajcych do edytora ............................................. 635
Dodawanie wasnych akcji do widoku edycji wizualnej edytora WSDL ............ 644
Rozszerzanie walidacji WSDL ..................................................................................... 651
Dodatki do walidacji WSDL 1.1 ............................................................................ 652
Wasne reguy walidacji .......................................................................................... 656
Podsumowanie ............................................................................................................. 660

Rozdzia 15. Dostosowywanie mechanizmu rozwizywania URI dla zasobw .............................. 661
Tworzenie wtyczki rozszerzenia infrastruktury rozwizywania zasobw ................ 664
Dodawanie zasobw do katalogu XML ...................................................................... 665
Katalog XML .......................................................................................................... 667
Dodawanie pojedynczego zasobu do katalogu XML ........................................... 667
Dodawanie do katalogu XML zestawu zasobw .................................................. 670

12

Spis treci
Wasna strategia rozwizywania zasobw ................................................................... 673
Infrastruktura rozwizywania URI dla zasobw .................................................. 675
Tworzenie folderu mechanizmu rozwizywania URI ........................................ 678
Podsumowanie ............................................................................................................. 681

Cz IV

Produkty i dodatki .................................................................................. 683

Rozdzia 16. Inne narzdzia WWW bazujce na Eclipse ................................................................ 685


WWW w Javie ............................................................................................................... 686
BEA Workshop ....................................................................................................... 686
CodeGear JBuilder ................................................................................................. 686
Exadel Studio .......................................................................................................... 686
IBM Rational Application Developer ................................................................... 687
JBoss Tools (JBoss IDE) ........................................................................................ 688
MyEclipse ............................................................................................................... 688
ObjectWeb Lomboz ............................................................................................... 688
SAP NetWeaver Developer Studio ....................................................................... 689
W4T Eclipse ........................................................................................................... 689
WWW w Perlu .............................................................................................................. 689
EPIC ........................................................................................................................ 690
WWW w PHP ............................................................................................................... 690
Eclipse PHP Development Tools ......................................................................... 691
PHPEclipse ............................................................................................................. 691
WWW w Pythonie ........................................................................................................ 691
PyDev ...................................................................................................................... 691
WWW w Ruby .............................................................................................................. 692
RadRails .................................................................................................................. 692
Podsumowanie ............................................................................................................. 692

Sowniczek ............................................................................................................... 693


Bibliografia .............................................................................................................. 701
Skorowidz ................................................................................................................ 709

Rozdzia 5. Architektura i projektowanie aplikacji WWW

135

ROZDZIA 5.
Architektura i projektowanie
aplikacji WWW
Pomyki s wrotami do odkry.
James Joyce
W tym rozdziale zajmiemy si opisem dwch rodzajw systemw WWW infrastruktury
aplikacji i infrastruktury usugi. Wielu z nas tworzy aplikacje z interfejsem WWW. Owe interfejsy odwouj si do warstw biznesowych aplikacji i utrwalaj pobrane dane w bazach
danych. Dla takich rodzajw systemw architektur warstwow udostpnia infrastruktura
aplikacji. Z kolei w przypadku infrastruktury usugi mamy do czynienia ze wspprac poszczeglnych usug za porednictwem WWW bez udziau uytkownikw. W tym przypadku mowa o architekturze zorientowanej na usugi SOA (od Service Oriented Architecture).
Oba systemy maj cechy wsplne; w obu chodzi o zmontowanie rozlegego i poprawnego pod wzgldem struktury systemu WWW, opartego na prawidach zasad obiektowoci.
Przypomnimy wic wiadomoci z wykadw o projektowaniu obiektowym i zobaczymy,
jak mona je zastosowa do WWW.

Krajobraz WWW
Sie WWW ewoluuje od sieci stanowicej nonik informacji dla odbiorcw-uytkownikw,
w kierunku rodka komunikacji i wsppracy pomidzy ludmi, ale i pomidzy aplikacjami
(zob. rysunek 5.1).
Sie WWW dziaa w oparciu o standardowe i otwarte protokoy. Jest niejednorodna,
rozproszona i szeroko dostpna. Sie WWW jest wic niemal idealn platform do wymiany
informacji i koordynacji dziaa. Budowanie aplikacji WWW i integrowanie tych aplikacji nie

136

Cz II Tworzenie aplikacji WWW w Javie

RYSUNEK 5.1. Aplikacje i usugi WWW

Rozdzia 5. Architektura i projektowanie aplikacji WWW

137

s ju oddzielnymi zadaniami. Podstawowym zaoeniem SOA jest to, e systemy WWW
powinny by montowane z usug eksponujcych otoczeniu cile zdefiniowane interfejsy,
ktre pozwalaj na komunikacj zarwno z uytkownikami, jak i aplikacjami.
W wiecie ukierunkowanym na usugi mamy mnstwo aplikacji sieciowych: aplikacje
patnicze uruchamiane na komputerach typu mainframe, drukarki fotograficzne drukujce
zdjcia z aparatu cyfrowego czy wsady wieych wiadomoci z praktycznie dowolnej dziedziny. Wszystkie te aplikacje s przykadami systemw wiadczcych pewne usugi. Kady
z takich systemw-usugodawcw eksponuje swoje zasoby za porednictwem publicznego
interfejsu definiujcego jego usug. Nowe aplikacje uywaj takich usug i montuj z nich
nowe aplikacje, ktre same mog by udostpniane rwnie jako osobne usugi. W tym prostym modelu usugodawcy i usugobiorcy mona uj tworzenie aplikacji WWW nastpnej
generacji, z prawie nieograniczonymi moliwociami.

Aplikacje WWW
Prosta aplikacja WWW skada si z trzech logicznych warstw: warstwy prezentacji, warstwy
logiki biznesowej i warstwy danych (zob. rysunek 5.2). To jedynie podstawowy podzia oglny, ale w faktycznej aplikacji mona wyrnia logicznie dodatkowe warstwy, reprezentujce
i wyodrbniajce poszczeglne charakterystyczne elementy architektury aplikacji. Architektura fizyczna aplikacji jest tu nieistotna: wszystkie trzy warstwy mog rwnie dobrze dziaa
na pojedynczym serwerze aplikacyjnym i jednym komputerze albo na trzech i wicej osobnych serwerach aplikacyjnych. W J2EE architektur fizyczn mona zarzdza niezalenie
od warstw logicznych aplikacji.

RYSUNEK 5.2. Aplikacje i usugi WWW

138

Cz II Tworzenie aplikacji WWW w Javie


Najwysza warstwa to warstwa prezentacji. Jest to warstwa interfejsu uytkownika, montowana zazwyczaj na bazie jzyka HTML. Modele RIA (Rich Internet Application) i AJAX
wprowadzaj zreszt do warstwy prezentacji nowsze technologie implementacji strony klienckiej, na przykad Flash czy JavaScript. Jeli interfejs uytkownika nie wymaga do uruchomienia
niczego poza przegldark WWW, okrelamy go mianem cienkiego klienta ang. thin client.

Adobe Flash
Flash jest co prawda najpowszechniejszy wanie w bogatym interfejsie uytkownika, ale czsto
wykorzystuje si go rwnie w aplikacjach wielowarstwowych. Flash ma wasny obiektowy jzyk
programowania ActionScript 2.0 i komponenty umoliwiajce odwoywanie si do usug
WWW i baz danych. Wicej informacji o tej stronie platformy Flash mona znale
 pod adresem http://www.adobe.com/platform.

Warstwa rodkowa to warstwa, w ktrej realizuje si tak zwan logik biznesow aplikacji. W tej warstwie bd dziaa na przykad obiekty realizujce dodanie druyny do ligi.
Wydzielona warstwa logiki biznesowej nie jest zreszt zwizana wycznie z aplikacj WWW
porzdne wyodrbnienie warstwy umoliwia wykorzystanie jej rwnie w innych systemach.
Dolna warstwa to warstwa, gdzie realizowane jest zadanie przechowywania danych w sposb trway. Najbardziej typowym rdem trwaoci jest baza danych, ale rwnie dobrze mog
to by pliki w systemie plikw.
W dalszej czci rozdziau zajmiemy si kwestiami dotyczcymi poszczeglnych wyrnionych tu warstw. W sieci WWW mona znale mnstwo przykadw takich aplikacji;
wszystkie udostpniaj jakie usugi warstwy biznesowej uytkownikom kocowym. Aplikacje te mog by ze sob skojarzone (na przykad odnonikami hipertekstowymi), ale nie s
faktycznie zintegrowane stanowi raczej luno powizane ekosystemy, w ktrych czynnikiem wicym jest wanie uytkownik kocowy. Tymczasem w systemie zorientowanym
na usugi aplikacje s zintegrowane za porednictwem tyche usug; miejsce uytkownikw
w tych systemach zajmuj inne, zewntrzne aplikacje WWW, a warstwa prezentacji jest zastpowana warstw usugi.

Aplikacje WWW w Javie


Aplikacje WWW w jzyku Java wykorzystuj technologie opisane w specyfikacji J2EE i powszechne standardy oglne, jak HTML, XMLO czy Web Service.
Koncepcja warstwowego podziau aplikacji i systemw klient-serwer jest w informatyce
obecna znacznie duej ni technologie WWW i jzyk Java. Chyba najcenniejszym wkadem
ze strony J2EE w tej dziedzinie byo udostpnienie praktycznej i ustandaryzowanej specyfikacji. Dziki temu powstao wiele komercyjnych i niekomercyjnych serwerw aplikacyjnych
obsugujcych tak ustanowiony standard.
J2EE oferuje standardy dla modeli wykonawczych i programistycznych, wykorzystywanych w aplikacjach WWW. S tu komponenty dla sesji klienckich, prezentacji, logiki biznesowej i logiki sterowania aplikacj, a take dla operacji biznesowych. S tu te zdefiniowane
usugi dotyczce rozproszenia, transakcyjnoci i zarzdzania danymi, umoliwiajce uruchamianie tych komponentw w rodowiskach korporacyjnych.

Rozdzia 5. Architektura i projektowanie aplikacji WWW

139

Aplikacje WWW w technologii J2EE s przenone pomidzy zgodnymi ze specyfikacj


serwerami aplikacyjnymi. Przenono ta bazuje na dostpnoci kompletnego standardu regulujcego przebieg interakcji klientw z systemem, implementacj poszczeglnych komponentw i sposb wykorzystania przez te komponenty interfejsw usug w celu integrowania
ich z innymi systemami korporacyjnymi. Model J2EE dzieli warstw prezentacji na warstwy
prezentacji strony klienta i strony serwera. Do modelowania i implementowania logiki biznesowej su tu komponenty EJB. Warstwa danych jest realizowana rwnie za pomoc komponentw EJB, a take za porednictwem usug dajcych dostp do korporacyjnych systemw
informatycznych.
J2EE definiuje osobne kontenery dla komponentw WWW i komponentw biznesowych (EJB) zob. rysunek 5.3. Kontenery udostpniaj standardowe dla nich usugi, obsugujc rozproszenie, sesyjno i transakcyjno . Klienty mog by aplikacjami typu thin client
(jak przegldarka WWW) albo penoprawnymi i samodzielnymi aplikacjami. Wymagane do komunikacji protokoy WWW s obsugiwane przez rodowiska wykonawcze po stronie serwera.

RYSUNEK 5.3. Kontenery J2EE

Kontener WWW obsuguje komponenty takie jak strony JSP i serwlety. Komponenty
te s wykorzystywane powszechnie do realizacji warstwy prezentacji.
Kontener komponentw EJB udostpnia rodowisko wykonawcze dla komponentw
biznesowych i dostp do korporacyjnych systemw informatycznych.

rodowisko wykonawcze skada si z licznych ustandaryzowanych usug, w tym usug


cznoci z bazami danych (JDBC), interfejsu transakcyjnego Java Transaction API i usug
transakcyjnoci (JTA/JST), architektury J2CA (Java 2 Connector), usug uwierzytelniania

140

Cz II Tworzenie aplikacji WWW w Javie


i autoryzacji (JAAS), usug interfejsu systemw nazw i katalogw (JNDI) i mnstwa innych
interfejsw realizujcych komunikacj wewntrzn i zewntrzn, zapewniajcych rozszerzalno systemw J2EE.

Projektowanie aplikacji WWW w jzyku Java


Czasami jestemy tak zaaferowani nowymi technologiami i systemami, e zapominamy nauki z przeszoci. Stosowanie zasad inynierii oprogramowania, zwaszcza za zasad obiektowoci, jest dla nas w tych nowych technologiach wyzwaniem (Knight 2002). Owe nowe technologie bywaj tak samo grone, jak efektywne; mog zachca do stosowania niekoniecznie
najlepszych praktyk programistycznych. Na przykad programowanie stron JSP kusi moliwoci bezporedniego odwoywania si do baz danych, atwo tu te zapomnie o zdatnoci
kodu do ponownego wykorzystania. Komponenty EJB jako skadowe biznesowych komponentw aplikacji s krytykowane za nadmiern zoono . XML promuje wspdzielenie
i wielokrotne wykorzystanie, ale bywa naduywany.
Aplikacje WWW pisane w Javie skadaj si od strony warstwy prezentacji ze stron JSP
i serwletw. Zarwno JSP, jak i serwlety mona wykorzysta przy tworzeniu architektur
z wyodrbnionymi warstwami. W ten sposb buduje si dwa najpopularniejsze typy aplikacji WWW w Javie, ktre bdziemy oznacza jako model 1. i model 2. Ot wedle modelu 1.
dania klientw s przesyane wprost do stron JSP, podczas gdy w modelu 2. s one kierowane do serwletu kontrolujcego, ktry dopiero przekierowuje je do odpowiednich stron JSP.
Obszerne opisy obu modeli mona znale w podrozdziale 4.4, Web-Tier Application Framework
Design, w ksice Designing Enterprise Applications with the J2EE Platform (Singh 2002). Model 1.
jest wykorzystywany w bardzo prostych aplikacjach WWW. Z kolei model 2. stanowi adaptacj wzorca projektowego MVC (Model View Controller) dla potrzeb aplikacji WWW. Wzorcem projektowym MVC zajmiemy si nieco pniej (w podrozdziale Wzorzec MVC
w aplikacji WWW).
Wedle modelu 1. najwaniejszym celem jest przeniesienie moliwie duej iloci kodu
obsugujcego prezentacj z klas Java do stron JSP. Elementy JSP s popularne, poniewa
pozwalaj na zarzdzanie treci (HTML, CSS, JavaScript czy XML) i na rwnoczesne stosowanie kodu w jzyku Java. W JSP mona wygodnie przetwarza dania HTTP i generowa
odpowiedzi w postaci gotowych dokumentw HTML. Strony JSP daj si te atwo zrozumie projektantom i twrcom WWW (ktrzy niekoniecznie s wykwalifikowanymi programistami Java). W architekturze narzucanej przez model 1. caa aplikacja jest w zasadzie
realizowana na bazie JSP. Niektrzy podnosz, e mimo wszystko dochodzi do separacji treci
i prezentacji, poniewa wszystkie odwoania do danych s realizowane za pomoc komponentw jzyka Java. Architektura modelu 1. sprawdza si na szybko w niewielkich aplikacjach,
ale dla wszystkich aplikacji obejmujcych wicej ni kilka stron kodu trzeba j uzna za
zwyczajnie z. JSP nie jest dobrym miejscem do realizowania logiki biznesowej i logiki sterowania aplikacj. Model 1. w miar wzrostu rozmiaru aplikacji szybko degeneruje projekt,
wymuszajc zwielokrotnianie kodu i zwikszajc zoono . Wszystkie podstawowe warstwy
logiczne typowej aplikacji s tu sprasowane do postaci pojedynczego komponentu.
Z punktu widzenia wyodrbniania rnych abstrakcji do rnych warstw i z punktu widzenia zasad obiektowoci model 1. programowania z uyciem JSP jest najgorszy w tym,
e w pojedynczym skrypcie grupuje si zadania nalece do oddzielnych warstw. Wedle
modelu 1. JSP musi:

Rozdzia 5. Architektura i projektowanie aplikacji WWW

141

1. Przyjmowa dane wejciowe.


2. Obsugiwa logik aplikacji (logik biznesow i logik przepywu sterowania).
3. Generowa dane wyjciowe (obsugiwa logik prezentacji).

Skoro wszystkie trzy warstwy zostay zwizane w pojedynczym komponencie, nie mona
adnej z nich modyfikowa ani testowa z osobna. Do tego obsuga wszystkich tych zada
(opiszemy je osobno) rwnie jest problematyczna. To samo dotyczyoby wykorzystania
samych serwletw (bo serwlet mona uzna za skrypt z dodatkowymi osadzonymi elementami XML czy HTML); do tego mieszanie kodu z tekstem utrudnia zarzdzanie kodem
i diagnostyk kodu.

Przyjmowanie danych wejciowych


W ramach przyjmowania danych wejciowych skrypt otrzymuje do dyspozycji obiekt
HttpServletRequest, bdcy reprezentacj strumienia wejciowego HTTP, minimalnie tylko
przetworzon. W HTTP wyrniono trzy mechanizmy do przekazywania parametrw (metoda kodowania parametrw w URL, metoda parametrw zapyta i formularze) i we wszystkich dane s przekazywane jako zwyczajne cigi znakw. Kady ze skryptw skadajcych
si na aplikacj musi wic na wasn rk okrela sposb przekazywania parametrw,
konwersj parametrw na wartoci odpowiednich typw i weryfikacj (walidacj) tych wartoci. Brak wsplnego, wyodrbnionego kodu obsugi danych wejciowych wymusza powielanie tego samego bd podobnego kodu w wielu osobnych skryptach.

Obsuga logiki aplikacji


Kolejn kwesti problematyczn, dotyczc zarwno obsugi wejcia, jak i logiki aplikacji, jest
brak hermetyzacji informacji przy odwoaniach do danych dania i danych sesji. Skrypt musi
pobra dane z dania wejciowego po nazwie. Protok HTTP jest protokoem bezstanowym,
wic dane wykorzystywane na wielu osobnych stronach JSP w kadym skrypcie wymagajcym tych danych musz albo by zapisane w sesji skojarzonej z danym uytkownikiem, albo
wielokrotnie odczytywane z zewntrznego rda danych.
Na przykad, jeli skrypt przekazuje dane logowania uytkownika jako dane formularza,
kod zapisujcy te dane w sesji mgby wyglda tak:

Listing 5.1. Zapisywanie sesji z parametrami dania HTTP


password = request.getParameter("passwordField");
decrypted = this.decode("password");
request.getSession().setAttribute("password", decrypted);

Zarwno zapis danych w atrybutach sesji, jak i zapis w zewntrznym rdle danych to
efektywny zapis danych w zasigu globalnym, a aplikacja odwouje si do takich danych jak
do sownika, to znaczy poprzez cigi z nazwami traktowanymi jako klucze wartoci. Tak
skadowanych danych nie dotycz zwyczajne mechanizmy kontrolowania czasu ycia zmiennych i w kadym skrypcie czy te na kadej stronie korzystajcej z danych trzeba ujawni

142

Cz II Tworzenie aplikacji WWW w Javie


stosowane nazewnictwo atrybutw-zmiennych. Nie mona wtedy w prosty sposb wyszuka wszystkich odwoa do zmiennych za porednictwem zwyczajnych mechanizmw programistycznych, co z kolei utrudnia modyfikowanie odwoa do danych. A jeli JSP nie
hermetyzuje stosowanej konwencji nazewniczej, wiedza i niej i o niskopoziomowych przecie szczegach implementacji protokou HTTP musi by implementowana w caoci aplikacji, co skutecznie niweczy jej zdatno do adaptacji do nowych zastosowa. Co wicej,
mamy tu te potencjalne rdo bdw, ktre mog powsta nie tylko wskutek zwyczajnej
literwki w nazwie zmiennej, ale take w wyniku zastosowania takiej samej nazwy w rnych skryptach do rnych celw. W miar zwikszania si liczby stron JSP budowanej w ten
sposb aplikacji, problemy te mog okaza si przytaczajce.
Kiedy do realizacji logiki aplikacji wykorzystuje si strony JSP, wprowadza si do nich
potencjalnie znaczce iloci kodu. Tymczasem techniki zarzdzania kodem w przypadku kodu
osadzonego w JSP musz z koniecznoci by ograniczone. Mieszanina kodu i tekstu na stronach JSP utrudnia te diagnostyk kodu. Co prawda w WTP znalazy si zarwno mechanizmy asysty przy wprowadzaniu kodu w JSP, jak i mechanizmy interaktywnego debugowania kodu, w przypadku prekompilowanych stron JSP trzeba bdzie debugowa zoony kod
generowany przez serwer, co jest trudne. Z tych wzgldw naleaoby minimalizowa ilo
kodu w stronach JSP i unika programowania tam logiki aplikacji.

Obsuga logiki biznesowej


W JSP cay kod ma struktur monolityczn. Co prawda mona w nim wydelegowa zadania
biznesowe do obiektw biznesowych, ale wci mamy do czynienia z mieszaniem logiki aplikacji i logiki biznesowej. Tymczasem nie da si skutecznie przetestowa niezalenie od siebie
poszczeglnych fragmentw JSP, tak jak to jest moliwe w przypadku odrbnych klas jzyka
Java (i testw jednostkowych). Do tego realizacja logiki biznesowej w JSP prowadzi do dalszego przeadowania strony kodem, co utrudnia zarzdzanie tym kodem i konserwacj projektu.

Generowanie danych wyjciowych


Przy generowaniu danych wyjciowych w prostym skrypcie miesza si tre HTML bd
XML z danymi dynamicznymi. Powoduje to wizanie wygldu strony wynikowej z pozostaymi warstwami aplikacji. Zmiana wygldu strony WWW czy cho by przystosowanie
aplikacji do potrzeb i ogranicze rnych urzdze docelowych s wtedy mocno utrudnione.
A ta ostatnia trudno nabiera znaczenia, poniewa sie WWW nieustannie rozprzestrzenia si
na urzdzenia przenone, w tym cho by telefony komrkowe. JSP pomaga w uporaniu si
z tym problemem, pozwalajc projektantom WWW tworzy wygld stron, podczas gdy programici Java realizuj logik prezentacji w adnotacjach. Taki ukad uwaa si powszechnie
za najbardziej odpowiednie zastosowanie stron JSP.

Projekt aplikacji WWW z podziaem na warstwy


W architekturze z wyodrbnionymi warstwami powstaje system skadajcy si z kilku wyranie oddzielonych czci (warstw), z moliwie ograniczonymi zalenociami i interakcjami
pomidzy tymi czciami. Taki system cechuje si dobrym podziaem problematyki aplikacji, co oznacza, e rne aspekty dziaania aplikacji mona opracowywa niezalenie od siebie,

Rozdzia 5. Architektura i projektowanie aplikacji WWW

143

z minimalnym wpywem (a docelowo z brakiem takiego wpywu) na pozostae czci. Oddzielajc od siebie poszczeglne fragmenty systemu czynimy oprogramowanie wysoce adaptowalnym, atwo dostosowujcym si do zmieniajcych si w przyszoci wymaga. Warstwy
obejmuj logik pobierania danych i ich wyprowadzania (warstwa prezentacji), logik aplikacji, logik biznesow i zagadnienia trwaoci danych. Wszystkie te warstwy mona wyprowadzi z opisywanego wczeniej trzywarstwowego modelu wzorcowego; warstwa wejcia
to skadowa warstwy prezentacji. Warstwa logiki aplikacji jest czsto podzielona na logik
przepywu sterowania w warstwie prezentacji i logik biznesow oraz przepywy danych
i procesw w warstwie logiki biznesowej. Logika utrwalania danych moe stanowi osobn
warstw danych; elementy tej logiki mog znajdowa si w warstwie logiki biznesowej.

Warstwa danych wejciowych


Warstwa danych wejciowych albo te warstwa wejcia obejmuje kod zajmujcy si przetwarzaniem i weryfikacj poprawnoci skadniowej danych wejciowych, a wic strumieni
SOAP, HTTP, SMPT i tak dalej; odpowiada te za wyuskiwanie wartoci parametrw
z da. Wedle wzorca MVC odpowiada ona kontrolerowi wejcia.
Do zmontowania tej warstwy wykorzystujemy komponenty i interfejsy serwletw do
obsugi protokou HTTP. Sposobami uycia tych interfejsw i komponentw zajmiemy si
w dalszej czci rozdziau.

Logika aplikacji
Kod logiki aplikacji odpowiada za oglny przepyw sterowania w aplikacji WWW. Czsto ta
warstwa okrelana jest mianem warstwy sklejajcej (ang. glue layer), oddzielajcej warstw logiki
biznesowej od logiki danych wejciowych i wyjciowych i zarzdzajcej stykiem tych warstw.
Wymaga to zaszycia tutaj pewnej wiedzy o obu tych warstwach. W tej warstwie bdzie na
przykad dochodzi do konwersji pomidzy wejciem i wyjciem warstwy prezentacji w postaci cigw znakw a komunikatami bd wartociami obiektw biznesowych. W aplikacji
WWW ta warstwa moe rwnie zarzdza interakcj uytkownika z wieloma stronami aplikacji jako sekwencj krokw (przejciami pomidzy stronami WWW). W MVC odpowiada to
roli kontrolera aplikacji.
Standard J2EE nie definiuje bezporednio komponentw do realizacji logiki aplikacji.
Warstwa ta jest zazwyczaj implementowana w obrbie kontenera WWW J2EE i wykorzystuje podobne komponenty i interfejsy, jak te wykorzystywane w warstwie danych wejciowych. Sytuacja ta poprawia si wyranie wraz z dodaniem do Java EE 5 specyfikacji JSF
(JavaServer Faces).

Logika biznesowa
Kod logiki biznesowej, implementujcy tak zwane obiekty biznesowe, zajmuje si wycznie wewntrznymi i waciwymi zadaniami aplikacji, czyli jej procesami biznesowymi. Kod
ten powinien by kompletnie niezaleny od warstw zewntrznych (prezentacji). W zoonej
aplikacji logika biznesowa bdzie najpewniej najbardziej rozbudowanym komponentem, cile

144

Cz II Tworzenie aplikacji WWW w Javie


zwizanym z kodem odwoujcym si do systemw zewntrznych, w tym baz danych, korporacyjnych systemw informacyjnych (EIS) takich jak ERP (Enterprise Resource Planning) czy
CRM (Client Relationship Management) i innych powizanych usug. We wzorcu MVC logice
biznesowej odpowiada model.
Obiekty realizujce logik biznesow nie powinny by zalene od obiektw pozostaych warstw. W takim ukadzie mona atwo implementowa rdzenne zadania biznesowe
aplikacji i umoliwi realizacj tych zada nie tylko w obrbie aplikacji J2EE, ale rwnie
w innych systemach. Nasza rekomendacja dotyczca projektowania warstwy biznesowej jest
prosta: warstwa ta powinna by moliwie uproszczona, implementowana w miar moliwoci
za pomoc zwyczajnych obiektw Javy i cakowicie niezalena od pozostaych warstw architektury aplikacji. Odwoywanie si tu do komponentu takiego jak JSP albo ktrego z interfejsw J2EE typowego dla specyfiki WWW (np. interfejsu dania HTTP) jest tu niepodane. Tak samo niepodane byoby korzystanie tu bezporednio z interfejsw utrwalania
danych wykorzystywanych w warstwie trwaoci. Bo co stanie si z obiektami logiki biznesowej po pniejszej zmianie technologii utrwalania danych? Prawidowe ograniczenie takich
zalenoci eliminuje przysze problemy i umoliwia niezalene wprowadzanie zmian w innych warstwach.

Trwao
Logika biznesowa implementowana w postaci obiektw jzyka Java potrzebuje jakiego narzdzia do trwaego skadowania danych biznesowych. W wikszoci aplikacji w tej roli wystpuj relacyjne bazy danych. Mona te wykorzystywa technologie alternatywne, jak bazy
danych XML czy bazy obiektowe. Zadaniem warstwy trwaoci jest udostpnienie tej funkcjonalnoci w aplikacji. Logika biznesowa nie powinna by zalena od warstwy trwaoci, wic
w modelu biznesowym nie naley odwoywa si wprost do interfejsw skadowiska danych.
Utrwalanie obiektw realizuje si na rne sposoby, od obiektw DAO (Data Access
Object), zalenych zazwyczaj od interfejsw dostpu do baz danych i jzykw zapyta takich
jak SQL. Takie podejcie jest odpowiednie w przypadku niewielkiego zestawu prostych
obiektw, z zalet zwikszonej elastycznoci. W innych podejciach uwzgldnia si interfejs
trwaoci Java Persistence API (JPA), wyrafinowane szkielety ORM (Object-Relational Mapping),
jak Hibernate czy TOPLink, oraz podejcia angaujce obiektowe bazy danych. Utrwalanie
obiektw byo przedmiotem intensywnych prac i szczegowe omawianie tego zagadnienia
wykracza poza zakres tematyczny niniejszej ksiki.

Prezentacja wynikw
Ta warstwa grupuje kod i zasoby niestanowice kodu (pliki HTML, XML czy obrazki), lecz
wykorzystywane do prezentowania wynikw dziaania aplikacji uytkownikowi. Zazwyczaj
skada si z niewielkiej iloci kodu, a tene kod dotyczy wycznie formatowania i prezentowania danych. Na przykad strona JSP warstwy prezentacji wynikw moe zawiera fragmenty kodu w jzyku Java, wypisujcego saldo konta na dynamicznie generowanej stronie
WWW. We wzorcu MVC odpowiada to koncepcji widoku.
Standard J2EE udostpnia komponenty JSP i serwlety przewidziane do implementowania warstwy prezentacji. Komponenty te s obsugiwane poprzez bogaty zestaw interfejsw
do przetwarzania HTML i XML, tworzenia obrazkw, zarzdzania adresami URL i oglnie
do obsugi wszystkich zada zwizanych z budow interfejsu uytkownika poprzez WWW.

Rozdzia 5. Architektura i projektowanie aplikacji WWW

145

Wzorzec MVC w aplikacji WWW


Wzorzec MVC (Model-Controller-View) stanowi elegancki koncepcyjny model podziau zada
w serwerowej stronie aplikacji WWW. Aplikacj implementuje si jako poczenie serwletw,
stron JSP, usug i waciwego kodu w jzyku Java. Prezentowane i polecane tutaj podejcie
to jedno z moliwych podej do podziau odpowiedzialnoci i wyeliminowania saboci
tkwicych w wykorzystywanych technologiach. Koncepcja MVC wywodzi si z systemu
Smalltalk-80 i promuje warstwowe podejcie przy projektowaniu i tworzeniu graficznych
interfejsw uytkownika. Oto podstawowe koncepcje uczestniczce w MVC:
model obsugujcy logik aplikacji i logik biznesow,
widok obsugujcy logik prezentacji,
kontroler przyjmujcy i rozprowadzajcy wejcie (z klawiatury i myszy).

Wzorzec MVC powsta jako sposb oddzielenia kodu modelowego (czyli kodu niezwizanego z interfejsem uytkownika) od kodu prezentacyjnego i sterujcego. Kod modelowy
nie powinien zawiera adnej wiedzy o interfejsie, a jedynie rozgasza powiadomienia o wszelkich zmianach stanu do komponentw zalenych, ktrymi w klasycznym ujciu s widoki.
Taki schemat zapewnia dobr separacj pomidzy trzema wymienionymi warstwami,
za to boryka si z dwoma wadami. Po pierwsze, postrzeganie modelu jest uproszczone i nie
uwzgldnia rozrnienia pomidzy logik aplikacji (na przykad przepywem sterowania pomidzy skadowymi stronami WWW aplikacji) i logik biznesow (czyli np. przetwarzaniem
patnoci). Po drugie, w wikszoci systemw okienkowych i bibliotek funkcje kontrolera
i widoku s czone w pojedynczym elemencie interfejsu, co redukuje uyteczno koncepcyjnego podziau na kontroler i widok.
Pierwotne rozumienie architektury MVC ulegao wic ewolucji. Obecnie pojcie kontrolera odnosi si do obiektu obsugujcego logik aplikacji, a pojcie modelu zarezerwowano dla
obiektw biznesowych. Bdziemy wic tak okrela obiekty biznesowe, a pojcia kontroler
wejcia i kontroler aplikacji odnosi do dwch podstawowych typw kontrolerw aplikacji.
W popularnych ramach projektowych Javy, jak Struts, JSF czy Spring, koncepcje MVC
s wcielane w ycie jako poczenie kodu w jzyku Java, stron JSP, serwletw i zwyczajnych
obiektw Javy realizujcych zadania rnych komponentw. Owe ramy projektowe koncentruj si na oddzieleniu widoku od kontrolera, ale niekoniecznie sugeruj sposoby oddzielenia
kontrolerw, czyli logiki aplikacji, od logiki biznesowej. W kontekcie WWW dwojakie stosowanie pojcia kontrolera (jako kontrolera wejcia i kontrolera aplikacji) jest jak najbardziej
poprawne. W przypadku aplikacji HTTP wejcie i prezentacja s od siebie cakiem rozdzielone, podany jest wic kontroler wejcia oddzielony od widoku. A w przypadku aplikacji o jakiejkolwiek realnej zoonoci trzeba jeszcze uwzgldni byt kontrolera aplikacji
jako oddzielajcego szczegy przepywu sterowania w aplikacji od szczegw implementacji logiki biznesowej.
W nastpnych podrozdziaach bdziemy omawia podstawow struktur obiektw w ramach projektowych MVC dla WWW (zob. rysunek 5.4). Architektura ta jest implementowana przez liczne wymienione wczeniej szkielety aplikacyjne.

146

Cz II Tworzenie aplikacji WWW w Javie

RYSUNEK 5.4. MVC dla aplikacji WWW

Kontroler wejcia
Centralnym elementem jest kontroler wejcia. W systemie dziaa jeden taki kontroler dla
wszystkich stron WWW. Kontroler wejcia odbiera i analizuje dane wejciowe, wykrywa mechanizm przekazywania danych, wyuskuje z dania niezbdne informacje, we wsppracy
z kontrolerem aplikacji identyfikuje nastpn operacj okrelan mianem akcji i wywouje ow akcj w odpowiednim kontekcie (zmontowanym z zestawu danych wejciowych). Uruchomienie kontrolera wejcia jako pojedynczego komponentu pozwala na wyizolowanie w projekcie caoci wiedzy zwizanej z obsug protokou HTTP i konwencji
nazewniczych obowizujcych na poziomie da HTTP. W ten sposb eliminuje si powielanie kodu i zmniejsza czny rozmiar kodu. Dziki temu mona te atwiej modyfikowa kad z funkcji przetwarzajcych dane wejciowe, poniewa modyfikacje s ograniczone
do pojedynczego komponentu i nie wpywaj na pozostae komponenty aplikacji. Kontroler
wejcia jest typowo realizowany za porednictwem serwletu; czsto wyrnia si osobny
serwlet, obsugujcy dania dostpu do aplikacji za porednictwem protokou HTTP z poziomu zwyczajnej przegldarki WWW, i drugi, obsugujcy dostp do aplikacji z poziomu
urzdze operujcych protokoem i przegldark WAP.

Kontroler aplikacji
Kontroler aplikacji jest najczciej zwyczajnym obiektem jzyka Java. Jego zadaniem jest
koordynowanie dziaa zwizanych z przepywem sterowania w aplikacji, obsuga bdw,
utrzymywanie informacji zwizanych ze stanem aplikacji (w tym referencji do obiektw biznesowych) i wybieranie odpowiedniego widoku do wywietlenia. Kontroler aplikacji musi

Rozdzia 5. Architektura i projektowanie aplikacji WWW

147

rozumie dania i ich udzia w przepywie sterowania w aplikacji oraz przekazywa te dania w celu uzyskania odpowiedzi. dania WWW s kodowane w strumieniach tekstowego
protokou HTTP, a wartoci parametrw maj w nich posta par klucz-warto (oba elementy pary to cigi znakw). Kontroler aplikacji musi dysponowa mechanizmem odwzorowania takich par na obiekty aplikacji, ktre zarzdzaj przepywem danych. W wikszoci
szkieletw aplikacyjnych te odwzorowania s reprezentowane za pomoc rozbudowanych
plikw konfiguracyjnych w formacie XML, jak w przypadku pliku struts-config.xml wykorzystywanego w Struts. Na przykad kontroler aplikacji rozpoznaje cigi URI takie jak poniszy:
/leagueplanet/addPlayer.do

Bazuje si tu na konwencji nazewniczej, co ma opisywane wczeniej wady, ale poniewa jest to jedyny komponent wykorzystywany w taki sposb, skutki tych saboci s minimalizowane. W lepszym projekcie pojedynczy kontroler aplikacji jest zazwyczaj odpowiedzialny za wiele stron WWW i wiele operacji. W najprostszej aplikacji pojedynczy kontroler
aplikacji moe obsugiwa wszystkie strony. W aplikacji rozbudowanej wyznacza si zazwyczaj kilka kontrolerw aplikacji, kady do innego obszaru jej dziaalnoci. Poprzez wykorzystywanie pojedynczego obiektu jako wsplnego, centralnego punktu odniesienia dla hermetyzacji informacji kontroler aplikacji rozwizuje zagadnienia ukrywania informacji i konwencji
nazewniczych. Zamiast przechowywa izolowane skrawki informacji w atrybutach sesji, skaduje si je w obiektach biznesowych. Do ledzenia dziaania kontrolera aplikacji i obiektw
biznesowych mona wykorzysta klasyczne mechanizmy jzyka programowania, co bardzo
uatwia konserwacj i modyfikowanie kodu. Do tego cao podlega statycznej kontroli typw,
co jest niejako dodatkow metod walidacji danych.
Kontrolery aplikacji konstruuje si rozmaicie. W szkielecie Struts reprezentuje si je jako
akcje, podczas gdy w JSF okrela si je mianem managed backing beans. W Struts przewiduje
si obecno wielu akcji. Jeli na przykad dana aplikacja ma dwa przypadki uycia tworzenie druyn i dodawanie graczy do druyn moemy zrealizowa te przypadki w aplikacji za pomoc dwch odpowiednich akcji. W aplikacji Struts klasy implementujce takie akcje
mogyby wyglda tak, jak na listingu 5.2.

Listing 5.2. Przykadowy kod klasy akcji (Struts)


public class CreateTeamAction
{
public void execute(...){}
}
public class AddPlayerAction
{
public void execute(...){}
}

Akcje dotyczce druyny i graczy s w oczywisty sposb powizane. Cho by przez to,
e graczy dodaje si do druyn. Ale w Struts nie przewidziano mechanizmu do grupowania
akcji. Nie mona wic zgrupowa wielu akcji bdcych czci tego samego przepywu, jak
na przykad przy procesie rejestracji konta online.

148

Cz II Tworzenie aplikacji WWW w Javie


Te braki szkieletu aplikacyjnego Struts s wypeniane przez inne mechanizmy, bazujce
na Struts, jak w projekcie Eclipse Pollinate, w ktrym kontroler aplikacji to obiekt Javy
zwany przepywem w obrbie strony (ang. page flow). Jest to klasa ujmujca grup akcji jako jej
metody i definiujca struktur opisujc przepyw pomidzy poszczeglnymi metodami.
W Pollinate powysze przypadki uycia zrealizowalibymy za pomoc pojedynczej klasy
przepywu dla strony (klasy akcji i ich zachowanie z przykadowego listingu 5.2 zostayby
zaimplementowane jako metody klasy przepywu).
Moliwo grupowania akcji i kojarzenia ich z obiektem reprezentujcym przepyw
sterowania w obrbie strony ilustruje kod z listingu 5.3. Posiadanie wsplnego kontrolera
aplikacji dla caej grupy akcji zwiksza elastyczno wyraania logiki aplikacji. Do tego mona
zarzdza stanem przepywu w obrbie pojedynczego obiektu, a nie za porednictwem da
HTTP i interfejsw obsugi sesji.

Listing 5.3. Przykadowy kod klasy przepywu page flow


public class LeacuePlanetPageFlow extends PageFlowController
{
public Forward createTeam(){..}
public Forward addPlayer(){..}
}

Dwie najpopularniejsze obecnie realizacje modelu MVC w programowaniu aplikacji


WWW, czyli Struts i JSF, s w istocie bardzo podobnymi koncepcjami. Niektrzy uwaaj,
e bliszy zaoeniom MVC jest JSF, a to ze wzgldu na dostpno komponentw stanowych w warstwie widoku i obsug modelu zdarzeniowego do obsugi interakcji (np. zdarze kliknicia przycisku). JSF okrela te rozbudowan bibliotek standardowych znacznikw,
ktre wydatnie zmniejszaj ilo kodu Java w stronach JSP (zob. listing 5.4).

Listing 5.4. Znaczniki JSF w JSP


<h:panelGroup>
<h:commandButton id="submitCreateTeam"
action="#{JsfLeaguePlanetBean.createTeam}" value="Create Team" />
<h:commandButton id="submitAddPlayer"
action="#{JsfLeaguePlanetBean.addPlayer}" value="Add Player" />
</h:panelGroup>

Trzeba jednak zawsze pamita , e wszystkie te szkielety aplikacyjne bazuj na bezstanowym protokole HTTP. W JSF wystpuje koncepcja kontrolera aplikacji w postaci komponentw managed backing beans (listing 5.5). Te komponenty mog ujmowa grupy powizanych akcji, czego brakuje w Struts. Wreszcie koncepcja przepywu w obrbie strony nie jest
implementowana ani w JSF, ani w Struts. Informacja o takim przepywie jest niejawnie zaszyta w kontrolerach i plikach konfiguracyjnych XML.

Rozdzia 5. Architektura i projektowanie aplikacji WWW

149

Listing 5.5. Komponent backing bean w JSF


public class JsfLeaguePlanetBean
{
public String createTeam(...){}
public String addPlayer(...){}
}

Kontroler wejcia dla kadego dania wywoa jedn z wielu moliwych akcji. Jednym
z jego zada jest okrelenie waciwego kontekstu akcji przeznaczonej do wywoania. Wybr akcji zaleny jest zarwno od danych wprowadzonych na wejcie, jak i od biecego
stanu aplikacji; decyzja naley wic do kontrolera aplikacji. Wynik tego procesu decyzyjnego jest reprezentowany poprzez obiekt ApplicationController (ApplicationController to
implementacja wzorca projektowego Command, opisywanego w Gamma 1995).
Obiekty biznesowe s zwyczajnymi obiektami Javy, zawierajcymi wycznie logik biznesow, bez jakichkolwiek informacji o warstwach ssiadujcych. Jedynym komponentem
wyznaczonym do manipulowania obiektami biznesowymi jest za wanie kontroler aplikacji
(zob. rysunek 5.4). Dziki temu znacznie atwiej jest zarwno zaimplementowa , jak i przetestowa logik biznesow, bo moe si to odbywa w cakowitej izolacji od caej kopotliwej infrastruktury WWW. Jeli aplikacja jest prawidowo zaprojektowana, obiekty biznesowe
stanowi wyizolowan warstw, zdatn do wykorzystania zarwno w aplikacji WWW, jak
i w aplikacjach zakadajcych dostp z poziomu innych rodzajw klientw, a nawet w klasycznych aplikacjach stanowiskowych.

Widok
W aplikacji J2EE widoki s najczciej stronami JSP, ktre odwouj si do kontrolera aplikacji i obiektw biznesowych. Widoki powinny zawiera moliwie mao kodu, a wic delegowa wikszo swoich zada do kontrolera aplikacji albo obiektw biznesowych. Na samej
stronie powinien pozosta jedynie kod bezporednio zwizany z prezentacj biecej strony.
Specyfikacja JSP udostpnia te biblioteki znacznikw (ang. taglibs) do definiowania wasnych
znacznikw, ujmujcych bardziej rozbudowane zachowania widoku w przypadku skomplikowanych widokw zaleca si przenoszenie kodu wanie do samodzielnie definiowanych
znacznikw. Na rysunku 5.4 byo wida dwa rne mechanizmy widoku. Kontroler wyjcia
JSP wykorzystuje implementacj JSP odpowiedni dla przegldarki WWW albo WAP. Kontroler wyjcia WS reaguje na te same dania, a w odpowiedzi generuje komunikaty XML
zdatne do uytku w innych aplikacjach.

Szkielety aplikacyjne dla Javy


Programici aplikacji WWW mog przebiera pomidzy rozmaitymi otwartymi i wolnymi
(od wolno ) szkieletami aplikacyjnymi dla Javy przyjrzymy si niektrym z nich (zob.
rysunek 5.5). Szkielety te wydatnie upraszczaj tworzenie aplikacji WWW w Javie. Udostpniaj elementy znacznie polepszajce moliwo testowania kodu, uatwiaj zarzdzanie
nim i samo programowanie. Izoluj i implementuj podstawow infrastruktur aplikacji
i dobrze integruj si z serwerami aplikacyjnymi.

150

Cz II Tworzenie aplikacji WWW w Javie

RYSUNEK 5.5. Szkielety aplikacyjne dla Javy

OSGi
OSGi Alliance (dawniej Open Services Gateway Initiative) to ciao definiujce standard udostpniania platform usugowych na bazie Javy. Specyfikacja ta obejmuje szkielet aplikacyjny do
modelowania cyklu ycia aplikacji oraz rejestr usug.
Istniejce implementacje OSGi, jak Eclipse Equinox, Felix czy Knoplerfish, udostpniaj kompletne i dynamiczne modele komponentowe, ktrych brakowao w standardowych rodowiskach wykonawczych dla Javy. Dziki nim mona instalowa, uruchamia, zatrzymywa, aktualizowa i odinstalowywa aplikacje bd
komponenty nawet zdalnie.
OSGi zyskuje uznanie jako uoglniona platforma dla usug, poniewa dobrze si skaluje, od
urzdze wbudowanych po systemy korporacyjne. Przykadem systemu bazujcego na OSGi
jest Eclipse (i co za tym idzie WTP). Na bazie platform OSGi swoje serwery aplikacyjne nastpnej generacji konstruuj takie firmy jak IBM i BEA. Co ciekawe, OSGi moemy te wykorzysta sami do budowania prostych komponentw biznesowych i usug, ktre w czasie wykonania
s skadane do postaci usugi biznesowej. W OSGi mona na przykad uruchamia aplikacje
bazujce na Spring 2.0.

Apache Beehive
Projekt Beehive ma na celu udostpnienie szkieletu aplikacyjnego dla prostych komponentw
sterowanych metadanymi, redukujcych ilo kodu niezbdnego w aplikacjach J2EE. Rozwizania z Beehive dotycz wszystkich trzech warstw modelowej aplikacji WWW. Szkielet
wykorzystuje adnotacje, zwaszcza metadane wedug JSR 175 (JSR 175). Odwouje si te

Rozdzia 5. Architektura i projektowanie aplikacji WWW

151

do innych projektw Apache, jak Struts i Axis. Oferuje NetUI do prezentacji, szkielet Controls
do prostych komponentw i WSM (Web Service Metadata implementacja JSR 181) oraz
bazujcy na adnotacjach model do konstruowania usug WS w Javie (JSR 181).

Apache Struts
Struts to szkielet aplikacyjny udostpniajcy warstw kontroln bazujc na standardowych
technologiach WWW w Javie wykorzystuje si tu JSP, serwlety oraz inne projekty Apache.
Jest to swoista implementacja wzorca projektowego MVC.

JavaServer Faces
JSF to standard JSR 127 wywodzcy si z JCP (Java Community Process) (JSR 127), definiujcy zestaw znacznikw JSP oraz klas Java upraszczajcych konstruowanie interfejsu uytkownika dla aplikacji WWW. Powszechnie uwaa si, e JSF ma szans zestandaryzowa narzdzia i komponenty. JSF to szkielet dla warstwy prezentacji, z koncepcjami zapoyczonymi
z MVC. JSF to oficjalny element specyfikacji J2EE 5.

Spring
Spring to szkielet aplikacyjny obejmujcy komplet trzech warstw typowej aplikacji WWW
w Javie. Szkielet dla wszystkich swoich komponentw implementuje wzorce projektowe
Inversion of Control oraz Dependency Injection. Udostpnia te prosty kontener do implementowania logiki biznesowej za pomoc zwyczajnych obiektw Javy (POJO) i dziki temu
moe wyeliminowa potrzeb stosowania komponentw EJB. Do tego Spring udostpnia
mechanizmy do zarzdzania danymi aplikacji.

Pico Container
Pico Container jest prostym szkieletem aplikacyjnym, rwnie bazujcym na wzorcach
Inversion of Control i Dependency Injection. Podobnie jak Spring, powsta jako odpowied
na nadmiern zoono tworzenia aplikacji J2EE, a szczeglnie na trudnoci zwizane z programowaniem komponentw EJB.

Hibernate
Hibernate to szkielet relacyjnego odwzorowania obiektw ORM (Object Relational Mapping).
Pozwala programistom implementowa relacyjne utrwalanie obiektw oraz odpytywa usugi
o obiekty Javy bez koniecznoci modyfikowania ich kodu.
Specyfikacja komponentw encyjnych EJB3, a zwaszcza specyfikacja interfejsu trwaoci
JPA (Java Persistent API), ktra z niej wyewoluowaa, w obliczu zoonoci dostpnych rozwiza standardowych zwiksza jeszcze atrakcyjno Hibernate i podobnych szkieletw ORM.

152

Cz II Tworzenie aplikacji WWW w Javie

Architektura usugowa SOA


SOA (Service Oriented Architecture) dotyczy wydzielania czci waciwej dziaalnoci aplikacji
do postaci istotnych jednostek, zwanych usugami, oraz montowania aplikacji poprzez integrowanie tyche usug. Ukierunkowanie na usugi oznacza ujmowanie poszczeglnych elementw logiki biznesowej. Usuga to wcielenie fundamentalnej zasady programowania obiektowego, czyli oddzielenia implementacji od interfejsu. W poczeniu ze standardowymi
jzykami opisu (jak XML), powszechnymi protokoami transportowymi (HTTP) oraz moliwoci wyszukiwania i kojarzenia usugodawcy w czasie wykonania SOA okazuje si wietn
technologi integrowania rozmaitych systemw. SOA i usugi WWW Web Service opieraj
si na licznych standardach, w tym XML, XML Schema, WSDL (Web Service Description
Language), UDDI (Universal Description, Discovery and Integration), SOAP, JAX-RPC i wielu
specyfikacjach WS-*. Szczegowe omwienie SOA dalece wykracza poza tematyk niniejszej
ksiki, zajmiemy si jednak tym, jak mona w WTP montowa aplikacje WWW ukierunkowane usugowo, gwnie na bazie technologii Web Service.

Udostpnianie usug. Warstwa usugowa


Zadaniem warstwy usugowej w aplikacji jest eksponowanie poszczeglnych funkcji aplikacji
i funkcji biznesowych jako wyodrbnionych usug. O przydatnoci czy ciekawoci aplikacji
wiadcz przecie wycznie wykorzystujcy j klienci (jeli w lesie przewrci si drzewo,
a nikogo nie ma w pobliu, to czy sycha trzask?).
Z usug, w przeciwiestwie do aplikacji, mona korzysta rozmaicie:
za porednictwem rozbudowanych aplikacji klienckich RCA (Rich Client Application),

ktre konsumuj usugi wielu usugodawcw;


w systemach osadzonych (telefony komrkowe);
w portalach i aplikacjach WWW, od zdalnych portali i aplikacji WWW po warstwy

sterujce systemu pionowego, w ktrych warstwa usugowa wykorzystywana jest


do odwoa do modelu biznesowego, w rozbudowanej implementacji MVC
z warstw usugow w postaci opisanej dalej;
w projektach integracyjnych, za porednictwem jzyka BPEL (Business Process

Execution language) automatyzujcego procesy biznesowe;


w systemach udostpniajcych usugi bdce wynikiem zmontowania usug

dostpnych skdind w nowym modelu biznesowym.


Uzupenienie omwionej poprzednio architektury o warstw usugow (jak na rysunku 5.6) pozwala na tworzenie aplikacji, ktra nie tylko jest uyteczna dla uytkownikw kocowych, ale te moe wspdziaa z innymi systemami informatycznymi. Dodatkowa warstwa
skada si z elementw takich jak usugi Web Service, rejestry usug (UDDI), kontrakty
(WSDL) i elementy poredniczce (proxy), ktre wi te usugi z naszymi aplikacjami.
Warstwa usugowa eksponuje cile zdefiniowane interfejsy do identycznego jak poprzednio modelu biznesowego. Interfejs usugi jest okrelany przez kontrakt opisywany w jzyku

Rozdzia 5. Architektura i projektowanie aplikacji WWW

153

RYSUNEK 5.6. Model rozszerzony o warstw usugow

WSDL. W danym modelu biznesowym mona korzysta z procesw i logiki bazujcej na


usugach systemw zewntrznych. Konsumentom usug nie s ujawniane szczegy wewntrznego modelu biznesowego. Wszystkie szczegy techniczne niezbdne do konsumowania usug s opisywane przez kontrakt wyraony w WSDL.

Gdzie pasuje SOA?


Warto byoby si zastanowi, jak ma si SOA do tradycyjnego podziau warstwowego aplikacji.
Nasuwaj si od razu takie pytania: Czy SOA to cz warstwy prezentacji? Czy SOA zastpuje
warstw prezentacji warstw usugow? A co z logik biznesow, gdzie ona teraz przynaley?
Ot usuga nie ma widoku; skoro tak, nie ma potrzeby wydzielania warstwy prezentacji. Zastpuje j zazwyczaj warstwa usugowa. Mona wic powiedzie, e warstwa usugowa odgrywa
rol warstwy prezentacji; usuga jest prezentacj, widokiem perspektywy biznesowej w formie
dostpnej do zautomatyzowanego uycia przez inne aplikacje.
Trudniejsze jest pytanie o to, czy usugi wchodz w skad modelu aplikacji i jej logiki biznesowej. Najprociej byoby odpowiedzie nie, ale to nie wyczerpuje zagadnienia. Logika biznesowa nie jest zawsze i wycznie modelowana w formie, ktr da si natychmiast i bezporednio
udostpni jako usugi. Dobry model obiektowy cechuje si wysok ziarnistoci i skada z wielu
niewielkich, ale prostych do ogarnicia obiektw z atwymi do opanowania i wykorzystywania
metodami. Obiekty te ujmuj istotne koncepcje biznesowe i dane, ale nie s specjalnie przydatne do tworzenia usug. Usugi s zazwyczaj projektowane na bazie przypadkw uycia; reprezentuj zachowanie biznesowe jako cig zdarze , jak np. patno za rezerwacj. Drobnoziarniste obiekty modelu pojedynczo nie ujmuj takich transferw. Usugi stanowi wic
mieszank logiki biznesowej i logiki aplikacji. W naszej przykadowej aplikacji League Planet
warstwa usugowa dysponowaaby obiektem obsugujcym tworzenie nowej ligi. Warstw logiki
biznesowej omwimy w rozdziale 8.

154

Cz II Tworzenie aplikacji WWW w Javie

Konsumowanie usug zestawianie


Aplikacje konsumuj usugi przez zestawianie i czenie treci bd usug udostpnianych
przez usugodawcw. Mona wic zrealizowa nowy proces biznesowy na bazie integracji
usug wiadczonych przez rnych usugodawcw i uzupeni cao o now logik biznesow, nowe reguy i moliwoci. Udostpnione treci podlegaj rekompozycji i odwzorowaniu do modelu biznesowego aplikacji klienckiej i s w niej prezentowane w nowy i unikatowy
sposb, niekoniecznie dostpny od ktregokolwiek z usugodawcw usug skadowych
z osobna. To podstawowe zaoenie SOA.
Modelowanie procesu biznesowego i montowanie usug moe konsumowa usugi
w sposb standaryzowany, za porednictwem mechanizmw usug WWW. Warstwa usugowa realizuje abstrakcj wielu rnych systemw biznesowych, a usugi tej warstwy mona
wykorzystywa do montowania nowych procesw biznesowych. W WTP nie mamy do dyspozycji narzdzi do zestawiania usug w taki sposb, ale producenci tacy jak IBM, Oracle
czy BEA rozszerzyli WTP o moliwo projektowania i wykonywania takich procesw skadanych. Suy tam do tego jzyk BPEL (Business Process Execution Language), standard OASIS
bdcy odpowiednikiem jzyka XML dla dziedziny zestawiania i kompozycji usug w procesy.

Studium przypadku League Planet


W tym podrozdziale sprbujemy opracowa architektur dla naszej fikcyjnej strony WWW
League Planet (zob. podrozdzia Przedstawiamy League Planet w rozdziale 1.). Z punktu
widzenia architektury League Planet jest systemem wieloaspektowym, z rnymi profilami
dla rnych uytkownikw.
Po pierwsze, mamy wrd nich ludzi, ktrzy umieszczaj treci w systemie. S to osoby
zainteresowane sportem i wykorzystujce League Planet do prowadzenia wasnych amatorskich lig sportowych. Odwiedzaj stron WWW i tworz nowe ligi, w ramach ktrych mog
rejestrowa druyny, graczy, terminarze rozgrywek, miejsca rozgrywek, wyniki, statystyki
i wiele rozmaitych innych informacji. League Planet ma dla nich udostpnia wysoce dynamiczny interfejs WWW, ktry pozwoli im wchodzi w bezporednie interakcje z systemem.
Korzystanie z systemu polega na przechodzeniu pomidzy stronami WWW i wykonywaniu czynnoci takich, jak przegldanie prezentowanych informacji, wypenianie formularzy i zamawianie dbr oferowanych przez partnerw biznesowych League Planet. Do obsugi takich uytkownikw League Planet musi mie warstw prezentacji. Warstwa prezentacji
bdzie zrealizowana na bazie stron JSP. Aby ograniczy ilo kodu opisujcego interfejs, wykorzystamy bibliotek znacznikw dla Javy. Warstwa prezentacji bdzie ograniczona do kodu wywietlajcego informacje i przyjmujcego dane od uytkownika. Przepyw sterowania
w aplikacji bdzie nalee do zada warstwy sterujcej.
Warstwa kontroli jest odpowiedzialna za takie zadania, jak weryfikacja poprawnoci wprowadzanych danych, przepyw sterowania na stronie i pomidzy nimi oraz wsppraca z warstw
modelu biznesowego w celu realizacji zada biznesowych i udostpniania treci dla warstwy
widoku (prezentacji).

Rozdzia 5. Architektura i projektowanie aplikacji WWW

155

Kolejny profil dla League Planet to aplikacje zewntrzne, np. aplikacje sponsorw, ktrzy
potrzebuj dostpu do pewnych usug. League Planet generuje spor cz swojego przychodu z reklam ogoszeniodawcw. Informacje o druynach, graczach i odwiedzajcych oraz
ich profilach mog si przyda do przygotowywania skuteczniejszych reklam. Profile te su
do generowania banerw reklamowych i odnonikw do stron odpowiednich partnerw biznesowych. Informacje te s udostpniane systemom partnerw League Planet za porednictwem zbioru usug, realizowanych w warstwie usugowej; samo wywietlanie reklam
rwnie realizowane jest na bazie usug, tym razem zewntrznych (udostpnianych w systemach partnerw biznesowych).
Wreszcie serwis League Planet wspiera te swoje organizacje partnerskie, oferujc wikszo swoich treci i usug online dla zewntrznych serwisw. Niektre z nich to darmowe
i abonamentowe informacje o ligach, graczach, druynach, profilach odwiedzajcych,
ogoszeniach, wiadomoci ze wiatka oraz doniesienia o najnowszych wynikach spotka. Jako
dostawca usug WWW League Planet jest rdem unikatowych treci i usug, przeznaczonych do konsumpcji w aplikacjach zewntrznych.
Aby zrealizowa taki system, wykorzystamy architektur opisan w poprzednim podrozdziale (zob. rysunek 5.6). Aby zademonstrowa planowany sposb dziaania systemu, wemy scenariusz rozpisany na diagramie z rysunku 5.7.

RYSUNEK 5.7. Warstwa usugowa

Aplikacja kliencka, podobna do naszej wasnej aplikacji WWW, konsumuje usugi udostpniane przez League Planet. Konsument usugi bdzie wykorzystywa jedn (bd wiele)
z udostpnianych usug Web Service za porednictwem protokou SOAP. Oba systemy maj
kompletnie rne modele biznesowe i odmienn logik aplikacji, ale bd zdolne do wspdziaania na bazie architektury SOAP. Mianowicie, klient wysya danie w celu pozyskania
informacji o zespoach grajcych w danej lidze. danie jest wysyane za porednictwem

156

Cz II Tworzenie aplikacji WWW w Javie


protokou SOAP. Warstwa usugowa w League Planet odbiera danie; rodowisko wykonawcze usug WWW rozpracowuje danie i odwzorowuje dane wejciowe opisane w przysanym XML na odpowiadajce im obiekty klas Javy. Kod Javy w LeagueService odbiera takie
danie tak, jakby byo zwyczajnym wywoaniem (komunikatem) z obiektu Javy. Warstwa
usugowa wysya do warstwy modelowej komunikaty Javy majce na celu pozyskanie z bazy
danych informacji o zespoach w danej lidze; zespoy te s odwzorowywane na obiekty Javy
i w takiej postaci przekazywane do warstwy usugowej. Tam wreszcie dochodzi do serializacji obiektw wynikowych, to jest konwersji obiektw Javy na ich reprezentacj tekstow
w jzyku XML, okrelon poprzez typy danych odpowiedzi opisane WSDL. Odpowied jest
potem zwracana do aplikacji klienckiej w formacie XML. Konsument usugi odbierajcy tak
odpowied wykorzystuje podobne technologie do odwzorowania odpowiedzi na jego wasne
wewntrzne obiekty modelu biznesowego i na przykad prezentuje pozyskane dane o zespoach na swojej stronie WWW.

Podsumowanie
Koncepcje omawiane w tym rozdziale powinny okaza si pomocne przy projektowaniu
aplikacji WWW, ktre od pocztku maj mie poprawn architektur. Zaprezentowalimy
szereg rnych podej i omwilimy rne gotowe szkielety aplikacyjne wcielajce te podejcia. Na bazie prezentowanych tu wzorcw omwilimy zyski jakociowe, bo wzorce te
narzucaj i promuj uznane zasady projektowania obiektowego. Omwione szkielety aplikacyjne s pomoc szczeglnie istotn dla projektantw niedowiadczonych w metodologii
obiektowej, bo daj im punkt wyjcia do projektu wysokiej jakoci, bez koniecznoci zagbiania si w szczegy implementacji systemu, na ktrym ta jako w duej mierze bazuje.
Szkielety wzorowane na MVC, omawiane w tym rozdziale, mogyby zosta rozszerzone
w kilku dziedzinach, uwzgldniajc na przykad rne charakterystyczne dla WWW wymagania, jak bezpieczestwo, walidacja danych itp. Zalecamy wasne eksperymenty z wymienionymi technologiami, bo to najlepiej pozwoli ogarn ich struktur i pozna zastosowane
kompromisy architekturalne; w ten sposb najlepiej mona si te zorientowa w zdatnoci
danego rozwizania w danej dziedzinie zastosowa.
Po wykadzie z projektowania moemy kontynuowa nauk wykorzystywania WTP przy
tworzeniu wasnych aplikacji WWW. W rozdziale 6. zajmiemy si konkretnie rnymi stylami
tworzenia aplikacji WWW w Javie i rnymi organizacjami projektu.

You might also like