LAURES: Wollen wir zu Beginn einen beliebten Vorwurf der Java-Community aufgreifen: Ist .NET ein Java-Clone? Denn ungeachtet dessen, was die Marketing-Abteilungen von Sun und Microsoft erzählen, sehen sich die beiden zum Verwechseln ähnlich.
DATSICHIN: .NET ist kein Clone, es ist eine Alternative - und natürlich eine Konkurrenz. Beide sind objektorientierte Frameworks, setzen eine Laufzeitumgebung voraus und bieten Programmiermodelle für Client-, Server- und Mobilanwendungen. Darüber hinaus stellen sowohl Java als auch .NET die für Enterprise-Entwicklung üblichen Dienste zur Verfügung.
Der Java-Einfluss in .NET ist allerdings nicht zu übersehen. Es sind aber auch viele Ideen aus anderen Sprachen und Forschungsprojekten dort eingeflossen.
LAURES: .NET ist die konsequente Portierung eines erfolgreichen Konzepts in die Windows-Welt. Dass dabei natürlich kräftig abgekupfert wurde, ist klar. Durch eigenständige Neuerungen bringt .NET frischen Schwung in die Java-Fraktion. Die Konkurrenz durch Microsoft tut Java gut.
In meinen Augen hinkt .NET dem Konkurrenten J2EE, was die Integrität der einzelnen Schichten eines Enterprise-Systems betrifft, klar hinterher. Die führenden J2EE-Plattformen bieten eine solche durchweg an.
DATSICHIN: Sie beziehen sich bestimmt auf das von Gartner entwickelte Konzept der Application Platform Suite, bei der die wichtigsten Komponenten einer Server-Plattform wie Portal, Integration Broker, Applikations-Server und Entwicklungsumgebung eng miteinander verzahnt sind und als Gesamtpaket vermarktet werden?
LAURES: Exakt. Hier ist die Java-Community einen Schritt weiter. Enterprise-Anwendungen basieren auf dem Zusammenspiel von mehreren Schichten, von denen nur eine durch den Applikations-Server repräsentiert wird. Dazu zählen jene für die Präsentation, die typischerweise in ein Portal eingebettet wird, eine Integrationsschicht, die Umsysteme in den abzubildenden Geschäftsprozess einbindet, und ein Applikations-Server, der neue Geschäftslogik und Persistenzmechanismen zur Verfügung stellt. Dieses Prinzip zieht sich durch alle Produkte der relevanten Hersteller.
DATSICHIN: Gerade Microsoft verfolgt ja seit Jahren die Strategie, möglichst viele Funktionen in das Betriebssystem zu packen. Die typischen Dienste eines Applikations-Servers werden von Windows angeboten. Darauf bauen weitere Anwendungen wie "Biztalk" oder "Sharepoint" auf. Microsoft wird oft für eine schlechte Anbindung zur Außenwelt kritisiert, aber in puncto Integration und Zusammenspiel der eigenen Produkte setzt es Maßstäbe.
Ich befürchte jedoch, dass dieser Trend gerade im Java-Umfeld dazu führt, dass die von der J2EE-Community oft so gepriesene Anbieterunabhängigkeit auf der Strecke bleibt. Wenn ich auf die proprietären Features von Weblogic setze, habe ich keine Möglichkeit mehr, meine Anwendung auf Websphere zu portieren. Hinsichtlich Herstellerabhängigkeit unterscheidet sich also J2EE keinen Deut von .NET.
LAURES: Natürlich versucht jeder Hersteller sein Produkt über proprietäre Features zu vermarkten. Anders als mit .NET habe ich allerdings als J2EE-Architekt und Entwickler immer noch die Freiheit, nach Spezifikation und damit portabel zu programmieren. Ich kann selbst entscheiden, ob ich mich einem Hersteller ausliefere. Im Fall von Microsoft gerate ich nicht nur in Abhängigkeit von .NET, sondern auch noch von Windows.
DATSICHIN: Tatsache ist, dass .NET momentan eng mit der Windows-Plattform verwoben ist. Die Laufzeitumgebung an sich ist portabel, und Microsoft hat sogar für die nicht-kommerzielle Nutzung eine "Shared-Source"-Implementierung ("Rotor") für Windows, FreeBSD und Mac OS freigegeben. Dabei handelt es sich natürlich nicht um den Quellcode des Produktivsystems, also die optimierten Varianten des Memory-Managers, des Garbage-Collectors und der Compiler. Darauf baut übrigens auch das Mono-Projekt auf, welches an einer freien Implementierung von .NET für Linux arbeitet.
LAURES: Das Mono-Projekt halte ich aus zweierlei Hinsicht für bedenklich: Erstens glaube ich nicht, dass Microsoft wirklich an einer funktionierenden .NET-Umgebung außerhalb von Windows interessiert ist. Das ist in meinen Augen Marketing, um die Sympathie der Open-Source-Community zu gewinnen. Mono wird scheitern, weil es keine vollständige Spezifikationen für Microsofts proprietäre Technologie gibt, nach denen man programmieren könnte. Und zweitens wird ohnehin niemand seine komplexen Backend-Anwendungen auf Basis einer Open-Source-Lösung entwickeln.
DATSICHIN: Das schließt aber dann auch den Einsatz des quelloffenen J2EE-Servers "Jboss" aus?
LAURES: Nicht wirklich. Denn im Gegensatz zu Mono basiert Jboss abprüfbar auf der J2EE-Spezifikation. Microsoft lässt das Mono-Projekt jedoch im Glauben, es könnte etwas Proprietäres nachbauen.
DATSICHIN: Bei .NET bemüht sich Microsoft sehr wohl um Standardisierung und Offen-heit. Zum einen sind offene Technologien wie XML tief im Framework verankert. Zum anderen haben die ECMA und ISO bereits zwei .NET-bezogene Standards verabschiedet. Der eine normiert die Syntax von C#, und der andere beschreibt die "Common Language Infrastructure", also die Laufzeitumgebung von .NET sowie die Basisbibliotheken. Man muss aber einräumen, dass ASP.NET oder Windows Forms bisher von der Standardisierung ausgeschlossen blieben.
LAURES: Stehen diese Standardisierungsbemühungen von Microsoft mit den vor kurzem eingereichten Patentansprüchen auf .NET Framework nicht im Widerspruch?
DATSICHIN: Die Bedingungen von ECMA/ISO verlangen, dass alle für die Implementierung des Standards relevanten Patente unter "reasonable and non-discriminatory terms" verfügbar gemacht werden. Microsoft, Intel und Hewlett-Packard haben sich darauf geeinigt, für die C# und CLI betreffenden Patente keine Lizenzgebühren zu erheben. Leider bedeutet das gleichzeitig, dass andere Teile wie ASP.NET und Windows Forms unter strengerer Kontrolle gehalten werden können.
LAURES: Bleiben wir doch mal bei dem Beispiel ASP.NET. Für einen J2EE-Entwickler ist es eine Selbstverständlichkeit, für ein architektonisches Konzept eine saubere Spezifikation zu haben, die genau beschreibt, wie sich die Plattform, auf der ich arbeite, verhält. Bei Microsoft hingegen finde ich oft nur Beispiele, gepaart mit etwas Marketing und technischer Prosa. Das entspricht in meinen Augen genau dem Konzept, das Microsoft auch bei den Entwicklungswerkzeugen und Sprachen wie Visual Basic verfolgt: Vor lauter Wizards versteht der Entwickler nicht mehr, was eigentlich das Endprodukt seiner Arbeit ist. Im Fehlerfall steht er dann vor einem großen Problem.
DATSICHIN: Gibt es denn wirklich "saubere" Spezifikationen für das viel genutzte Apache-Framework "Struts"? Auch die Dokumentation von .NET ist nicht besser oder schlechter als die von Java. Und es macht auch wohl kaum einen Unterschied, ob ein Helferlein wie bei Microsoft "Wizard" oder "Smartguide" wie bei IBM heißt. Ich bin froh, wenn solche Tools den Entwicklungsprozess beschleunigen.
LAURES: Ich sehe das Problem, dass .NET auf die Erstellung komplexer Anwendungen abzielt. Diese folgen aber nicht unbedingt einem bestimmten Muster. Der Architekt oder Entwickler muss in diesem Umfeld verstehen, was er tut. Da helfen keine bunten Wizards, da diese immer nur Standardfälle abdecken.
DATSICHIN: Natürlich wird Ihnen kein Wizard oder Tool die Denkarbeit abnehmen. Ein Framework kann aber durch die darin verankerten Konzepte und Modelle die Implementierung der Lösung wesentlich vereinfachen. .NET bietet in allen Bereichen eine vernünftige Standardimplementierung an, die im Normalfall ausreicht. Man hat aber immer die Chance, diese zu erweitern oder ganz zu ersetzten.
LAURES: Ich würde das Gespräch gern noch auf eine dritte Abhängigkeit lenken, die bei Java immer erwähnt wird. Im Gegensatz zu Java wartet .NET mit der Unterstützung für viele Sprachen auf. Nach meiner Einschätzung wird dieses Feature überschätzt, weil Programmiersprachen an Bedeutung verlieren.
DATSICHIN: Es ist eine der größten Stärken von .NET überhaupt, dass jeder Hersteller einen eigenen Compiler für .NET anbieten kann. Die Werbung verschweigt jedoch, dass man zum Beherrschen von .NET mehr benötigt als die Syntax einer Sprache. Es sind neue Bibliotheken, neue Konzepte und Modelle - auch wenn sie intuitiv sind -, die erlernt sein wollen. Ein Cobol-Programmierer wird nicht über Nacht zum .NET- oder Java-Entwickler.
LAURES: Bei den Bibliotheken und APIs sehe ich J2EE klar im Vorteil. Zum einen, weil die Libraries im Lauf der Zeit ausgereift sind, und zum anderen, weil hinter ihnen ein ganzes Herstellerkonsortium steht.
Neben den APIs sind auch die Entwicklungswerkzeuge wichtig, die für eine Plattform zur Verfügung stehen. Und auch hier schneidet Java besser ab.
DATSICHIN: Es gibt momentan lediglich zwei kommerzielle Anbieter für .NET-Tools: Microsoft selbst und Borland. "Visual Studio" von Microsoft ist zwar ein ausgezeichnetes Entwicklerwerkzeug, es konzentriert sich jedoch auf die Software-Erstellung. Borland dagegen will mit seinen Produkten den kompletten Lebenszyklus einer .NET-Software abdecken.
Bei den Open-Source-Tools handelt es sich meistens um Java-Tools Portierungen, wie beispielsweise "NAnt" oder "OJB.NET". Aber die Anzahl der Projekte nimmt rapide zu.
LAURES: Bei der Bewertung des Entwicklungsmarkts wird oft übersehen, dass immer mehr Insellösungen entstehen, die eine bestimmte Phase des Softwarelebenszyklus abdecken, sich aber nicht in einen komplexen Gesamtprozess verteilt arbeitender Experten eingliedern. Dies gilt insbesondere für die im .NET-Umfeld eingesetzten Werkzeuge. Microsoft hat hier den Trend zur Tool-Suite verpasst. Da waren Borland mit dem Kauf von Starbase und Togethersoft und IBM mit der für Microsoft schmerzlichen Übernahme von Rational schlauer. Die .NET-Welt steht jetzt ohne ein wirklich gutes Modellierungswerkzeug da, und das, obwohl gerade die Modellierung in einem komplexen Umfeld immer wichtiger wird.
Microsoft wirbt nicht zuletzt wegen seiner benutzerfreundlichen Werkzeuge mit einer niedrigen Total Cost of Ownership für .NET-basierende Lösungen. Ich glaube nicht, dass diese Rechnung aufgeht.
DATSICHIN: Bei vergleichbarer Funktionalität liegen die Kosten für eine .NET-gestützten Lösung oft weit unter denen einer kommerziellen J2EE-Anwendung. Dieser Kostenvorteil kommt vor allem dadurch zustande, dass die Enterprise Services mit dem Betriebssystem ausgeliefert werden.
Ich gebe jedoch nicht viel auf Studien bezüglich TCO. Die Architektur einer Enterprise-Lösung wird durch das Geschäftsmodell, funktionale und nichtfunktionale Anforderungen sowie durch die bestehende Infrastruktur bestimmt. Ein Kostenvergleich hat für mich nur im Kontext einer konkreten Architektur Sinn.
LAURES: Bei einer J2EE-Lösung besteht auch hinsichtlich der Kosten durch die Vielzahl an Anbietern ein größerer Spielraum. Bei .NET ist fast ausschließlich auf Microsoft-Produkte angewiesen, mit der Ausnahme von Datenbanken und ein paar Entwicklungs-Tools. Da kann man gleich mit erheblichen Fixkosten rechnen.
In vielen Fällen wird aber eine Wahlfreiheit zwischen Java und .NET ohnehin nicht bestehen. Vielmehr entstehen gemischte Anwendungen, weil etwa am Desktop kein Weg an .NET vorbeiführt.
DATSICHIN: Ich bin ebenfalls überzeugt, dass .NET auf jeden Fall die Basis für fast alle Client-Anwendungen unter Windows sein wird. Auch am Windows-Server wird es wohl so sein. Da steckt die gesamte Marketing-Macht von Microsoft dahinter.
LAURES: Ich denke auch, dass .NET sich eher bei Frontends positionieren wird. Im lukrativen Backend rechne ich jedoch mit einer Fortsetzung der J2EE-Erfolgsgeschichte. Viele Großunternehmen haben sich gerade für J2EE entschieden und werden jetzt kaum auf .NET umschwenken.
DATSICHIN: Gartner und andere Marktanalysten prophezeien, dass die meisten Großunternehmen J2EE und .NET gleichzeitig einsetzen werden. Angesichts dieser Prognose wird nicht die Frage "Was ist besser", sondern "Wie bringe ich diese Welten zusammen" entscheidend sein.
Nach meiner persönlichen Einschätzung sind Web-Services hier die wichtigste Technologie. Der Soap-Standard wird von allen großen Herstellern unterstützt. Einige Analysten sagen immer noch, die Web-Services seien noch nicht ausgereift. Man darf Web-Services nicht auf das "XML über HTTP" reduzieren. Vielmehr muss man die Gesamtheit der "Global XML Web Services Architecture" betrachten: UDDI, Security, Reliable Messaging, Transactions. Sie sind der zweite Atem für den Internet-Boom und das Bindeglied der serviceorientierten Architektur.
LAURES: Das sehe ich genauso und hoffe, dass sich damit ein Standard wirklich einmal übergreifend durchsetzen kann. Ziehen wir ein Fazit: Wie es aussieht, wird sich .NET als Java-Alternative in kleinen und mittleren Unternehmen etablieren.
DATSICHIN: .NET möchte gern in die Enterprise-Entwicklung. Es besitzt aus der technologischen Sicht die Voraussetzungen dazu, leidet aber unter dem Microsoft-Image (Instabilität, Sicherheitsmängel). .NET wird zudem erst noch die Rentabilitäts- und TCO-Versprechungen einlösen müssen. (ws)