Einleitung

SEITE BEFINDET SICH NOCH IN DER ENTSTEHUNG!!!

Motivation zu dieser Arbeit

Seit die Java Intelligent Network Infrastructure, kurz Jini(TM), 1999 durch die Firma Sun Microsystems zum ersten Mal der Öffentlichkeit vorgestellt wurde, verbindet die Mehrzahl der Interessenten mit dem Begriff Jini(TM) eine Middleware-Plattform, die dazu gedacht ist, Java(TM)-fähige Geräte ohne größeren administrativen Aufwand miteinander verbinden zu können. Sicher entspricht diese Vorstellung einem Teil der durch Jini(TM) offerierten Möglichkeiten. Aber hinter Jini(TM) steckt ein viel weiterführender Ansatz der Softwareentwicklung, als er für das bloße „Zusammenstöpseln“ von Hardware notwendig wäre. W. Keith Edward, der Autor des Buches Core JINI , schreibt dazu:

„... As I learned more about Jini, I became convinced that – even though it is a young technology – it could bring about a shift in what we expect from the technology in our lives. ... „ [ W. K. Edwards, Core JINI , S. XLI].

Leider tat Sun bis zum heutigen Tage relativ wenig, um die hinter Jini(TM) stehenden Konzepte offensiv zu promoten. Und obwohl diese aus Sicht des Autors ganz hervorragend zum Aufbau moderner verteilter Softwaresysteme geeignet sind, wird Jini(TM) selbst in den Kreisen eingefleischter Java(TM)-Entwickler eher stiefmütterlich behandelt. Als Ausdruck dessen kann u. a. die relativ geringe Anzahl an Open-Source-Projekten gewertet werden, die sich mit Jini(TM) beschäftigen. Ziel dieser Studienarbeit soll es sein, die in Jini(TM) enthaltenen Konzepte und Konstrukte etwas näher vorzustellen und vielleicht den einen oder anderen Kommilitonen zu einer vertiefenden Beschäftigung mit dieser Technologie zu motivieren. Für Leser, die für sich in Anspruch nehmen, Java(TM) zu kennen, sich aber noch nicht weiter mit Jini(TM) beschäftigt haben, sei gesagt, dass Jini(TM) so ziemlich alles aus der Trickkiste holt, was mit der Java(TM)-Umgebung möglich ist. Jeder mag nach dem Studium dieser Technologie für sich selbst entscheiden, wie gut er die in Java(TM) verankerten Mechanismen schon kannte, bevor er sich mit Jini(TM) befasst hat. Der Autor dieser Zeilen kann für sich behaupten, dass er erst durch die Arbeit mit Jini(TM) die Fülle an Fähigkeiten und Möglichkeiten der Java(TM)-Plattform kennengelernt hat und das obwohl er seit 1997 aktiv mit Java(TM) entwickelt und an diversen CORBA-, Web-Service- und J2EE-Projekten teilhaben durfte.

Jini(TM) Designziele

Wenn Jini(TM) nicht ausschließlich für die Integration Java(TM)-betriebener Hardware gedacht ist, welche Zielsetzungen werden dann von Jini(TM) verfolgt? Jini(TM) dient dem Aufbau flexibler, robuster, administrations- und wartungsarmer verteilter Systeme. Im Besonderen ist es Ziel von Jini(TM), den Akteuren (externe und interne) eines verteilten Systems das Auffinden von und den Zugriff auf im Netzwerk vorhandene Ressourcen zu ermöglichen. Hinter einer Ressource kann sich dabei ein Stück Hardware oder ein Softwaremodul, aber auch eine Kombination aus Hard- und Software verbergen. Grundlegend für Jini(TM) ist die Tatsache, dass moderne verteilte Systeme während ihrer Laufzeit dynamischen strukturellen Änderungen unterworfen sein können. In solchen Systemen muss daher ständig mit dem Ausscheiden bisher am System beteiligter Akteure und Ressourcen gerechnet werden, während gleichzeitig neue zu diesem hinzu kommen können. Jini(TM) will einen Rahmen schaffen, der trotz der dieser Dynamik den Aufbau stabiler verteilter Systeme ermöglicht, wobei diese Systeme nahezu die gleiche Performanz und den gleichen Komfort bieten sollen, wie sie die Anwender von traditionellen zentralisierten EDV-Systemen gewohnt sind. Auch der für ein Jini(TM)-System notwendige Aufwand an Wartung und Administration soll den, für ein traditionelles zentralisiertes System notwendigen nicht wesentlich übersteigen. Ein weiters Ziel von Jini(TM) ist es, die Anpassungsfähigkeit von Systemen zu erhöhen. Ein Jini(TM)-System soll mit den aktuellen Bedürfnissen seiner Anwender wachsen (oder auch schrumpfen) können ohne das hierfür ein Re-Deployment des gesamten Systems notwendig ist.

Ein Beispielszenario

TODO

---

Anregungen und konstruktive Kritik bitte an Thomas Lehmann