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