Head First EJB. Edycja polska

Wydawnictwo Helionul. Chopina 644-100 Gliwicetel. (32)230-98-63e-mail: [email protected]

PRZYK£ADOWY ROZDZIA£PRZYK£ADOWY ROZDZIA£

IDZ DOIDZ DO

ZAMÓW DRUKOWANY KATALOGZAMÓW DRUKOWANY KATALOG

KATALOG KSI¥¯EKKATALOG KSI¥¯EK

TWÓJ KOSZYKTWÓJ KOSZYK

CENNIK I INFORMACJECENNIK I INFORMACJE

ZAMÓW INFORMACJEO NOWOŒCIACH

ZAMÓW INFORMACJEO NOWOŒCIACH

ZAMÓW CENNIKZAMÓW CENNIK

CZYTELNIACZYTELNIAFRAGMENTY KSI¥¯EK ONLINEFRAGMENTY KSI¥¯EK ONLINE

SPIS TREŒCISPIS TREŒCI

DODAJ DO KOSZYKADODAJ DO KOSZYKA

KATALOG ONLINEKATALOG ONLINE

Head First EJB.Edycja polska

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 wierszyi 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:

• Architektura aplikacji EJB• Typy komponentów• Tworzenie i stosowanie komponentów session bean oraz entity bean• Powi¹zania pomiêdzy komponentami• Po³¹czenia z baz¹ danych• Komunikaty• Obs³uga wyj¹tków w komponentach• Tworzenie mechanizmów autoryzacji• Wdra¿anie aplikacji EJB

Przekonaj siê, ¿e nawet przy poznawaniu skomplikowanych technologii mo¿na siê œwietnie bawiæ.

Autorzy: Kathy Sierra, Bert BatesT³umaczenie: Rafa³ Joñca, Piotr RajcaISBN: 83-7361-548-2Tytu³ orygina³u: Head First EJBFormat: 200×234, stron: 720

http://helion.pl/view/2547w



http://helion.pl/add/2547w/hfejb




mailto:[email protected]

http://helion.pl/view/2547w/hfejb.htm

http://www.amazon.com/exec/obidos/ASIN/0596005717/eboinf-20

Spis treści (podsumowanie)Wprowadzenie 16

1. Zapraszamy do EJB: wprowadzenie 252. Architektura EJB: omówienie architektury 853. Ujawnianie się: z punktu widzenia klienta 1354. Być komponentem session bean: cykl istnienia komponentów session bean 1975. Encje są trwałe: informacje podstawowe o komponentach entity bean 2836. Być komponentem entity bean: synchronizacja komponentu i encji 3197. Kiedy komponenty są ze sobą powiązane: relacje komponentów entity bean 3978. Odbieranie komunikatu: komponenty message-driven bean 4619. Wiek niepodzielności: transakcje EJB 493

10. Gdy coś się przytrafia komponentom: wyjątki w EJB 54911. Chroń swoje tajemnice: bezpieczeństwo w EJB 59312. Radość wdrażania: środowisko komponentów 623A Ostateczny egzamin próbny 661

Skorowidz 707

Spis treści (szczegółowy)Wprowadzenie

��

��

�� !�"# � ��

�� $�� !��%��%�� &�� '��&(�

�� '' � �� ) �*��

��' �� ' �� '�� '��+,-.

Po co została napisana ta książka? 14

Wiemy, co sobie myśli Twój mózg 15

Metapoznanie 17

Zmuś swój mózg do posłuszeństwa 19

Czego będziesz potrzebować podczas lektury tej książki 20

Zdajemy egzamin certyfikujący 22

Podziękowania 24

5

W

Head_First EJB_rozdz00-got1.qxd 05-08-15 08:45 Page 5

Zapraszamy do EJBKomponenty Enterprise JavaBean są łatwe. /��

� ��

�� '��

��% �� '��%��

+,-�� 0��1�� ' ��

�� %��+,-�� &�� %��%��

2�� '� 3�� +,-

Cele 26

O co chodzi w technologii EJB? 27

Żadnych rozwiązań zależnych od dostawcy! 29

Jak to wszystko działa? 31

Za kulisami… 32

Trzy rodzaje komponentów 35

Komponent Doradcy 39

Pięć czynności niezbędnych do stworzenia komponentu 40

Zadania i obowiązki EJB 50

Poradnik 52

Bar kawowy 83

Architektura EJBTechnologia EJB jest związana z infrastrukturą. 4�� &� � � ��

�� %��'�� '��%��

*�� &�� &��$��

5��6��7 �� 1��&��

� � ��+80 �0 �� %� ��&��

��

�� 9

Cele 86

Wywoływanie zdalnej metody 88

A co z argumentami i wartościami wynikowymi? 91

Klient wywołuje metodę biznesową za pośrednictwem zdalnego interfejsu biznesowego 103

EJB wykorzystuje technologię RMI 105

Zdalny obiekt nie jest komponentem — to strażnik komponentu 106

Przegląd architektury — komponenty session bean 122

Przegląd architektury — komponenty entity bean 123

Przegląd architektury — tworzenie stanowego komponentu session bean 124

Przegląd architektury — tworzenie bezstanowego komponentu session bean 125

Przegląd architektury — komponenty message-drive bean 130

Zorganizuj swoje komponenty 132

6

1

2��

��

��

SSeerrwweerr

inte

rfej

s bi

znes

owy

usłu

gi

logikabiznesowaoddzielonaod danych

to TY piszesztę klasę

(klasa komponentu)

to TY piszeszten interfejs

(interfejs zdalnegokomponentu)

<<interfejs>>Remote

brak metod

<<interfejs>>EJBObject

kilka metod

<<interfejs>>KoszykZKsiazkami

dodajKsiazke()usunKsiazke()pokazKsiazkiWKoszyku()zaplac()

<<interfejs>>EnterpriseBean

brak metod

<<interfejs>>SesionBean

kilka metod

KOSZYKBEAN


inne metody


Ujawnianie sięSwoich komponentów nie możesz zachować tylko dla siebie. 4� ��&��

�� &��%�� 20 ��

�� 3�0��Komponent Doradca�� getPorada() ��%��&�&�� $ ��

��&� �� &� �� , ��

� �� &�� &��

/��' �� $ ��Doradca � �� $ �� EJBObject��

�� : ��%�� &�� : ��

��&�� $ ��

Cele 136

Czego tak naprawdę chce klient 137

Czym jest JNDI? 140

PortableRemoteObject.narrow() (egzotyczne rzutowanie) 145

Tworzenie interfejsu bazowego dla komponentu session bean 149

Na szczęście mamy uchwyty 163

Jakie metody nadają się do umieszczenia w lokalnym interfejsie klienta? 172

Dlaczego jest tak dużo metod remove() 175

Porównanie interfejsu zdalnego i lokalnego 178

Argumenty metod zdalnych i lokalnych 187

Bar kawowy 192

Być komponentem session beanKomponenty session bean są tworzone i usuwane. , ��

�� 7�� '��

� �� '� �� %�� 7&��

'&�� %�� ' � ��

�� *� ��'�� ;�-��

��'�� &'��

��'��%��

Cele 198

Metody zwrotne kontenera, dla szczególnych chwil w życiu komponentu 205

Tworzenie komponentu 212

Czynności komponentów jakie można wykonywać w metodach biznesowych 223

Dezaktywacja: szansa na zapewnienie skalowalności dla komponentów stanowych 224

Usuwanie komponentu 232

Tworzenie komponentu session bean: Twoje zadanie jako Dostawcy Komponentów 254

SessionContext: to Ty bardziej potrzebujesz kontekstu niż on Ciebie 264

Bar kawowy 268

�� %��

�� %��

�� isIdentical()

��

��'��%��

7

3

4

Wszystkie tekomponenty sąidentyczne!

Obiekt bazowy

Komponent bezstanowy

komponent

komponent

komponent

To dla mnie? To jest takwyjątkowa chwila! Jedenjedyny raz w życiu…


Encje są trwałe� �� 4�� &

4�� & �7��&�� &��

�$��%��&��%�� 2��(�� ' ��

� ��'�� $��

��%��&� �� %��% 3�, ��

�� Klient�� ' �� ,��4��

<=�>?@A�� =��:�� >BC �� &�

��$�� &� � �� 4�� &��

�� '��

Cele 284

Czym jest komponent entity bean 285

Komponenty entity bean z punktu widzenia klienta 289

Bardzo prosty komponent entity bean Klient 292

Zdalny interfejs komponentu dla komponentu entity bean 294

Interfejs zdalnego obiektu bazowego komponentu entity bean 297

Czego klient oczekuje od interfejsu obiektu bazowego komponentu entity bean 298

Z pomocą spieszą metody biznesowe interfejsu obiektu bazowego 302

Metoda create() komponentu session bean a metoda create()komponentu entity bean 305

Metoda remove() komponentu session bean a metoda remove()komponentu entity bean 306

Usunięcie encji, komponentu, egzemplarza komponentu 309

Bar kawowy 312

Być komponentem entity beanKomponenty entity bean są aktorami. D�� &�� &��&(��

�&(�� 4�� 2 ��%��&��

��%3 �4 �� &��

��%�� &� ��& ��(�� $�

�� ,��E��%��

��'�� %9��

��

Cele 320

Prawdziwą potęgą komponentów entity bean jest synchronizacja 322

Porównanie trwałości zapewnianej przez kontener oraz przez komponent 327

Interfejs EntityBean udostępnia nowe metody zwrotne kontenera 334

Tworzenie komponentu entity bean CMP 337

Tożsamość obiektu: klucz główny 356

Metody wyszukiwawcze 363

Metody biznesowe interfejsu bazowego 369

Bar kawowy 386

8

5

6

Jeśli masz jakieśostatnie życzenie, to lepiejwypowiedz je w metodzie

ejbRemove()…

Och nie! Proszę,nie! Dam Ci cokolwiek

zechcesz, tylko nie wywołujmetody remove()!

Jeśli jestemkomponentem, mówię metodzie:

„Nie wywołuj moich metod,wywołuj metody mojego strażnika,

oto jego namiary…”

komponent

Zamiast:

zrobCos(this);

Użyj:

zrobCos(mojKontekst.getEJBObject());

obiekt EJBObject


Kiedy komponenty są ze sobą powiązaneKomponenty entity bean potrzebują relacji. Zamówienie �� Klienta

ElementZamówienia �� Zamówienia �Zamówienie ��

ElementuZamówienia �/�� &��

� �� &��

�� ElementZamówienia ��

� Zamówieniem.�, ��Klienta �� Zamówień�

��ElementZamówienia �, �� '��&�

��+,-FG#��' ��

Cele 398

Relacje 402

Liczność 404

Pola CMP oraz CMR 407

Kaskadowe operacje usuwania mogą propagować 417

EJB-QL dla komponentu FilmBean 426

Klauzule SELECT oraz FROM są obowiązkowe 433

Klauzula WHERE 435

Kolekcje nie szczekaj()ą! 438

Wyrażenia BETWEEN, IN, IS EMPTY oraz LIKE 440

Przypisania relacji 445

Bar kawowy 449

Odbieranie komunikatuOdbieranie komunikatów to świetna zabawa. :�' ��

�� &�H�� &��7��$ ��I��

�� -�� (��

' �� '��

��

�� , ��

�� ' ��

Cele 462

Tworzenie komponentu message-driven bean: Twoje zadania jako Dostawcy Komponentów 471

Kompletny deskryptor komponentu message-driven bean 472

Tematy i kolejki 474

MessageDrivedContext 479

Potwierdzenie komunikatu 482

Bar kawowy 487

Moje życie jestsmutne. Nie mam domu, nie mamklientów… a swojego kontekstu

mogę używać WYŁĄCZNIE do obsługitransakcji… Przynajmniej

należę do puli…

<<interfejs>>

EJBContex

getCallerPrincipal()getEJBHome()isCallerInRole(String s)getRollbackOnly()getEJBLocalHome getUserTransactiongetRollbackOnly()

<<interfejs>>

MessageDrivenContex

// ten interfejs nie dodajeżadnych nowych metod

9

7

8

Mnogość:wiele

Liczność:jeden

Film

Rezyser getRezyser()

Rezyser

Collection getFilmy()

10..*

Z konkretnym komponentem Film może być

skojarzony tylko jeden Rezyser, le

cz

z komponentem Rezyser może być skojarzonych

więcej komponentów Film.


Wiek niepodzielnościTransakcje strzegą Twojego bezpieczeństwa. =��' ��

�� &�� &��' ��

�� ' ��

� ��

�� +,-��&��J��'��'��

� ��

�� (��;�H�� ! �

��&��

Cele 494

Test ACID 496

Transakcje w EJB 498

Pewne transakcje nie są propagowane 499

W jaki sposób utworzyć transakcję? 500

Metoda setRollbackOnly() istnieje w DWÓCH interfejsach? 511

Komponent BMT może się okazać bardzo ZŁYM pomysłem. BMT utrudnia wielokrotne użycie komponentu 514

Transakcje zarządzane przez kontener (CMT) 515

Jak działają atrybuty? 516

Oto metody, dla których MUSISZ określić atrybut (dla komponentu CMT) 522

„Nieokreślony kontekst transakcji” 523

Przykład deskryptora dla komponentu CMT 527

„Szczególne momenty” interfejsu SessionSynchronization 536

Bar kawowy 540

Gdy coś się przytrafia komponentomOczekuj nieoczekiwanego. 0 �� '� ��%��1��' ��

�� ;�:��

�� 0 ��' ��

�� ' �� &� � ��

�� 0 ��' �� ' ��&

�� :�� '��

��

Cele 550

W EJB wyjątki dzielimy na dwa rodzaje: systemowe i programowe 556

W przypadku wyjątku programowego, kontener… 557

W przypadku wyjątku systemowego, kontener… 558

Wyjątek RemoteException wędruje do zdalnych klientów,a wyjątek EJBException do lokalnych klientów 563

Obowiązki dostawcy komponentu 565

Pięć standardowych wyjątków programowych EJB 572

Typowe wyjątki systemowe 575

Bar kawowy 587

10 wstęp

9

10

Komponenty CMT transakcji nie znająa komponenty BMT własnych używają.

W porządku, sami wiemy, że ten wierszyk nie jestnajlepszy. 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.

Zapamiętaj

Obowiązkowyznaczy

istniejąca

zwracainterfejs

komponentu

kup tę

książkę

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ątkiprogramowe… Mogę wyjść

z trudnej sytuacji, jeśliprzekażę w wywołaniu metody

create() argumentyo różnych wartościach…


Chroń swoje tajemniceStrzeż swoich tajemnic. - �� 1��&' ��

�� &��'��

�� ' �� %��+,-��'��

� �� 1��'��

�� %�� , ��

� �� 9�� Dostawcą Komponentów ��Twórcą Aplikacji�

�� &�� '��;

Cele 594

W jaki sposób określić zasady bezpieczeństwa w EJB 597

Zadanie konstruktora aplikacji: sterowanie dostępem 598

Definiowanie uprawnień do wykonywania metod 602

Zadania wdrożeniowca: przypisanie konkretnych osób do abstrakcyjnych ról 607

Bezpieczeństwo na poziomie klasy a bezpieczeństwo na poziomie egzemplarza 610

Wykorzystanie bezpieczeństwa programistycznego do „uszycia metodyskrojonej na miarę” własnych potrzeb 611

Użyj elementu <run-as>, aby udawać, iż ktoś inny wywołał metodę 615

Propagacja kontekstu bezpieczeństwa przy użyciu <run-as> 616

Bar kawowy 617

Radość wdrażaniaCiężko pracowałeś nad stworzeniem tego komponentu. 4��

�� %�� "�� &��&

�%�� $�� '��

' �� $��'�� *��

�� (�� .�� %��+,-��

��

�� '��%��

#��

Cele 624

Szczególne miejsce dla komponentów — java:comp/env 626

Wszystko jest tylko podkontekstem 633

Obowiązki dostawcy komponentów i konstruktora aplikacji 641

Obowiązki wdrożeniowca 642

Zapamiętaj kto jest za co odpowiedzialny 643

Jaki interfejs programistyczny zapewnia EJB 2.0 645

Co MUSI się znaleźć w pliku ejb-jar? 648

Ograniczenia programowe 649

Bar kawowy 651

11

11

12

W deskryptorzewdrożenia EJB

W sposóbcharakterystyczny dladostawcy

W sposóbcharakterystycznydla firmy

uużżyyttkkoowwnniiccyy ii ggrruuppyy RRzzeecczzyywwiissttee oossoobbyy<<sseeccuurriittyy--rroollee--rreeff>> <<sseeccuurriittyy--rroollee>>

META-INFcom

headfirst

SSŁŁÓÓJJ11

ejb-jar

ejb-jar.xml

DoradcaHome.classDoradcaBean.class

Doradca.class


Ostateczny Próbny Egzamin Baru Kawowego. To jest to. 70 pytań. Forma, zagadnieniai poziom trudności jest niemal taki sam jak na prawdziwym egzaminie. My to wiemy.

Ostateczny egzamin próbny 661

Skorowidz 707

12

Bar Bar kakawwoowywyA

S


Technologia EJB jest związana z infrastrukturą. Komponenty są elementamikonstrukcyjnymi. 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. Niemniejjednak 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?

85to jest nowy rozdział

Rozdział 2. Przegląd architektury

Architektura EJB

Ten widok zapiera dechw piersiach.

Ale nie można w nieskończonośćpozostawać na tym

poziomie…


Celem niniejszego rozdziału jest przekazanie Ci podstawowych informacjizwiązanych z technologią EJB, a nie udzielenie wyjaśnień dotyczących konkretnychcelów egzaminacyjnych. Niemniej jednak, równie dobrze mógłbyś stwierdzić,że każdy cel i każda odpowiedź udzielana na pytania egzaminacyjne zależą odznajomości i zrozumienia tych zagadnień podstawowych.

Nie przejmuj się jednak, wystarczająco dużo celów egzaminacyjnych znajdzieszw 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 żadnychcelów. Będziesz jeszcze tęsknić za tym rozdziałem, więc delektuj się jego lekturąpóki jeszcze możesz.

86 Rozdział 2

Brak celów

Informacje podstawowe

Cele


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 bardziejzłożonych aspektów RMI, niemniej jednak technologia RMI jest używana i bez jej dokładnego zrozumienia niektórezagadnienia 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ładniepoznać technologię RMI, to możesz pominąć tę część rozdziału i przejść bezpośrednio do fragmentu, w którymopisujemy sposoby wykorzystania RMI w EJB. Jednak nawet jeśli dobrze znasz RMI, to powinieneś przynajmniejpobież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…

87jesteś tutaj��

Przegląd architektury

Obiekt klienta

KlientSSeerrwweerr

bazadanych

Obiekt EJBkomponent EJB

usłu

gi

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…

Wygląd architektury EJB przedstawiony ze śmiesznie wysokiego poziomu

tu następuje cud

inte

rfej

s bi

znes

owy


Wywoływanie zdalnej metody

Kiedy piszesz klienta, który będzie korzystać z komponentu, może to być klientlokalny bądź zdalny. Klient lokalny to taki, który działa na tej samej wirtualnejmaszynie Javy (JVM) co komponent. Innymi słowy, zarówno klient, jak i komponentistnieją na tej samej stercie. Zagadnienia te zostaną bardziej szczegółowo opisanew 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 wysoceprawdopodobne, że klientów lokalnych będziesz używać wyłącznie wrazz 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 korporacyjnychposiada klienty zdalne, nawet jeśli niektóre komponenty używane w tych aplikacjachkomunikują się wzajemnie na zasadach klientów lokalnych. (Nim dotrzesz do końca tejksiążki dokładnie poznasz wszystkie najdrobniejsze szczegóły tych zagadnień.)

A zatem, w jaki sposób, obiekt umieszczony na jednej stercie (wykonywany przezjedną JVM) może wywołać jakąś metodę, używając w tym celu referencji do obiektudziałającego na innej stercie (wykonywanego przez inną JVM)? Z technicznegopunktu 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łystworzone i są używane. Gdybyś był obiektem i posiadał referencję do innegoobiektu, to ten drugi obiekt musiałby się znajdować na tej samej stercie co Ty.

Technologia RMI rozwiązuje ten problem poprzez udostępnienie klientowi obiektupośrednika (ang. stub), który obsługuje wymianę informacji pomiędzy klientemi zdalnym obiektem. Klient wywołuje metody pośrednika, a pośrednik obsługujewszystkie czynności niskiego poziomu związane z komunikacją ze zdalnym obiektem(i bazujące na wykorzystaniu gniazd i strumieni).

88 Rozdział 2

Metody zdalne

Dzięki RMI obiekt klientazaczyna działać w takisposób, jak gdybywywoływał zdalną metodę.Jednak w rzeczywistościwywołuje on jedyniemetody obiektu„pośrednika”, działającegona tej samej stercie.Pośrednik obsługujewszystkie operacjesieciowe niskiego poziomu związanez wykorzystaniem gniazdi strumieni.

SStteerrttaa KKlliieennttaa

SStteerrttaa sseerrwweerraa

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.

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ę nainnej stercie, klient wywołuje metodę obiektu pośrednika(który z kolei przesyła odpowiednie informacje siecią).

Obiekt zdalny, to obiekt posiadający faktycznąmetodę wykonującą operacje, które klient chcewykonać (na przykład: sprawdzKarteKredytowa(),obliczWartoscPI() i tak dalej.)

obiekt klienta

obiekt zdalny

zdalny pośrednik

getPorada()

getPorada()


Także po stronie serwera jest dodatkowy „pomocnik”…

��

�� !�

�� !�� "�� #��

��!��$��

�� %&'�(�� !��

�� !��

�� )�� !�%&'�� '��

�� #�� #��

��#��!�� *��!�� #�� !�

�� !��

+�� !��%&'�� #��

��!,�� *��

��,�� -��!��.��/�� $� ��

0 �� !�%&'��#��!��

�� "��

� ��#��

��!�� 1��,��!�� !��!��!��#

�� !�2�3��,��!��/��

��#�� #��!� ��

1�� #�� ,��

#�� !��

��!��



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.

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 onzwyczajne wywołanie metody, do której odwołał sięobiekt przechowywany na tej samej stercie.

Sterta KlientaSStteerrttaa sseerrwweerraa

obiekt klienta

zdalny „pośrednik”zdalny obiekt

getPorada()

getPorada()

„szkielet”


��

��

��

� ��

�!�� !�"��!�

#��"��

��"�� $

��%��

�!� %��

P. W jaki sposób możliwe jest uzyskanie„przezroczystości operacji sieciowych”? Co się dzieje, gdyserwer zostanie wyłączony lub sieć ulegnie uszkodzeniuw momencie gdy klient wywoła zdalną metodę? Wydajesię, ż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łaniemetody innego obiektu umieszczonego na tej samej stercie.

O. Tak, tak. Bez wątpienia rozumiesz, że „przezroczystośćoperacji sieciowych” nie jest jedynie mitem — jest złym pomysłem.Oczywiście, że w przypadku wywoływania zdalnej metody możewystąpić WIELE problemów, które nie pojawiają się podczas realizacjizwyczajnych wywołań, a klient musi być na te sytuacjeprzygotowany.

To właśnie z tego powodu w technologii RMI wszystkie zdalnemetody muszą deklarować wyjątekjava.rmi.RemoteException, który jest wyjątkiemweryfikowanym. A to oznacza, że klient musi bądź go obsługiwać,bądź zadeklarować. Innymi słowy, klient tak naprawdę nie możeudawać, że wywołanie metody jest standardowe, a nie „zdalne”.

Ale chwileczkę, to nie wszystko — klient musi wykonać specjalneoperacje, żeby w ogóle zdobyć referencję do zdalnego obiektu.A właściwie czym jest ta referencja? Tak naprawdę, jest to zwyczajnareferencja do pośrednika zdalnego obiektu.

A zatem, należałoby odpowiedzieć, że RMI nie zapewnia prawdziwejprzezroczystości operacji sieciowych. Projektanci tej technologii chcą,by klient potwierdził świadomość, że podczas wywoływania zdalnejmetody mogą się zdarzyć katastrofalne problemy.

Niemniej jednak, przyglądając się wszystkim operacjom, które należywykonać w celu wywołania zdalnej metody (nawiązaniu połączeniasieciowego, obsłudze strumieni, spakowaniu i przekazaniuargumentów itd.), możemy dojść do wniosku, że klient i tak musiwykonać jedynie dwie proste czynności: użyć specjalnej usługiwyszukiwawczej w celu uzyskania referencji do zdalnego obiektui umieścić wywołanie zdalnej metody w bloku try-catch. Tonaprawdę banalne operacje w porównaniu z tym wszystkim, co klientmusiałby robić, gdyby samodzielnie chciał obsługiwać cały proces.

(A całe zadanie możemy jeszcze bardziej uprościć, stosując wzorzecprogramowy wykorzystywany w technologii EJB, który poznamyw ostatnim rozdziale.)

90 Rozdział 2

Architektura EJB

Nie ma niemądrych pytań

Wysil szare komórki

P. Czy to ja jestem odpowiedzialny za stworzenieobiektu pośrednika i szkieletu? Skąd pośrednik wie jakiemetody posiada mój zdalny obiekt? Na podobnej zasadzie —skąd klient wie jakie metody udostępnia mój zdalny obiekt?

O. Nie, nie musisz tworzyć ani obiektu pośrednika, ani obiektuszkieletu. W przypadku technologii RMI są one generowane zapomocą kompilatora RMI (rmic). Jeśli chodzi o pozostałe dwapytania… to nim zaczniemy wyjaśniać, pozwolimy Ci jeszczepomyśleć chwilkę nad odpowiedziami na nie.

(Odpowiedzi na te pytania znajdziesz kilka stron dalej.)


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łaniametody, 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ć obiektypośrednika i szkieletu (czy też cokolwiek, co pełni funkcję szkieletu) — pakowaniai rozpakowywania argumentów wywołania przesyłanych siecią.

Pamiętaj, że w rzeczywistości klient wywołuje metodę pośrednika, do którego malokalny dostęp (co oznacza, że zarówno klient, jak i pośrednik znajdują się na tejsamej stercie). Dlatego też, z punktu widzenia klienta przesyłanie argumentówwywołania metody nie ma w sobie nic szczególnego. To pośrednik wykonuje całą„czarną” robotę. Musi on spakować argumenty wywołania (do czego jestwykorzystywany proces określany jako szeregowanie, ang. marshaling), zapisać jew 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łanychprzez 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 wrazz 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 jerozpakowuje i zwraca klientowi jako zwyczajne wartości. Jednak, aby można byłoprzesłać argumenty i wartości wynikowe, muszą to być wartości typówpodstawowych, obiekty implementujące interfejs Serializable, tablice lubkolekcje wartości typów podstawowych lub obiektów implementujących interfejsSerializable bądź też obiekty implementujące interfejs Remote.



Zarówno pośrednik, jaki szkielet uczestniczą w całymprocesie wywoływania zdalnejmetody. Oba sąodpowiedzialne za pakowanieoraz rozpakowywaniewartości przesyłanych siecią.

Cały ten proces nie mógłbydziałać, gdyby argumentyoraz wartości wynikowe nienadawały się do przesłaniasiecią.

Wartości, które możnaprzysyłać to:

� wartości typówpodstawowych,

� obiekty implementująceinterfejs Serializable,

� tablice lub kolekcjewartości typówpodstawowych bądźobiektówimplementujących interfejsSerializable,

� obiekty implementująceinterfejs Remote.

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łnifunkcję szkieletu) rozpakowuje argumenty wywoływanejmetody obiektu zdalnego, po czym pakuje i wysyławyniki wywołania.

*RPC to skrót od terminu Remote Procedure Call (wywoływanie zdalnych procedur). Ale to nudy…

Klient Serwer

obiekt klienta

pośrednikobiekt zdalny

pobierzImie(22)

pobierzImie(22)

szkielet„Jan” „Jan”„Jan”

pobierzImie(22)


W przypadku zwyczajnych, lokalnych wywołańmetod Java przekazuje referencje przez wartość.Innymi słowy, kopiuje bity zapisane w zmiennejreferencyjnej.

Sam obiekt nigdy nie jest przekazywany.

92 Rozdział 2

Zdalne przekazywanie obiektów

Zaraz, chwileczkę… PrzecieżJava przekazuje obiekty, przekazując kopię

referencji do danego obiektu, a nie samobiekt. A zatem, jakim cudem coś takiego

może działać w przypadku wywołań zdalnych?Przecież taka referencja nie ma

najmniejszego znaczenia na innejstercie…

Będziemy sobie wyobrażać, że referencjajest pilotem do obiektu znajdującego się nastercie. Pilotem, czyli czymś, czego możemyużyć do naciskania przycisków i sterowaniaobiektem (czyli, na przykład, dowywoływania jego metod).

void doDziela() {

Pies azor = new Pies();

this.szkolZwierzaka(azor);

}

void szkolZwierzaka(Pies arg) { }

Co tak naprawdę tu przekazujemy?

Kopia referencji (pilota), a nie obiekt Pies.

Teraz parametr „arg” oraz zmienna

„azor” są identyczne. Obie odwołują

się do tego samego obiektu Pies.

Oczywiście wiemy, że Ty towszystko wiesz, ale wyjaśniamy totak na wszelki wypadek, aby miećpewność, że jesteś „na tej samejstronie co my” (co brzmi niecodziwnie, bo to przecież oczywiste,że jesteśmy na tej samej stronie),i że rozumiesz ideę.

azor

Pies

obiekt Pies

azor

Pies

arg

Pies

obiekt Pies


Co tak naprawdę jest przekazywane,

gdy przekazujesz obiekt w wywołaniu

zdalnej metody?



Wyobraź sobie poniższy fragment kodu używanego przez KLIENTA:

try {

Pies azor = new Pies();

zdalnyPosrednik.szkolZwierzaka(azor);

} catch (RemoteException ex) {

ex.printStackTrace();

}

Oraz ten kod ZDALNEJ metody:

void szkolZwierzaka(Pies pies) { }

Co tak naprawdę tutajprzekazujemy??

To NIE jest referencja!

To serializowana kopia

faktycznego obiektu Pies.

Obiekt Pies na serwerze jest

kopią obiektu istniejącego po

stronie klienta.

Jeśli Twoja zdalnametoda wymagaprzekazaniaargumentu, któregowartość jest obiektem,to argument ten będzieprzekazywany jakokompletna kopiaobiektu!

W przypadku wywołańzdalnych metod, Javaprzekazuje obiektykopiując je, a nie w formie referencji.

Serializowana kopiaobiektu jestprzekazywana doobiektu zdalnego.

&��Pies ��!��

��Serializable

azor

Pies

obiekt Pies

KKlliieenntt

azor

Pies

obiekt Pies

KKlliieennttarg

Pies

obiekt Pies

SSeerrwweerr

obiekt Pies

Serializable

Pies


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.

94 Rozdział 2

Argumenty zdalnych metod

Klient przekazujekopię referencji doobiektu Piesznajdującego się nastercie. Istnieje tylkojeden obiekt Pies.

c Pośrednik tworzy serializowaną kopię obiektu i przesyła ją siecią do obiektu szkieletu.

Pośrednik przesyła

serializowany obiekt Pies.

klient

zdalnyobiekt

pośrednik

Pies

szkieletszkolZwierzaka(mojPies)

klient

zdalnyobiekt

pośrednik

Pies

szkolZwierzaka(mojPies)szkielet

Pies


Rozpakowywanie (deserializacja) obiektu na serwerze

d Szkielet przeprowadza deserializację przekazanychargumentów, tworząc tym samym nowy obiekt Piesna stercie zdalnego obiektu.



Nowy obiekt Pies jest taki sam jak obiektznajdujący się po stronie klienta.

e Szkielet wywołuje metodę zdalnego obiektu, przekazującw wywołaniu zwyczajną referencję do nowego obiektu Pies.

W chwili gdy realizowane jest

wywołanie metody zdalnego obiektu,

obiekt Pies jest już kolejnym,

zwyczajnym obiektem na stercie.

klient

zdalnyobiekt

pośrednik

Pies

Pies

szkielet

klient

zdalnyobiekt

pośrednik

Pies

szkielet

Pies

szkolZwierzaka(nowyPies)


P. Mam obiekt HashMap pełny obiektów Klient(implementujących interfejs Serializable), z którychkażdy ma unikatowy klucz typu String. Czy powinienem martwić się tym, czy sam obiektHashMap można serializować?

O. W porządku, to jedno z serii podchwytliwych pytań. Wszystkieimplementacje interfejsu Collection dostępne w J2SE APIimplementują interfejs Serializable. A zatem, nie musiszprzejmować się obiektem HashMap — jeśli obiekty, które w nimumieszczasz implementują interfejs Serializable, to wszystkobędzie w porządku.

Ale… jest coś, co może doprowadzić do wystąpienia problemów.Prawdopodobnie nigdy się nie znajdziesz w takiej sytuacji, niemniejjednak warto o niej wspomnieć. Zapewne już wiesz, że klasyimplementujące interfejs Map, takie jak HashMap orazHashtable, dysponują metodą values() zwracająca kolekcjęwartości, bez skojarzonych z nimi kluczy. Innymi słowy, możeszwywoł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 obiektimplementujący interfejs Collection. Jednak informacja ta niewystarcza nam, by stwierdzić czy obiekt zwrócony przez wywołaniemetody values() może być serializowany! Innymi słowy, może sięokazać, że pomimo umieszczenia w kolekcji obiektówimplementujących interfejs Serializable, nie możnaprzeprowadzić serializacji samej kolekcji!

A oto wniosek: nie polegaj na tym, że kolekcje zwrócone przezmetodę values() obiektów implementujących interfejs Map,będzie można serializować. Umieszczaj swoje obiekty w czymś, co napewno pozwala na serializację, czyli, na przykład, w obiektachArrayList, a dopiero potem próbuj przesyłać je jako argumentwywołania zdalnej metody.

P. Jeśli czegoś, co przekazujesz w wywołaniu zdalnejmetody nie można serializować, to czy próba wykonaniaserializacji spowoduje wystąpienie błędu podczaskompilacji, czy też w trakcie działania programu?

O. W czasie działania programu! A przynajmniej zazwyczaj takbywa. Pamiętaj, że zadeklarowany typ argumentu lub wartościwynikowej niekoniecznie odpowiada typowi obiektu, który będzieprzekazywany lub zwracany w czasie wykonywania programu.

Problemy mogłyby zostać wykryte podczas kompilacji tylko iwyłącznie w przypadku, gdyby zadeklarowanym typem argumentówlub wartości wynikowych był interfejs Serializable:

public void wezTo(Serializable s);

W takim przypadku kompilator mógłby wykorzystać standardowemechanizmy kontroli typów, by sprawdzić, czy typ przekazywanegoargumentu faktycznie implementuje Serializable.

Jednak w większości przypadków Serializable nie jestzadeklarowanym 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żnaserializować, czy nie, aż do chwili gdy spróbuje to zrobić (a w takiejsytuacji, gdy obiekt nie implementuje interfejsu Serializable,zostanie zgłoszony wyjątek).

W przypadku serializacji tablic i kolekcji, jeśli którykolwiekz umieszczonych w nich obiektów nie będzie implementować interfejsuSerializable, to cała operacja serializacji nie powiedzie się.

P. Czy moje klasy muszą jawnie implementowaćinterfejs Serializable, czy wystarczy, że będzie ondziedziczony po klasie bazowej?

O. Przypomnij sobie jedną z podstawowych zasadobowiązujących w Javie: jeśli Twój rodzic (czyli klasa bazowa) jestczymś, to także Ty jesteś tym czymś. Jeśli klasa Pies dziedziczy poklasie Zwierze, a klasa Zwierze implementuje interfejsSerializable, to także obiekty Pies nadają się do serializacji i toniezależnie do tego czy klasa Pies jawnie implementuje interfejsSerializable, czy nie.

Niemniej jednak, jawne deklarowanie, że klasa implementuje interfejsSerializable, nawet jeśli jest on implementowany w klasiebazowej, jest uznawane za dobrą praktykę programistyczną. Dziękitemu inne osoby używające stworzonych przez Ciebie klas nie będąmusiały wnikliwie analizować całej ich hierarchii, by sprawdzić czyktóraś z klas bazowych implementuje interfejs Serializable.

96 Rozdział 2




Pamiętaj, że argumenty wywołania orazwartości wynikowe zwracane przez zdalnemetody muszą być:

� wartościami typów podstawowych,

� obiektami implementującymi interfejsSerializable,

� tablicami lub kolekcjami wartości typówpodstawowych lub obiektów implementującychinterfejs Serializable,

� obiektami implementującymi interfejs Remote.



Za chwilę wszystko sięwyjaśni i ułoży w logicznącałość. Jednak zanimodwrócisz kartkę, zastanówsię przez chwilę nadimplikacjami wynikającymiz faktu przesyłaniaw wywołaniu zdalnej metodyzdalnego obiektu.

Nie rozumiem dlaczegoprzekazanie obiektu typu

Remote w wywołaniu zdalnej metody jestpoprawne! No bo przecież, czy cała

idea takiego zdalnego obiektu niepolega na tym, że… jest on zdalny?

Po co miałbyś przesyłać taki obiekt doklienta? Przecież to nie ma

sensu.


Przekazywanie obiektu Remote

w wywołaniu zdalnej metody

Przesyłanie zdalnego obiektu w wywołaniu zdalnej metody niema 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 zdalnegoklienta referencję do innego zdalnego obiektu? Co się stanie,jeśli zamiast normalnej kopii obiektu Klient, przekażemy doniego pośrednika do zdalnego obiektu Klient?

Przemyśl to sobie zanim rozpoczniesz lekturę następnej strony.

98 Rozdział 2



��%��!�� "�� '�

��!�Klient �� '��!�Klient�

�� "��%� �� "��

�� '��!�Klient�

��%��'�� % ��

()��*��

��

��"�� !� ��%

�� %��%$�#� �� !��%��'��

�� '�� % �� "��%

� � ��$+

W przypadku przekazywania obiektutypu Remote do lub z wywołaniazdalnej metody, Java przekazujew rzeczywistości pośrednika dotego obiektu.

Innymi słowy, podczas działaniaprogramu zdalny obiekt pozostajedokładnie tam, gdzie jest,a zamiast niego przekazywany jestjedynie jego pośrednik.

Zdalna referencja to pośrednik do zdalnegoobiektu. Jeśli klient dysponuje zdalnąreferencją, oznacza to, że dysponujezwyczajną, lokalną referencją do pośrednika,który z kolei jest w stanie komunikować sięze zdalnym obiektem.

lokalna referencja

do pośrednika

pośrednikdo zdalnegoobiektu

FFoooo

tst

zdalny obiekt

Foo zdalny obiekt

Foo

Obiekt klienta

SSeerrwweerrKKlliieenntt


Kiedy wartość wynikowa jest zdalnym obiektem…

B Klient wywołuje metodę pobierzKlienta() zdalnegoobiektu A (korzystając przy tym z pośrednika 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 powrotemdo klienta.

Pośrednik klienta (B) zostaje odtworzony(deserializowany) po stronie klienta, po czym klientotrzymuje lokalną referencję do nowego obiektupośrednika.

Teraz klient otrzymuje lokalną

referencję do pośrednika

do obiektu Klient (B).

Serializowany pośrednikdo zdalnego obiektu B(obiektu Klient).

Obiekt zdalny (A) zwraca lokalną refe

rencję

do obiektu Klient (zdalnego obiek

tu B),

jednak z powrotem jest tak naprawdę

przesyłany pośrednik.

klient

zdalnyobiekt

Azdalnyobiekt

B

pośrednikA

szkieletpobierzKlienta()

pobierzKlienta()pobierzKlienta()

Klient

klient

zdalnyobiekt

Azdalnyobiekt

B

pośrednikA

pośrednik B

szkielet

Klient

zdalnypośrednik B

lokalna referencjado pośrednika B


P. Co się stanie, jeśli obiekt klienta oraz obiekt zdalnybędą działać na różnych JVM, lecz na tym samymkomputerze? Innymi słowy, jeśli będą działać w dwóchróżnych programach napisanych w Javie i wykonywanych natym samym serwerze?

O. To nie ma żadnego znaczenia. Liczy się tylko to, czy dwaobiekty istnieją na tej samej czy na różnych stertach, a na szczęściedwie wirtualne maszyny Javy nie używają tej samej sterty, niezależniedo tego, jak są sobie bliskie (czyli, bez względu na to czy działają natym samym serwerze).W praktyce jednak możesz (a w przypadku technologii EJB częstomusisz) używać RMI, nawet jeśli obiekty znajdują się na tej samej stercie.

P. Niby dlaczego miałbyś chcieć używać RMI, jeśli niejest to konieczne? Czy samo wywoływanie zdalnych metodnie jest wystarczająco kosztowne?

O. Zagadnieniem tym zajmiemy się szczegółowo nieco później,jednak głównym powodem jest to, iż rezygnacja z wykorzystaniaRMI do wywoływania metod powoduje ograniczenie aplikacjipoprzez utratę możliwości rozmieszczania obiektów w różnychmiejscach 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 todecyzja nieodwołalna, gdyż późniejsza zmiana rozwiązaniapociągnęłaby za sobą konieczność przepisywania całego kodu.Z drugiej strony, jeśli zastosujesz RMI, to w dowolnej chwili będzieszmógł zdecydować się, aby go podzielić na części i rozmieścić w różnychmiejscach 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 rozproszonychaplikacji korporacyjnych, nie jest to wcale największy problem.Zazwyczaj największy wpływ na wydajność działania aplikacji maprzepustowość 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 niezawsze jest takie proste, dlatego też powrócimy do tego zagadnieniaw dalszej części książki.

100 Rozdział 2

Pytania dotyczące RMI


■ Technologia EJB używa RMI, aby zdalne klienty mogłykorzystać z komponentów.

■ W tym kontekście klient zdalny to obiekt wykonywanyprzez inną wirtualną maszynę Javy, co jednocześnieoznacza, że jest on umieszczony na innej stercie.

■ Zdalny obiekt pozostaje na swojej stercie, natomiastklienty wywołują metody pośrednika tego zdalnegoobiektu.

■ Obiekt pośrednika obsługuje wszystkie siecioweoperacje 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średnikistnieje na tej samej stercie co klient.

■ Z punktu widzenia klienta, wywołanie zdalnej metodyjest niemal identyczne z wywołaniem metody lokalnej;jedyna różnica polega na tym, że wywołanie metodyzdalnej może zgłosić wyjątek RemoteException(wyjątek weryfikowany).

■ Pośrednik przygotowuje informacje o argumentachwywołania metody i przesyła je do obiektu szkieletudziałającego na serwerze. Sam obiekt szkieletu jestwprawdzie opcjonalny, jednak jego zadania muszązostać wykonane. Nie musimy przejmować się tym kto— lub co — wykona te zadania.

■ Argumenty wywołania zdalnej metody oraz zwracaneprzez nie wartości muszą być wartościami typówpodstawowych, obiektami implementującymi interfejsSerializable, tablicami lub kolekcjami wartościtypów podstawowych lub obiektów implementującychinterfejs Serializable bądź też obiektamiimplementującymi interfejs Remote. Jeśli argumenty lub wartości wynikowe będą jakiegokolwiek innegotypu, to podczas działania programu zostaniezgłoszony wyjątek.

■ Jeśli wartością argumentu lub wynikiem zwracanymprzez metodę będzie obiekt, to zostanie on przesłanyjako serializowana kopia, a następnie odtworzony nalokalnej stercie zdalnego obiektu.

■ Jeśli wartością argumentu lub wynikiem metody będzieobiekt typu Remote, to zamiast samego obiektuzostanie przesłany jego pośrednik.

KLUCZOWE ZAGADNIENIA




O rany! Niemalzapomniałam o najważniejszej sprawie

związanej z wywołaniami zdalnych metod! Jeślito serializowane obiekty są przekazywane jako

argumenty lub wartości wynikowe, to koniecznie musisz upewnić się, że plik

klasowy dla klasy przekazywanego obiektu jestdostę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 klaspośredników. Jeśli klient nie

dysponuje plikami klasowymiobiektu pośrednika, to wszystko na nic!


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 metodybiznesowe, z których chce korzystać klient. Jeśli chodzio szczegóły techniczne, to interfejs biznesowy zdalnego obiektupowinien (i to jest prawdziwe zaskoczenie) być interfejsemzdalnym.

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ątekjava.rmi.RemoteException,

� argumenty i wartości wynikowe muszągwarantować możliwość przesłania (czyli muszą być obiektami Serializable,wartościami typów podstawowych itd.).

import java.rmi.*;

public interface KosciDoGry extends Remote {

public int rzucKoscmi() throws RemoteException;

}

102 Rozdział 2

Interfejs Remote

Wszystko zaczyna się od zdalnego. Zarówno zdalny obiekt,

jak i pośrednik implementują ten saminterfejs… zawierający metody, któreklient chce wywoływać.

Zdalny interfejs musi dziedziczyć pointerfejsie , a każdajego metoda musi deklarować wyjątek

.RemoteException

java.rmi.Remote

interfejsu

Klasa RemoteException oraz interfejs Remote

należą do pakietu java.rmi.

Zdalny interfejs MUSI dziedziczyć po interfejsie

java.rmi.Remote (który nie deklaruje żadnych metod).

Wszystkie metody zdalnego interfejsu muszą

deklarować wyjątek RemoteException.


Klient wywołuje metodę biznesową

za pośrednictwem zdalnego interfejsu

biznesowego

Pamiętaj, że z punktu widzenia klienta, wywołuje on metodyPrawdziwego Obiektu. Faktycznego zdalnego obiektu. Czyliobiektu 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.



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.

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ędziemyjuż pokazywali obiektu szkieletu.Obchodzi nas tylko to, że COŚ naserwerze będzie realizowaćzadania, które normalniewykonuje szkielet.

sstteerrttaa kklliieennttaasstteerrttaa sseerrwweerraa

<<interfejs>>Remote

<<interfejs>>KosciDoGry

rzucKoscmi()

KosciDoGryStub

rzucKoscmi()

KosciDoGryImpl

rzucKoscmi()

zdalny (biznesowy)

interfejs

klasapośrednika

klasazdalnegoobiektu

klientKosciDoGryImplpośrednik KosciDoGryK

osci

DoG

ry

Kos

ciD

oGry


Bazując na przedstawionym poniżej schemacie, umieść klasy i interfejsyw odpowiednich prostokątach, reprezentujących odpowiednio klientai serwer (klasy mogą być używane zarówno po stronie klienta,jak i serwera). Schemat jest uproszczony, zatem nie zostały na nimprzedstawione wszystkie elementy aplikacji.

104 Rozdział 2

Architektura EJB

Przygotuj ołówek

TToo ććwwiicczzeenniiee jjeesstt zzwwiiąązzaannee zz bbłłęęddeemm,, kkttóórryy pprrooggrraammiiśśccii uużżyywwaajjąąccyy tteecchhnnoollooggiiii EEJJBBppooppeełłnniiaajjąą nnaajjcczzęęśścciieejj.. DDllaatteeggoo nniiee ppoommiijjaajj ggoo!!

klientpośrednik

Pieszdalny

TrenerPsówszkolZwierzaka(mojPies)

Pies

TrenerPsowImpl

interfejsTrenerPsow

TrenerPsowStub

klasa klienta

Pies


Sposób zastosowania RMI w technologii EJB



W technologii EJB klient niemal zawsze uzyskujedostę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 cokomponent, które nie używają RMI do wywoływaniametod biznesowych), a w niektórych sytuacjach jest tonawet konieczne. Jednak dotyczy to nieznacznej liczbybardzo szczególnych sytuacji.

A zatem, w przeważającej większości przypadkówRMI stanowi podstawę komunikacji pomiędzyklientem i komponentem. Jednak, jak miałeś okazjęprzekonać się w pierwszym rozdziale, architekturaEJB jest nieco bardziej skomplikowana niż prostyschemat komunikacji „klient-pośrednik-obiektzdalny”. W technologii EJB komponent, czyli to coś,co posiada metody biznesowe, które chcemywywołać, nie jest obiektem zdalnym!

Standardowe zastosowanie technologii RMI tu jestzaimplementowana

logika biznesowa!

Zastosowanie technologii RMI w EJBtu jest zaimplementowanalogika biznesowa!

Klient

pośrednik

inte

rfej

s biz

neso

wy

zdalnyobiekt

KKlliieennttsseerrwweerr

sterta bazadanych

Klient

pośrednik

inte

rfej

s biz

neso

wy

usłu

gizdalnyobiekt

obiekt EJB


sterta bazadanych

komponent EJB

inte

rfej

s biz

neso

wy

inte

rfej

s biz

neso

wy


Zdalny obiekt — EJBObject — nie jest

komponentem, to strażnik komponentu

Pamiętaj, że w technologii EJB zdalny obiekt (EJBObject) pełnifunkcję „strażnika” komponentu. Sam komponent trzyma się z tyłu i jestzabezpieczony przed wszystkimi bezpośrednimi odwołaniami ze stronyklientów, natomiast to obiekt typu EJBObject implementuje zdalnyinterfejs i przyjmuje wywołania metod. Kiedy wywołanie dotrze doobiektu 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, czyteż należy rozpocząć nową), czy też trwałość (czy przed wykonaniemmetody komponent powinien pobrać jakieś informacje z bazy danych?).

Obiekt EJBObject implementuje zdalny interfejs biznesowy, a zatemwywoł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.

106 Rozdział 2

Obiekt EJB

Zarówno zdalny obiekt, jaki pośrednik implementują tensam interfejs — interfejsbiznesowy (nazywany takżeinterfejsem komponentu) — lecz nie dysponują faktycznąlogiką biznesową.

Z kolei klasa komponentu NIE implementuje interfejsubiznesowego (oczywiście jedyniez formalnego punktu widzenia),lecz dysponuje możliwościamifunkcjonalnymi realizującymifaktyczną logikę biznesową.Nikt nie będzie

rozmawiać z komponentembez wcześniejszegouzgodnienia tego

ze mną.

Komponent nie implementuje zdalnegointerfejsu (czyli interfejsubiznesowego)! (Jednak IMPLEMENTUJElogikę biznesową.)

Klient

pośrednik

inte

rfej

s biz

neso

wy

usłu

gi

obiekt EJB

KKlliieennttsseerrwweerrEEJJBB

sterta bazadanych

komponent EJB

inte

rfej

s biz

neso

wy

zdalnyobiekt

Zarówno pośrednik, jak i zdalny

obiekt implementują ten sam

interfejs, lecz nie dysponują

implementacją FAKTYCZNEJ

logiki biznesowej.


Interfejs komponentu

W technologii EJB interfejs biznesowy jest nazywany interfejsemkomponentu. To właśnie on informuje klienta o dostępnychmetodach biznesowych. Podstawowa różnica pomiędzyinterfejsem RMI oraz zdalnym interfejsem komponentu polegana tym, że w EJB dziedziczymy po interfejsiejavax.ejb.EJBObject, a nie po interfejsie java.rmi.Remote�

Kluczowe zagadnienia:

B &��'��

��java.rmi.Remote��

�� $

c ��EJBObject � �� Remote�

�� EJBObject �� $

d ,�� !��!��

��EJBObject.

(�� !

� � �� !� ��%��

��-� �� .$

�$*�� $+

e /�� !��

�� %��!��!$

f ��EJBObject !��

�� $�

(0�� !�� "��%��$+



Wszystkie zdalne interfejsy

muszą dziedziczyć po

interfejsie java.rmi.Remote.

W RMI interfejsjava.rmi.Remote jestdziedziczony bezpośrednio.Natomiast w technologiiEJB Twój interfejspowinien dziedziczyć pointerfejsie EJBObject,który z kolei dziedziczy pointerfejsie Remote.

Twój interfejs komponentu

dziedziczy po interfejsie

EJBObject. To właśnie

w tym interfejsie

umieszczasz swoje metody

biznesowe. To właśnie

tego interfejsu będzie

używać klient!

)�� '��!��

��Koszyk��!��

�� 1

Koszyk �� EJBObject$��EJBObject ��'%��

�� 2�3$

<<interfejs>>Remote


kilka metod

<<interfejs>>Koszyk



Jak klasa komponentu pasuje do tej układanki

108 Rozdział 2

Klasa komponentu

to TY tworzysztę klasę

(klasa komponentu)

to TY tworzyszten interfejs

(zdalny interfejskomponentu)

Te same metody, które jednak nie są ze sobąbezpośrednio powiązane z punktu widzenia języka.Klasa KoszykBean nie implementuje interfejsu Koszyk!(a jednak wygląda tak, jak gdyby implementowała…)

Twórca komponentu musi upewnić się, że klasa

komponentu ma te same metody, co interfejs

komponentu. Metody w klasie oraz w interfejsie

muszą być identyczne, jak gdyby klasa

IMPLEMENTOWAŁA interfejs komponentu.

NAPRAWDĘmusisz znać te interfejsy!

Podchodząc do egzaminu, musisz dokładniewiedzieć gdzie jest deklarowana każdaz metod. Musisz wiedzieć, które z nich należądo interfejsu EJBObject, a które, naprzykład, do interfejsu SessionBean. Musisztakże znać dokładną sygnaturę każdej z tychmetod. Wszystkie te interfejsy zostanąszczegółowo opisane w kilku kolejnychrozdziałach, a gdy zaczniemy je analizować,lepiej się skoncentruj i wytęż uwagę!

Uwaga

<<interfejs>>Remote

brak metod


kilka metod

<<interfejs>>Koszyk



brak metod


kilka metod

<<interfejs>>KoszykBean


inne metody


P. Chciałbym mieć pewność, że wszystko dobrzezrozumiałem… interfejsy mogą dziedziczyć po innychinterfejsach?

O. Tak, interfejsy mają swoje własne drzewo dziedziczenia.W rzeczywistości interfejsy pozwalają na coś, czego nie możnazrobić z klasami — na to, by jeden interfejs dziedziczył po kilkuinnych interfejsach jednocześnie!

interface Koszyk extends EJBObject,

LogikaBiznesowaKoszyka

P. Ale co to oznacza, że jeden interfejs dziedziczy poinnym? No bo właściwie co interfejs może dziedziczyć?

O. W przypadku interfejsów dziedziczenie oznacza,iż interfejs dziedziczący będzie dysponować wszystkim, czymdysponuje jego interfejs (lub interfejsy) bazowy. Ktokolwiekbędzie implementować taki interfejs, musi zaimplementować nietylko jego metody, lecz także wszystkie metody każdego interfejsubazowego… aż do samego wierzchołka drzewa dziedziczenia.

A zatem, w powyższym przykładzie ktokolwiek będzieimplementować interfejs Koszyk, musi także zaimplementowaćwszystkie metody interfejsu EJBObject.

P.. Dlaczego w komponencie nie jest implementowanyinterfejs Remote (interfejs biznesowy)? Czy nie po towłaśnie są stosowane interfejsy — aby kompilator mógłwymusić uczciwość programisty, oraz by móc wykorzystaćmechanizmy kontroli typów?




O. Już wcześniej zadałeś to pytanie. Ale nie przejmuj się,wszyscy o czymś zapominamy, dlatego przypomnimy Ciodpowiedź. Komponent nie implementuje interfejsu Remote, gdyżnigdy nie powinien być obiektem zdalnym (w terminologiitechnologii RMI). Innymi słowy, nie chcesz, by ktokolwieki kiedykolwiek dysponował pośrednikiem do samego komponentu!Starając się w jakiś sposób przemycić i udostępnić klientomreferencję do komponentu (czyli pośrednika komponentu),niszczysz podstawowy cel technologii EJB! Jeśli pozwolisz,by klient komunikował się bezpośrednio z komponentem, toserwer nie będzie w stanie udostępnić Ci swoich usług, a jeśli niepotrzebujesz usług serwera, to… sam wiesz dokąd zmierza torozumowanie.

Z technicznego punktu widzenia implementowanie w komponencieinterfejsu Remote nie jest błędem. Jednak stosowanie takiegorozwiązania jest fatalnym pomysłem, gdyż sprawia, że możeszpopełnić błędy, które nie zostaną wykryte na etapie kompilacji(i uwidocznią się dopiero podczas działania aplikacji). Jednak wcalenie musisz stosować takiego rozwiązania, gdyż niemal wszystkienarzędzia programistyczne (z praktycznie wszystkimi zintegrowanymiśrodowiskami programistycznymi wspomagającymi tworzeniekomponentów EJB włącznie) doskonale znają wzajemne zależnościwystępujące pomiędzy komponentem, interfejsem EJBObject orazRemote i są w stanie zagwarantować, że zarówno interfejskomponentu, jak i komponent będą mieć te same metody.

P. No dobrze, ale jeśli to całe rozwiązanie jest dlamnie zbyt stresujące? Taki pomysł kłóci się z mojąprogramistyczną wrażliwością, pozostajew sprzeczności z podstawowymi zasadami, którymikieruję się, pisząc programy w Javie. Jestem pewny, że istnieje jakieś inne rozwiązanie!

O. Mógłbyś nam zaufać i uwierzyć stwierdzeniu, że „niemal napewno będziesz używać narzędzi, więc to naprawdę nie maznaczenia. Poważnie”; ale nie… No dobrze, zatem faktycznie jest coś,co mógłbyś zrobić i co pewnie pozwoli, byś poczuł się lepiej.Opisaliśmy to rozwiązanie na następnej stronie, leczprawdopodobnie sam możesz zgadnąć na czym ono polega.Niemniej jednak, obstajemy przy swojej opinii, że większośćprogramistów nie będzie musiała uciekać się do tego rozwiązania.

Implementując interfejs, musimyzaimplementować wszystkie metody,które interfejs ten odziedziczył poswoich interfejsach bazowych.

Oznacza to, że ktokolwiek zajmie sięimplementacją interfejsu Koszyk,będzie musiał zaimplementować metodyzarówno interfejsu Koszyk jaki EJB0bject.


Rozwiązanie dla tych, których sama myśl o tym, że komponent może nie implementowaćinterfejsu metod biznesowych napawa obrzydzeniem.

110 Rozdział 2

Implementacja interfejsu

Stwórz interfejs zawierającymetody biznesowe, któryjednak nie będziedziedziczyć po EJBObject(a zatem nie będzieinterfejsem typu Remote).

Teraz interfejs komponentu

dziedziczy zarówno po

EJBObject, JAK I po

interfejsie metod biznesowych.

Klasa komponentu powinna w tymprzypadku implementować zarównointerfejs EJBObject, JAK I interfejsmetod biznesowych. W ten sposóbkompilator zagwarantuje,że w klasie komponentu znajdą sięwłaściwe metody.

WWłłaassnnyymmii śścciieeżżkkaammii

<<interfejs>>Remote

brak metod


kilka metod

<<interfejs>>Koszyk

brak metod


brak metod


kilka metod

<<interfejs>>KoszykBean


inne metody

<<interfejs>>LogikaBiznesowaKoszyka



Kto tworzy klasę, która w rzeczywistości

implementuje interfejs komponentu? Innymi

słowy, kto tworzy klasę EJBObject?

Kontener. Wprawdzie Ty deklarujesz metody, lecz to właśnie kontenerimplementuje Twój interfejs komponentu. Pamiętaj, że interfejskomponentu jest interfejsem, który dziedziczy po EJBObject, a zatem,kontener musi zaimplementować w nim nie tylko Twoje metody biznesowe,lecz także metody interfejsu EJBObject (których jeszcze nie poznaliśmy).

P. Ale skąd kontener wie co należy umieścić w tych metodach?Przecież to ja je deklaruję…

O. Pamiętaj, że kontener nie implementuje faktycznej logiki biznesowej.Prawdziwe możliwości funkcjonalne metod biznesowych znajdują się w klasiekomponentu — którą Ty implementujesz. Klasa implementująca interfejsu komponentuposłuży do utworzenia obiektu EBJObject. „Strażnika” komponentu. Obiektuzdalnego. A nie zapominaj, że obiekt EJBObject tylko udaje, że jest komponentem.Może on odpowiadać na wywołania zdalnych metod przesyłane przez klienty(za pomocą pośredników), jednak jego zadanie polega wyłącznie na przechwytywaniuwywołań kierowanych do komponentu. Wszystko co dzieje się potem zależy wyłącznieod kontenera (lub serwera).

Tak naprawdę nie wiemy w jaki sposób jest implementowany obiekt typuEJBObject, to w całości zależy od twórców kontenera lub serwera. Jednak właściwiew ogóle nas to nie obchodzi. Wystarczy byś wiedział, że specyfikacja wymaga,by kontener EJB był w stanie wygenerować kod klasy EJBObject(oraz odpowiadającego jej pośrednika).



W porządku, zatemto ja tworzę swój bean i umieszczam

w nim odpowiednie metody z interfejsukomponentu, a przy tym,

z oficjalnego punktu widzenia, nieimplementuję tego interfejsu. Ale jeśli ja

nie implementuję tego interfejsu,to… kto to robi?


Kto tworzy poszczególne klasy?

Wiesz, że w przypadku komponentów widocznych dla zdalnych klientów (czyli komponentów, do których zdalne klienty mają dostęp), to Ty musisz napisać interfejs komponentu oraz klasękomponentu. Jednak ktoś musi stworzyć klasę implementującą Twój interfejs komponentu (aby można było stworzyć obiekt typu EJBObject), jak również ktoś musi stworzyć pośrednika,który będzie współpracować z obiektem EJBObject. Tym „kimś” jest kontener. Aby poniższeinformacje były kompletne, wymieniliśmy w nich także interfejs oraz klasy obiektu bazowego, choćdo tej pory jeszcze ich nie opisywaliśmy.

112 Rozdział 2

Kto tworzy poszczególne klasy

TyB �� (� ��

javax.ejb.EJBObject+$

c �� (��!��

javax.ejb.SessionBean �!�

javax.ejb.EntityBean+$

d �� (� ��

��javax.ejb.EJBHome-��!!��

��'��+$

Nie pisaliśmy jeszcze na temat interfejsuoraz klas obiektu bazowego, dlatego też nieprzedstawiliśmy ich na poniższym rysunku.

KontenerB &��EJBObject (��!��

��!+$

c &��"��EJBObject (��!��

��!��

��!�� EJBObject+$

d &��!�� '��(��!��

��!�� '�+$

e &��"��!�� '�

(��!��!�� '�

� �� !��+$

pośrednik usłu

gizdalnyobiekt

obiekt EJB


bazadanych

komponent EJB

inte

rfej

s kom

pone

ntu

kontener

Tykontener Ty


EJBObject: Hej Beanku… czy nie denerwuje Cię to, że zawszemieszam się do wszystkiego co robisz? Czy nie chciałbyśczasami pogadać z kimś bezpośrednio?

Komponent: Nie. Jestem zbyt ważny. Zbyt cenny. A poza tymnie mam najmniejszego zamiaru zabezpieczać swoich własnychwywołań. W końcu to wy od tego jesteście.

EJBObject: My?

Komponent: No, wy — wszyscy ludzie kontenera. Czyli obiektbazowy, pośrednicy… wy wszyscy. Moim zadaniem jest obsługazłożonej logiki biznesowej. Krytycznych funkcji, od którychmoże zależeć sukces lub porażka operacji wykonywanychw środowisku korporacyjnym.

EJBObject: (O rany… to brzmi jak gadka gości od marketingu.)No dobra, rozumiem, że dysponujesz ważnymi metodami, alewciąż nie łapię dlaczego ja muszę uczestniczyć w wywoływaniukażdej z tych metod.

Komponent: Słuchaj, moja praca jest zbyt ważna, aby byleklient, który w ogóle nie ma potrzeby kontaktowania się zemną, mógł ją przerywać swoimi wywołaniami. Czy naprawdęuważasz, że mam zamiar sprawdzać wszystkich klientówi upewniać się, że mają prawo kontaktować się ze mną? Jakbymnie miał ważniejszych rzeczy do roboty…

EJBObject: W porządku, czyli tak naprawdę chodzio bezpieczeństwo, ale w takim razie nie rozumiem dlaczego niemożesz zawierać kodu sprawdzającego prawa, jakimi dysponujekażdy klient. To pozwoliłoby na duże oszczędności (zwłaszczadla MNIE).

Komponent: Przede wszystkim, bezpieczeństwo jest tylkoJEDNYM z powodów, dla których obsługujesz wywołaniakierowane do mnie. Za chwilę mogę Ci je podać. A wracając doumieszczania kodu związanego z zabezpieczeniami we mnie —mogę to zrobić, jeśli programista sobie tego zażyczy. Ale niejest to przyjęty sposób zapewniania bezpieczeństwa.

EJBObject: A co w tym złego, że sam będziesz zabezpieczałswoje metody?

Komponent: Poważnie nie wiesz? [wznosi oczy do nieba] Przede wszystkim, gdy mechanizmy zabezpieczeń zostanąumieszczone w moich metodach, to zostaną ograniczonemożliwości wielokrotnego stosowania mnie w różnychaplikacjach. Jednym z celów EJB jest zapewnienie możliwościkonfigurowana i dostosowywania komponentu do potrzebaplikacji w trakcie eksploatacji, a nie poprzez wprowadzaniezmian w kodzie źródłowym. Gdyby mechanizmy zabezpieczeńbyły umieszczone we mnie, to nie można by ich zmienić bezwprowadzania modyfikacji w moim kodzie źródłowym. A kto by tego chciał?

EJBObject: Hm… To ma sens. Można umieścić informacjeo sposobie zabezpieczania w XML-owym deskryptorzerozmieszczenia, a kiedy odbiorę wywołanie, serwer będziew stanie sprawdzić czy konkretny klient ma niezbędneuprawnienia. Ale co w sytuacji, gdy nie zwracasz uwagi na kwestiezabezpieczeń? W sytuacji, gdy ktoś, kto Cię zainstalował niezwraca uwagi na to kto wywołuje Twoje metody?

Komponent: Nie jesteś zbyt bystry… nieprawdaż? Cóż… aleprzynajmniej możesz podnosić ciężkie obiekty… POMYŚLo wszystkich innych sprawach, które mają znaczenie; takich jaktransakcje bądź trwałość.

EJBObject: Fakt… zapomniałem o transakcjach. W porządku,transakcje też mają sens. W końcu, aby metoda mogła byćwykonana w ramach transakcji, przed jej wywołaniem serwermusi sprawdzić czy istnieje kontekst transakcji. Niezależnie czyto będzie kontekst Twój czy wywołującego klienta…

Komponent: Otóż to…

EJBObject: No ale co z tą trwałością?

Komponent: Cóż, zastanów się przez chwilę nad komponentamientity bean. Jeśli jestem takim komponentem, oznacza to, żereprezentuję jakieś dane pochodzące z trwałego magazynu i…

EJBObject: Chwila — czy mówiąc „trwały magazyn” nie masz namyśli po prostu BAZY DANYCH? Dlaczego po prostu niepowiesz, że te informacje pochodzą z bazy danych?

Komponent: O rany, co za gość. Wyrażenie „trwały magazyn”nie jest synonimem terminu „baza danych”. Ale jeśli poczujeszsię lepiej, wyobrażając to sobie w taki sposób, proszę bardzo.Ale jak już mówiłem, jeśli będę reprezentować jakieś dane, naprzykład, dane klienta Jaś Wędrowniczek, to co się stanie kiedyklient wywoła moją metodę getAdres()? Serwer nie może takpo prostu przekazać do mnie wywołania tej metody!

EJBObject: Ponieważ…

Komponent: Ponieważ w pierwszej kolejności muszępobrać informacje o Jasiu Wędrowniczku z bazy danych!EJBObject: Ponieważ…

Komponent: Ponieważ mógłbym zwrócić nieprawidłowy,nieważny adres! Jeśli wciąż znajduję się w obrębie wcześniejszejtransakcji, to serwer musi dać mi znać, abym odczytał aktualneinformacje o Jasiu Wędrowniczku z bazy danych ZANIM każemi wykonać metodę getAdres(). W przeciwnym razie nikt niewie co bym zwrócił. No dobra, to było ostatnie wywołanie,więc dokończymy rozmowę innym razem.



Zasłyszane w

POCZEKALNI DLAKOMPONENTÓW


P. Jak i kiedy kontener tworzyobiekt EJBObject, obiekt bazowy orazpośredników?

O. Podczas wdrażania komponentukontener analizuje deskryptor rozmieszczeniai pobiera komponent ze wskazanego miejsca.Pamiętaj, że deskryptor zawiera informacjeo w pełni kwalifikowanej nazwie zdalnegointerfejsu komponentu (EJBObject) orazinterfejsu zdalnego obiektu bazowego.Gdy kontener zdobędzie informacje o tychinterfejsach, wygeneruje kod dwóch klas,które je implementują. A ponieważ oba teinterfejsy dziedziczą po interfejsie Remote,kontener wygeneruje także klasy pośrednikówdla tych nowych klas.

P. Czy to zawsze są zwyczajneobiekty pośredników RMI? Podczaswdrażania komponentu na serwerzepojawił się komunikat o wykonywaniuprogramu rmic…

O. Kontener może generować klasypośredników w całkowicie dowolny sposób,jedynym ograniczeniem jest wymóg, aby byłyone zgodne z RMI-IIOP. W celuzaimplementowania możliwości funkcjonalnychpośredników serwer może wykorzystaćrozwiązanie nazywane „dynamicznymipośrednikami” (ang. dynamic proxies), ale nas tow ogóle nie obchodzi. Mówiąc „pośrednik”,mamy na myśli cokolwiek, co ma możliwościfunkcjonalne pośrednika. A to czy jest topośrednik RMI, czy też coś innego, to jedynieszczegół implementacyjny. Zagadnieniem tymzajmiemy się bardziej szczegółowo w następnymrozdziale. Najważniejsze jest jednak to, iżw rzeczywistości nie wiemy jak wygląda kodklasy pośrednika. A zatem, nie wiemy jak jestzaimplementowany obiekt typu EJBObjectoraz obiekt bazowy. Co więcej, nawet niepowinniśmy tego wiedzieć.

Być może, używany kontener EJB pozwala naoglądnięcie generowanego przez siebie koduźródłowego (a może nawet na jegomodyfikację), niemniej jednak nie powinieneś na

to liczyć. A na Twoim miejscu nie staralibyśmy sięani oglądać tego kodu, ani go modyfikować,nawet gdybyśmy mieli taką możliwość.

P. A zatem, implementacja tychklas zależy wyłącznie od twórcówserwera lub kontenera EJB?

O. Tak! Twórcy mogą wybierać różnesposoby implementacji i starać się uzyskaćpoprawę wydajności poprzez zastosowanieodpowiedniej postaci obiektów pośredników,obiektów bazowych oraz obiektówEJBObject. Ale powtarzamy, te zagadnienianie powinny Cię nawet interesować, a tymbardziej nie powinieneś w nich czegokolwiekzmieniać.

Specyfikacja wymusza (także na Tobie) igwarantuje jedynie to, iż obiekty typu Remotemuszą być zgodne z regułami technologii RMI-IIOP, czyli wersji RMI korzystającej z protokołutransportowego IIOP (należącego doarchitektury CORBA).

P. Skoro już wspomnieliście o tym,to czym różni się RMI-IIOP odzwyczajnego RMI?

O. W pierwotnej wersji RMI używany byłprotokół transportowy JRMP. Z kolei protokółIIOP pozwala, by zdalne obiektywspółpracowały, korzystając z technologiiCORBA (w niniejszej książce nie będziemyszczegółowo zajmować się tą technologią,może z wyjątkiem krótkich wzmianekumieszczonych w kilku rozdziałach; CORBAbezsprzecznie wykracza poza zakresegzaminu oraz poza ramy tematyczneksiążki).

Protokół IIOP sprawia, że z Twoich obiektówbędą mogły korzystać klienty napisane takżew innych językach niż Java. Określa on sposóbprzekazywania wraz z wywołaniem metodyinformacji dotyczących transakcjii bezpieczeństwa, z których może skorzystaćużywany kontener.

W większości przypadków nawet nie będzieszzauważać różnicy pomiędzy początkowąwersją RMI a RMI-IIOP. Choć… jest kilka różnicpomiędzy obydwiema wersjami RMI, a jednaz nich bez wątpienia pojawi się na egzaminie.Zagadnieniem tym jest „zawężanie”i zajmiemy się nim bardziej szczegółowow następnym rozdziale. Na razie wystarczy,jeśli będziesz wiedział, że jest to coś, co klientmusi zrobić z pośrednikiem EJB, a czego niemusi robić ze zwyczajnym pośrednikiem;a konieczność wykonania tej operacji wynikaz faktu, iż specyfikacja EJB nakazuje, byprzyjąć założenie, że pośrednik korzystaz protokołu IIOP, a zatem może byćpośrednikiem innego rodzaju.

P. A kiedy porozmawiamyo obiekcie bazowym?

O. Na następnej stronie.

P. Dlaczego tak długo zwlekaliściez rozmową na ten temat? Czy obiektbazowy nie jest ważny?

O. Niezależnie od tego jak ważny jestobiekt bazowy, zazwyczaj stanowi on jedyniesposób na zdobycie referencji do jakiegośobiektu, który implementuje interfejskomponentu. Innymi słowy, obiektu bazowegomożesz użyć, aby uzyskać pośrednika do obiektuEJBObject (używanego przez zdalnychklientów, bo tylko o takich do tej pory pisaliśmy).

Znaczenie obiektu bazowego jest nieco większew przypadku stosowania komponentów entitybean (o czym się przekonamy), jednak i taksprowadza się ono głównie do umożliwieniazdobycia pośrednika do obiektu EJBObject.Na późniejszych etapach przeważającawiększość komunikacji pomiędzy klientemi komponentem jest realizowana poprzez obiektEJBObject, a nie poprzez obiekt bazowy.W praktyce, w przeważającej większościprzypadków klienty używają obiektówbazowych jedynie w celu zdobycia referencji doobiektu EJBObject, potem referencja doobiektu bazowego staje się niepotrzebnai można się jej pozbyć.

114 Rozdział 2

Architektura EJB



Obiekt bazowy komponentów

Każdy komponent session bean i entity bean ma swój obiekt bazowy.

Komponenty message-driven bean nie posiadają obiektówbazowych, gdyż nie są widoczne dla klientów (innymi słowy,klienty nie mogą pobrać referencji do komponentów tego typu).

Obiekty bazowe mają jedno podstawowe zadanie: zwracaniereferencji do interfejsu komponentu. W przypadku stosowaniakomponentów session bean będzie to jedyne zastosowanieobiektów bazowych. Z kolei w aplikacjach wykorzystującychkomponenty entity bean znaczenie obiektów bazowych będzieznacznie większe.

Każdy wdrożony komponent posiada swój obiekt bazowy, któryjest odpowiedzialny za wszystkie egzemplarze komponentu tegotypu. Na przykład, jeśli wdrożyłeś komponent session bean typuKoszyk, to kontener utworzy jeden obiekt bazowy dlakomponentów typu Koszyk. Obiekt ten będzie zarządzaćwszystkimi egzemplarzami komponentów Koszyk. Innymi słowy,jeśli 2000 klientów będzie chciało uzyskać referencję dokomponentu Koszyk (co, jak zapewne pamiętasz, oznaczareferencję do interfejsu komponentu beanu Koszyk), to wszystkie2000 referencji zostanie udostępnionych przez jeden jedyny obiektbazowy Koszyk.

Jeśli w ramach aplikacji wdrożysz trzy komponenty, na przykład:Koszyk, Towar oraz Klient, to na serwerze pojawią się trzyobiekty bazowe, z których każdy będzie reprezentowaćkonkretny komponent. Nie ma znaczenia ile obiektówEJBObject oraz ile pośredników utworzą i zwrócą obiektybazowe — zawsze będą tylko trzy obiekty bazowe.

A zatem, czy to oznacza, że każdemu obiektowi bazowemuodpowiada tylko jeden egzemplarz klasy implementującejinterfejs obiektu bazowego konkretnego typu? Niekoniecznie;jednak my mamy właśnie tak myśleć. Właśnie dlatego cały czasużywamy i będziemy używać terminu obiekt bazowy; podobnieprzyjmiemy, że dla każdego wdrożonego typu komponentubędzie istnieć tylko jeden obiekt bazowy. Specyfikacja zapewnia,że możemy traktować obiekty bazowe właśnie w taki sposób,niezależnie od faktycznej implementacji zastosowanej przeztwórców kontenera EJB czy serwera.



Każdy wdrożony komponentsession bean oraz entity beanposiada obiekt bazowy. Na przykład, komponentDoradcaBean posiada własny,unikatowy dla siebie obiektbazowy. Niezależnie od tego ileklientów pobierze referencję dokomponentu DoradcaBean,i tak będzie tylko jeden obiektbazowy tego typu.

Zadaniem obiektu bazowego jestudostępnianie referencji dointerfejsu komponentu.

Obiekt bazowy

(Z technicznego punktu widzenia całe tozagadnienie jest nieco bardziej złożone, gdyżkomponent może posiadać zarówno lokalny,jak i zdalny obiekt bazowy, choć jest to bardzo małoprawdopodobne. Jednak nawet w takim przypadkuistniałby tylko jeden lokalny oraz jeden zdalny obiektbazowy, niezależnie od tego ile komponentów tegotypu istniałoby w aplikacji.)


Pobieranie i korzystanie z obiektu bazowego dla komponentu DoradcaBean(#� ��!� � �� DoradcaBean ��$+

B Komponent DoradcaBean zostaje wdrożony, a serwer tworzy jeden egzemplarz obiektu bazowego DoradcaBean i rejestruje go w usłudze JNDI.

116 Rozdział 2

Obiekt bazowy

c Klient przeszukuje rejestr JNDI, poszukując w nim zarejestrowanej nazwy „Doradca”.

��-45��6.

klient obiektbazowy

inte

rfej

s obi

ektu

baz

oweg

o

usłu

gi

Obiekt bazowy

pośrednik

Obiekt bazowy

usługa nazwJNDI

„Doradca”

klient obiektbazowy

inte

rfej

s obi

ektu

baz

oweg

o

usłu

gi

Obiekt bazowy

pośrednik

Obiekt bazowy

usługa nazwJNDI

„Doradca”


d JNDI przesyła z powrotem pośrednika od zdalnego obiektu bazowego.



e Klient prosi obiekt bazowy o zwrócenie referencji do interfejsukomponentu, wywołując w tym celu metodę create().

(Innymi słowy, klient chce „utworzyć” komponent i pobraćpośrednika do obiektu EJBObject chroniącego ten komponent.)

klient obiektbazowy

inte

rfej

s obi

ektu

baz

oweg

o

usłu

gi

Obiekt bazowy

pośrednik

Obiekt bazowy

usługa nazwJNDI

„Doradca”pośrednik

klient obiektbazowy

usłu

gi

Obiekt bazowy

inte

rfej

s obi

ektu

baz

oweg

o

inte

rfej

s obi

ektu

baz

oweg

o

create()pośrednik

Obiekt bazowy


Obiekt bazowy tworzy obiekt EJBObject i przesyła klientowi pośrednikaf W tym momencie do akcji wkraczają „usługi”

i jest tworzony komponent.

118 Rozdział 2

Obiekt bazowy

g Tworzony jest obiekt EJBObject(strażnik naszego nowego komponentu), a do klienta zostaje przekazany odpowiedni pośrednik.

klient

komponent

obiektbazowy

usłu

gi

Obiekt bazowy

inte

rfej

s obi

ektu

baz

oweg

o

inte

rfej

s obi

ektu

baz

oweg

o

pośrednik

Obiekt bazowy

create()

klient

komponent

obiektbazowy

usłu

gi

Obiekt bazowy

inte

rfej

s kom

pone

ntu

pośrednik

Obiekt bazowy

obiektEJBObject

pośrednik

inte

rfej

s obi

ektu

baz

oweg

o

inte

rfej

s obi

ektu

baz

oweg

o


H Teraz (nareszcie!) klient może zrobić to, czego tak NAPRAWDĘ pragnął od samego początku — wywołać metodę biznesową komponentu! (Oczywiście wywołanie to musi zostać przekazane przez interfejs komponentu.)



I Jeśli klient nie chce używać większej liczby komponentów tego typu (w naszym przypadku — komponentów DoradcaBean), to może się jużpozbyć pośrednika obiektu bazowego. Pomimo to klient wciąż będziemógł wywoływać metody interfejsu komponentu.

klient

komponent

obiektbazowy

usłu

gi

Obiekt bazowy

pośrednik

Obiekt bazowy

obiektEJBObject

pośrednik

inte

rfej

s obi

ektu

baz

oweg

o

inte

rfej

s obi

ektu

baz

oweg

oin

terf

ejs k

ompo

nent

u

inte

rfej

s kom

pone

ntu

klient

komponent

obiektbazowy

usłu

gi

Obiekt bazowy

pośrednik

Obiekt bazowy

obiektEJBObject

pośrednik

inte

rfej

s obi

ektu

baz

oweg

o

inte

rfej

s obi

ektu

baz

oweg

oin

terf

ejs k

ompo

nent

u

inte

rfej

s kom

pone

ntu


Cykl istnienia komponentów EJB:

Klient dysponuje jedyniepośrednikiem obiektubazowego, a chce wywołaćmetodę biznesowąkomponentu.

120 Rozdział 2

Architektura EJB

Przygotuj ołówek 4�� !� !�� !�� "��

�� !��!��)5�� "�� '��!�� '�$�

4� �� !�!��%��!�

#6�� "��!�� '��'��

��!�EJBObject$�7� �� 8��8� ��

�� !$

,�� !�� (�� !��

��+��"��%�� %�� $�

9� � ��!� %�� %� �� 8��(��

�� "��'%+$�4��:�� !�%��05;<02)�;$�4��"�

��!�%�%� �� '�� $

=��:�� '�

�� %��$�)��!�!��!��

�� !��!� � �� %��

��%�� $

6��"�� >

��"�� !��'��

�� "�� "�� !$�

1.

2.

3.

4.

5.

Pośrednik przekazuje obiektowi bazowemu,że klient chciałby „stworzyć” komponent.

6.

7.

8.

9.

10.

11.

klient

komponent

usłu

gi

pośrednik

obiektEJBObjectpośrednik

Obiekt bazowy

obiektbazowy

Obiekt bazowy




No wiemy, wiemy… To nie jest nasze najlepsze dzieło.

Ale spróbuj sam… Pamiętaj, że takie wierszyki

zapamiętasz lepiej, jeśli je sam wymyślisz.

■ Komponenty, które są dostępne dla zdalnychklientów wykorzystują dwa zdalne interfejsy dziedziczącepo odpowiednio interfejsach EJBHome oraz EJBObject.

■ Interfejs „zdalny” musi dziedziczyć (jawnie bądź niejawnie) po interfejsiejava.rmi.Remote, a wszystkie jego metody muszą deklarować wyjątekjava.rmi.RemoteException.

■ W technologii EJB interfejs dziedziczący po interfejsie EJBObject jestnazywany zdalnym interfejsem komponentu. To właśnie w nim sądeklarowane metody biznesowe.

■ Klient nigdy nie wywołuje metod samego komponentu, gdyż komponentNIE jest obiektem zdalnym.

■ Kontener implementuje zdalny interfejs komponentu, tworząc klasę, którago implementuje. Klasa ta jest następnie używana w celu stworzeniaobiektu typu EJBObject dla danego komponentu. (Przypominamy,że obiekt ten jest strażnikiem komponentu.)

■ Kontener tworzy także pośrednika do obiektu EJBObject.■ Aby stworzyć zdalny interfejs komponentu, należy napisać interfejs

dziedziczący po interfejsie javax.ejb.EJBObject (a on z koleidziedziczy po interfejsie java.rmi.Remote).

■ Ty tworzysz także klasę komponentu, w której są zaimplementowanefaktyczne metody biznesowe (pomijając fakt, że z technicznego punktuwidzenia w klasie tej wcale nie jest implementowany interfejs zdalnegokomponentu).

■ Obiekt bazowy jest fabryką komponentów. Jego podstawowym zadaniemjest przekazywanie klientom referencji do komponentów. Pamiętaj jednak,że klient tak naprawdę nigdy nie dysponuje referencją do komponentu,w najlepszym przypadku może to być referencja do obiektu typuEJBObject wygenerowanego przez serwer dla danego komponentu.

■ Interfejs obiektu bazowego tworzony jest poprzez napisanie interfejsudziedziczącego po interfejsie javax.ejb.EJBHome (który z koleidziedziczy po java.rmi.Remote).

■ Kontener odpowiada za utworzenie klasy, która zaimplementuje teninterfejs, jak również za wygenerowanie odpowiedniego pośrednika.

■ Dla każdego wdrożonego komponentu istnieje tylko jeden obiekt bazowy.Na przykład, niezależnie od liczby istniejących komponentów Koszyk,na serwerze będzie istnieć tylko jeden obiekt bazowy zarządzającykomponentami tego typu.

KLUCZOWE ZAGADNIENIA

Kwiatki są na łące, a chmurki na niebie,

interfejsy zdalne są pisane przez Ciebie.

To mały kontener, a to duży projekt,

A serwer sam stworzy obiekty EJBObject.

Znowu przyszedł weekend i pogoda marna,

a klasa komponentu nigdy nie jest zdalna.

Zapamiętaj

Obowiązkowyznaczyistniejąca

zwracainterfejs

komponentu

kup tę

książkę


122 Rozdział 2

Przegląd komponentów session bean

Klient pierwszy

Klient drugi

Serwer

Klient korzystający z komponentu session bean może mieć pewność,

że będzie jedynym klientem wywołującym metody tego komponentu.

W trakcie wykonywania metody biznesowej komponent jest

własnością komponentu, który zażądał wykonania metody.

klientkomponent

pośrednik

komponent

obiektEJBObject

obiektEJBObject

pośrednik420

Obiekt bazowy

klient

pośrednik

pośrednik

Obiekt bazowy

obiektbazowy

Obiekt bazowy

Przegląd architektury — komponenty session bean

Klienty wspólnie używają obiektu bazowego, ale nigdy nie współdzielą komponentów.&�� !��%�� %��!��!�EJBObject ��

� ��$�&��'�� !� ��

�� !� �� ?�� @� ��'��

�� $�(#� �� $+

�� '��!�(�� !�DoradcaBean+

�� -�� %��"��

��'��'��!�� '�$�6�� %��

��!�DoradcaBean$�(6� ��"��'�� !��

�� '��!

EJBObject$�;��EJBObject �� 1��

��Remote 1� �� !��"��'��!$+

Istnieje tylko jeden obiektbazowy, lecz każdy klientotrzymuje własny komponenti obiekt EJBObject.

usłu

gius

ługi


Przegląd architektury — komponenty entity bean

Klienty wspólnie używają obiektu bazowego i mogą także współdzielić same komponenty.&�� %��'��%��'��!�� '�

�� %� ��%��'��'��!�(�� KonsumentBean+$

�� !�'��!�%�! ��'��'��!

Konsument (<��!�=�'��ABC+��%��'��'��!

EJBObject$�6��!�EJBObject ��ABC$�� EJBObject ��

�� '%��'��!�Konsument (�� <��=�'��+$��"��

��%��! ��!�<��=�'��ABC��

�� "��(�� +�� "��

�� "��%��!�� EJBObject$�#� ��

�� %��<��=�'��ABC$�4�� !

'��!��! ��

��"��!��!�%�� EJBObject�� !�%��

��Konsumentów$�;�� $



Klient pierwszy

Klient drugi

Serwer

klientkomponent

pośrednik

komponent

obiektEJBObject

obiektEJBObject

pośrednik420

Obiekt bazowy

klient

pośrednik

pośrednik420

pośrednik17

Obiekt bazowy

obiektbazowy

Obiekt bazowy

bazadanych

tabelaKonsumentów

Strażnik RysiaMigasa

Rysiu Migas nr 420

Stefan Sannr 17

Strażnik StefanaSana

usłu

gi


Przegląd architektury — tworzenie stanowego

komponentu session bean

#��! ��!��"��!�� '�� !��'��

��(+$�4��

��2�36�� !��"��!�2�36��$

124 Rozdział 2

Przegląd komponentów sesyjnych

1. Klient wywołuje metodę create() pośrednika obiektu bazowego (create()

jest metodą zdefiniowaną w interfejsie obiektu bazowego).

2. Pośrednik przesyła wywołanie metody create() do zdalnego obiektu bazowego.

3. Obiekt bazowy wkracza do akcji i korzysta z dostępnych dla niego usług.

4. Zostaje utworzony i zainicjalizowany obiekt EBJObject dla komponentu danego typu.

5. Inicjalizowany jest sam komponent.

6. Do klienta przesyłany jest pośrednik obiektu EJBObject, za pomocą którego klient może

wywoływać metody biznesowe zdefiniowane w interfejsie komponentu.

klient

komponent

usłu

gi

pośrednik


Obiekt bazowy

obiektbazowy

Obiekt bazowy

❷❶

❻ ❸

❺❹


Przegląd architektury — tworzenie bezstanowego

komponentu session bean

#��! ��!��"��!�� '�� !��'��

create()$�4�� !�� "��!��%��'�

��!�EJBObject�� "�� '��!� ��D

&�� !��'��!��"��

��!�EJBObject �� $



pula komponentów

1. Klient wywołuje metodę create() pośrednika obiektu bazowego (metoda create()

jest zdefiniowana w interfejsie bazowym).

2. Pośrednik przysyła wywołanie metody create() do zdalnego obiektu bazowego.

3. Obiekt bazowy wkracza do akcji i korzysta z dostępnych dla niego usług.

4. Tworzony jest obiekt EJBObject, który będzie obsługiwać żądania zgłaszane przez danego klienta.

5. Komponent cały czas pozostaje w puli! Jest z niej pobierany wyłącznie w celu obsługi wywołania metody

biznesowej, jeśli oczywiście klient wywoła tę metodę, używając do tego pośrednika obiektu EJBObject.

6. Do klienta przesyłany jest pośrednik obiektu EJBObject, za pomocą którego klient może wywoływać

metody biznesowe zdefiniowane w interfejsie komponentu.

klient

komponent

usłu

gi

pośrednik


Obiekt bazowy

obiektbazowy

Obiekt bazowy

❷❶

❻ ❸ ❺

❹


Kto i kiedy tworzy bezstanowe

komponenty session bean

W pierwszej kolejności musimy zdefiniować, co w tym przypadku oznacza słowo„tworzy”. W przypadku komponentów session bean oznacza to fizycznestworzenie i zainicjalizowanie egzemplarza komponentu. Jednak musisz widzieć,że w odniesieniu do komponentów entity bean to samo słowo oznacza zupełnie coinnego, dlatego też poniższe rozważania dotyczą tylko i wyłącznie komponentówsession bean. W dalszej części książki wyjaśnimy co oznacza tworzeniekomponentów entity bean.

W przypadku stanowych komponentów session bean proces ich tworzenia jestrozpoczynany przez klienta. To klient wywołuje metodę create() pośrednikaobiektu bazowego i właśnie to wywołanie rozpoczyna wszystkie kolejne operacje— utworzenie i zainicjalizowanie obiektu EJBObject dla przyszłegokomponentu, a następnie utworzenie samego komponentu i skojarzenie goz jego strażnikiem — obiektem EJBObject.

Jednak w razie korzystania z bezstanowych komponentów session bean obieoperacje — wywołanie przez klienta metody create() oraz samo stworzeniekomponentu — nie są ze sobą powiązane. Innymi słowy, fakt wywołania przezklienta metody create() pośrednika obiektu bazowego wcale nie oznacza,że od razu zostanie utworzony sam komponent.

Bezstanowe komponenty session bean nie są tworzone aż do momentu, gdykontener uzna, że taki komponent jest mu potrzebny; a to oczywiście zależywyłącznie od kontenera. Na przykład, kontener może utworzyć kilkakomponentów i umieścić je w puli jeszcze zanim jakikolwiek klient zdążypoprosić o jeden z nich (wywołując metodę create() pośrednika obiektubazowego). Równie dobrze kontener możne tworzyć komponenty „na żądanie”— czyli nie zawracać sobie głowy ich tworzeniem aż do momentu gdy klientfaktycznie wywoła metodę biznesową.

126 Rozdział 2


No dobra. Zatem komponent jestpobierany z puli wyłącznie w przypadku

gdy klient wywoła metodę biznesową, ale… jakkomponent w ogóle znalazł się w tej puli?

Przecież nie został utworzony kiedy klient wywołałmetodę create()… Co zatem spowodowało

utworzenie komponentu?


Bezstanowe komponenty session bean

są bardziej skalowalne

Klienty nie współdzielą obiektów EJBObject, jednak ten sam komponentmoże obsługiwać wywołania metod biznesowych zgłaszane przez wwiieelleeobiektów EJBObject. Jeden komponent może zatem obsługiwać wieleklientów, o ile w danej chwili tylko jeden klient wywołuje metodę biznesową.



Komponent jest pobierany z puli

TYLKO I WYŁĄCZNIE gdy klient

wywoła metodę biznesową,

używając do tego pośrednika

obiektu EJBObject. A zatem,

jeden komponent może być

pobrany z puli, by obsłużyć

wywołanie metody zgłoszone

przez jednego klienta, następnie

może wrócić do puli i ponownie

zostać z niej pobrany, by

obsłużyć wywołanie zgłoszone

przez zupełnie innego klienta…

i tak dalej…

Klient pierwszy

Klient drugi

Serwer

klient

pośrednik

obiektEJBObject

obiektEJBObject

pośrednik

Obiekt bazowy

klient

pośrednik

obiektbazowy

Obiekt bazowy

pula komponentów

komponent

pośrednik

Obiekt bazowy


5�� '�� !��

�� !�� !�%��

�� !��!��

�� %��"��

� ��

5�� '��

��'%�� !��

128 Rozdział 2




P. Jest coś, co mnie NAPRAWDĘdenerwuje… dlaczego mamy interfejskomponentu i interfejs obiektu bazowego,skoro zdalne obiekty są nazywaneobiektami bazowymi i obiektamiEJBObject? Dlaczego nie ma po prostuinterfejsu EJBObject i interfejsuHomeObject? Albo, jeszcze prościej,interfejsów Home i EJB? Skąd teniespójności?

O. Cóż… to jest coś, co także nas wyprowadzaz równowagi. Ale przyzwyczaisz się do tego. I takpowinieneś być zadowolony, że nie uczyłeś się wersjitechnologii EJB wcześniejszych niż 2.0, w którychinterfejsy te były nazywane po prostu Home i Remote.To dopiero był problem, gdyż w rzeczywistości,w rozumieniu technologii RMI, oba były interfejsami typuRemote (czyli dziedziczyły po interfejsiejava.rmi.Remote). Po drugie, w EJB 2.0 interfejsy tewcale nie muszą być… interfejsami typu Remote.Właśnie dlatego trzeba było zrezygnować ze stosowanianazwy Remote i zmienić ją na „interfejs komponentu”.Wszystko będzie dobrze, jeśli uda Ci się zapamiętać,że interfejs komponentu to ten, w którym sądefiniowane metody biznesowe, a interfejs obiektubazowego to ten, w którym są definiowane metody…hm… bazowe. Po prostu zapamiętaj proste równanie:komponent = biznes = EJBObject(lub EJBLocalObject, ale tym zajmiemy sięw następnym rozdziale).

P F 9��

��'%�� !��

��$

P F &��2��3��'%��

�� !��

��

��!��$

P F 3� ��

�� %�� '��

�� create()��!�� '�$

P F 9��

�%�� '��

��create() ��"��

��!�� '�$

P F ��"��

��!�EJBObject��

��'�� !��

��!��

��$

P F ��"��

��

�� '�

��!��

!��

��$

P F &�� !��

��

EJBObject$

Przygotuj ołówek

6�� *�E�#�E�#�E�#�#


P. Jak działają te pule? Czy jestjedna pula dla wszystkichkomponentów, czy jedna dla wszystkichkomponentów konkretnego typu?

O. W praktyce nie wiemy jakierozwiązanie zastosowano w kontenerze,jednak można sobie wyobrazić, że istnieje jednapula dla każdego typu komponentu. A zatem,gdybyś wdrożył dwa bezstanowe komponentysession bean, na przykład: PoradaBean orazPrognozaPogodyBean, to dla każdegoz nich zostałaby utworzona odrębna pula.

P. Czy każdy bezstanowykomponent session bean ma swójwłasny obiekt EJBObject?

O. Poniekąd. Bezstanowe komponentysession bean nie potrzebują strażników, aż domomentu gdy zaczną realizować wywołaniemetody biznesowej. A zatem, klient otrzymujereferencję do obiektu EJBObject, jednakobiekt ten nie jest kojarzony z komponentemaż do chwili gdy klient wywoła metodębiznesową. W tym momencie komponent jestpobierany z puli, by obsłużyć wywołanie.Jak widać, obiekt EJBObject, którymdysponuje klient może współpracowaćz komponentami konkretnego typu(na przykład: DoradcaBean lubPrognozaPogodyBean), a niez konkretnym egzemplarzem komponentu.

P. Dlaczego stanowe komponentysession bean nie są przechowywanew pulach?

O. Czy zastanawiałeś się nad tymzagadnieniem w ćwiczeniu „Wysil szarekomórki” na poprzedniej stronie? Jeśli sięnie zastanawiałeś, to nie czytaj dalszejczęści tej odpowiedzi aż do chwili gdywymyślisz jakieś własne propozycje. Jeśliczytasz dalszą część tego akapitu, oznaczato, że jednak przemyślałeś zagadnienie,

znasz odpowiedź na postawione pytanie,a my jedynie ją potwierdzimy…

Pamiętaj, że stanowe komponenty sessionbean przechowują stan interakcji z klientem.Oznacza to, że komponent musiprzechowywać stan klienta (innymi słowy,musi pamiętać pewne informacje dotycząceklienta) pomiędzy kolejnymi wywołaniamimetod realizowanymi przez tego samegoklienta.

Wyobraź sobie ponownie koszyk na zakupy —komponent stanowy obsługujący taki koszykmusi pamiętać co jest w koszyku za każdymrazem gdy klient wywoła metodędodajTowarDoKoszyka(). Z drugiejstrony, komponent bezstanowy nie musipamiętać żadnych informacji związanychz klientem; dlatego też, z punktu widzeniaklienta, poszczególne komponenty bezstanowe(konkretnego typu) absolutnie niczym sięmiędzy sobą nie różnią i klient może skorzystaćz każdego z nich.

Jeśli komponent DoradcaBean zwracaporadę w żaden sposób nie związanąz poradami, które komponent zwróciłwcześniej (jak również, która nie zależy odniczego, o czym komponent dowiedział się odklienta), to nie ma żadnego powodu, by byłon komponentem stanowym. W tymprzypadku, za każdym razem gdy klientwywoła metodę getPorada()zdefiniowaną w interfejsie komponentu(używając w tym celu obiektu EJBObject),będzie ją w stanie wykonać dowolnykomponent DoradcaBean.

Z drugiej strony, gdyby komponentDoradcaBean został zmodyfikowany w takisposób, by zwracał losową, lecz niepowtarzającą się poradę, to DoradcaBeanmusiałby być komponentem stanowym, gdyżtylko w ten sposób mógłby przechowywaćinformacje o poradach udzielonych wcześnieji nie powtarzać się.

P. Jak długo stanowy komponentsession bean przechowuje informacjeo stanie związane z konkretnymklientem?

O. Jedynie przez okres trwania sesji.Sesja trawa do momentu gdy klientpoinformuje komponent, iż zakończył używaćkomponentu (co może zrobić, wywołującmetodę remove() dostępną w interfejsiekomponentu) lub do momentu wystąpieniaawarii serwera bądź do upłynięcia limitu czasuistnienia komponentu (tym zagadnieniemzajmiemy się w rozdziale poświęconymkomponentom session bean).

P. A zatem, stanowe komponentysession bean nie są skalowalne?

O. Nie, takie komponenty są skalowalne.Jednak nie zapewniają równie dużejskalowalności, co komponenty bezstanowe.

P. Ale jak to możliwe, że stanowekomponenty session bean są skalowalne,skoro zawsze dla jednego klienta musiistnieć jeden taki komponent?

O. To prawda, że dla każdego klienta musiistnieć jeden komponent, lecz nie każdykomponent musi aktywnie korzystaćz zasobów. Jeśli pomiędzy kolejnymiwywołaniami metod biznesowych stanowegokomponentu session bean zgłaszanymi przeztego samego klienta występują długie odstępyczasu, to komponent może być chwilowowprowadzony w stan dezaktywacji (ang.passivation). Ten stan pozwala na zachowanieinformacji o kliencie (co jest oczywiste) przyjednoczesnym zmniejszeniu liczbykomponentów istniejących na serwerze.Komponent wyjdzie ze stanu dezaktywacjii ponownie przystąpi do pełnienia swychobowiązków (czyli będzie aktywny), kiedy klientzgłosi wywołanie metody biznesowej.






— komponenty message-driven bean

&�� %�� '��?��!��@$

6 �� %��(�� +�

�� !��$

�� '��!��%��!�� '��

��!�EJBObject$�)��%��!��!�� '��!

��!$

130 Rozdział 2

Przegląd komponentów message−driven bean

1. Klient przesyła komunikat do usługi JMS.

2. Usługa JMS dostarcza komunikat kontenerowi.

3. Kontener pobiera z puli komponent message-driven bean.

4. Kontener przekazuje komunikat do komponentu (wywołując jego metodę onMessage()

należącą do interfejsu MessageListener).

klient

komponent

usłu

gi

pula komponentów

komponent

JMS (Java Messaging Service)

❷❶

❸❹


Gdzie umieścić poszczególne elementy?

/��"�� '��1��

�� !��!�� "��(��

��+$�)��*�� !� ��

��"�� 8� �� "�(��!��+�

��' �� :��!��D



klient serwer

pośrednik

obiektEJBObject

pośrednik

Obiekt bazowy

obiektbazowy

Obiekt bazowy

bazadanych

komponentklasa klienta

klasa komponentu

klasa pośrednikaobiektu bazowego

interfejs EJBObject

klasa obiektu bazowego

Rozwiązaniaćwiczeń


Zorganizuj swoje komponenty

/ !�� !�� %�� (�� 1��"��+

� �� !��

��'��!��!$��%� �� "�� 7��$��"�� "

�� ! !��

�� $�4��!�� !�� '��$�)��

1�� 8� �� !�� %�� "�$�4��

�� $�(#� �� !�?<��@$+

132 Rozdział 2

Tabela komponentów

Ćwiczenia

Wraz z nimi są używane pule.

Wiele klientów może miećreferencje do tego samegokomponentu.

Mamy gwarancję, że przetrwająawarię serwera.

Mają widok klienta.

Pozwalają na komunikacjęasynchroniczną.

Reprezentują proces.

Reprezentują „rzeczy” w trwałym magazynie (na przykład, w bazie danych).

Bezstanowekomponentysession bean

Stanowekomponentysession bean

Komponentyentity bean

Komponentymessage-driven

bean Tak. Ponieważ nieprzechowują żadnychinformacji skojarzonychz konkretnym klientem,nie trzeba mieć jednegotakiego komponentu dlakażdego klienta.


Gdzie umieścić poszczególne elementy?



Ćwiczenia

)��*�� % �� %

��$�7��"��,F��%�! !�� $�

�� "��!� �� '�"��

��%�� "��%$

klient serwer

pośrednik

obiektEJBObject

pośrednik

Obiekt bazowy

obiektbazowy

Obiekt bazowy

bazadanych

klasa klienta

klasa komponentu

klasa pośrednikaobiektu bazowego klasa pośrednika

obiektu bazowego

interfejs EJBObject

interfejs EJBObject

klasa obiektu bazowego

komponent


=�� "��$�,��

��

��

��' ��8

��'��' ��!$

5��8�� !��

��1��

�!��>

134 Rozdział 2

Architektura EJB

Ech bracie… Ten rozdział tobyła prawdziwa gehenna. Czy moglibyśmy pominąć w nim pytania

egzaminacyjne? Przyrzekam, że sumienniewykonam je we wszystkich następnych

rozdziałach.


Head First EJB. Edycja polska

Documents

Transcript of Head First EJB. Edycja polska