Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00175 007772 10476019 na godz. na dobę w sumie
Head First EJB. Edycja polska (Rusz głową!) - książka
Head First EJB. Edycja polska (Rusz głową!) - książka
Autor: , Liczba stron: 720
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-548-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> java - programowanie
Porównaj ceny (książka, ebook, audiobook).

EJB (Enterprise JavaBeans) to technologia najczęściej wykorzystywana do tworzenia aplikacji opartych na komponentach. Aby ją efektywnie wykorzystywać, musisz zgłębić jej podstawowe założenia, dowiedzieć się, na jakie typy dzielimy komponenty, jak działają mechanizmy transakcji i do czego służą wzorce projektowe. Przeraża Cię to? Niepotrzebnie. Otwórz swój umysł. Poznaj technologię EJB w sposób gwarantujący jej szybkie i skuteczne opanowanie. Zapomnij o listingach liczących tysiące wierszy i długich, nużących opisach teoretycznych. Czytając książkę 'Head First EJB. Edycja polska', poznasz technologię EJB w ciekawszy sposób.

Dzięki tej książce wszystkie pojęcia związane z EJB przestaną być dla Ciebie wiedzą tajemną. Autorzy książki, wykorzystując najnowsze elementy teorii uczenia, przedstawią Ci wszystkie zagadnienia niezbędne do rozpoczęcia projektowania i tworzenia aplikacji w technologii EJB. Poznasz architekturę EJB, cykle życia komponentów entity bean, session bean i message-driven bean, CMP, EJB-QL, transakcje, bezpieczeństwo, wzorce i ogólne idee tworzenia aplikacji opartych na komponentach. Jednak, co najważniejsze, nauczysz się stosować tę wiedzę w praktyce.

W książce poruszono między innymi następujące tematy:

Przekonaj się, że nawet przy poznawaniu skomplikowanych technologii można się świetnie bawić.

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. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Head First EJB. Edycja polska Autorzy: Kathy Sierra, Bert Bates T³umaczenie: Rafa³ Joñca, Piotr Rajca ISBN: 83-7361-548-2 Tytu³ orygina³u: Head First EJB Format: 200×234, stron: 720 EJB (Enterprise JavaBeans) to technologia najczêœciej wykorzystywana do tworzenia aplikacji opartych na komponentach. Aby j¹ efektywnie wykorzystywaæ, musisz zg³êbiæ jej podstawowe za³o¿enia, dowiedzieæ siê, na jakie typy dzielimy komponenty, jak dzia³aj¹ mechanizmy transakcji i do czego s³u¿¹ wzorce projektowe. Przera¿a Ciê to? Niepotrzebnie. Otwórz swój umys³. Poznaj technologiê EJB w sposób gwarantuj¹cy jej szybkie i skuteczne opanowanie. Zapomnij o listingach licz¹cych tysi¹ce wierszy i d³ugich, nu¿¹cych opisach teoretycznych. Czytaj¹c ksi¹¿kê „Head First EJB. Edycja polska”, poznasz technologiê EJB w ciekawszy sposób. Dziêki tej ksi¹¿ce wszystkie pojêcia zwi¹zane z EJB przestan¹ byæ dla Ciebie wiedz¹ tajemn¹. Autorzy ksi¹¿ki, wykorzystuj¹c najnowsze elementy teorii uczenia, przedstawi¹ Ci wszystkie zagadnienia niezbêdne do rozpoczêcia projektowania i tworzenia aplikacji w technologii EJB. Poznasz architekturê EJB, cykle ¿ycia komponentów entity bean, session bean i message-driven bean, CMP, EJB-QL, transakcje, bezpieczeñstwo, wzorce i ogólne idee tworzenia aplikacji opartych na komponentach. Jednak, co najwa¿niejsze, nauczysz siê stosowaæ tê wiedzê w praktyce. W ksi¹¿ce poruszono miêdzy innymi nastêpuj¹ce tematy: (cid:129) Architektura aplikacji EJB (cid:129) Typy komponentów (cid:129) Tworzenie i stosowanie komponentów session bean oraz entity bean (cid:129) Powi¹zania pomiêdzy komponentami (cid:129) Po³¹czenia z baz¹ danych (cid:129) Komunikaty (cid:129) Obs³uga wyj¹tków w komponentach (cid:129) Tworzenie mechanizmów autoryzacji (cid:129) Wdra¿anie aplikacji EJB Przekonaj siê, ¿e nawet przy poznawaniu skomplikowanych technologii mo¿na siê œwietnie bawiæ. Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 5 Spis treści (podsumowanie) Wprowadzenie 1. Zapraszamy do EJB: wprowadzenie 2. Architektura EJB: omówienie architektury 3. Ujawnianie się: z punktu widzenia klienta 4. Być komponentem session bean: cykl istnienia komponentów session bean 5. Encje są trwałe: informacje podstawowe o komponentach entity bean 6. Być komponentem entity bean: synchronizacja komponentu i encji 7. Kiedy komponenty są ze sobą powiązane: relacje komponentów entity bean 8. Odbieranie komunikatu: komponenty message-driven bean 9. Wiek niepodzielności: transakcje EJB 10. Gdy coś się przytrafia komponentom: wyjątki w EJB 11. Chroń swoje tajemnice: bezpieczeństwo w EJB 12. Radość wdrażania: środowisko komponentów A Ostateczny egzamin próbny Skorowidz 16 25 85 135 197 283 319 397 461 493 549 593 623 661 707 Spis treści (szczegółowy) W Wprowadzenie 6MCAIJI?AJHM=O=-* 9JOH@E=A6O IJ=H=IIE(cid:15)?AC @MEA@EA=6MC H E+EFHOIKC(cid:15)EEAFHO=@=IE(cid:15)@=F=E(cid:10)JOM=E= @ OM=AMEA@O6MCO EI EATAFEAIJ=ME(cid:15)EAI?AMF=E(cid:15)?E= =H@EAEIJJAEBH=?A=FHO=@=E?D@EE?DMEAH J=A’OKE= @  ?OA’@’AEA=C=IM =H@EAAIJ@ HOFOIA^)=JAM=EIFI ’AIFHA=IMC’A6MA’O?EA=A’O@F=E=-* Po co została napisana ta książka? Wiemy, co sobie myśli Twój mózg Metapoznanie Zmuś swój mózg do posłuszeństwa Czego będziesz potrzebować podczas lektury tej książki Zdajemy egzamin certyfikujący Podziękowania 14 15 17 19 20 22 24 5 Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 6 1 i g u ł s u   2 Zapraszamy do EJB Komponenty Enterprise JavaBean są łatwe. 2HO=EAA EFHM=OA  JO?JHA = O=FEI== OM=IH(cid:15)?EAIJMHOI=M=O JH=I=?OO AFEA?OJHM=OEMIF EA’OIAHMAHFAJM HFH=?OO?D9JOH@E=AIJMHOOM@H’OOEKHK?DEO=FE=?(cid:15) -*==IJ(cid:15)FEAFEIAOAI?ACOEI?OO@MEAIIE(cid:15)J=’A=EA =AJO=JA?DCE=-*=EAI A?A?DO?D=H=JAHOIJO?AEF=I F EA’EA=I=@O@E==E=JAAHM-* SSeerrwweerr logika biznesowa oddzielona od danych * Cele O co chodzi w technologii EJB? Żadnych rozwiązań zależnych od dostawcy! Jak to wszystko działa? Za kulisami… Trzy rodzaje komponentów Komponent Doradcy Pięć czynności niezbędnych do stworzenia komponentu Zadania i obowiązki EJB Poradnik Bar kawowy 26 27 29 31 32 35 39 40 50 52 83 i y w o s e n z b s e f r e t n j i  EAJ -  *  FA J -  Architektura EJB Technologia EJB jest związana z infrastrukturą. FAJOI AAAJ=E IJHK?OOE6A?DCE=J=K’EME=JMHAEA =H@@K’O?D=FE=?E )FE=?EJHAFM== =EA=MIOIJF? MIO@ IKCEBEHO 8E?JHE=I5A?HAJI=I?OMIO==H @=EKMIOIJEE@KAJ=E M ?AJHK =@=M?O+-4EAEAA@==H?DEJAJKH=HME =E=J=EA A=IJO? ?E?OEI=M= ?EEAAIJFHIJ=9IOIJ=?O=IE(cid:15)@ @AKFHCH=M=E=HFHIACU interfejs Remote brak metod interfejs EJBObject kilka metod interfejs KoszykZKsiazkami dodajKsiazke() usunKsiazke() pokazKsiazkiWKoszyku() zaplac() interfejs EnterpriseBean brak metod interfejs SesionBean kilka metod KOSZYKBEAN to TY piszesz tę klasę (klasa komponentu) dodajKsiazke() usunKsiazke() pokazKsiazkiWKoszyku() zaplac() inne metody Cele Wywoływanie zdalnej metody A co z argumentami i wartościami wynikowymi? Klient wywołuje metodę biznesową za pośrednictwem zdalnego interfejsu biznesowego EJB wykorzystuje technologię RMI Zdalny obiekt nie jest komponentem — to strażnik komponentu Przegląd architektury — komponenty session bean Przegląd architektury — komponenty entity bean Przegląd architektury — tworzenie stanowego komponentu session bean Przegląd architektury — tworzenie bezstanowego komponentu session bean Przegląd architektury — komponenty message-drive bean Zorganizuj swoje komponenty 86 88 91 103 105 106 122 123 124 125 130 132 to TY piszesz ten interfejs (interfejs zdalnego komponentu) 6 Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 7 Komponent bezstanowy Obiekt bazowy Wszystkie te komponenty są identyczne! komponent komponent komponent 9FHOF=@K AIJ=MO?DFAJM IAIIE A= KJMHO?DFHAJAI=  EAJ =MOAJ@=isIdentical() =MIAMH=?=M=HJ JHKA=MAJ@= H’O?DFAJM 4 To dla mnie? To jest tak wyjątkowa chwila! Jeden jedyny raz w życiu… 3 Ujawnianie się Swoich komponentów nie możesz zachować tylko dla siebie. EAJOKI EA @IJ(cid:15)F@EIJEA ?O?DFAJMEA@JO?OJFAJMAII=CA @HELA A=JHAEA@OIFK ME@EAEAJ==IKomponent Doradca K@IJ(cid:15)FE=AJ@(cid:15) getPorada() M?D@ ? MI=@EJAHBAIKFAJK IJ=ME ?ACEAI?AMJHOI @A=HM=AAJ@O EAIMAA@=J AI?AEAMIOIJ?EAJOC  =?OE@?AC= @IJ(cid:15)F 2=E(cid:15)J=’AEJAHBAIDoradca @EA@E?OFEJAHBAIEAEJBObjectJHOFIE=@= M=IA AJ@OAJ@O@JHO?DEAJO= @IJ(cid:15)FAJ@OJHAEAJO C MOM=6I=@JO?OEJAHBAIK =MAC Cele Czego tak naprawdę chce klient Czym jest JNDI? PortableRemoteObject.narrow() (egzotyczne rzutowanie) Tworzenie interfejsu bazowego dla komponentu session bean Na szczęście mamy uchwyty Jakie metody nadają się do umieszczenia w lokalnym interfejsie klienta? Dlaczego jest tak dużo metod remove() Porównanie interfejsu zdalnego i lokalnego Argumenty metod zdalnych i lokalnych Bar kawowy 136 137 140 145 149 163 172 175 178 187 192 Być komponentem session bean Komponenty session beansą tworzone i usuwane. A E=II?(cid:15) ?EAJAIJA FAJA AIJ=MO5?(cid:15) ?EAC@O’EIJEAEAFAJMIJ=MO?D AIJ?=ME?EA=A’A@=FHOIMEA?KO?DEAJM5 AJMHA= ’ @=EAEAJ==A@OO IAIAE?DEIJEAE=E EAH?EAIJIK’AEAJAK EAJME)A?J=’O?EAFAJK AIJ=MACAIJ?K@MA*=IAO @HEEJOE=KJEEF=H=I=EE’=@AK@O M?E ’IFJO=IE(cid:15)J=MEAA H’O?DEAJM Cele Metody zwrotne kontenera, dla szczególnych chwil w życiu komponentu Tworzenie komponentu Czynności komponentów jakie można wykonywać w metodach biznesowych Dezaktywacja: szansa na zapewnienie skalowalności dla komponentów stanowych Usuwanie komponentu Tworzenie komponentu session bean: Twoje zadanie jako Dostawcy Komponentów SessionContext: to Ty bardziej potrzebujesz kontekstu niż on Ciebie Bar kawowy 198 205 212 223 224 232 254 264 268 7 Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 8 5 Encje są trwałe FAJOAJEJO A= I JHM=A FAJOAJEJO A= EIJEA  FAJOAJEJO A= FFHIJKI 5J=ME A EAJM HAFHAAJ=?(cid:15) EBH=?EF?D@ ?O?DJHM=AC=C=OK9O H= I EA’AJ == @=O?DC@O’ME(cid:15)I FAJMAJEJO A= HAFHAAJKAEBH=?A F?D@ ?AHA=?OO?D =@=O?DA E@OIFKAIFAJAAJEJO A= KlientJA@AJ=EFAJ’AHAFHAAJM=A?(cid:15)=M=IE 1,! =EOA?(cid:15),HJ=E EAME? 6HOFAJOHAFHAAJK ?A JHOB=JO?EAEIJEA ?AA?AFAJOAJEJO A= I FFHIJKHA=E=? ?AC ?K’EIJEAA Jeśli masz jakieś ostatnie życzenie, to lepiej wypowiedz je w metodzie ejbRemove()… Och nie! Proszę, nie! Dam Ci cokolwiek zechcesz, tylko nie wywołuj metody remove()! Cele Czym jest komponent entity bean Komponenty entity bean z punktu widzenia klienta Bardzo prosty komponent entity bean Klient Zdalny interfejs komponentu dla komponentu entity bean Interfejs zdalnego obiektu bazowego komponentu entity bean Czego klient oczekuje od interfejsu obiektu bazowego komponentu entity bean Z pomocą spieszą metody biznesowe interfejsu obiektu bazowego Metoda create() komponentu session bean a metoda create() komponentu entity bean Metoda remove() komponentu session bean a metoda remove() komponentu entity bean Usunięcie encji, komponentu, egzemplarza komponentu Bar kawowy 284 285 289 292 294 297 298 302 305 306 309 312 6 Jeśli jestem komponentem, mówię metodzie: „Nie wywołuj moich metod, wywołuj metody mojego strażnika, oto jego namiary…” komponent Zamiast: zrobCos(this); obiekt EJBObject Użyj: zrobCos(mojKontekst.getEJBObject()); 8 Być komponentem entity bean Komponenty entity beansą aktorami. /@OEIJEA FHA OM=  @ MFKE @ IJ= IE(cid:10) E E KHOJACJHM=AC=C=OKA?=EF?D@ ?OE  =O@=O?DEA@OFAJM?EA=IE(cid:15)M?O FIJ=KIE O?=O?=I IO?DHEM=OHAFHAAJM= A? 9O H= I EA===J=IJHB= C= OIE(cid:15)MO@=HOC@O OFAJK@=M==FHO=@==E?D= =J  E’OACEEJHA@OJMOM =EA@=O?DUE=FE=JOB=?EA FEBHM=FAJ Cele Prawdziwą potęgą komponentów entity bean jest synchronizacja Porównanie trwałości zapewnianej przez kontener oraz przez komponent Interfejs EntityBean udostępnia nowe metody zwrotne kontenera Tworzenie komponentu entity bean CMP Tożsamość obiektu: klucz główny Metody wyszukiwawcze Metody biznesowe interfejsu bazowego Bar kawowy 320 322 327 334 337 356 363 369 386 Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 9 7 Kiedy komponenty są ze sobą powiązane Komponenty entity beanpotrzebują relacji. Zamówienie FJHA KAKlienta ElementZamówienia FJHA KAZamówieniaZamówienie FJHA KA ElementuZamówienia2E(cid:15)@OFAJ=EAJEJO A= C MOIJ(cid:15)FM= HA=?A=H @=AFHAJAAHEMJ=EFHOF=@KJJAAH@ = FH=JO?EAMIOIJ6HA =IJMHOMOElementZamówienia I=HO  ZamówieniemA EFFHIEOKlienta FHA@IJ=MEAEAACZamówień KOI=OMOElementZamówieniaAI?AAFIAAIJA@=JE’IJIK ? (cid:15)O-*3’AOJMHOFHA=I=A =FOJ=E= Mnogość: wiele Film Rezyser getRezyser() Liczność: jeden Rezyser Collection getFilmy() 0..* 1 Z konkretnym komponentem Film może być skojarzony tylko jeden Rezyser, lecz z komponentem Rezyser może być skojarzonych więcej komponentów Film. Cele Relacje Liczność Pola CMP oraz CMR Kaskadowe operacje usuwania mogą propagować EJB-QL dla komponentu FilmBean Klauzule SELECT oraz FROM są obowiązkowe Klauzula WHERE Kolekcje nie szczekaj()ą! Wyrażenia BETWEEN, IN, IS EMPTY oraz LIKE Przypisania relacji Bar kawowy 398 402 404 407 417 426 433 435 438 440 445 449 462 471 472 474 479 482 487 9 8 Odbieranie komunikatu Odbieranie komunikatów to świetna zabawa. ’AEAAIJJ=EA= @ EAH=EAF=?E=F  EAM= ?=5KHBAJ=cFMOCH=A=K?E= FHJ=KA*=OEAEAA@=EJ=AIJ= =MAEABAJOMA9O H= I EA ’A FFHAI=EK=MEAE=EA O O MIJ=EAFK ?EEAI=E==’@ AJK@IJ=H?AE=FHAIOE6=M= EAIE(cid:15)@EAAMFHOF=@K FAJMIAIIE A= EAJEJO A=A@=@E(cid:15)EFAJ AII=CA@HELA A= EAJ’AFHAI=KE=JEE =IF=?AH Moje życie jest smutne. Nie mam domu, nie mam klientów… a swojego kontekstu mogę używać WYŁĄCZNIE do obsługi transakcji… Przynajmniej należę do puli… Cele Tworzenie komponentu message-driven bean: Twoje zadania jako Dostawcy Komponentów Kompletny deskryptor komponentu message-driven bean Tematy i kolejki MessageDrivedContext Potwierdzenie komunikatu Bar kawowy interfejs EJBContex getCallerPrincipal() getEJBHome() isCallerInRole(String s) getRollbackOnly() getEJBLocalHome getUserTransaction getRollbackOnly() interfejs MessageDrivenContex // ten interfejs nie dodaje żadnych nowych metod Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 10 9 Wiek niepodzielności Transakcje strzegą Twojego bezpieczeństwa. ,E(cid:15)EJH=I=?’AI IFH M=MO=FAM FAH=?(cid:15)MEA@ ?’AA E? IE(cid:15)EAFMEA@EA (cid:15)@EAICK@=M=’AMCAE?IE(cid:15)EAIJ=9IOIJMH?E@IJ=K M =E=FE=?==@M==IE(cid:15)FHA@ F@(cid:15)?EAFH OMO=E=FAH=?E 6H=I=?AM-*I ?O MIF=E=Oa’=M@H’OFAJ  JH=I=?=E@IJIM=OE@ACFJHA EJ AMFHM=@=E= =E?DMEA E=MAC@EA H@MO?OME ?EAA EJHA =J!= =FEI=@ IKCK ?OJH=I=?A Obowiązkowy znaczy istniejąca zwraca interfejs komponentu kup tę książkę Zapamiętaj Komponenty CMT transakcji nie znają a komponenty BMT własnych używają. W porządku, sami wiemy, że ten wierszyk nie jest najlepszy.Ale może samemu spróbujesz napisać lepszy? Metody wspomagające zapamiętywanie mogą pomóc, ale działają znacznie lepiej, kiedy stosuje się je samemu. 10 O jejku! Wyjątek systemowy. Nic nie mogę na to poradzić. I tak oto diabli wzięli moje bezstanowe komponenty. Muszę wszystko zaczynać od początku… Pokocham wyjątki programowe… Mogę wyjść z trudnej sytuacji, jeśli przekażę w wywołaniu metody create() argumenty o różnych wartościach… 10 wstęp Cele Test ACID Transakcje w EJB Pewne transakcje nie są propagowane W jaki sposób utworzyć transakcję? Metoda setRollbackOnly() istnieje w DWÓCH interfejsach? Komponent BMT może się okazać bardzo ZŁYM pomysłem. BMT utrudnia wielokrotne użycie komponentu Transakcje zarządzane przez kontener (CMT) Jak działają atrybuty? Oto metody, dla których MUSISZ określić atrybut (dla komponentu CMT) „Nieokreślony kontekst transakcji” Przykład deskryptora dla komponentu CMT „Szczególne momenty” interfejsu SessionSynchronization Bar kawowy 494 496 498 499 500 511 514 515 516 522 523 527 536 540 Gdy coś się przytrafia komponentom Oczekuj nieoczekiwanego. EA=A’EA@6MO?DIJ=H=M=FE=?E’AIE(cid:15) @=HO? EA@ HAC+ IJH=IACJH=CE?ACKIEIIE(cid:15)FHA@JO = AFEA?OEA’AI@FK ?E@JAC O=M=HE=FHAHM==FH=?(cid:15)?=A =FE=?EEJJO@=JAC’AA@AFAJCIEMO JA)FE=?=KIE @E==@=A EA’AI=F EA?JH=CA@EEA@=’AIIE(cid:15)=E FHOCJM=KIEIMEA@EA=EAIOJK=?E@=IE(cid:15)MO ===K’=JEA FMEEJ AIJ@FMEA@E=O==EIJE=OIJ=HA?O Cele W EJB wyjątki dzielimy na dwa rodzaje: systemowe i programowe W przypadku wyjątku programowego, kontener… W przypadku wyjątku systemowego, kontener… Wyjątek RemoteException wędruje do zdalnych klientów, a wyjątek EJBException do lokalnych klientów Obowiązki dostawcy komponentu Pięć standardowych wyjątków programowych EJB Typowe wyjątki systemowe Bar kawowy 550 556 557 558 563 565 572 575 587 Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 11 11 Chroń swoje tajemnice Strzeż swoich tajemnic. *AFEA?AIJMME ’AIE(cid:15)KMEAHOJAE=EA E =KJHO=? 9FEAHMIAA ?EKIEIFJMEAH@EIM J’I= =O FJAFMEAO+E?’AIH E9JA?DCEE-*=JM’==FAME AFEA?AIJMC@O’FHCH=EIJ=KIE=@ =A@OEA=KJHO=?(cid:15)66O @A?O@KAIJ (cid:15)@EAEA@IJ(cid:15)F@HA O?DAJ@FAJKAIJJO A@AFH AUA EAIJA Dostawcą Komponentów K Twórcą Aplikacji J FH=M@F@ EAEAMEAI E (cid:15)@ AK’OJME?O W deskryptorze wdrożenia EJB W sposób charakterystyczny dla dostawcy W sposób charakterystyczny dla firmy sseeccuurriittyy--rroollee--rreeff sseeccuurriittyy--rroollee uużżyyttkkoowwnniiccyy ii ggrruuppyy RRzzeecczzyywwiissttee oossoobbyy Cele W jaki sposób określić zasady bezpieczeństwa w EJB Zadanie konstruktora aplikacji: sterowanie dostępem Definiowanie uprawnień do wykonywania metod com headfirst META-INF ejb-jar.xml Doradca.class DoradcaHome.class DoradcaBean.class Cele Szczególne miejsce dla komponentów — java:comp/env Wszystko jest tylko podkontekstem Obowiązki dostawcy komponentów i konstruktora aplikacji Obowiązki wdrożeniowca Zapamiętaj kto jest za co odpowiedzialny Jaki interfejs programistyczny zapewnia EJB 2.0 Co MUSI się znaleźć w pliku ejb-jar? Ograniczenia programowe Bar kawowy 624 626 633 641 642 643 645 648 649 651 11 594 597 598 602 607 610 611 615 616 617 Zadania wdrożeniowca: przypisanie konkretnych osób do abstrakcyjnych ról Bezpieczeństwo na poziomie klasy a bezpieczeństwo na poziomie egzemplarza Wykorzystanie bezpieczeństwa programistycznego do „uszycia metody skrojonej na miarę” własnych potrzeb Użyj elementu run-as , aby udawać, iż ktoś inny wywołał metodę Propagacja kontekstu bezpieczeństwa przy użyciu run-as Bar kawowy 12 SSŁŁÓÓJJ 11 ejb-jar Radość wdrażania Ciężko pracowałeś nad stworzeniem tego komponentu. @M=A  FEM=A FHAJAIJM=A +DO =EE=H@H=OIJ=JE HA? = ?D?E= O H EAIJ@OBEM=EAK’FHAJAIJM=AC@KJO@=JAC ’A EAEIE(cid:15)=E I?ACMBECKH=?EM@H=’=E==FE=?E)?H EA E =MAJEA=O @K H@MAC6A?DCE=-*FM===MEAHJA MOHOIJOM=EAFAJM@E(cid:15)E=IJIM=EK@AIHOFJHM HEAI?AE=JHA’=@IJIM=@M=IO?DFJHA H=IFA?=AC H@MEI= FAJM Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 12 A S Bar Bar kakawwoowywy Ostateczny Próbny Egzamin Baru Kawowego. To jest to. 70 pytań. Forma, zagadnienia i poziom trudności jest niemal taki sam jak na prawdziwym egzaminie. My to wiemy. Ostateczny egzamin próbny Skorowidz 661 707 12 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 85 Rozdział 2. Przegląd architektury Architektura EJB Ten widok zapiera dech w piersiach. Ale nie można w nieskończoność pozostawać na tym poziomie… Technologia EJB jest związana z infrastrukturą. Komponenty są elementami konstrukcyjnymi. Technologia ta daje możliwość tworzenia bardzo dużych aplikacji. Aplikacji, które pozwalają na niemal wszystko, począwszy od obsługi firmy Victoria’s Secrets, a skończywszy na zarządzaniu wszystkimi dokumentami w centrum badawczym CERN. Niemniej jednak architektura rozwiązania o takiej elastyczności, mocy i skalowalności nie jest prosta. Wszystko zaczyna się od modelu programowania rozproszonego, w którym klienty, serwery, a nawet poszczególne fragmenty tej samej aplikacji działają „gdzieś” w sieci. Ale w takim razie, jak klient ma odnaleźć komponent? Jak może wywołać metody komponentu? Dlaczego istnieją różne typy komponentów? Czy Ridge ponownie ożeni się z Taylor? to jest nowy rozdział 85 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 86 Brak celów Cele Informacje podstawowe Celem niniejszego rozdziału jest przekazanie Ci podstawowych informacji związanych z technologią EJB, a nie udzielenie wyjaśnień dotyczących konkretnych celów egzaminacyjnych. Niemniej jednak, równie dobrze mógłbyś stwierdzić, że każdy cel i każda odpowiedź udzielana na pytania egzaminacyjne zależą od znajomości i zrozumienia tych zagadnień podstawowych. Nie przejmuj się jednak, wystarczająco dużo celów egzaminacyjnych znajdziesz w kolejnym, 3. rozdziale. W rozdziale 6. będziesz już z rozrzewnieniem wspominać ten rozdział i przypominać sobie co czułeś, kiedy nie miałeś na głowie żadnych celów. Będziesz jeszcze tęsknić za tym rozdziałem, więc delektuj się jego lekturą póki jeszcze możesz. 86 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 87 Przegląd architektury Czy pamiętasz ten rysunek… Ale to wszystko było zbyt ogólne, aby gdziekolwiek nas doprowadzić. Pomyśl ilu elementów nie ma na tym rysunku. Na przykład, w jaki sposób klient zdobywa referencję do czegoś, co działa na zupełnie innym komputerze? Jak faktycznie przebiega komunikacja klienta z komponentem? Jak to się dzieje, że serwer może ingerować w realizację metody komponentu wywoływanej przez klienta? Jednym z fundamentów technologii EJB jest inna technologia Javy — RMI (ang. Remote Method Invocation, wywoływanie zdalnych metod). To fakt, że EJB ukrywa przed programistami komponentów niektóre z bardziej złożonych aspektów RMI, niemniej jednak technologia RMI jest używana i bez jej dokładnego zrozumienia niektóre zagadnienia związane z działaniem EJB nigdy nie ułożą się w logiczną całość. A zatem, porzucimy ogólne rozważania i zajmiemy się poznawaniem szczegółów i tajników technologii EJB, zaczynając od krótkiej lekcji poświęconej RMI. Jeśli jesteś jednym ze szczęśliwców, którzy mieli już okazję dokładnie poznać technologię RMI, to możesz pominąć tę część rozdziału i przejść bezpośrednio do fragmentu, w którym opisujemy sposoby wykorzystania RMI w EJB. Jednak nawet jeśli dobrze znasz RMI, to powinieneś przynajmniej pobieżnie przejrzeć tę część rozdziału, choćby po to, by poznać terminologię i rysunki, których będziemy używać w dalszej części książki. W porządku, wróćmy na chwilę do punktu wyjścia — czego brakuje na poniższym rysunku? Zacznij od miejsc, w których zdarzają się cuda… Klient tu następuje cud Obiekt kli e n ta tu następuje cud Jest jeszcze zbyt wcześnie, by stwierdzić czy tu następuje cud, czy nie, ale można sądzić że następuje… SSeerrwweerr gi u ł s u Obiekt E J B komponent E J B baza danych y w o s e n z b s e f r e t n j i i Wygląd architektury EJB przedstawiony ze śmiesznie wysokiego poziomu jesteś tutaj 87 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 88 Metody zdalne Wywoływanie zdalnej metody Kiedy piszesz klienta, który będzie korzystać z komponentu, może to być klient lokalny bądź zdalny. Klient lokalny to taki, który działa na tej samej wirtualnej maszynie Javy (JVM) co komponent. Innymi słowy, zarówno klient, jak i komponent istnieją na tej samej stercie. Zagadnienia te zostaną bardziej szczegółowo opisane w rozdziale 3., pt. Co widzi klient, jak na razie powinieneś jednak pamiętać, że lokalny oznacza istniejący na tej samej stercie (w tej samej JVM). Jest wysoce prawdopodobne, że klientów lokalnych będziesz używać wyłącznie wraz z komponentami entity bean i tylko w bardzo szczególnych sytuacjach. Jeśli chcesz, by komponent był używany przez program z „dowolnego miejsca świata”, to powinieneś skorzystać z klienta zdalnego. Większość aplikacji korporacyjnych posiada klienty zdalne, nawet jeśli niektóre komponenty używane w tych aplikacjach komunikują się wzajemnie na zasadach klientów lokalnych. (Nim dotrzesz do końca tej książki dokładnie poznasz wszystkie najdrobniejsze szczegóły tych zagadnień.) A zatem, w jaki sposób, obiekt umieszczony na jednej stercie (wykonywany przez jedną JVM) może wywołać jakąś metodę, używając w tym celu referencji do obiektu działającego na innej stercie (wykonywanego przez inną JVM)? Z technicznego punktu widzenia wywołanie takie nie jest możliwe! Referencje w Javie to ciągi bitów, które nic nie znaczą poza konkretną wirtualną maszyną Javy, na której zostały stworzone i są używane. Gdybyś był obiektem i posiadał referencję do innego obiektu, to ten drugi obiekt musiałby się znajdować na tej samej stercie co Ty. Dzięki RMI obiekt klienta zaczyna działać w taki sposób, jak gdyby wywoływał zdalną metodę. Jednak w rzeczywistości wywołuje on jedynie metody obiektu „pośrednika”, działającego na tej samej stercie. Pośrednik obsługuje wszystkie operacje sieciowe niskiego poziomu związane z wykorzystaniem gniazd i strumieni. Technologia RMI rozwiązuje ten problem poprzez udostępnienie klientowi obiektu pośrednika (ang. stub), który obsługuje wymianę informacji pomiędzy klientem i zdalnym obiektem. Klient wywołuje metody pośrednika, a pośrednik obsługuje wszystkie czynności niskiego poziomu związane z komunikacją ze zdalnym obiektem (i bazujące na wykorzystaniu gniazd i strumieni). Pośrednik udaje, że jest zdalnym obiektem, jednak w rzeczywistości jest jedynie pośrednikiem, czyli czymś, co wie jak należy się komunikować ze zdalnym obiektem. SStteerrttaa KKlliieennttaa g e t Porada() g e t Porada() obiekt z d aln y obiekt kl i e a t n Celem klienta jest wywołanie metody zdalnego obiektu (czyli zrobienie czegoś, co w rzeczywistości jest niemożliwe). Jednak ze względu na to, że zdalny obiekt znajduje się na innej stercie, klient wywołuje metodę obiektu pośrednika (który z kolei przesyła odpowiednie informacje siecią). 88 Rozdział 2 SStteerrttaa sseerrwweerraa zdalnypoś r d e nik Obiekt zdalny, to obiekt posiadający faktyczną metodę wykonującą operacje, które klient chce wykonać (na przykład: sprawdzKarteKredytowa(), obliczWartoscPI() i tak dalej.) Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 89 Przegląd architektury Także po stronie serwera jest dodatkowy „pomocnik”… @=O EAJ@OIFKAAJ@ JH EAJ?D?AMOM=A@=EA@OF HA@E=ME KA F ?AEAIEA?EMAIAHMAHA? =IAHMAHAKIEF H=EBH=?AAIJHKEAE=MA ?EMAC E FHAIJ=?E=MOM=EAAJ@O@=AC EAJK?OME ?EA(cid:5)= O KEA ?E@IK# ?O@  IKCEF ?AIEA?EMO?DMI=O@=O EA?EAA@=J=EAHME =EA=FHA?= O F@IJ=MMAE@AE41aJHA=@=EAAIJJ=EAK=JMEAEAMOM=E=AJ@O@=AC EAJK FHAEAJ= O OHMEAFHIJA=MOM=EAAJ@O EAJKEIJEA ?AC=JAI=AIJAH?EA ?EAJ+AAJA?DCEE41AIJ=FAMEAEAFHAH?OIJ ?EFAH=?EIEA?EMO?D1OEIMO B=J#A EAJEAJ=H= EAJ@=O@E== =H#O?DFKJAH=?DFMEEA OFH=MEA EA=KM=#=O@=FHCH=EIJO6MACFKJKME@AE==?=J#EM JMHAE=HJIAC E=JMEAIAC@K )=JAFHOJ=@ABEEM=O?D?A=?DJA?DCE=41 EAHA=IEA EA@FMEA@E= J=#A=  IKC,MOM=E=@=AAJ@OFIJHEAIAHMAH=6? ?FIJHEAIAHMAH=@ EAH=F ?AEA IEA?EMAIE=M,IEAAJK =CIAAJ5EAAJIJ=MEFHA?EMEAIJMF HA@E= 9 F? JMO?DMAHI=?DJA?DCEE41@==#@ACF HA@E=JHA = OIJMHO @FME=@= ?OK EAJIEAAJKA@= A?EAEA=MIAAIJJEA?A?OME ?EA? F IJHEAIAHMAH=KIE=FAME=#EM ?EBK?=A=EE@OIFKAIEAAJA@=JMHAEA I=AC EAJK IEAAJKAIJF?=AEA ,@EAOI?ACMMO= E=JAC=C=@EAE=C@O# MJA ?EAJA?DCEE-*EA=ME,IAC=?AE=5FI M=EJAAHEFAAJKA #EM ?EBK?=AIEAAJK=A#OMO ?EA@AC JMH?M =I ?D@EJOJ#A=IAHMAHAAIJ? ?OF HA@EAIJMIJ=EAIE,KEM=H= #AJ? FJH=BEEJAHFHAJM=FHAIO=AFHAEACKE=JOEMOMOM=@FMEA@EAAJ@O @=AC EAJK Szkielet przyjmuje połączenie sieciowe, które próbuje nawiązać pośrednik, określa co pośrednik chce przekazać (czyli jaką metodę próbuje wywołać), po czym wywołuje odpowiednią metodę zdalnego obiektu. g e t Porada() Sterta Klienta g e t Porada() SStteerrttaa sseerrwweerraa zdalny„poś r e d nik” obiekt kl i e a t n „szkiel e t ” zdalny o bi e k t Z punktu widzenia klienta realizuje on zwyczajne wywołanie metody obiektu znajdującego się na tej samej stercie. Z punktu widzenia obiektu zdalnego obsługuje on zwyczajne wywołanie metody, do której odwołał się obiekt przechowywany na tej samej stercie. jesteś tutaj 89 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 90 Architektura EJB Nie ma niemądrych pytań P. W jaki sposób możliwe jest uzyskanie „przezroczystości operacji sieciowych”? Co się dzieje, gdy serwer zostanie wyłączony lub sieć ulegnie uszkodzeniu w momencie gdy klient wywoła zdalną metodę? Wydaje się, że w tym przypadku istnieje znacznie więcej powodów, które mogą doprowadzić do wystąpienia problemów, niż gdyby obiekt klienta realizował zwyczajne wywołanie metody innego obiektu umieszczonego na tej samej stercie. O. operacji sieciowych” nie jest jedynie mitem — jest złym pomysłem. Oczywiście, że w przypadku wywoływania zdalnej metody może wystąpić WIELE problemów, które nie pojawiają się podczas realizacji zwyczajnych wywołań, a klient musi być na te sytuacje przygotowany. Tak, tak. Bez wątpienia rozumiesz, że „przezroczystość Czy to ja jestem odpowiedzialny za stworzenie P. obiektu pośrednika i szkieletu? Skąd pośrednik wie jakie metody posiada mój zdalny obiekt? Na podobnej zasadzie — skąd klient wie jakie metody udostępnia mój zdalny obiekt? O. szkieletu. W przypadku technologii RMI są one generowane za pomocą kompilatora RMI (rmic). Jeśli chodzi o pozostałe dwa pytania… to nim zaczniemy wyjaśniać, pozwolimy Ci jeszcze pomyśleć chwilkę nad odpowiedziami na nie. Nie, nie musisz tworzyć ani obiektu pośrednika, ani obiektu Wysil szare komórki =EAIJ=AFIOIFI JHO(cid:21)= =IJIM=M=LEA OFHA==EAJME EBH=?A@IJ(cid:28)FO?DAJ@=?D1OE IMOM=EIFI (cid:21)=F==IMA FK E?AAJ@O?=AK ME=JK 2O HA=?EFE(cid:28)@O EAJA F HA@E==B=JO?O@=O EAJA =EAI MIFA?A?DOJHA =JA EAJO KI FIE=@= (Odpowiedzi na te pytania znajdziesz kilka stron dalej.) To właśnie z tego powodu w technologii RMI wszystkie zdalne metody muszą deklarować wyjątek java.rmi.RemoteException, który jest wyjątkiem weryfikowanym. A to oznacza, że klient musi bądź go obsługiwać, bądź zadeklarować. Innymi słowy, klient tak naprawdę nie może udawać, że wywołanie metody jest standardowe, a nie „zdalne”. Ale chwileczkę, to nie wszystko — klient musi wykonać specjalne operacje, żeby w ogóle zdobyć referencję do zdalnego obiektu. A właściwie czym jest ta referencja? Tak naprawdę, jest to zwyczajna referencja do pośrednika zdalnego obiektu. A zatem, należałoby odpowiedzieć, że RMI nie zapewnia prawdziwej przezroczystości operacji sieciowych. Projektanci tej technologii chcą, by klient potwierdził świadomość, że podczas wywoływania zdalnej metody mogą się zdarzyć katastrofalne problemy. Niemniej jednak, przyglądając się wszystkim operacjom, które należy wykonać w celu wywołania zdalnej metody (nawiązaniu połączenia sieciowego, obsłudze strumieni, spakowaniu i przekazaniu argumentów itd.), możemy dojść do wniosku, że klient i tak musi wykonać jedynie dwie proste czynności: użyć specjalnej usługi wyszukiwawczej w celu uzyskania referencji do zdalnego obiektu i umieścić wywołanie zdalnej metody w bloku try-catch.To naprawdę banalne operacje w porównaniu z tym wszystkim, co klient musiałby robić, gdyby samodzielnie chciał obsługiwać cały proces. (A całe zadanie możemy jeszcze bardziej uprościć, stosując wzorzec programowy wykorzystywany w technologii EJB, który poznamy w ostatnim rozdziale.) 90 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 91 A co z argumentami i wartościami wynikowymi? Wywołania zdalnych metod przypominają wywołania metod lokalnych, z tym że mogą zgłaszać wyjątki RemoteException. A jaki byłby pożytek z wywołania metody, gdyby nie można było przekazać do niej żadnych argumentów ani pobrać wartości wynikowej? Równie dobrze mógłbyś używać RPC*, jak Twoi rodzice. I tak doszliśmy do jednego z kluczowych zadań, jakie muszą realizować obiekty pośrednika i szkieletu (czy też cokolwiek, co pełni funkcję szkieletu) — pakowania i rozpakowywania argumentów wywołania przesyłanych siecią. Pamiętaj, że w rzeczywistości klient wywołuje metodę pośrednika, do którego ma lokalny dostęp (co oznacza, że zarówno klient, jak i pośrednik znajdują się na tej samej stercie). Dlatego też, z punktu widzenia klienta przesyłanie argumentów wywołania metody nie ma w sobie nic szczególnego. To pośrednik wykonuje całą „czarną” robotę. Musi on spakować argumenty wywołania (do czego jest wykorzystywany proces określany jako szeregowanie, ang. marshaling), zapisać je w strumieniu wyjściowym, a następnie, za pośrednictwem połączenia sieciowego, przesłać na serwer. Z kolei do zadań szkieletu należy odebranie i przetworzenie danych przesłanych przez pośrednika, rozpakowanie argumentów, określenie co należy z nimi zrobić (na przykład, jaką metodę jakiego obiektu należy wywołać) i wywołanie metody (w tym przypadku jest to wywołanie lokalne) zdalnego obiektu wraz z przekazaniem do niej odpowiednich argumentów. Następnie cały proces jest wykonywany raz jeszcze, tylko w przeciwnym kierunku! Szkielet pakuje wartości wynikowe i przesyła je do pośrednika, który z kolei je rozpakowuje i zwraca klientowi jako zwyczajne wartości. Jednak, aby można było przesłać argumenty i wartości wynikowe, muszą to być wartości typów podstawowych, obiekty implementujące interfejs Serializable, tablice lub kolekcje wartości typów podstawowych lub obiektów implementujących interfejs Serializable bądź też obiekty implementujące interfejs Remote. Przegląd architektury Zarówno pośrednik, jak i szkielet uczestniczą w całym procesie wywoływania zdalnej metody. Oba są odpowiedzialne za pakowanie oraz rozpakowywanie wartości przesyłanych siecią. Cały ten proces nie mógłby działać, gdyby argumenty oraz wartości wynikowe nie nadawały się do przesłania siecią. Wartości, które można przysyłać to:  wartości typów podstawowych,  obiekty implementujące interfejs Serializable,  tablice lub kolekcje wartości typów podstawowych bądź obiektów implementujących interfejs Serializable,  obiekty implementujące interfejs Remote. p o b i erzImie(22) o p b i erzImie(22) p o b ierzImie(22) Klient Serwer „Jan” pośred nik „Jan” szkiel e t „Jan” obiekt z d aln y obiekt kl i e a t n Pośrednik pakuje argumenty i wysyła je wraz z informacjami o wywołaniu metody, a następnie odbiera wyniki, rozpakowuje je i przekazuje klientowi. Szkielet (lub cokolwiek, co po stronie serwera pełni funkcję szkieletu) rozpakowuje argumenty wywoływanej metody obiektu zdalnego, po czym pakuje i wysyła wyniki wywołania. *RPC to skrót od terminu Remote Procedure Call (wywoływanie zdalnych procedur). Ale to nudy… jesteś tutaj 91 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 92 Zdalne przekazywanie obiektów Zaraz, chwileczkę… Przecież Java przekazuje obiekty, przekazując kopię referencji do danego obiektu, a nie sam obiekt. A zatem, jakim cudem coś takiego może działać w przypadku wywołań zdalnych? Przecież taka referencja nie ma najmniejszego znaczenia na innej stercie… W przypadku zwyczajnych, lokalnych wywołań metod Java przekazuje referencje przez wartość. Innymi słowy, kopiuje bity zapisane w zmiennej referencyjnej. Sam obiekt nigdy nie jest przekazywany. Będziemy sobie wyobrażać, że referencja jest pilotem do obiektu znajdującego się na stercie. Pilotem, czyli czymś, czego możemy użyć do naciskania przycisków i sterowania obiektem (czyli, na przykład, do wywoływania jego metod). obiekt Pies azor Pies void doDziela() { Co tak naprawdę tu przekazujemy? Pies azor = new Pies(); this.szkolZwierzaka(azor); } Kopia referencji (pilota), a nie obiekt Pies. void szkolZwierzaka(Pies arg) { } Teraz parametr „arg” oraz zmienna „azor” są identyczne. Obie odwołują się do tego samego obiektu Pies. azor Pies obiekt Pies arg Pies Oczywiście wiemy, że Ty to wszystko wiesz, ale wyjaśniamy to tak na wszelki wypadek, aby mieć pewność, że jesteś „na tej samej stronie co my” (co brzmi nieco dziwnie, bo to przecież oczywiste, że jesteśmy na tej samej stronie), i że rozumiesz ideę. 92 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 93 Co tak naprawdę jest przekazywane, gdy przekazujesz obiekt w wywołaniu zdalnej metody? obiekt Pies KKlliieenntt azor Pies Wyobraź sobie poniższy fragment kodu używanego przez KLIENTA: try { Pies azor = new Pies(); Co tak naprawdę tutaj przekazujemy?? zdalnyPosrednik.szkolZwierzaka(azor); } catch (RemoteException ex) { ex.printStackTrace(); } Oraz ten kod ZDALNEJ metody: void szkolZwierzaka(Pies pies) { } obiekt Pies To NIE jest referencja! To serializowana kopia faktycznego obiektu Pies. Obiekt Pies na serwerze jest kopią obiektu istniejącego po stronie klienta. obiekt Pies KKlliieenntt azor Pies obiekt Pies SSeerrwweerr arg Pies Przegląd architektury Jeśli Twoja zdalna metoda wymaga przekazania argumentu, którego wartość jest obiektem, to argument ten będzie przekazywany jako kompletna kopia obiektu! W przypadku wywołań zdalnych metod, Java przekazuje obiekty kopiując je, a nie w formie referencji. Serializowana kopia obiektu jest przekazywana do obiektu zdalnego. Serializable Pies =I=Pies EFAAJKA EJAHBAISerializable jesteś tutaj 93 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 94 Argumenty zdalnych metod Przekazywanie argumentu będącego obiektem z klienta na serwer B Klient wywołuje metodę szkolZwierzaka(mojPies) obiektu pośrednika, przekazując w nim referencję do obiektu Pies. Klient przekazuje kopię referencji do obiektu Pies znajdującego się na stercie. Istnieje tylko jeden obiekt Pies. szkielet Pies s zkolZwierzaka(mojPies) klient pośrednik c Pośrednik tworzy serializowaną kopię obiektu i przesyła ją siecią do obiektu szkieletu. Pośrednik przesyła serializowany obiekt Pies. Pies szkielet Pies s zkolZwierzaka(mojPies) klient pośrednik 94 Rozdział 2 zdalny obiekt zdalny obiekt Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 95 Rozpakowywanie (deserializacja) obiektu na serwerze d Szkielet przeprowadza deserializację przekazanych argumentów, tworząc tym samym nowy obiekt Pies na stercie zdalnego obiektu. Przegląd architektury Pies klient pośrednik szkielet Pies zdalny obiekt Nowy obiekt Pies jest taki sam jak obiekt znajdujący się po stronie klienta. e Szkielet wywołuje metodę zdalnego obiektu, przekazując w wywołaniu zwyczajną referencję do nowego obiektu Pies. Pies klient pośrednik szkielet szkolZwierzaka(nowyPies) Pies zdalny obiekt W chwili gdy realizowane jest wywołanie metody zdalnego obiektu, obiekt Pies jest już kolejnym, zwyczajnym obiektem na stercie. jesteś tutaj 95 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 96 Argumenty zdalnych metod Nie ma niemądrych pytań P. Mam obiekt HashMap pełny obiektów Klient (implementujących interfejs Serializable), z których każdy ma unikatowy klucz typu String. Czy powinienem martwić się tym, czy sam obiekt HashMap można serializować? O. W porządku, to jedno z serii podchwytliwych pytań. Wszystkie implementacje interfejsu Collection dostępne w J2SE API implementują interfejs Serializable. A zatem, nie musisz przejmować się obiektem HashMap — jeśli obiekty, które w nim umieszczasz implementują interfejs Serializable, to wszystko będzie w porządku. Ale… jest coś, co może doprowadzić do wystąpienia problemów. Prawdopodobnie nigdy się nie znajdziesz w takiej sytuacji, niemniej jednak warto o niej wspomnieć. Zapewne już wiesz, że klasy implementujące interfejs Map, takie jak HashMap oraz Hashtable, dysponują metodą values() zwracająca kolekcję wartości, bez skojarzonych z nimi kluczy. Innymi słowy, możesz wywołać tę metodę swojego obiektu HashMap i uzyskać w rezultacie kolekcję obiektów Klient. Jednak kolekcję jakiego typu? I na tym właśnie polega problem. Nie wiadomo jakiego typu. Wiadomo tylko to, że jest to obiekt implementujący interfejs Collection. Jednak informacja ta nie wystarcza nam, by stwierdzić czy obiekt zwrócony przez wywołanie metody values() może być serializowany! Innymi słowy, może się okazać, że pomimo umieszczenia w kolekcji obiektów implementujących interfejs Serializable, nie można przeprowadzić serializacji samej kolekcji! A oto wniosek: nie polegaj na tym, że kolekcje zwrócone przez metodę values() obiektów implementujących interfejs Map, będzie można serializować. Umieszczaj swoje obiekty w czymś, co na pewno pozwala na serializację, czyli, na przykład, w obiektach ArrayList, a dopiero potem próbuj przesyłać je jako argument wywołania zdalnej metody. P. Jeśli czegoś, co przekazujesz w wywołaniu zdalnej metody nie można serializować, to czy próba wykonania serializacji spowoduje wystąpienie błędu podczas kompilacji, czy też w trakcie działania programu? O. W czasie działania programu! A przynajmniej zazwyczaj tak bywa. Pamiętaj, że zadeklarowany typ argumentu lub wartości wynikowej niekoniecznie odpowiada typowi obiektu, który będzie przekazywany lub zwracany w czasie wykonywania programu. Problemy mogłyby zostać wykryte podczas kompilacji tylko i wyłącznie w przypadku, gdyby zadeklarowanym typem argumentów lub wartości wynikowych był interfejs Serializable: public void wezTo(Serializable s); W takim przypadku kompilator mógłby wykorzystać standardowe mechanizmy kontroli typów, by sprawdzić, czy typ przekazywanego argumentu faktycznie implementuje Serializable. Jednak w większości przypadków Serializable nie jest zadeklarowanym typem argumentów ani wartości wynikowych (są nimi raczej takie typy jak Pies, ArrayList, String itp.); dlatego też Java nie będzie wiedzieć czy przekazywany obiekt można serializować, czy nie, aż do chwili gdy spróbuje to zrobić (a w takiej sytuacji, gdy obiekt nie implementuje interfejsu Serializable, zostanie zgłoszony wyjątek). Czy moje klasy muszą jawnie implementować W przypadku serializacji tablic i kolekcji, jeśli którykolwiek z umieszczonych w nich obiektów nie będzie implementować interfejsu Serializable, to cała operacja serializacji nie powiedzie się. P. interfejs Serializable, czy wystarczy, że będzie on dziedziczony po klasie bazowej? O. obowiązujących w Javie: jeśli Twój rodzic (czyli klasa bazowa) jest czymś, to także Ty jesteś tym czymś. Jeśli klasa Pies dziedziczy po klasie Zwierze, a klasa Zwierze implementuje interfejs Serializable, to także obiekty Pies nadają się do serializacji i to niezależnie do tego czy klasa Pies jawnie implementuje interfejs Serializable, czy nie. Przypomnij sobie jedną z podstawowych zasad Niemniej jednak, jawne deklarowanie, że klasa implementuje interfejs Serializable, nawet jeśli jest on implementowany w klasie bazowej, jest uznawane za dobrą praktykę programistyczną. Dzięki temu inne osoby używające stworzonych przez Ciebie klas nie będą musiały wnikliwie analizować całej ich hierarchii, by sprawdzić czy któraś z klas bazowych implementuje interfejs Serializable. 96 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 97 Przegląd architektury Pamiętaj, że argumenty wywołania oraz wartości wynikowe zwracane przez zdalne metody muszą być:  wartościami typów podstawowych,  obiektami implementującymi interfejs Serializable,  tablicami lub kolekcjami wartości typów podstawowych lub obiektów implementujących interfejs Serializable,  obiektami implementującymi interfejs Remote. Nie rozumiem dlaczego przekazanie obiektu typu Remote w wywołaniu zdalnej metody jest poprawne! No bo przecież, czy cała idea takiego zdalnego obiektu nie polega na tym, że… jest on zdalny? Po co miałbyś przesyłać taki obiekt do klienta? Przecież to nie ma sensu. Za chwilę wszystko się wyjaśni i ułoży w logiczną całość. Jednak zanim odwrócisz kartkę, zastanów się przez chwilę nad implikacjami wynikającymi z faktu przesyłania w wywołaniu zdalnej metody zdalnego obiektu. jesteś tutaj 97 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 98 Argumenty zdalnych metod Przekazywanie obiektu Remote w wywołaniu zdalnej metody Przesyłanie zdalnego obiektu w wywołaniu zdalnej metody nie ma sensu. W końcu taki obiekt istnieje po to, aby być zdalnym. Aby mogły z niego korzystać klienty działające… gdzie indziej. Na innej stercie. Co się jednak stanie, jeśli zechcemy przekazać do zdalnego klienta referencję do innego zdalnego obiektu? Co się stanie, jeśli zamiast normalnej kopii obiektu Klient, przekażemy do niego pośrednika do zdalnego obiektu Klient? Przemyśl to sobie zanim rozpoczniesz lekturę następnej strony. Wysil szare komórki =EAI IKJEFHA==E=F HA@E=@@=AC  EAJKKlient =E=IJMO?=AC EAJKKlient =EAHO ?EMOE= FHA==E=F HA@E= =E=IJMO?=AC EAJKKlient =EAI M=@OJ=EACHME =E= J=J=MO HFE(cid:28)@OFHA=OM=EA IAHE=EM=O?D EAJM=FHA=OM=EA F HA@EM@ EAJM@=O?DAIJK?M @A?O FHAJM 2HA==EKAO C@O=EAO IE(cid:28)=C=@EAE=EME =OE MO@= ?E E MH?=E 98 Rozdział 2 W przypadku przekazywania obiektu typu Remote do lub z wywołania zdalnej metody, Java przekazuje w rzeczywistości pośrednika do tego obiektu. Innymi słowy, podczas działania programu zdalny obiekt pozostaje dokładnie tam, gdzie jest, a zamiast niego przekazywany jest jedynie jego pośrednik. Zdalna referencja to pośrednik do zdalnego obiektu. Jeśli klient dysponuje zdalną referencją, oznacza to, że dysponuje zwyczajną, lokalną referencją do pośrednika, który z kolei jest w stanie komunikować się ze zdalnym obiektem. KKlliieenntt zdalny obiekt Foo pośrednik do zdalnego obiektu SSeerrwweerr zdalny obiekt Foo Obiekt kl i e n a t FFoooo tst lokalna referencja do pośrednika Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 99 Kiedy wartość wynikowa jest zdalnym obiektem… B Klient wywołuje metodę pobierzKlienta() zdalnego obiektu A (korzystając przy tym z pośrednika A). Przegląd architektury r z Klienta() b i e o p pośrednik A klient b i e rzKlienta() o p szkielet p o b ierzKlienta() zdalny obiekt B Klient zdalny obiekt A c Zdalny obiekt A zwraca referencję do obiektu Klient (zdalny obiekt B). Szkielet zastępuje (i serializuje) pośrednika do tego obiektu i przesyła go z powrotem do klienta. Pośrednik klienta (B) zostaje odtworzony (deserializowany) po stronie klienta, po czym klient otrzymuje lokalną referencję do nowego obiektu pośrednika. Obiekt zdalny (A) zwraca lokalną referencję do obiektu Klient (zdalnego obiektu B), jednak z powrotem jest tak naprawdę przesyłany pośrednik. klient pośrednik A lokalna referencja do pośrednika B pośrednik B Teraz klient otrzymuje lokalną referencję do pośrednika do obiektu Klient (B). szkielet zdalny obiekt B Klient zdalny obiekt A zdalny pośrednik B Serializowany pośrednik do zdalnego obiektu B (obiektu Klient). jesteś tutaj 99 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 100 Pytania dotyczące RMI Nie ma Co się stanie, jeśli obiekt klienta oraz obiekt zdalny To nie ma żadnego znaczenia. Liczy się tylko to, czy dwa Zagadnieniem tym zajmiemy się szczegółowo nieco później, niemądrych pytań P. będą działać na różnych JVM, lecz na tym samym komputerze? Innymi słowy, jeśli będą działać w dwóch różnych programach napisanych w Javie i wykonywanych na tym samym serwerze? O. obiekty istnieją na tej samej czy na różnych stertach, a na szczęście dwie wirtualne maszyny Javy nie używają tej samej sterty, niezależnie do tego, jak są sobie bliskie (czyli, bez względu na to czy działają na tym samym serwerze). W praktyce jednak możesz (a w przypadku technologii EJB często musisz) używać RMI, nawet jeśli obiekty znajdują się na tej samej stercie. P. Niby dlaczego miałbyś chcieć używać RMI, jeśli nie jest to konieczne? Czy samo wywoływanie zdalnych metod nie jest wystarczająco kosztowne? O. jednak głównym powodem jest to, iż rezygnacja z wykorzystania RMI do wywoływania metod powoduje ograniczenie aplikacji poprzez utratę możliwości rozmieszczania obiektów w różnych miejscach sieci (lub nawet na tym samym serwerze). Innymi słowy, jeśli nie wykorzystasz RMI, to oba obiekty będą musiały znajdować się na tej samej stercie. Z punktu widzenia modelu programowania rozproszonego jest to decyzja nieodwołalna, gdyż późniejsza zmiana rozwiązania pociągnęłaby za sobą konieczność przepisywania całego kodu. Z drugiej strony, jeśli zastosujesz RMI, to w dowolnej chwili będziesz mógł zdecydować się, aby go podzielić na części i rozmieścić w różnych miejscach swojego systemu, przy czym będzie to wymagało niewielkich, a niejednokrotnie nie będzie wymagało żadnych, zmian w kodzie. A zatem, kosztem uzyskania elastyczności traci się wydajność działania, jednak w przypadku znacznej większości rozproszonych aplikacji korporacyjnych, nie jest to wcale największy problem. Zazwyczaj największy wpływ na wydajność działania aplikacji ma przepustowość sieci oraz możliwości współbieżnej realizacji zadań. Ogólnie rzecz biorąc, to prawdopodobnie inne czynniki będą w większym stopniu oddziaływać na wydajność aplikacji niż to, czy używasz wywołań zdalnych czy lokalnych. Jednak życie nie zawsze jest takie proste, dlatego też powrócimy do tego zagadnienia w dalszej części książki. 100 Rozdział 2 KLUCZOWE ZAGADNIENIA Technologia EJB używa RMI, aby zdalne klienty mogły korzystać z komponentów. W tym kontekście klient zdalny to obiekt wykonywany przez inną wirtualną maszynę Javy, co jednocześnie oznacza, że jest on umieszczony na innej stercie. Zdalny obiekt pozostaje na swojej stercie, natomiast klienty wywołują metody pośrednika tego zdalnego obiektu. Obiekt pośrednika obsługuje wszystkie sieciowe operacje niskiego poziomu związane z komunikacją ze zdalnym obiektem. Kiedy klient chce wywołać metodę zdalnego obiektu, wywołuje tę samą metodę pośrednika. Pośrednik istnieje na tej samej stercie co klient. Z punktu widzenia klienta, wywołanie zdalnej metody jest niemal identyczne z wywołaniem metody lokalnej; jedyna różnica polega na tym, że wywołanie metody zdalnej może zgłosić wyjątek RemoteException (wyjątek weryfikowany). Pośrednik przygotowuje informacje o argumentach wywołania metody i przesyła je do obiektu szkieletu działającego na serwerze. Sam obiekt szkieletu jest wprawdzie opcjonalny, jednak jego zadania muszą zostać wykonane. Nie musimy przejmować się tym kto — lub co — wykona te zadania. Argumenty wywołania zdalnej metody oraz zwracane przez nie wartości muszą być wartościami typów podstawowych, obiektami implementującymi interfejs Serializable, tablicami lub kolekcjami wartości typów podstawowych lub obiektów implementujących interfejs Serializable bądź też obiektami implementującymi interfejs Remote. Jeśli argumenty lub wartości wynikowe będą jakiegokolwiek innego typu, to podczas działania programu zostanie zgłoszony wyjątek. Jeśli wartością argumentu lub wynikiem zwracanym przez metodę będzie obiekt, to zostanie on przesłany jako serializowana kopia, a następnie odtworzony na lokalnej stercie zdalnego obiektu. Jeśli wartością argumentu lub wynikiem metody będzie obiekt typu Remote, to zamiast samego obiektu zostanie przesłany jego pośrednik. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 101 Przegląd architektury O rany! Niemal zapomniałam o najważniejszej sprawie związanej z wywołaniami zdalnych metod! Jeśli to serializowane obiekty są przekazywane jako argumenty lub wartości wynikowe, to koniecznie musisz upewnić się, że plik klasowy dla klasy przekazywanego obiektu jest dostępny na drugim komputerze. Jeśli plik klasowy nie będzie dostępny, to nigdy nie uda się odtworzyć przekazanego obiektu. To dotyczy także klas pośredników. Jeśli klient nie dysponuje plikami klasowymi obiektu pośrednika, to wszystko na nic! jesteś tutaj 101 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 102 Interfejs Remote Jakie wspólne cechy muszą mieć zdalny obiekt i pośrednik? Skąd klient ma wiedzieć, jakie metody może wywoływać? Skąd pośrednik wie, jakimi metodami dysponuje zdalny obiekt? Pamiętaj — skoro pośrednik udaje, że jest zdalnym obiektem, musi mieć te same metody co on. Oczywiście znasz odpowiedź na te pytania. Oczywiście — interfejs. Właśnie w taki sposób klient powinien dowiadywać się o wszystkich metodach dostępnych w środowisku rozproszonym. Taki interfejs nazywamy biznesowym, gdyż zawiera on metody biznesowe, z których chce korzystać klient. Jeśli chodzi o szczegóły techniczne, to interfejs biznesowy zdalnego obiektu powinien (i to jest prawdziwe zaskoczenie) być interfejsem zdalnym. Aby interfejs mógł być uznany za „zdalny”, powinien spełniać trzy poniższe warunki:  dziedziczyć po interfejsie java.rmi.Remote,  każda jego metoda musi deklarować wyjątek java.rmi.RemoteException,  argumenty i wartości wynikowe muszą gwarantować możliwość przesłania (czyli muszą być obiektami Serializable, wartościami typów podstawowych itd.). Wszystko zaczyna się od zdalnego interfejsu . Zarówno zdalny obiekt, jak i pośrednik implementują ten sam interfejs… zawierający metody, które klient chce wywoływać. Zdalny interfejs musi dziedziczyć po interfejsie , a każda jego metoda musi deklarować wyjątek RemoteException java.rmi.Remote . Klasa RemoteException oraz interfejs Remote należą do pakietu java.rmi. import java.rmi.*; Zdalny interfejs MUSI dziedziczyć po interfejsie java.rmi.Remote (który nie deklaruje żadnych metod). public interface KosciDoGry extends Remote { public int rzucKoscmi() throws RemoteException; Wszystkie metody zdalnego interfejsu muszą deklarować wyjątek RemoteException. } 102 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 103 Klient wywołuje metodę biznesową za pośrednictwem zdalnego interfejsu biznesowego Pamiętaj, że z punktu widzenia klienta, wywołuje on metody Prawdziwego Obiektu. Faktycznego zdalnego obiektu. Czyli obiektu udostępniającego metody, które klient chce wywołać. Jedynym czynnikiem, który przypomina klientowi, iż w rzeczywistości nie wywołuje on metod zdalnego obiektu, jest konieczność obsługi wyjątków RemoteException. Przegląd architektury interfejs Remote interfejs KosciDoGry rzucKoscmi() zdalny (biznesowy) interfejs klasa pośrednika KosciDoGryStub KosciDoGryImpl rzucKoscmi() rzucKoscmi() klasa zdalnego obiektu Zarówno klasa KosciDoGryImpl (będąca zdalnym obiektem dysponującym możliwościami funkcjonalnymi związanymi z grą w kości), jak i pośrednik KosciDoGryStub implementują zdalny interfejs KosciDoGry. sstteerrttaa kklliieennttaa sstteerrttaa sseerrwweerraa y r G o D i c s o K klien t pośrednikKo s ciDoGry y r G o D i c s o K KosciDoG r yImpl Klient używa zdalnego interfejsu biznesowego w celu wywoływania metod pośrednika. Zarówno pośrednik, jak i zdalny obiekt implementują ten sam zdalny interfejs. Od tego momentu nie będziemy już pokazywali obiektu szkieletu. Obchodzi nas tylko to, że COŚ na serwerze będzie realizować zadania, które normalnie wykonuje szkielet. jesteś tutaj 103 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 104 Architektura EJB Przygotuj ołówek TToo ććwwiicczzeenniiee jjeesstt zzwwiiąązzaannee zz bbłłęęddeemm,, kkttóórryy pprrooggrraammiiśśccii uużżyywwaajjąąccyy tteecchhnnoollooggiiii EEJJBB ppooppeełłnniiaajjąą nnaajjcczzęęśścciieejj.. DDllaatteeggoo nniiee ppoommiijjaajj ggoo!! Bazując na przedstawionym poniżej schemacie, umieść klasy i interfejsy w odpowiednich prostokątach, reprezentujących odpowiednio klienta i serwer (klasy mogą być używane zarówno po stronie klienta, jak i serwera). Schemat jest uproszczony, zatem nie zostały na nim przedstawione wszystkie elementy aplikacji. Pies sz k o lZ wierzaka(mojPies) klient pośrednik Pies zdalny TrenerPsów TrenerPsowImpl TrenerPsowStub interfejs TrenerPsow klasa klienta Pies 104 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 105 Przegląd architektury Sposób zastosowania RMI w technologii EJB W technologii EJB klient niemal zawsze uzyskuje dostęp do aplikacji korporacyjnej za pomocą referencji (pośrednika) do zdalnego obiektu. Owszem, istnieje możliwość stosowania klientów lokalnych (czyli klientów istniejących na tej samej stercie co komponent, które nie używają RMI do wywoływania metod biznesowych), a w niektórych sytuacjach jest to nawet konieczne. Jednak dotyczy to nieznacznej liczby bardzo szczególnych sytuacji. A zatem, w przeważającej większości przypadków RMI stanowi podstawę komunikacji pomiędzy klientem i komponentem. Jednak, jak miałeś okazję przekonać się w pierwszym rozdziale, architektura EJB jest nieco bardziej skomplikowana niż prosty schemat komunikacji „klient-pośrednik-obiekt zdalny”. W technologii EJB komponent, czyli to coś, co posiada metody biznesowe, które chcemy wywołać, nie jest obiektem zdalnym! Standardowe zastosowanie technologii RMI tu jest zaimplementowana logika biznesowa! KKlliieenntt Klient i y w o s e n z b s j e f r e t n i pośrednik Zastosowanie technologii RMI w EJB KKlliieenntt Klient i y w o s e n z b s j e f r e t n i pośrednik i y w o s e n z b s j e f r e t n i i y w o s e n z b s j e f r e t n i sseerrwweerr zdalny obiekt sterta baza danych zdalny obiekt obiekt E J B i g u ł s u sterta tu jest zaimplementowana logika biznesowa! sseerrwweerr komponen t E J B baza danych jesteś tutaj 105 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 106 Obiekt EJB Zdalny obiekt — EJBObject — nie jest komponentem, to strażnik komponentu Pamiętaj, że w technologii EJB zdalny obiekt (EJBObject) pełni funkcję „strażnika” komponentu. Sam komponent trzyma się z tyłu i jest zabezpieczony przed wszystkimi bezpośrednimi odwołaniami ze strony klientów, natomiast to obiekt typu EJBObject implementuje zdalny interfejs i przyjmuje wywołania metod. Kiedy wywołanie dotrze do obiektu EJBObject, ingeruje w nie serwer, dodając wszelkie usługi, takie jak: bezpieczeństwo (czy klient ma prawo wywoływać metodę?), transakcje (czy to wywołanie jest elementem istniejącej transakcji, czy też należy rozpocząć nową), czy też trwałość (czy przed wykonaniem metody komponent powinien pobrać jakieś informacje z bazy danych?). Obiekt EJBObject implementuje zdalny interfejs biznesowy, a zatem wywołania zgłaszane przez klienta trafiają właśnie do tego obiektu. Jednak to sam komponent implementuje właściwą logikę biznesową, choć z technicznego punktu widzenia nie jest komponentem „zdalnym”, gdyż nie implementuje interfejsu Remote. Nikt nie będzie rozmawiać z komponentem bez wcześniejszego uzgodnienia tego ze mną. Zarówno zdalny obiekt, jak i pośrednik implementują ten sam interfejs — interfejs biznesowy (nazywany także interfejsem komponentu) — lecz nie dysponują faktyczną logiką biznesową. Z kolei klasa komponentu NIE implementuje interfejsu biznesowego (oczywiście jedynie z formalnego punktu widzenia), lecz dysponuje możliwościami funkcjonalnymi realizującymi faktyczną logikę biznesową. Zarówno pośrednik, jak i zdalny obiekt implementują ten sam interfejs, lecz nie dysponują implementacją FAKTYCZNEJ logiki biznesowej. Komponent nie implementuje zdalnego interfejsu (czyli interfejsu biznesowego)! (Jednak IMPLEMENTUJE logikę biznesową.) sseerrwweerrEEJJBB pośrednik i y w o s e n z b s j e f r e t n i i y w o s e n z b s j e f r e t n i zdalny obiekt obiekt E J B i g u ł s u sterta komponen t E J B baza danych KKlliieenntt Klient 106 Rozdział 2 Head_First EJB_rozdz02-got1.qxd 05-08-15 18:00 Page 107 Przegląd architektury Interfejs komponentu W technologii EJB interfejs biznesowy jest nazywany interfejsem komponentu. To właśnie on informuje klienta o dostępnych metodach biznesowych. Podstawowa różnica pomiędzy interfejsem RMI oraz zdalnym interfejsem komponentu polega na tym, że w EJB dziedziczymy po interfejsie javax.ejb.EJBObject, a nie po interfejsie java.rmi.Remote Kluczowe zagadnienia: B =(cid:21)@OEJAHBAIJHAC@HAM@EA@E?AE= =MEAH=EJAHBAIjava.rmi.Remote(cid:21)A O EJAHBAIA@=O c 1JAHBAIEJBObject @EA@E?OFEJAHBAIEARemote ==JAEJBObject AIJEJAHBAIA@=O d 6M@=OEJAHBAIFAJKKIE@EA@E?O FEJAHBAIEAEJBObject. (cid:3)AI IJMHO=OEJAHBAIFAJK E M J=EFHOF=@K=I=@OFIJ(cid:28)FM=E=I EA? EA=EAOIE(cid:28)JOFHOF=@EAMH@E=A! FJ+ME@EEAJ e 7@IJ(cid:28)FE=AAJ@O EAIMAFHAAJKAI EAJME=F? EJAHBAIKFAJK f 1JAHBAIEJBObject K@IJ(cid:28)FE=J=(cid:21)AEAAJ@O  JHO?D(cid:21)AHOIJ=EAJ =FHAAJKAOAM@=IA?(cid:28) ?EIE (cid:21)E interfejs Remote Wszystkie zdalne interfejsy muszą dziedziczyć po interfejsie java.rmi.Remote. interfejs EJBObject kilka metod W RMI interfejs java.rmi.Remote jest dziedziczony bezpośrednio. Natomiast w technologii EJB Twój interfejs powinien dziedziczyć po interfejsie EJBObject, który z kolei dziedziczy po interfejsie Remote. interfejs Koszyk dodajKsiazke() usunKsiazke() pokazKsiazkiWKoszyku() zaplac() Twój interfejs komponentu dziedziczy po interfejsie EJBObject. To właśnie w tym interfejsie umieszczasz swoje metody biznesowe. To
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Head First EJB. Edycja polska (Rusz głową!)
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ą: