Um ein Jini-Netzwerk funktionsfähig auf die Beine zu stellen, müssen zuvor einige Voraussetzungen erfüllt sein:  
   
 

Erzeugen eines policy-Sicherheitsfiles:

  • Das java.policy-file dient zur spezifischen Definition auf Dienste zutreffender Sicherheitsrichtlinien.
  • Der hier verwandte Quellcode berechtigt zum Vollzugriff ohne jegliche Beschränkung. Die Implementierung wird in den jeweiligen Quellcodes dargestellt.

Quellcode des policy.all-files:

grant { permission java.security.AllPermission "", ""; };

 
   
  Wir empfehlen, jeden der nun folgenden Quellcodes in eine eigene batch-Datei einzutragen. Diese müssen dann in der aufgelisteten Reihenfolge am DOS-Prompt gestartet werden.  
   
 

Setzen des Klassenpfades:

  • Um mit dem Jini-System programmieren zu können, muss der Zugriff auf drei jar-Dateien, die dem Jini-Starter-Kit entsprechen, gewährleistet sein:
    jini-core.jar - enthält die Jini-Kerntechnologie
    jini-ext.jar - enthält Erweiterungs- und Dienstprogramm-Interfaces
    sun-util.jar - enthält die zum Jini Software Kit gehörenden Helferklassen
  • Diese Dateien befinden sich im jeweils spezifischen lib-Verzeichnis des Jini Starter Kit, und müssen über das Setzen des Klassenpfades zugänglich gemacht werden.
  • Neben der Möglichkeit, den Klassenpfad jeweils aktuell über das Aufrufen einer entsprechenden batch-Datei zu setzen, kann der unten aufgeführte Quellcode auch in die autoexec.bat eingetragen werden. (nicht bei Windows 2000 !!)

Quellcode zum Setzen des spezifischen Klassenpfades:

set JINI_HOME=h:\jini1_1
set JINI_LIB=%JINI_HOME%\lib
set CLASSPATH=.;%JINI_LIB%\jini-core.jar;%JINI_LIB%\jini-ext.jar;%JINI_LIB%\sun-util.jar

 
   
 

HTTP -Server:

  • Zum Betrieb von Jini ist ein Netzwerk erforderlich. Welche Art von Netzwerk das ist, ist grundsätzlich irrelevant, es werden von den JVMs momentan jedoch nur TCP/IP-Netze unterstützt.
  • Das Protokoll, über das Jini den Lookup-Service entdeckt, muss multitaskingfähig sein.
  • Java muss im gesamten Netzwerk aktiv sein, da der Lookup-Service auf Java arbeitet.
  • Dienste laufen entweder auf einer JVM, oder auf einer JVM als Proxy.
  • Die Netzwerkkomponenten, auf denen die JVM präsent ist, müssen im Netz angemeldet sein. In einem TCP/IP-Netz kann dies durch DHCP (Dynamic Host Configuration Protocol), oder durch eine direkte Vergabe von TCP/IP-Adressen erfolgen.
  • Hierdurch wird eine Protokollneutralität in Bezug auf das verfügbare Netzwerk gewährleistet.
  • Clients bekommen von Jini mittels Objektserialisierung den Proxy übergeben, der den Jeweiligen Dienst repräsentiert. Bei der Implementierung von SUN enthalten die Proxys sogenannte RMI-Rümpfe, die in der Lage sind, mit dem jeweiligen Dienst Kontakt aufzunehmen.
  • RMI erfordert einen Mechanismus, der an Clients Klassendateien ausliefert, die über die diese pfadspezifisch nicht verfügen. Dies geschieht über den Webserver.
  • Für die grundlegenden Jini-Dienste müssen die Clients Klassen aus dem installierten lib-Verzeichnis herunterladen können. Dies wird durch den HTTP-Dienst realisiert.

Quellcode eines einfachen HTTP-Servers:

java -jar c:\jini1_1\lib\tools.jar -port 8081 -dir c:\jini1_1\lib -verbose

Hierdurch wird ein HTTP-Server auf dem Port 8081 des Rechners installiert.

 
     

RMI (Remote Method Invocation) - Aktivierungsdämon:

  • RMI ist eine Möglichkeit, durch die Objekte, die auf unterschiedlichen JVMs vorhanden sind, aufeinander Methoden aufrufen können.
  • RMI stellt ein verteiltes Objektsystem dar,bei dem ein Server die Referenzen einzelner Objekte, die auch Remote-Objekte genannt werden,exportiert. Erhält ein Client Referenzen diverser Remote-Objekte, kann er auf ihnen Methoden aufrufen.
  • Der Aufruf einer Methode erfolgt nicht auf dem Remote-Objekt, sondern auf der VM des Servers.
  • Parameter des Methodenaufrufs werden vom RMID zusammengestellt, und vom Client an den Server geschickt, welcher die Methode ausführt.
  • Rückgabewerte werden vom RMID aufgenommen, und an den Client zurückgeschickt.
  • RMI ermöglicht Ausnahmebehandlung:
    Tritt beim Ausführen der Methode ein Fehler auf, gibt RMID eine Ausnahme an den Client zurück.
  • Logbuchführung durch RMID:
    Es wird ein log-file im RMID-Verzeichnis oder an zuvor definierter Stelle angelegt. Hier sind alle angemeldeten Dienste registriert. Wird der Dämon beendet, enden alle in ihm registrierten Dienste. Ebenso wird das System mit allen zuvor registrierten Diensten reaktiviert, wenn RMID neu gestartet wird. Dies geschieht ohne eine neuerliche Eintragung der Dienste.
  • Ist beim Neustart das Logfile gelöscht, beinhaltet RMID keinerlei Einträge, und kein zuvor registrierter Dienst wird gestartet.
  • RMID erzeugt für jeden registrierten Dienst eine neue VM, auf der der Dienst arbeitet, d.h. für jeden Dienst sind zwei VMs erforderlich: Die, die den Dienst registriert, und die, auf der der Dienst letztendlich läuft.
  • Beim RMID registrierte Dienste nennt man aktivierbare Dienste. Stürzt ein Dienst ab, startet RMID ihn neu.

Quellcode des RMID:

rmid -J-Dsun.rmi.activation.execPolicy=none
(hier: ohne Sicherheitsbeschränkung)

   

Jini-Lookup-Service

  • Jini spezifisch gesehen, stellt der Lookup-Service lediglich einen weiteren Dienst dar.
  • Funktionell lässt sich der Service mit einer Art Nameserver vergleichen, alle in der Jini-Gemeinschaft verfügbaren Dienste registrieren sich bei ihm.
  • Will eine Anwendung einen Jini-Dienst in Anspruch nehmen, findet sie ihn, indem sie beim Lookup-Service nach seiner Registrierung sucht.
  • Durch die Jini Lookup Service Specification ist das Dienstinterface des Lookup-Service definiert.
  • SUN liefert mit seiner Jini-Umgebung eine Lookup-Service-Implementierung mit dem Namen reggie und APIs, über die eine Interaktion mit dem Lookup-Service möglich ist. Dieses Dienst-Interface beschreibt die Operationsweise des Service.
  • Generell wird hier die Art und Weise definiert, wie Clients in einer Jini-Gemeinschaft Dienste anfordern, die ein spezielles Interface implementieren.
  • Eine client-Anwendung muss das Dienst-Interface kennen, welches siesucht, und erfragt dann beim Lookup-Service alle registrierten Dienste, die das definierte Dienst-Interface implementiert haben.
  • Der Lookup-Service gibt sog. Dienstobjekte für alle in ihm registrierten Dienste an den client zurück, die das angefragte Dienst-Interface implementieren.
  • Nun besitzt der client ein verteiltes Objekt, das den Dienst implementiert, und kann auf diesem Objekt Methoden aufrufen, die eine Interaktion mit dem entsprechenden Server ermöglichen.
  • Es können auch mehrere Instanzen eines Lookup-Services in einer Jini-Gemeinschaft betrieben werden. Dies führt zu einer Redundanz, die den Vorteil bietet, einen Lookup zur Verfügung zu haben, auch wenn ein anderer ausfällt.
  • Jini-Lookup-Services sind in sog. Gruppen organisiert. Man benennt hierzu den Service beliebig, z.B. "Labor01", analog hierzu werden die Dienste im entsprechenden Raum so konfiguriert, dass sie nur auf den lokalen Lookup-Service zugreifen können.
  • Ein client findet einen Lookup-Service durch den "Discovery-Prozess", welcher in der Jini-Discovery and Join Specification definiert ist. Hierdurch wird im Netzwerk das Protokoll festgelegt, mit dem clients den Lookup-Service lokalisieren können.
  • Es gibt zwei Arten des Discovery-Prozesses:
      • Multicast-Recovery:
        Hier wird vom Client eine Multicast-Abfrage ausgesendet. Alle Lookup-Services, die diese Abfrage sehen, antworten.
      • Unicast-Discovery:
        Stellt eine Abfrage nach einem speziellen Lookup-Service dar, der auf einem bestimmten Host mit einer speziellen Port-Nummer residiert.
  • Registriert sich ein Dienst bei einem Lookup-Service, so bekommt er von diesem einen sog. Lease zugewiesen. Ein Lease stellt sozusagen eine zeitlich beschränkte Nutzungsberechtigung dar. Jeder Dienst ist dafür verantwortlich, den Lease vor dessen Ablauf zu erneuern. Geschieht dies nicht, geht der Lookup-Service davon aus, dass der Dienst nicht mehr existiert, und stellt ihn in seinem Umfeld nicht mehr zur Verfügung.
    Eine Standard-Grössenordnung für einen Lease sind z.B. 5 Min.

Quellcode des Jini-Lookup-Services:

java -jar c:\jini1_1\lib\reggie.jar http://UNIMATRIX001:8081/reggie-dl.jar
c:\jini1_1\policy\policy.all
c:\tmp\reggie_log public