CW: Für die Kommunikation zwischen verteilten Anwendungen nutzt .NET durchgängig das Simple Object Access Protocol (Soap). Zu diesem Zweck gibt es schon eine Reihe anderer Mechanismen. Warum herrscht nach Ihrer Meinung in der ganzen Softwarebranche eine solche Aufregung über Soap?
Gosling: Weil Microsoft dafür Unsummen an Marketing-Dollars ausgegeben hat. Das ist die Wahrheit. Soap hat weniger Features und ist langsamer als etwa Corba. Aber die Object Management Group (OMG) hatte nie solche Marketing-Budgets wie Microsoft. Der einzige tatsächliche Vorteil von Soap beruht auf der Nutzung von XML. Dabei handelt es sich um ein flexibles und selbstbeschreibendes Format. Besonders elektronische Geschäftsdokumente, die Unternehmen austauschen, liegen immer häufiger in dieser Syntax vor und eignen sich daher besonders als Nutzlast für Soap. Ansonsten finde ich die Idee, ein Protokoll auf HTTP zu schichten, ehrlich gesagt dumm.
Vertreter von Microsoft nennen als besonderen Vorteil dieser Lösung, dass die meisten Firewalls HTTP durchlassen. Für mich liegt dieses Argument irgendwo zwischen absurd und gefährlich. Als eines der wichtigsten Features dieser Technolgie gilt mithin, dass sie sehr leicht gegen die Sicherheitsregeln von Unternehmen verstoßen kann. Alle bekannten Protokolle wie Corba, Remote Method Invocation (RMI) oder Remote Procedure Call (RPC) funktionieren wunderbar über Firmengrenzen hinweg - wenn man die Firewalls richtig konfiguriert. Der Systemverwalter hat in diesem Fall wesentlich mehr Kontrolle darüber, was über das Internet herein- und hinausgeht. Wenn Leute aber alles durch den Port 80 schleusen, höhlen sie das Konzept der Firewall als Sicherheitsbarriere aus.
CW: Das Problem scheint sich nur zu verschieben. Sicherheitsverantwortliche setzen zukünftig wohl auf Content-Filter für den Port 80. Werden Soap-Filter zu einem Standard-Feature für Firewalls?
Gosling: Absolut! Alle Anbieter von Sicherheitssoftware werden Soap-Filter anbieten. Außerdem können schon heute die meisten Firewalls mit Hilfe von Suchmustern Inhalte blockieren. Ich glaube deshalb, dass viele Administratoren bereits entsprechende Vorkehrungen treffen.
CW: Beim Vergleich von Corba und Web-Services drängt sich die Analogie zu SGML und XML auf. SGML gab es auch schon lange, galt aber als zu kompliziert und wurde daher kaum genutzt. Der Durchbruch kam erst mit der Light-Version namens XML. Corba hat ebenfalls den Ruf, übermäßig komplex zu sein. Hat die Euphorie über Web-Services ihren Grund nicht darin, dass sich damit relativ einfach verteilte Anwendungen entwickeln lassen?
Gosling: Ich glaube nicht an dieses Versprechen der Einfachheit. XML war vielleicht in seinen Anfängen eine simple Technik. Wenn Sie sich die ganzen Co-Standards wie XML Schema oder Namespaces ansehen, dann ist XML mittlerweile mindestens genauso komplex wie SGML.
CW: Mit Hilfe von Soap können Anwendungen doch sehr einfach miteinander kommunizieren. Komplizierte Techniken wie WSDL oder UDDI müssen bei Web-Services ja gar nicht genutzt werden.
Gosling: Das ist richtig. Im Übrigen erstaunt mich die XML-Gemeinde immer wieder damit, dass sie die komplexen Aspekte von Spezifikationen ignoriert. Durchschnittliche Anwendungen, die XML nutzen, greifen nur auf einen kleinen Ausschnitt dieser Technologie zurück. Ich hätte mir gewünscht, man hätte die ursprüngliche XML-Spezifikation belassen, wie sie war, anstatt sie mit so vielen zusätzlichen Standards aufzublähen.
Für Web-Services werden nun zahlreiche weitere XML-Anwendungen aus dem Boden gestampft, um all jene Funktionen zu realisieren, die Corba schon vor Jahren bot. Dazu zählen etwa solche für Transaktionen oder Sicherheit. Die XML-Verfechter können nichts vorweisen, was besser wäre, ihre Technik ist nur langsamer und voluminöser.
CW: Im Internet kursieren diverse Wunschlisten, die Verbesserungen für Java unterbreiten. Ein häufig geäußerter Vorschlag drängt darauf, eine der beiden Grafikbibliotheken über Bord zu werfen. Gemeint ist damit natürlich nicht Swing, sondern das längst überholte Abstract Windowing Toolkit (AWT). Was halten Sie davon?
Gosling: Wir hatten für die Entwicklung von AWT vier Wochen Zeit, bevor Java 1.0 ausgeliefert wurde. Angesichts dieser Umstände finde ich das AWT eigentlich ganz gut. Es gibt viele Leute, die AWT samt seinem problematischen Event-Modell liebend gerne aus Java löschen würden - und ich gehöre ganz vorne mit dazu. Wir haben mittlerweile einige Altlasten in Java, von deren Verwendung wir schon länger abraten. Aber wir können sie aus Gründen der Abwärtskompatibilität nicht einfach eliminieren.
CW: Möglicherweise etabliert sich in Java bald eine dritte Grafikbibliothek. Ich spreche von IBMs "Standard Widget Toolkit" (SWT), das mit "Eclipse" ausgeliefert wird. SWT nutzt die nativen Dialoge des Betriebssystems und soll laut IBM daher schneller ablaufen als Swing. Außerdem sähen Java-Anwendungen dann so aus wie native Programme für das jeweilige System. Wie denken Sie über dieses Modell?
Gosling: Das ist absolut lächerlich. SWT verfolgt doch den gleichen Ansatz wie AWT! Genau das Betriebssystem-abhängige Look and Feel empfanden viele Anwender als Nachteil, weil es ihnen Schwierigkeiten beim Verfassen der Dokumentation bereitete. Swing hingegen bietet mehrere Oberflächen zur Auswahl, die sich über alle Betriebssysteme hinweg exakt gleich verhalten. Sobald Sie nach dem Muster von IBM mehrere Plattformen unterstützen wollen, geraten Sie in Teufels Küche. Wenn ein bestimmtes Bildschirmelement, das Sie sonst überall anbieten möchten, auf einigen Systemen nicht existiert, müssen Sie es dort in Java nachbauen. Zum Schluss haben Sie dann ein riesiges Set selbst entworfener Komponenten à la Swing und müssen zudem die ganze Komplexität der Betriebssystem-eigenen Dialoge beherrschen. Besonders unverständlich finde ich, dass ausgerechnet die IBM einen solchen Vorstoß unternimmt. Diese Firma hat uns am meisten dazu gedrängt, Swing zu entwickeln.
CW: Seit Microsoft .NET vorstellte, fordern Beobachter immer wieder, dass auch die Java-Plattform mehrsprachig werden müsse. Zwar lassen sich diverse Programmiersprachen für die Java Virtual Machine (JVM) übersetzen, den Segen von Sun gab es dafür aber nie. Planen Sie eine "offizielle" Mehrsprachigkeit von Java, etwa durch Zertifizierungen?
Gosling: Tatsächlich existieren schon seit längerem Compiler für unterschiedliche Programmiersprachen, die Java-Bytecode erzeugen können. Aus unserer Sicht ist das völlig in Ordnung. Allerdings sehe ich nicht, welchen Nutzen eine Zertifizierung solcher Übersetzer haben soll. Wir selbst konnten keine nennenswerte Nachfrage nach anderen Sprachen feststellen.
Auch wenn sich die meisten Sprachen gut mit der JVM vertragen, so gibt es aufgrund ihres übergreifenden Objekt- und Speichermodells doch häufig subtile Probleme. Besonders gilt dies für C und C++, die den Konzepten von Java hinsichtlich Sicherheit und Verlässlichkeit widersprechen. Wir könnten beide Sprachen unterstützen, aber nur auf Kosten dieser Eigenschaften.
Microsoft stand im Prinzip vor der gleichen Situation wie wir. Zum einen müssen Sprachen an das allgemein gültige Objektmodell der Common Language Runtime (CLR) angepasst werden. Besuchen Sie doch die Website von Eiffel (http://www.eiffel.com) und beachten Sie den Unterschied zwischen "richtigem" Eiffel und Eiffel für .NET. Das sind verschiedene Sprachen. Ähnliches gilt auch für C++, da kann bestehender Code nicht einfach übernommen werden. Wenn Microsoft behauptet, .NET unterstütze mehrere Sprachen, dann ist das eigentlich falsch.
Zum anderen hat Microsoft mit C/C++ für .NET die wesentlichen Vorteile einer Laufzeitumgebung eliminiert. Weil die Verwendung von Zeigern weiterhin erlaubt ist, schleppt man die altbekannten Probleme dieser Sprachen auch in Zukunft mit. Dazu zählen besonders ungültige Speicherzugriffe, die oft nur schwer auffindbar sind und die Entwicklungszeit verlängern. Vor allem stellen sie aber ein riesiges Sicherheitsproblem dar. Merkwürdig finde ich außerdem, dass nicht nur diese Legacy-Sprachen Risiken bergen, sondern dass auch C# mit seinem "unsafe mode" das Speichermodell der CLR aushebelt.