Ein Besuch auf der CeBIT

Von Volker Ricke

In der letzten Ausgabe habe ich Ihnen von bekannten Atari-Gesichtern auf der diesjährigen CeBit berichtet. In dieser ATOS möchte ich ein wenig über den Tellerrand blicken und Ihnen das Schlagwort "Intranet" ein wenig näherbringen.

Das Intranet

Was war dieses Jahr das ultimative Schlagwort? Nach dem Internet, das die letztjährige Messe beherrschte, war es nun das "Intranet", das nicht etwa, wie manche voreilige Journalisten vor der Kamera erzählten, dem Internet-Surfer auch firmeninterne Netze öffnet, sondern Technologien der Zusammenarbeit innerhalb von Unternehmen bereitstellt. Nachdem HTML einen plattformübergreifenden Standard für die Präsentation von Informationen darstellt, bietet die vom Workstation-Spezialisten SUN entwickelte Sprache Java eine Systemgrenzen überspringende Sprachsyntax, mit der ganze Programmpakete entwickelt werden können. Sogenannte Java-Applets sind kleine vorcompilierte Programmpäckchen, die bei Bedarf über das Netz auf den PC oder Netzcomputer geladen werden und dort innerhalb einer Laufzeitumgebung, der "Java virtual machine", ablaufen.

Die Java-Verfechter (neben SUN ist das vor allem der Datenbank-Software-Riese ORACLE) versuchen mit dieser Technologie vor allem auch die Dominanz der WIntel-Allianz (Intel PC unter Windows 95/NT) zu brechen, denn die Java-Applets laufen auf jeder Hardware, für die eine Laufzeitumgebung verfügbar ist.

Auf die Windows-Systemsoftware ist Java (im Gegensatz zu den Microsoft ActiveX-Controls) nicht angewiesen. Kein Wunder, daß sich die Company von Bill Gates angegriffen fühlt und in Presseverlautbarungen vor allem darauf hinweist, daß die gängige Microsoft Office-Software auf der Java-Plattform nicht verwendet werden kann.

Daß Java jedoch mächtig genug für vollwertige Office-Pakete ist, beweist etwa die Hamburger Star Division, die ihr Star Office 4 auch in einer Java-Version präsentierte.

Gestern

Worin liegt aber jetzt wirklich der Java-Vorteil? Betrachten wir doch einmal die Welt der Firmen-Netze. Vor wenigen Jahren noch fanden wir eine Großrechner-Architektur vor. Die Programme wurden auf dem Host (neben Großrechnern auch zum Beispiel UNIX-Plattformen) abgelegt und wurden dort gestartet. Am Arbeitsplatz standen "dumme" Terminals, die nur in der Lage waren, die Bildschirmausgaben des Servers darzustellen und die Tastatureingaben des Benutzers an den Großrechner weiterzugeben. Diese Lösung stellte ein Paradies für Entwickler und die Datenschützer dar, konnte doch der Benutzer nur über genau definierte Zugriffspfade auf die Software und die Daten zugreifen. Die Terminals konnten längerfristig genutzt werden, bei höherem Performance- und Speicherbedarf wurde der Host aufgerüstet.

Heute

Heute ist eine Client/Server-Architektur "State-of-the-Art". Vernetzte PC, überwiegend unter Windows, werden für Standard- und Spezialsoftware genutzt. Datenbank und Netzlaufwerk sind auf dem Server abgelegt.

Diese Architektur wirft heftige Probleme auf. Ein Windows-PC mag in der Anschaffung günstig sein, benötigt aber eine intensive Betreuung. Wenn Firmen bis zu 20.000 DM im Jahr an Kosten pro PC einplanen müssen (Abschreibung, Wartung, Anwenderbetreuung, durch leistungshungrige Software notwendige Aufrüstung) und alle zwei Jahre der Hauptspeicher und die Prozessorleistung der Clients verdoppelt werden müssen, um die verbreitete Bürosoftware ablaufen zu lassen, müssen sich die DV-Verantwortlichen einfach fragen, ob es nicht anders geht. Schlimmer als ein einzelner Windows-PC ist nämlich immer noch ein ganzes Netzwerk mit Windows-Clients ...

Unter Windows 3.1x oder Windows95 gibt es kein taugliches Mittel, den Anwender daran zu hindern, sein System zu zerschießen. Ein Macintosh läßt sich schon etwas besser schützen, während ein Windows-NT-Client, der wieder ziemlich viel Hauptspeicher benötigt, immerhin über Benutzerprofile und ein sichereres Dateisystem verfügt und so den "normalen" Benutzer vor verhängnisvollen Fehlern bewahrt. Hochkomplizierte Lösungen sind hier somit gängig, die die Fehlersuche nicht langweilig werden lassen ...

Back to the past?

Vielleicht gibt es ja doch eine Möglichkeit, die sicheren Terminal-Lösungen der Vergangenheit auf den aktuellen Stand der Software-Ergonomie zu bringen? Hier setzt Sun ein. Die Java-Laufzeitumgebung stellt relativ geringe Anforderungen an die Hardware. Ob Internet-Box für den Fernseher, in der der Java-Interpreter im ROM enthalten ist (und das Gerät so wie der gute alte Atari ST durch pures Aus- und wieder Einschalten nach einem Absturz wieder zum Leben erweckt werden kann), mit Tastatur und Mouse aufgerüstete Spielekonsole, Netz PC, Windows-PC, Unix Workstation oder Apple Macintosh - die Java Software wird ohne Änderungen auf vielen Plattformen zuhause sein.

Die Programme werden entweder über Datenträger oder über das Netz auf den Rechner geladen und sind auf diesem sofort lauffähig. Möglich macht es das binäre Datenformat, das zwar vorkompiliert (und somit für den neugierigen Kunden nicht mehr wie etwa ein Basic Programm lesbar) ist, jedoch noch nicht für den Prozessor übersetzt ist. Die Übersetzung in den Maschinen-Code übernimmt der Java-Interpreter zur Laufzeit. Daß die Arbeitsgeschwindigkeit dabei geringer ist als beim Ausführen fertig kompilierter Programme, darf natürlich nicht verschwiegen werden (und war bei den auf der CeBIT gezeigten Alpha- und Beta-Versionen auch nicht zu verbergen). Die Leistungsfähigkeit heutiger Prozessoren würde es aber durchaus erlauben, sowohl die "Java virtual machine" als auch die Java Applets in guter Geschwindigkeit ablaufen zu lassen. Geben wir also Sun und den Java Entwicklern noch etwas Zeit für Optimierungen! Angesichts der rasanten Weiterentwicklung inbesondere der RISC-Prozessoren fällt es den Softwarehäusern allerdings leichter, mit den Pfunden zu wuchern.

Nicht vergessen - gerade für den Betrieb im Intra- oder Internet - dürfen wir den Sicherheitsaspekt. Da Java-Applets nur Befehle ausführen können, die in der Laufzeitumgebung vorgesehen und zugelassen sind, lassen sich hinterhältige Programme, die im System herumräubern, leichter ausschließen.

Vor allem Kontrahent Microsoft bindet sich dagegen mit ActiveX und der geplanten engeren Integration der nächsten Windows-Version in das Internet hier große Risiken ans Bein - ein geladenes ActiveX-Control kann im Prinzip ungehindert im Betriebssystem herumräubern, womit die Fehlersuche erneut erschwert wird.

Und der Privatmann?

Wer nicht über eine Standleitung zum Internet-Provider verfügt, wird als europäischer Privatmann kaum einen Netz-PC nutzen, der sich ständig die benötigte Software über die Telefonleitung laden muß. Da Java-Software aber auch ohne Netzanschluß von der lokalen Festplatte gestartet werden kann, ergibt sich die Chance, auch auf nicht ganz so stark verbreiteten Plattformen in Java geschriebene aktuelle Standard-Software zu nutzen, während parallel die Software (oder auch nur das bessere Betriebssystem) läuft, die Grund dafür war, eben keinen Windows-PC zu verwenden.

Volker Ricke