12   Verteilte Objekte (RMI)

Inhalt

Literatur: Eine Einführung findet sich im Nutshellbuch [FFCM99] über Javas sogenannte Enterprise-Klassen (Kapitel 3, 8 und 13). Einiges ist anscheinend auch in [Har97] enthalten. Schließlich noch [Lea99].

• bisher: richtig verteilte Berechnungen Anwendungen | bis auf das low-Level Client/Server-Modell | haben wir noch nicht kennengelernt, nur
  • verteilten Code (distributed code) ¹ verteilte Programmierung mittels Applets
  • (hauptsächlich) Lesen verteilter Daten durch das Laden von File-Urls
  • quasi-parallele Ausführung durch mehrere Threads
• echte Verteilung:

  Methodenaufruf an Objekten auf anderen Maschinen

• Pakete (³ Java 1.1)
  

  java.rmi	Remote interface und Exception
  java.rmi.server	u.a. remote Objects
  java.rmi.dgc	Distributed GC
  java.rmi.registry	Verwaltung von RO's

• gehört zu den Enterprise-Klassen.⁷³

• im Folgenden: Server: (Java)programm, welches Methoden über's Netz anbietet, Klienten sind die Aufrufer
• ein klein wenig wie die Client/Server auf den Sockets, aber
• wichtigste neue Zutat: Aufruf von Methoden an Objekten mit ihrem Namen anstelle von Kommunikation mit Ports!
• Bestandteile:
  • Remote Interface: legt die von Ferne zugreifbaren Methoden fest: Subinterface von rmi.Remote
  • Server: implementiert das Interface
  • Nameservice: eigenes Programm/Dämon rmiregistry
  • Klient: erkundigt sich beim Nameservice nach den Servern

---

Figure 6: Remote method invocation

---

• remote interface
  • Erweiterungen des (leeren) Interface java.rmi.Remote⁷⁴ Þnur die Methoden die in einem remote Interface spezifiziert sind, sind auch von Ferne zugreifbar.
  • alle Methoden des Interfaces: throws RemoteException notwendig
  • die Schnittstelle muß public sein
  • die Remote Objects: deklariert als Implementierungen der remote interfaces (nicht ihrer Implementierungsklasse!)⁷⁵
  
  
• Implementierung eines RI:
  • Klasse, deren Instanzen die verteilten Methoden zur Verfügung stellen
  • (meist) Erweiterungen von UnicastRemoteObject
  • (Sicherheitsregistratur java.rmi.RMISecurityManager)

• separater Serverprozeß (= außerhalb des Interpreters)
  • Start mit rmiregistry &: Dämonprozeß⁷⁶
  • rmiregistry läuft unabhängig vom Javacompiler/Javaprogrammen, also Obacht beim Starten innerhalb Javas (LocateRegisty.createRegistry())
• Klasse java.rmi.Naming: dient zur Kommunikation mit dem Registrationsdämon und zur Namensverwaltung
• Beispiel:

  Naming.bind("//snoopy/ServiceName", instanz);
  

  • snoopy = Rechner.⁷⁷, ServiceName: Name (String) unter dem der Service bekannt ist, es muß nicht der Name der Klasse sein
  • instanz:
    • Referenz des remote objects
    • Instanz des UnicastRemoteObject und
    • Implementierung des RemoteInterface
    • oft stub
• rebind(): dasselbe, aber es ersetzt ggf. einen Service
• Lebenszeit der Dienste:
  • solange rmiregistry läuft
  • bis Naming.unbind()

• Client/Server Kommunizieren nicht direkt
• Dem Server muß noch vorgespiegelt werden, daß er lokal aufgerufen wird Þ
• Programm rmic: fügt dem kompilierten Kode (für den Server) zwei neue Klassen hinzu:

       Server_Stub.class
       Server_Skel.class
  

• Stub und Skeleton dienen als Fassade für das RO.
  1. Klient ruft in Wirklichkeit Stub-objekt auf
  2. Stub leitet es an Skeleton-Objekt weiter
  3. Skeleton leitet es weiter an das Server-Objekt (und ggf. zurück)

• Im Gegensatz zum Server: Klientenseite ist einfach
• Lokalisieren des Objektes mittels des rmiregistry-Dämons und Naming.lookup:

  ServiceInterface ro =             // Interface, nicht der Server!
    (ServiceInterface)Naming.lookup("//snoopy/ServiceName");
    ...
    ro.method(...);                // Methode des Interfaces