Jini: Neue Technologie für eine vernetzte Welt

Zurück 1 2 Page 2 Seite 2 von 2

Jini im Kontext

Traditionell wurden Betriebssysteme unter der Annahme entwickelt, dass ein Computer über einen Prozessor, etwas Speicher und eine Festplatte verfügt. Wenn Sie einen Computer starten, suchen Sie zunächst nach einer Festplatte. Wenn keine Festplatte gefunden wird, kann sie nicht als Computer fungieren. Computer erscheinen jedoch zunehmend in einer anderen Form: als eingebettete Geräte mit einem Prozessor, etwas Speicher und einer Netzwerkverbindung - aber ohne Festplatte. Das erste, was ein Mobiltelefon beim Booten tut, ist beispielsweise die Suche nach dem Telefonnetz. Wenn das Netzwerk nicht gefunden wird, kann es nicht als Mobiltelefon fungieren. Dieser Trend in der Hardwareumgebung, von festplattenzentriert zu netzwerkzentriert, wird sich auf die Organisation unserer Software auswirken - und genau hier setzt Jini an.

Jini ist ein Versuch, die Computerarchitektur angesichts der zunehmenden Bedeutung des Netzwerks und der zunehmenden Verbreitung von Prozessoren in Geräten ohne Festplattenlaufwerk zu überdenken. Diese Geräte, die von vielen verschiedenen Anbietern stammen, müssen über ein Netzwerk interagieren. Das Netzwerk selbst wird sehr dynamisch sein - Geräte und Dienste werden regelmäßig hinzugefügt und entfernt. Jini bietet Mechanismen zum reibungslosen Hinzufügen, Entfernen und Auffinden von Geräten und Diensten im Netzwerk. Darüber hinaus bietet Jini ein Programmiermodell, mit dem Programmierer ihre Geräte leichter miteinander kommunizieren können.

Aufbauend auf Java, Objektserialisierung und RMI, die es Objekten ermöglichen, sich im Netzwerk von virtueller Maschine zu virtueller Maschine zu bewegen, versucht Jini, die Vorteile der objektorientierten Programmierung auf das Netzwerk auszudehnen. Anstatt von Geräteherstellern zu verlangen, dass sie sich auf die Netzwerkprotokolle einigen, über die ihre Geräte interagieren können, ermöglicht Jini den Geräten, über Schnittstellen zu Objekten miteinander zu kommunizieren.

Was ist Jini?

Jini ist eine Reihe von APIs und Netzwerkprotokollen, mit denen Sie verteilte Systeme erstellen und bereitstellen können, die als Verbände von Diensten organisiert sind. Ein Dienst kann alles sein, was sich im Netzwerk befindet und bereit ist, eine nützliche Funktion auszuführen. Hardwaregeräte, Software, Kommunikationskanäle - auch menschliche Benutzer selbst - können Dienste sein. Ein Jini-fähiges Festplattenlaufwerk könnte beispielsweise einen "Speicher" -Dienst anbieten. Ein Jini-fähiger Drucker könnte einen "Druck" -Dienst anbieten. Ein Verbund von Diensten ist also eine Reihe von Diensten, die derzeit im Netzwerk verfügbar sind und die ein Client (dh ein Programm, ein Dienst oder ein Benutzer) zusammenführen kann, um ein bestimmtes Ziel zu erreichen.

Um eine Aufgabe auszuführen, nimmt ein Client die Hilfe von Diensten in Anspruch. Beispielsweise kann ein Client-Programm Bilder vom Bildspeicherdienst in eine Digitalkamera hochladen, die Bilder auf einen dauerhaften Speicherdienst herunterladen, der von einem Festplattenlaufwerk angeboten wird, und eine Seite mit Versionen der Bilder in Miniaturgröße an den Druckdienst von senden ein Farbdrucker. In diesem Beispiel erstellt das Client-Programm ein verteiltes System, das aus sich selbst, dem Bildspeicherdienst, dem dauerhaften Speicherdienst und dem Farbdruckdienst besteht. Der Client und die Dienste dieses verteilten Systems arbeiten zusammen, um die Aufgabe auszuführen: Bilder von einer Digitalkamera auszulagern und zu speichern und eine Seite mit Miniaturansichten auszudrucken.

Die Idee hinter dem Wort Föderationbasiert auf der Jini-Ansicht des Netzwerks - es gibt keine zentrale Kontrollbehörde. Da kein einziger Dienst zuständig ist, bilden alle im Netzwerk verfügbaren Dienste einen Verbund - eine Gruppe, die sich aus gleichen Peers zusammensetzt. Anstelle einer zentralen Behörde bietet die Laufzeitinfrastruktur von Jini lediglich eine Möglichkeit für Clients und Dienste, sich zu finden (über einen Suchdienst, in dem ein Verzeichnis der derzeit verfügbaren Dienste gespeichert ist). Nachdem sich die Dienste gefunden haben, sind sie auf sich allein gestellt. Der Client und seine eingetragenen Dienste führen ihre Aufgabe unabhängig von der Jini-Laufzeitinfrastruktur aus. Wenn der Jini-Suchdienst abstürzt, können alle verteilten Systeme, die vor dem Absturz über den Suchdienst zusammengeführt wurden, ihre Arbeit fortsetzen.Jini enthält sogar ein Netzwerkprotokoll, mit dem Clients Dienste finden können, wenn kein Suchdienst vorhanden ist.

Wie Jini funktioniert

Jini definiert eine Laufzeitinfrastruktur , die sich im Netzwerk befindet, und bietet Mechanismen, mit denen Sie Dienste hinzufügen, entfernen, suchen und darauf zugreifen können. Die Laufzeitinfrastruktur befindet sich an drei Stellen im Netzwerk: in Suchdiensten, die sich im Netzwerk befinden; in den Dienstanbietern (wie Jini-fähigen Geräten); und bei Kunden. Suchdienste sind der zentrale Organisationsmechanismus für Jini-basierte Systeme. Wenn neue Dienste im Netzwerk verfügbar werden, registrieren sie sich bei einem Suchdienst. Wenn Kunden einen Dienst suchen möchten, der sie bei einer bestimmten Aufgabe unterstützt, wenden sie sich an einen Suchdienst.

Die Laufzeitinfrastruktur verwendet ein Protokoll auf Netzwerkebene, das als Erkennung bezeichnet wird , und zwei Protokolle auf Objektebene, die als Join und Lookup bezeichnet werden. Mit Discovery können Clients und Dienste Suchdienste suchen. Mit Join kann sich ein Dienst in einem Suchdienst registrieren. Mit der Suche kann ein Client einen Suchdienst nach Diensten abfragen, mit denen der Client seine Ziele erreichen kann.

Der Erkennungsprozess

Die Erkennung funktioniert folgendermaßen: Stellen Sie sich vor, Sie haben ein Jini-fähiges Laufwerk, das einen dauerhaften Speicherdienst bietet. Sobald Sie das Laufwerk mit dem Netzwerk verbinden, sendet es eine Anwesenheitsansage, indem ein Multicast-Paket an einen bekannten Port gesendet wird . In der Anwesenheitsanzeige sind eine IP-Adresse und eine Portnummer enthalten, unter denen das Laufwerk von einem Suchdienst kontaktiert werden kann.

Suchdienste überwachen den bekannten Port auf Anwesenheitsansagepakete. Wenn ein Suchdienst eine Anwesenheitsansage erhält, wird das Paket geöffnet und überprüft. Das Paket enthält Informationen, mit denen der Suchdienst bestimmen kann, ob er den Absender des Pakets kontaktieren soll oder nicht. In diesem Fall wird der Absender direkt kontaktiert, indem eine TCP-Verbindung zu der aus dem Paket extrahierten IP-Adresse und Portnummer hergestellt wird. Mit RMI sendet der Suchdienst ein Objekt, das als Dienstregistrar bezeichnet wird.über das Netzwerk an den Absender des Pakets. Der Zweck des Dienstregistrierungsobjekts besteht darin, die weitere Kommunikation mit dem Suchdienst zu erleichtern. Durch Aufrufen von Methoden für dieses Objekt kann der Absender des Ankündigungspakets eine Verknüpfung und Suche für den Suchdienst durchführen. Im Fall des Festplattenlaufwerks würde der Suchdienst eine TCP-Verbindung zum Festplattenlaufwerk herstellen und ihm ein Dienstregistrierungsobjekt senden, über das das Festplattenlaufwerk dann seinen dauerhaften Speicherdienst über den Verknüpfungsprozess registrieren würde.

Der Join-Prozess

Sobald ein Dienstanbieter über ein Dienstregistrierungsobjekt verfügt, das Endprodukt der Ermittlung, kann er einen Join durchführen, um Teil des Verbandes von Diensten zu werden, die im Suchdienst registriert sind. Um einen Join durchzuführen, ruft der Dienstanbieter die register()Methode für das Dienstregistrierungsobjekt auf und übergibt als Parameter ein Objekt, das als Dienstelement bezeichnet wird, ein Bündel von Objekten, die den Dienst beschreiben. Die register()Methode sendet eine Kopie des Serviceelements an den Suchdienst, in dem das Serviceelement gespeichert ist. Sobald dies abgeschlossen ist, hat der Dienstanbieter den Beitrittsprozess abgeschlossen: Sein Dienst wurde im Suchdienst registriert.

Das Serviceelement ist ein Container für mehrere Objekte, einschließlich eines Objekts, das als Serviceobjekt bezeichnet wird und mit dem Clients mit dem Service interagieren können. Das Serviceelement kann auch eine beliebige Anzahl von Attributen enthalten, bei denen es sich um ein beliebiges Objekt handeln kann. Einige mögliche Attribute sind Symbole, Klassen, die GUIs für den Dienst bereitstellen, und Objekte, die weitere Informationen zum Dienst enthalten.

Serviceobjekte implementieren normalerweise eine oder mehrere Schnittstellen, über die Clients mit dem Service interagieren. Ein Suchdienst ist beispielsweise ein Jini-Dienst, und sein Dienstobjekt ist der Dienstregistrar. Die register()von Service Providern während des Joins aufgerufene Methode wird in der ServiceRegistrarSchnittstelle deklariert , die alle Service Registrar-Objekte implementieren. Clients und Dienstanbieter kommunizieren über das Dienstregistrierungsobjekt mit dem Suchdienst, indem sie in der ServiceRegistrarSchnittstelle deklarierte Methoden aufrufen . Ebenso würde ein Festplattenlaufwerk ein Dienstobjekt bereitstellen, das eine bekannte Speicherdienstschnittstelle implementiert. Clients würden über diese Speicherdienstschnittstelle nachschlagen und mit dem Festplattenlaufwerk interagieren.

Der Suchvorgang

Sobald sich ein Dienst über den Join-Prozess bei einem Suchdienst registriert hat, kann dieser Dienst von Clients verwendet werden, die diesen Suchdienst abfragen. Um ein verteiltes System von Diensten aufzubauen, die zusammenarbeiten, um eine Aufgabe auszuführen, muss ein Client die Hilfe der einzelnen Dienste suchen und in Anspruch nehmen. Um einen Dienst zu finden, fragen Clients Suchdienste über einen Prozess namens Suche ab.

Um eine Suche durchzuführen, ruft ein Client die lookup()Methode für ein Dienstregistrierungsobjekt auf. (Ein Client erhält wie ein Dienstanbieter einen Dienstregistrar durch den Erkennungsprozess, wie weiter oben in diesem Artikel beschrieben.) Der Client übergibt als Argument lookup()eine Dienstvorlage, ein Objekt, das als Suchkriterium für die Abfrage dient. Die Dienstvorlage kann einen Verweis auf ein Array von ClassObjekten enthalten. Diese ClassObjekte geben dem Suchdienst den Java-Typ (oder die Java-Typen) des vom Client gewünschten Dienstobjekts an. Die Servicevorlage kann auch eine Service-ID enthalten, die einen Dienst eindeutig identifiziert, und Attribute, die genau mit den Attributen übereinstimmen müssen, die vom Dienstanbieter in das Dienstelement hochgeladen wurden. Die Dienstvorlage kann auch Platzhalter für jedes dieser Felder enthalten. Ein Platzhalter im Feld Service-ID stimmt beispielsweise mit jeder Service-ID überein. Die lookup()Methode sendet die Dienstvorlage an den Suchdienst, der die Abfrage ausführt und Null an viele übereinstimmende Dienstobjekte zurücksendet. Der Client erhält als Rückgabewert der lookup()Methode einen Verweis auf die übereinstimmenden Serviceobjekte .

Im allgemeinen Fall sucht ein Client einen Dienst nach Java-Typ, normalerweise eine Schnittstelle. Wenn ein Client beispielsweise einen Drucker verwenden muss, erstellt er eine Dienstvorlage, die ein ClassObjekt für eine bekannte Schnittstelle zu Druckerdiensten enthält. Alle Druckerdienste würden diese bekannte Schnittstelle implementieren. Der Suchdienst würde ein Dienstobjekt (oder Objekte) zurückgeben, das diese Schnittstelle implementiert hat. Die Servicevorlage kann Attribute enthalten, um die Anzahl der Übereinstimmungen für eine solche typbasierte Suche einzugrenzen. Der Client würde den Druckerdienst verwenden, indem er die Dienstobjektmethoden aufruft, die in der bekannten Druckerservice-Schnittstelle deklariert sind.

Trennung von Schnittstelle und Implementierung

Die Architektur von Jini bringt objektorientierte Programmierung in das Netzwerk, indem Netzwerkdienste eine der Grundlagen der objektorientierten Programmierung nutzen können: die Trennung von Schnittstelle und Implementierung. Beispielsweise kann ein Dienstobjekt Clients auf viele Arten Zugriff auf den Dienst gewähren. Das Objekt kann tatsächlich den gesamten Dienst darstellen, der während der Suche auf den Client heruntergeladen und dann lokal ausgeführt wird. Alternativ kann das Dienstobjekt lediglich als Proxy für einen Remote-Server dienen. Wenn der Client Methoden für das Serviceobjekt aufruft, sendet er die Anforderungen über das Netzwerk an den Server, der die eigentliche Arbeit erledigt. Das lokale Serviceobjekt und ein Remote-Server können ebenfalls einen Teil der Arbeit erledigen.

Eine wichtige Konsequenz der Jini-Architektur ist, dass das Netzwerkprotokoll, das für die Kommunikation zwischen einem Proxy-Service-Objekt und einem Remote-Server verwendet wird, dem Client nicht bekannt sein muss. Wie in der folgenden Abbildung dargestellt, ist das Netzwerkprotokoll Teil der Implementierung des Dienstes. Dieses Protokoll ist eine private Angelegenheit, über die der Entwickler des Dienstes entschieden hat. Der Client kann über dieses private Protokoll mit dem Dienst kommunizieren, da der Dienst einen Teil seines eigenen Codes (das Dienstobjekt) in den Adressraum des Clients einfügt. Das injizierte Dienstobjekt kann mit dem Dienst über RMI, CORBA, DCOM, ein selbst gebrautes Protokoll, das auf Sockets und Streams aufgebaut ist, oder über alles andere kommunizieren. Der Client muss sich einfach nicht um Netzwerkprotokolle kümmern.weil es mit der bekannten Schnittstelle kommunizieren kann, die das Serviceobjekt implementiert. Das Serviceobjekt sorgt für die notwendige Kommunikation im Netzwerk.

Unterschiedliche Implementierungen derselben Dienstschnittstelle können völlig unterschiedliche Implementierungsansätze und völlig unterschiedliche Netzwerkprotokolle verwenden. Ein Dienst kann spezielle Hardware verwenden, um Kundenanforderungen zu erfüllen, oder er kann seine gesamte Arbeit in Software erledigen. Tatsächlich kann sich der Implementierungsansatz eines einzelnen Dienstes im Laufe der Zeit weiterentwickeln. Der Client kann sicher sein, dass er über ein Dienstobjekt verfügt, das die aktuelle Implementierung des Dienstes versteht, da der Client das Dienstobjekt (über den Suchdienst) vom Dienstanbieter selbst empfängt. Für den Client sieht ein Dienst wie die bekannte Schnittstelle aus, unabhängig davon, wie der Dienst implementiert ist.

Fazit

Wie wir in dieser einleitenden Spalte gesehen haben, versucht Jini, die Abstraktionsebene für die Programmierung verteilter Systeme von der Netzwerkprotokollebene auf die Objektschnittstellenebene zu erhöhen. In der zunehmenden Verbreitung eingebetteter Geräte, die mit Netzwerken verbunden sind, können viele Teile eines verteilten Systems von verschiedenen Anbietern stammen. Jini macht es für Anbieter von Geräten unnötig, Protokolle auf Netzwerkebene zu vereinbaren, mit denen ihre Geräte interagieren können. Stattdessen müssen sich Anbieter auf Java-Schnittstellen einigen, über die ihre Geräte interagieren können. Die von der Jini-Laufzeitinfrastruktur bereitgestellten Prozesse zum Erkennen, Verbinden und Nachschlagen ermöglichen es den Geräten, sich gegenseitig im Netzwerk zu lokalisieren. Sobald sie sich gefunden haben, können Geräte über Java-Schnittstellen miteinander kommunizieren.

Nächsten Monat

Obwohl sich diese Spalte hauptsächlich darauf konzentriert, wie bestimmte Programmierprobleme mit Jini gelöst werden können, z. B. das Hinzufügen einer GUI zu einem Dienst oder das Verwalten eines Dienstes, werde ich im nächsten Monat die realen Probleme und Perspektiven von Jini erörtern.

Jini diskutieren

Informationen zum in diesem Artikel vorgestellten Material finden Sie unter: //www.artima.com/jini/jf/intro/index.html

Bill Venners schreibt seit 14 Jahren professionell Software. Er ist im Silicon Valley ansässig und bietet Software-Beratungs- und Schulungsdienste sowie eine Website für Java- und Jini-Entwickler, artima.com. Er ist Autor des Buches: Inside the Java Virtual Machine, veröffentlicht von McGraw-Hill.

Erfahren Sie mehr über dieses Thema

  • Besuchen Sie die Jini-Community, um Informationen über den Prozess zu erhalten, mit dem bekannte Schnittstellen definiert werden

    //www.jini.org

  • Download-Seite für die aktuelle Jini-Version (bei Java Developer Connection)

    //developer.java.sun.com/developer/products/jini

  • Download-Seite für JDK 1.2 FCS Release, auf der die aktuelle Jini-Version ausgeführt wird

    //java.sun.com/products/jdk/1.2/

  • Ein Online-Jini-Tutorial

    //pandonia.canberra.edu.au/java/jini/tutorial/Jini.xml

  • Online-Vorlesungsunterlagen für einen Kurs über RMI und Jini

    //www.eli.sdsu.edu/courses/spring99/cs696/notes/index.html

  • "The Network Revolution", Clyde Higaki und Bill Venners (Suns Jini Technology Homepage, 1999). Die Autoren Clyde Higaki und Bill Venners bieten eine Reihe von Szenarien an, um zu beschreiben, wie Jini in der realen Welt verwendet werden kann

    //java.sun.com/features/1999/01/jini_scenario.html

  • Links zu Jini-Ressourcen

    //www.artima.com/jini/resources/index.html

  • Die Hauptseite von Jini bei Sun.

    //java.sun.com/products/jini/

  • Die Jini Community, die zentrale Website für die Interaktion zwischen Unterzeichnern der Jini Sun Community Source License

    //www.jini.org

  • Download-Seite für alle Jini-Spezifikationen

    //java.sun.com/products/jini/specs/

  • Mailinglisten-Archive von JINI-USERS. Um die JINI-USERS-Mailingliste zu abonnieren, senden Sie eine E-Mail an [email protected]. Geben Sie im Nachrichtentext Folgendes einsubscribe jini-users

    //archives.java.sun.com/archives/jini-users.html

  • Eine Jini-FAQ für die JINI-USERS-Mailingliste

    //www.artima.com/jini/faq.html

Diese Geschichte "Jini: Neue Technologie für eine vernetzte Welt" wurde ursprünglich von JavaWorld veröffentlicht.