Der Druck, Anwendungen in immer kürzerer Zeit bereitzustellen, dabei jedoch gleichzeitig die rasch expandierenden technischen Möglichkeiten zu nutzen, nimmt stetig zu. Der einzige Weg zum Ziel führt über deutlich spürbare Produktivitätssteigerungen. Diese lassen sich nur bedingt durch Rationalisierungen in der Software- Entwicklung erzielen. Größere Potentiale können hingegen erschlossen werden, indem konsequent auf eine komponentenbasierte Anwendungsentwicklung gesetzt wird und erweiterbare Frameworks die Basis bilden.

Vor etwa zwei Jahren hielt eine neue Produktkategorie Einzug: die Applikations-Server. Derzeit gibt es mehr als 30 Anbieter. Sämtliche Hersteller außer Microsoft setzen dabei auf die Enterprise Javabeans (EJB) von Sun Microsystems. Produkte, die dieses Komponentenmodell tatsächlich unterstützen, befinden sich jedoch meist noch im Betatest. Sie alle arbeiten mit einem wiederverwendbaren Framework (siehe Kasten "Applikations-Server").

Das prognostizierte Marktpotential für Applikations-Server ist beträchtlich. Dadurch entsteht für Softwarehersteller ein enormer Anreiz, an dem zu verteilenden "Kuchen" zu partizipieren. Die Versuchung ist groß, das modische Etikett "Application Server" zu nutzen, auch wenn das Produkt den Mindestanforderungen nicht entspricht. Tatsächlich sind die meisten Produkte noch nicht ausgereift.

Für die Kommunikation im Applikations-Server kommen meist die Object Broker von Iona und Inprise zum Einsatz. Die Remote Method Invocation (RMI) ist als Object Bus wenig interessant, da nur Objekte miteinander kommunizieren können, deren Klassen mit Java als Programmiersprache entwickelt wurden. Zumindest für die Softwarehersteller uninteressant ist die Microsoft-Technik COM/DCOM, da der Windows-Riese mit seinem "Transaction Server" (MTS) das Feld für Applikations-Server bereits besetzt hält. Es wäre also unattraktiv, ein Konkurrenzprodukt zu entwickeln, zumal MTS zu einem Bestandteil von Windows NT werden soll. Den Softwerkern bleibt lediglich der Markt für Add-ons wie etwa einem Generator für Geschäftsregeln.

Der Schlüssel zum Erfolg der Applikations-Server liegt bei den Komponententechniken. Die Hauptrolle spielen hier neben Microsofts bereits etablierten Active-X-Komponenten die Enterprise Javabeans. Letztere haben den Vorteil, daß sie von einer ganzen Reihe von Herstellern unterstützt werden. Außerdem sollen sie durch die Object Management Group standardisiert und mit deren Corba-Technik verschmolzen werden.

Der Markt wird langfristig nur vier oder fünf Produkte übriglassen, die zusammen mehr als 80 Prozent des Marktvolumens auf sich vereinigen. Beim Ringen um Marktanteile zwischen Microsoft und dem Rest der Welt hat die Fraktion der Enterprise Javabeans das Argument der Plattformunabhängigkeit auf ihrer Seite. Microsoft wird durch äußerst niedrige Lizenzpreise (MTS ist Teil seiner "Back Office Suite") dazu beitragen, daß sich das Lizenzpreisniveau auf einem insgesamt niedrigen Level halten wird.

Eine weitere Chance von Microsoft besteht darin, daß Corba und EJB, die zwei mit COM und Active X konkurrierenden Techniken, noch nicht vollständig festgelegt sind. Auf technisch-konzeptioneller Ebene weisen die drei Komponentenmodelle COM, Corba und EJB so viele Gemeinsamkeiten auf, daß der Anschein entstehen könnte, als würden nur unterschiedliche Terminologien verwendet. Die Ernüchterung folgt jedoch auf der Ebene der unterschiedlichen Anwendungsprogrammier-Schnittstellen (APIs).

Anwenderunternehmen erwarten, daß selbstentwickelte oder von Softwareherstellern lizenzierte Komponenten portabel sind, sofern sie auf demselben Komponentenmodell basieren. Innerhalb von Microsoft-Umgebungen werden diese Erwartungen erfüllt, da der Hersteller die Spezifikationen vorgibt und außerdem die Container selbst implementiert (zum Beispiel MTS). Dem Entwickler bleibt kein Freiraum zur Einführung von Inkompatibilitäten.

EJB-Spezifikationen sind dringend nötig

Entwickler von EJB-Komponenten sehen sich mit einer völlig anderen Situation konfrontiert. Sun Microsystems entwickelt und pflegt die Spezifikation, implementiert jedoch selbst keine Container. Den Softwareherstellern wird damit Tür und Tor geöffnet, APIs um proprietäre Elemente zu erweitern und auf diese Weise Kunden zu binden. Es bestünde dann die Gefahr, daß Anhänger der EJB-Technik ihre Hauptvorteile gegenüber Microsoft preisgeben: Plattformunabhängigkeit und Portabilität.

Sun kann dieser wenig attraktiven Perspektive nur mit einer eigenen Referenzimplementierung entgegensteuern, an der in der Tat bereits gearbeitet wird. Damit sollen gleichzeitig die möglichen Interpretationen der EJB-Spezifikation durch die verschiedenen Hersteller vereinheitlicht werden.

Ähnlich ist die Situation in bezug auf Corba. Die beiden Modelle sind derzeit nicht deckungsgleich. An einer Harmonisierung wird gegenwärtig gearbeitet. Welches Ergebnis am Ende stehen wird, ist noch nicht genau abzusehen. Interoperabilität ist jedenfalls angestrebt.

Grundsätzlich sind Softwarehersteller an einer uneingeschränkten Portablität wenig interessiert. Im Unterschied zur Vergangenheit haben sie jedoch mit proprietären Erweiterungen keinen unbegrenzten Spielraum mehr. Treiben sie das Spiel zu weit, verhindern sie das Aufblühen eines Komponentenmarkts durch Partikularisierung und spielen damit Microsoft in die Hände.

Ein wichtiges Entscheidungskriterium für Anwender wird aber auch die Angebotsbreite und -tiefe im Komponentenmarkt sein. Daß die Hersteller so vernünftig sein werden, sich nicht kollektiv selbst ein Bein zu stellen, darf gehofft werden. Zum gegenwärtigen Zeitpunkt ist die Hoffnung jedoch noch nicht durch Fakten unterlegt.

Die "Alles-aus-einer-Hand"-Wünsche der Anwenderunternehmen werden dazu führen, daß etwa Anbieter von Corba-Middleware ihre Produkte zu vollständigen Applikations-Server-Frameworks ausbauen werden.

Applikations-Server und ihre Frameworks werden als Produktivitätsmittel unverzichtbar sein. Da die Unternehmensgrenzen in der Zukunft noch weniger als heute die Grenzen der betrieblichen Informationsverarbeitung definieren und die Unternehmen noch wesentlich intensiver zusammenwirken werden, ist vor allem die Interoperabilität eine wichtige Anforderung.

Applikations-Server

Applikations-Server stellen ein Ausführungsumfeld für Geschäftslogik zur Verfügung und verbergen die Komplexität der verteilten Umgebung. Ein solcher Server entspricht einem Framework, das sämtliche systemorientierten Dienste bereitstellt, die zur Ausführung von Geschäftslogik erforderlich sind. Die Geschäftslogik kann ganz oder teilweise durch Komponenten als "Fertig-Bausteine" repräsentiert werden.

Die Programm-Infrastruktur des Applikations-Servers wird durch ein Framework zur Verfügung gestellt, dessen Design im Prinzip mit jeder entwickelten Anwendung wiederverwendet wird. In dieser Weise sind die Frameworks der Applikations-Server ein sehr geeignetes Mittel zur Steigerung der Entwicklungsproduktivität.

Da Bedieneroberfläche, Geschäftslogik und Datenhaltung auf unterschiedlichen Computersystemen implementiert sein können, ist ein gemeinsames Verständigungsverfahren erforderlich. Dieses kann durch eine Plattform für verteilte Objekte wie COM/DCOM, Corba und Java geschehen. Der Applikations-Server implementiert Container als Ausführungsumfeld von Komponenten. Die zugrundeliegenden Komponentenmodelle sind im Falle von Microsoft COM/Active X, ansonsten Enterprise Javabeans.

Weitere Infrastrukturservices der Frameworks sind Standards wie Verzeichnis- und Transaktionsdienste, asynchrone Nachrichtenübermittlung über Warteschlangen sowie aufgabenspezifische Leistungen, die Skalierbarkeit und Verfügbarkeit in verteilten Umgebungen erhöhen. Zu nennen sind in diesem Zusammenhang insbesondere dynamische Lastverteilung, Daten- Caching, Connection Pooling (Zuordnung von Datenbank-Connections aus einem Pool) und der automatische Wiederanlauf. Anwendungsdesign und Entwicklung können auf der reichhaltigen Basis bereits vorhandener Dienste aufsetzen und sich auf die rein applikationsspezifischen Aufgaben konzentrieren.

Der Begriff Applikations-Server läßt sich durchaus auf eine ganze Reihe gängiger Softwaretechniken wie Transaktionsmonitore anwenden. Web-Applikations-Server sind eine Untergruppe, die ursprünglich für dokumentenorientierte Web-Anwendungen geschaffen wurde.

Vorteile

Wiederverwendbarkeit: Unterschiedliche Front-ends (zum Beispiel statische und dynamische HTML-Front-ends, Java-Front-ends (Applets, Java-Anwendungen), C++-Anwendungen,) können gemeinsam dieselbe Geschäftslogik nutzen.

Infrastruktur: Allgemeine, häufig benötigte Funktionen werden bereits vom Framework zur Verfügung gestellt und müssen nicht selbst entwickelt werden.

Bessere Administrierbarkeit: Die Zentralisierung der Geschäftslogik erleichtert die Administration im Vergleich zu Fat Clients (ein Großteil der Geschäftslogik wird auf der Anwender- Arbeitsstation ausgeführt).

Mehr Fehlertoleranz: Die Verfügbarkeit des Applikations-Servers wird deutlich gesteigert,

Höhere Skalierbarkeit: Frameworks enthalten Funktionalität zur Leistungssteigerung. Ein Wechsel der Systemplattform kann hinausgeschoben werden.

Dieter Jenz ist Geschäftsführer der Unternehmensberatung Jenz & Partner GmbH, Erlensee.