- Das Discovery/Join-Protokoll [1]
sorgt zunächst für die Einbindung des Gerätes, bzw. des
Dienstes in den djinn: wird ein Jinifähiges Gerät physikalisch
mit dem Netz verbunden, so sendet dieses typischerweise als erstes ein
sog. „multicast Discovery"Paket (quasi einen Rundruf ins Netz),
um einen Lookup-Service zu finden. Dieser meldet sich daraufhin bei
dem Gerät. Danach teilt das Gerät dem Lookup-Service Informationen
über den bereitgestellten Dienst mit und sendet insbesondere ein
JavaApplet (sog. „Proxy") an den Lookup-Service, das später
die Kommunikation mit dem Gerät selbst implementieren wird (Fußnote:
Im Falle eines Druckers würde dieser Proxy u.a. den Druckertreiber realisieren).
Damit sind die Dienste, die das Gerät anbietet, im Jini-Netz verfügbar.
- Zur Nutzung von Diensten können Jini-Teilnehmer über einen
sog. Lookup-Request Jini-Dienste nachfragen: Dabei erhält
der Lookup-Service eine Spezifikation in Form eines Java-Interfaces
und sucht nach passenden Kandidaten.
- Konnte der Lookup-Service einen geeigneten Dienst identifizieren,
so wird der zugehörige Proxy an den nachfragenden Client geschickt.
Konkret ist ein solcher Proxy ein serialisierbares Java-Objekt.
- Der Client startet den Proxy dann in der eigenen virtuellen Java-Maschine
und erhält über ein Interface des Proxies Zugriff auf den
Dienst.
Interessant dabei ist insbesondere die automatische Übertragung
des Dienste-Proxies zu dem Client: Zum einen kann man so die Installation
von Plattform-spezifischer Software auf einem Client vermeiden (z.B. die
eines Druckertreibers), zum anderen kann ein Jini-Device damit berechnungsintensive
Vorgänge (z.B. die Interpretation von PostScript) auf den Client
auslagern.
Jini zielt jedoch nicht nur auf „klassische" Client/Server-Szenarien,
sondern bietet auch Konzepte zur Realisierung verteilter, objektorientierter
Systeme:
Mit dem Distributed Leasing-Konzept kann der Zugriff auf Ressourcen
verwaltet werden, Distributed Transactions dienen dazu, verteilte,
aber zusammengehörende Schritte atomar zu gestalten und so die Konsistenz
in einem System sicherzustellen und durch Distributed Events läßt
sich das Verhalten von verteilten Objekten koordinieren, also lokalen
Zustandsänderungen auch globale Auswirkungen geben. Letztlich sind
die JavaSpaces ein Dienst, der auf Linda Tuple Spaces [2]
beruht und Java-Objekte verwaltet; damit ist es möglich, Anwendungen
mit Hilfe von persistenten, verteilten Objekten zu realisieren.
Ausblick
Jini ist eine interessante Technologie, verspricht sie doch eine wesentliche
Vereinfachung bei der Nutzung Internet-basierter Dienste und der Realisierung
verteilter Systeme in der Praxis. Eine solche Entwicklung ist, angesichts
der sich abzeichnenden Entwicklung im Bereich kleiner, spezialisierter
Internet-Endgeräte (PDAs, Personal Appliances, etc). unzweifelhaft
notwendig.
Jini ist nicht die Lösung für das anvisierte Szenario,
es ist lediglich eine denkbare Variante, nämlich eine Java-zentrierte
Lösung: das Konzept fußt auf dem Java-spezifischen Kommunikationskonzept
RMI („Remote Method Invocation") [3]
und serialisierbaren Java-Objekten; jede Jini-Komponente, die einen Dienst
nutzen möchte, muß eine eigene Java-Umgebung (Java-VM und entsprechende
Laufzeitbibliotheken) besitzen. Jini-Devices, die lediglich Dienste anbieten,
können zwar etwas einfacher gestaltet werden (vgl. Jini Device
Architecture Specification [1]), müssen
aber in der Lage sein, an den Jini-Protokollen zu partizipieren und das
CORBA-Protokoll IIOP [3] beherrschen.
In mancher Hinsicht versucht Jini, das Rad neu zu erfinden: Etwas mehr
Offenheit zu CORBA und den CORBAservices [3],
die sehr ähnliche Lösungen bieten, oder auch TINA [4]
wäre sicher wünschenswert.
Aus technologischer Sicht baut Jini auf weitgehend bekannten Konzepten
auf, das Gesamtkonzept läßt jedoch noch einige Fragen offen:
unklar bleibt beispielsweise, inwieweit Java Tuple-Spaces skalierbar sind,
wie das (statische) Sicherheitskonzept von Java mit der dynamischen Jini-Welt
zusammenpaßt, wie Key-Management konkret funktionieren soll, usw.
Der Jini-Geist erfüllt zwar noch nicht alle Wünsche, weist
aber hinsichtlich einer Infrastruktur für dynamisch vernetzte Internet-basierte
Geräte in die richtige Richtung. Insofern ist die Entwicklung vielversprechend
und spannend.
Danksagung. Ich danke Friedemann Mattern und Marco Gruteser für
hilfreiche Kommentare zu diesem Beitrag.
Artikelanfang Seitenanfang
|
