Was heute noch nicht funktioniert, kann morgen vorbildlich gelöst sein. Programmierer müssen daher sehr aufmerksam die Entwicklungspfade und Stan- dardisierungsbemühungen rund um Java verfolgen, um sich nicht in Sackgassen zu programmieren.

Sehr entwicklungsfähig ist auch der Markt, der sich den plattformunabhängigen Anwendungen öffnet, die mit Java entstehen sollen. Die gewohnten Anwendungen werden nicht bleiben, wie sie sind, sondern zu kleinen Bausteinen mutieren - je nach aktueller Tätigkeit geladen oder zu persönlichen Anwendungen zusammengestellt - so die Prognosen von Marktforschern. Daher müssen die Funktionen einer Java-Applikation genau abgegrenzt und Schnittstellen sauber definiert sein.

Wer heute größere Programme mit Java entwickelt, sieht sich vor allem mit einem Problem konfrontiert: mangelnde Geschwindigkeit. Java-Programme liegen in einer Form vor, die heutige Prozessoren nicht direkt verarbeiten können. Die Java-Programme müssen erst in die jeweilige Maschinensprache übersetzt werden.

Das geschieht entweder bei der Ausführung Befehl für Befehl oder unmittelbar nach dem Laden des Programms als Ganzes. Dieser Umstand ist der Preis für die Plattformunabhängigkeit, denn so ist das Java-Programm immer das gleiche, nur die Übersetzungsmaschine, die Java Virtual Machine, ist prozessor- und betriebssystemspezifisch.

Ein Tribut an die Sicherheit sind Funktionsbeschränkungen. Denn eben diese Übersetzungsmaschinen dürfen Java-Programmen gewisse Funktionen nicht gestatten, mit denen sie Schaden auf dem Wirtsrechner anrichten könnten. So dürfen die Programme etwa nur auf Dateien zugreifen, die auf dem gleichen Rechner liegen, von dem auch sie selbst gekommen sind.

Allerdings gelten diese Beschränkungen nur für Programme bedenklicher Herkunft, also vor allem aus dem Internet. Diese Programme heißen im Java-Jargon Applets.

Außerdem gibt es vollwertige Java-Programme, die sogenannten Applikationen, die diesen Restriktionen nicht unterworfen sind, dafür aber eine unbedenkliche Herkunft nachweisen müssen.

Das Hauptmotiv, diese Einschränkungen in Kauf zu nehmen, liefert das Internet. Java-Programmen, die auf jedem Rechner laufen, für den ein entsprechender Übersetzer verfügbar ist, steht ein riesiger Markt offen. Um diese Möglichkeit zu nutzen, müssen sich Entwickler von Java-Programmen jedoch an einige weitere Regeln halten. Die Programmiersprache ist nämlich noch in der Entwicklung, so daß heutige Lösungen für künftige Versionen offen sein müssen, wenn ihnen nicht die Zukunft verbaut sein soll.

Auseinandersetzungen, wer denn nun bei der Standardisierung von Java das Heft in der Hand hält und prüft, welche Implementation den Vorschriften entspricht, seien hier außen vor gelassen. Das Maß der Dinge ist das Java Development Kit (JDK) von Sunsoft. Daneben bieten Drittanbieter Ergänzungen an, die derzeitige Lücken füllen sollen.

Bei der Verwendung solcher Ergänzungen ist jedoch Vorsicht angeraten, denn schon im nächsten Release des JDK kann die jeweilige Lücke geschlossen sein. Wenn sich also der Einsatz von Zusatzkomponenten nicht umgehen läßt, sollte das Gesamtprogramm so angelegt sein, daß jene sich durch Standardkomponenten ersetzen lassen, sobald sie verfügbar sind.

Wenn etwa Fremdkomponenten in vielen Benutzerdialogen vorkommen, lohnt es sich, eine eigene Tree-Control-Klasse zu schreiben, um sie dann leichter durch andere Komponenten austauschen zu können. Mit dieser Klasse werden die Methoden der Drittanbieter-Komponente implementiert, so daß bei einem Wechsel nur diese Klasse anzupassen ist und nicht jeder einzelne Dialog.

Ziel: Eine Anwendung für alle Plattformen

Die Möglichkeiten von Java müssen sich auf die Gemeinsamkeiten aller Plattformen beschränken, auf denen das fertige Programm laufen soll. Dazu gib es einerseits verschiedene Wege, um ein Ziel zu erreichen, und andererseits entwickeln sich die jeweiligen Plattformen weiter. Insbesondere beim Erscheinungsbild von Anwendungen ist es wenig sinnvoll, daran allzu intensiv zu feilen. Statt eine plattformspezifische Oberfläche nachbilden zu wollen, ist die Suche nach dauerhaften Gemeinsamkeiten vorzuziehen.

Das Java-gerechte Entwickeln von Programmen beginnt schon bei deren Struktur. Die Anwendungen sollen ja von verschiedenen Plattformen aus nutzbar sein und am besten auch über das Internet oder über Intranets verteilt werden können.

Neben den Geschwindigkeitsproblemen bei der Ausführung, die bei großen Programmen besonders ins Gewicht fallen, wären schon die Ladezeiten über das Netz unzumutbar lang. Am elegantesten sind diese Probleme in den Griff zu bekommen, indem ein starker Server den Großteil der Arbeit leistet und die Clients sich im wesentlichen auf das Anfordern und Darstellen von Informationen beschränken.

In diesem Fall würde es auch genügen, nur die Clients in Java zu programmieren, das Server-Programm dagegen in einer schnelleren Sprache zu schreiben. Die Konzentration der wesentlichen Funktionen einer Software in einer Server-Applikation bietet noch eine Reihe weiterer Vorteile.

Dadurch gestalten sich insbesondere die Verwaltung und Aktualisierung erheblich einfacher, als wenn eine große Zahl umfangreicher Clients via Datennetz verteilt und gepflegt werden müßte. Schließlich läßt sich mit einer zentralen Instanz auch leichter überprüfen und sicherstellen, daß nur berechtigte Nutzer die Informationen zu sehen bekommen, die für sie bestimmt sind.

Ein Beispiel: Das Dokumenten-Management- und Archivierungssystem "Scanview plus" von DAA war zwar bereits als Client-Server-Anwendung aufgebaut, jedoch diente der Server im wesentlichen als Datenlager; die meisten Funktionen erledigte der Client. Für den Einsatz im Internet war es aus den genannten Gründen sinnvoller, diese Aufteilung umzukehren und die Hauptarbeit auf den Server zu verlagern.

Zwischen Archiv- und Web-Server unterscheiden

Beim Server sollte noch zwischen dem eigentlichen Archiv-Server und dem Web-Server, der für die Vermittlung zwischen Archiv und Clients zuständig ist, unterschieden werden. Einerseits läßt sich der Archiv-Server dadurch hinter einer Firewall in Sicherheit bringen und außerdem auf eine eigene Maschine auslagern, damit sich beide Server nicht stören.

Zudem lassen sich so die einzelnen Schichten des Systems getrennt voneinander ändern, ohne daß die anderen Schichten davon betroffen wären. Auf diese Weise können auch andere Anwendungen eingebunden werden, etwa um das elektronische Archiv mit einer kaufmännischen Software zu verbinden.

Es versteht sich von selbst, daß für die Kommunikation zwischen den Schichten nur Standardprotokolle und -verfahren in Frage kommen. Der herkömmliche Windows-Client verwendet Remote Procedure Calls für die Kommunikation mit dem Archiv-Server. Zunächst wurde für den Java-Client ein eigenes Anwendungsprotokoll, basierend auf TCP/IP, genutzt. Mit zunehmender Anzahl an Server-Funktionen ist diese Methode jedoch umständlicher und zeitraubender zu implementieren. Inzwischen hat die Standardisierung von Java Fortschritte gemacht, und jetzt steht mit der Remote Methode Invocation (RMI) ein leistungsfähigeres und einfach zu implementierendes Verfahren zur Verfügung.

Als weitere Alternativen bieten sich das Distributed Component Object Model (DCOM) von Microsoft und die Common Request Broker Architecture (Corba) an. Allerdings ist DCOM plattformgebunden, denn es läuft nur auf der Virtual Machine von Microsoft. Corba erfordert seinerseits Software von Drittanbietern und die Zahlung von Lizenzgebühren.

Da jedoch Corba ein übergreifender Standard ist, dessen Bedeutung über die von Java noch hinausgeht, haben sich die Standardisierungsgremien darauf geeinigt, RMI mit dem Corba-Protokoll Internet Inter Object Request Broker Protocol (IIOP) verträglich zu machen. Dadurch lassen sich RMI-Aufrufe über IIOP transportieren.

Aber nicht nur die Programme, auch die Daten sollen auf ihrem Weg durch das Internet keinen Schaden erleiden oder auf Abwege geraten. Dies ist jedoch nicht nur ein Problem einer einzelnen Anwendung, wenngleich es Programme gibt, die wichtigere Daten verarbeiten als andere. Allgemein gilt jedoch, daß der Schutz um so wirksamer ist, je tiefer er in der Hierarchie (des OSI-Modells) angesiedelt ist.

Daher ist etwa die Version 6 des neuen Internet-Protokolls IPv6 mit wesentlich besseren Sicherheitsfunktionen ausgestattet als ihr Vorgänger. Da es in der Praxis jedoch erst in Testinstallationen läuft, ist der Schutz vor Mißbrauch beim Übertragen der Informationen über das Internet derzeit vor allem Aufgabe von Verschlüsselungsverfahren wie Secured Sockets Layer SSL 2.0, SSL 3.0 und PCT (Private Communications Technology).

Auch wenn grafische Oberflächen inzwischen Standard und auf allen Plattformen verfügbar sind, so weisen sie doch bedeutende Unterschiede auf. Für die Oberflächengestaltung ist in Java das Abstract Windowing Toolkit (AWT) zuständig. Es enthält Klassen zum Aufbau plattformunabhängiger Graphical User Interfaces (GUIs).

Allerdings umfassen sie lediglich die aktiven Komponenten Button, Scrollbar, Choice, Checkboxen, Listboxen und Textfelder. Da sich die AWT-Entwickler auf die grundlegenden Komponenten beschränkt haben, die auf allen unterstützten Plattformen gemeinsam vorhanden sind, genügen diese Komponenten für eine anspruchsvolle Anwendung häufig nicht.

Bei der Benutzeroberfläche für den Java-Recherche-Client von Scanview plus wurde beispielsweise eine tabellenförmige Aus- und Eingabemöglichkeit benötigt, die in der Lage war, scrollbar zu sein, dynamisch Spalten und Reihen zu erzeugen und wieder zu entfernen sowie einzelne Felder für Eingaben zu sperren. Nach einigem Recherchieren im Netz und in Fachzeitschriften ließen sich Demoversionen solcher Tabellenkomponenten von verschiedenen Software-Anbietern testen.

Diese Komponenten erwiesen sich zwar von der Funktion her für die Anwendung als brauchbar, jedoch waren die zusätzlichen Klassen, die für diese Komponente in die eigene Klassenbibliothek importiert werden mußten, teilweise wesentlich umfangreicher als die eigene. Diese zusätzlichen Klassen verlängerten das Laden des Applets über das Internet so extrem, daß es nicht akzeptabel war.

Inzwischen setzt Sun mit seinen Java Foundation Classes (JFC), die neben dem Abstract Windowing Toolkit die Internet Foundation Classes von Netscape und eine Technologie von IBM und Lotus enthalten, einen langersehnten Standard. Das macht einen Großteil der Komponenten von Drittanbietern überflüssig und die Pflege von Applikationen erheblich einfacher.

Die Swing-GUI-Komponenten als Teil der JFC stellen dem Entwickler eine Vielzahl grafischer Komponenten zur Verfügung. Programmierer können sie auch wie Chamäleons einsetzen, die ihr Erscheinungsbild der jeweiligen Plattform anpassen, auf der die Anwendung gerade läuft. Mitten im Betrieb kann zwischen dem neutralen Java-Aussehen und etwa einer Mac- oder Windows- typischen Oberfläche umgeschaltet werden, ohne die zugrunde- liegenden Funktionen zu beeinflussen.

Vermisst

Mit dem Hauptzweck von Java, plattformübergreifende Applikationen zu schreiben, liegt noch einiges im argen. Jedenfalls ist derzeit nicht immer davon auszugehen, daß ein Programm, das auf einer Plattform läuft, auch unter einem anderen Betriebssystem ein gleiches Verhalten zeigt. Hauptursache dafür sind Unterschiede in der Implementierung der Java Virtual Machines für die jeweilige Plattform.

Die Virtual Machines bieten aus einem weiteren Grund Anlaß zur Kritik: Ihre Größe hat bereits für manche Systeme bedenkliche Ausmaße angenommen. Wenn mindestens 16 MB freier Speicher vorhanden sein müssen, kann von einem "Thin-Client" nicht mehr die Rede sein. Dazu kommen weitere 20 MB für die Klassenbibliotheken. Andererseits fehlen dem Abstract Windowing Toolkit noch wichtige Funktionen.

Standpunkt

Neue Java-Tools tauchen in großer Vielfalt am Markt auf. Das Web verspricht viele Vorteile und wird in wenigen Jahren konventionelle Netze zweifelsohne alt aussehen lassen: "Web-basiertes wird LAN-basiertes File-sharing zum Anachronismus machen", so drücken das die Kaffeesatzdeuter der Gartner Group gewohnt manieriert, aber zutreffend aus.

Nur, wer soll das bezahlen? Was tun Unternehmen mit den Millionen und Milliarden Codezeilen, die sie in der Vergangenheit produziert haben? Sind die vielen Cobol-, 3270-, CICS-, aber auch Visual-Basic-, C++- und SQL-Windows-Applikationen wertlos geworden? Wer stellt die astronomischen Budgets für Neuentwicklungen zur Verfügung? Neben in der Tat wirklich neuen Electronic-Commerce-Lösungen sollen ja auch ganz konventionelle Applikationen im Web verfügbar werden, zum Beispiel eine Warenwirtschaft oder eine Fibu. Alles neu?

Paradoxerweise scheint sich der Großteil der Web-willigen Industrie mehr auf die Entwicklung netter, kleiner Nice-to-have-Java-Applets zu konzentrieren, anstatt auf die Fragen, wie sich künftig mit Hilfe des globalen Netzes DV-Kosten senken lassen oder wie eine Strategie aussieht, die neue Web-spezifische mit bereits existierenden, konventionellen Applikationen integriert. Diese Fragen sind für Unternehmen aber bald existentiell.

Der proklamierte Paradigmenwechsel ist in Wirklichkeit keiner. Die angeberische und wortgewaltige Diskussion könnte gar viele Unternehmen davon abhalten, sich ernsthaft mit dem Web auseinanderzusetzen. Nein: Das Web ist vielmehr eine Evolution, nichts anderes also als der nächste logische Schritt in der DV-Geschichte: Client-Server-Architektur um eine neue Plattform erweitert.

Wer Client-Server-Applikationen in der Vergangenheit logisch-konzeptionell sauber entwickelt hat oder "mission-critical"-Großrechnerlösungen einsetzt, kann sie auf dieser Basis ins Web stellen Ñ gleichberechtigt mit den neu hinzugekommenen Anwendungen. Aufwand und Kosten sind verhältnismäßig gering: Man will ja nicht gleich eine komplette Fibu im Web integrieren, sondern bloß den direkten Zugang schaffen. Dazu ist lediglich die Entwicklung neuer Benutzerschnittstellen notwendig, die gleichzeitig der bestehenden Lösung neuen Glanz verleihen.

1997 ist zunächst einmal das Jahr der Informationssammlung. Die meisten Unternehmen werden nicht sofort ihre komplette DV auf das Web umstellen, sondern sich fundiert auf diesen nächsten Schritt vorbereiten wollen. Das braucht seine Zeit, und erfordert eine Lern- und Experimentierphase.

Es muß andererseits aber auch klar sein, daß die Web-Technik - sei es in Form des Internet oder von Intranets - für die Industrie sehr schnell eine strategische Tragweite erlangen wird. Sie erlaubt es nicht, Entscheidungen lange hinauszuzögern. Je intensiver die Industrie sich schon heute mit der Web-Integration neuer und existierender Lösungen auseinandersetzt, desto besser ist sie für die neuen Herausforderungen am Weltmarkt gerüstet.Alain Blaes, Geschäftsführer der Agentur PR-Com in Martinsried bei München.

Angeklickt

Die Programmiersprache Java symbolisiert den Traum von offenen, plattformunabhängigen Lösungen, die einen riesigen, weltweiten Markt versprechen. Java entwickelt sich jedoch mindestens so rasant wie das Internet selbst. Daher müssen Entwickler stets auf Änderungen des Standards gefaßt sein und ihre Programme entsprechend offen und flexibel halten. Das kostet zwar eine Menge Lehrgeld, doch abzuwarten kann sich niemand leisten, der in diesem Markt mitmischen will. Anwendungen sollten in klar abgegrenzte Einheiten aufgeteilt werden, die über sauber definierte Schnittstellen miteinander kommunizieren. Dadurch läßt sich eine Einheit ändern, ohne die anderen zu beeinträchtigen.

*Diplomingenieur Frank Schuhmacher ist Mitarbeiter des Systemhauses für Client- Server-Technologie DAA in Baden-Baden.