SOP322/ćw - temat F1

Obiekty rozproszone RMI w języku Java.
RMI = Remote Method Invocation

literatura i inne materiały ...

• ogólny opis RMI http://java.sun.com/j2se/1.4.2/docs/guide/rmi/index.html
• opis "dynamicznego ładowania klas" http://java.sun.com/j2se/1.4.2/docs/guide/rmi/codebase.html
• Orfali, Harkey, "Client/Server Programming with Java and Corba", rozdział 13, str 281-312

Krótki opis technologii RMI

• Obiekty RMI to odległe obiekty rezydujące na odległych maszynach.
• Klient na lokalnej maszynie może wywoływać metody obiektów RMI tak jakby to były zwykłe lokalne obiekty.
• Obiekty RMI są tworzone przez serwer działający na odległej maszynie.

.....................................................................................................................

• Klientowi "wydaje się" że odwołuje się do odległego obiektu, a w rzeczywistości odwołuje się on do lokalnego obiektu zwanego pieńkiem (ang. stub). Klasa pieńka jest tworzona przy pomocy kompilatora rmic na podstawie klasy implementującej interfejs obiektu RMI (patrz niżej).
• Podobnie obiekt RMI kontaktuje się bezpośrednio z tzw szkieletem (?) (ang. skeleton), także tworzonym przy pomocy kompilatora rmic.

.....................................................................................................................

• Obiekty RMI mogą być dostępne poprzez nazwę przy pomocy usługi nazewniczej (ang. Naming Service) rmiregistry.
• Klient może zwrócić się do rmiregistry i otrzymać odniesienie (referencję) do odległego obiektu RMI na podstawie podanej nazwy tego obiektu.
• Serwer obiektu RMI musi wcześniej utworzyć, wyeksportować i zarejestrować obiekt w rmiregistry.

.....................................................................................................................

public interface OdleglyObiekt extends Remote
{
   int powolnaMetoda(int skok) throws RemoteException;
}

.....................................................................................................................

Serwer musi zawierać klasę implementującą interfejs OdległyObiekt:

class OdleglaKlasa
implements OdleglyObiekt, Serializable
{
   // konstruktor 
   OdleglaKlasa(String s) throws RemoteException
   {
      super();
      try {
        UnicastRemoteObject.exportObject(this);
          // eksportujemy obiekt
          // dzięki temu obiekt będzie "odległy"
          // (exportObject() musi byc PRZED rebind())

        Naming.rebind(s,this);
          // rejestrujemy obiekt w rmiregistry

      } catch(Exception e) {
        System.err.println("sss: OdleglaKlasa(String); blad !!! "+e.getMessage());
   }
  
   // implementacja interfejsu OdleglyObiekt
   private int licznik=0;
   public int powolnaMetoda(int skok) throws RemoteException
   {
      for(int i=0; i<10; i++) {
        licznik=licznik+skok;
        System.out.println("sss: powolnaMetoda(); licznik="+licznik);
        try {Thread.sleep(100);} catch(Exception e){};
      }
      return licznik;
   }
}

.....................................................................................................................

Serwer musi wykonać następujące czynności:

1. utworzyć obiekt - robi to w metodzie sss.main,
2. wyeksportować go - robi to w konstruktorze OdleglaKlasa; eksportowanie obiektu powoduje że staje się on odległym obiektem (gdyby nie został wyeksportowany to odwołania klienta do tego obiektu spowodowałyby kopiowanie obiektu od serwera do klienta i obiekt stałby się lokalny !)
3. zarejestrować w rmiregistry - robi to także w konstruktorze OdleglaKlasa.
4. po wykonaniu tych czynności serwer nie kończy działania lecz oczekuje na klientów

public class sss
{
   public static void main(String args[])
   {
     //System.setSecurityManager(new RMISecurityManager());
       // chwilowo nie używamy SecurityManagera !

     try {
       OdleglyObiekt oo= new OdleglaKlasa("moj_obiekt");
         // tworzymy obiekt

     } catch(Exception e) {
       System.err.println("sss: blad !!! "+e.getMessage());
     }
   }
}

Uwaga 2: Jeśli NIE dziedziczymy z UnicastRemoteObjecta to powinniśmy samodzielnie przedefiniować w OdleglaKlasa niektóre metody klasy Object: hashCode, equals, toString [w podanych przykładach tego się nie robi ...]; patrz też klasa RemoteObject.

.....................................................................................................................

Klient musi wykonać następujące czynności:

1. uzyskać referencję do obiektu RMI
2. wywoływać metody na rzecz obiektu RMI

Powinien istnieć pomocniczy obiekt RMI "TwórzOdległeBufory" dostępny przez nazwę "producent_konsument" w rmiregistry, zawierający metodę:

OdleglyBufor nowyOdległyBufor()
  // mogą z niej korzystać dwa wątki tego samego procesu ...

tworzącą obiekty OdległyBufor na żądanie.
Przygotuj eksperyment pokazujący że to wszystko działa. Do sprawozdania wstaw kody źródłowe klas oraz wydruki eksperymentów ...

Zadanie 91a (*)

która pozwala korzystać z bufora dwóm różnym procesom (dostają się od tego samego buforu podając tę samą nazwę).

.....................................................................................................................

Dynamiczne ładowanie potrzebnych klas w RMI - java.rmi.server.codebase

Opis dynamicznego ładowania klas z dokumentacji java.sun.com.

Wstępne przypomnienie pewnych cech języka Java:

• mobilność kodu; można ściągnąć kod klasy np z Internetu, następnie utworzyć obiekt tej klasy i używać go; istnieją wyrafinowane mechanizmy bezpieczeństwa które zapewniają że obcy kod nie wykona niebezpiecznych operacji (SecurityManager).
• właściwości; właściwość ma nazwę i wartość; program w Javie może wyświetlić dostępne właściwości np tak:
          Properties props= System.getProperties();
          props.list(System.out);
  można zdefiniować właściwość podczas uruchamiania programu:
          java -Dnazwa_właściwości=wartość_właściwości klasa_główna
• SecurityManager zapewnia że aplikacja nie wykona niebezpiecznych operacji; korzysta on z tzw "polityki", specjalnego pliku definiującego co wolno robić aplikacji; przykładowo taka polityka:
          grant { permission java.security.AllPermission; };
  daje aplikacji wszystkie możliwe prawa;
  plik z polityką podaje się przy uruchamianiu aplikacji, za pomocą właściwości java.security.policy w taki sposób:
          java -Djava.security.policy=plik.polityka klasa_główna
  SecurityManager musi zostać włączony na początku metody main:
          System.setSecurityManager(new RMISecurityManager());
             // w tym przypadku włączamy specyficznego Security Managera związanego z RMI ...

Klient i serwer aplikacji RMI muszą mieć dostęp do kodu wielu klas, przykładowo:

• klient musi mieć dostęp do kodu klasy pieńka
• klient i serwer muszą mieć dostęp do wszystkich klas używanych pośrednio i bezpośrednio w argumentach i w zwracanych wartościach metod interfejsu odległego obiektu (patrz też tutaj)
   

Aby mechanizm ten działał należy:

1. serwer musi podać URL z którego mogą być ładowane klasy serwera (w szczególności pieniek); URL podaje się w właściwości java.rmi.server.codebase, np w taki sposób:
           java -Djava.rmi.server.codebase=file:///D:\Java\jdk1.2.2\Przyklad\rmi4a\SERWER\ klasa_serwera
               // pod Windows
           java -Djava.rmi.server.codebase=file:///home/mhanckow/katalog/ klasa_serwera
               // pod Linux-em
           java -Djava.rmi.server.codebase=http://qqq.www.eee/~jkowalski/moje_klasy klasa_serwera
2. podobnie klient musi podać URL do swoich klas (np klas obiektów przekazywanych jako parametry metod odległego obiektu)
3. jeżeli klient i serwer NIE pracują na tej samej maszynie i nie mają dostępu do tego samego systemu plików to trzeba się posłużyć jakimś niezależnym sposobem kopiowania plików, np serwerem httpd lub ftp (wtedy użyjemy codebase=http://...);
4. rmiregistry MUSI być tak uruchomione żeby NIE MIAŁO(!!!) dostępu do klas serwera poprzez CLASSPATH
5. interfejs odległego obiektu koniecznie musi mieć słowo "public" (!!!)
6. [implementacja mechanizmu dynamicznego ładowania klas] gdy obiekt jest przesyłany przez sieć to towarzyszy mu informacja GDZIE można znaleźć kod klas tego obiektu, informację tę definiujemy właśnie w codebase ...

.....................................................................................................................

Zadanie 92 (*)

PrzykladowaKlasa Eksperyment1(PrzykladowaKlasa pk1, PrzykladowaKlasa pk2);

PrzykładowaKlasa powinna zawierać jakieś dane i metodę pokaz() wyświetlającą te dane; ponadto konstruktor powinien wyświetlać napis informujący o swoim uruchomieniu. Niech klient uruchamia tę metodę podając jako parametry obiekt klasy PrzykładowaKlasa, oraz obiekt podklasy PrzykładowaKlasa o nazwie PrzykładowaKlasa2. Metoda Eksperyment1() powinna uruchamiać pokaz() dla swoich parametrów, podobnie klient powinien uruchomić pokaz() dla obiektu zwróconego przez Eksperyment1().
Klasy których potrzebują klient i serwer powinny być dynamicznie ściągane przy pomocy mechanizmu "codebase". Należy wykorzystać serwer atos i katalog html_public i w nim (w odp podkatalogach) umieścić wszystkie potrzebne klasy. Proszę spróbować uruchomić klienta i serwera na innych maszynach (np na lokalnym linixie i na atosie, ew na 2 lokalnych linuxach). Do sprawozdania proszę oprócz kodu w Javie wstawić także wydruki eksperymentów dowodzące że wszystko działa poprawnie ...

Zadanie 93 (*)

void WstawElement(Object el) 
Object PobierzElement() 

Koniecznie użyj mechanizmu "codebase" do kopiowania klas. Zaprojektuj odp przykłady pokazujące że Twoje rozwiązanie działa poprawnie ...