Web

"Wer für Java-Produkte Geld ausgibt ist feige"

01.07.2002
J2EE und .Net sind die Plattformen der Zukunft. Doch welche passt zu wem? Ein Appetithappen aus der neuen "CW extra" zum Thema "Die Zukunft der Software".

J2EE und .Net sind die Plattformen der Zukunft. Doch welche passt zu wem? Ein Appetithappen von Michael Bauer* aus der "CW extra" vom vergangenen Freitag...

In den letzten fünf Jahren wurden 4GL-Sprachen, aber auch Smalltalk durch Java verdrängt und das Fat-Client-Konzept ist durch eine mehrschichtige Architektur abgelöst. Daneben sind Web-Technologie und die Extended Markup Language (XML) eine Selbstverständlichkeit und vereinzelte Middleware-Ansätze wie Distributed Computing Environment (DCE) oder die Common Object Request Broker Architecture (Corba) wurden durch übergreifende technische Infrastrukturen ersetzt. Übriggeblieben sind heute im Wesentlichen nur noch zwei technische Plattformen für neue Anwendungen: Java 2 Enterprise Edition (J2EE) und Microsoft .Net. Um hier die richtige Entscheidung für die Zukunft zu treffen, sollten Anwender zwei Hauptkriterien berücksichtigen: Zum einen, wie vollständig und ausbaufähig die jeweiligen Ansätze sind und zum anderen, wie potent der jeweilige Plattformanbieter ist, seine Lösungen zu entwickeln, zu vermarkten und weiter zu pflegen.

So hat sich Java in den letzten fünf Jahren rasant verbreitet: von einer Sprache für eingefleischte Freaks der Objektorientierung (OO) zu einer selbstverständlichen Technologie. Dies ist weniger auf den Charme der Sprache als auf die damit verbundene technische Plattform zurückzuführen. Neben J2EE bietet nun Microsoft eine junge Plattform-Technik an. Der erste frühe Ansatz der Redmonder mit der Distributed Internet Architecture (DNA) war noch stark PC-geprägt und mit vielen Krücken behaftet.

Neben den offensichtlichen Problemen mit der Registry und den DLL-Konflikten war es das Komponentenmodell (COM), das durch die Unterstützung unterschiedlicher Sprachen zu komplex geworden war. Auch war eine verteilte Verarbeitung mit der proprietären DCOM-Lösung auf Basis des Microsoft RPC und der Registry nicht Internet-fähig.

.Net hat von Java gelernt

Seit .Net, mit dem Microsoft eine radikale Veränderung gegenüber DNA vorgenommen hat, gesteht die Gates-Company nun auch offen die Probleme der Vorgängertechnologie ein. In puncto Architektur und der Funktionalität sind sich .Net und J2EE sehr ähnlich, doch Microsoft bietet die modernere technische Lösung. Dies sieht man zum Beispiel am konsequenten Einsatz von Web-Technologie und XML. Auch die neue Sprache C# und die virtuelle Maschine (CLR) haben von Java gelernt. Aber es gibt auch Unterschiede von strategischer Bedeutung:

J2EE ist kein Produkt, sondern eine Spezifikation, für die viele Hersteller Produkte anbieten. Die Anwendungen sind dadurch unabhängig von der zugrunde liegenden Middleware. So erzielen die Unternehmen nicht nur eine Unabhängigkeit von einem einzelnen Lieferanten, sondern können auch ihre Technologie-Plattform aus Produkten unterschiedlicher Hersteller zusammenstellen - zumindest theoretisch.

.Net dagegen ist eine Produktsammlung eines Herstellers, die zusammen mit Windows ausgeliefert wird. Dadurch ist eine gute Integration der einzelnen Produkte gewährleistet. Zugleich können spezielle Eigenschaften des Betriebssystems genutzt werden.

J2EE ist vom Konzept her unabhängig von Betriebssystemen. Die damit verbundene Portabilität für die Anwender müssen die Hersteller mit zusätzlichen Aufwänden erkaufen, da das Java Runtime Environment, die Application Server und sonstige Middleware-Produkte maschinennah programmiert sind. Deshalb müssen Hersteller für jedes Betriebssystem eine passende Portierung vornehmen. Viele Betriebssysteme werden lieblos oder gar nicht bedient. Vielfach muss eine Zwischenschicht eingezogen werden, um Unterschiede zwischen Betriebssystemen auszugleichen.

Andererseits geht Microsoft als Betriebssystem-Hersteller davon aus, dass die Spannbreite von Windows-Versionen vom Pocket-PC bis zum großen Server-Cluster ausreicht. Andere Betriebssysteme seien deshalb nicht nötig.

Neben diesen Aspekten gibt es noch weitere Kriterien, die für eine Entscheidung zwischen diesen beiden Technologie-Plattformen wichtig sind. So etwa die Festellung wie vollständig, umfassend und ausbaufähig das jeweilige Konzept ist - die Analysten von Gartner nennen das "Completeness of Vision". Der Vorsprung von J2EE besteht in den vielen Application Programming Interfaces (APIs), die eine Technologie-Unabhängigkeit der Anwendungen schafft. Dies ermöglicht den weiteren Ausbau der Technologie mit geringen Nebeneffekten. Weiterhin ist das Komponenten-Modell von Java methodisch durchdachter. Auch die Konnektor-Architektur bietet die Grundlage für eine flexiblere Interoperabilität.

.Net: Bessere Performance

Bevor sich IT-Verantwortliche für die eine oder andere Lösung entscheiden, sollten sie auch die technische Implementierung der jeweiligen Infrastruktur unter die Lupe nehmen. Unter diesem Aspekt besitzt .Net mehr Vorteile, da von vornherein moderne Technologien wie XML und Web-Interaktion eingesetzt werden. Auch beim Bau der eigenen virtuellen Maschine konnte Microsoft Probleme, die aus dem Interpreter-Ansatz von Java stammen, vermeiden. Durch die Verzahnung mit Windows lassen sich für .Net viele Betriebssystem-Funktionen direkt nutzen wie der IIS, Active Directory, OLE-DB und Windows Load Balancing. Die enge Kopplung mit dem Betriebssystem ist Ursache für die bessere Performance von .Net-Anwendungen. Erste Benchmark-Zahlen - auch wenn es schwierig ist, deren Objektivität nachzuprüfen - zeigen erheblich bessere Leistungen im Vergleich zu J2EE-Applikationen. Allerdings gibt es keine Pauschalaussagen zur Leistungsfähigkeit von Java. So schwankt die Performance von Java

Virtual Machines auf gleicher Hardware um den Faktor drei. Ebenso groß ist die Schwankungsbreite bei Java-Application-Servern.

Die Erfahrung lehrt, dass komplexe Software-Produkte Jahre benötigen, um wirklich ausgereift zu sein. Das hat sich bei Datenbanken, Transaktions-Monitoren und auch bei Java bewahrheitet. Deshalb ist es kein Nachteil, wenn ein neues Produkt auf alten, erprobten Kernkomponenten aufbaut. Die J2EE-Produkte haben inzwischen einen akzeptablen Reifegrad erreicht. Für .Net fehlen allerdings die Erfahrungen aus anspruchsvollen Praxisanwendungen, um darüber eine Aussage zu machen.

Neben den Leistungskriterien sollten IT-Manager und Projektleiter die Effizienz der Plattformen betrachten, also wie produktiv die Anwendungsentwicklung unterstützt wird. Misst man die Produktivität nur anhand der "Lines of Code", dann besitzt .Net klare Vorteile gegenüber Java. Dies lässt sich aus vorliegenden Programmier-Benchmarks ableiten. Entscheidend ist jedoch, wieviele dieser Codezeilen wirklich von Hand eingegeben werden mussten. An dieser Stelle wirken sich sich sowohl ein automatisierter Entwicklungsprozess als auch die Intelligenz einer Software-Entwicklungsumgebung aus.

Bei Java existieren erhebliche Unterschiede zwischen den Entwicklungs-Tools, was die Hersteller beim Marketing hervorheben. Fazit ist, dass sich Microsofts "Visual Studio .Net" mit den leistungsfähigsten Entwicklungsumgebungen für Java vergleichen lässt.

Lizenz- und Wartungsgebühren sind inzwischen ein nicht zu unterschätzender Faktor bei der Entscheidung für oder gegen eine Technik. Mit J2EE-Lösungen der Hersteller wie IBM oder BEA bewegt man sich kostenmäßig in Mainframe-Kategorien. Andererseits kann man mit Open-Source-Produkten ein gutes Angebot zum Nulltarif erhalten - man muss nur etwas mehr Mut aufbringen. In dieser Spannbreite von kostenlos bis teuer liegt Microsoft .Net etwa in der Mitte.

Hinzu kommen auch noch die Aufwendungen für ausreichendes und qualifiziertes Personal, das eine solche komplexe Infrastruktur betreiben kann. Diese Mitarbeiter sind für beide Technologien rar und teuer. Bei großen operativen Anwendungen ist die technische Komplexität sowohl bei J2EE als auch bei .Net vergleichbar mit Cics oder IMS.

Neben der Prüfung, ob eine Technologie oder ein Konzept vollständig ist, sollten Anwender die Fähigkeit der Anbieter betrachten, die Technik auch tatsächlich zu entwickeln, auf den Markt zu bringen und weiter auszubauen. Hier sind Zweifel an der wirtschaftlichen Kraft von Microsoft wohl eher überflüssig. Bei der Java-Fraktion sind Fragezeichen eher angebracht. Was passiert mit Java, wenn es Java-Wächter Sun weiterhin so schlecht geht? Sind die Java-Entwickler der verschiedenen Hersteller in der Lage, der geschlossenen Phalanx von Microsoft-Entwicklern Paroli zu bieten?

Hierzu muss gesagt werden, dass die Hersteller der Java-Technologie nur gemeinsam in der Lage sind, der Entwicklungs- und Marktkraft von Microsoft zu trotzen. Ihr Zusammenhalten ist zugleich eine Überlebensstrategie. Aber sie hängen nicht unbedingt von der Existenz von Sun ab. Im Falle einer Insolvenz von Sun kann diese Rolle auch von einem anderen übernommen werden.

Andererseits führt eine solche Herstellergruppierung auch zur Zersplitterung der Entwicklerkapazität. Jedes Produkt für Java muss sechs- bis achtmal parallel entwickelt werden. So gibt es allein für Application Server rund 40 Hersteller. Aber durch Konkurrenz wird die Ideenvielfalt auch beflügelt. An dieser Stelle sollte die Innvovationskraft der Open-Source-Gemeinde nicht vergessen werden. Im Rahmen solcher Projekte wie "Apache" entstehen gute, leistungsfähige Produkte.

Wechseln ist teuer

Die Betrachtung nur des heutigen Status ist aber keine ausreichende Entscheidungsbasis. Schließlich investieren die Unternehmen viele Millionen Euro in die Infrastruktur und in ihre neuen Anwendungen. Sollte die einmal gewählte Technologie-Plattform ein Flop werden, ist ein Wechsel zu vertretbaren Kosten kaum möglich. Davon können Unternehmen mit OS2- oder Smalltalk-Anwendungen ein Lied singen. Die Auguren von Gartner gehen davon aus, dass Microsoft durch .Net die Java-Welt in Bedrängnis bringen, aber nicht verdrängen wird. Ebenso ist es unwahrscheinlich, dass Java noch so dominant werden wird, dass .Net keine Marktanteile erzielt. Allein die vielen Tausend Vorabkopien, die über das Internet heruntergeladen werden, dokumentieren ein reges Interesse an .Net. Das heißt, dass es zukünftig eine Koexistenz beider Technologie-Plattformen geben wird.

Da .Net für die Unternehmen, die bisher schon auf Microsoft-Technologie gesetzt hatten, einen großen Sprung vorwärts darstellt, haben diese sicher keinen Grund, zu Java zu wechseln. Wer bisher schon in Java investiert hatte, findet auch wenig Gründe, auf .Net zu wechseln und die bisherigen Investionen in den Sand zu setzen. So viele Vorteile bietet .Net schließlich auch nicht.

Einmal Java, immer Java

Bleiben noch die Unternehmen übrig, die sich noch nicht festgelegt beziehungsweise noch nicht viel in die ein oder andere Technik investiert haben. Hier werden eher strategische Ziele die Entscheidung beeinflussen. Kleinere Betriebe, die für ihre IT auf preisgünstige Intel-Prozessoren setzen und damit Windows im Haus haben, werden für ihre neuen Anwendungen - sofern sie überhaupt noch welche entwickeln - eher .Net verwenden. Die großen Unternehmen - insbesondere die Mainframe-Fraktion - setzen dagegen meist leistungsfähige Unix-Rechner ein und sie haben den Wunsch, eine Plattform zu kaufen, die auch noch auf dem Mainframe läuft. Diese Firmen werden also J2EE vorziehen.

Nicht nur Anwender haben eine Entscheidung hinsichtlich IT-Architektur zu fällen, auch Softwareanbieter müssen für die Entwicklung eine Plattformentscheidung treffen. Für viele war die Erfindung von Java ein wahrer Glückstreffer. Mussten sie früher ihre Anwendungen auf zig verschiedenen Betriebssystemen testen, bevor sie ausgeliefert werden konnten, so reicht heute eigentlich ein Test auf der Referenzimplementierung von Sun. Trotzdem kann es aber hilfreich sein, einen zusätzlichen Test auf einer Produktionsumgebung von IBM, BEA oder Oracle zu machen.

Doch auch .Net hat für die Softwarehersteller seinen Reiz. Dieser liegt in der erforderlichen Infrastruktur für den jeweiligen Kunden. Wenn ein Unternehmen eine Java-Anwendung kauft, so sollte - zumindest zur Zeit noch - auch die dazugehörige J2EE-Umgebung eingesetzt werden, da meist doch herstellerspezifische Erweiterungen genutzt wurden. Durch den Kauf mehrerer Softwarepakete kommt ein Unternehmen schnell zu mehreren Application Servern. Bei .Net genügt eine Infrastruktur für alle Anwendungen.

Hinsichtlich der Kenntnisse der Anwendungsentwickler sind die Anforderungen aus beiden Technologien vergleichbar. Neben den Sprachen und Tools müssen Objektorientierung, Schichtenarchitektur, Komponenten-Design und iterative Entwicklung beherrscht werden. Wer bereits mit der bisherigen Microsoft-Technologie Anwendungen entwickelt, könnte es mit .Net leichter haben. Doch das trügt, denn ein "klassischer PC-Entwickler", der Fat-Client-Lösungen mit Visual Basic gebaut hatte, bringt keine besondere Eignung für die modernen Technologien mit. Auch das neue VB.Net ist nicht mehr identisch mit dem alten Visual Basic.

Ähnlich sieht es mit der Migration alter Microsoft-Programme auf .Net aus. Zwar werden für einige Arbeiten Migrationsassistenten angeboten. Doch das ist nur sinnvoll, wenn die alten Anwendungen schon aus Komponenten bestehen und eine Drei-Schichten-Architektur besitzen. Doch das sind die wenigsten.

Da die berechtigte Tendenz zum Kauf von Software statt zur Eigenentwicklung geht, haben die Unternehmen wenig Chancen, eine homogene Technologie-Welt zu erhalten. So entsteht ein Technologie-Mix aus Mainframe-, Standardlösungs-, PC-, Java- und .Net-Anwendungen. Deshalb benötigt die IT vorrangig die Fähigkeit zur Integration und zum Betrieb heterogener Plattformen.

Zur Lösung dieser Integrationsaufgaben können Technologien wie XML und Web-Services verwendet werden, die von Java wie von .Net gleichermaßen unterstützt werden. Auch alte Mainframe-Anwendungen lassen sich mit etwas Aufwand so integrieren. Den härtesten Widerstand gegen jede Integration leisten die vielen PC-Programme aus der "Fat- Client"-Ära - also der bisherigen Microsoft-Technologie. (bs)

* Michael Bauer ist Geschäftsführer der Informatik Consulting Bauer GmbH in Moos. Kontakt: michael.bauer@plenum.de.