Das Rennen um die Dienste
Portabilität beachten bei Drittanbietern
Doch eine Anwendungsarchitektur erfordert mehr als einen Applikationsserver. Um den Entwicklungs- und Verwaltungsaufwand für Anwendungen gering zu halten, entstehen verschiedene Techniken wie Integrationsserver, Workflow, Business Process Management und andere. Die Java-Spezifikation adressiert außer dem schon erwähnten Messaging und der Integration keine weiteren Elemente. Es gibt von Drittanbietern verschiedene zusätzliche Komponenten für die XML-basierte Integration von Legacy-Anwendungen, B-to-B-Collaboration oder das Management von Geschäftsprozessen. Doch diese Vielfalt geht auf Kosten der Portabilität. Der Anwender ist daher gut beraten, sich auf das Angebot eines Herstellers zu konzentrieren. Inzwischen haben auch große Hersteller wie IBM oder BEA vollständige Webservices-Lösungen oder bieten über Partnerschaften kompatible Komponenten.
.Net bietet ebenfalls eine breite Lösung aus einer Hand, wobei naturgemäß der Integrationsaufwand geringer ist. Dem aktuellen Angebot fehlt es jedoch an Tiefe, beispielsweise bezüglich Integrationsmöglichkeiten, Workflow, Portale oder auch Netzwerkmanagement. Theoretisch können .Net-Anwendungen auf jeder anderen Plattform laufen - vorausgesetzt, sie enthält die grundsätzlichen .Net-Dienste und -Bibliotheken. Zur Stunde gibt es jedoch von Seiten von Microsoft noch keine Pläne, Laufzeitfunktionalität auf anderen Plattformen als Windows anzubieten. Die Strategie der Gates-Company, die eigene Produktlinie immer mehr auszuweiten, hält auch die Konkurrenz in Schach. Liegen keine zwingenden Argumente vor, die für eine der beiden Plattformen sprechen, so sollte die Wahl auch nach der bereits existierenden "IT-Welt" ausgerichtet werden.
Die Giga Group hält J2EE für ausgereifter als .Net. Als Beweis führen die Analysten bereits erprobte Plattformen wie "Websphere" von IBM oder BEAs "Weblogic" an. Obwohl die Microsoft-Software einige bewährte Elemente aus früheren Produkten enthält, sind viele neue hinzugekommen wie die .Net-Sprachenarchitektur oder die "Common Language Runtime", die ihre Stabilität erst beweisen müssen.
Des Weiteren sollte die Komplexität der zu entwickelnden Anwendungen in die Überlegungen einbezogen werden. Die MS-Werkzeuge bieten vorgefertigte Designmodelle und unterstützen die Entwicklung auf deren Basis. Doch bei komplexen Anwendungen rät die Giga Group eher zu J2EE. Begründung: Will man sich über die Java-Architektur informieren, so stehen einem gut strukturierte Plattformspezifikationen mit Zusammenfassungen zur Verfügung. Im Gegensatz dazu sind die einzelnen Teile der Microsoft-Architektur jeweils separat definiert und beschrieben, ohne einen Überblick über die Gesamtarchitektur.
Aufgrund der Tatsache, dass die GUI-Bibliotheken von Microsoft ausgereifter sind als die für Java, mehren sich die Stimmen der Unternehmen, die .Net eher für die Entwicklung von Frontend-Anwendungen einsetzen wollen, während sie J2EE im Backend sehen. Die Kommunikation wird durch die XML und SOAP möglich - Unterstützung dafür gibt es in beiden Modellen. Die Meta Group warnt jedoch vor Performance-Einbußen und Schwierigkeiten in der Anwendungsverwaltung. Dennoch wird eine reine J2EE- beziehungsweise .Net-Landschaft in einem Unternehmen eher die Ausnahme sein. Unternehmen wie Iona nehmen bereits ihre Chance wahr und bieten Tools an, die .Net-, Legacy- und J2EE-Anwendungen dort verbinden, wo nicht die Webservices-Standards diese Aufgabe übernehmen.