Von: Achim Born
Unternehmen stehen heute vor einem Dilemma. Sie verfügen weder über die Finanzkraft noch die erforderliche Zeit, ihre bestehende Anwendungswelt gänzlich durch neue Web-Anwendungen abzulösen. Sie können es sich auch nicht erlauben, im Internet-Zeitalter abseits zu stehen. Ebensowenig wollen die IT-Verantwortlichen aber die erreichte Qualität und Sicherheit der eigenen DV gegen das sprichwörtliche Internet-Chaos eintauschen.
Als Ausweg aus dieser Zwickmühle haben Hersteller die "Middleware-Spezies" der Application-Server erdacht, die als ordnende Instanz die diversen Interessen unter einen Hut bringen soll. Für die Analysten von Ovum steht es auch außer Frage: "Application-Server werden Ecksteine der nächsten Generation von IT-Infrastrukturen". Entsprechend optimistisch fallen die Prognosen aus. Gleichwohl eröffnet sich dem Anwender weiterhin ein Marktsegment mit unüberschaubaren Strukturen, in dem beinahe täglich neue Anbieter mitmischen wollen, während andere sich durch Aufkauf oder ähnliches als eigenständiges Unternehmen verabschieden.
Der Mangel einer allgemein verbindlichen Definition sorgt ebenfalls nicht gerade für Transparenz. Forrester Research beschreibt beispielsweise einen Application-Server einfach als ein Softwareprodukt, das schlanke Clients mit einer integrierten Suite verteilter Betriebsmöglichkeiten verbindet. Folglich unterstützen sie Client-Sitzungen, beinhalten und managen die Verbindung zu Ressourcen im Hintergrund, zum Beispiel Datenbanken, Inhalte oder Transaktionen. Wird dieser Definitionsansatz noch um eine Entwicklungsumgebung ergänzt, trifft man in etwa den Leistungsumfang heutiger Produkte. Deshalb ist es schwierig, eine genaue Grenze zwischen Application-Server und Web-Entwick- lungsumgebung zu ziehen. Neben den bekannten Middleware-Veteranen und -Newcomern wollen zunehmend auch Anbieter integrierter Entwicklungssysteme ihr Stückchen vom "Marktkuchen" ergattern. Zu dem Zweck ergänzen sie ihre Produkte um entsprechende Runtime-Umgebungen.
Eine eher technische, wenn auch nicht uneigennützige Sichtweise pflegt die OMG (Object Management Group) mit ihrer Definition "einer gemeinsamen Plattform für Application-Server". Sie baut in erster Linie auf dem Fundament von Corba (Common Object Request Broker Architecture) sowie EJB (Enterprise Java Beans) auf. "Damit Anwendungsserver eine erfolgreiche Geschäftslösung für Unternehmen darstellen, müssen sie zwei Grundvoraussetzungen bieten: interoperable Dienste und Portabilität", erläutert Dr. Richard Soley den Ansatz. Und der OMG-Chef verhehlt nicht seine Freude, daß die meisten Anbieter in jüngster Zeit genau dieser Idee - Java für die Portabilität und Corba für die Interoperabilität - folgen.
Hierin spiegeln sich zwei Entwicklungen wider. Zum einen bekennen sich die Hersteller nach proprietären Versuchen nun mehr und mehr zu einer offenen Architektur. Zum anderen finden die Sun-Bemühungen, Java auf der Server-Seite zu etablieren, zunehmend Anhänger.
Mit der Spezifikation der Enterprise-Java-Beans nahm sich der Workstation-Pionier explizit der Themen Persistenz, Transaktionsmanagement, Sicherheit und Lastverteilung an. Im Rahmen der EJB-Architektur übernimmt ein sogenannter Container als Ablaufumgebung alle Arbeiten wie Speicherung, Transaktionsabwicklung sowie Sicherheit und reicht von außen ankommende Methodenaufrufe an das Java-Programm weiter. Via IIOP (Internet Inter-ORB-Protokoll) und EJB-Corba-Mapping lassen sich diese Container, beziehungsweise die übergeordnete Instanz der EJB-Server, von beliebigen Corba-Clients ansprechen.
Eine Reihe von Herstellern arbeiten derzeit an solchen spezialisierten EJB-Servern und/oder ergänzen ihre bisherigen Middleware- beziehungsweise Broker-Angebote um entsprechende Funktionalität. So verknüpfte Iona die Corba-basierte Produktfamilie für Middleware unter dem Dach "Orbix Home" mit EJB-Containern. Objectspace, ein US-Newcomer, veredelte den in Java implementierten Corba-konformen ORB (Object Request Broker) "Voyager" zu einem vollständigen Anwendungsserver, der neben Corba und DCOM (Distributed Component Object Model) nun Jini, RMI (Remote Method Invocation) sowie Java, mit EJB als präferiertes Komponentenentwicklungsmodell, unterstützt.
IBM offeriert seit kurzem den Anwendungsserver "Websphere" in drei Ausführungen und strebt damit eine mit Bea vergleichbare Strategie an: Als Standard-Edition ohne besondere Transaktionsmanagement-Funktionalität, als Advanced-Edition für Transaktionsverarbeitung mit EJB sowie als Enterprise-Edition, die zusätzlich Transaktionsmonitoring wie Cics und Datenbankanschluß an DB/2 und Oracle unterstützt. Die Liste der EJB-Serveranbieter läßt sich beinahe beliebig fortsetzen.
Java in Deutschland
Auch deutsche Unternehmen mischen mit. Siemens entwickelte beispielsweise auf Basis ihres TP-Monitors (TP = Transaction Processing) "Open UTM" einen NT-basierten EJB-Anwendungsserver. Die Kölner Prosyst Software GmbH wiederum zeigte auf der diesjährigen Systems unter anderem ihren "Enterprise Beans Server 3.0", der die "Java2"-Enterprise-Edition, also Enterprise-Java-Beans 1.1, Java-Server-Pages 1.1, Java-Message-Service 1.0 und Java-Mail 1.1, vollständig unterstützt. Der als "100 percent pure Java" zertifizierte Server kann von Linux bis zu OS/390 eingesetzt werden und bietet RMI-Kommunikation über IIOP zur Optimierung der Interoperabilität sowie den Einsatz des IIOP-Protokolls über Secure Socket Layer (SSL) zur Kommunikationssicherheit im Corba-Umfeld. Weitere neue Merkmale des Produkt-Releases sind unter anderem die Unterstützung von XA-Ressourcen bei verteilten Transaktionen sowie die Möglichkeit, über C/C++-Stubs und Skeletons die entsprechenden Clients zu integrieren.
An dem Produkt der Kölner zeigt sich denn auch beispielhaft, wie auf Java-Grundlage eine neue Message-orientierte Middleware (MOM) entsteht. Auf Basis vorhandener Beans lassen sich hier nun neue Anwendungen kombinieren, ohne daß die Kenntnis über die interne Verankerung notwendig ist. Der Austausch von Nachrichten zwischen verschiedenen Anwendungen auf unterschiedlichen Plattformen, die systemtechnisch nicht aufeinander abgestimmt werden müssen, funktioniert ebenfalls.
"Die Technik der Application-Server liefert ein Set wesentlicher Services zur Entwicklung und zum Betrieb verteilter Anwendungen", bringt Ovum-Analyst Gary Barnett nochmals den Ansatz der neuen Middleware auf den Punkt. Die Anwender führen laut Barnett Application-Server in drei unterschiedlichen Phasen ein. Zunächst versehen sie existierende Anwendungen ohne große Mühe mit Web-freundlichen Benutzer-Schnittstellen. Ovum nennt das "webification". Mittelfristig wird dann ergänzende Geschäftslogik, die auf Internet-Techniken beruht, mit Hilfe der Anwendungsserver eingebunden. Zu guter Letzt steht dann die Konstruktion von "Integrations-Hubs" an. Beinahe beliebig lassen sich hier alte und neue Anwendungen beziehungsweise deren Komponenten miteinander verknüpfen.
In diesem Zusammenhang erwartet der Analyst auch, daß typische Unternehmens-Middleware und EAI-Software (EAI = Enterprise Application Integration) mit Anwendungsservern verschmelzen. Es ist aber noch nicht auszumachen, ob die Server als eigenständige Kategorie bestehen bleiben.
Denn bekanntlich bündeln Hersteller wie Apple, IBM oder Microsoft zunehmend typische Middleware-Funktionalitäten in ihre Betriebssystemumgebungen. Vergleichbare Tendenzen kann man bei Datenbankanbietern wie Oracle beobachten. Zusätzlich sorgen die angesprochenen Aufkäufe nach Analystenmeinung für einen andauernden Shake-out bis ins Jahr 2002 hinein. (sf)