[ Pobierz całość w formacie PDF ]

była odtwarzalna po stronie serwera aplikacji. Konieczne jest zatem, dostępne w
Javie, zastosowanie mechanizmu serializacji (klasy obiektów muszą implementować
interfejs Serializable). Prawie wszystkie obiekty mogą być w ten sposób podlegać
konwersji, z wyjątkiem tych, które mają charakter lokalny (np. odnoszą się do plików
lokalnych). Przesyłanie obiektów poprzez ich kopie wykonywane jest również dla tych
obiektów po stronie serwera aplikacji (zdalnej), które nie implementują interfejsu
Remote, czyli są obiektami lokalnymi serwera lecz nie stanowią w świetle RMI
obiektów zdalnych. Podsumowując, możliwe są następujące formy przekazywania
argumentów i wyników działania metod:
- przez wartość: w komunikacji dwustronnej poprzez wartość przekazywane są
proste typy danych jak: int, boolean, iitp),
- przez referencję zdalną: w komunikacji klient -> serwer przekazywana jest zdalna
referencja zdalnego obiektu,
- przez kopię: - czyli również przez wartość  w komunikacji dwustronnej poprzez
kopie przekazywane są obiekty inne niż zdalne (tzn. te dziedziczące po interfejsie
Remote).
8.4.2 Komunikacja w procesie zdalnego wykonywania metod.
W celu analizy procesu komunikacji pomiędzy klientem a serwerem aplikacji
posłużmy się modelem zaprezentowanym na rysunku:
Rysunek 8.1. Model warstwowy procesu komunikacji w RMI
Z prezentowanego modelu widać, że logicznie oprogramowanie klienta pracuje tak,
jakby było bezpośrednio powiązane z programami serwera. W rzeczywistości
8-34
Jacek Rumiński - Język JAVA 
Jacek Rumiński - Język JAVA  Rozdział 8
Jacek Rumiński - Język JAVA 
Jacek Rumiński - Język JAVA 
komunikacja jest bardziej złożona. Klient wywołując metody zdalne używa
specjalnego obiektu  stub  będącego odpowiednikiem, lokalnym reprezentantem
obiektu zdalnego. Stub implementuje interfejs obiektu zdalnego dzięki czemu
posiada pełen opis (sygnatury) metod tego obiektu. Obiekt stub stanowi więc
namiastkę (stub jest często tłumaczony przez słowo namiastka) obiektu zdalnego po
stronie lokalnej. Wywoływane przez klienta metody zdalne są bezpośrednio
odnoszone do obiektu stub, a nie do obiektu zdalnego. Stub przekazuje dalej
wywołanie do warstwy zdalnych referencji. Głównym zadaniem tej warstwy jest
odniesienie lokalnych referencji obiektu stub do referencji obiektu zdalnego po
stronie serwera. Kolejnym krokiem jest przesłanie danych wywołania metody do
warstwy transportowej. Warstwa ta jest odpowiedzialna za przesyłanie danych przez
sieć i realizuje: ustalanie połączeń, śledzenie obiektów zdalnych, zarządzanie
połączeniem, itp. Po stronie serwera warstwa transportowa realizuje nasłuch danych
przenoszących żądanie wykonania metody zdalnej. Po uzyskaniu referencji obiektu
zdalnego, będącego teraz obiektem lokalnym serwera dane przekazywane są do
kolejnej warstwy o nazwie skeleton. Skeleton (namiastka) jest odpowiednikiem stub
a po stronie klienta. Warstwa ta odpowiada za przypisanie do wywoływanych metod
przez stub ich implementacji realizowanych w oprogramowaniu serwera. Po
wykonaniu zadania przez serwer ewentualne wyniki mogą być zwrotnie
transportowane do klienta (jako: wartości, kopie obiektów lub obiekty zdalne).
Zgodnie z zaprezentowanym modelem ważną rolę w procesie wymiany parametrów
odgrywają warstwy stub oraz skeleton. Nazwy stub oraz skeleton są tu przyjęte z
technologii RPC. Warstwy pośredniczą i sterują procesem wykonywania zdalnych
procedur. Jakkolwiek w wersjach Javy od JDK1.2 nie jest już wymagana oddzielna
realizacja (poza oprogramowaniem serwera) warstwy skeleton. Fizyczna realizacja
oprogramowania warstw stub a i skeleton u powstaje w wyniku generacji dla nich
kodu pośredniego Javy na podstawie klasy obiektu zdalnego. Generacja ta
wykonywana jest za pomocą dodatkowego kompilatora o nazwie rmic (RMI
compiler).
Powyższe rozważania nie uwzględniają problemu adresowania zdalnego serwera
aplikacji. Możliwe jest przecież, że w sieci istnieć będą tysiące komputerów
serwujących setki obiektów zdalnych (ich metod) każdy. Jak zatem zaadresować po
stronie klienta konkretny obiekt zdalny na konkretnym serwerze? Otóż w tym celu
tworzony jest mechanizm rejestracji obiektów zdalnych. RMI wykorzystuje w tym celu
interfejs java.rmi.registry.Registry oraz klasę java.rmi.registry.LocateRegistry do
obsługi (rejestracja obiektów i przeszukiwanie rejestru) rejestru obiektów zdalnych
poprzez przypisane im nazwy. Rejestr pełni zatem rolę prostej bazy danych wiążącej
ze sobą nazwy obiektów z ich realizacją. Przykładową realizacją rejestru
(implementująca interfejs Registry) jest program dostarczany przez Suna 
rmiregistry, który po wywołaniu pracuje na danym komputerze na domyślnym porcie
dla RMI zdefiniowanym w interfejsie Registry:
public static final int REGISTRY_PORT = 1099.
Oczywiście można podać jako argument do programu rmiregistry inny numer portu,
należy jednak pamiętać o konsekwencjach tego posunięcia, czyli o właściwym
adresowaniu rejestru z poziomu programów go użytkujących. Lokalizacja rejestru jest
obsługiwana przez metody klasy LocateRegistry. Użytkowanie rejestru odbywa się
poprzez zastosowanie metod klasy java.rmi.Naming. Metody tej klasy wykonując
8-35
Jacek Rumiński - Język JAVA 
Jacek Rumiński - Język JAVA  Rozdział 8
Jacek Rumiński - Język JAVA 
Jacek Rumiński - Język JAVA 
operacje na rejestrze odwołując się pośrednio przy pobieraniu referencji do rejestru [ Pobierz całość w formacie PDF ]