Integration von Palm Handhelds in eine Jini-Umgebung

Inhaltsverzeichnis

1 Einleitung
1.1 JINI Allgemein
1.2 Klassifizierung

2 Jini-Grundlagen
2.1 Entwicklungsziele
2.1.1 Einfachheit
2.1.2 Zuverlässigkeit
2.1.3 Skalierbarkeit
2.2 Überblick
2.2.1 Registrierung eines Services
2.2.2 Nutzung eines Services
2.3 Jini-Infrastruktur
2.3.1 Discovery
2.3.1.1 Multicast-Request-Protokoll
2.3.1.2 Multicast-Announcement-Protokoll
2.3.1.3 Unicast-Discovery-Protokoll
2.3.2 Join
2.3.3 LUS
2.3.4 Verteiltes Sicherheitssystem
2.4 Jini-Programmiermodell
2.4.1 Leasing
2.4.2 Distributed Transaction
2.4.3 Distributed Events
2.5 Jini-Services
2.6 Realsierung von Services
2.6.1 Device-Architektur
2.6.2 Java-Objekt
2.6.3 JavaBeans
2.6.4 Enterprise JavaBeans

3 Jini und Palm
3.1 Technische Voraussetzungen
3.1.1 K Virtual Machine
3.1.2 Netzwerkverbindung
3.2 Architekturmöglichkeiten
3.2.1 Autonomer Jini-Client
3.2.2 Via Proxy (Java Client)
3.2.3 Via Proxy (PalmOS Client)

4 Jini Einrichten
4.1 Installation
4.2 Start der Basisdienste
4.2.1 StartService
4.2.2 Start der Dienste einzeln

5 Beispiel für Palm
5.1 Dienst
5.2 Client
5.2.1 Proxy auf dem PC
5.2.2 Client auf dem Palm
5.3 Ausführen des Beispiels

6 Fazit

Anhang

Inhalt der CD

Zusammenfassung

Die Systemarchitektur JINI soll in Zukunft die Zusammenarbeit von beliebigen Geräten erheblich erleichtern. Es sollen somit nicht nur PC’s untereinander verbunden werden, sondern auch Heimgeräte oder Handys. Die einzelnen Geräte verstehen sich, aus der Per­spektive des Anwenders betrachtet, automatisch und ohne weiteres Zutun miteinander.

Dieses Dokument soll einen Einblick in die Möglichkeiten geben, Palm™ Hand­helds in eine JINI-Umgebung zu integrieren. Zuerst werden die Grundlagen der JINI- Architektur besprochen, um einen Überblick über die Technologie zu geben. Dazu wird auf die Designziele von JINI eingegangen und im weiteren die verschiedenen Architek­turkomponenten besprochen. Danach werden einzelne Realisierungsmöglichkeiten dieser Technologie vorgestellt.

Im praktischen Teil des Dokumentes werden die Schritte zur Installation einer JINI- Umgebung erläutert. Im weiteren werden verschiedene Architekturmöglichkeiten, zur In­tegration von eines Palm™ Handhelds in eine JINI-Umgebung, vorgeschlagen. Abschlie­ßend wird eine dieser Möglichkeiten an einem konkreten Beispiel vorgeführt.

1 Einleitung

1.1 JINI Allgemein

Jini (Java Intelligent Network Infrastructure), eine Systemarchitektur aus dem Hause Sun, soll die Zusammenarbeit von beliebigen elektronischen Geräten erheblich verein­fachen. Sie stellt die Plattform für einen Service, der ein Gerät aktiviert und nutzbar macht, sobald dieses an ein Netzwerk angeschlossen wird. Herstellerunabhängig sollen somit nicht nur PC’s miteinander verbunden werden, sondern auch Geräte wie Stereoan­lage, Videokamera oder Handy. Aus der Sicht des Anwenders verstehen sich die Geräte automatisch miteinander, ohne irgendeinen Aufwand.

Sun trifft mit der Jini-Technologie genau den Nerv der Zeit, wo die Datenverarbei­tung immer mehr vernetzt erfolgt. Bill Joy^[1] nennt das Prinzip auch "Das Netzwerk ist der Computer". Man sieht es am Siegeszug des Internets, wo mit Hilfe eines Browsers auf beliebig viele Dienstleistungen auf den unterschiedlichsten Rechnerplattformen zugegrif­fen werden kann, ohne das dem Nutzer klar wird, wo er räumlich welche Dienstleistung in Anspruch nimmt. Jini versucht nun ähnlichen Komfort in beliebigen Netzen für die Nutzung von Diensten und Geräten zur Verfügung zu stellen.

Durch Jini wird es möglich, dass der Anwender sich überhaupt keine Gedanken mehr machen braucht, wie er bestimmte Dienste oder Geräte in ein System integriert. Bisher wurde z.B. zusätzliche Peripherie eines PC’s dadurch integriert, dass sie im ersten Schritt angeschlossen oder eingesteckt wurden und im zweiten Schritt die entsprechende Trei­bersoftware installiert wurde. Diese Software muß für jedes Betriebssystem extra vom Hersteller entwickelt worden sein. Diese Prozedur beschränkt sich bei Jini auf das An- schliessen des Gerätes, da jede Jini-Komponente ihren eigenen Treiber mitbringt. Jedoch ist die Jini-Technologie nicht nur auf Hardwaregeräte beschränkt, sondern auch ganze Anwendungen können als Service zur Verfügung gestellt und genutzt werden.

Eine weitere herausragende Eigenschaft von Jini ist die Flexibilität und Zuverläs­sigkeit. Heutige verteilte Systeme leiden oft unter Stabilitätsproblemen auf Grund von unsicheren Netzwerkverbindungen. In einem Jini-System ist es nun möglich, dass Dien­ste hinzugefügt oder entfernt werden, ohne das es zu einem Ausfall des ganzen Systems kommt. Es wird von vornherein mit unzuverlässigen Netzwerkverbindungen und nur zeit­weiser Verfügbarkeit von Geräten gerechnet. So kann auf Fehler reagiert und durch red­undante Strukturen repariert werden.

1.2 Klassifizierung

Jini ist eine auf Java basierende dynamisch verteilte Systemarchitektur. Es stellt allen Beteiligten eine Infrastruktur zur Verfügung, die es erlaubt permanent neue Dienste dem System hinzuzufügen und zu entfernen. Jini ermöglicht den Verbindungsaufbau zwischen verschiedenen Services, die aus einem Java-Programm oder einem Programm, das zumin­dest zu einem Teil aus Java-Code besteht. Bei Jini ist alles ein Service, egal ob Hardware oder Software. Jeder Service wird durch Java-Objekte repräsentiert. Dieser Ansatz er­innert stark an die Architektur von komponentenbasierter Software. Man benötigt also für jeden Service eine Java-Virtual Machine um ihn ausführen zu können. Die Services können, nach einer Registrierung, von potentiellen Benutzern anhand von bestimmten Eigenschaften ausgewählt werden. Der verteilte Ansatz von Jini soll eine robuste Archi­tektur hervor bringen. Die Ausfälle von einzelnen Geräten sollen nur deren momentane Benutzer treffen, und nicht die Funktionsweise des Systems verändern.

2 Jini-Grundlagen

2.1 Entwicklungsziele

In diesem Abschnitt soll es um die Entwicklungsziele von Jini gehen. Damit sind jene Bereiche gemeint, welche die Entwickler als besonders wichtig erachtet haben.

2.1.1 Einfachheit

Wenn sie Java schon kennen, ist ihnen auch Jini im Grunde bereits weitgehend bekannt. Jini benutzt die grundlegenden Konzepte von Java und fügt lediglich eine dünne Schicht ein, um Geräten und Diensten innerhalb des Netzwerkes die Zusammenarbeit zu erleich­tern [EdwOOj.

Im wesentlichen dient Jini der Verbindung von Diensten. Es nimmt keinen Einfluß darauf, welche Dienste im einzelnen angeboten werden ,wie diese gestaltet werden und wie sie sich verhalten. Jini-Dienste müssen nicht in Java geschrieben sein. Es ist lediglich erforderlich, dass sich irgendwo im Netz etwas Code befindet, der in Java geschrieben ist und an den Mechanismen teilnehmen kann, die Jini zur Auffindung anderer Jini-Geräte und Jini-Dienste verwendet. Aus der Sicht von Jini kann alles ein Dienst sein - Geräte wie Scanner, Drucker gehören genauso dazu, wie Speicher oder Rechenleistung. Wobei sich die Integration solcher Dienste in ein Jini-Netzwerk, aus Sicht des Nutzers, so einfach und narrensicher gestaltet, wie das anstecken eines Telefons. Die Jini-Dienste sind sofort nach dem Einschalten für alle Teilnehmer des Netzwerkes ohne zusätzlichen Aufwand (wie z.B. Treiberinstallation) nutzbar. So ist es praktisch jedem intelligenten elektronischen Gerät möglich, spontan zum Dienstanbieter oder -nutzer in einem Jini-Netzwerk zu werden.

2.1.2 Zuverlässigkeit

Zuverlässigkeit gehört mit zu den wichtigsten Aspekten bei verteilten Systemen. Bei der Integration von neuen Netzteilnehmern muß unabhängig davon die Funktionsfähigkeit der bestehenden Teilnehmer gewährleistet sein. Kleine Fehler führen bei herkömlichen Systemen schnell zum Ausfall des ganzen Netzwerkes. Nicht so bei Jini, da neu hinzu­kommende Dienste nicht mit bestehenden Diensten und Nutzern in Berührung kommen. Jini ist auch in der Lage, beim Ausfall von einzelnen Services, die Funktionsfähigkeit des Netzwerkes aufrecht zu erhalten. Nur die direkten Nutzer dieses Services sind von dem Ausfall betroffen.

Diese Eigenschaften sorgen dafür, das ein Jini-Netz praktisch keiner Verwaltung be­darf. Durch die von Jini gebotene “spontane Vernetzung” wird die Änderung der Konfigu- ration eine Netzwerkes, ohne Zuhilfenahme von Administratoren, erlaubt. Die Fähigkeit des Systems zur Selbstheilung verringert den Verwaltungsaufwand und erspart Benutzern manchen Arger. Eine zusammenarbeitende Gruppe von Jini-Diensten kann sich an Ände­rungen der Netzwerktopologie, Ausfällen von Diensten und Teilungen des Netzwerkes auf adäquate Weise anpassen. Jini Dienste können mit Störungen innerhalb des Netzwerkes umgehen. Es könnte sein, dass sie ihre Aufgabe nicht mehr erfüllen, doch sie werden sich zumindest auf vorhersehbare Weise verhalten.

2.1.3 Skalierbarkeit

Bei Jini können sich Gruppen von Diensten zu gemeinsamarbeitenden Einheiten zusam­menschließen. Diese Einheiten werden auch als Gemeinschaften bezeichnet. Alle Teilneh­mer einer solchen Gemeinschaft kennen sich und können sich gegenseitig benutzen[1]. Im Idealfall beinhaltet solch eine Gruppe die Mitarbeiter einer Arbeitsgruppe, und die von ihnen benötigten Drucker, PDA’s^{[2] [3]}, Mobiltelefone, Scanner, Netzwerkdienste und sonsti­ge Geräte. Diese Konzentration auf Arbeitsgruppen ist darauf zurückzuführen, dass die meisten Leute am ehesten mit Personen Zusammenarbeiten, die sich in ihrer unmittel­baren Umgebung befinden. Mit Jini ist es ganz einfach, solche Gruppen von Personen zu einer Gemeinschaft zusammenzufügen, und ihre Ressourcen der gemeinsamen Ver­wendung zugänglich zu machen. Manchmal benötigen Teilnehmer einer Gruppe jedoch Resourcen, die sich außerhalb der Arbeitsgruppe befinden. Der Zugriff auf Dienste ande­rer Gemeinschaften wird von Jini unterstützt. Da der Lookup-Dienst - welcher für das Erfassen aller Dienste in einer Gemeinschaft zuständig ist - selbst auch ein Jini-Dienst ist, kann dieser sich auch bei einem anderen Lookup-Dienst registrieren, wodurch die Dienste der einen Gemeinschaft auch der anderen Gemeinschaft zur Verfügung gestellt werden. Die Topologie solcher Gemeinschaften ist also äußerst flexibel und kann so gut wie jede beliebige Form annehmen.

2.2 Überblick

Um nun dio Jini-Architektur genauer zu betrachten, wird in Abbildung 2.1 gezeigt, welche Bestandteile notwendig sind, wenn ein Java-Programm Jini-Dienste benutzen möchte. Es ist ausschließlich Java-Programmen möglich, auf Jini-Dienste zuzugreifen. Wie in der Abbildung zu erkennen ist, gibt es keine genaue Trennung zwischen Java und Jini. Der Grund dafür ist, dass Jini komplett in Java realisiert ist. Es werden also ausschließlich J ava-Dionsto verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Statische Jini-Struktur

Des Weiteren ist in der Abbildung zu sehen, dass RMI eine wichtige Rolle in der Jini-Struktur oinnimmt. Einfach gesagt, stellt RMI Dienste zur Verfügung, welche es ermöglichen, auf beliebige verteilte Java-Objekte zuzugreifen. Wie Jini ist auch RMI vollständig in Java realisiert, man kann sogar sagen, RMI ist Bestandteil von Java. Die Java-Plattform bildet also die Grundvoraussetzung für die Jini-Architektur.

Grob läßt sich nun im weiteren die Jini-Architektur in drei wesentliche Bestandteile aufspalten.

- Infrastruktur
- Programmiormodoll
- Services

Die einzelnen Teile stehen zwar für sieh, jedoch gibt es eine enge Verbindung untereinan­der, die die Unterscheidung erschwert. So verwenden die Komponenten der Infrastruktur das Programmiormodoll und bilden ihrerseits die Basis für die Dienste, die sieh auch an das Programmiormodoll halten. Dieses wiederum basiert auf der Infrastruktur und wird von ihr unmittelbar unterstützt. Jedoch besteht grob der in Abbildung 2.2 dargestellte Zusammenhang.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Zusammenhang der Jini-Bestandteile

Zuerst einiges zur Infrastruktur: Wie bereits oben erwähnt, ist Jini vollständig in Ja­va realisiert. Somit ist auch verständlich, dass zu dessen Betrieb eine JVM 1.2 benötigt wird. Mittels RMI erfolgt die Kommunikation zwischen den verschiedenen Java-Objekten, die sieh beim Dienstnutzer und beim Dienstanbieter befinden. Die Sieherheitsmeehanis- mon von RMI wurden für Jini an die Bedürfnisse und Notwendigkeiten eines verteilten Systems angopaßt. Des Weiteren werden verschiedene Protokolle benötigt, um Services in einem Jini-Netz zur Verfügung zu stellen und nutzen zu können. Hierzu dient das Discovery- und Join-Protokoll. Ferner sollte es eine Möglichkeit geben, angebotene Ser­vices zu registrieren und eventuellen Nutzern zur Verfügung zu stellen. Diese Aufgabe übernimmt der sogenannte Lookup-Service. Er macht Services im Jini-Netz ausfindig und stellt sie in Form eines “Schwarzen Brettes” zur Verfügung. Der Lookup-Services speichert die Services also nicht direkt, sondern gibt nur Auskunft darüber, welche Services wo im Jini-Netz vorhanden sind. Durch den Einsatz von beliebig vielen Lookup-Services, welche auch hierarchisch aufgebaut sein können, kann die Ausfallsiehorthoit des Jini-Netzwerkes erhöht und eine logische Strukturierung vorgenommen werden. Auf die Infrastruktur wird im Weiteren Verlauf noch näher eingegangen.

Neben den Infrastrukturkompononton bietet Jini verschiedene Konzepte an, die zum Aufbau von zuverlässigen und sicheren verteilten Anwendungen dienen sollen. Diese Bau­steine stehen jedoch nur als Interfaces zur Verfügung und erweitern im allgemeinen das

JavaBeans-Programmiermodell. Die wichtigsten sind:

- Leasing Interface
- Distributed Transactions Interface
- Distributed Events Interface

In verteilten Systemen muß mit unzuverlässigen Netz Verbindungen, im Extremfall sogar mit dem Ausfall eines Services, gerechnet werden. Da dies oft unangekündigt auftritt, ist es nicht möglich, 100%ige Aussagen darüber zu machen, ob ein Dienst noch aktuell ist oder nicht. Dazu führt Jini das Leasing-Konzept ein. Jede Referenz auf eine Netzwerkre- source wird zeitlich begrenzt. Ein Dienstanbieter z.B. muß seine Bereitschaftserklärung periodisch erneuern. Ist das nicht der Fall, so verfällt die Bereitschaftserklärung und der Dienst ist nicht mehr verfügbar.

Jini stellt auch ein Interface für verteilte Transaktionen zur Verfügung. 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 bisherige Event-Modell von Java ist auf einen einzelnen Adressraum (eine JVM) beschränkt. Es ist nicht für Events ausgelegt, die verzögert und unzuverläßig über das Netz geschickt werden. Hierzu wird bei Jini ein verteiltes Event-Modell eingeführt. Ein Objekt kann so Informationen über Zustandsänderungen in anderen JVM’s, die sich ir­gendwo im Netz befinden, erhalten.

Nun zum letzten und wohl auch dem wichtigsten Teil von Jini: den Services. Dies sind Einheiten, die von einer Person, einem Programm oder einem anderen Service benutzt werden können. Ein Service kann hierbei fast jede beliebige Funktionalität annehmen. Es kann sich um eine Hardwarekomponente genauso wie um Rechenleistung oder eine Softwarekomponente handeln. Programmiertechnich sind Services Objekte, die in Java realisiert sind. Jeder Service besitzt ein Interface, über welches von Außen auf seine Funktionalität zugegriffen werden kann.

Das Herzstück eines jeden Jini-Netzwerkes bildet der Lookup-Service. Er ist für das Zustandekommen von Verbindungen zwischen Dienstnutzer und Dienstanbieter verant­wortlich. Damit Services in einem Netzwerk überhaupt sichtbar sind, müssen sie sich bei dem Lookup-Service anmelden. Ein potentieller Nutzer schickt nun seine Wünsche über spezielle Dienste an den Lookup-Service. Dieser schaut nach, ob ein Service mit den gewünschten Eigenschaften bei ihm registriert ist. Ist das der Fall, so übermittelt der Lookup-Service dem potentiellen Dienstnutzer die Informationen über den vorhandenen Service. Der Dienstnutzer baut nun eine direkte Verbindung zum Service auf. Aus diesem Szenario ergeben sich nun zwei wichtige Mechanismen in einem Jini-Netzwerk:

- Registrierung eines Services
- Nutzung eines Services

worauf nun im folgenden näher eingegangen werden soll.

2.2.1 Registrierung eines Services

Wie schon in 2.2 erwähnt wurde, nini sich ein Service zuerst bei einem Lookup-Service registrieren lassen, bevor er für die anderen Teilnehmer des Jini-Netzwerkes sichtbar wird. Dies erfolgt mit Hilfe des Discovery- and Join-Mochanisnius. Der Dienst anbiet er ist der Inhaber des Services. Um nun einen Service registrieren zu lassen, müssen verschie­dene Schritte durchlaufen werden. Zuerst werden mittels Discovery verfügbare Lookup- Services ausfindig gemacht. Von denen wird ein Passender ausgewählt. Danach werden dem Lookup-Service die Daten, die den Jini-Service charakterisieren, übermittelt und dort gespeichert. Die Daten können sich hierbei aus verschiedenen Interfaces, Attributen oder Methoden zusammensetzen. Der Vorgang des Übermittelns und Speieherns wird auch Joining genannt. Nun ist der Jini-Service beim Lookup-Service registriert und für die anderen Netzteilnehmer verfügbar. Dieser Ablauf ist auch in Abbildung 2.3 sichtbar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Registrierung eines Java-Objekts als Jini-Service

Die Registrierung eines Jini-Service bei einem Lookup-Service geschieht immer nur für einen bestimmten Zeitraum. Der Service muß sich selbst immer wieder beim Lookup- Service “melden”. So wird auf elegante Art und Weise sichergestellt, dass immer nur aktuelle und damit verfügbare Services beim Lookup-Service registriert sind.

2.2.2 Nutzung eines Services

Um einen registrierten Service zu nutzen, muß auf der Grundlage der gewünschten Funk­tionalität nach ihm gesucht werden. Dieser Vorgang ähnelt dem der Registrierung eines Services. Zuerst wird nach einem oder mehreren Lookup-Services, die die gewünsch­ten Services verwalten, Ausschau gehalten. In Abhängigkeit vom gewählten Anfrage­Protokoll, erhält der Dienstsuehende Informationen über einen oder mehrere Lookup- Services. Nun wird an einem ausgewählten Lookup-Service eine Anfrage zu einem Service geschickt. Als Ergebnis bekommt der Dienstsuehende ein Interface und eventuell zusätz­liche Informationen über den Service. Ab diesem Zeitpunkt kann nun der potentielle Dienstnutzer direkt mit dem Service über das Interface kommunizieren. In Abbildung 2.4 ist dieser Abblauf noeheinmal grafisch dargestellt. Die Jini-Architektur dient also ausschließlich der Registrierung von Diensten und bietet die Möglichkeit, diese Dienste anderen zur Verfügung zu stellen. Sie dient also nur als Vermittler oder Makler zwischen Dienstesuchenden und Diensteanbieter. Die eigentliche Nutzung der Dienste erfolgt dann völlig unabhängig von der Jini-Architektur. Dies eröffnet enorme Freiheiten bei der Ar­chitektur der Dienste und der Kommunikation zwischen Dienst und Dienstnutzer, da man nicht an bestimmte Vorgaben gebunden ist.

Abbildung in dieser Leseprobe nicht enthalten

2.3 Jini-Infrastruktur

Die Jini-Infrastruktur beschreibt den Kern von Jini. Sie enthält folgende Bestandteile:

- Discovery und Join (erlauben Java-Objekten Teil eines Jini-Netzwerkes zu werden)
- Lookup-Service (er dient zur Verwaltung und Vermittlung der registrierten Ser­vices)
- verteiltes Sicherheitssystem (in RMI integriert, welches um die Erfordernisse einer verteilten Architektur erweitert wurde)

Im Folgenden wird auf die drei Bestandteile der Infrastruktur näher eingegangen.

2.3.1 Discovery

Damit ein Service in einem Jini-Netzwerk nutzbar ist, muß er sich zuerst bei einem Lookup-Service registrieren. Die Suche nach solch einem Lookup-Service erfolgt mit Hil­fe des Discovery-Protokolls. Danach meldet sich der Service mittels des Join-Protokolls, auf welches in 2.3.2 eingegangen wird, bei einem ausgewählten Lookup-Service an.

Damit ein Java-Objekt sich als Jini-Service anmelden kann, muß auf dem Server, auf dem es gespeichert ist, eine Java-Vitual-Machine 1.2 installiert sein. Da Jini RMI für die Kommunikation zwischen den Services benutzt, kann als Protokoll TCP/IP- oder auch das UDP-Protokoll verwendet werden.

Beim Discovering zwischen Lookup-Service und einem Service können drei verschie­dene Protokolle verwendet werden:

- Multicast-Request-Protokoll
- Multicast-Announcement-Protokoll und
- Unicast-Discovery-Protokoll.

Bevor genauer auf die einzelnen Protokolle eingegangen wird, zuerst ein paar prinzipiel­le Unterschiede zwischen Multicast- und Unicast-Anfragen. Multicast-Anfragen werden nicht an alle Netzteilnehmer verschickt, wie bei Broadcast, sondern an eine Pseudo­Adresse, von welcher die Netzarchitektur die Anfrage weitervermittelt. Bei einer Unicast- Anfrage wird ein spezieller Empfänger angesprochen.

2.3.1.1 Multicast-Request-Protokoll

Bei Jini besteht die Möglichkeit, mehrere Lookup-Services zu einer Gruppe zusammenzu­fassen. Dadurch können mit einer Anfrage mehrere Lookup-Services angesprochen wer­den. So wird es für den Suchenden auch einfacher, entsprechende Lookup-Services zu finden. Da die Suchanfrage nicht über IP-Adressen funktioniert, entsteht eine große Fle­xibilität. Fällt z.B. ein einzelner Lookup-Service aus, kann ein anderer Rechner diese Aufgabe übernehmen, ohne dass der Suchende etwas darüber erfahren muß.

Bei dem Multicast-Request-Protokoll sind mehrere Komponenten beteiligt, 2 davon auf der Client-Seite und 2 auf der Seite des Lookup-Services. Auf der Client-Seite befindet sich [Dis99j:

- Ein Multicast-Request-Client (zum Lokalisieren der näehstgelegenen Lookup-Services)
- Ein Multicast-Response-Server (zur Entgegennahme der Antworten der verschiede­nen Server)

Die Komponenten treten immer paarweise auf. Auf der Server-Seite sind folgende Kom­p onent cn vorhanden :

- Ein Multicast-Request-Server (zur Entgegennahme von eingehenden Anfragen)
- Ein Multicast-Response-Client (übermittelt dem anfragenden Client ein Proxy, über welches dann die Kommunikation zwischen Client und Lookup-Service erfolgt)

Der Multicast-Request basiert nicht auf RMI. Das Senden vom Client zum Server erfolgt via UDP-Protokoll. Für den umgekehrten Kommunikationsweg, dem Multicast-Response, wird TCP/IP verwendet, da ausschließlich eine Antwort von einem Lookup-Service zu einem Service verschickt wird.

Die Suche nach einem Lookup-Service findet nun wie folgt statt: Zuerst startet der Client via UDP ein Multicast-Requester. Der Multicast-Requester auf dem Lookup-Service erkennt den Registrierungswunseh des Services und schickt ihm ein Multicast-Response- Client via TCP/IP zurück. Diese Nachricht wird vom laufenden Multicast-Response- Server auf der Seite des Clients cmpfangcnfHBOOj. Dieser Vorgang wird in Abbildung 2.5 noch einmal grafisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Multicast-R.equest-Protokoll

Bevor der Client eine Anfrage an den Lookup-Service abschickt, erstellt er erst eine Liste aller Lookup-Services, die er schon kennt. Diese wird dem Lookup-Service über­mittelt. Daraufhin scliaut er nach, ob er sich in der Liste befindet. Wenn dies nicht zutrifft, schickt der Lookup-Service eine Antwort an den Client mit seiner ID. Ansonsten antwortet der Lookup-Service nicht.

2.3.1.2 Multicast-Announcement-Protokoll

Das Multicast-Announcement-Protokoll wird nicht wie das Multicast-Request-Protokoll vom Client, sondern vom Lookup-Service initiiert. Der Lookup-Service gibt so seine Ver­fügbarkeit in einem Jini-Netzwerk bekannt. Bei diesem Protokoll sind nur 2 Komponenten beteiligt:

- der Multicast-Announcement- Client
- der Multicast-Announcement-Server.

Der Multicast-Announcement-Client befindet sich auf demselben Rechner wie der Lookup- Service. Er wird beim Starten des Lookup-Services ebenfalls gestartet und existiert bis zur Beendigung des Lookup-Services. Die Services bilden diesmal die Serverseite und beinhalten den Multicast-Announcement-Server.

Der Lookup-Service sendet, wie in Abbildung 2.6 Zusehen ist, via UDP einen Multicast an die Services. Falls die ID des Lookup-Services für den Jini-Service neu ist und zu einer interessanten Gruppe gehört, wird sie in die eigene Liste der bekannten Lookup-Services aufgenommen. Ansonsten werden die Nachrichten ignoriert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Multicast-Announcement-Protokoll

2.3.1.3 Unicast-Discovery-Protokoll

Nun zum Dritten und letzten Protokoll der Aufzählung in 2.3.1: dem Unicast-Discovery- Protokoll. Es ist ein einfaches auf TCP/IP basierendes Sender-Empfänger-Protokoll und wird in zwei verschiedenen Aktionen benutzt. Die Erste ist die, die in Abbildung 2.7 dar­gestellt ist. Der Client sucht einen speziellen Lookup-Service, urn sich dort als .Jini-Service zu registrieren. Es wäre aber auch der umgekehrte Fall denkbar: Der Lookup-Service er­greift von sich aus die Initiative, z.B. nach einem Rechnerausfall, um sein Repository wieder auf den aktuellen Stand zu bringen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Unicast-Discovery-Protokoll

2.3.2 Join

Nach dem der Client einen passenden Lookup-Service, via Discovery-Protokoll, zur Re­gistrierung gefundet hat, meldet er sich dort mit Hilfe des Jom-Protokolls an. Es wird hierbei ein Proxy-Objekt in der Registry des Lookup-Services gespeichert. Wie schon in 2.2 erwähnt wurde, erfolgt die Registrierung nicht einmalig, sondern muh periodisch erneuert werden, da sie nach einem bestimmten Zeitabschnitt automatisch verfällt. Die­ser Vorgang wird auch Leasing genannt und wird in 2.4.1 noch genauer beschrieben. Es kann so gewährleistet werden, dass ini Repository des Lookup-Service nur aktuelle und auch verfügbare .Jini-Services eingetragen sind. Um einen Service im .Jini-Net zwerk zu charakterisieren sind verschiedene Informationen notwendig IDis99j:

- Service-ID (für jeden Service eindeutig)
- Menge von Attributen
- Menge von Gruppen, den der Service angehören möchte
- Menge von Lookup-Services, bei den der Service registriert werden soll

Von diesen Informationen werden die ersten beiden auf der Seite des Lookup-Services gespeichert, und die anderen beiden auf der Client-Seite, also beim Service.

Die Services werden durch die Service-ID und durch das Interface oft nicht ausrei­chend beschrieben. Hierzu dient die Angabe von weiteren Attributen (bei einem Drucker können z.B. angegeben werden ob s/w oder Farbe oder die Druckauflösung), damit es dem potentiellen Benutzer einfäclier fällt, gezielt den richtigen Service auszuwählen. Die Attribute werden in Form von Klassen dargestellt, was große Freiheiten bei ihrer Imple­mentierung mit sich bringt. Diese Daten und die Service-ID müssen bei der Registrierung bei verschiedenen Lookup-Services gleich sein. .Jedoch gibt es die Möglichkeit, dass sich der gleiche Service mehrmals mit verschiedenen Attributen bei einem Lookup-Services anmeldet. Bei der Registrierung werden die Attribute und das Interface via RMI an den Lookup-Service übertragen.

2.3.3 LUS

Dor Lookup-Service bildet die zentrale Komponente in einem Jini-Netzwerk. Es muß mindestens einer im Netz vorhanden sein. Um diese herum befinden sieh beliebig viele verschiedene Services. Uber den Lookup-Service wird es für die Clients möglich, bestimm­te Services ausfindig zu machen und diese dann zu nutzen. Siehe dazu auch Abbildung 2.8.

Abbildung in dieser Leseprobe nicht enthalten

Der Lookup-Service verwaltet also Einträge von Services, die sich im Jini-Netzwerk befinden. Diese Einträge beinhalten einen RMI-Stub (wenn der Sorvein als Remote­Objekt implementiert ist) oder ein anderes Objekt, über das der Client auf den Service zugreifen kann (z.B. ein Proxy) und verschiedene Attribute, die den Service genauer be­schreiben. Der Lookup-Service verfügt über verschiedene Funktionen, um die Verwaltung und Vermittlung von Services zu ermöglichen und zu beeinflussen. So kann z.B. ein Sy­stemadministrator über ein Applet die Attribute eines registrierten Services verändern und gogobonfalls einige hinzufügen. Für potentielle Nutzer von Services stehen neben den wichtigen Methoden zur Nachfrage nach bestimmten Services auch andere, wie das Brow- son in der Registry des Lookup-Service, um einen Überblick über registrierte Services zu bekommen, zur Verfügung [LUS99J.

2.3.4 Verteiltes Sicherheitssystem

Die Kommunikation zwischen einzelnen Jini-Objekten wird mit Hilfe der RMI-Teehnologie realisiert. Ein Sicherheitssystem ist erforderlich, das festlegt, welche Clients welche Server benutzen dürfen. Da es sich bei Jini um ein dynamisches verteiltes System handelt, müs­sen die Sicherheitsmechanismen der Java-Plattform erweitert werden. Auf der Seite der Services sind keine speziellen Sicherheitsmechanismen notwendig, da sie auf einem Server von einem Entwickler, mit entsprechenden Rechten, entwickelt und installiert wurden. Es ist allein die Aufgabe der JVM auf dem Server, dass die Java-Objekte der Jini-Services korrekt und sicher ausgeführt werden. Es muß also nur ein Mechanismus eingeführt wer­den, der gewährleistet, dass nur berechtigte Clients auf die jeweiligen Jini-Services zu­greifen dürfen.

Hierzu wird für jeden Service eine Zugriffsliste (access control list) erstellt. In ihr wird festgelegt, welchen Nutzern oder Nutzergruppen der Zugriff auf den Service ge­währt oder verweigert wird. Darüber hinaus wird von Sun an einer Erweiterung dieses Sicherheitssystems gearbeitet, die eine vollständige Authentifizierung gewährleistet.

2.4 Jini-Programmiermodell

Neben den Infrastrukturkomponenten, siehe 2.3, bietet Jini Konzepte an, die zum Aufbau von zuverlässigen und sicheren verteilten Anwendungen dienen sollen. Diese Bausteine stehen jedoch nur als Interfaces und Referenzimplementation zur Verfügung. Sie sollen auch zu einem einheitlichen Programmierstil der Jini-Anwendungen führen. In diesem Abschnitt werden nun die folgenden Interfaces besprochen:

- Leasing-Interface
- Transaction-Interface
- Event-Interface

2.4.1 Leasing

In verteilten Systemen muß mit unzuverlässigen Netzverbindungen und im Extremfall mit dem Ausfall eines Services gerechnet werden. Da dies oft unangekündigt auftritt, ist es nicht möglich, 100%ige Aussagen darüber zu machen, ob ein Service noch aktuell ist oder nicht. Dazu führt Jini das Leasing-Konzept ein.

Der Grundgedanke des Leasing besteht darin, dass die Nutzung einer bestimmten Res­source nicht unendlich lang, sondern immer nur für einen bestimmten Zeitraum möglich ist. Der Zeitraum, in dem eine Nutzung erfolgt, wird dann zwischen den zwei beteiligten Parteien, Anbieter und Nutzer, ausgehandelt. Für den ausgehandelten Zeitabschnitt ga­rantiert dann der Dienstanbieter seine Verfügbarkeit. Die Jini-Services melden sich z.B. immer nur für einen bestimmten Zeitabschnitt beim Lookup-Service an. Nach Ablauf der Zeit muss der Jini-Service sich neu beim Lookup-Service melden und seine Verfügbarkeit erneut bestätigen. Macht er das nicht, wird der Eintrag beim Lookup-Service gelöscht. Die zeitliche Abfolge des Leasings sieht wie folgt aus [Köhj:

- Lease-Bewerber (Holder) verlangt vom Lease-Anbieter (Grantor) für eine bestimm­te Zeit ein Lease
- der Grantor entscheidet, ob und für wie lange er den Lease gewähren will
- Grantor schickt dem Holder ein Lease-Objekt
- Holder kann den Lease abbrechen, erneuern oder verfallen lassen

Der Leasing-Mechanismus sorgt für eine einfache Administration des Jini-Netzwerkes, ohne große Einwirkung eines menschlichen Netzwerkverwalters. Jedoch treten auch hier Probleme auf, wenn der Service innerhalb des definierten Zeitabschnittes ausfällt. Ganz zu schweigen von der steigenden Netzlast, die durch die periodische Erbringung des Ver­fügbarkeitsbeweises hervorgerufen wird.

2.4.2 Distributed Transaction

Nun zu dem Transaction-Interface. Eine Transaktion ist eine unteilbare Aktion, die aus einer oder mehreren Operationen besteht. Die Operationen einer solchen Aktion werden entweder alle oder es wird gar keine ausgeführt. Tritt während der Ausführung der Ope­rationen ein Fehler auf oder es entsteht ein Zustand, in dem die weitere Abarbeitung nicht möglich ist, werden alle bisher ausgeführten Operationen rückgängig gemacht und es wird der Zustand vor der Aktion wieder hergestellt. Dies ist vor allem in verteilten Systemen interessant, wo Transaktionen über mehrere Teilnehmer im Netz ausgeführt werden. Wenn einer dieser Teilnehmer nicht erreichbar ist, werden die Operationen auf den verfügbaren Teilnehmern wieder zurückgenommen. So kann ein konsistenter Zustand des Systems garantiert werden. In Jini wird dieser Mechanismus sehr locker umgesetzt. Es sind ausschliesslich Interfaces und Protokolle definiert. Die Implementierung ist dem Anwender selbst überlassen.

Zu einer Transaktion gehören verschiedene Beteiligte:

- ein Client
- Transaktionsmanager
- verschiedene Teilnehmer

Der Client initiiert die Transaktionen, dessen Ausführung dann vom Transaktionsma­nager kontrolliert und gesteuert wird. Die Teilnehmer sind diejenigen, auf denen dann die einzelnen Operationen ausgeführt werden. Zur Kommunikation zwischen diesen Be­teiligten wird das Two-Phase Commit Protocol verwendet. Der Vorteil dieses Protokolls besteht hauptsächlich darin, dass der Zeitraum, in dem auftretende Probleme ausschließ­lich durch eine aufwendige Kommunikation zwischen dem Transaktionsmanager und den Teilnehmern gelöst werden können, erheblich verkürzt wird.

Der zeitliche Ablauf einer Transaktion zwischen dem Initiator (Client), dem Manager und den Teilnehmern ist grob in Abbildung 2.9 dargestellt. Der Transaktionsmanager startet eine Transaktion. Dazu muß vom Initiator, dem Client, die create-Methode auf­gerufen werden. Danach werden vom Client aus die verschiedenen Teilnehmer aufgerufen. Diese treten mit der jom-Methode des Transaktionsmanagers der Transaktion bei.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Zeitlicher Ablauf einer verteilten Transaktion

2.4.3 Distributed Events

In objektorientierten Programmen kommt es oft vor, dass bestimmte Objekte in ihrer Abarbeitung erst dann fortfahren, wenn sie eine Reaktion eines anderen Objektes erhal­ten. Diese Reaktion wird als Ereignis (Event) bezeichnet. Dieses Vorfahren findet z.B. bei grafischen Benutzeroberflächen Anwendung. Die Kommunikation zwischen der Anwen­dung und dem Betriebssystem erfolgt hier durch Versenden und Reagieren auf Ereignisse in Form von ausgetauschten Nachrichten. Die Anwendung kann so über eine Vielzahl von Zustandsänderungen des Betriebssystems informiert werden. Wenn der Nutzer eines Pro­gramms z.B. einen Button drückt, wird ein Event vom Betriebssystem ausgelöst, wovon die Anwendung erfährt und entsprechend reagieren kann. An einem Event sind immer zwei Parteien beteiligt, der Event ompfängor und der Event er zeuger. Der Event ompfängor registriert sich beim Event er zeuger, um so sein Interesse an bestimmten Events zu be­kunden. Dieses Evontmodoll wird auch als “Delegation Event Model” bezeichnet. Bisher wurde bei Java solch ein Eventmeehanismus nur innerhalb eines Adrossraums, also einer JVM, realisiert. Hier kann man davon ausgehen, das die Events schnell und zuverlässig sind, und in geordneter Reihenfolge eint reffen [Evo99j.

Bei Jini wird nun ein verteilter Eventmeehanismus eingeführt. Dieser ermöglicht es, dass Objekte Informationen über Zustandsänderungen in anderen JVM’s, die sich irgonwo im Netz befinden, erfahren können. Es muß sich hierbei weder um JVM’s des gleichen Herstellers noch um die gleiche Version der JVM eines Herstellers handeln.

Ein verteilter Eventmeehanismus hat ganz andere Eigenschaften und muß von ganz anderen Voraussetzungen ausgehen, als einer der sich nur auf einen Adrossraum be­schränkt. Es muß dafür ausgelegt sein, dass Events verzögert und unzuverlässig durch das Netz verschickt werden. Meldungen über Events können in einer anderen Roihonfol-ge als sie aufgotroton sind odor gar nicht beim Empfänger ankommen. Auch kann man keine Anssage darüber machen, wie lange es dauern wird, bis die Benachrichtigungen den Empfänger erreichen. Ans diesem Grund besteht bei dem verteilten Eventmeeha- nismns von Jini die Möglichkeit, zwischen dem Eventauslösor und dem Empfänger ein Objekt dazwischen zu schieben. Dieses Proxy-ähnliche Objekt kümmert sich dann um die korrekte Weiterleitung der Benachrichtigungen.

Folgende Objekte sind an einem verteilten Event system beteiligt:

- ein Objekt, das Interesse an einem Event meldet
- ein Objekt, in dem sich ein Event ereignet, der Event Generat or
- ein Empfängorobjokt, der EvontListonor (dies kann, muß aber nicht das Objekt sein, welches sich als Interessent registriert hat)

Zuerst meldet sich also das Objekt, mit dem Interesse an einem bestimmten Event, bei dem EvontGonorator an. Die Registrierung erfolgt mit Hilfe des Leasing-Mechanismus (siehe 2.4.1), d.h. sie besteht nicht dauerhaft, sondern nur für einen bestimmten Zeitraum und muß periodisch erneuert werden. Findet diese Zustandsänderung beim EvontGono­rator statt, erzeugt er ein RemotEvent-Objekt und schickt diese an den EvontListonor. Dies ist schematisch in Abbildung 2.10 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: Schema eines verteilten Event systems

Die erzeugten RemotEvent-Objekte erhalten eine Sequenznummer. Da die Events in einem verteilten System in der falschen Reihenfolge beim Empfänger ankommen können, kann so sicher gest eilt werden, dass es zu keiner Verwechselung zwischen diesen verschie­den verteilten Ereignissen kommt.

2.5 Jini-Services

Das wichtigste Konzept der Jini-Architektur ist der Service. Ein Service ist eine Einheit, die von einer Person, einem Programm oder von einem anderen Service benutzt werden kann. Ein Service kann z.B. sein :

- Rechenleistung
- Speicher
- Hardwarekomponenten
- Programm
- ein Kommunikationskanal zu einem anderen Nutzer
- ein Nutzer selbst.

Es wäre möglich, dass ein Minicomputer für eine Berechnung Hauptspeicher eines Groß­rechners benutzt. Genauso kann man sich vorstellen, einen Dienst bereitzustellen, der die Konvertierung aus dem Format eines Textverarbeitungsprogrammes in ein anderes anbietet. Ein Jini-System besteht aber nicht nur aus Clients und Servern. So lassen sich die einzelnen Komponenten für bestimmte Aufgaben beliebig kombinieren. Ein Dienst kann sich anderer bedienen, und der Client eines Dienstes kann wiederum Dienst eines Clients sein.

Ein Service ist durch sein Interface und weitere Attribute genau spezifiziert. Diese At­tribute können den Service, seine Lokalität und Leistungsfähigkeit genauer beschreiben. Die technsichen Anforderungen an ein Gerät oder ein Programm, welches als Jini-Dienst fungieren möchte, sind relativ gering. Der Dienst, oder ein anderes Programm in dessen Auftrag, muß folgendes gewährleisten:

- Er muss in der Lage sein, TCP/IP-Verbindungen aufzubauen, dabei eine eigene IP-Adresse besitzen und über einen vollständigen Protokollstack verfügen, der die Fähigkeit zum Senden und Empfangen von Multicast-Nachrichten besitzt.
- Durchführen des Discovery-Vorgangs, um mindestens einen Lookup-Service ausfin­dig zu machen
- Registrierung bei einem Lookup-Service, wobei ein Proxy-Objekt hinterlassen wer­den muss, welches sich Clients herunterladen können, um den Dienst zu nutzen.
- Muß sich darum kümmern, daß die Leases seiner Lookup-Registrierung verlängert werden, solange der Dienst verfügbar ist.

Einfach gesagt, wird lediglich ein Proxy-Objekt benötigt, welches beim Lookup-Service hinterlegt wird, und über welches ein Client auf den Dienst zugreifen kann. Die anderen oben genannten Aufgaben können vom Dienst selbst oder von einem anderen Programm übernommen werden. Aber auch an die potentiellen Nutzer der Dienste, also den Clients, werden verschiedene Anforderungen gestellt:

- Der Client (der selbst auch wieder ein Dienst sein kann) muß in der Lage sein, mit Hilfe des Discovery-Mechanismus mindestens einen Lookup-Service ausfindig zu machen.
- Erhalten des Proxy-Objekts des Dienstes. Das Auffinden dieses Dienstes erfolgt, in dem der Client die Attribute, die beim Lookup-Service gespeichert sind, überprüft und sich für den passenden Dienst entscheidet.

Auch auf der Client-Seite ist alles relativ einfach. Sobald der entsprechende Dienst beim Lookup-Service gefunden wurde, kann dessen Proxy-Objekt von dort heruntergeladen werden. Der Client ist dann in der Lage den Dienst wie ein Objekt zu benutzen, welches ihm schon zur Compile-Zeit bekannt war.

2.6 Realsierung von Services

Welche Anforderungen Jini-Services erfüllen müssen, um an einer Gemeinschaft teilneh­men zu können, wurde bereits in 2.5 besprochen. In diesem Abschnitt soll es nun um die verschiedenen Realisierungsmöglichkeiten gehen. Zum einen werden verschiedene Device­Architekturen vorgestellt, zum anderen wird kurz besprochen, wie man ein Jini-Device als Java-Objekt, JavaBean oder als Enterprise JavaBean realisiert.

2.6.1 Device-Architektur

Ein vermittelter Jini-Service besteht grob aus zwei Teilen: dem Client und dem Server. Beide werden eventuell auf unterschiedlichen Rechnern und dadurch auch in verschiede­nen JVM’s ausgeführt. Hieraus ergeben sich nun verschiedene Möglichkeiten, eine solche verteilte Architektur zu realisieren. Vor allem vor dem Hintergrund, dass Jini-Services Aufgaben übernehmen sollen, wofür Rechner mit einer abgespeckten oder gar keiner JVM zum Einsatz kommen. Da die Kommunikation zwischen Client und Server über RMI erfolgt, muß für den Client und den Server direkt oder indirekt eine JVM vorhan­den sein, die über die Mechanismen von RMI verfügt. Aus diesen Tatsachen ergeben sich die folgenden 3 Architekturmöglichkeiten:

- Jeder Jini-Service besitzt eine vollwerige Java 2 - JVM
- Mehrere Services teilen sich eine vollwerige Java 2 - JVM
- Services greifen via Proxy auf eine vollwerige Java 2 - JVM zu

Die erste der 3 Möglichkeiten stellt die wohl naheliegendste und einfachste dar. Hierbei wird der Jini-Service auf einem Rechner ausgeführt, der über einen Netzwerkanschluß via TCP verfügt und auf Grund seiner Rechen- und Speicherkapazität in der Lage ist eine vollwertige Java2 - JVM auszuführen (siehe Abbildung 2.11). Vollwertige JVM soll hier heißen, das RMI und Mechanismen von Jini, Discvovery/Lookup/Join, unterstützt werden. Bei der Implementierung der Clients und Services kann also auf die gesamten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.11: cino JVM jo Service

technischen Möglichkeiten von Java zuriiekgegriffen werden. Der Service kümmert sieh selbst um das Auflinden von Lookup-Service und die Registrierung bei ihnen.

Bei der zweiten Arehitekturmögliehkeit (siehe Abbildung 2.12) teilen sieh mehrere Services eine JVM. Das Grundprinzip ähnelt dem der ersten Variante. Der Unterschied besteht darin, dass durch die Aufteilung einer JVM wertvoller Speicher auf dem Server eingespart wird. Jedoch wird eine zusätzliche Software benötigt, die das Auffinden von Lookup-Services und das Registrieren für die einzelnen Services erledigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.12: mehrere Services je JVM

Bei der dritten Möglichkeit (siehe Abbildung 2.13) werden Geräte ohne eigene JVM in ein Jini-System integriert. Hierbei handelt es sieh um Geräte die nur über sehr geringe oder gar keine Reehenleistung, jedoch über eine einfache E/A-Mögliehkoit verfügen. Die Steuerung und Bereitstellung der Services übernimmt hierbei ein zentraler jini-fähiger Rechner. Die Kommunikation zwischen den Services und dem Proxy-Rechner erfolgt über ein proprietäres Netzwerkprotokoll.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.13: Proxy zwischen Service und Client

Für die Implementierung der einzelnen Services stehen nun die verschieden Techni­ken von Java zur Verfügung. Je nach Einsatz des Services kommt eins der folgenden 3 Konzepte zum Einsatz:

- Realisierung als reines Java-Objekt
- Realisierung als JavaBean
- Realisierung als Enterprise JavaBean

Um die weiteren Betrachtungen etwas zu vereinfachen, wird davon ausgegangen, dass die Kommunikation zwischen Client und Service via RMI erfolgt.

2.6.2 Java-Objekt

Die einfachste Art der Erstellung eines Jini-Services ist die der Implemtierung als rei­nes Java-Objekt. Auf der Client-Seite mufe hierzu ein Interface des Services vorhanden sein. Auf der Server-Seite müssen verschiedene Klassen und Interfaces von Jini und RMI benutzt bzw. implementiert werden.

2.6.3 JavaBeans

Es liegt nahe, dass man Jini-Service mit Hilfe des Java-Komponontonmodoll, den Java­Beans, zu realisieren. Das hat neben einem wohlbekannten Programmiormodoll auch den Vorteil, dass zur Manipulation von Jini-Attributen Standart-JavaBaons-Moehanismon verwendet werden können. Diese Maehanismen kann dann z.B. auch ein Systemadmini­strator benutzen, um nachträglich die Attribute eines registrierten Service zu verändern. Durch die Realisierung durch JavaBeans ist es aber auch einfacher möglich, den Service so zu implementieren, dass er, nur durch Änderung von Attributen, für andere ähnlich Geräte wiederverwendet werden kann.

2.6.4 Enterprise JavaBeans

Ein Enterprise JavaBoan kann indirekt über ein JavaBoan an einem Jini-System tcilneli­men. Das JavaBoan dient hierbei als eine Art Proxy für das Enterprise JavaBoan. Die

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.14: Integration von Enterprise JavaBeans in ein Jini-Netzwerk

Kommunikation zwischen beiden Beans erfolgt hierbei über RMI. Diese Lösung weist vor allem den Vorteil auf, dass hierbei keinerlei Änderungen innerhalb des Enterprise JavaBoan vorzunehmen sind. Es kann somit, dem Widerverwendungsgedanken folgernd, auch in einem anderen Kontext verwendet werden.

3 Jini und Palm

In diesem Kapitel soll es nun darum gehen, wie ein Palm™ III Handheld in eine Jini- Umgebung integriert werden kann. Zuerst werden die technischen Voraussetzungen auf der Seite des Palm III untersucht und bewertet. Hierzu wird die dafür verfügbare Virtual Machine (K Virtual Machine) vorgestellt und Aussagen über die möglichen Netzwerkver­bindungen getroffen. Daraus werden dann verschiedene Architekturmöglichkeiten (siehe 2.6.1) vorgeschlagen und deren Vor- und Nachteile gegeneinander abgewogen.

3.1 Technische Voraussetzungen

Die Integration von Geräten in eine Jini-Umgebung gestaltet sich dann am einfachsten, wenn das Gerät selbst über eine Java-VM verfügt. Diese sollte in der Lage sein, Objekten die Kommunikation via RMI zu ermöglichen und die für die Jini-Umgebung notwendigen Mechanismen unterstützen. Demzufolge erscheint es sinnvoll, als erstes die auf dem Palm III lauffähige K Virtual Machine genauer zu betrachten.

3.1.1 K Virtual Machine

Sun hat seine Java-Technologie seit der Version 2 in drei verschiedene Versionen auf­geteilt: die Java 2 Platform Enterprise Edition (J2EE), die Java 2 Platform Standard Edition (J2SE) und die Java2 Platform Micro Edition (J2ME). Jede von ihnen ist für einen bestimmten Einsatzbereich konzipiert.

- Java 2 Platform Enterprise Edition. Für serverbasierende Anwendungen im Unter- nehmensb er eich.
- Java 2 Platform Standard Edition. Für normale Desktopanwendungen.
- Java 2 Platform Micro Edition. Für verschiedene kleine Endgeräte wie Telephone, Pager, PDA’s, set-top Boxen oder Terminals.

Für die einzelnen Versionen von Java stehen nun verschiedene Virtual Machine’s zur Verfügung (siehe Abbildung 3.1). Für die Java 2 Platform Micro Edition ist dies die K Virtual Machine. Die K Virtual Machine (KVM) (siehe [KVM99]) ist eine sehr kompak­te Java-VM die speziell für Geräte mit geringen Resourcen entwickelt wurde. Auf einem Palm Handheld ist die KVM ab dem Betriebssystem PalmOS v. 3.0 lauffähig. Sie benö­tigt hier, je nach Konfiguration, gerade einmal 128-256KByte Speicher. Jedoch ist diese

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Übersicht der .Java-Versionen und ihre Vitual Machine

Virtual Machine in ihrer Funktionalität kaum mit der eines normalen PC’s, welche auch schnell einen Umfang von mehreren MBytes annehmen kann, vergleichbar. Viele Funktio­nen wurden auf Grund der Performance und des Speicherangebotes nicht implementiert. Es kann nur auf Teile der von .Java bekannten Packages java, lang, java, io, java.net, java, ut il zurückgegriffen werden. Hierdurch werden verschiedene grundlegende Opera­tionen, wie Event- und Threadsliandling, einfache Datentypen, Streams für Ein/Ausgabe usw., bereitgestellt, um einfache .Java-Anwendungen zu entwickeln. Außerdem steht das Package com.sun.kjava zur Verfügung, welches hauptsächlich Klassen beinhaltet, die den Zugriff auf einfache grafische Elemente und die databa,se-Files des Palm’s ermöglichen. Mit Hilfe des java.net Packages ist man in der Lage, z.B. eine TCP/IP-Verbindung zu einer anderen Anwendung aufzubauen, was für ein .Jini-Service unbedingt erforderlich ist. Die K Virtual Machine verfügt jedoch nicht über RMI-Funktionalität. Auch die Klassen und Interfaces, die zum Suchen eines Lookup-Service und zur Registrierung eines Ser­vices im .Jini-Netzwerk benötigt werden, sind nicht Bestandteil der K Virtual Machine . Es besteht auch keine Möglichkeit die benötigten Packages zusätzlich zu installieren, wie man es z.B. von einer Virtual Machine auf einem PC gewöhnt ist.

3.1.2 Netzwerkverbindung

Der Palm III ist dafür ausgelegt, mit Hilfe eines Mobilfunktelefons oder eines Modems, eine TCP/IP-Verbindung via PPP-Verbindung^[4] zu einem DFÜ-Server aufzubauen. Dies wäre für das hier zu implementierende Beispiel nicht gerade praktikabel, aber für zu­künftige Anwendungen interessant. Es gibt jedoch auch die Möglichkeit mit Hilfe der Docking-Station (siehe Į3C098J), welche an die serielle Schnittstelle eines PC’s ange-schlossen wird, eine PPP-Vcrbindung z.B. zu einem WinNT-Roehner aufzubauen. Hierzu gibt es für alle Windows-Plattformen ein Shareware-Programm der Firma MoehaSoft (www.mochasoft.dk), welches den Namen “Mocha W32 PPP” trägt. Es nimmt einem die entsprechende Konfiguration des Windows-Rechner ab. Man braucht das Programm nur anzustarten, und die Schnittstelle zu wählen, an der die Docking-Station des Palm angesehlossen ist. Nach dem Aufbau der Verbindung vom Palm aus steht eine vollwertige TCP/IP-Verbindung zur Verfügung.

3.2 Architekturmöglichkeiten

Aus den unter 3.1 gemachten Äußerungen zu den technischen Gegebenheiten für die Inte­gration eines Palm III in eine Jini-Umgebung, ergeben sich verschiedene Konfigurationen für die praktische Realisierung. Die folgenden drei Möglichkeiten sollen kurz besprochen werden, obwohl eine davon bis jetzt noch nicht realisierbar ist:

- Autonomer Jini-Client
- Via Proxy (Java Client)
- Via Proxy (PalmOS Client)

klan beachte, dass in diesen Betrachtungen, und auch in dem in Kapitel 5 folgendem Beispiel, anders als in 2.6.1 der Service sich auf einem Rechner befindet, der eine voll­wertige Java 2-VM besitzt. Der Client befindet sich jedoch auf dem Palm, welcher nur über eine spartanisch ausgestattete Virtual Machine verfügt.

3.2.1 Autonomer Jini-Client

Wie schon in 2.6.1 erwähnt ist dies die naheliegendste und einfachste Lösung. Der Client

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Architektur mit vollwertigem Jini-Client

solbor kümmort sich um dio Sucho eines Lookup-Sorvicos und dor Nachfrage nach pas­senden Services. Hat er einen ansprechenden Service gefunden, lässt er sich vom Lookup- Service den entsprechenden RMI-Stub^[5] zukommen und kann dann darüber direkt mit dem Service kommunizieren. Diese Lösung ist jedoch bis heute noch nicht umsetzbar, da die K Virtual Machino weder über Mechanismen wie Discovery /Join (siehe 2.3.1 und 2.3.2) noch über RMI-Funktionalität verfügt. Wenn man aber die schnelle Entwicklung von Java betrachtet, so wird es bestimmt in absehbarer Zeit eine Virtual Machino für den Palm geben, die über diese Fähigkeiten verfügt, womit der Palm zu einem vollständigen Client oder Service wird.

3.2.2 Via Proxy (Java Client)

Kommen wir nun zu der Lösung mit einem Proxy, welche mit der dritten Möglichkeit aus 2.6.1 vergleichbar ist. Der Client verfügt zwar über eine Virtual Machino, ist aber nicht in der Lage, selber im Jini-System aktiv zu werden. Er bonötgt einen Proxy auf einem Rechner mit vollwertiger JVM, der dann für den Client nach passenden Services sucht und auch via RMI mit dem ausgewählten Service kommuniziert (siehe Abbildung 3.3). Die Kommunikation zwischen dem Client und dem Proxy erfolgt über ein pro-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Architektur mit Proxy und Client als Java-Objekt

prietäres Netzprotokoll. Der Client selbst wurde als Java-Anwendung implementiert, da eine Virtual Machino zur Verfügung steht, und man so die Vorteile und Einfachheit der objekt orientierten J ava-Programmiorung nutzen konnte.

3.2.3 Via Proxy (PalmOS Client)

Dio dritto Möglichkoit ist fast idontisch mit dor zwoiton. Jodoch wurdo dor Cliont als roino PalmOS-Anwondung implomontiort. Dioso Mothodo wäro haupsächlich aus Performanee- und Rosourcongründon zu wählon. Roino PalmOS-Anwondungon sind um oinigos schnollor und bonötigon nur oinon Bruchtoil an Spoichor gogoniibor don Java-Anwondungon. Dor Nacht oil wäro aber, dass man boi dor Implomontiorung auf Sprachen wie C oder C zurückgreifen müsste, wodurch sich die Programmerstellung nicht gerade vereinfacht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Architektur mit Cliont als roino Palm-Anwendung

Abschließend kann man folgendes zu den Architokturmöglichkoiton sagen: Wären für dio KVM entsprechende Packages für RMI und Diseovor/Join verfügbare, steht wohl außer Frage, das die erste Möglichkoit die einfachste und sinnvollste Lösung darstellt. Da dies aber nicht der Fall ist, schränkt sich die Auswahl auf die letzten beiden ein. Hier wäre die mit dem Java-Client zu bevorzugen, da das Java-API für die KVM übersichtlich ist und so die Implementierung des Client relativ einfach ist. Vor allem wenn man bedenkt, dass man für die Entwicklung des Proxy’s und den Service sowieso auf Java zurückgreifen muß. Da kann man auch auftretende Pcrformanccvcrlustc in Kauf nehmen.

4 Jim Einrichten

Bevor man nun mit der Implementation eigener Dienste beginnen kann, müssen selbst­verständlich die Softwarekomponenten von Jini eingerichtet werden. Als grundlegende Voraussetzung sollte Java 2 oder eine neuere Version installiert sein. Ist dies nicht der Fall, sollte man das zunächst nachholen. Danach kann man mit der Installation von Jini beginnen. Dieses Dokument und auch das nachfolgende Beispiel stützt sich auf die Ver­sion 1.0.1 von Jini. Es gibt zwar bereits eine Version 1.1, aber diese befindet sich noch im Beta-Status.

4.1 Installation

Die Version 1.0.1 von Jini kann bei Sun Microsystems auf der Jini-Homepage http: //www.sun.com/products/jini nach Akzeptierung der Lizenzbedingungen herunterge­laden werden. Es werden dort drei verschiedene Packete zum Herunterladen angeboten.

- Jini Starter Kit umfaßt die elementaren Bestandteile der Jini-Infrastruktur, ein­schließlich des Quellcodes der Schnittstellen und Bibliotheken, die Java-Programmen das Zusammenarbeiten mit den wesentlichen Jini-Diensten ermöglichen. Beinhaltet außerdem Implementierungen mehrerer grundlegender Jini-Dienste.
- Jini Technology Compatibility Kit beinhaltet Quellcode, mit dem die Kompatibili­tät von Jini-Diensten und Anwendungen getestet werden kann.
- JavaSpaces Technology Kit beinhaltet JavaSpaces, ein Speicherdienst der auf Jini aufsetzt.

Für die Ausführungen in diesem Dokument wird nur das Jini Starter Kit benötigt. Jetzt muß nur noch der CLASSPATH entsprechend dem Verzeichnis, in dem Jini installiert wurde, angepasst werden, damit die zur Entwicklung eigener Dienste notwendigen Klas­sen und Interfaces vom Java-Compiler gefunden werden. Hierbei handelt es sich haupt­sächlich um die Packages jini-core, jar, jini-ext. jar und sun-util, jar, welche sich im Unterverzeichnes lib des Jini-Installationsverzeichnis befinden.

4.2 Start der Basisdienste

Wenn wir nun eine Jini-Umgebung benutzen möchten, benötigt man zur Laufzeit eine bestimmte Netzwerkinfrastruktur. Hierbei handelt es sich um verschiedene Dienste, die eventuell auf einem dafür vorgesehenen Rechner oder aus Redundanzgründen auch auf mehreren Servern laufen müssen. Alle notwendigen Dienste werden entweder mit Java oder Jini ausgeliefert. Der Start der Dienste kann entweder mit Hilfe des Programms “StartService” oder einzeln von der Kommandozeile aus erfolgen.

4.2.1 StartService

Mit Jini wird eine einfach bedienbare GUI^[6] für das Starten der benötigten Dienste mitge­liefert. Die GUI verbirgt keine Einzelheiten der Dienste, sondern soll lediglich das Einrich­ten der Jini-Umgebung erleichtern. Das Programm wird mit folgender Kommandozeile gestartet:

Abbildung in dieser Leseprobe nicht enthalten

Mit Hilfe dieser GUI kann man nun den HTTP-Server, den RMI-Activation-Daemon und der Lookup-Service starten.

4.2.2 Start der Dienste einzeln

Die einzelnen Dienste können aber auch per Hand von der Kommandozeile aus gestartet werden. Wichtig hierbei ist, dass eine bestimmte Reihenfolge eingehalten wird. Als erstes wird der HTTP-Server mit folgendem Kommando gestartet:

Abbildung in dieser Leseprobe nicht enthalten

Als Parameter wird die Portnummer und das Verzeichnis, in dem sich der herunterladbare Code befindet, übergeben. Der Start des RMI-Activation-Daemon gestaltet sich relativ einfach, da er sich im bin Verzeichnis von Java befindet. Am Prompt braucht man nur

rmid

einzugeben. Zum Schluß muß noch der Lookup-Service gestartet werden. Dies gestaltet sich etwas schwieriger, da mehrere Parameter übergeben werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Als erstes wird eine Sicherheitsrichtliniendatei übergeben, welche bestimmt, auf welche Resourcen der Lookup-Service zugreifen kann. Danach folgt das Jar^[7] -File, welches den Code für den Lookup-Service enthält. Als nächstes folgt eine URL, die angibt, an welcher Stelle sich die Code-Teile des Lookup-Service befinden, die von Anfragenden herunterge­laden werden können. Die zweite Sicherheitsrichtliniendatei liefert Informationen für den RMI-Activation-Daemon. Danach folgt noch ein Temp-Verzeichnis, in das verschiedene Log-Files geschrieben werden. Abschließend erfolgt die Angabe verschiedener Gruppen, die der Lookup-Service unterstüzt.

5 Beispiel für Palm

Kommen wir nun zur praktischen Umsetzung der Integration eines Palm’s in eine Jini- Umgebung. Hierzu soll das nun folgende Beispiel dienen. In diesem Szenario soll die Be­rechnung der größten Primzahl unter einer bestimmten Schranke erfolgen. Für die Berech­nung, soll die Anwendung auf dem Palm einen Service, der sich auf einem PC befindet, benutzen. Zum Vergleich wird diese Berechnung auch auf dem Palm lokal durchgeführt, um einen Eindruck von der Zeitersparnis zu bekommen. Der Service ist in seiner Funk­tionalität nicht gerade umwerfend, jedoch sollte es zum Darstellen der Jini-Architektur vollkommen ausreichen.

Wie schon in 3.2 anklang, ist die Implementierung eines Java-Clients auf dem Palm und eines Proxy’s auf einem PC die im Moment einfachste und sinnvollste Architektur­lösung. Deshalb wurde sie auch für dieses Beispiel herangezogen. Bei dieser Architektur­lösung müssen nun verschiedene Komponenten implementiert werden. Hierbei handelt es sich grob um die folgenden drei:

- der Dienst
- der Proxy
- und der Java-Client auf dem Palm,

welche im weiteren Verlauf genauer besprochen werden. Zuvor müssen jedoch noch be­stimmte technische Voraussetzungen sichergestellt werden. Folgendes muß vorhanden sein, damit dann auch die implementierten Architekturkomponenten lauffähig sind:

- Palm III mit installierter K Virtual Machine
- Rechner, auf dem ein HTTP-Server, der RMI-Activation-Daemon und ein Lookup- Service gestartet ist
- Server, auf dem der Service zur Verfügung gestellt wird
- Rechner, auf dem der Proxy läuft, und über eine serielle Schnittstelle mit dem Palm III verbunden ist.

Die letzten drei Elemente, in der oben aufgeführten Liste, können zur Vereinfachung auch alle durch ein und demselben Rechner repräsentiert werden. Bei zukünftigen praktischen Lösungen sollte man aber davon ausgehen, dass diese drei Elemente sich irgendwo verteilt in einem Netzwerk befinden können.

5.1 Dienst

Beim Design des Dienstes sollte man zuerst nur sein charakteristischen Eigenschaften betrachten, d.h. die Funktionalität, die die Komponente nach außen hin zur Verfügung stellt. Erst in späteren Schritten wird die innere Struktur des Dienstes festgelegt. Diese charakteristischen Eigenschaften werden mit Java-Interfaces^[8] beschrieben. Dieser hier zu implementierende Dienst, der ab sofort den Namen PrimeNumberService trägt, soll über eine sehr einfache Funktionalität verfügen, nämlich über eine Methode, die die größte Primzahl unter einer übergebenen Schranke zurückgibt. Das Interface sieht dann wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Wie man sieht, wurde das Interface noch um RMI-Dienste erweitert. Diese werden für die spätere Kommunikation zwischen Dienst und Client benötigt. Außerdem wird bei der RMI-Kompilation gleich ein RMI-Stub gebildet, welcher die Eigenschaften eines Stellver­treterobjekts besitzt. Dieser Stub wird dann während des Join-Mechanismus direkt beim LookupService hinterlegt. Wie man aus der RMI-Spezifikation entnehmen kann, ist jede Remote-Methode in der Lage, eine java.rmi.RemoteException auszulösen. Demzufolge muß die Deklaration entsprechend modifiziert werden.

Den eigentlichen Dienst beinhaltet die Klasse PrimeNumberlmpl. Da es sich um einen RMI-Dienst handelt, ist die Klasse von java.rmi.UnicastRemoteObject abgeleitet und implementiert logischerweise die oben definierte Schnittstelle:

Abbildung in dieser Leseprobe nicht enthalten

als RemoteException-auslösend angegeben werden müssen. Damit wäre die Funktionalität des Dienstes komplett. Der Dienst benötigt nun nur noch die Möglichkeit, sich einen Lookup-Service zu suchen und sich dort zu registrieren. Zur besseren Übersicht wurde hierfür eine eigenständige Anwendung, anmeldeApp, geschaffen, obwohl der Dienst das auch selbst übernehmen könnte. Dieser AnmeldeApplikation wird der zu registrierende Dienst als Parameter übergeben. In diesem Fall:

Abbildung in dieser Leseprobe nicht enthalten

welche von der GUI ausgelöst wird, werden nun alle verfügbaren LookupServices ausfin­dig gemacht. Dies geschieht via Multicast-Request-Protokoll mit Hilfe der Klasse Lookup- Discovery, die den Zugriff auf das Netzprotokoll kapselt. Dadurch braucht sich der Ent­wickler nicht um die Netzprotokolldetails zu kümmern. Damit die AnmeldeApplikation über gefundene LookupServices informiert wird, muß sie das DiscoveryListener-lnterïace implementieren.

Abbildung in dieser Leseprobe nicht enthalten

Die darin definierte discovered Methode wird nach dem Entdecken eines LookupServices aufgerufen.

void discovered (DiscoveryEvent e)

Das übergegebene DiscoveryEvent-Objekt beinhaltet Informationen über den gefunde­nen LookupService. Danach erfolgt nun die Registrierung des Services mit Hilfe des Join- Protokolls. Hierzu dient die Klasse JoinManager, welche die Einzelheiten der Registrie­rung übernimmt.

Abbildung in dieser Leseprobe nicht enthalten

Als Parameter werden der Klasse das zu registrierende Java-Objekt obj (in diesem Fall ist es ein PrimNumberlmpl-Objekt), eine Menge von Attributen attrSets, eine Menge von Gruppen groups, an denen der Service teilnehmen möchte, eine Menge von Loo­kupServices locators (welche durch die LookupLocator-Objekte repräsentiert werden), ein ServicelDListener-Objekt listener, welches die Benachrichtigung über das Setzen der Service-ID entgegennimmt (in diesem Fall übernimmt das die Anmelde Anwendung, die durch Implementierung des ServicelDListener-Interface die entsprechenden Eigenschaf­ten erhält) und zum Schluß ein LeaseRenewalManager, der alle Einzelheiten des Leasing (siehe 2.4.1) für den zu registrierenden Service übernimmt, übergeben. Hiermit ist der Service nun bei einem LookupService angemeldet und für die Vermittlung an interessierte Client’s bereit. Der Zusammenhang der verwendeten Klassen und Interfaces wird auch nochmal in der Abbildung 5.1 deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.1: UML-Darstellung der Dionsto-Struktur

5.2 Client

Kommon wir nun zu dom potontiollon Nutzer, dos obon implomontiorton Sorvicos, dom Cliont. Diosor ist, wio schon weiter oben erwähnt, auf Grund der technischen Gegeben­heiten, in zwei einzelne Elemente aufgespalten.

5.2.1 Proxy auf dem PC

Der Proxy hat die Aufgabe, den Client in der Jini-Umgebung zu vetroten, da dieser nicht direkt an den Jini-Mechanismen toilnohmon kann. Hierzu wird eine TCP/IP-Verbindung zwischen dem Proxy und dem Client aufgebaut. Dadurch kann der Proxy Kommandos vom Client empfangen, und dann die gewünschten Operationen im Jini-System ausfüh­ren. Da die Virtual Machine auf dem Palm über Netzwerkfunktionalität verfügt und auch alle anderen Voraussetzungen (z.B. hardwareseitig) für eine Netzwerkverbindung gegeben sind, ist es relativ einfach, Verbindung via Socket zwischen Palm und Client aufzubauen.

Zur besseren Übersicht wurde der Aufbau der Netzwerkverbindung in einem geson­derten Objekt zusammengefaßt. In diesem SocketListener-Objekt wird ein ServerSocket,- Objekt erzeugt, welches an einem bestimmten Port auf Anfragen eines Clients wartet. Sobald eine Verbindungsanfrage von einem Client eintrifft, wird von der accept()-Methode ein Socket-Objekt erzeugt, über das man dann direkt mit dem Client kommuniziern kann. Mit Hilfe des Socket-Objekts kann man dann einen Input- und einen OutputStream er­zeugen, mit denen dann Informationen zum Client geschrieben oder vom Client gelesen werden können. Diese beiden Streams werden dann im eigentlichen Proxy, der Klasse palm,proxy, weiterverwendet.

Um die Kommunikation zwischen Proxy und Client auf dem Palm nicht übermäßig kompliziert zu gestalten, werden einfach ein paar Kommandos definiert, die dann direkt an den In- oder OutputStream übergeben werden. Der Client auf dem Palm schickt die Kommandos an den Proxy, der dann die gewünschte Aktion ausführt. Dies sind im einzelnen:

- SLUS = “Search LookupSertvice”, veranlaßt den Proxy nach vorhandenen Lookup- Services zu suchen
- SS = “Search Service”, veranlaßt den Proxy nach vorhandenen Prim,eNum,berSer- vices zu suchen
- CS = “Call Service”, veranlaßt den Proxy die Methode getHighestPrimeNumber des PrimeNumberService aufzurufen
- EXIT = “Exit”, veranlaßt den Proxy die Streams zu schließen, und die Socketver- bindung zu beenden

Sobald der Proxy das Komando “SLUS” vom PalmPilot empfängt, startet er die Suche nach LookupServices, wie bei der AnmeldeApplikation, via Multicast-Request-Protokoll mit Hilfe eines LookupDiscovery-Objékt. Damit der palm,proxy über gefundene Lookup­Services informiert wird, muß er das DiscoveryListener-Interface implementieren.

public dass palmproxy implements Discovery-Listener {}

Die gefunden LookupServices melden sich dann mit Hilfe der discovered Methode, wel­cher ein DiscoveryEvent-Objekt mit den Daten des LookupService übergeben wird. Dem PalmPilot werden daraufhin die Hostnamen der gefunden LookupServices übermittelt. Als nächstes wird nun nach Empfang des Komandos “SS”, auf allen gefundenen Lookup­Services nach registrierten Prim eNum berServices gesucht. Für alle weiteren Schritte wird zur Vereinfachung des Beispiels, der zuerst gefundene Prim,eNum,ber Services verwendet. Dem PalmPilot wird mitgeteilt, dass ein Prim,eNum,berService gefunden wurde. Nachdem der Proxy das Komando “CS” empfangen hat wird die Methode getHighestPrimeNumber des Prim,eNum,ber Services mit Hilfe des bei der Servicesuche erhaltenen RMI-Stub auf­gerufen. Die Verarbeitung der Anfrage erfolgt dann logischerweise auf der Server-Seite. Das Ergebnis landet wieder beim Proxy, von wo aus es dann dem PalmPilot übermittelt wird.

Dio Abhängigkeiten der benutzten Klassen und Interfaces untereinander sind in der Abbildung 5.2 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.2: UML-Darstellung der Proxy-Struktur

5.2.2 Client auf dem Palm

Auf der Palmsoito kann man, auf Grund der abgospoekton K Virtual Machine, für die Anwendungsentwicklung nur auf einen sehr eingeschränkten Bereich an Funktionen zu- riiekgreifen (siehe 3.1.1). Dies war auch der Grund, welshalb die Proxylösung gewählt wurde. Jedoch ist man in der Lage, eine Net zwerk Verbindung zu einem Proxy aufzu­bauen (siehe 3.1). Die Palmanwondung besteht im wesentlichen aus zwei verschiedenen Klassen, palmcMent und connectspotlet, welche beide von der Klasse Spottet abgeleitet sind.

Abbildung in dieser Leseprobe nicht enthalten

Dioso Klasso kann man mit clor Framo- odor Dialog-Klasse dos AWT^[9] -Packagos dor Java 2 Platform Standard Edition vorgloichon. Dio palmdient-Klasso orzongt nur oin Startbild und initialisiort dio Klasso connextspotlet, wolcho dio oigontlicho GUI und Funktionali­tät dor Anwondung boinhaltot. Zum Aufbau dor Netzwerkverbindung zum Proxy wird von dor coonextspotlet-Klasso oin Soc&ef-Objokt orzongt, wodurch oin InputStream und oin OutputStream zur Verfügung stehen. Dioso beiden Streams werden direkt zum Son­den und Empfangen von Kommandos, von oder zur PalmProxy-Anwendung, verwendet. Durch Versenden von vorher festgelegten Kommandos (siehe 5.2.1) an den Proxy worden dann die gewünschten Aktionen ausgeführt. Mit Hilfe dor Methode

public void readlnputCint Mode) {}

wird die entsprechende Antwort gelesen. Die verschiedenen Modi dienen dazu, dass die Antworten entsprechend interpretiert werden. Außerdem verfügt die Klasse connextspot- let über verschiedene andere Methoden, die aber hauptsächlich zur Reaktion auf das Betätigen eines Buttons benötigt werden. Die Struktur der Palmanwendung ist auch nochmal in der Abbildung 5.3 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.3: UML-Darstollung der Palm-Client-Struktur

Um den Zeitgewinn der Primzahlberechnung auf einem anderen Rechner besser ein­schätzen zu können, wird die gleiche Berechnung auch lokal auf dem Palm ausgeführt. Da man durch die technischen Voraussetzungen eingeschränkt ist, wurde für die Prim- zahlbereehnung ein Algorithmus gewählt, der ohne die Verwendung von Arrays arbeitet^[10]. Dieser Algorithmus wurde auch für den PrimeNumberServiœ übernommen, um gleiche Bedingungen zuschaffon.

5.3 Ausführen des Beispiels

Bevor das Beispiel ausgeführt werden kann, müssen die Klassen zuerst kompiliert werden. Bei dem Dienst auf der Serverseite ist zusätzlich zu beachten, dass nach dem Erzeugen der dass-Files noch, mit Hilfe des RMI-Stub-Generator rmic von Klassen mit Remote-Code, die Stub-Klassen zu erzeugen sind. Die Kompilierung der Proxy-Anwendung gestaltet sich einfacher, da nur die dass-Files erzeugt werden müssen. Bei der Palmanwendung muß eine andere Vorgehensweise eingehalten werden, da die dass-Files nicht direkt auf dem Palm geladen werden können, sondern nur prc-Files^[11]. Also werden zuerst mit Hilfe eines normalen Javacompilers die dass-Files erzeugt, wobei sich die Packages für die KVM-Anwendungen im dasspath befinden müssen. Danach werden diese Files, mit Hilfe eines zusätzlichen Tools, in ein prc-File zusammengefaßt.

java palm.database.MakePalmApp palmclient

Dieses kann dann, unter Verwendung des HotSync-Tools, auf dem Palm installiert wer­den.

Nachdem nun alles kompiliert ist, können wir das Beispiel in Aktion sehen. Hierzu müssen zuerst die Basisdienste gestartet werden, was ausführlich im Abschnitt 4.2 be­schrieben wurde. Danach wird der Dienst mit folgendem Befehl von der Kommandozeile aus gestartet:

Abbildung in dieser Leseprobe nicht enthalten

Als Parameter treten hier auf: Ein policy-File, welches die Zugriffsrechte des Dienstes regelt, danach folgt die Angabe des Codehase, das ist die Stelle, von woaus der RMI-Stub des Dienstes heruntergeladen werden kann. Zum Schluß folgt die Angabe der Anmel­deApplikation mit dem anzumeldenden Dienst und dem Parameter GUI, der bewirkt, dass die Anmelde Applikation mit einem Graphical User Interface gestartet wird.

Das Starten des PalmProxies gestaltet sich einfacher.

java -Djava security.policy=policy palmproxy

Der einzige Parameter ist hier ein policy-File, welches die Rechte des Proxies festlegt. Zum Schluß muß nur noch die Palmanwendung gestartet werden, was einfach mit Hilfe des Stiftes erfolgt. Die Bedienung der Anwendung palmclient ist recht einfach. Als erstes erscheint ein Connect-Button (siehe Abbildung 5.4). Durch dessen Betätigung wird eine Verbindung zum Proxy aufgebaut. Mit Hilfe des darauf erscheinenden SearchLUS-Button wird die Suche nach Lookup Services gestartet. Die Aktionen, die der Proxy ausführt, können auch in der Shell, in der er gestartet wurde, mitverfolgt werden. Der Name des ersten gefundenen LookupServiee wird zum PalmPilot übertragen und dargestellt. Da­nach kann durch betätigen des SearchService-Button ein PrimoNumborSorvieo gesucht werden. Wird ein entsprechender Service bei dem LookupServiee gefunden, wird dies an­gezeigt und es erscheinen zwei neue Buttons. Durch betätigen des Remote-Button wird

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.4: GUI der Palmanwendung palmdient

nun die größte Primzahl unterhalb von 2Õ000 mit Hilfe des Services auf dem Server er­mittelt. Es erscheint darauf das Ergebnis und die dafür benötigte Zeit in Millisekunden. Mit Hilfe des Local-Buttons wird die gleiche Berechnung auf dem PalmPilot ausgeführt.

6 Fazit

Wir haben gesehen, wie relativ einfach eine Integration eines Palm™ Handhelds in eine Jini-Umgebung erfolgen kann. Die Einsatzmöglichenkeiten können hierfür sehr verschie­den sein. Zum einen könnte man sich, wie in unserem Beispiel, die Auslagerung einer rechen- und speicherintensiven Berechnung vorstellen. Dies könnte z.B. bei der Erfas­sung von Meßdaten im Freien erfolgen. Mit Hilfe eines Mobilfunkgerätes kann der Palm dann eine Netzwerkverbindung aufbauen und nach einem Jini-Service Ausschau halten, der von einem Hochleistungsrechner angeboten wird, welcher dann die Auswertung der Daten vornehmen kann und die Ergebnisse wieder an den Palm schickt. Eine andere Möglichkeit wäre aber auch die Informationsbereitstellung. So könnte es einen Service geben, der einen Stadtplan zur Verfügung stellt, welcher von einer Person in einer frem­den Stadt benutzt werden könnte. Man könnte hier wohl noch eine Menge von Beispielen aufführen, jedoch scheint die in diesem Beispiel verwendete Architekturlösung im prakti­schen Einsatz nicht sehr vorteilhaft. Man benötigt unbedingt, neben Service, Client und Lookup Service, eine zusätzliche Instanz, den Proxy, der die Verbindung zum Jini-System aufbaut und im Weiteren die Kommuniaktion mit dem möglichen Service stellvertretend übernimmt. Dies ist nach meiner Meinung nur für Geräte sinnvoll, die über gar keine Ja­va Virtual Machine verfügen. Da es aber für den Palm eine Virtual Machine gibt, sollte es das Ziel sein, die Architekturlösung ohne Proxy (siehe 3.2.1) zu verwirklichen. Leider ist die K Virtual Machine bis jetzt dazu nicht in der Lage (siehe 3.1.1). Wenn man aber bedenkt, wie schnell sich die Javatechnologie verbreitet und weiterentwickelt hat, kann man davon ausgehen, dass es in absehbarer Zeit, auch für Geräte wie den Palm oder den Mobilfunkgeräten, eine Java Virtual Machine zur Verfügung steht, welche die direkte Teilnahme an einem Jini-System ermöglicht.

Anhang

Inhalt der CD

/Jini install 1 0 1

Das Jini Starter Kit. Umfaßt die elementaren Bestandteile der Jini-Infrastruktur, ein­schließlich des Quellcodes der Schnittstellen und Bibliotheken, die Java-Programmen das Zusammenarbeiten mit den wesentlichen Jini-Diensten ermöglichen. Beinhaltet außerdem Implementierungen mehrerer grundlegender Jini-Dienste und verschiedene Dokumenta­tionen.

/KVM

Das KVM-Package. Beihaltet die Kava Virtual Machine, die Libraries für die Entwicklung von Palmanwendungen, Dokumentationen und verschieden Beispielprogramme.

/Studienarbeit

Die eigentliche Studienarbeit. Im Unterverzeichnis /doc befindet sich die Studienarbeit als PostScript-Dokument. In den Verzeichnissen /Palm, /Service und /Proxy befinden sich jeweils die Binaries und Sourcen des entwickelten Beispiels.

/Mocha_W32

Das Programm Mocha V 32 PPP. Dient dazu, eine vollwertige TCP/IP-Verbindung via PPP zwischen Palm und WindowsPC aufzubauen.

Abbildungsverzeichnis

2.1 Statische Jini-Struktur

2.2 Zusammenhang der Jini-Bestandteile

2.3 Registrierung eines Java-Objekts als Jini-Service

2.4 Verwenden eines Services

2.5 Multicast-Request-Protokoll

2.6 Multicast-Announcement-Protokoll

2.7 Unicast-Discovery-Protokoll

2.8 Logische Struktur eines Jini-Netzwerkes

2.9 Zeitlicher Ablauf einer verteilten Transaktion

2.10 Schema eines verteilten Eventsystems

2.11 eine JVM je Service

2.12 mehrere Services je JVM

2.13 Proxy zwischen Service und Client

2.14 Integration von Enterprise JavaBeans in ein Jini-Netzwerk

3.1 Übersicht der Java-Versionen und ihre Vitual Machine

3.2 Architektur mit vollwertigem Jini-Client

3.3 Architektur mit Proxy und Client als Java-Objekt

3.4 Architektur mit Client als reine Palm-Anwendung

5.1 UML-Darstellung der Dienste-Struktur

5.2 UML-Darstellung der Proxy-Struktur

5.3 UML-Darstellung der Palm-Client-Struktur

5.4 GUI der Palmanwendung palmclient

Literaturverzeichnis

[3C098J 3COM. Palm-Organizer Handbuch. 3COM, 1998.

[Dis99j Jini discovery and join spezification. Technical report, Sun Microsystems Inc., January 25 1999.

[EdwOOj W. Keith Edwards. Core Jini. Der erste Developer’s Guide für Jini. Markt und Technik, 2000.

[Eve99j Jini distributed event spezification. Technical report, Sun Microsystems Inc., January 25 1999.

[HBOOj Walter Huber Herbert Bader. Jini Die intelligente Netzwerkarchitektur in Theorie und Praxis. Addison-Wesley, 2000.

[Köhj Ulrich Köhler. Hauptseminar zum thema jini. January.

[KVM99J The k vitual machine (kvm). Technical report, Sun Microsystems Inc., June 8 1999.

[LUS99J Jini lookup service spezification. Technical report, Sun Microsystems Inc., November 1999.

[...]

---

^[1] Bill Joy ist Chefentwickler bei Sun Microsystems und mitverantwortlich für die Entwicklung der Java- und Jini-Technologie.

^[2] In technischen Dokumentationen von Jini werden diese Gemeinschaften auch als “Djinn” bezeichnet.

^[3] Personal Digital Assistents

^[4] Poiut-to-Poiut Protocol

^[5] Ein Stub ist bei RMI ein Vertreterobjekt für das reale Serverobjekt auf einem anderen R echner, welches sich auf dem Client befindet.

^[6] Graphical User Interface

^[7] jar steht für Java ARchive

^[8] Ein Interface ist eine Ansammlung von Methodendeklarationen ohne jede Implementation. Es ist vergleichbar mit einer abstrakten Klasse.

^[9] AWT steht für Abstract Windowing Toolkit und beinhaltet Klassen für graphische Elemente, wie Fenster, Dialogboxen, Scrollbars usw.

^[10] Die K Virtual Machine ist nicht in der Lage, Arrays mit relativ vielen Elementen (z.B. 20000) zu erzeugen.

Häufig gestellte Fragen zu Jini und Palm Integration

Was ist Jini?

Jini (Java Intelligent Network Infrastructure) ist eine Systemarchitektur von Sun Microsystems, die die Zusammenarbeit von elektronischen Geräten vereinfachen soll. Sie ermöglicht die automatische Vernetzung und Nutzung von Diensten, unabhängig vom Hersteller.

Was sind die Entwicklungsziele von Jini?

Die Hauptentwicklungsziele von Jini sind Einfachheit, Zuverlässigkeit und Skalierbarkeit. Jini soll einfach zu verwenden sein, auch bei unzuverlässigen Netzwerkverbindungen stabil funktionieren und sich flexibel an die Größe und Struktur des Netzwerks anpassen können.

Welche sind die Hauptkomponenten der Jini-Architektur?

Die Jini-Architektur besteht aus drei Hauptbestandteilen: Infrastruktur, Programmiermodell und Services. Die Infrastruktur umfasst Discovery, Join und Lookup-Service (LUS). Das Programmiermodell umfasst Leasing, Distributed Transactions und Distributed Events. Services sind die Einheiten, die von Personen, Programmen oder anderen Services genutzt werden können.

Wie funktioniert die Registrierung eines Services in Jini?

Ein Service registriert sich bei einem Lookup-Service (LUS) mithilfe des Discovery- und Join-Protokolls. Zuerst werden verfügbare LUSs gefunden, dann werden die Daten, die den Service charakterisieren, an den LUS übermittelt und dort gespeichert. Die Registrierung ist zeitlich begrenzt und muss periodisch erneuert werden.

Wie nutzt man einen Service in Jini?

Um einen Service zu nutzen, wird nach einem oder mehreren Lookup-Services gesucht. Dann wird an einen ausgewählten LUS eine Anfrage nach einem bestimmten Service geschickt. Der LUS übermittelt die Informationen über den Service an den potentiellen Nutzer.

Was ist der Lookup-Service (LUS) in Jini?

Der Lookup-Service (LUS) ist eine zentrale Komponente in einem Jini-Netzwerk, die Services verwaltet und vermittelt. Er speichert Informationen über registrierte Services und ermöglicht es Clients, bestimmte Services zu finden und zu nutzen.

Was ist Leasing in Jini?

Leasing ist ein Konzept, bei dem die Nutzung einer Ressource zeitlich begrenzt ist. Der Dienstanbieter garantiert seine Verfügbarkeit für einen bestimmten Zeitraum. Nach Ablauf dieser Zeit muss der Service sich neu anmelden, um weiterhin verfügbar zu sein.

Was ist Distributed Transaction in Jini?

Eine Transaktion ist eine unteilbare Aktion, die aus einer oder mehreren Operationen besteht. In Jini wird dieser Mechanismus sehr locker umgesetzt. Es sind ausschliesslich Interfaces und Protokolle definiert. Die Implementierung ist dem Anwender selbst überlassen.

Was ist Distributed Events in Jini?

Der verteilte Event-Mechanismus ermöglicht es Objekten Informationen über Zustandsänderungen in anderen JVM’s, die sich irgendwo im Netz befinden, erfahren können. Es muß sich hierbei weder um JVM’s des gleichen Herstellers noch um die gleiche Version der JVM eines Herstellers handeln.

Wie kann ein Palm III Handheld in eine Jini-Umgebung integriert werden?

Ein Palm III Handheld kann in eine Jini-Umgebung integriert werden, obwohl die K Virtual Machine (KVM) auf dem Palm nicht alle Jini-Funktionen unterstützt. Es gibt verschiedene Architekturmöglichkeiten, einschließlich der Verwendung eines Proxys auf einem PC, um die Jini-Kommunikation zu ermöglichen.

Was ist die K Virtual Machine (KVM)?

Die K Virtual Machine (KVM) ist eine kompakte Java-VM, die speziell für Geräte mit geringen Ressourcen entwickelt wurde. Sie ist auf dem Palm III lauffähig, unterstützt aber nicht alle Funktionen der Java 2 Platform Standard Edition (J2SE) oder Jini.

Welche Netzwerkverbindungen sind auf dem Palm III möglich?

Der Palm III kann eine TCP/IP-Verbindung über ein Mobilfunktelefon, ein Modem oder über die Docking-Station, die an die serielle Schnittstelle eines PCs angeschlossen ist, herstellen.

Welche Architekturmöglichkeiten gibt es für die Jini-Integration mit Palm?

Es gibt verschiedene Architekturmöglichkeiten:

• Autonomer Jini-Client: Der Palm fungiert als vollwertiger Jini-Client (derzeit nicht realisierbar wegen KVM-Beschränkungen).
• Via Proxy (Java Client): Ein Proxy auf einem PC übernimmt die Jini-Kommunikation für den Palm-Client.
• Via Proxy (PalmOS Client): Ein Proxy dient als Schnittstelle für eine reine PalmOS-Anwendung.

Wie richtet man eine Jini-Umgebung ein?

Um eine Jini-Umgebung einzurichten, benötigt man Java 2 (oder höher) und das Jini Starter Kit. Nach der Installation muss der CLASSPATH angepasst werden und die Basisdienste (HTTP-Server, RMI-Activation-Daemon und Lookup-Service) gestartet werden.

Wie startet man die Jini Basisdienste?

Die Jini Basisdienste können mit dem Programm “StartService” oder einzeln von der Kommandozeile aus gestartet werden.

Was ist das Ziel des Palm Jini Beispiels?

Ziel des Palm Jini Beispiels ist zu zeigen, wie man einen Primzahl Berechnungs Dienst von einem Palm benutzen kann. Dies beinhaltet das Einrichten der KVM auf dem Palm, Verbindung ueber eine TCP/IP-Verbindung zu einem Rechner, auf dem der Proxy laueft und das Versenden von entsprechenden Kommandos. Die Implementierung eines Java-Clients auf dem Palm und eines Proxy’s auf einem PC die im Moment einfachste und sinnvollste Architekturlösung.

Wie kann man die Java Code für ein Palm ausführen?

Die Anwondung besteht im wesentlichen aus zwei verschiedenen Klassen, palmcMent und connectspotlet, welche beide von der Klasse Spottet abgeleitet sind. Also werden zuerst mit Hilfe eines normalen Javacompilers die dass-Files erzeugt, wobei sich die Packages für die KVM-Anwendungen im dasspath befinden müssen. Danach werden diese Files, mit Hilfe eines zusätzlichen Tools, in ein prc-File zusammengefaßt.

Details

• Hochschule: Technische Universität Ilmenau
• Autor: Ulrich Köhler (Autor:in)
• Erscheinungsjahr: 2001
• Seiten: 48
• Katalognummer: V99987
• ISBN (eBook): 9783638984195
• Sprache: Deutsch
• Schlagworte: Integration Palm Handhelds Jini-Umgebung