Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.06.1998 - 

Java/Einschränkungen und Gezänk sollten Anwender nicht irritieren

Java ist auf dem Weg zu großen unternehmensweiten Anwendungen

Die Sprache allein ist keine ausreichende Erklärung für den Erfolg von Java. Sie ist eine Weiterentwicklung von C++ und Smalltalk. Java verbindet zwar die Vorteile beider Sprachen, ist aber genau wie diese recht kompliziert. Viele Entwickler kaufmännischer Anwendungen, die mit Cobol, C oder Sprachen der vierten Generation arbeiten, können Java nicht ohne weiteres anwenden.

Als sich C++ und Smalltalk vor einigen Jahren ausbreiteten, gab es Prognosen, wonach sie alle vorangegangenen Sprachen der dritten und vierten Generation und auch die darauf abgestimmten Verfahren des Software-Engineering bald ablösen würden. Das hat sich als Fehleinschätzung erwiesen.

Außer der Komplexität objektorientierter Sprachen haben die Auguren nämlich auch die lange Lebensdauer bestehender Softwaresysteme unterschätzt. Ein umfassender Erfolg von C++ und Smalltalk wäre nur bei einem Austausch bestehender Anwendungssysteme und der ihnen zugrundeliegenden Technologien möglich gewesen. Aber das können sich weder viele Anwender noch Anbieter leisten.

Neben der Objektorientierung bietet Java eine Reihe von Vorteilen. Mit der Applet-Technologie gelang schon früh der Schritt in die Komponententechnik. Mit Javabeans und dem neuen Enterprise Javabeans Framework entstehen Komponentenlösungen für den unternehmensweiten Client-Server-Einsatz.

Weiterhin erweist sich die Laufzeitumgebung Java Virtual Machine (JVM) von besonderer Tragweite. Sie dient als Plattform für kompilierte Java-Programme, den Java Byte Code, und hat sich inzwischen de facto als Industriestandard bei den DV-Anbietern durchgesetzt. Hersteller von Unix- und Windows-Systemen, selbst IBM für seine Großrechner, bieten JVMs an. Sie sind im Prinzip unabhängig von der Sprache, mit der Programme erstellt werden. Also brauchen Objektprogramme, die auf einer JVM laufen, nicht unbedingt mit Java erstellt zu sein.

Weiterhin gibt es die Kommunikationsmethode Remote Method Invocation (RMI), die es Java-Programmen erlaubt, andere Java-Anwendungen aufzurufen, die nicht auf dem gleichen System laufen. RMI ist in Kombination mit JVM Träger der Javabeans-Architektur, die den Aufbau und Betrieb von Client-Server-Systemen mit Java erlaubt.

In einer Applet-Umgebung ist es primäre Aufgabe eines Web-Servers, Applets vorzuhalten, die Clients bei Bedarf abrufen und herunterladen können. Kaufmännische Anwendungssysteme verlangen jedoch starke Applikations-Server, die die aufgerufenen Funktionen durchführen können. Dieses Paradigma hat sich durch Java nicht verändert.

Es ist nach wie vor erwünscht und sinnvoll, daß größere Gruppen von Anwendern, zum Beispiel Sachbearbeiter in der Finanz- oder Auftragsabteilung oder Kundendienst-Ingenieure, auf gemeinsam genutzte Funktionsbibliotheken auf Servern zugreifen können. Man hat es also mit Transaktionen zu tun. Deren Code in Applets zu packen und bei Bedarf auf Clients herunterzuladen, hat keinen Sinn, zumal sich auch die Datenbanken für die kaufmännischen Daten auf den Servern befinden.

Vielfach ist von Fachleuten der Vorbehalt zu hören, daß eine Client-Server-Architektur mit Java an zu geringer Performance scheitern würde. Das ist sicher nicht von der Hand zu weisen. Jedoch ist zu erwarten, daß die Prozessorleistung zukünftig weiter so steigen wird, daß dieser Mangel kompensiert wird. Diese Vorbehalte gab es früher auch gegen große Benutzerzahlen auf Unix-Servern. Heute ist das dank der stark gestiegenen Server-Leistung kein Thema mehr.

Weitere Verbesserungen bietet die Software. So soll das neue Java Developer Kit in der Version 1.2 bis zu 50 Prozent mehr Perfomance bringen. Die Hot-spot-Technik von Sun optimiert den Maschinencode weiter. An diesem Punkt lassen sich Bemühungen der Systemhersteller um Java gut erkennen.

Interessensgegensätze auf Anbieterseite gibt es allemal: Nämlich zwischen der Unterstützung von Standards einerseits, also der Sprache und der Plattform JVM, und plattformspezifischen Java-Erweiterungen andererseits. Es ist jedoch völlig unnötig, sich von diesen Auseinandersetzungen zwischen den von Sun beziehungsweise Microsoft angeführten Fraktionen beunruhigen zu lassen.

Hat doch hier auch die weltweite Anwenderschaft ein Wort mitzureden. Das läßt sich zum Beispiel daran ermessen, daß sie selbst IBM gezwungen hat, das Großrechner-Betriebssystem MVS Unix-fähig zu machen. Anwenderinteressen werden es nun auch schaffen, Java zum Durchbruch in heterogenen Systemumfeldern zu verhelfen.

Selbst wenn die Java-Technologie in Zukunft unter herstellerspezifischen Besonderheiten leiden sollte, wird es Integrationswege geben. Sie bauen auf zwei Konzepten auf, auf Corba-Technologie von der Object Management Group oder auf DCOM von Microsoft. Corba-Objekte kommunizieren in TCP/IP-Netzen über das Internet Inter ORB Protocol (IIOP), Microsoft nutzt einen DCE-kompatiblen Remote Procedure Call (RPC). Diese Mechanismen sind von der JVM aus nutzbar.

Für Transaktionen gibt es in klassischen Systemumgebungen TP-Monitore wie CICS oder Encina. Damit der Schritt von Java-Technologie in das kaufmännische Umfeld mit großen Benutzerzahlen gelingen soll, entstehen derzeit leistungsfähige Lösungen.

Eine besteht darin, die Transaktionskontrolle aus dem einzelnen Anwendungsobjekt herauszulösen und einem übergeordneten Steuerungsobjekt zu überlassen. Eine Erweiterung wäre die sogenannte "lange Transaktion". Sie kontrolliert umfassende Geschäftstransaktionen, die sich über einen längeren Zeitraum erstrecken.

Was dem Kaufmann an Java noch fehlt

Derlei ist beispielsweise für die Ausführung eines Auftrages nötig, der über eine Electronic-Business-Anwendung im Internet hereinkommt und der zu Bestellungen bei Lieferanten und schließlich zur Lieferung und zur Zahlung führt. Die "lange Transaktion" sieht auch kompensierende Aktionen vor, die bei Stornos nötig sind.

Es gibt weitere Defizite in der Sprache Java, die im kaufmännischen Umfeld sehr schmerzhaft sind. So rechnen Java-Programme mit Exponentialzahlen, was kaufmännische Rundungen erschwert. Das hat einfache historische Ursachen: Die Applets, die das Grundelement für Java darstellten, konnten keine kaufmännischen Rechenaufgaben lösen, da sie für solche Aufgaben einfach nicht vorgesehen waren.

Es stehen jedem Hersteller Chancen offen, die Java-Technologie auch für Einsatzzwecke fit zu machen, für die die Sprache ursprünglich nicht geplant war. Außerdem gibt es zahlreiche spezielle Möglichkeiten für Komponentenbauer. Ein Beispiel sind die unterschiedlichen Rundungsregeln für kaufmännische Summen in der Schweiz, Deutschland oder anderen Ländern.

Die Java-Technologie ist also flexibel und erweiterbar. Zukünftige Entwicklungsumgebungen werden die Integration von Java- und Nicht-Java-Systemen noch besser unterstützen. Damit können Anwender die neue Technik einsetzen und zugleich ihre Investitionen in vorhandene betriebswirtschaftliche Systeme, seien es nun Individual- oder Standardanwendungen, weiter nutzen. Java-Technologien werden sowohl umfassende Systeme bilden als auch bestehende Systeme ergänzen und sowohl Server als auch Clients unterstützen.

Angeklickt

Noch sind Defizite von Java zu erkennen. Aber sie verbauen der neuen Technologie nicht die Perspektiven. Zum einen verbessern sich alle Techniken im Java-Spektrum mit außerordentlicher Geschwindigkeit, zum anderen wird die allgemeine technische Entwicklung Schwächen, zum Beispiel in puncto Performance, ausgleichen. Historische Analogien gibt es über Unix hinaus. Zur Zeit geht es um Java-Applikationen auf Servern und damit um Transaktionen. Dann steht die neue Technik auch für unternehmensweite Anwendungen mit großen Nutzerzahlen offen. Lösungswege in dieser Richtung sind schon vorhanden.

Rainer Glaap ist Produkt-Marketing-Manager für Bolero und Wolf-Ruediger Hansen Pressesprecher bei der Software AG, Darmstadt.