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.

17.09.1999 - 

Dynamischer Markt, unerprobte Technik, fehlendes Know-how

App-Server: Hoffnung und Herausforderung

MÜNCHEN (as) - Der noch junge Markt für Web-Applikations-Server ist verheißungsvoll und gnadenlos zugleich. Laut einer Analyse der Meta Group werden nur wenige der etwa 50 Hersteller den Kampf um die Kunden überleben. Auch entwächst die Technik erst langsam ihren Kinderschuhen und verlangt viel Gehirnschmalz von den Anwendern.

Zwei Jahre ist es her, daß Hersteller und Analysten mit dem Applikations-Server ein weiteres Mitglied der Middleware-Familie aus der Taufe hoben. Dieser erweckte von Anfang an weniger durch neuartige Technik als vielmehr aufgrund seines Konzeptes das Interesse der Anwender. Er bietet eine Runtime-Infrastruktur inklusive wichtiger Services (Programmier-Schnittstellen), mit denen IT-Abteilungen sowohl bestehende als auch neue, mehrschichtige Anwendungen integrieren, entwickeln, verteilen und zentral verwalten können (siehe Kasten "Eigenschaften"). Dabei wird eine klare Trennung der Präsentationsschicht (Benutzeroberfläche) von der Geschäftslogik vorgenommen sowie die komponentenbasierte Software-Entwicklung propagiert. Dazu kommen die Architekturstandards Component Object Model (COM), Component Object Request Broker Architecture (Corba) und Enterprise Javabeans (EJB) sowie entsprechende Programmierumgebungen zum Einsatz. Auch Server-Eigenschaften wie Zuverlässigkeit, Hochverfügbarkeit, Sicherheit und Skalierbarkeit werden gern und viel im Zusammenhang mit den Produkten gebraucht, müssen sich in der Praxis ihre Qualität noch beweisen.

Die Applikations-Server-Technik zieht ihre Existenzberechtigung aus der immer komplexeren und kostspieligeren Verwaltung und Pflege bestehender Anwendungen. Auf der einen Seite gilt es, zunehmend heterogenere Systemlandschaften in den Griff zu bekommen, und andererseits müssen zweischichtige Client-Server-Anwendungen gewartet werden, die sich mittlerweile als zu unflexibel, wenig skalierbar und teuer erwiesen haben. Zugleich wächst der Druck seitens des Marktes und der Geschäftsleitungen, im Zeichen der Globalisierung die Geschäftsprozesse etwa im Rahmen von E-Commerce-Projekten stärker mit dem Web zu koppeln.

Angesichts des vielversprechenden Konzepts und des wachsenden Leidensdrucks bei den Anwendern haben Marktanalysten deshalb zunächst einmal gute Nachricht für die Branche: Viele der von ihnen befragten Unternehmen wollen trotz der teilweise noch unausgereiften Technik der Applikations-Server schon bald ihre strategische Entscheidung treffen. Das britische Marktforschungsunternehmen Ovum etwa schätzt, daß Kunden dieses Jahr 250 Millionen Dollar, im Jahr 2004 aber schon 16,7 Milliarden Dollar in entsprechende Produkte und Services investieren (siehe Grafik "Umsätze").

Doch die Entwicklung und das Design mehrschichtiger, komponentenbasierter Systeme ist schwer, das Personal oft nicht vorhanden oder nicht geschult. Hinzu kommt, daß die junge Middleware-Technik wenig Zeit zum Reifen hatte und hohe Ansprüche an das Können der Anwender und Anbieter stellt.

In der Implementierungspraxis zeigt sich dann auch, daß der Einzug der Applikations-Server in die Unternehmens-DV nur langsam und schrittweise vonstatten geht. Hierbei ist in der Mehrzahl der aktuellen Projekte momentan noch eine technisch überschaubare Web-Erweiterung bestehender Systeme das Ziel (siehe Kasten "Die Rolle der App-Server"). Hinzu kommt, daß angesichts laufender Umstellungen zum Jahr 2000 die Anwender davor zurückschrecken, neue Technik schon jetzt im großen Stil einzuführen.

Kaufinteressenten sollten sich an diesem pragmatischen Vorbild orientieren. Vorab könnte aber auch einmal grundsätzlich durchgespielt werden, ob die gewünschte Funktionalität sich nicht auch mit Messaging-Middleware oder gar Server-basierter Datenzugriffs-Software abdecken läßt. Ist dies nicht der Fall, sollte man das Einsatzgebiet des Applikations-Servers definieren, um nicht etwa ein teures "Full-blown"-Produkt für eine einfache Client-Integration zu kaufen.

Ferner sind neben dem Service- und Leistungsangebot des Herstellers die technischen Eigenschaften dieser neuen Produkte genau zu hinterfragen. Probleme kann etwa das in der Praxis noch wenig erprobte Server-API bereiten, das unterschiedlichste Datenquellen zusammenführen soll. Selbst wenn es sich als einigermaßen performant erweist, können Fehler durch die unterstützten, noch nicht voll ausgereiften Integrationstechniken wie EJB oder DCOM auftreten. Zudem sind Funktionen wie Cluster-Failover, Polling und Load Balancing kompliziert und schwer zu implementieren.

Eine weitere Problemquelle sehen Experten in der Entwicklungsumgebung. Hier wächst der Lern- und Programmieraufwand je nach der "Offenheit" des Tools. Selbst bei nicht herstellerspezifischen Lösungen muß der Anwender sich darauf einstellen, bei der Arbeit systemspezifischen API-Calls und Syntax zu begegnen und Teile bestehenden Codes mehr oder weniger händisch recompilieren zu müssen. Mit wachsendem Bestand an speziell an die Server-API angepaßtem Anwendungs-Code sinkt zudem die Portierbarkeit. Auch ist es unwahrscheinlich, daß die Entwicklungsumgebung für alle Anwendungszwecke gleich gut geeignet ist. So können sich etwa die mitgelieferten HTML-Wizards als fehlerhaft oder leistungsschwach erweisen, oder der Server läßt sich nur durch Workarounds oder zusätzliche Plug-ins mit existierenden Anwendungen koppeln.

Angesichts der möglichen Probleme und Fehlerquellen sowie der Komplexität der Technik ist zu erwarten, daß Anwender zunehmend einen umfassenden Support und eine klare Produktstrategie für die künftig auch unternehmenskritischen Anwendungen einfordern werden. Dies setzt die Hersteller unter Druck, auf dem leergefegten Arbeitsmarkt eine entsprechend große Zahl an Experten oder qualifizierten Partnern zu rekrutieren.

Auch ergeben sich für die Anbieter Probleme bei der Vermarktung ihrer Produkte, da sich die Architekturen und der Funktionsumfang der Applikations-Server immer mehr gleichen. War die erste Server-Generation noch durch proprietäre Schnittstellen, Persistenzmodelle und State-Management-Modelle geprägt, so haben sich in den letzten Monaten die meisten Hersteller zu einer "offenen" Architektur bekannt. Diese ist bei der Mehrheit der Produkte durch die Unterstützung von Suns Server-Komponentenmodell EJB, weiterer Java-Standards sowie Corba-Implementierungen gekennzeichnet. Allerdings hält das Bekenntnis der Hersteller zu Standards sie nicht davon ab, bei der Implementierung dennoch proprietäre Erweiterungen unterzubringen.

Einen eigenen Weg hat Microsoft eingeschlagen, das für das eigene Komponentenmodell COM und den "Microsoft Transaction Server" wirbt. Laut der Meta Group könnte die Gates-Company sich bis zum Jahr 2002 eine führende Position auf dem Markt für Applikations-Server aufbauen. Zwar sind die diversen Techniken wie MTS, COM+, MSMQ, Active Directory Server, Site Server, Load Balancing Service und Cluster Service derzeit noch nicht eng miteinander gekoppelt, doch verspricht Windows 2000 in seiner "Data Center Edition" eben dies zu tun und damit gewissermaßen selbst in die Rolle eines "Applikations-Servers" zu wachsen. Die Analysten halten den Kauf des NT-Nachfolger daher nur noch dann für sinnvoll, wenn ein Anwender die angebotene Funktionalität auch wirklich benötigt.

Parallel zu Microsofts Aufstieg prognostizieren die Auguren einen massiven Shakeout im EJB/Corba-Lager bis zum Jahr 2002. Dabei könnten Anbieter wie Bea Systems mit ihrem "Weblogic"-Server und IBM mit "Websphere" dank ihrer Erfahrung mit unternehmenskritischer Middleware-Technik eine führende Rolle spielen. So besitzt Big Blue mit dem " Component Broker" und "Encina" sowie Bea mit "M3" und "Tuxedo" laut Meta schon heute ausgereifte und skalierbare Transaktions-Engines für ihre Applikations-Server.

Zu den beiden "Anführern" gesellen sich laut Meta Group aber noch eine Reihe von "Jokern", die aufgrund ihrer technischen Basis die Aussicht haben, in der nächsten Zeit Marktanteile für sich zu gewinnen. In diese Gruppe fallen Anbieter wie Iona, Oracle, Persistence, Progress, Sun-Netscape (und seit kurem Forté) sowie Sybase. Ihre Chance besteht darin, über eine größere installierte Kundenbasis zu verfügen, die man möglicherweise für den eigenen Applikations-Server gewinnen kann. Ferner werden sie versuchen, ihre Produkte auch auf dem Markt für Enterprise Application Integration (EAI), Portale und Business-to-Business-Lösungen für E-Commerce unterzubringen.

Für den suchenden Anwender bleibt der umkämpfte Markt für Applikations-Server also unübersichtlich, und es ist trotz aller ausgelobten "Favoriten" noch offen, welcher Anbieter am Ende überlebt. Zudem mehren sich schon heute die Stimmen, die erwarten, daß die Applikations-Server-Technik mittelfristig ihre Eigenständigkeit verliert und sich entsprechende Features und Funktionalitäten in Programmiersprachen und Infrastruktursoftware wie etwa Betriebssystemen oder Datenbanken wiederfinden.