Wydawnictwo Helion
ul. Koœciuszki 1c
44-100 Gliwice
tel. 032 230 98 63
Eclipse Web Tools Platform.
Tworzenie aplikacji WWW
w jêzyku Java
Autor: Naci Dai, Lawrence Mandel, Arthur Ryman
T³umaczenie: Przemys³aw Szeremiota
ISBN: 978-83-246-1391-5
Tytu³ orygina³u:
Format: 168x237, stron: 744
Zwiêksz swoj¹ wydajnoœæ dziêki platformie WTP!
•
Jak wykorzystaæ œrodowisko Eclipse do tworzenia aplikacji internetowych?
•
W jaki sposób zorganizowaæ projekt aplikacji?
•
Jak przeprowadziæ w aplikacjach testy jednostkowe?
Eclipse to zintegrowane œrodowisko programistyczne. Projekt zosta³ zapocz¹tkowany
przez firmê IBM, natomiast aktualnie jest rozwijany przez Fundacjê Eclipse. Dziêki
licznym dodatkom, pluginom i podprojektom zyska³ on ogromn¹ popularnoœæ i jest w tej
chwili jednym z narzêdzi najczêœciej wybieranych do tworzenia aplikacji w jêzyku Java
— i nie tylko. Natomiast projekt WTP (skrót od ang. Web Tools Platform) dziêki swoim
rozszerzeniom u³atwia tworzenie aplikacji WWW.
„Eclipse Web Tools Platform. Tworzenie aplikacji WWW w jêzyku Java” jest d³ugo
oczekiwan¹ na polskim rynku ksi¹¿k¹, poœwiêcon¹ tej w³aœnie platformie. Autorzy
przedstawiaj¹ tu inspiruj¹c¹ historiê tego rozwi¹zania, strukturê projektu oraz sposób
konfiguracji Web Tools Platform. Kolejne rozdzia³y przybli¿¹ Ci zagadnienia zwi¹zane
z warstw¹ prezentacji, logiki biznesowej i trwa³oœci. Dowiesz siê, w jaki sposób
wykorzystaæ narzêdzia dostarczane przez WTP do przyspieszenia prac w ka¿dej z tych
warstw. W zakresie podejmowanych zagadnieñ znajduj¹ siê równie¿ tematy zwi¹zane
z testami integracyjnymi i wydajnoœciowymi.
•
Konfiguracja Web Tools Platform
•
Architektura aplikacji WWW
•
Podzia³ projektu na warstwy
•
Sposób wykorzystania narzêdzia Maven
•
Wykorzystanie us³ug 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 ródowy przykadów ............................................................................................. 30
League Planet .................................................................................................................. 30
Podsumowanie ............................................................................................................... 32
Rozdzia 2. Wprowadzenie do Eclipse Web Tools Platform ........................................................... 33
Narodziny WTP ............................................................................................................. 33
Ekonomika WTP ............................................................................................................ 35
Redukcja nakadów programistycznych .................................................................. 36
Generowanie przychodu .......................................................................................... 38
Struktura WTP ............................................................................................................... 42
Przedmiot WTP ....................................................................................................... 43
Projekty skadowe WTP .......................................................................................... 44
Architektura WTP .................................................................................................... 46
Podprojekt WST ....................................................................................................... 48
Podprojekt JST ......................................................................................................... 53
6
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 komunikatów 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 archiwów ZIP ................................................................................ 118
Instalowanie materiaów zewntrznych ................................................................ 120
JDK ......................................................................................................................... 123
Weryfikowanie instalacji ........................................................................................ 124
Aktualizowanie WTP ............................................................................................. 125
Spis treci
7
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
Wspólne 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 projektów 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 projektów ......................................................... 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
8
Spis treci
Podejcie 1. Projekty statycznych stron WWW, HTML i edytory
kodu ródowego .......................................................................................................... 225
Projekty statycznych aplikacji WWW .................................................................... 225
HTML .................................................................................................................... 228
Edytory kodu ródowego ..................................................................................... 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
9
Podejcie 2. Tworzenie sesyjnych komponentów EJB .............................................. 347
Dodawanie serwera JBoss ...................................................................................... 351
XDoclet ................................................................................................................... 354
Projekty EJB ........................................................................................................... 357
Tworzenie komponentów 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
Krótkie wprowadzenie do MDB ........................................................................... 380
Tworzenie komponentu komunikatowego .......................................................... 380
Tworzenie kolejki komunikatów w JBoss ............................................................ 384
Tworzenie klienta kolejki JMS .............................................................................. 385
Podsumowanie podejcia 3. ................................................................................... 388
Podsumowanie ............................................................................................................. 389
Rozdzia 9. Warstwa trwaoci ................................................................................................... 391
Projekty warstwy trwaoci .......................................................................................... 392
Odwzorowanie obiektów w bazie danych za pomoc interfejsu JDBC ............. 394
Odwzorowanie obiektów w bazie danych za porednictwem
komponentów encyjnych ...................................................................................... 395
Odwzorowanie obiektów w bazie danych za porednictwem
gotowych szkieletów 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 góry” ....................................................... 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 klientów 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 komunikatów 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 serwletów ............................................................................................. 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 testów .............................................................................. 532
Przypadek testowy JUnit ....................................................................................... 532
Zestaw testów 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 serwerów ................................................................................. 567
Ogólnie o dodawaniu uniwersalnego adaptera serwera ............................................. 570
rodowisko wykonawcze GlassFish ............................................................................ 571
Wtyczki adapterów serwerów ...................................................................................... 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 typów plików ................................................................................ 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 elementów rozszerzajcych WSDL
w panelu edycji wizualnej ...................................................................................... 632
Dodawanie elementów 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 zasobów .............................. 661
Tworzenie wtyczki rozszerzenia infrastruktury rozwizywania zasobów ................ 664
Dodawanie zasobów do katalogu XML ...................................................................... 665
Katalog XML .......................................................................................................... 667
Dodawanie pojedynczego zasobu do katalogu XML ........................................... 667
Dodawanie do katalogu XML zestawu zasobów .................................................. 670
12
Spis treci
Wasna strategia rozwizywania zasobów ................................................................... 673
Infrastruktura rozwizywania URI dla zasobów .................................................. 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 dwóch rodzajów systemów WWW — infrastruktury
aplikacji i infrastruktury usugi. Wielu z nas tworzy aplikacje z interfejsem WWW. Owe in-
terfejsy odwouj si do warstw biznesowych aplikacji i utrwalaj pobrane dane w bazach
danych. Dla takich rodzajów systemów architektur warstwow udostpnia infrastruktura
aplikacji. Z kolei w przypadku infrastruktury usugi mamy do czynienia ze wspóprac po-
szczególnych usug za porednictwem WWW — bez udziau uytkowników. W tym przypad-
ku mowa o architekturze zorientowanej na usugi — SOA (od Service Oriented Architecture).
Oba systemy maj cechy wspólne; w obu chodzi o zmontowanie rozlegego i popraw-
nego pod wzgldem struktury systemu WWW, opartego na prawidach zasad obiektowoci.
Przypomnimy wic wiadomoci z wykadów o projektowaniu obiektowym i zobaczymy,
jak mona je zastosowa do WWW.
Krajobraz WWW
Sie WWW ewoluuje od sieci stanowicej nonik informacji dla odbiorców-uytkowników,
w kierunku rodka komunikacji i wspópracy 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
R
YSUNEK
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,
które pozwalaj na komunikacj zarówno z uytkownikami, jak i aplikacjami.
W wiecie ukierunkowanym na usugi mamy mnóstwo aplikacji sieciowych: aplikacje
patnicze uruchamiane na komputerach typu mainframe, drukarki fotograficzne drukujce
zdjcia z aparatu cyfrowego czy wsady wieych wiadomoci z praktycznie dowolnej dzie-
dziny. Wszystkie te aplikacje s przykadami systemów wiadczcych pewne usugi. Kady
z takich „systemów-usugodawców” eksponuje swoje zasoby za porednictwem publicznego
interfejsu definiujcego jego usug. Nowe aplikacje uywaj takich usug i montuj z nich
nowe aplikacje, które same mog by udostpniane równie jako osobne usugi. W tym pro-
stym 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 ogól-
ny, ale w faktycznej aplikacji mona wyrónia logicznie dodatkowe warstwy, reprezentujce
i wyodrbniajce poszczególne charakterystyczne elementy architektury aplikacji. Architek-
tura fizyczna aplikacji jest tu nieistotna: wszystkie trzy warstwy mog równie dobrze dziaa
na pojedynczym serwerze aplikacyjnym i jednym komputerze albo na trzech i wicej osob-
nych serwerach aplikacyjnych. W J2EE architektur fizyczn mona zarzdza niezalenie
od warstw logicznych aplikacji.
R
YSUNEK
5.2. Aplikacje i usugi WWW
138
Cz II • Tworzenie aplikacji WWW w Javie
Najwysza warstwa to warstwa prezentacji. Jest to warstwa interfejsu uytkownika, mon-
towana zazwyczaj na bazie jzyka HTML. Modele RIA (Rich Internet Application) i AJAX
wprowadzaj zreszt do warstwy prezentacji nowsze technologie implementacji strony klienc-
kiej, 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 równie 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 adre-
sem http://www.adobe.com/platform.
Warstwa rodkowa to warstwa, w której realizuje si tak zwan logik biznesow apli-
kacji. 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 równie w innych systemach.
Dolna warstwa to warstwa, gdzie realizowane jest zadanie przechowywania danych w spo-
sób trway. Najbardziej typowym ródem trwaoci jest baza danych, ale równie dobrze mog
to by pliki w systemie plików.
W dalszej czci rozdziau zajmiemy si kwestiami dotyczcymi poszczególnych wyró-
nionych tu warstw. W sieci WWW mona znale mnóstwo przykadów takich aplikacji;
wszystkie udostpniaj jakie usugi warstwy biznesowej uytkownikom kocowym. Aplika-
cje te mog by ze sob skojarzone (na przykad odnonikami hipertekstowymi), ale nie s
faktycznie zintegrowane — stanowi raczej luno powizane „ekosystemy”, w których czyn-
nikiem wicym jest wanie uytkownik kocowy. Tymczasem w systemie zorientowanym
na usugi aplikacje s zintegrowane za porednictwem tyche usug; miejsce uytkowników
w tych systemach zajmuj inne, zewntrzne aplikacje WWW, a warstwa prezentacji jest za-
stpowana warstw usugi.
Aplikacje WWW w Javie
Aplikacje WWW w jzyku Java wykorzystuj technologie opisane w specyfikacji J2EE i po-
wszechne standardy ogólne, jak HTML, XMLO czy Web Service.
Koncepcja warstwowego podziau aplikacji i systemów 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 specyfi-
kacji. Dziki temu powstao wiele komercyjnych i niekomercyjnych serwerów aplikacyjnych
obsugujcych tak ustanowiony standard.
J2EE oferuje standardy dla modeli wykonawczych i programistycznych, wykorzystywa-
nych w aplikacjach WWW. S tu komponenty dla sesji klienckich, prezentacji, logiki bizneso-
wej i logiki sterowania aplikacj, a take dla operacji biznesowych. S tu te zdefiniowane
usugi dotyczce rozproszenia, transakcyjnoci i zarzdzania danymi, umoliwiajce urucha-
mianie tych komponentów 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 re-
gulujcego przebieg interakcji klientów z systemem, implementacj poszczególnych kompo-
nentów i sposób wykorzystania przez te komponenty interfejsów 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 bizne-
sowej su tu komponenty EJB. Warstwa danych jest realizowana równie za pomoc kompo-
nentów EJB, a take za porednictwem usug dajcych dostp do korporacyjnych systemów
informatycznych.
J2EE definiuje osobne kontenery dla komponentów WWW i komponentów bizneso-
wych (EJB) — zob. rysunek 5.3. Kontenery udostpniaj standardowe dla nich usugi, obsu-
gujc rozproszenie, sesyjno i transakcyjno. Klienty mog by aplikacjami typu thin client
(jak przegldarka WWW) albo penoprawnymi i samodzielnymi aplikacjami. Wymagane do ko-
munikacji protokoy WWW s obsugiwane przez rodowiska wykonawcze po stronie serwera.
R
YSUNEK
5.3. Kontenery J2EE
Kontener WWW obsuguje komponenty takie jak strony JSP i serwlety. Komponenty
te s wykorzystywane powszechnie do realizacji warstwy prezentacji.
Kontener komponentów EJB udostpnia rodowisko wykonawcze dla komponentów
biznesowych i dostp do korporacyjnych systemów 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 systemów nazw i katalogów (JNDI) i mnóstwa innych
interfejsów realizujcych komunikacj wewntrzn i zewntrzn, zapewniajcych rozszerzal-
no systemów J2EE.
Projektowanie aplikacji WWW w jzyku Java
Czasami jestemy tak zaaferowani nowymi technologiami i systemami, e zapominamy na-
uki z przeszoci. Stosowanie zasad inynierii oprogramowania, zwaszcza za zasad obiekto-
woci, jest dla nas w tych nowych technologiach wyzwaniem (Knight 2002). Owe nowe tech-
nologie bywaj tak samo grone, jak efektywne; mog zachca do stosowania niekoniecznie
najlepszych praktyk programistycznych. Na przykad programowanie stron JSP kusi mo-
liwoci bezporedniego odwoywania si do baz danych, atwo tu te zapomnie o zdatnoci
kodu do ponownego wykorzystania. Komponenty EJB jako skadowe biznesowych kom-
ponentów aplikacji s krytykowane za nadmiern zoono. XML promuje wspódzielenie
i wielokrotne wykorzystanie, ale bywa naduywany.
Aplikacje WWW pisane w Javie skadaj si od strony warstwy prezentacji ze stron JSP
i serwletów. Zarówno JSP, jak i serwlety mona wykorzysta przy tworzeniu architektur
z wyodrbnionymi warstwami. W ten sposób buduje si dwa najpopularniejsze typy aplika-
cji WWW w Javie, które bdziemy oznacza jako model 1. i model 2. Otó wedle modelu 1.
dania klientów s przesyane wprost do stron JSP, podczas gdy w modelu 2. s one kiero-
wane do serwletu kontrolujcego, który 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 adap-
tacj wzorca projektowego MVC (Model View Controller) dla potrzeb aplikacji WWW. Wzor-
cem projektowym MVC zajmiemy si nieco póniej (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 równoczesne stoso-
wanie kodu w jzyku Java. W JSP mona wygodnie przetwarza dania HTTP i generowa
odpowiedzi w postaci gotowych dokumentów HTML. Strony JSP daj si te atwo zro-
zumie projektantom i twórcom WWW (którzy niekoniecznie s wykwalifikowanymi pro-
gramistami Java). W architekturze narzucanej przez model 1. caa aplikacja jest w zasadzie
realizowana na bazie JSP. Niektórzy podnosz, e mimo wszystko dochodzi do separacji treci
i prezentacji, poniewa wszystkie odwoania do danych s realizowane za pomoc kompo-
nentów 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 ste-
rowania 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 rónych abstrakcji do rónych warstw i z punktu wi-
dzenia 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) równie jest problematyczna. To samo dotyczyoby wykorzystania
samych serwletów (bo serwlet mona uzna za skrypt z dodatkowymi osadzonymi elemen-
tami 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 wyróniono trzy mechanizmy do przekazywania parametrów (me-
toda kodowania parametrów w URL, metoda parametrów zapyta i formularze) i we wszyst-
kich dane s przekazywane jako zwyczajne cigi znaków. Kady ze skryptów skadajcych
si na aplikacj musi wic „na wasn rk” okrela sposób przekazywania parametrów,
konwersj parametrów na wartoci odpowiednich typów i weryfikacj (walidacj) tych war-
toci. Brak wspólnego, wyodrbnionego kodu obsugi danych wejciowych wymusza powiela-
nie tego samego bd podobnego kodu w wielu osobnych skryptach.
Obsuga logiki aplikacji
Kolejn kwesti problematyczn, dotyczc zarówno 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 wymagaj-
cym tych danych musz albo by zapisane w sesji skojarzonej z danym uytkownikiem, albo
wielokrotnie odczytywane z zewntrznego róda danych.
Na przykad, jeli skrypt przekazuje dane logowania uytkownika jako dane formularza,
kod zapisujcy te dane w sesji mógby wyglda tak:
Listing 5.1. Zapisywanie sesji z parametrami dania HTTP
password = request.getParameter("passwordField");
decrypted = this.decode("password");
request.getSession().setAttribute("password", decrypted);
Zarówno zapis danych w atrybutach sesji, jak i zapis w zewntrznym ródle 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 zmien-
nych i w kadym skrypcie czy te na kadej stronie korzystajcej z danych trzeba „ujawni”
142
Cz II • Tworzenie aplikacji WWW w Javie
stosowane nazewnictwo atrybutów-zmiennych. Nie mona wtedy w prosty sposób wyszu-
ka wszystkich odwoa do zmiennych za porednictwem zwyczajnych mechanizmów pro-
gramistycznych, co z kolei utrudnia modyfikowanie odwoa do danych. A jeli JSP nie
hermetyzuje stosowanej konwencji nazewniczej, wiedza i niej i o niskopoziomowych prze-
cie szczegóach implementacji protokou HTTP musi by implementowana w caoci apli-
kacji, co skutecznie niweczy jej zdatno do adaptacji do nowych zastosowa. Co wicej,
mamy tu te potencjalne ródo bdów, które mog powsta nie tylko wskutek zwyczajnej
literówki w nazwie zmiennej, ale take w wyniku zastosowania takiej samej nazwy w ró-
nych skryptach do rónych celów. W miar zwikszania si liczby stron JSP budowanej w ten
sposób 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 stro-
nach JSP utrudnia te diagnostyk kodu. Co prawda w WTP znalazy si zarówno mechani-
zmy asysty przy wprowadzaniu kodu w JSP, jak i mechanizmy interaktywnego debugowa-
nia kodu, w przypadku prekompilowanych stron JSP trzeba bdzie debugowa zoony kod
generowany przez serwer, co jest trudne. Z tych wzgldów 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 obiektów biznesowych, ale wci mamy do czynienia z mieszaniem logiki apli-
kacji i logiki biznesowej. Tymczasem nie da si skutecznie przetestowa niezalenie od siebie
poszczególnych fragmentów JSP, tak jak to jest moliwe w przypadku odrbnych klas jzyka
Java (i testów jednostkowych). Do tego realizacja logiki biznesowej w JSP prowadzi do dalsze-
go 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 pozo-
staymi warstwami aplikacji. Zmiana wygldu strony WWW czy choby przystosowanie
aplikacji do potrzeb i ogranicze rónych urzdze docelowych s wtedy mocno utrudnione.
A ta ostatnia trudno nabiera znaczenia, poniewa sie WWW nieustannie rozprzestrzenia si
na urzdzenia przenone, w tym choby telefony komórkowe. JSP pomaga w uporaniu si
z tym problemem, pozwalajc projektantom WWW tworzy wygld stron, podczas gdy pro-
gramici 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 wy-
ranie oddzielonych czci (warstw), z moliwie ograniczonymi zalenociami i interakcjami
pomidzy tymi czciami. Taki system cechuje si dobrym podziaem problematyki aplika-
cji, co oznacza, e róne 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. Od-
dzielajc od siebie poszczególne fragmenty systemu czynimy oprogramowanie wysoce ad-
aptowalnym, atwo dostosowujcym si do zmieniajcych si w przyszoci wymaga. Warstwy
obejmuj logik pobierania danych i ich wyprowadzania (warstwa prezentacji), logik aplika-
cji, logik biznesow i zagadnienia trwaoci danych. Wszystkie te warstwy mona wypro-
wadzi 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 procesów 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 prze-
twarzaniem i weryfikacj poprawnoci skadniowej danych wejciowych, a wic strumieni
SOAP, HTTP, SMPT i tak dalej; odpowiada te za wyuskiwanie wartoci parametrów
z da. Wedle wzorca MVC odpowiada ona kontrolerowi wejcia.
Do zmontowania tej warstwy wykorzystujemy komponenty i interfejsy serwletów do
obsugi protokou HTTP. Sposobami uycia tych interfejsów i komponentów zajmiemy si
w dalszej czci rozdziau.
Logika aplikacji
Kod logiki aplikacji odpowiada za ogólny 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 po-
staci cigów znaków a komunikatami bd wartociami obiektów biznesowych. W aplikacji
WWW ta warstwa moe równie zarzdza interakcj uytkownika z wieloma stronami aplika-
cji jako sekwencj kroków (przejciami pomidzy stronami WWW). W MVC odpowiada to
roli kontrolera aplikacji.
Standard J2EE nie definiuje bezporednio komponentów do realizacji logiki aplikacji.
Warstwa ta jest zazwyczaj implementowana w obrbie kontenera WWW J2EE i wykorzy-
stuje podobne komponenty i interfejsy, jak te wykorzystywane w warstwie danych wej-
ciowych. 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 wycz-
nie 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 systemów zewntrznych, w tym baz danych, korpo-
racyjnych systemów 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 obiektów pozosta-
ych warstw. W takim ukadzie mona atwo implementowa rdzenne zadania biznesowe
aplikacji i umoliwi realizacj tych zada nie tylko w obrbie aplikacji J2EE, ale równie
w innych systemach. Nasza rekomendacja dotyczca projektowania warstwy biznesowej jest
prosta: warstwa ta powinna by moliwie uproszczona, implementowana w miar moliwoci
za pomoc zwyczajnych obiektów Javy i cakowicie niezalena od pozostaych warstw archi-
tektury aplikacji. Odwoywanie si tu do komponentu takiego jak JSP albo którego z in-
terfejsów J2EE typowego dla specyfiki WWW (np. interfejsu dania HTTP) jest tu niepo-
dane. Tak samo niepodane byoby korzystanie tu bezporednio z interfejsów utrwalania
danych wykorzystywanych w warstwie trwaoci. Bo co stanie si z obiektami logiki bizne-
sowej po póniejszej zmianie technologii utrwalania danych? Prawidowe ograniczenie takich
zalenoci eliminuje przysze problemy i umoliwia niezalene wprowadzanie zmian w in-
nych warstwach.
Trwao
Logika biznesowa implementowana w postaci obiektów jzyka Java potrzebuje jakiego na-
rzdzia do trwaego skadowania danych biznesowych. W wikszoci aplikacji w tej roli wy-
stpuj relacyjne bazy danych. Mona te wykorzystywa technologie alternatywne, jak bazy
danych XML czy bazy obiektowe. Zadaniem warstwy trwaoci jest udostpnienie tej funk-
cjonalnoci w aplikacji. Logika biznesowa nie powinna by zalena od warstwy trwaoci, wic
w modelu biznesowym nie naley odwoywa si wprost do interfejsów skadowiska danych.
Utrwalanie obiektów realizuje si na róne sposoby, od obiektów DAO (Data Access
Object), zalenych zazwyczaj od interfejsów dostpu do baz danych i jzyków zapyta takich
jak SQL. Takie podejcie jest odpowiednie w przypadku niewielkiego zestawu prostych
obiektów, 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
obiektów byo przedmiotem intensywnych prac i szczegóowe omawianie tego zagadnienia
wykracza poza zakres tematyczny niniejszej ksiki.
Prezentacja wyników
Ta warstwa grupuje kod i zasoby niestanowice kodu (pliki HTML, XML czy obrazki), lecz
wykorzystywane do prezentowania wyników dziaania aplikacji uytkownikowi. Zazwyczaj
skada si z niewielkiej iloci kodu, a tene kod dotyczy wycznie formatowania i prezen-
towania danych. Na przykad strona JSP warstwy prezentacji wyników moe zawiera frag-
menty 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 implemento-
wania warstwy prezentacji. Komponenty te s obsugiwane poprzez bogaty zestaw interfejsów
do przetwarzania HTML i XML, tworzenia obrazków, zarzdzania adresami URL i ogólnie
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 serwletów,
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
interfejsów 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 sposób oddzielenia kodu modelowego (czyli kodu niezwi-
zanego z interfejsem uytkownika) od kodu prezentacyjnego i sterujcego. Kod modelowy
nie powinien zawiera adnej wiedzy o interfejsie, a jedynie rozgasza powiadomienia o wszel-
kich zmianach stanu do komponentów zalenych, którymi 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 rozrónienia pomidzy logik aplikacji (na przykad przepywem sterowania po-
midzy skadowymi stronami WWW aplikacji) i logik biznesow (czyli np. przetwarzaniem
patnoci). Po drugie, w wikszoci systemów okienkowych i bibliotek funkcje kontrolera
i widoku s czone w pojedynczym elemencie interfejsu, co redukuje uyteczno koncep-
cyjnego podziau na kontroler i widok.
Pierwotne rozumienie architektury MVC ulegao wic ewolucji. Obecnie pojcie kontro-
lera odnosi si do obiektu obsugujcego logik aplikacji, a pojcie modelu zarezerwowano dla
obiektów biznesowych. Bdziemy wic tak okrela obiekty biznesowe, a pojcia kontroler
wejcia i kontroler aplikacji odnosi do dwóch podstawowych typów kontrolerów 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, serwletów i zwyczajnych
obiektów Javy realizujcych zadania rónych komponentów. Owe ramy projektowe koncen-
truj si na oddzieleniu widoku od kontrolera, ale niekoniecznie sugeruj sposoby oddzielenia
kontrolerów, czyli logiki aplikacji, od logiki biznesowej. W kontekcie WWW dwojakie stoso-
wanie pojcia kontrolera (jako kontrolera wejcia i kontrolera aplikacji) jest jak najbardziej
poprawne. W przypadku aplikacji HTTP wejcie i prezentacja s od siebie cakiem roz-
dzielone, podany jest wic kontroler wejcia oddzielony od widoku. A w przypadku apli-
kacji o jakiejkolwiek realnej zoonoci trzeba jeszcze uwzgldni byt kontrolera aplikacji
jako oddzielajcego szczegóy przepywu sterowania w aplikacji od szczegóów implemen-
tacji logiki biznesowej.
W nastpnych podrozdziaach bdziemy omawia podstawow struktur obiektów w ra-
mach projektowych MVC dla WWW (zob. rysunek 5.4). Architektura ta jest implemento-
wana przez liczne wymienione wczeniej szkielety aplikacyjne.
146
Cz II • Tworzenie aplikacji WWW w Javie
R
YSUNEK
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 me-
chanizm przekazywania danych, wyuskuje z dania niezbdne informacje, we wspópracy
z kontrolerem aplikacji identyfikuje nastpn operacj — okrelan mianem akcji — i wy-
wouje ow akcj w odpowiednim kontekcie (zmontowanym z zestawu danych wejcio-
wych). Uruchomienie kontrolera wejcia jako pojedynczego komponentu pozwala na wy-
izolowanie w projekcie caoci wiedzy zwizanej z obsug protokou HTTP i konwencji
nazewniczych obowizujcych na poziomie da HTTP. W ten sposób eliminuje si po-
wielanie kodu i zmniejsza czny rozmiar kodu. Dziki temu mona te atwiej modyfiko-
wa 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 wyrónia si osobny
serwlet, obsugujcy dania dostpu do aplikacji za porednictwem protokou HTTP z po-
ziomu 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 bdów,
utrzymywanie informacji zwizanych ze stanem aplikacji (w tym referencji do obiektów biz-
nesowych) 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 parametrów maj w nich posta par klucz-warto (oba ele-
menty pary to cigi znaków). Kontroler aplikacji musi dysponowa mechanizmem odwzo-
rowania takich par na obiekty aplikacji, które zarzdzaj przepywem danych. W wikszoci
szkieletów aplikacyjnych te odwzorowania s reprezentowane za pomoc rozbudowanych
plików konfiguracyjnych w formacie XML, jak w przypadku pliku struts-config.xml wykorzy-
stywanego 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 ponie-
wa jest to jedyny komponent wykorzystywany w taki sposób, skutki tych saboci s mi-
nimalizowane. W lepszym projekcie pojedynczy kontroler aplikacji jest zazwyczaj odpowie-
dzialny za wiele stron WWW i wiele operacji. W najprostszej aplikacji pojedynczy kontroler
aplikacji moe obsugiwa wszystkie strony. W aplikacji rozbudowanej wyznacza si zazwy-
czaj kilka kontrolerów aplikacji, kady do innego obszaru jej dziaalnoci. Poprzez wykorzysty-
wanie pojedynczego obiektu jako wspólnego, centralnego punktu odniesienia dla hermetyza-
cji informacji kontroler aplikacji rozwizuje zagadnienia ukrywania informacji i konwencji
nazewniczych. Zamiast przechowywa izolowane skrawki informacji w atrybutach sesji, ska-
duje si je w obiektach biznesowych. Do ledzenia dziaania kontrolera aplikacji i obiektów
biznesowych mona wykorzysta klasyczne mechanizmy jzyka programowania, co bardzo
uatwia konserwacj i modyfikowanie kodu. Do tego cao podlega statycznej kontroli typów,
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 — two-
rzenie druyn i dodawanie graczy do druyn — moemy zrealizowa te przypadki w aplika-
cji za pomoc dwóch 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 sposób powizane. Choby 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 którym 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 poszczególnymi 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 wspólnego 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 interfejsów 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. Niektórzy uwaaj,
e bliszy zaoeniom MVC jest JSF, a to ze wzgldu na dostpno komponentów stano-
wych w warstwie widoku i obsug modelu zdarzeniowego do obsugi interakcji (np. zda-
rze kliknicia przycisku). JSF okrela te rozbudowan bibliotek standardowych znaczników,
które 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 bezsta-
nowym protokole HTTP. W JSF wystpuje koncepcja kontrolera aplikacji w postaci kom-
ponentów managed backing beans (listing 5.5). Te komponenty mog ujmowa grupy powiza-
nych 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 za-
szyta 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. Wy-
bór akcji zaleny jest zarówno od danych wprowadzonych na wejcie, jak i od biecego
stanu aplikacji; decyzja naley wic do kontrolera aplikacji. Wynik tego procesu decyzyjne-
go jest reprezentowany poprzez obiekt
ApplicationController
(
ApplicationController
to
implementacja wzorca projektowego Command, opisywanego w Gamma 1995).
Obiekty biznesowe s zwyczajnymi obiektami Javy, zawierajcymi wycznie logik biz-
nesow, 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 zarówno zaimplementowa, jak i prze-
testowa logik biznesow, bo moe si to odbywa w cakowitej izolacji od caej kopotli-
wej infrastruktury WWW. Jeli aplikacja jest prawidowo zaprojektowana, obiekty biznesowe
stanowi wyizolowan warstw, zdatn do wykorzystania zarówno w aplikacji WWW, jak
i w aplikacjach zakadajcych dostp z poziomu innych rodzajów klientów, a nawet w kla-
sycznych aplikacjach stanowiskowych.
Widok
W aplikacji J2EE widoki s najczciej stronami JSP, które odwouj si do kontrolera apli-
kacji i obiektów biznesowych. Widoki powinny zawiera moliwie mao kodu, a wic dele-
gowa wikszo swoich zada do kontrolera aplikacji albo obiektów biznesowych. Na samej
stronie powinien pozosta jedynie kod bezporednio zwizany z prezentacj biecej strony.
Specyfikacja JSP udostpnia te biblioteki znaczników (ang. taglibs) do definiowania wasnych
znaczników, ujmujcych bardziej rozbudowane zachowania widoku — w przypadku skom-
plikowanych widoków zaleca si przenoszenie kodu wanie do samodzielnie definiowanych
znaczników. Na rysunku 5.4 byo wida dwa róne mechanizmy widoku. Kontroler wyjcia
JSP wykorzystuje implementacj JSP odpowiedni dla przegldarki WWW albo WAP. Kon-
troler 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 niektórym z nich (zob.
rysunek 5.5). Szkielety te wydatnie upraszczaj tworzenie aplikacji WWW w Javie. Udo-
stpniaj 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
R
YSUNEK
5.5. Szkielety aplikacyjne dla Javy
OSGi
OSGi Alliance (dawniej Open Services Gateway Initiative) to ciao definiujce standard udo-
stpniania 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 kom-
pletne i dynamiczne modele komponentowe, których brakowao w standardowych rodowi-
skach wykonawczych dla Javy. Dziki nim mona instalowa, uruchamia, zatrzymywa, aktu-
alizowa i odinstalowywa aplikacje bd komponenty nawet zdalnie.
OSGi zyskuje uznanie jako uogólniona 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 na-
stpnej generacji konstruuj takie firmy jak IBM i BEA. Co ciekawe, OSGi moemy te wykorzy-
sta sami do budowania prostych komponentów biznesowych i usug, które 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 komponentów
sterowanych metadanymi, redukujcych ilo kodu niezbdnego w aplikacjach J2EE. Roz-
wizania 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 projektów Apache, jak Struts i Axis. Oferuje NetUI do prezentacji, szkielet Controls
do prostych komponentów 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), definiu-
jcy zestaw znaczników JSP oraz klas Java upraszczajcych konstruowanie interfejsu uyt-
kownika dla aplikacji WWW. Powszechnie uwaa si, e JSF ma szans zestandaryzowa na-
rzdzia 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 komponentów implementuje wzorce projektowe
Inversion of Control oraz Dependency Injection. Udostpnia te prosty kontener do im-
plementowania logiki biznesowej za pomoc zwyczajnych obiektów Javy (POJO) i dziki temu
moe wyeliminowa potrzeb stosowania komponentów EJB. Do tego Spring udostpnia
mechanizmy do zarzdzania danymi aplikacji.
Pico Container
Pico Container jest prostym szkieletem aplikacyjnym, równie bazujcym na wzorcach
Inversion of Control i Dependency Injection. Podobnie jak Spring, powsta jako odpowied
na nadmiern zoono tworzenia aplikacji J2EE, a szczególnie na trudnoci zwizane z pro-
gramowaniem komponentów EJB.
Hibernate
Hibernate to szkielet relacyjnego odwzorowania obiektów — ORM (Object Relational Mapping).
Pozwala programistom implementowa relacyjne utrwalanie obiektów oraz odpytywa usugi
o obiekty Javy bez koniecznoci modyfikowania ich kodu.
Specyfikacja komponentów encyjnych EJB3, a zwaszcza specyfikacja interfejsu trwaoci
JPA (Java Persistent API), która z niej wyewoluowaa, w obliczu zoonoci dostpnych rozwi-
za standardowych zwiksza jeszcze atrakcyjno Hibernate i podobnych szkieletów 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 inte-
growanie tyche usug. Ukierunkowanie na usugi oznacza ujmowanie poszczególnych ele-
mentów logiki biznesowej. Usuga to wcielenie fundamentalnej zasady programowania obiek-
towego, czyli oddzielenia implementacji od interfejsu. W poczeniu ze standardowymi
jzykami opisu (jak XML), powszechnymi protokoami transportowymi (HTTP) oraz mo-
liwoci wyszukiwania i kojarzenia usugodawcy w czasie wykonania SOA okazuje si wietn
technologi integrowania rozmaitych systemów. 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-*. Szczegóowe omówienie SOA dalece wykracza poza tematyk niniejszej
ksiki, zajmiemy si jednak tym, jak mona w WTP montowa aplikacje WWW ukierun-
kowane usugowo, gównie na bazie technologii Web Service.
Udostpnianie usug. Warstwa usugowa
Zadaniem warstwy usugowej w aplikacji jest eksponowanie poszczególnych funkcji aplikacji
i funkcji biznesowych jako wyodrbnionych usug. O przydatnoci czy ciekawoci aplikacji
wiadcz przecie wycznie wykorzystujcy j klienci (jeli w lesie przewróci 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),
które konsumuj usugi wielu usugodawców;
w systemach osadzonych (telefony komórkowe);
w portalach i aplikacjach WWW, od zdalnych portali i aplikacji WWW po warstwy
sterujce systemu pionowego, w których 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 omówionej poprzednio architektury o warstw usugow (jak na rysun-
ku 5.6) pozwala na tworzenie aplikacji, która nie tylko jest uyteczna dla uytkowników ko-
cowych, ale te moe wspódziaa z innymi systemami informatycznymi. Dodatkowa warstwa
skada si z elementów takich jak usugi Web Service, rejestry usug (UDDI), kontrakty
(WSDL) i elementy poredniczce (proxy), które wi te usugi z naszymi aplikacjami.
Warstwa usugowa eksponuje cile zdefiniowane interfejsy do identycznego jak poprzed-
nio modelu biznesowego. Interfejs usugi jest okrelany przez kontrakt opisywany w jzyku
Rozdzia 5. • Architektura i projektowanie aplikacji WWW
153
R
YSUNEK
5.6. Model rozszerzony o warstw usugow
WSDL. W danym modelu biznesowym mona korzysta z procesów i logiki bazujcej na
usugach systemów zewntrznych. Konsumentom usug nie s ujawniane szczegóy we-
wntrznego modelu biznesowego. Wszystkie szczegóy techniczne niezbdne do konsumo-
wania 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. Zast-
puje 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 bizneso-
wej. Najprociej byoby odpowiedzie „nie”, ale to nie wyczerpuje zagadnienia. Logika bizne-
sowa nie jest zawsze i wycznie modelowana w formie, któr da si natychmiast i bezporednio
udostpni jako usugi. Dobry model obiektowy cechuje si wysok ziarnistoci i skada z wielu
niewielkich, ale prostych do ogarnicia obiektów z atwymi do opanowania i wykorzystywania
metodami. Obiekty te ujmuj istotne koncepcje biznesowe i dane, ale nie s specjalnie przy-
datne do tworzenia usug. Usugi s zazwyczaj projektowane na bazie przypadków uycia; re-
prezentuj zachowanie biznesowe jako cig zdarze, jak np. „patno za rezerwacj”. Drob-
noziarniste obiekty modelu pojedynczo nie ujmuj takich transferów. 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 omówimy 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 usugodawców. Mona wic zrealizowa nowy proces biznesowy na bazie integracji
usug wiadczonych przez rónych usugodawców i uzupeni cao o now logik bizneso-
w, nowe reguy i moliwoci. Udostpnione treci podlegaj rekompozycji i odwzorowa-
niu do modelu biznesowego aplikacji klienckiej i s w niej prezentowane w nowy i unikatowy
sposób, niekoniecznie dostpny od któregokolwiek z usugodawców usug skadowych
z osobna. To podstawowe zaoenie SOA.
Modelowanie procesu biznesowego i montowanie usug moe konsumowa usugi
w sposób standaryzowany, za porednictwem mechanizmów usug WWW. Warstwa usu-
gowa realizuje abstrakcj wielu rónych systemów biznesowych, a usugi tej warstwy mona
wykorzystywa do montowania nowych procesów biznesowych. W WTP nie mamy do dys-
pozycji narzdzi do zestawiania usug w taki sposób, ale producenci tacy jak IBM, Oracle
czy BEA rozszerzyli WTP o moliwo projektowania i wykonywania takich procesów „ska-
danych”. 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 spróbujemy 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 rónymi profilami
dla rónych uytkowników.
Po pierwsze, mamy wród nich ludzi, którzy umieszczaj treci w systemie. S to osoby
zainteresowane sportem i wykorzystujce League Planet do prowadzenia wasnych amator-
skich lig sportowych. Odwiedzaj stron WWW i tworz nowe ligi, w ramach których mog
rejestrowa druyny, graczy, terminarze rozgrywek, miejsca rozgrywek, wyniki, statystyki
i wiele rozmaitych innych informacji. League Planet ma dla nich udostpnia wysoce dyna-
miczny interfejs WWW, który pozwoli im wchodzi w bezporednie interakcje z systemem.
Korzystanie z systemu polega na przechodzeniu pomidzy stronami WWW i wykony-
waniu czynnoci takich, jak przegldanie prezentowanych informacji, wypenianie formu-
larzy i zamawianie dóbr oferowanych przez partnerów biznesowych League Planet. Do ob-
sugi takich uytkowników League Planet musi mie warstw prezentacji. Warstwa prezentacji
bdzie zrealizowana na bazie stron JSP. Aby ograniczy ilo kodu opisujcego interfejs, wy-
korzystamy bibliotek znaczników dla Javy. Warstwa prezentacji bdzie ograniczona do ko-
du 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 wpro-
wadzanych danych, przepyw sterowania na stronie i pomidzy nimi oraz wspópraca 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 sponsorów, którzy
potrzebuj dostpu do pewnych usug. League Planet generuje spor cz swojego przy-
chodu z reklam ogoszeniodawców. Informacje o druynach, graczach i odwiedzajcych oraz
ich profilach mog si przyda do przygotowywania skuteczniejszych reklam. Profile te su
do generowania banerów reklamowych i odnoników do stron odpowiednich partnerów biz-
nesowych. Informacje te s udostpniane systemom partnerów League Planet za pored-
nictwem zbioru usug, realizowanych w warstwie usugowej; samo wywietlanie reklam
równie realizowane jest na bazie usug, tym razem zewntrznych (udostpnianych w sys-
temach partnerów biznesowych).
Wreszcie serwis League Planet wspiera te swoje organizacje partnerskie, oferujc wik-
szo swoich treci i usug online dla zewntrznych serwisów. Niektóre 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 ródem unikatowych treci i usug, przeznaczo-
nych do konsumpcji w aplikacjach zewntrznych.
Aby zrealizowa taki system, wykorzystamy architektur opisan w poprzednim pod-
rozdziale (zob. rysunek 5.6). Aby zademonstrowa planowany sposób dziaania systemu, we-
my scenariusz rozpisany na diagramie z rysunku 5.7.
R
YSUNEK
5.7. Warstwa usugowa
Aplikacja kliencka, podobna do naszej wasnej aplikacji WWW, konsumuje usugi udo-
stpniane przez League Planet. Konsument usugi bdzie wykorzystywa jedn (bd wiele)
z udostpnianych usug Web Service za porednictwem protokou SOAP. Oba systemy maj
kompletnie róne modele biznesowe i odmienn logik aplikacji, ale bd zdolne do wspó-
dziaania 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 wyko-
nawcze usug WWW rozpracowuje danie i odwzorowuje dane wejciowe opisane w przy-
sanym 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 seriali-
zacji obiektów wynikowych, to jest konwersji obiektów 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 ze-
spoach na swojej stronie WWW.
Podsumowanie
Koncepcje omawiane w tym rozdziale powinny okaza si pomocne przy projektowaniu
aplikacji WWW, które od pocztku maj mie poprawn architektur. Zaprezentowalimy
szereg rónych podej i omówilimy róne gotowe szkielety aplikacyjne wcielajce te po-
dejcia. Na bazie prezentowanych tu wzorców omówilimy zyski jakociowe, bo wzorce te
narzucaj i promuj uznane zasady projektowania obiektowego. Omówione szkielety apli-
kacyjne s pomoc szczególnie istotn dla projektantów niedowiadczonych w metodologii
obiektowej, bo daj im punkt wyjcia do projektu wysokiej jakoci, bez koniecznoci zag-
biania si w szczegóy implementacji systemu, na którym ta jako w duej mierze bazuje.
Szkielety wzorowane na MVC, omawiane w tym rozdziale, mogyby zosta rozszerzone
w kilku dziedzinach, uwzgldniajc na przykad róne charakterystyczne dla WWW wyma-
gania, jak bezpieczestwo, walidacja danych itp. Zalecamy wasne eksperymenty z wymie-
nionymi technologiami, bo to najlepiej pozwoli ogarn ich struktur i pozna zastosowane
kompromisy architekturalne; w ten sposób 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 rónymi stylami
tworzenia aplikacji WWW w Javie i rónymi organizacjami projektu.
Wyszukiwarka
Podobne podstrony:
więcej podobnych podstron