JavaVM als Nutzerprozeß, nach [6]
Die Welle euphorischer Begeisterung für Java hat (endlich) auch Betriebssysteme erfaßt. Etwas Vergleichbares hat es in Betriebssystemen allenfalls vor etwa 10 Jahren mit dem Aufkommen der Objektorientierung gegeben.
Dieser Beitrag befaßt sich mit Java-Betriebssystemen ("JavaOS's"), einer Klasse von Betriebssystemen zur Unterstützung von Java-Anwendungen. Unter diesem Oberbegriff lassen sich eine Vielzahl von Entwicklungen zusammenfassen, von denen Sun's JavaOSTM als wichtigste herausragt.
Dieser Bericht gibt eine Zusammenfassung eines Beitrags zum Workshop "Intranet", der vom 22.-25. April 1997 in Dürrenwaid stattfand. In diesem Beitrag wurden Trends unter dem Schlagwort "Intranets" und ihre Auswirkungen auf Betriebssysteme betrachtet [2].
Die Abgeschlossenheit von Intranets kann auf verschiedene Weise umgesetzt werden. Eine Variante ist die physische Trennung eines Intranets von öffentlich zugänglichen Datennetzen. Eine andere Variante der Abschottung besteht im selektiven Zugang zu Intranets über Internets, z.B. über sichere Authentifizierung, Autorisierung und gesicherte Verbindungen. Eine dritte Möglichkeit ist, das weltweite Internet lediglich als Transport-Infrastruktur für firmen- oder organisationsinterne, d.h. für Dritte logisch unzugängliche Protokolle zu benutzen.
Für Betriebssysteme gibt es seit einiger Zeit Entwicklungen, die mit Intranets in Verbindung stehen und die hier unter dem Blickwinkel JavaOS betrachtet werden sollen:
Hersteller folgen dieser hier vereinfachten Argumentationskette,
um aus ihrer Sicht auf die Bedürfnisse und Probleme von Kunden
einzugehen und neue Anwendungsfelder zu öffnen.
Aus der sich stärker ausprägenden Differenzierung von Aufgaben
zwischen Client- und Serverbetriebssystemen folgt die
Notwendigkeit, Betriebssysteme speziell für diese Aufgaben
auszulegen.
Diese Idee ist nicht neu, so gab es etwa für Plan9 von den
AT&T Bell Labs bereits in den achtziger Jahren in einem
Workstation-Netz spezialisierte Betriebssystem-Kerne für eine
Fileserver-Maschine, für einen Compute-Server und für
Terminals (Clients), die untereinander interaktionsfähig waren
[7, 4].
In Unix findet man diese Spezialisierung von Betriebssystemen bis heute
nicht.
Maschinen für unterschiedliche Aufgaben unterscheiden sich
natürlich in Ausstattung und Konfiguration, es läuft aber auf allen
Maschinen im Prinzip das gleiche (universelle = "fat")
Betriebssystem, und jede Maschine kann prinzipiell auch als Server
dienen.
In NT gibt es eine Spezialisierung als Server- bzw. Client-System,
wobei hier nur dieser Fakt konstatiert und keine Wertung erfolgen soll.
Bei der "neuen" Art des Java-Computing wird die Idee der Spezialisierung konsequent umgesetzt. Serverseitig wird sich dabei für Betriebssysteme nicht allzuviel ändern. änderungen betreffen vor allem die Client-Seite. Hier besteht die Chance, Betriebssysteme erheblich in Funktion, Umfang und Komplexität zu vereinfachen, d.h. ihren Bedien-, Administrations- und Wartungsaufwand im angestrebten Idealfall auf Null zu reduzieren [1].
Was ist jetzt aber neu?
Neu ist vor allem ein Potential für neue Einsatzfelder, die hier in Form von vier Punkten zusammengefaßt werden sollen.
Für die Administration von vernetzten Systemen ist neu, daß nicht mehr nur die prinzipielle Möglichkeit zur zentralen Organisation netzweit zugänglicher Dienste und Anwendungen auf Servern besteht, sondern es besteht ein stärkerer Zwang dazu. Auf einer JavaStation läßt sich lokal keine Software installieren, kein Nutzer einrichten u.a., wie es bei PC's und Workstations bis dato immer noch möglich ist und mehr oder weniger auch praktiziert wird.
"Dumme", weil zustandslose (automatisch verwaltete Zustände von Caches werden davon nicht berührt) Arbeitsplatzrechner besitzen eine Eigenschaft, die vor allem von Großkunden mit transaktionsorientierten Anwendungen (Terminals) sehr geschätzt wird. Sie sind in Relation billig und erfordern keine clientseitigen Administrationsaufwendungen. Gerade hierin hatten die bisherigen vorwiegend dezentral organisierten PC- und Workstation-Netze einen entscheidenden Nachteil gegenüber Mainframes mit vielen angeschlossenen, billigen und wartungsfreien Terminals. Totgesagte leben länger, und Mainframes verzeichnen auch aus diesem Grund heute stabile bzw. sogar wachsende (Stück-) Umsätze, und der Grund dafür liegt nicht allein im immensen Bestand an Alt-Software.
Für Java-Computing bietet sich die Chance, Zugang in diesen riesigen und damit attraktiven Markt der transaktionsorientierten Datenverarbeitung zu bekommen, indem (neu!) die Kostenvorteile von Terminals beibehalten werden und durch Java-Anwendungen auf einfache Weise zeitgemäße Oberflächen hergestellt werden können und neue und erweiterbare Dienste an den Terminal-Arbeitsplätzen angeboten werden können, wie Mail, Web (z.B. für die firmeninterne Informationsverteilung), News und nicht zuletzt auch die bekannten Office-Lösungen. Dies wäre in der Tat ein Fortschritt in dem großen Bereich transaktionsorientierter Anwendungen. Die Akzeptanzgrundlage ist dabei ebenfalls gewahrt. Mainframe-Anwendungen werden von Änderungen auf der Client-Seite kaum berührt. Sie können über Java-Frontends unverändert ablaufen.
Zu Euphorie besteht jedoch noch kein Anlaß. Die Java-Technik gibt es erst seit ca. 3 Jahren. Das Performance-Problem bekommt man mit JIT-Compilern bzw. Sun's angekündigtem Java-Prozessor wahrscheinlich relativ schnell in den Griff, weit komplizierter ist die Verfügbarkeit sinnvoller Java-Software und Anbindungen an bestehende Anwendungen.
Mit vereinfachten, abgerüsteten Java-Client-Betriebssystemen erschließen sich aber auch neue Anwendungsfelder. Durch die Reduktion der Funktionen reduziert sich auch der Ressourcenbedarf von Betriebs- und Anwendungssystemen, so daß sich Clients dieser Art in kleine (mobile) Geräte kostengünstig integrieren lassen, was mit heutigen "fat clients" nicht möglich wäre. Diese Eigenschaft soll nach [5, 6] "new types of network devices" ermöglichen.
Fazit:
Informatiker neigen dazu, Systeme aus rein technischer Sicht
zu beurteilen und Fragen wie Kosten oder Integrationsfähigkeit in
bestehende Verhältnisse zu vernachlässigen.
Gerade die Entwicklung der Netz- bzw. Java-Computer ist ein
Beispiel dafür.
Es geht nicht darum, Arbeitssysteme oder Workstations für
Wissenschaftler oder Entwickler aus Kostengründen auf das Niveau
von vor 10 Jahren abzurüsten, das würde nie eine Akzeptanz finden,
es geht vielmehr darum, Innovationen in den genannten Bereichen
zu ermöglichen, und dort liegen auch die von Herstellern
avisierten Potentiale.
Diese Einordnung wird oft bei anfangs rein technisch und später
emotional (bis religiös) geführten Debatten nicht beachtet und
geht damit am Gegenstand vorbei.
Unter dem allgemeinen Begriff JavaOS sollen Betriebssysteme
verstanden werden, welche speziell (oder ausschließlich) für den
Ablauf von Java-Anwendungen auf Client-Systemen ausgelegt sind.
Zahlreiche Hersteller arbeiten gegenwärtig an Betriebssystemen
dieser Art, nicht nur Sun.
Im Prinzip könnte man jedes Betriebssystem, welches den Ablauf der
Java-Virtual-Machine (JavaVM) unterstützt, als JavaOS bezeichnen.
Das unterscheidende Kriterium ist die direkte Unterstützung durch den
Kern und das weitgehende Fehlen nicht für den Ablauf von
Java-Anwendungen benötigter Funktionen (z.B. lokale Filesysteme).
Die JavaVM muß im Kern ablaufen oder anders - die JavaVM ist das
Betriebssystem bzw. der Kern.
Vereinfacht kann man sagen, daß alle Dinge, die nicht für den
Ablauf von Java-Anwendungen erforderlich sind, prinzipiell entfallen
können.
Wenn es keine lokalen Platten oder andere persistente Speicher gibt,
benötigt man auch keine Gerätetreiber und Filesysteme dafür.
Es ist aber nur eine Frage der Zeit, bis man clientseitigen persistenten
Speicher wieder in Geräte für Caching einbaut. Sun hat dies vor.
Clientseitiges Abrüstungspotential für das Betriebssystem liegt
aber auch in den Bereichen, die bislang wie selbstverständlich mit
Betriebssystem-Eigenschaften verbunden wurden, wie z.B.
Multi-User und Multi-Tasking. Auf einer Client-Maschine arbeitet zu
einem Zeitpunkt nur ein Nutzer, folglich braucht man
(clientseitig!) keine Multi-User Unterstützung.
Auch Multi-Tasking ist zu überdenken, eine einfache
Thread-Unterstützung würde für Java-Anwendungen genügen.
Virtueller Speicher steht ebenso zur Disposition, und es entfällt
der Zwang zur stets vollen Kompatibilität zu traditionellen,
umfangreichen Kern-API. Gerade diese Forderung, stets eine Obermenge
an Funktionen für verschiedene Standards zu erfüllen,
bedingt eine nicht unerhebliche Komplexität in heutigen
Universal-Betriebssystemen.
Es sei nocheinmal klar gesagt, diese Aussagen beziehen sich nur auf
Client-Betriebssysteme !
Auf der anderen Seite gibt es auch keine Veranlassung zur zwanghaften Vereinfachung. Flexibilität und Skalierbarkeit sind die entscheidenden Merkmale. Wenn ein Client-System über lokale Platten verfügt, so können diese für Caching oder virtuellen Speicher benutzt werden. Es gibt auch keinen Grund, keine entfernten Filesysteme zu montieren, um z.B. lokal bearbeitete Dateien auf den Server zurückzuschreiben.
Das Betriebssystem heißt Kona. Kona ist aber kein JavaOS im o.g. Sinn mit der JavaVM als Betriebssystem-Kern. Dafür gibt es bei Sun ein anderes Projekt - JavaOSTM (siehe unten).
Im Prinzip handelt es sich bei der JavaStation um eine "weiter abgerüstete" diskless Workstation auf Basis: Micro-Sparc-II-CPU, 100 MHz (Sparc5), 32 MB RAM, keine Platte. Diese Maschine funktioniert aber ganz nach dem Grundprinzip des Java-Computing, d.h., alle Software wird von einem Server geliefert, und auch nur dort ist die Verwaltung konzentriert. Laut Sun können von einem Server (SparcStation5, 128 MB RAM, 2 GB Platte) bis 20 JavaStation betrieben werden. Ein anschaulicher Artikel einschließlich Performance-Messungen zur JavaStation1 und 1+ befindet sich in [3].
Das Betriebssystem Kona kommt via tftp ebenfalls vom Server. Auf der JavaStation läuft als einzige Anwendung der HotJava-Browser, welcher als "Web-Viewer" fungiert und die JavaVM für den Ablauf von Java-Anwendungen in Form von Applets enthält. Wichtig ist, daß außer dem HotJava-Browser keine anderen Anwendungen aufruf- und abarbeitbar sind, es also keine X-Anwendungen, keine Shells u.a. gibt. Auch das liegt in der Intention des Java-Computing, keine Konfigurierungsmöglichkeit auf Client-Seite zu erlauben (Server).
Wie bereits oben erwähnt, fehlen heute vor allem sinnvolle
Java-Anwendungen.
Beim Unix-Stammtisch konnte in dieser Kategorie lediglich das
Office-Paket von Applix vorgestellt werden, und dieses arbeitet dem
Java-Prinzip entgegen. Die Anwendung läuft auf dem Server,
nicht auf den Clients, nur die Oberfläche wird auf den Clients
angezeigt.
Es scheint ein weiteres Problem zu geben, woraus sich vielleicht auch
die "verkehrte" Ablaufform des Applix-Pakets ergibt, daß es nämlich
z.Zt. keine Möglichkeit für den Transport von Nutzer-Files zwischen
Server- und Java-Client-Maschine gibt, wie es z.B. für Office-Lösungen
notwendig ist, wenn lokal bearbeitete Texte auf den Server
zurückgeschrieben werden sollen. Der einfachste Weg wäre,
einen nfs-(oder afs)-Clients zu integrieren und damit in gewohnter
Weise Nutzerverzeichnisse des Servers clientseitig sichtbar
zu machen.
Dies scheint für die JavaStation z.Zt. nicht vorgesehen zu sein.
Einen Filetransport Client (Server via http scheint es gegenwärtig
auch nicht zu geben).
Generell ist über Kona wenig zu erfahren, und es liegt die Vermutung nahe, daß es sich um ein reguläres (ggf. modifiziertes) "Sun-Unix" handelt. Auch sonst erinnert die Technik sehr an diskless Workstations. Auch die in [3] angegebenen Performance-Zahlen lassen diesen Schluß zu. Dies war sicher notwendig, um als "Erfinder" der Java-Technik auch sehr schnell eine Java-Workstation anbieten zu können. Das ausgefallene Design einer Kaffeemaschine hat seine Funktion zudem glänzend erfüllt, nämlich Aufmerksamkeit zu erregen. Auch hier zeigt sich wieder, daß man Entwicklungen nicht allein technisch einordnen sollte, und andere Hersteller verfolgen ähnliche Strategien.
Das JavaOSTM-Betriebssystem wurde auf der JavaOne'96-Konferenz
(29.-31. Mai 1996 in San Francisco) von Peter Madany in einem
Vortrag vorgestellt
[6].
Peter Madany ist auf dem Gebiet der Betriebssysteme nicht unbekannt.
Er war an der Entwicklung von Choices, dem ersten
objektorientierten Betriebssystem in C++ Ende der 80'er Jahre an
University of Illinois beteiligt und ist jetzt bei Sun für das
JavaOSTM -Projekt verantwortlich.
In diesem Vortrag wurde eine Art Spezifikation für das
Java-Betriebssystem gegeben, nach der dann die Entwicklung erfolgte.
Etwa ein Jahr später gab es von Sun eine Pressenotiz,
daß JavaOSTM jetzt an Lizenznehmer abgegeben wird, so daß diese
damit eigene Anwendungen entwickeln können
[8]:
Mountain View, Calif., March 5, 1997
Sun Microsystems, Inc. today announced that the
JavaOSTM operating system, the smallest, fastest
way to run the Java environment on a microprocessor,
is now available to Sun's JavaOSTM licensees.
A broad range of products incorporating the JavaOSTM operating system - ranging from network computers to entertainment products - will soon be shipping from companies that license JavaOSTM .
Die Ziele für dieses Betriebssystem decken sich mit den bereits oben genannten.
Insbesondere der letzte Punkt macht die Zielrichtung deutlich, kleine
(ggf. mobile) Client-Systeme für unterschiedlichste Zwecke.
Der gesamte Code für das JavaOS (kernel, drivers, class-libraries,
graphics, windowing und auch die JavaVM), für Fonts und für den
HotJava-Browser soll in 4 MB ROM Platz finden, und für das ablaufende
System stehen 4 MB RAM zur Verfügung (2.5 MB für JavaOS + HotJava,
1.5 MB für web-pages, applets, and images).
Diese sehr restriktiven Speichergrenzen lassen ebenfalls erkennen, daß
hier andere Ziele als bei Unix verfolgt werden, daher
wird JavaOSTM auch nicht als Betriebssystem verkauft,
sondern es werden Lizenzen an Drittanbieter vergeben,
die auf Basis JavaOSTM Java-Anwendungen und -Geräte herstellen.
Lizenznehmer sind u.a. Applix, Chorus, IBM, ITRI, ARM, Toshiba und
Wyse
[8].
In den beiden folgenden Abbildungen sind die Unterschiede zwischen Java auf Basis konventioneller Technik (JavaVM nicht im Kern enthalten) und der Architektur von JavaOSTM gegenübergestellt.
Alle Funktionen der JavaVM werden in dieser Variante außerhalb des Kerns ausgeführt.
In Abbildung 2 sind die Kern-Komponenten von JavaOSTM gezeigt. Einzig der HotJava-Browser läuft außerhalb dieses Kerns ab.
Die Vorteile dieses Kerns liegen auf der Hand. Die Dienste dieses Kerns werden im Prinzip durch die Funktionen der Java-Basisklassen beschrieben und direkt durch diesen Kern umgesetzt. Für Grafik oder für Oberflächen bedeutet dies zum Beispiel, daß keine Abbildung auf das jeweilige Host-Fenstersystem mit dem damit verbundenen Overhead vorgenommen werden muß, sondern daß die grundlegenden Java-Grafik- und Fensterfunktionen unmittelbar vom Kern unterstützt werden. Dasgleiche gilt für Threads, Gerätezugriffe und anderes. Gegenwärtig gibt es Implementationen für SPARC, den ARM-Prozessor und für Intel.
Offen bleibt das Performance-Problem, welches durch die softwareseitige
Interpretation des Java-P-Codes verursacht wird. Hier würde sich
ein JIT-Compiler anbieten, bis Sun's P-Code (Co-) Prozessor tatsächlich
verfügbar ist. In JavaOSTM erfolgt eine softwareseitige
Interpretation, und JavaOSTM ist selbst zu großen Teilen in Java
implementiert (classes u.a.), was erwartungsgemäß zu einer schlechten
Performance führt.
In [5, 6]
sind keine Performancewerte angegeben, und die Demonstration der
JavaStation zum Unix-Stammtisch führte auch nicht zu Begeisterung,
vor allem die recht langen Ladezeiten vom Server verwunderten.
Die softwareseitige Interpretation von P-Code ist für größere
Anwendungen nicht akzeptabel. JIT-Compiler bieten dafür einen schnellen
Ausweg bevor Sun den P-Code Prozessor tatsächlich verfügbar hat.
Dort haben Netz- oder Java-Computer auch eine berechtigte Chance auf Erfolg. Den Einzug in den Bereich von Wissenschaftler- oder Entwickler-Workstations werden sie (vorerst, und wohl auch auf längere Sicht) nicht schaffen, und dafür waren sie auch nicht vorgesehen. Vielleicht wird es aber auch in Kürze Anwendungen auf Basis Java und JavaOSTM geben, die heute noch gar nicht vorstellbar sind.
