Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00618 008414 10491693 na godz. na dobę w sumie
Enterprise JavaBeans 3.0. Wydanie V - książka
Enterprise JavaBeans 3.0. Wydanie V - książka
Autor: , Liczba stron: 760
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-0726-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> j2ee - programowanie
Porównaj ceny (książka, ebook, audiobook).

Wykorzystaj zaawansowane technologie
tworzenia aplikacji korporacyjnych

Enterprise JavaBeans to technologia przeznaczona do tworzenia złożonych programów, oparta na języku Java i platformie Java Enterprise Edition. Stosowana jest przy tworzeniu rozbudowanych aplikacji korporacyjnych i pozwala programistom na generowanie mechanizmów automatycznego zarządzania usługami kluczowymi dla systemu. Wersje EJB stosowane do tej pory wymagały od twórców aplikacji implementowania mechanizmów, które nie miały wiele wspólnego z właściwą logiką biznesową tworzonego oprogramowania, co znacznie wydłużało i komplikowało proces produkcji systemu. Najnowsza wersja, oznaczona numerem 3.0, jest pozbawiona tych wad.

Dzięki książce 'Enterprise JavaBeans 3.0. Wydanie V' poznasz najnowsze wcielenie technologii EJB. Opisano tu wszystkie rozwiązania, które umożliwiły uproszczenie standardu Enterprise JavaBeans 3.0 względem jego poprzednich wersji. Czytając tę książkę, poznasz nowy interfejs Java Persistence API, który zastąpił stosowane dotychczas komponenty encyjne zwykłymi obiektami Javy, oraz nauczysz się sposobów eliminowania konieczności implementowania interfejsów EnterpriseBean. Dowiesz się, jak stosować adnotacje w miejsce elementów języka XML umieszczanych w deskryptorach wdrożenia. Znajdziesz tu również praktyczne przykłady, dzięki którym błyskawicznie opanujesz nową wersję EJB.

Nie trać więcej czasu! Zastosuj technologię,
która ułatwi Ci wytwarzanie systemów korporacyjnych.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREœCI SPIS TREœCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOœCIACH O NOWOœCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Koœciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Enterprise JavaBeans 3.0. Wydanie V Autorzy: Bill Burke, Richard Monson-Haefel T³umaczenie: Miko³aj Szczepaniak, Krzysztof Ostrowski ISBN: 83-246-0726-9 Tytu³ orygina³u: Enterprise JavaBeans 3.0 (5th Edition) Format: B5, stron: 760 Przyk³ady na ftp: 10150 kB Wykorzystaj zaawansowane technologie tworzenia aplikacji korporacyjnych (cid:129) Poznaj architekturê EJB 3.0 (cid:129) Stwórz w³asne komponenty (cid:129) Zaprojektuj w³asne us³ugi sieciowe na podstawie EJB 3.0 Enterprise JavaBeans to technologia przeznaczona do tworzenia z³o¿onych programów, oparta na jêzyku Java i platformie Java Enterprise Edition. Stosowana jest przy tworzeniu rozbudowanych aplikacji korporacyjnych i pozwala programistom na generowanie mechanizmów automatycznego zarz¹dzania us³ugami kluczowymi dla systemu. Wersje EJB stosowane do tej pory wymaga³y od twórców aplikacji implementowania mechanizmów, które nie mia³y wiele wspólnego z w³aœciw¹ logik¹ biznesow¹ tworzonego oprogramowania, co znacznie wyd³u¿a³o i komplikowa³o proces produkcji systemu. Najnowsza wersja, oznaczona numerem 3.0, jest pozbawiona tych wad. Dziêki ksi¹¿ce „Enterprise JavaBeans 3.0. Wydanie V” poznasz najnowsze wcielenie technologii EJB. Opisano tu wszystkie rozwi¹zania, które umo¿liwi³y uproszczenie standardu Enterprise JavaBeans 3.0 wzglêdem jego poprzednich wersji. Czytaj¹c tê ksi¹¿kê, poznasz nowy interfejs Java Persistence API, który zast¹pi³ stosowane dotychczas komponenty encyjne zwyk³ymi obiektami Javy, oraz nauczysz siê sposobów eliminowania koniecznoœci implementowania interfejsów EnterpriseBean. Dowiesz siê, jak stosowaæ adnotacje w miejsce elementów jêzyka XML umieszczanych w deskryptorach wdro¿enia. Znajdziesz tu równie¿ praktyczne przyk³ady, dziêki którym b³yskawicznie opanujesz now¹ wersjê EJB. (cid:129) Architektura EJB 3.0 (cid:129) Relacje pomiêdzy komponentami (cid:129) Zapytania i jêzyk EJB QL (cid:129) Komponenty sesyjne (cid:129) Obs³uga transakcji (cid:129) Implementowanie us³ug WWW (cid:129) Instalacja i konfiguracja serwera JBoss Nie traæ wiêcej czasu! Zastosuj technologiê, która u³atwi Ci wytwarzanie systemów korporacyjnych Spis treści Słowo wstępne ..............................................................................................................11 Przedmowa ................................................................................................................... 15 Część I Standard EJB 3.0 23 1. Wprowadzenie ..............................................................................................................25 26 28 29 31 33 33 Komponenty serwerowe Utrwalanie danych i komponenty encyjne Asynchroniczne przesyłanie komunikatów Usługi Web Services Titan Cruises — wymyślone przedsiębiorstwo Co dalej? 2. Przegląd architektury ...................................................................................................35 35 39 48 54 55 Komponent encyjny Komponent biznesowy (korporacyjny) Stosowanie komponentów EJB i komponentów encyjnych Kontrakt komponent-kontener Podsumowanie 3. Zarządzanie zasobami i usługi podstawowe ..............................................................57 57 66 78 Zarządzanie zasobami Usługi podstawowe Co dalej? 4. Konstruowanie pierwszych komponentów ................................................................79 79 82 Wytwarzanie komponentu encyjnego Wytwarzanie komponentu sesyjnego 5 5. Utrwalanie: usługa EntityManager ............................................................................. 91 92 93 96 100 104 111 Encje są obiektami POJO Encje zarządzane kontra encje niezarządzane Pakowanie jednostek utrwalania Uzyskiwanie dostępu do usługi EntityManager Techniki współpracy z usługą EntityManager Transakcje zasobów lokalnych 6. Odwzorowywanie obiektów trwałych ......................................................................115 116 119 123 133 140 143 Model programowania Podstawy odwzorowań relacyjnych Klucze główne Odwzorowywanie właściwości Odwzorowania w wielu tabelach i adnotacja @SecondaryTable Obiekty osadzone (oznaczone adnotacją @Embedded) 7. Relacje łączące komponenty encyjne ........................................................................145 145 178 181 182 Siedem rodzajów relacji Odwzorowywanie relacji reprezentowanych przez kolekcje Encje odłączone i typ wyliczeniowy FetchType Propagacja kaskadowa 8. Dziedziczenie encji ..................................................................................................... 187 188 191 193 195 196 Reprezentacja hierarchii klas w formie pojedynczej tabeli Jedna tabela dla konkretnej klasy Jedna tabela dla każdej podklasy Strategie mieszane Nieencyjne klasy bazowe 9. Zapytania i język EJB QL .............................................................................................199 200 204 231 235 Interfejs Query API Język EJB QL Zapytania rdzenne Zapytania nazwane 10. Wywołania zwrotne i klasy nasłuchujące .................................................................239 239 240 241 Zdarzenia zwrotne Wywołania zwrotne klas komponentów encyjnych Klasy nasłuchujące encji 6 | Spis treści 11. Komponenty sesyjne .................................................................................................. 245 247 258 261 265 276 280 281 Bezstanowy komponent sesyjny Interfejs SessionContext Cykl życia bezstanowego komponentu sesyjnego Stanowy komponent sesyjny Cykl życia stanowego komponentu sesyjnego Stanowe komponenty sesyjne i rozszerzone konteksty utrwalania Zagnieżdżanie stanowych komponentów sesyjnych 12. Komponenty sterowane komunikatami ................................................................... 283 283 295 309 311 314 Usługa JMS i komponenty sterowane komunikatami Komponenty sterowane komunikatami JMS Cykl życia komponentu sterowanego komunikatami Komponenty sterowane komunikatami wykorzystujące konektory Wiązanie komunikatów 13. Usługa Timer Service ..................................................................................................319 321 321 331 331 334 340 Harmonogram konserwacji statków linii Titan Interfejs Timer Service API Transakcje Liczniki czasowe bezstanowych komponentów sesyjnych Liczniki czasowe komponentów sterowanych komunikatami Słowo końcowe 14. Kontekst JNDI ENC i mechanizm wstrzykiwania ......................................................341 341 349 Kontekst JNDI ENC Referencje i rodzaje wstrzyknięć 15. Obiekty przechwytujące .............................................................................................377 377 385 387 390 393 394 394 Metody przechwytujące Obiekty przechwytujące i wstrzykiwanie Przechwytywanie zdarzeń związanych z cyklem życia komponentu Obsługa wyjątków Cykl życia obiektu przechwytującego Stosowanie adnotacji @AroundInvoke dla metod samych komponentów EJB Kierunki rozwoju obiektów przechwytujących 16. Transakcje ....................................................................................................................397 397 402 412 Transakcje ACID Deklaracyjne zarządzanie transakcjami Izolacja i zabezpieczanie bazy danych Spis treści | 7 Nietransakcyjne komponenty EJB Jawne zarządzanie transakcjami Wyjątki i transakcje Transakcyjne stanowe komponenty sesyjne Konwersacyjny kontekst trwałości 422 423 433 438 440 17. Bezpieczeństwo ..........................................................................................................447 448 449 454 456 Uwierzytelnianie i tożsamość Autoryzacja Identyfikator bezpieczeństwa RunAs Bezpieczeństwo programowe 18. EJB 3.0: standardy usług WWW ................................................................................ 459 459 460 470 473 480 480 Ogólnie o usługach WWW XML Schema oraz XML Namespaces SOAP 1.1 WSDL 1.1 UDDI 2.0 Od standardu do implementacji 19. EJB 3.0 i usługi WWW .................................................................................................481 482 490 494 503 Dostęp do usług WWW za pomocą JAX-RPC Definiowanie usługi WWW za pomocą JAX-RPC Korzystanie z JAX-WS Inne adnotacje i API 20. Java EE .........................................................................................................................505 505 507 507 508 513 Serwlety Strony JavaServer Komponenty WWW i EJB Wypełnianie luki Składanie kawałków w jedną całość 21. Projektowanie EJB w zastosowaniach rzeczywistych ............................................. 515 515 517 540 545 Projekt wstępny — kontenery i bazy danych Projekt właściwy Czy korzystać z EJB? Opakowywanie 8 | Spis treści Część II Podręcznik użytkownika serwera JBoss 547 Wprowadzenie ..................................................................................................................... 549 22. Instalacja i konfiguracja serwera JBoss ..................................................................... 551 551 O serwerze JBoss 552 Instalacja serwera aplikacji JBoss 555 Krótki przegląd struktury wewnętrznej serwera JBoss Wdrażanie i konfigurowanie kodu źródłowego ćwiczeń 558 23. Ćwiczenia do rozdziału 4. ..........................................................................................561 561 571 Ćwiczenie 4.1. Pierwsze komponenty w serwerze JBoss Ćwiczenie 4.2. Deklarowanie związków z interfejsem JNDI za pomocą adnotacji Ćwiczenie 4.3. Deklarowanie związków z interfejsem JNDI za pomocą elementów języka XML 573 24. Ćwiczenia do rozdziału 5. ..........................................................................................577 577 587 Ćwiczenie 5.1. Interakcja z usługą EntityManager Ćwiczenie 5.2. Utrwalanie w autonomicznych aplikacjach Javy 25. Ćwiczenia do rozdziału 6. ..........................................................................................591 591 595 597 599 601 Ćwiczenie 6.1. Podstawowe odwzorowywanie właściwości Ćwiczenie 6.2. Adnotacja @IdClass Ćwiczenie 6.3. Adnotacja @EmbeddedId Ćwiczenie 6.4. Odwzorowywanie pojedynczych encji w wielu tabelach Ćwiczenie 6.5. Klasy osadzone 26. Ćwiczenia do rozdziału 7. ...........................................................................................605 605 611 615 Ćwiczenie 7.1. Propagacja kaskadowa Ćwiczenie 7.2. Relacje odwrotne Ćwiczenie 7.3. Leniwa inicjalizacja 27. Ćwiczenia do rozdziału 8. .......................................................................................... 621 621 625 627 Ćwiczenie 8.1. Strategia odwzorowywania hierarchii w pojedynczych tabelach Ćwiczenie 8.2. Strategia odwzorowywania klas w pojedynczych tabelach Ćwiczenie 8.3. Strategia dziedziczenia JOINED 28. Ćwiczenia do rozdziału 9. ..........................................................................................631 631 649 Ćwiczenie 9.1. Interfejs Query i podstawy języka zapytań EJB QL Ćwiczenie 9.2. Rdzenne zapytania języka SQL Spis treści | 9 29. Ćwiczenia do rozdziału 10. .........................................................................................655 655 660 Ćwiczenie 10.1. Wywołania zwrotne Ćwiczenie 10.2. Obiekty nasłuchujące 30. Ćwiczenia do rozdziału 11. .........................................................................................667 667 671 674 676 682 Ćwiczenie 11.1. Wywołania zwrotne Ćwiczenie 11.2. Przykrywanie ustawień za pomocą elementów XML-a Ćwiczenie 11.3. Bezstanowy komponent sesyjny bez adnotacji Ćwiczenie 11.4. Stanowy komponent sesyjny Ćwiczenie 11.5. Stanowy komponent sesyjny bez adnotacji 31. Ćwiczenia do rozdziału 12. ........................................................................................ 685 685 Ćwiczenie 12.1. Komponent sterowany komunikatami 32. Ćwiczenia do rozdziału 13. .........................................................................................693 693 Ćwiczenie 13.1. Usługa EJB Timer Service 33. Ćwiczenia do rozdziału 15. .........................................................................................697 697 699 Ćwiczenie 15.1. Obiekty przechwytujące EJB Ćwiczenie 15.2. Przechwytywanie wywołań zwrotnych EJB 34. Ćwiczenia do rozdziału 16. .........................................................................................703 703 Ćwiczenie 16.1. Konwersacyjny kontekst trwałości 35. Ćwiczenia do rozdziału 17. .........................................................................................707 707 712 Ćwiczenie 17.1. Bezpieczeństwo Ćwiczenie 17.2. Zabezpieczanie za pomocą XML 36. Ćwiczenia do rozdziału 19. .............................................................................................. 715 715 722 Ćwiczenie 19.1. Udostępnianie komponentu bezstanowego Ćwiczenie 19.2. Korzystanie z klienta .NET Dodatki 725 A Konfiguracja bazy danych JBoss ................................................................................727 Skorowidz .................................................................................................................... 731 10 | Spis treści ROZDZIAŁ 3. Zarządzanie zasobami i usługi podstawowe W rozdziale 2. opisano podstawy architektury technologii Enterprise JavaBeans i Java Persi- stence, w tym relacje łączące klasę komponentu, kontener EJB oraz usługę EntityManager. Relacje pomiędzy wymienionymi elementami interesującej nas architektury składają się od- powiednio na wspólny model rozproszonych komponentów serwera oraz na model utrwala- nia, który może być stosowany zarówno w aplikacjach działających po stronie serwera, jak i w aplikacjach autonomicznych. Same modele w tej formie nie wystarczą do tego, by tech- nologia Enterprise JavaBeans zainteresowała programistów i stała się bardziej funkcjonalna od innych popularnych architektur. Serwery EJB dodatkowo muszą zarządzać zasobami wy- korzystywanymi przez komponenty i z reguły oferują możliwość jednoczesnego zarządzania tysiącami lub wręcz milionami obiektów rozproszonych. Właśnie do serwera EJB należy za- rządzanie sposobem wykorzystywania przez obiekty rozproszone pamięci, wątków, połączeń z bazą danych, mocy obliczeniowej itp. Co więcej, specyfikacja EJB definiuje interfejsy, które ułatwiają programistom korzystanie z wymienionych mechanizmów. Serwery EJB oferują pięć podstawowych usług: współbieżność, zarządzanie transakcjami, utrwalanie danych, rozpraszanie obiektów, nazewnictwo oraz bezpieczeństwo. Wymienione usługi stanowią rodzaj infrastruktury niezbędnej do właściwej pracy systemu trójwarstwo- wego. Specyfikacja Enterprise JavaBeans opisuje też dwie usługi dodatkowe: asynchroniczne przesyłanie komunikatów i licznik czasowy. W niniejszym rozdziale skoncentrujemy się na elementach funkcjonalności odpowiedzialnych za zarządzanie zasobami oraz na najważniejszych usługach (tzw. usługach podstawowych) oferowanych komponentom Enterprise JavaBeans przez ich serwery. Zarządzanie zasobami Wielkie systemy biznesowe charakteryzujące dużą liczbą użytkowników mogą wymagać jednoczesnego istnienia i realizacji właściwych zadań przez tysiące lub wręcz miliony obiektów. Wraz ze wzrostem liczby wspólnych operacji podejmowanych przez te obiekty działania w takich obszarach jak zarządzanie współbieżnością czy przetwarzanie transakcyjne mogą prowadzić do wydłużenia czasu odpowiedzi i — tym samym — frustracji użytkowników. Serwery En- terprise JavaBeans próbują optymalizować pracę systemów EJB, synchronizując wspólne działania rozproszonych obiektów i wymuszając współdzielenie najcenniejszych zasobów. 57 Jest pewna zależność pomiędzy liczbą klientów a liczbą obiektów rozproszonych, których ist- nienie jest warunkiem koniecznym sprawnej obsługi tych klientów. Obsługa większej liczby klientów z oczywistych względów wymaga większej liczby obiektów rozproszonych. Istnieje punkt, od którego wzrost liczby klientów powoduje spadek wydajności i przepustowości całego systemu. Specyfikacja Enterprise JavaBeans opisuje dwa mechanizmy, których zadaniem jest ułatwienie zarządzania dużą liczbą komponentów w czasie wykonywania: mechanizm za- rządzania pulą egzemplarzy oraz mechanizm aktywacji. Twórcy technologii EJB dodatkowo zdecydowali się użyć do zarządzania połączeniami z zasobami architektury Java EE Con- nector Architecture (czyli konektory Java EE Connectors). Wraz ze wzrostem liczby obiektów rozproszonych i klientów z natury rzeczy musi rosnąć także liczba połączeń z zasobami. Konektory Java EE Connectors mogą być wykorzystywane przez kontener EJB do zarządzania połączeniami z bazami danych, systemami przesyłania komunikatów, systemami ERP, ist- niejącymi systemami informatycznymi oraz pozostałymi typami zasobów. Zarządzanie pulą egzemplarzy Koncepcja tworzenia puli zasobów nie jest żadną nowością. Przykładowo większość baz da- nych tworzy i zarządza pulą połączeń, która umożliwia obiektom biznesowym wchodzącym w skład danego systemu współdzielenie dostępu do zasobów bazy danych. W ten sposób można stosunkowo łatwo ograniczyć liczbę potrzebnych połączeń, co z kolei pozwala zmniej- szyć poziom wykorzystania zasobów i — tym samym — przekłada się na wyższą przepu- stowość. Architekturę Java EE Connector Architecture (JCA), która jest często wykorzystywana przez kontenery EJB właśnie do zarządzania pulą połączeń z bazami danych i innymi zaso- bami, szczegółowo omówimy w dalszej części tego rozdziału. Większość kontenerów EJB sto- suje mechanizmy zarządzania pulą zasobów dla komponentów serwera — ta technika często jest określana mianem zarządzania pulą egzemplarzy (ang. instance pooling). Pula egzemplarzy ogranicza liczbę egzemplarzy komponentów (a więc także zasobów) niezbędnych do obsługi żądań generowanych przez oprogramowanie klienckie. Jak wiemy, aplikacje klienckie współpracują z komponentami sesyjnymi za pośrednictwem interfejsów zdalnych i lokalnych implementowanych przez odpowiednie obiekty EJB. Ozna- cza to, że oprogramowanie klienckie nigdy nie ma bezpośredniego dostępu do właściwych egzemplarzy klas komponentów sesyjnych. Podobnie aplikacje klienckie systemu JMS nigdy nie współpracują bezpośrednio z komponentami sterowanymi komunikatami JMS (kompo- nentami JMS-MDB). Komunikaty wysyłane przez te aplikacje są kierowane do systemu kon- tenera EJB, który odpowiada za ich dostarczanie do odpowiednich egzemplarzy komponentów sterowanych komunikatami. Zarządzanie pulą egzemplarzy jest możliwe, ponieważ aplikacje klienckie nigdy nie uzyskują bezpośredniego dostępu do komponentów. W związku z tym utrzymywanie odrębnej kopii każdego z komponentów EJB dla każdego klienta nie jest konieczne. Serwer EJB może z po- wodzeniem realizować te same zadania, utrzymując mniejszą liczbę egzemplarzy kompo- nentów EJB, ponieważ pojedyncze egzemplarze tych komponentów mogą być wielokrotnie wykorzystywane do obsługi różnych żądań. Mimo że opisywane podejście wielu programistom może się wydawać niebezpieczne, dobrze zaprojektowany i zaimplementowany mechanizm zarządzania pulą egzemplarzy może znacznie ograniczyć ilość zasobów potrzebnych do ob- sługi wszystkich żądań generowanych przez oprogramowanie klienckie. 58 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe Cykl życia bezstanowego komponentu sesyjnego Aby jak najlepiej zrozumieć sposób działania puli egzemplarzy, warto przeanalizować cykl życia bezstanowego komponentu sesyjnego. Ogólnie bezstanowy komponent sesyjny może się znajdować w trzech stanach: Brak stanu W tym stanie znajdują się te egzemplarze komponentów, które nie zostały jeszcze zaini- cjalizowane. Warto identyfikować ten specyficzny stan, ponieważ dobrze reprezentuje sytuację z początku i końca cyklu życia egzemplarza komponentu. W puli Kiedy egzemplarz komponentu znajduje się w tym stanie, wiemy, że został zainicjalizowany przez kontener, ale jeszcze nie związano go z żadnym żądaniem wygenerowanym przez oprogramowanie klienckie. Stan gotowości Egzemplarz komponentu EJB znajdujący się w tym stanie został związany z konkretnym żądaniem EJB i jest gotowy do przetworzenia przychodzących wywołań metod biznesowych. Ponieważ bezstanowe komponenty sesyjne nie utrzymują swojego stanu pomiędzy kolejnymi wywołaniami metod, każde z tych wywołań jest niezależne od pozostałych — może wykony- wać swoje zadania bez konieczności odwoływania się do zmiennych egzemplarzy. Oznacza to, że dowolny egzemplarz bezstanowego komponentu sesyjnego może obsługiwać żądania dowolnego obiektu EJB pod warunkiem, że rodzaj i format tych żądań jest właściwy. Kontener EJB może więc wymieniać egzemplarze komponentu sesyjnego nawet pomiędzy kolejnymi wywołaniami metod. Każdy producent kontenera EJB implementuje mechanizm zarządzania pulą egzemplarzy w nieco inny sposób, jednak wszystkie strategie tworzenia tego rodzaju pul mają na celu takie zarządzanie kolekcjami egzemplarzy komponentów, które w czasie wykonywania zagwa- rantuje możliwie szybki dostęp do tych egzemplarzy. Podczas konstruowania puli egzempla- rzy kontener EJB tworzy wiele egzemplarzy klasy pojedynczego komponentu i utrzymuje je w wewnętrznej kolekcji do chwili, w której okażą się potrzebne. W odpowiedzi na żądania metod biznesowych generowanych przez aplikacje klienckie kontener EJB przypisuje poszcze- gólnym klientom egzemplarze komponentu wchodzące w skład dostępnej puli. Po zakoń- czeniu przetwarzania żądania, kiedy odpowiedni obiekt EJB nie jest już potrzebny, następuje jego zwrócenie do puli egzemplarzy. Serwer EJB utrzymuje pule egzemplarzy dla każdego wdrożonego typu bezstanowego komponentu sesyjnego. Warto pamiętać, że każdy egzem- plarz wchodzący w skład puli egzemplarzy jest elementem równoprawnym — wszystkie eg- zemplarze są traktowane w identyczny sposób. Egzemplarze są wybierane z puli i przydzielane kolejnym żądaniom EJB w sposób całkowicie przypadkowy (żaden z egzemplarzy nie ma pozycji uprzywilejowanej względem pozostałych). Na rysunku 3.1 przedstawiono schemat wymiany egzemplarzy pomiędzy kolejnymi wywo- łaniami metod bezstanowego komponentu sesyjnego. Na rysunku 3.1a widać egzemplarz A obsługujący wywołanie metody biznesowej przekazane przez 1. obiekt EJB. Po zakończeniu obsługi tego żądania egzemplarz A wraca do puli egzemplarzy (patrz rysunek 3.1b). Kiedy do systemu EJB dociera wywołanie metody 2. obiektu EJB, egzemplarz A jest wiązany z tym obiektem na czas trwania bieżącej operacji (patrz rysunek 3.1c). W czasie, gdy egzemplarz A obsługuje żądanie 2. obiektu EJB, 1. obiekt EJB otrzymuje wygenerowane przez oprogramo- wanie klienckie wywołanie innej metody — nowe żądanie jest obsługiwane przez egzem- plarz B (patrz rysunek 3.1d). Zarządzanie zasobami | 59 Rysunek 3.1. Strategia wymiany egzemplarzy bezstanowych komponentów sesyjnych Opisana strategia wymiany egzemplarzy bezstanowych komponentów sesyjnych umożliwia efektywną obsługę kilkuset aplikacji klienckich za pomocą zaledwie kilku egzemplarzy bez- stanowego komponentu sesyjnego, ponieważ czas potrzebny do wykonania większości wy- wołań metod z reguły jest znacznie krótszy od przerw dzielących kolejne wywołania. Egzem- plarz komponentu, który kończy obsługę żądania wygenerowanego przez obiekt EJB, natychmiast jest dostępny dla dowolnego innego obiektu EJB, który tego potrzebuje. Takie rozwiązanie umożliwia znacznie mniejszej liczbie bezstanowych komponentów sesyjnych obsługę więk- szej liczby żądań, co automatycznie przekłada się na mniejsze wykorzystanie zasobów i wyższą wydajność. Jeśli dany komponent sesyjny żąda wstrzyknięcia egzemplarza interfejsu javax.ejb.EJBContext, zaraz po umieszczeniu jego egzemplarza w odpowiedniej puli następuje przekazanie referen- cji do właściwego obiektu kontekstu (więcej informacji na ten temat można znaleźć w rozdziale 14.). Interfejs EJBContext może być wykorzystywany przez komponenty do komunikowania się z ich środowiskiem EJB. Interfejs EJBContext jest szczególnie przydatny w czasie, gdy dany egzemplarz komponentu znajduje się w stanie gotowości. W czasie obsługi żądania przez egzemplarz komponentu interfejs EJBContext nabiera nieco innego znaczenia, ponieważ oferuje informacje o aplikacji klienckiej korzystającej z danego komponentu. Co więcej, interfejs EJBContext zapewnia egzemplarzowi komponentu dostęp 60 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe do jego namiastki pośrednika EJB, co nie jest bez znaczenia w sytuacji, gdy dany komponent musi przekazywać referencje do samego siebie i (lub) pozostałych komponentów EJB. Ozna- cza to, że interfejs EJBContext w żadnym razie nie jest strukturą statyczną — jest dynamicznym interfejsem kontenera EJB. Bezstanowe komponenty sesyjne deklarujemy jako „bezstanowe”, stosując adnotację @javax. ejb.Stateless w kodzie źródłowym lub odpowiednie zapisy w deskryptorze wdrożenia. Od momentu wdrożenia klasy naszego bezstanowego komponentu sesyjnego kontener zakłada, że pomiędzy kolejnymi wywołaniami metod nie jest utrzymywany stan konwersacji. Bezstanowe komponenty sesyjne mogą zawierać zmienne egzemplarzy, jednak z uwagi na możliwość ob- sługi wielu różnych obiektów EJB przez pojedynczy egzemplarz takiego komponentu tego rodzaju zmienne nie powinny być wykorzystywane do reprezentowania stanu konwersacji. Komponenty sterowane komunikatami i pula egzemplarzy Podobnie jak bezstanowe komponenty sesyjne, komponenty sterowane komunikatami nie utrzymują stanów właściwych dla poszczególnych żądań i jako takie doskonale nadają się do składowania w puli egzemplarzy. W większości kontenerów EJB dla każdego typu komponentów sterowanych komunikatami jest tworzona osobna pula egzemplarzy odpowiedzialnych za obsługę komunikatów przycho- dzących. Komponenty JMS-MDB rejestrują swoje zainteresowanie określonymi rodzajami komunikatów (kierowanych w określone miejsce, rodzaj adresu wykorzystywanego podczas wysyłania i odbierania komunikatów). Kiedy asynchroniczny komunikat jest wysyłany przez klienta systemu JMS, komunikat trafia do kontenera EJB zawierającego komponenty, które zarejestrowały się jako odbiorcy tego rodzaju komunikatów. Kontener EJB odpowiada za określenie, który komponent JMS-MDB powinien otrzymać nowy komunikat, po czym wy- biera z puli jeden egzemplarz tego komponentu, któremu zostanie zlecona obsługa danego komunikatu. Kiedy wybrany egzemplarz komponentu JMS-MDB zakończy przetwarzanie tego komunikatu (gdy wywołana metoda onMessage() zwróci sterowanie), kontener EJB zwróci ten egzemplarz do odpowiedniej puli. Sposób przetwarzania żądań aplikacji klienckich przez kontener EJB przedstawiono na rysunku 3.2. Rysunek 3.2. Pula egzemplarzy komponentów JMS-MDB Zarządzanie zasobami | 61 Na rysunku 3.2a przedstawiono sytuację, w której pierwszy klient JMS dostarcza komunikat kierowany pod adres A, natomiast ostatni (trzeci) klient JMS dostarcza komunikat kierowany pod adres B. Kontener EJB wybiera egzemplarz komponentu MessageDrivenBean_1, który ma przetworzyć komunikat kierowany pod adres A, oraz egzemplarz komponentu Message- DrivenBean_2, który ma przetworzyć komunikat kierowany pod adres B. Egzemplarze obu wymienionych komponentów są na czas przetwarzania odpowiednich komunikatów usu- wane z puli. Na rysunku 3.2b przedstawiono sytuację, która ma miejsce chwilę później — środkowy (drugi) klient JMS wysyła komunikat kierowany pod adres B. Na tym etapie pierwsze dwa komuni- katy zostały już przetworzone, zatem należy przyjąć, że kontener EJB zwrócił oba egzemplarze komponentów sterowanych komunikatami do właściwych pul. W reakcji na otrzymanie nowego komunikatu kontener wybiera nowy egzemplarz komponentu MessageDrivenBean_2, którego zadaniem będzie przetworzenie tego komunikatu. Komponenty JMS-MDB zawsze są wdrażane z myślą o przetwarzaniu komunikatów kiero- wanych w określone miejsce docelowe. Przykładowo na rysunku 3.2 egzemplarze komponentu MessageDrivenBean_1 przetwarzają tylko komunikaty kierowane pod adres A, natomiast eg- zemplarze komponentu MessageDrivenBean_2 przetwarzają wyłącznie komunikaty z adresem docelowym B. Warto pamiętać, że istnieje możliwość jednoczesnego przetwarzania wielu komunikatów kierowanych pod ten sam adres. Przykładowo jeśli system EJB nagle otrzyma sto komunikatów kierowanych z adresem docelowym A, kontener EJB będzie musiał wybrać z puli sto egzemplarzy komponentu MessageDrivenBean_1, które przetworzą te komunikaty przychodzące (każdemu egzemplarzowi zostanie przydzielony inny komunikat). W specyfikacji Enterprise JavaBeans 2.1 i kolejnych wersjach rozszerzono rolę komponentów sterowanych komunikatami, rezygnując z ograniczania ich możliwości do jednego systemu przesyłania komunikatów — obecnie komponenty MDB oprócz systemu JMS mogą współ- pracować także z innymi usługami i interfejsami API przesyłania komunikatów. Ten odważ- ny krok otworzył komponenty sterowane komunikatami na niemal dowolne rodzaje zaso- bów, włącznie z systemami przesyłania komunikatów alternatywnymi względem systemu JMS, takimi systemami ERP jak SAP oraz istniejącymi systemami informatycznymi (np. IMS). Niezależnie od rodzaju zasobów reprezentowanych przez dany komponent sterowany komu- nikatami, jego egzemplarze są składowane w puli w dokładnie taki sam sposób jak egzem- plarze komponentów JMS-MDB. Mechanizm aktywacji W przeciwieństwie do pozostałych rodzajów komponentów EJB stanowe komponenty sesyjne utrzymują swój stan pomiędzy kolejnymi wywołaniami metod. Tzw. stan konwersacji (ang. conversational state) reprezentuje konwersację z klientem stanowego komponentu sesyjnego. Integralność takiego stanu konwersacji wymaga jego utrzymywania przez cały czas trwania obsługi żądań klienta przez dany komponent. Inaczej niż w przypadku bezstanowych kom- ponentów sesyjnych i komponentów sterowanych komunikatami egzemplarze stanowych komponentów sesyjnych nie są składowane w ramach puli. Zamiast tego stanowe kompo- nenty sesyjne wykorzystują mechanizm aktywacji, który także pozwala na pewne oszczędno- ści w zakresie wykorzystywanych zasobów. Kiedy serwer EJB musi zachować jakieś zasoby, może po prostu usunąć stanowe komponenty sesyjne z pamięci. Stan konwersacji usuniętego komponentu jest serializowany w pamięci pomocniczej. Kiedy klient wywołuje metodę 62 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe obiektu EJB, kontener EJB tworzy egzemplarz stanowego komponentu sesyjnego i odtwarza w nowym egzemplarzu stan zachowany w chwili usuwania z pamięci jego poprzednika. Pasywacja (ang. passivation) polega na rozłączeniu stanowego komponentu sesyjnego od obiektu EJB oraz na zachowaniu jego stanu w pamięci pomocniczej. Pasywacja wymaga skła- dowania stanu konwersacji pomiędzy egzemplarzem komponentu a odpowiednim obiektem EJB. Po wykonaniu pasywacji egzemplarz komponentu jest bezpiecznie usuwany zarówno z obiektu EJB, jak i z pamięci. Aplikacje klienckie w ogóle nie są informowane o procesach pasywacji. Warto pamiętać, że oprogramowanie klienckie wykorzystuje zdalną referencję do komponentu implementowaną przez namiastkę pośrednika EJB, zatem klient może być połą- czony z obiektem EJB także po przeprowadzeniu pasywacji. Aktywacja (ang. activation) polega na przywróceniu stanu konwersacji egzemplarza stano- wego komponentu sesyjnego z obiektem EJB. W momencie wywołania metody obiektu EJB, który był przedmiotem pasywacji, kontener automatycznie tworzy nowy egzemplarz odpo- wiedniego komponentu i przypisuje jego polom dane zapisane w czasie pasywacji. Obiekt EJB może następnie delegować wspomniane wywołanie metody do nowo utworzonego eg- zemplarza komponentu sesyjnego. Procesy aktywacji i pasywacji stanowego komponentu se- syjnego przedstawiono na rysunku 3.3. Rysunek 3.3a ilustruje sytuację, w której komponent podlega pasywacji. Stan konwersacji egzemplarza B z obsługiwanym obiektem EJB jest od- czytywany i utrwalany. Na rysunku 3.3b przedstawiono moment pasywacji i zapisywania stanu. Od tej pory dany obiekt EJB nie jest już związany ze wspomnianym egzemplarzem kompo- nentu. Aktywację tego komponentu przedstawiono na rysunku 3.3c. Rysunek ten prezentuje sytuację, w której nowy egzemplarz, nazwany C, jest tworzony, wypełniany danymi repre- zentującymi stan zapisany w czasie pasywacji i ostatecznie wiązany z tym samym obiektem EJB, z którym przed pasywacją współpracował egzemplarz B. Rysunek 3.3. Procesy pasywacji i aktywacji Zarządzanie zasobami | 63 Ponieważ sama klasa stanowego komponentu sesyjnego nie musi oferować możliwości se- rializacji, konkretne rozwiązania stosowane w mechanizmach aktywacji i pasywacji tego ro- dzaju komponentów zależą od producenta kontenera EJB. Warto pamiętać, że np. właściwo- ści transient mogą nie być traktowane przez mechanizmy odpowiedzialne za aktywację i pasywację dokładnie tak, jak tego oczekujemy. Przykładowo w czasie deserializacji obiektu Javy jego polom przejściowym zawsze są przypisywane wartości początkowe właściwe dla ich typów. Pola typu Integer mają przypisywaną wartość 0, pola typu Boolean mają przypi- sywaną wartość false, referencje do obiektów mają przypisywaną wartość null itd. W sys- temach EJB pola przejściowe aktywowanych komponentów nie mają przywracanych warto- ści początkowych, tylko albo zachowują swoje wartości oryginalne, albo wartości dowolne. Stosując pola przejściowe, należy zachowywać szczególną ostrożność, ponieważ ich stan po dokonaniu pasywacji i aktywacji zależy od implementacji. Proces aktywacji jest obsługiwany przez metody zwrotne cyklu życia komponentu. W prze- ciwieństwie do specyfikacji Enterprise JavaBeans 2.1 specyfikacja Enterprise JavaBeans 3.0 nie nakłada na programistów klas bezstanowych komponentów sesyjnych obowiązku imple- mentowania metod zwrotnych, które nie są potrzebne (niezaimplementowane metody oczy- wiście nie są udostępniane przez interfejs komponentu sesyjnego). Za pośrednictwem metod zwrotnych (oznaczonych stosownymi adnotacjami) programiści komponentów mogą uzy- skiwać sygnały o zdarzeniach mających związek z cyklem życia ich komponentów. Przykła- dowo metoda oznaczona adnotacją @javax.ejb.PostActivate (jeśli istnieje) jest wywoływa- na natychmiast po pomyślnym zakończeniu procesu aktywacji egzemplarza komponentu. W ciele tej metody można np. „wyzerować” wartości pól przejściowych przypisując im war- tości początkowe. Metoda oznaczona adnotacją @javax.ejb.PrePassivate (jeśli istnieje) jest wywoływana bezpośrednio przed przystąpieniem do pasywacji egzemplarza danego kom- ponentu. Metody wyróżnione tą parą adnotacji są szczególnie przydatne, jeśli egzemplarze naszego komponentu utrzymują połączenia z zasobami, które powinny być zamykane lub zwalniane przed przeprowadzeniem pasywacji oraz ponownie uzyskiwane lub odtwarzane po aktywacji. Ponieważ egzemplarze stanowych komponentów sesyjnych w czasie pasywacji są usuwane z pamięci, otwarte połączenia z zasobami z natury rzeczy nie mogą być zacho- wywane. Do wyjątków należą zdalne referencje do pozostałych komponentów oraz kontek- stu sesji (reprezentowanego przez egzemplarz interfejsu SessionContext), które muszą być zachowywane wraz z serializowanym stanem komponentu i odtwarzane w momencie jego aktywowania. Specyfikacja Enterprise JavaBeans dodatkowo wymaga zachowywania w pro- cesie pasywacji referencji do kontekstu środowiska JNDI, interfejsów komponentu, usługi EntityManager oraz obiektu UserTransaction. Architektura Java EE Connector Architecture Architektura Java EE Connector Architecture definiuje interfejs łączący korporacyjne systemy informacyjne (ang. Enterprise Information Systems — EIS) z systemami kontenerów Javy EE (w tym kontenerami EJB i serwletów). EIS jest ogólnym terminem stosowanym w odniesieniu do systemów informacyjnych, włącznie z serwerami relacyjnych baz danych, oprogramowa- niem pośredniczącym (np. MQSeries lub SonicMQ), systemami w architekturze CORBA, systemami ERP (np. SAP, PeopleSoft czy JD Edwards) oraz istniejącymi systemami informa- tycznymi (np. IMS czy CICS). 64 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe Java EE definiuje (oprócz architektury Enterprise JavaBeans) szereg standardowych interfej- sów API dla rozwiązań korporacyjnych, w tym takie interfejsy jak JDBC, JMS, JNDI, Java IDL czy JavaMail. Każdy z tych interfejsów API oferuje niezależne od producentów mechanizmy dla ściśle określonego rodzaju korporacyjnych systemów informatycznych. Przykładowo in- terfejs JDBC służy do wymiany informacji z relacyjnymi bazami danych, JMS jest oprogra- mowaniem pośredniczącym systemu przesyłania komunikatów, JNDI jest zbiorem usług na- zewnictwa i usług katalogowych, JavaMail stworzono z myślą o obsłudze poczty elektronicznej, natomiast Java IDL jest interfejsem opracowanym z myślą o architekturze CORBA. Obowiązek implementowania obsługi tych interfejsów API jest gwarancją przenośności komponentów EJB pomiędzy środowiskami różnych producentów. Mimo że interfejsy API dla rozwiązań korporacyjnych w założeniu mają być niezależne od producentów konkretnych rozwiązań, produkty kryjące się za tymi interfejsami zawsze wy- kazują cechy właściwe wyłącznie dla ich producentów. Kiedy komponent EJB korzysta z tego rodzaju interfejsu API, kontener EJB odpowiada za właściwe zarządzanie pulą utrzymywa- nych połączeń z systemem EIS, włączanie tego systemu do obsługiwanych transakcji, propa- gowanie danych uwierzytelniających itp. Wymienione zadania często wymagają od kontene- ra EJB współpracy z systemami EIS z wykorzystaniem technik, których nie przewidzieli lub nie udokumentowali twórcy tych uniwersalnych interfejsów API. W efekcie każdy producent rozwiązań pisanych w Javie EE musi tworzyć własny, niestandardowy kod współpracujący z ewentualnymi systemami EIS. W związku z tym producenci rozwiązań Java EE wybierają dla każdego standardowego interfejsu API obsługiwane systemy EIS. Takie podejście ma poważny wpływ na zakres obsługi poszczególnych systemów EIS przez producentów rozwią- zań EJB — przykładowo producent A może obsługiwać połączenia za pośrednictwem inter- fejsu JDBC z systemami baz danych Oracle, natomiast producent B może implementować ob- sługę tylko połączeń z bazami danych DB2. Konektory JCA 1.5 Specyfikacja Enterprise JavaBeans 2.0 nakładała na twórców komponentów EJB obowiązek implementowania obsługi architektury Java EE Connector Architecture, która stanowiła ogromny krok na drodze do rozwiązania opisywanych problemów. Z drugiej strony, proponowane rozwiązanie okazały się niewystarczające. W szczególności nie udało się rozwiązać problemu braku obsługi tzw. trybu wpychania (ang. push model) w systemach przesyłania komunika- tów, co było o tyle istotne, że wiele systemów EIS (np. JMS) „wpychało” dane klientom mimo braku odpowiednich żądań. Zarówno specyfikacja Enterprise JavaBeans 2.1, jak i specyfikacja Enterprise JavaBeans 3.0 wymagają obsługi architektury Java EE Connector Architecture 1.5, która obsługuje tryb wpychania. Z myślą o obsłudze trybu wpychania twórcy architektury JCA 1.5 wykorzystali model programowania komponentów sterowanych komunikatami. W szczególności architektura JCA 1.5 definiuje interfejs kontener-konektor, który umożliwia przetwarzanie komunikatów przychodzących (wysyłanych asynchronicznie przez system EIS) przez komponenty sterowane komunikatami. Przykładowo producent X mógłby opracować konektor Java EE dla agenta Mail Delivery Agent (MDA) pełniący funkcję oprogramowania odpowiedzialnego za dostarczanie wiadomości poczty elektronicznej. W ramach tego procesu producent X może wówczas zdefiniować interfejs nasłuchiwania komunikatów nazwany EmailListenr, który powinien być implementowany przez komponenty poczty elektronicz- nej sterowane komunikatami odpowiedzialne za przetwarzanie wiadomości poczty elektro- nicznej. Agent MDA „wpycha” otrzymywane z internetu wiadomości poczty elektronicznej Zarządzanie zasobami | 65 do kontenera EJB, który z kolei deleguje otrzymywane komunikaty do egzemplarzy odpo- wiednich komponentów sterowanych komunikatami. Programista aplikacji powinien następnie napisać komponent poczty elektronicznej sterowany komunikatami oznaczony adnotacją @javax.ejb.MessageDriven i implementujący wspominany już interfejs com.producent. EmailListener. Ostatecznie opracowany i wdrożony komponent poczty elektronicznej ste- rowany komunikatami może przetwarzać komunikaty przychodzące. Usługi podstawowe Istnieje wiele wartościowych usług opracowanych z myślą o aplikacjach rozproszonych. W niniejszej książce szczegółowo przeanalizujemy osiem najważniejszych usług nazywanych usługami podstawowymi (ang. primary services) z uwagi na konieczność ich implementowa- nia przez wszystkie kompletne platformy Enterprise JavaBeans. Usługi podstawowe oferują mechanizmy w takich obszarach jak współbieżność, przetwarzanie transakcyjne, utrwalanie danych, obsługa obiektów rozproszonych, asynchroniczne przesyłanie komunikatów, licznik czasowy, nazewnictwo i bezpieczeństwo. Serwery EJB automatycznie zarządzają wszystkimi wymienionymi usługami podstawowymi. Takie rozwiązanie zwalnia programistów aplikacji z trudnego obowiązku samodzielnego implementowania wszystkich lub części spośród wy- mienionych rozwiązań. Zamiast tracić czas na implementowanie tego rodzaju mechanizmów, programiści mogą się koncentrować wyłącznie na definiowaniu logiki aplikacji opisującej określony wycinek działalności biznesowej — za dostarczanie wszelkich niezbędnych usług na poziomie systemowym odpowiada serwer EJB. W kolejnych punktach omówimy poszcze- gólne usługi podstawowe i opiszemy wymagany zakres oferowanej funkcjonalności w ramach tych usług (zgodnie ze specyfikacją EJB). Współbieżność Chociaż współbieżność (ang. concurrency) jako taka jest istotna z perspektywy programistów komponentów wszystkich typów, w przypadku pewnych rodzajów komponentów ma nieco inne znaczenie niż w przypadku innych typów. Współbieżność w pracy komponentów sesyjnych i encyjnych Komponenty sesyjne nie obsługują dostępu współbieżnego. To ograniczenie jest w pełni uza- sadnione, jeśli uwzględnimy faktyczny charakter stanowych i bezstanowych komponentów sesyjnych. Stanowy komponent sesyjny jest rozszerzeniem pojedynczego klienta i pracuje wyłącznie w jego imieniu. W związku z tym oferowanie współbieżnego dostępu do tego ro- dzaju komponentów całkowicie mijałoby się z ich właściwym przeznaczeniem, ponieważ i tak są wykorzystywane przez te aplikacje klienckie, które je utworzyły. Także bezstanowe kom- ponenty sesyjne nie muszą oferować współbieżności, ponieważ i tak nie utrzymują stanu, który wymagałby współdzielenia (współbieżnego dostępu). Zasięg operacji wykonywanych przez bezstanowe komponenty sesyjne ogranicza się do zasięgu odpowiednich wywołań metod. Ponieważ ani stanowe, ani bezstanowe komponenty sesyjne nie reprezentują danych współ- dzielonych, w ich przypadku serwer EJB nie musi implementować usług zarządzających współbieżnością. 66 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe Ponieważ za obsługę współbieżności odpowiadają serwery EJB, metody samych komponentów nie muszą gwarantować bezpieczeństwa przetwarzania wielowątkowego. W rzeczywistości specyfikacja Enterprise JavaBeans wręcz zakazuje programistom komponentów EJB stosowa- nia słowa kluczowego synchronized. Zakaz używania w kodzie podstawowych konstrukcji synchronizujących pracę wątków skutecznie uniemożliwia programistom podejmowanie prób samodzielnego sterowania synchronizacją i — tym samym — przekłada się na większą wy- dajność egzemplarzy komponentów w czasie wykonywania. Co więcej, specyfikacja Enter- prise JavaBeans wprost zakazuje komponentom tworzenia własnych wątków. Innymi słowy, programista nie może z poziomu swoich komponentów tworzyć nowych wątków. Zacho- wywanie pełnej kontroli nad komponentem należy do kontenera EJB, który musi właściwie zarządzać współbieżnością, przetwarzaniem transakcyjnym oraz utrwalaniem danych. Dowolność w kwestii tworzenia wątków przez programistę komponentu uniemożliwiłaby kontenerowi nie tylko śledzenie działań komponentu, ale także właściwe zarządzanie pod- stawowymi usługami. Komponenty encyjne reprezentują dane współdzielone i jako takie mogą być przedmiotem dostępu współbieżnego. Komponenty encyjne zaliczamy do tzw. komponentów współdzie- lonych. Przykładowo w systemie EJB linii żeglugowych Titan Cruises są reprezentowane trzy statki: Paradise, Utopia i Valhalla. Komponent encyjny Ship reprezentujący statek Utopia w do- wolnym momencie może być adresatem żądań generowanych przez setki aplikacji klienckich. Aby współbieżny dostęp do komponentu encyjnego był możliwy, mechanizm odpowiedzialny za utrwalanie danych musi odpowiednio chronić dane reprezentowane przez taki kompo- nent współdzielony (mimo następującego jednocześnie dostępu wielu aplikacji klienckich do jednego logicznego komponentu encyjnego). Specyfikacja Java Persistence przewiduje, że kontener odpowiedzialny za ochronę współ- dzielonych danych komponentów encyjnych powinien tworzyć po jednej kopii egzemplarza komponentu encyjnego dla każdej z wykonywanych transakcji. Właśnie istnienie migawki danej encji dla każdej transakcji umożliwia prawidłową i bezpieczną obsługę współbieżnego, wielowątkowego dostępu. Warto się więc zastanowić, jak to możliwe, że kontener skutecznie chroni komponenty encyjne przed fałszywymi odczytami oraz próbami jednoczesnej aktuali- zacji przez wiele transakcji. Jednym z możliwych rozwiązań jest stosowanie strategii tzw. współbieżności optymistycznej z wykorzystaniem prostego mechanizmu pól reprezentują- cych wersje. Innym rozwiązaniem jest użycie opcji SERIALIZED dla poziomu izolacji interfejsu JDBC. Implementacje tworzone przez rozmaitych producentów mogą wykorzystywać własne, niestandardowe mechanizmy bezpośredniego blokowania dostępu do informacji na poziomie bazy danych. Wszystkie te zagadnienia zostaną szczegółowo omówione w rozdziale 16. Współbieżność w pracy komponentów sterowanych komunikatami W przypadku komponentów sterowanych komunikatami określenie współbieżność odnosi się do jednoczesnego przetwarzania więcej niż jednego komunikatu. Gdyby komponent ste- rowany komunikatami mógł w danej chwili przetwarzać tylko jeden komunikat, jego przy- datność dla rzeczywistych aplikacji byłaby znikoma, ponieważ systemy złożone z takich komponentów nie mogłyby sobie radzić z dużymi obciążeniami (wyrażanymi w liczbie ko- munikatów generowanych w określonych przedziałach czasowych). Na rysunku 3.4 przed- stawiono sytuację, w której do przykładowego systemu EJB docierają trzy komunikaty wyge- nerowane jednocześnie przez trzy różne aplikacje klienckie — trzy egzemplarze pojedynczego komponentu JMS-MDB, które zarejestrowały swoje zainteresowanie tego rodzaju komuni- katami, mogą jednocześnie przetwarzać wspomniane komunikaty. Usługi podstawowe | 67 Rysunek 3.4. Przetwarzanie współbieżne z wykorzystaniem komponentów sterowanych komunikatami Także te komponenty sterowane komunikatami, które implementują inne interfejsy API niż JMS, mogą korzystać z tych samych usług współbieżności co komponenty JMS-MDB. Egzemplarze wszystkich rodzajów komponentów sterowanych komunikatami są składowane w puli i wy- korzystywane do współbieżnego przetwarzania komponentów przychodzących — dzięki temu istnieje możliwość jednoczesnej obsługi setek lub wręcz tysięcy komunikatów generowanych przez aplikacje klienckie1. Transakcje Transakcja jest jednostką pracy lub zbiorem zadań wykonywanych sekwencyjnie w odpo- wiedzi na jedno żądanie. Transakcje są atomowe, co oznacza, że pojedynczą transakcję moż- na uznać za prawidłowo wykonaną wtedy i tylko wtedy, gdy uda się zrealizować wszystkie zadania składające się na tę transakcję. W poprzednim rozdziale wielokrotnie mówiliśmy o komponencie EJB TravelAgent w kontekście sposobu kontrolowania przez komponenty sesyjne interakcji z pozostałymi komponentami. Poniżej przedstawiono metodę bookPassage(), którą opisano w rozdziale 2.: public Reservation bookPassage(CreditCardDO card, double price) throws IncompleteConversationalState { if (customer == null || cruise == null || cabin == null) { throw new IncompleteConversationalState( ); } try { Reservation reservation = new Reservation(customer,cruise,cabin,price,new Date( )); entityManager.persist(reservation); process.byCredit(customer,card,price); return reservation; } catch(Exception e) { throw new EJBException(e); } } Metoda bookPassage() realizuje dwa zadania, które muszą być wykonane albo razem, albo wcale — tymi zadaniami jest odpowiednio utworzenie nowego egzemplarza Reservation oraz przetworzenie płatności. Kiedy komponent EJB TravelAgent jest wykorzystywany do rezer- wacji miejsca w kajucie dla nowego pasażera, musi zostać skutecznie przeprowadzone za- 1 W praktyce jednoczesne przetwarzanie czegokolwiek w sytuacji, gdy nie dysponujemy wieloma procesorami, jest bardzo trudne, jednak na poziomie pojęciowym nasze stwierdzenie jest prawdziwe. Wiele wątków w ramach tej samej wirtualnej maszyny Javy lub w ramach wielu maszyn wirtualnych korzystających z tego samego procesora (fizycznego układu obliczeniowego) mogą skutecznie imitować przetwarzanie współbieżne. 68 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe równo pobranie stosownej kwoty z karty kredytowej pasażera, jak i utworzenie nowej encji reprezentującej samą rezerwację. Gdyby inny komponent EJB, ProcessPayment, pobrał kwotę z karty kredytowej pasażera w sytuacji, gdy próba utworzenia nowej encji Reservation zakoń- czyła się niepowodzeniem, należałoby to działanie uznać za niewłaściwe. Podobnie nie po- winniśmy tworzyć nowej rezerwacji, jeśli nie uda się pobrać stosownej kwoty z karty kredytowej pasażera. Oznacza to, że serwer EJB musi uważnie monitorować tego rodzaju transakcje, aby zagwarantować właściwe wykonywanie wszystkich zadań. Transakcje są zarządzane automatycznie, zatem programiści komponentów EJB nie muszą stosować żadnych interfejsów API odpowiedzialnych za zarządzanie zaangażowaniem two- rzonych komponentów w przetwarzanie transakcyjne. Aby zasygnalizować serwerowi EJB sposób, w jaki powinien zarządzać komponentem w czasie działania, wystarczy w czasie wdrażania zadeklarować odpowiednie atrybuty transakcyjne. Okazuje się jednak, że specyfi- kacja EJB definiuje mechanizm umożliwiający bezpośrednie zarządzanie transakcjami tym komponentom, w przypadku których jest to niezbędne. Atrybuty transakcyjne ustawiane w czasie wdrażania, techniki zarządzania transakcjami wprost przez programistów kompo- nentów EJB oraz pozostałe zagadnienia związane z przetwarzaniem transakcyjnym zostaną omówione w rozdziale 16. Trwałość Komponenty encyjne reprezentują zachowania i dane właściwe dla osób, miejsc lub przed- miotów. W przeciwieństwie do komponentów sesyjnych i komponentów sterowanych ko- munikatami komponenty encyjne mają charakter trwały, co oznacza, że ich stan jest zapisy- wany (utrwalany) w bazie danych. Mechanizm utrwalania umożliwia zachowywanie encji w sposób umożliwiający uzyskiwanie dostępu zarówno do zachowań, jak i do danych kom- ponentów encyjnych w dowolnym czasie (bez konieczności samodzielnego odzyskiwania tych zachowań i danych w razie ewentualnej awarii). Java Persistence W specyfikacji Enterprise JavaBeans 3.0 całkowicie zweryfikowano dotychczasowe podejście do problemu utrwalania — zdecydowano się nawet na wyłączenie tej problematyki do od- rębnej, przebudowanej specyfikacji Java Persistence. O ile specyfikacja Enterprise JavaBeans 2.1 proponowała model, w którym utrwalanie było realizowane na poziomie komponentów, zgodnie z nową specyfikacją Java Persistence trwałe komponenty encyjne mają postać zwy- kłych obiektów Javy (nazywanych obiektami POJO). Encje można tworzyć poza środowi- skiem kontenera EJB. Sam proces ich tworzenia niczym się nie różni od procesów tworzenia wszystkich innych obiektów Javy z wykorzystaniem standardowego operatora new(). Co więcej, komponent encyjny może być w dowolnym momencie włączany do kolekcji kompo- nentów zarządzanych przez kontener lub wykluczany z tego zbioru. Za wiązanie egzempla- rzy komponentów encyjnych z pamięcią trwałą (najczęściej bazą danych) odpowiada usługa EntityManager. Usługa EntityManager oferuje metody umożliwiające tworzenie, odnajdy- wanie, odczytywanie, usuwanie i aktualizowanie komponentów encyjnych. Po połączeniu egzemplarza komponentu encyjnego z pamięcią trwałą kontener EJB odpowiada za zarzą- dzanie trwałym stanem tego komponentu i automatyczną synchronizację z odpowiednim źródłem danych. Usługi podstawowe | 69 Szczególnie interesującym aspektem modelu proponowanego w specyfikacji Java Persistence jest możliwość odłączania egzemplarzy komponentów encyjnych od kontenera EJB. Egzem- plarze komponentów EJB z reguły są odłączane od kontenera w chwili zakończenia wyko- nywania bieżącej transakcji. Warto pamiętać, że tak odłączone egzemplarze można swobod- nie przesyłać za pośrednictwem sieci zdalnym aplikacjom klienckim lub wręcz zapisywać na dysku. Stan tego rodzaju egzemplarzy może być modyfikowany, a same egzemplarze kompo- nentów można ponownie łączyć z kontenerem EJB za pomocą metody EntityManager.merge(). W momencie ponownego łączenia egzemplarza komponentu encyjnego z kontenerem EJB wszelkie zmiany dokonane na danym komponencie automatycznie są synchronizowane z zawartością pamięci trwałej. Nowy model utrwalania danych umożliwia programistom komponentów EJB rezygnację ze starej koncepcji obiektów transferu danych (ang. Data Transfer Object), co w znacznym stopniu upraszcza architekturę konstruowanych aplikacji. Szczegółowe omówienie tego zagadnienia można znaleźć w rozdziale 5. Utrwalanie obiektowo-relacyjne Utrwalanie obiektowo-relacyjne (ang. object-to-relational — O/R) wiąże się z koniecznością odwzorowywania stanu komponentów encyjnych w tabelach i kolumnach relacyjnej bazy danych. Ponieważ relacyjne bazy danych są wykorzystywane przez 99 procent aplikacji ko- rzystających z baz danych, grupa ekspertów zaangażowana w prace nad nową specyfikacją Enterprise JavaBeans (EJB 3.0 Expert Group) ustaliła, że opracowanie mechanizmu odwzo- rowań obiektowo-relacyjnych będzie dużo lepszym rozwiązaniem niż podejmowanie skaza- nych na niepowodzenie prób tworzenia jednej, uniwersalnej architektury utrwalania. Wsku- tek tej decyzji powstała specyfikacja Java Persistence obejmująca bogaty zbiór mechanizmów odpowiedzialnych za odwzorowywanie komponentów encyjnych w relacyjnych bazach da- nych z uwzględnieniem takich technik jak dziedziczenie, odwzorowania w wielu tabelach, zarządzanie wersjami czy obsługa rozszerzonego języka zapytań EJBQL. Ponieważ odwzo- rowania obiektowo-relacyjne są precyzyjnie definiowane przez konkretną specyfikację, współ- czesne aplikacje EJB oferują dużo większą przenośność pomiędzy rozwiązaniami różnych producentów, ponieważ w znacznym stopniu wyeliminowano konieczność stosowania me- tadanych właściwych dla poszczególnych produktów. Przeanalizujmy teraz prosty przykład stosowania techniki odwzorowań obiektowo-relacyjnych w praktyce. W systemie informatycznym linii żeglugowych Titan Cruises klasa Cabin modeluje kajutę na statku. Klasa Cabin definiuje trzy pola składowe: name, deckLevel oraz id. Definicję klasy Cabin przedstawiono poniżej: @Entity @Table(name= CABIN ) public class Cabin { private int id; private String name; private int deckLevel; @Column(name= NAME ) public String getName( ) { return name; } public void setName(String str) { name = str; } @Column(name= DECK_LEVEL ) public int getDeckLevel( ) { return deckLevel; } public void setDeckLevel(int level) { deckLevel = level; } 70 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe @Id @Column(name= ID ) public int getId( ) { return id; } public void setId(int id) { this.id = id; } } W prezentowanym przykładzie metody akcesorów reprezentują pola komponentu encyjnego zarządzane przez kontener EJB. Skoro stosujemy mechanizm odwzorowań obiektowo-rela- cyjnych, możemy przyjąć, że pola komponentu encyjnego odpowiadają kolumnom relacyjnej bazy danych. Metadane opisujące odwzorowania obiektowo-relacyjne należy definiować w formie adnotacji poprzedzających zarówno metody akcesorów (@Column oraz @Id), jak i klasę komponentu (@Table). Przykładowo pole deckLevel klasy Cabin jest odwzorowywane w ko- lumnie DECK_LEVEL tabeli nazwanej CABIN i wchodzącej w skład relacyjnej bazy danych linii Titan Cruises. Na rysunku 3.5 przedstawiono graficzny schemat tego odwzorowania. Rysunek 3.5. Schemat odwzorowania obiektowo-relacyjnego komponentów encyjnych Kiedy pola komponentu encyjnego zostaną już odwzorowane w relacyjnej bazie danych, kontener bierze na siebie odpowiedzialność za utrzymywanie zgodności stanu danego eg- zemplarza komponentu z zawartością odpowiednich tabel bazy danych. Proces utrzymywa- nia tej zgodności bywa nazywany synchronizacją stanu egzemplarza komponentu. W przy- padku klasy Cabin egzemplarze komponentu encyjnego są odwzorowywane w odrębnych wierszach tabeli CABIN relacyjnej bazy danych. Oznacza to, że modyfikacja egzemplarza komponentu encyjnego Cabin wymaga jego zapisania we właściwym wierszu bazy danych. Warto pamiętać, że niektóre z komponentów są odwzorowywane w więcej niż jednej tabeli bazy danych. Tego rodzaju odwzorowania są znacznie bardziej skomplikowane i często wy- magają stosowania między innymi złączeń SQL-a i wielokrotnych aktualizacji — złożone odwzorowania obiektowo-relacyjne przeanalizujemy w dalszej części tej książki. Specyfikacja Java Persistence dodatkowo definiuje pola relacji komponentów encyjnych, które umożliwiają wchodzenie tego rodzaju komponentów w relacje „jeden do jednego”, „jeden do wielu” oraz „wiele do wielu” z pozostałymi komponentami. Co więcej, komponenty encyjne same mogą utrzymywać kolekcje innych komponentów encyjnych lub pojedyncze referencje. Model Java Persistence szczegółowo omówiono w rozdziałach od 5. do 10. Usługi podstawowe | 71 Obiekty rozproszone Kiedy mówimy o interfejsach komponentów oraz innych klasach i interfejsach technologii EJB wykorzystywanych przez oprogramowanie klienckie, mamy na myśli perspektywę klienta danego systemu EJB. Perspektywa klienta EJB (ang. EJB client view) nie obejmuje egzempla- rzy klas komponentów sesyjnych, kontenera EJB, mechanizmu wymiany egzemplarzy ani żadnych innych szczegółów związanych z implementacją poszczególnych komponentów se- syjnych. Z perspektywy klientów zdalnych komponent jest definiowany przez interfejs zdalny lub interfejs punktu końcowego2. Wszystkie inne elementy, włącznie z mechanizmem wyko- rzystywanym do obsługi obiektów rozproszonych, są niewidoczne. Jeśli wykorzystywany serwer EJB prawidłowo obsługuje perspektywę danego klienta EJB, w komunikacji pomiędzy tymi węzłami może być stosowany dowolny protokół obiektów rozproszonych. Specyfikacja Enterprise JavaBeans 3.0 mówi, że każdy serwer EJB musi obsługiwać protokół Java RMI-IIOP, co nie oznacza, że serwery EJB nie mogą obsługiwać także innych protokołów (w tym inter- fejsu Java RMI API oraz protokołu CORBA IIOP). Specyfikacja EJB 3.0 dodatkowo nakłada na producentów serwerów obowiązek implementowania obsługi protokołu SOAP 1.2 za po- średnictwem interfejsu JAX-RPC API. Niezależnie od wykorzystywanego protokołu serwer EJB musi obsługiwać żądania klientów Javy z wykorzystaniem odpowiedniego interfejsu API tych klientów, zatem stosowany pro- tokół powinien oferować możliwość odwzorowywania do modelu programowania Java RMI-IIOP lub JAX-RPC. Na rysunku 3.6 przedstawiono przykład interfejsu EJB API języka Java obsłu- giwanego przez różne protokoły obiektów rozproszonych. Rysunek 3.6. Perspektywa klienta systemu EJB obsługiwana przez różne protokoły Specyfikacja Enterprise JavaBeans przewiduje możliwość uzyskiwania przez oprogramowanie klienckie napisane w językach innych niż Java dostępu do komponentów EJB (pod warun- kiem, że producent serwera EJB zaimplementuje odpowiednie mechanizmy). Przykładem ta- kiego rozwiązania jest mechanizm odwzorowań EJB-CORBA opracowany przez firmę Sun3. Dokument opublikowany przez Sun Microsystems opisuje język definiowania interfejsów architektury CORBA (ang. CORBA Interface Definition Language — CORBA IDL), za pomocą którego można uzyskiwać dostęp do komponentów EJB z poziomu klientów technologii CORBA. Aplikacje klienckie architektury CORBA można pisać w dowolnych językach progra- mowania, włącznie z takimi językami jak C++, Smalltalk, Ada czy COBOL. Wspomniany me- chanizm odwzorowujący dodatkowo obejmuje szczegółowe rozwiązania w zakresie obsługi 2 Nieco inaczej jest w przypadku komponentów encyjnych, ponieważ egzemplarze klas tego rodzaju kompo- nentów mogą być odłączane od kontenera i wysyłane do zdalnego klienta (pod warunkiem, że wspomniane klasy implementują interfejs java.io.Serializable). 3 Enterprise JavaBeans™ to CORBA Mapping, Version 1.1, Sanjeev Krishnan, Sun Microsystems, 1999. 72 | Rozdział 3. Zarządzanie zasobami i usługi podstawowe perspektywy klientów Java EJB, odwzorowań systemu nazewnictwa architektury CORBA w system nazewnictwa serwerów EJB oraz rozproszonymi transakcjami obejmującymi swoim zasięgiem zarówno obiekty CORBA, jak i komponenty EJB. Innym ciekawym przykładem jest odwzorowanie EJB-SOAP zbudowane na bazie technologii JAX-RPC. Odwzorowanie EJB-SOAP umożliwia aplikacjom klienckim SOAP napisanym w takich językach jak Visual Basic .NET, C# czy Perl uzyskiwanie dostępu do bezstanowych komponentów sesyjnych. Na rysunku 3.7 przedstawiono możliwe rozwiązania w zakresie uzyskiwania dostępu do serwera EJB z poziomu innych obiektów rozproszonych. Rysunek 3.7. Komponent EJB udostępniany różnym rozproszonym aplikacjom klienckim Asynchroniczne przesyłanie komunikatów Przed wydaniem specyfikacji Enterprise JavaBeans 2.0 asynchroniczne przesyłanie komuni- katów nie było zaliczane do zbioru usług podstawowych, ponieważ implementacja obsługi teg
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Enterprise JavaBeans 3.0. Wydanie V
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: