Geist aus dem Netz

Inhaltsverzeichnis

Obwohl schon seit drei Jahren bei Sun in der Entwicklung, macht Jini erst seit neuestem von sich reden. Basierend auf der Java-Plattform soll das System beliebige Ressourcen netzweit dynamisch verwalten und Benutzern das Leben gewaltig erleichtern. Ob es um die netzweite Einbindung eines Druckers geht, um den Blick über eine Kamera ins heimische Kinderzimmer oder um den verteilten Zugriff auf eine neue Applikation: zukünftig soll sich die in Arbeit befindliche Klassenbibliothek Jini um die Kommunikationsdetails kümmern.

Das Ziel, diverse Dienste global anzubieten und per Plug-in zur Verfügung zu stellen, verfolgen auch HP mit JetSend und Lucent mit Inferno. Allerdings haben die drei Ansätze unterschiedliche Konzepte und sind somit nicht kompatibel zueinander. Für Jini spricht außer seinem hohen Abstraktionsniveau, daß es auf Java aufsetzt, plattformunabhängig ist und auf beliebiger Hardware laufen kann. Da der Kern nur 48 KByte groß ist, wäre theoretisch auch eine Installation auf einem Drucker oder einer Settop-Box denkbar.

Jinis Grundidee ist, einen Verbund (Federation) von Benutzern und Ressourcen zu bilden, mit dem Ziel, das Netz in ein flexibles, leicht zu verwaltendes Werkzeug zu transformieren. Mit dessen Hilfe sollen Benutzer - sowohl menschliche als auch maschinelle - Ressourcen leicht lokalisieren und ohne weiteren Aufwand verwenden können. Dabei ist der Begriff Ressource so weit gefaßt, daß er sowohl auf ein Stück Hardware als auch auf ein Programm oder eine Kombination von beidem zutrifft. Jinis Schwerpunkt liegt auf der Dynamisierung des Netzes: Ressourcen lassen sich jederzeit darin integrieren oder aus ihm entfernen. Dieses Konzept unterstützt speziell Arbeitsgruppen, die sich ständig neu zusammensetzen.

Eine Jini-Umgebung besteht grob aus folgenden Teilen:

• einer Reihe von Infrastrukturkomponenten für die Zusammenführung von Diensten in einem verteilten System,
• einem Programmiermodell für die Entwicklung von zuverlässigen verteilten Anwendungen und
• Diensten, die ihre Funktion den anderen Mitgliedern des Verbunds anbieten

Zwar stehen die einzelnen Teile für sich, doch gibt es eine enge Verbindung zwischen ihnen, die eine Unterscheidung in der Praxis mitunter etwas erschwert. Die Komponenten der Infrastruktur verwenden das Programmiermodell und bilden ihrerseits die Basis für die Dienste, die sich ebenfalls an das Programmiermodell halten. Dieses wiederum basiert auf der Infrastruktur und wird von ihr unmittelbar unterstützt. Sun will mit dem Konzept grob drei Zielgruppen ansprechen:

• Benutzer: Sie können Dienste und Ressourcen gemeinsam netzweit nutzen, ohne daß sie dabei an einen festen Arbeitsplatz gebunden sind.
• Anwendungsentwickler: Sie erhalten Werkzeuge und Konzepte an die Hand, um robuste und sichere verteilte Anwendungen schreiben zu können.
• Systemadministratoren: Ihnen wird die Aufgabe erleichtert, ein Netz von Geräten, Programmen und Benutzern aufzubauen und zu verwalten.

Komponenten der Jini-Architektur

Die Jini-Architektur ist relativ einfach, zum großen Teil deshalb, weil ihre Komponenten auf der Java-Plattform basieren. Voraussetzung ist, daß Jini Code dynamisch laden und ausführen kann. Solange die entsprechenden Compiler Java-kompatiblen Bytecode erzeugen, ist auch der Einsatz anderer Programmiersprachen denkbar.

Wichtigstes Konzept hierbei ist der Dienst, der von einer Person, einem Programm oder einem anderen Service benutzt werden kann. Dabei kann es sich um Rechenleistung, Sekundärspeicher, Hardware, einen Benutzer oder einen Kommunikationskanal zu einem zweiten Benutzer handeln. Theoretisch denkbar wäre also der Minicomputer, der sich seinen Hauptspeicher aus der Großrechnerabteilung holt. Dienste können aber auch wesentlich spezifischer sein und beispielsweise die Konvertierung aus dem Format eines Textverarbeitungsprogramms in ein anderes anbieten.

Ein Jini-Verbund ist allerdings nicht nur eine Ansammlung von Clients und Servern oder Benutzern und Programmen. Die einzelnen Komponenten lassen sich auch für bestimmte Aufgaben beliebig kombinieren. Dabei kann sich ein Dienst eines anderen bedienen, und der Client eines Dienstes kann wiederum ein Dienst mit eigenen Clients sein.

Dienste als zentrale Bestandteile

Hinsichtlich der Dienste bietet Jini Mechanismen zur Erstellung, zum Auffinden, für die Kommunikation und für den Einsatz in verteilten Systemen. Zentraler Bootstrapping-Mechanismus eines Jini-Systems ist der ‘Lookup Service’ zum Auffinden der Ressourcen. Mit ihm hat ein Benutzer den häufigsten Kontakt: sowohl dann, wenn er eine Ressource nutzen, als auch dann, wenn er selbst eine netzweit zur Verfügung stellen will. Die Funktion eines Dienstes exportiert Jini über Java-Interfaces, und der Lookup Service bildet diese Schnittstellen auf konkrete Objekte ab, die die entsprechende Funktion implementieren. Zusätzlich kann ein Dienst beschreibende Einträge haben, die einem Benutzer bei der Auswahl eines passenden Dienstes helfen. In bezug auf einen Drucker hieße das beispielsweise, daß der Lookup Service nicht nur einen Client Proxy, der die Funktion des benötigten Treibers erfüllt, zum Download zur Verfügung stellt, sondern auch über die Information verfügt, ob das Gerät PostScript unterstützt oder nicht.

Es ist möglich, daß Objekte innerhalb eines Lookup Service selbst wiederum einen solchen Service beinhalten, so daß sich eine hierarchische Struktur ergibt. Darüber hinaus können Objekte eines Lookup Service andere Namens- und Verzeichnisdienste kapseln und somit einen Übergang zwischen dem Jini Lookup Service und anderen Namensdiensten zur Verfügung stellen. Bekannte Vertreter solcher Namensdienste sind zum Beispiel NIS, NIS+ oder DNS. Im Prinzip ist ein beliebiger Verzeichnisdienst integrierbar - also beispielsweise auch X.500 oder LDAP - vorausgesetzt, jemand schreibt den entsprechenden Wrapper Code.

Als Beispiel soll hier die Integration einer vorhandenen NIS+-Installation dienen. Zunächst wird mit Hilfe von JNDI (Java Naming and Directory Interface) NIS+ in Java gekapselt und als Lookup Service zur Verfügung gestellt, der eine eindeutige ID hat, mit der er sich bei seinen bereits vorhanden Kollegen registriert. Wie jeder Jini-Dienst hat auch der neue Lookup Service beschreibende Attribute, in diesem Fall handelt es sich dabei um die Fähigkeit, NIS+-Anfragen bearbeiten zu können. Auf diese Weise läßt sich eine Hierarchie von Lookup Services aufbauen.

Sinnigerweise heißt die Registrierung eines Dienstes beim Lookup Service ‘Discovery’, da ihn Jini in dem Moment quasi ‘entdeckt’. Der Lookup Service verfügt jetzt über eine Referenz auf den Dienst, anhand derer zum Dienst gehörige Ressourcen wie Treiber, Hilfesysteme et cetera per ‘Join’ geladen werden und auf die eventuelle Clients von da an zugreifen können. (Eine detaillierte Beschreibung dieses Vorgangs folgt unten).

Die Kommunikation selbst erfolgt über ein ‘Service Protocol’, das sich aus einer Reihe von Java-Interfaces aufbaut. Anzahl und Funktionsumfang möglicher Service-Protokolle sind nicht beschränkt, die Jini-Architektur definiert bereits einige. Als Basis für die Service-Protokolle dient Javas Remote Method Invocation. Mit Hilfe von RMI ist es möglich, Code in Form von Objekten über das Netz auszutauschen.

Mehr Infos

Discovery Protocols

Multicast Request Protocol: Dieses Protokoll verwendet ein neu gestarteter Dienst zum Auffinden der vorhandenen Lookup Services.

Mulitcast Announcement Protocol: Hierüber gibt ein Lookup Service seine Existenz bekannt. Es kann in folgenden Situationen verwendet werden:

• Ein neuer Lookup Service wurde gestartet, der seine Existenz potentiellen Clients bekanntgeben will.
• Nach einem Netzwerkfehler oder -ausfall kann ein Lookup Service einem Client mitteilen, daß er (wieder) verfügbar ist.
  

Unicast Discovery Protocol: Es kann zur Kommunikation mit einem bestimmten Lookup Service dienen. Dies ist insbesondere dann sinnvoll, wenn die Kommunikation über ein langsames Netz läuft.

Javas Sicherheitsmodell erweitert

Eine Architektur, wie Jini sie implementiert, setzt ein wirksames Sicherheitskonzept voraus. Um den besonderen Anforderungen eines dynamischen Systems gerecht zu werden, hat Sun die Standardmechanismen der Java-Plattform erweitert. Jinis Sicherheitsmodell basiert auf zwei zentralen Komponenten: dem ‘Principal’ und einer ‘Access Control List’. Der Zugriff auf einen Dienst erfolgt immer unter einer bestimmten Identität, dem Principal, der sich allgemeinen Benutzern bis zu einem spezifischen Benutzer zurückverfolgen läßt. Wenn Dienste selbst den Zugriff auf andere Dienste anfordern, geschieht das mit der Identität des Objekts, das den anfordernden Dienst implementiert. Ob der gewünschte Zugriff gewährt wird, hängt von der zum Service gehörigen Access Control List ab.

Für die meisten Dienste legt eine ‘Lease’ die Dauer des Zugriffs fest. Die genauen Bedingungen handeln Benutzer und Anbieter eines Dienstes als Teil des Service Protocol aus. Nachdem der Benutzer den Service angefordert hat, wird ihm der Zugriff gewährt - im Idealfall unter Berücksichtigung des von ihm gewünschten Zeitraums. Soll eine Lease nach dessen Ablauf verlängert werden, ist erneutes Verhandeln angesagt. Stellt ein Service zum Beispiel einen Drucker zur Verfügung, kann er ihn nach Ablauf einer Lease einem anderen Client anbieten, wenn der erste Client ihn nicht erneut anfordert. Der Service wartet nicht darauf, daß der Client explizit sagt, daß er den Drucker nicht mehr benötigt. Wichtig ist dieses Vorgehen, wenn die Verbindung zwischen Client und Service unterbrochen wird, der Client also keine Möglichkeit mehr hat, mitzuteilen, daß er die Ressource nicht mehr braucht.

Ein Lease kann exklusiv sein oder für mehrere Benutzer gelten. Im ersten Fall wird ein exklusier Zugriff auf eine Ressource garantiert, andernfalls können sich mehrere Benutzer eine teilen.

Integrität durch Transaktionen

Um sicherzustellen, daß Aktionen vollständig ausgeführt werden, implementiert Jini einen Transaktionsmanager. Transaktionen umfassen in diesem Kontext eine Sequenz von Operationen, die innerhalb eines einzigen Dienstes ausgeführt werden oder sich über mehrere erstrecken können. Das für diesen Zweck vorgesehene Service Protocol besitzt die notwendigen Schnittstellen für ein Two Phase Commit. Allerdings wird nicht davon ausgegangen, daß eine Transaktion wie bei relationalen Datenbanken im Rahmen eines Transaktionsmonitors stattfindet, sondern das System definiert Mechanismen und Anforderungen für die korrekte Implementierung einer gegebenen Transaktionssemantik. Die Implementierung der notwendigen Mechanismen übernimmt nicht das Two-Phase-Commit-Protokoll, sondern die Objekte, die eine Transaktion verwenden, sind selbst dafür zuständig. In der Jini-Referenzimplementierung geschieht dies auf Basis der Transaktionsmechanismen einer einfachen objektorientierten Datenbank (ObjectStore Pro). Ziel der Jini-Architektur ist es, Interaktionen zu definieren, die notwendig sind, um eine Sequenz von Operationen zwischen verschiedenen Objekten zu koordinieren.

Weiterer Bestandteil der Architektur sind verteilte Events, die das Konzept der JavaBeans erweitern, so daß es auch über die Grenzen einer JVM hinweg funktioniert. Ein Objekt kann bei einem zweiten das Interesse an einem Event registrieren lassen. Tritt das Ereignis ein, erhält das registrierende Objekt eine entsprechende Nachricht. Dabei können sich registrierendes und benachrichtigendes Objekt in zwei verschiedenen virtuellen Maschinen befinden. Da sich verteilte Benachrichtigungen verzögern können oder gar ganz ausbleiben, ist jedes Event nicht nur mit einer ID, sondern auch mit einer Sequenznummer versehen.

Die bisher vorgestellten Komponenten bilden die Bereiche Infrastruktur und Programmiermodell. Einen Überblick über die gesamte Architektur zeigt die Grafik auf Seite 168, die auch die Beziehung zur Java-Plattform illustriert. Jini selbst kann als Basis für Dienste auf einer noch höheren Abstraktionsebene dienen. Ein Beispiel dafür sind JavaSpaces- gewissermaßen eine Online-Kooperative für verwandte Objekte. Die folgenden Ausführungen widmen sich dem dritten Bereich der Architektur - den Services.

Dienste registrieren und nutzen

Wie bereits erwähnt, erfolgt die Interaktion innerhalb eines Jini-Systems über Dienste. Dies gilt sowohl für die Programmierebene als auch für die Benutzerschnittstelle. Die Arbeitsweise des Protokollpaares Discovery und Lookup soll den Aufbau eines Service illustrieren.

Beide Protokolle kommen zu unterschiedlichen Zeitpunkten zum Einsatz. Wird ein Dienst Teil eines Jini-Verbunds, zum Beispiel durch den Anschluß eines Gerätes ans Netz, kommt das Discovery-Protokoll zum Einsatz. Möchte dagegen ein Benutzer oder ein Client einen Dienst über den Lookup Service finden und aufrufen, geschieht dies auf Basis des gleichnamigen Protokolls.

Im einzelnen funktioniert das Registrieren eines Dienstes bei einem Jini-System folgendermaßen. Der Anbieter - dies kann ein Gerät oder ein Programm sein - fragt zunächst nach einem Lookup Service, indem er seine Anwesenheit über einen Broadcast ankündigt. Hat er den Service gefunden, schickt er ihm einen Proxy mit den eigenen Schnittstellen als Java Interface sowie allen anderen beschreibenden Attributen. Nachdem der Lookup Service den neuen Dienst registriert hat, können Benutzer oder andere Dienste darauf zugreifen.

Ein Client findet den gewünschten Dienst über dessen Typ, das heißt über sein Java-Interface beziehungsweise das Java-Typ-System. Ist eine Benutzerschnittstelle vorhanden, lassen sich zusätzlich beschreibende Attribute für die Auswahl angegeben.

Für den Aufruf des Dienstes lädt der Lookup Service als RMI-Server den zugehörigen Proxy in den Client. Dies geschieht, indem der Service den Code des Objekts für den Client transparent überträgt, allerdings nur beim ersten Mal. Beim nächsten Aufruf ist das zum Objekt gehörige Class File auf dem Client vorhanden, und die vom Service gelieferte Referenz verweist auf das dort gefundene Objekt. Der Proxy kann ein privates Protokoll für die Kommunikation mit dem Dienstanbieter verwenden, so daß man bisher eingesetzte proprietäre Prokolle beibehalten kann, um Geräte oder Programme mit Jini zu verbinden. Verschiedene Realisierungen desselben Dienstes dürfen sogar mit unterschiedlichen Protokollen arbeiten.

Durch dieses Vorgehen - Code von einem Dienstanbieter an den Lookup Service zu übertragen und von dort an den Benutzer des Dienstes - steht es Programmierern weitgehend frei, wie sie die interne Kommunikation gestalten. Dadurch, daß der Dienst selbst den Proxy liefert, ist gewährleistet, daß beide stets synchronisiert sind. Für den Fall, daß sich die Objektimplementierung ändert, bietet es sich an, die Java Object Serialization zu nutzen. Einer Klasse kann ein ‘Stream Unique Identifier’ zugewiesen werden. Dieser Hash Code enthält Klassen- und Interfacenamen sowie Methoden und Attribute. Ändert ein Service Provider den Stream Unique Identifier seiner Proxy-Klasse, wird automatisch das neue Proxy-Objekt geladen. Diese Eigenschaft der RMI/ Object Serialization ist für den Client transparent. Während der Benutzer lediglich weiß, daß er mit einer Implementierung zusammenarbeitet, die ein ihm bekanntes Java-Interface umsetzt, kann der Dienstanbieter, der den Code liefert, die internen Details eines Dienstes voll ausnutzen, ohne bei einer Änderung Inkompatibilität bei einem Client befürchten zu müssen.

Smarte Proxies kombinieren

Die Interfaces, die ein Client benutzt, um mit einem Dienst zu interagieren, lassen sich in zwei Gruppen unterteilen: Programmier- und Benutzerschnittstellen. Ein Vertreter der ersten Gruppe kann entweder eine RMI-Referenz auf ein entferntes Objekt sein, das den Dienst implementiert, oder ein lokales Objekt, das ihn umsetzt. Auch eine Kombination beider Ansätze ist möglich. In diesem Fall wird von einem sogenannten ‘Smart Proxy’ gesprochen. Dieser implementiert einen Teil des Dienstes lokal - also beim Client - und delegiert den Rest über entfernte Methodenaufrufe an eine zentrale Instanz. Der Lookup Service kann die Benutzerschnittstelle eines Dienstes speichern und an einen Client übergeben. Eine solche Schnittstelle wird durch eine Instanz der Klasse Applet oder einer davon abgeleiteten Klasse identifiziert. Dabei handelt es sich um die spezielle Form eines Proxy, über den ein menschlicher Benutzer direkt mit einem Dienst interagieren kann. Direkt oder indirekt kann auch spezielle Hardware einen Dienst umsetzen. In dem Fall erfolgt der Zugriff immer über den Proxy.

Voraussetzung für eine Jini-Umgebung ist natürlich ein Netz mit ausreichender Geschwindigkeit, um die einzelnen Geräte und Ressourcen miteinander verbinden zu können. Im allgemeinen genügt eine Übertragungsrate von 10 Mbps. Einige Geräte verlangen eine wesentlich höhere Bandbreite, andere haben deutlich bescheidenere Anforderungen. Beispiele für zwei Extreme sind hochauflösende Farbdisplays und Drucker. Die Latenz des Netzes darf höchstens im Sekundenbereich liegen, Verzögerungen von einigen Minuten sind nicht akzeptabel.

Man geht davon aus, daß jedes mit Jini verbundene Gerät über Speicher sowie eine gewisse Verarbeitungskapazität (CPU) verfügt. Über einen Proxy, der das Gerät gegenüber Jini repräsentiert und der selbst über die nötige Verarbeitungskapazität verfügt, läßt sich aber auch Hardware integrieren, die diese Voraussetzungen nicht erfüllt.

Eine Jini-Referenzimplementierung soll, inklusive Sourcecode, unter einer an die NPL (Netscape Public License) angelehnten Lizenz veröffentlicht werden.

ANDREAS DÖRR
arbeitet im Java-Zentrum von Sun Microsystems in Grasbrunn.

Mehr Infos

iX-TRACT

• Die auf Java basierende Klassenbibliothek Jini soll die heutige komplexe Netzstruktur vereinfachen.
• Jinis Konzept sieht vor, daß ein Netz dynamisch um universelle Dienste erweiterbar ist, die Clients auf Anforderung zur Verfügung stehen.
• Das Spektrum der potentiellen Dienste reicht von Druckertreibern, über Formatierprogramme bis zu gemeinsam genutztem Hauptspeicher.
• Aufgabe von Jini ist es, die Kommunikation zwischen Diensten, Programmen und Benutzern zu koordinieren.

(ka)