Application Server- gestern, heute, morgen?

Transkript

1 Erschienen: Java Spektrum September / Oktober 2002 Autor: Ulrike Hammerschall Application Server- gestern, heute, morgen? Application Server sind heute in aller Munde. Wer in der IT Branche etwas auf sich hält, hat diverse Bücher und Artikel über dieses Thema gelesen, kann auf Anhieb die wichtigsten Produkte und Hersteller aufzählen und hat vielleicht auch schon mit dem einen oder anderen Produkt gearbeitet. Auf die Frage: was ist eigentlich ein Application Server, erhält man jedoch selten eine eindeutige Antwort. In der Literatur gibt es diverse Definitionen, die sich teilweise sogar widersprechen. Im Allgemeinen wird die Unterstützung komplexer transaktionaler Systeme gefordert. Manche Definitionen fordern zusätzlich die Komponentenfähigkeit eines Application Servers, andere betonen wiederum seine Webfähigkeit. Gleichzeitig läßt sich beobachten, dass im Alltag der Begriff Application Server durchaus nicht einheitlich verwendet wird. Transaktionsmonitore werden als Application Server bezeichnet, MOM (Message Oriented Middleware) Server ebenso wie Object Request Broker. Am häufigsten fällt jedoch der Begriff immer noch im Zusammenhang mit Enterprise Java Beans und dem Internet. Aber was ist denn nun tatsächlich ein Application Server? Dieser Artikel versucht darauf eine Antwort zu geben. Er beschreibt im Überblick die Entwicklung des Application Servers von seinen Anfängen bis heute und zeigt auf, wie es zu dieser Vielfalt an Definitionen kam. Anschließend werden die wichtigsten Architekturmodelle, die es zur Zeit für Application Server am Markt gibt, beschrieben und ihre aktuelle Position bewertet. 1 Transaktionsmonitore, die Urahnen Auf der Suche nach den Wurzeln des Application Servers muss man weit zurückgehen in die frühen Anfänge der Softwareentwicklung. In den 60er Jahren kamen die ersten Vielbenutzersysteme in Betrieb. Hunderte bis Tausende von Anwendern arbeiteten an Mainframe Terminals. Jeder Dialogschritt musste in einem transaktionsgesichtertem Raum ablaufen. Systeme dieser Art bezeichnete man als Transaktionssysteme oder auch OLTP (OnLine Transaction Processing) Systeme. Sie zeichneten sich durch spezielle Eigenschaften aus: Viele Benutzern, die kurze Antwortszeiten forderten. file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (1 von 11) [ :32:39]

2 Daraus resultierend viele kurze Transaktionen, die konkurrierend bearbeitet werden mußten Hohe Anforderungen an die Skalierbarkeit und die Verfügbarkeit der Systeme ( 7 * 24) Die damals am Mainframe verfügbaren Betriebssysteme waren Anforderungen dieser Art nicht gewachsen. Die ersten TP Monitore (Transaction Processing Monitore) wurden eingeführt. Sie erweiterten die Betriebssysteme um die geforderten Eigenschaften und lieferten die erforderlichen Ablaufumgebungen für Transaktionssysteme. Ursprünglich stand die Abkürzung TP für Tele-Processing (Dialogbetrieb). Dieser Begriff erschien jedoch schon bald als unmodern. So suchte man einen neuen Namen, der wie es heute scheint eher aus der Not geboren wurde: Transaction Processing Monitor, zu deutsch Transaktionsmonitor. Als Grundlage der Transaktionsverwaltung diente das Transaktionsmodell der X/Open Group zur Verwaltung verteilter Transaktionen. Dieses Modell ist bis heute Vorbild für viele Transaktionsdienste auf dem Markt. Es definiert im Detail die Rollen und die Interaktionen der beteiligten Akteure. Entscheidender Bestandteil des Modells ist das 2 Phase Commit Protokoll (2PC). Es garantiert die Sicherstellung der ACID Eigenschaften einer Transaktion, auch über den Zugriff auf mehrere Ressourcen hinweg. Die Aufgaben der Transaktionsmonitore gingen trotz des Namens weit über das reine Transaktionsmanagement hinaus. So boten sie zusätzlich ein effizientes Ressourcenmanagement zur Sicherstellung der Skalierbarkeit und stellten Failover- Mechanismen zur Gewährleistung der Hochverfügbarkeit zur Verfügung. Zu den ersten und bekanntesten Transaktionsmonitoren, die sich bis in die heutige Zeit gehalten haben, gehören CICS (Customer Information Control System) und IMS/DC (Information Management System). Von IBM für seine Großrechner entwickelt, zählen sie bis heute zu den am meisten verbreiteten Transaktionsmonitoren am Mainframe. Sie gelten als ausgereifte und zuverlässige Technologie und werden bis heute für geschäftskritische Anwendungen eingesetzt. 2 Von Monolithen zu verteilten Systemen Anwendungen am Mainframe wuchsen durch die Jahrzehnte dynamisch mit den Unternehmen mit. Es waren schwerfällige, monolithische Systeme, die in Cobol, PL/1 oder anderen alten Sprachen geschrieben waren. Präsentationslogik, Anwendungslogik file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (2 von 11) [ :32:39]

3 und Datenhaltung waren vermischt und machten die Anwendungen unübersichtlich und schwer wartbar. Aus diesem Grund, und nicht zuletzt auch wegen der immensen Kosten, die Mainframes verursachten, wuchs in den Unternehmen der Wunsch nach Alternativen. In den achtziger Jahren entstanden eine Reihe neuer Technologien, die eine Ablösung des Mainframes technisch zum ersten Mal möglich machten. Die Entwicklung kleiner, jedoch leistungsfähiger Minicomputer, die Einführung mächtiger, mainframeunabhängiger Betriebssysteme wie Unix, und Verbesserungen in der Netzwerktechnik lieferten die notwendige Infrastruktur für Dialoganwendungen jenseits vom Mainframe. Es entstanden die ersten verteilten Systeme. Anwendungen wurden aufgeteilt in sogenannte Fat Clients mit Präsentation und Anwendungslogik, und Server zur Datenhaltung. Client und Server lagen auf physisch getrennten Schichten, sogenannten Tiers. Architekturen dieser Art wurden 2 Tier Architekturen oder auch Fat Client Architekturen genannt. Unterstützt wurde der Trend der 2 Tier Architekturen durch sogenannte 4GLs (Fourth Generation Languages). Dieser Sprachtyp bot spezielle Konstrukte zum vereinfachten Zugriff auf Datenbanken an, häufig in Kombination mit einer graphischen Entwicklungsumgebung. 2 Tier Architekturen und 4GLs sind, wie zum Beispiel Oracle Forms, bis heute im Einsatz, wenn auch längst nicht mehr so populär. 3 2 Tier versus 3 Tier Nach der ersten Euphorie um 4GLs und 2 Tier Architekturen, wurden jedoch schon bald die Nachteile offensichtlich. Das Softwareverteilungsproblem: Die gesamte Anwendungslogik musste auf allen Clients installiert werden. Das galt für die erste Installation ebenso wie für alle weiteren Updates. 2 Tier Architekturen waren und sind auch heute nur schwer skalierbar. Durch die Verteilung war der Einsatz von Transaktionsmonitoren nicht möglich. Es gab demzufolge keine Unterstützung verteilter Transaktionen Die Systemadministration war aufwändig und schwierig. Es erwies sich als vorteilhafter die Anwendungslogik konzentriert an einer Stelle zur Verfügung zu stellen. Dies führte konsequenterweise zur 3 Tier Architektur, bis heute Standardarchitektur für verteilte Systeme (siehe Abbildung 1). file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (3 von 11) [ :32:39]

4 3 Tier Architekturen beherbergen die Anwendungslogik auf der mittleren Schicht. Präsentation und Datenhaltung sind durch physische Systemgrenzen strikt vom Anwendungskern getrennt. Auf der zusätzlichen mittleren Schicht kamen nun die ersten Transaktionsmonitore für verteilte Systeme, wie zum Beispiel Tuxedo, zum Einsatz. Diese liefen typischerweise auf Unix, waren in C geschrieben und unterstützten Anwendungen, die ebenfalls in prozeduralen Sprachen geschrieben waren. Abbildung 1: 2 und 3 Tier Architektur Zu dieser Zeit wurde der Begriff Middleware geprägt. Er umfasste alle Diensteanbieter für verteilte Systeme, die speziell auf der zweiten (middle) Tier lagen. Neben den genannten Transaktionsmonitoren zählten dazu beispielsweise MOM Server, verschiedene Kommunikationsprotokolle und später auch Object Request Broker. Der nächste logische Schritt war die Zusammenfassung der Dienste zu integrierten Plattformen. 4 CORBA und die ersten OTMs In den 80er Jahren entwickelte sich ein neuer Trend in der Anwendungsentwicklung. Das objektorientierte Paradigma trat seinen Siegeszug an. Prozedurale Sprachen wie C und Pascal wurden abgelöst durch ihre objektorientierten Varianten C++ und Delphi. Eine Reihe neuer objektorientierter Sprachen kam auf den Markt. Zusätzlich wurde mit der immer stärkeren Vernetzung in Unternehmen die Notwendigkeit der Interoperabilität von Anwendungen erkannt. Die Object Management Group (OMG), ein unabhängiges Gremium mit dem Ziel offene Standards für objektorientierte, verteilte Systeme zu spezifizieren, wurde 1989 ins Leben gerufen. Einer der ersten verabschiedeten Standards war die Object Management file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (4 von 11) [ :32:39]

5 Architecture (OMA), eine relativ abstrakte Referenzarchitektur mit dem Ziel der Interoperabilität von objektorientierten Anwendungen, unabhängig von Standort, Sprache, Plattform und Hersteller. Eine konkrete Ausprägung der Referenzarchitektur bildete ein weiterer Standard der 1991 von der OMG verabschiedet wurde: die Common Object Request Broker Architecture, kurz CORBA (siehe Abbildung 2). Zentrale Komponente der Architektur ist der Object Request Broker (ORB) als Vermittler zwischen verteilten Objekten. Er ist zuständig für das Auffinden von Serviceobjekten im Netz und die transparente Übertragung von Methodenaufrufe zwischen Client und Service. Ebenfalls im Standard enthalten sind eine Reihe von Systemdiensten, die sogenannten CORBAServices. Zu den wichtigsten CORBAServices zählen der Transaction Service, ein Transaktionsmanager nach dem Vorbild des X/Open Modells und ein Naming Service zum Auffinden von Serviceobjekten im Netz. Insgesamt wurden bisher von der OMG mehr als 20 CORBAServices spezifiziert und standardisiert. Abbildung 2: Corba Architektur Schwerpunkt der ersten CORBA Implementierungen war die Bereitstellung eines ORBs als reiner Kommunikationsservice. Erst mit der Zeit wurden die Produkte ausgereifter und boten neben dem ORB auch einen Transaktionsservice und noch weitere Services des Standards an. Damit wurden sie zu vollwertige Ablaufumgebungen für objektorientierte Transaktionssysteme. Produkte dieser Art nannte man in Anlehnung an die Transaktionsmonitore am Mainframe, Object Transaction Monitore (OTM). Generell erstellt die OMG lediglich Spezifikationen. Es ist Aufgabe der Mitglieder Referenzimplementierungen zu liefern. Bis 1998 machte die Entwicklung des CORBA file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (5 von 11) [ :32:39]

6 Standards und der CORBA Produkte rasante Fortschritte. Viele Unternehmen wie IBM, Bea oder IONA setzten auf CORBA als Middleware Technologie der Zukunft. 5 Die J2EE Offensive von Sun Anfang der 90er Jahre trat das Internet seinen Siegeszug an und mit ihm Java als die Sprache für das World Wide Web. Statische HTML Seiten konnten durch Applets und JavaScript mit Leben gefüllt werden. Webserver wurden um das Common Gateway Interface (CGI) erweitert. Damit konnten sie einfache Datenbankzugriffe durchführen und die Ergebnisse formatiert im Browser anzeigen. Active Server Pages, Servlets und Java Server Pages waren weitere Schritte auf dem Weg zur Nutzbarmachung des Internets für Unternehmen. Webserver waren die Technologie der Wahl um Internetmärkte zu eröffnen. Bald waren jedoch ihre Grenzen erreicht. Internetapplikationen stellen ähnliche Ansprüche wie klassische Transaktionssysteme am Mainframe: Hunderte bis Tausende von Benutzern wollen gleichzeitig zugreifen, erwarten zuverlässige Informationen und kurze Antwortzeiten. Ähnlich der Entwicklung von 2 Tier zu 3 Tier Architekturen, wurde auch hier die Notwendigkeit einer weiteren Tier offensichtlich startete Sun mit der Java 2 Platform Enterprise Edition (J2EE) eine Offensive in Richtung serverseitige Architekturen für Internet Applikationen. J2EE ist in erster Linie ein Herstellerstandard. Er definiert ähnlich CORBA die notwendigen Dienste, die verteilten Systemen zur Verfügung gestellt werden müssen. Der eigentliche Mehrwert der J2EE Spezifikation gegenüber CORBA liegt in ihrem Komponentenmodell Enterprise Java Beans (EJB). Die Anwendungslogik wird in Komponenten, den Enterprise Beans verpackt. Das Verhalten der Beans wird mit XML deklarativ im Deployment Descriptoren definiert. Ein Container stellt den Komponenten implizit die Dienste der Laufzeitumgebung zur Verfügung. 6 Der Application Server An dieser Stelle schließt sich der Kreis. Transaktionsmonitore, Object Transaction Monitore und Application Server haben alle das gleiche Ziel: Die Unterstützung großer, unternehmenskritischer, skalierbarer Transaktionssysteme. Der entscheidende Schritt vom Transaktionsmonitor zum Application Server war die Verschmelzung von Ablaufumgebung und Anwendungslogik durch Einführung des Containers (siehe Abbildung 3). Application Server sind nicht mehr nur reine Ablaufumgebungen, sie bieten file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (6 von 11) [ :32:39]

7 im Unterschied zu TPMs einen fertigen Rahmen für Anwendungen. Die Geschäftslogik wird in den Anwendungsserver eingebettet. Dies kann in Form von Komponenten geschehen, ist aber nicht zwingend notwendig. Abbildung 3: J2EE Application Server mit EJB Container Heute verwischen sich mehr und mehr die Grenzen zwischen den verschiedenen Technologien. CORBA und J2EE wachsen mit jeder neuen Version ihrer Standards stärker zusammen. Das CORBA Protokoll IIOP dient seit EJB 2.0 als Grundlage für die Kommunikation zwischen Beans. Damit wird die Interoperabilität von CORBA und J2EE möglich. Gleichzeitig enthalten viele J2EE Application Server im Kern einen klassischen Transaktionsmonitor. Diese Entwicklung ist vor allem bei Herstellern zu beobachten, die auf eigene Produkte zurückgreifen konnten. Diese Vermischung der Technologien führte zu der heute bekannten babylonischen Verwirrung bei Definitionen und Namen. 7.Net und die Microsoft Strategie Zeitgleich mit der OMG verfolgte Microsoft seine eigene Vision zur Umsetzung der Middletier. Wichtigster Baustein waren der Microsoft Transaction Service (MTS), ein Transaktionsmonitor ausschließlich für Windows Betriebssysteme mit dem Komponentenmodell COM (Common Object Model). COM in seiner ursprünglichen Form war Nachfolger von OLE (Object Linking and Embedding), einem Verfahren zur Integration und zum Austausch verschiedenartiger Daten zwischen Dokumenten. Zu diesem Zeitpunkt war noch keine Rede von der Unterstützung verteilter Systeme. Dies änderte sich erst 1997 mit der Einführung des Distributed Common Object Model (DCOM). Mit DCOM wurde es möglich COM Komponenten über das Netz zu lokalisieren und anzusprechen. Microsoft setzte in diesem Bereich entsprechend seiner Unternehmensphilosophie nicht file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (7 von 11) [ :32:39]

8 auf offene Standards. Ein Architekturmodell wie CORBA oder J2EE gab es nie. Auch der Begriff des Application Servers tauchte im Zusammenhang mit Microsoft nicht auf. Als Äquivalent wird in der Literatur häufig das Betriebssystem Windows NT (heute abgelöst durch Windows 2000) mit MTS, COM und DCOM (heute zusammengefasst unter dem Begriff COM+) genannt. Microsoft führte stattdessen, wenn auch eher halbherzig, den Begriff Distributed InterNet Applications (DNA) ein. Damit fasst Microsoft alle eigenen Produkte, die verteilte Anwendungen unterstützen, zusammen. Dazu zählte unter anderem auch COM+. Anfang 2001 startete Microsoft eine neue Offensive. Die DNA Komponenten wurden einer Gesamtrenovierung unterzogen. Bereits vorhandene Technologien wie ADO oder ASP wurden vereinfacht und vereinheitlicht. Die meisten der bereits vorhandenen Microsoft Services, wie SQL Server oder Microsoft Message Queue wurden integriert. Ergebnis war im vierten Quartal 2001 die Einführung von.net, einer Architektur für verteilte Systeme auf Microsoft Plattformen. Abbildung 4: Zeitleiste Eine der Kernideen von.net ist die Bereitstellung von Anwendungen als WebServices im Internet. Durch die Unterstützung offener Standards wie HTTP, XML und SOAP (Simple Object Access Protocol.) wird hier die Idee der Interoperabilität von Applikationen selbst file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (8 von 11) [ :32:39]

9 über Firewallgrenzen hinweg in ihrer letzten Konsequenz Wirklichkeit. Microsoft öffnet sich. 8 Aktuelle Situation CORBA hat aktuell den schwersten Stand. Crux des CORBA Standards ist die Unhandlichkeit bei der Entwicklung. Objekte, die CORBAServices verwenden wollen, müssen explizit auf diese zugreifen, ein Mehraufwand bei der Implementierung, der spätestens seit der Einführung des EJB Containers von Entwicklern in der Form nicht mehr akzeptiert wird. Die OMG spezifizierte als Antwort auf den Erfolg von EJB das CORBA Component Modell (CCM), ein an den EJB Standard angelehntes, in einigen Bereichen durchaus verbessertes Komponentenmodell. Wie sich jedoch gezeigt hat, kam der Standard zu spät. Herstellerfirmen wie Bea oder IONA, die sich als OMG Mitglieder ursprünglich bereit erklärt hatten, eine Referenzimplementierung zu liefern, setzen heute auf J2EE. Nach dem Standardisierungsmodell der OMG wird ein Standard zurückgenommen, falls nicht innerhalb eines vorgegebenen Zeitraums eine Referenzimplementierungen vorliegt. Dieser Fall könnte nun einzutreten und obwohl es einen vollständigen Standard für ein Komponentenmodell gibt, wird dieses wohl nicht Teil des CORBA Standards werden. J2EE hat seine ersten Kinderkrankheiten überstanden und steht gerade in der Blüte seiner Entwicklung. Mit der neuen Version 1.3 wurden einige Defizite der vorangegangenen Versionen ausgebügelt. Wichtigste Neuerungen sind die Erweiterung des EJB Standards um eine vollständige Spezifikation der Persistenz, die Einführung von Message Driven Beans und die Einführung von Local Interface zur Minimierung entfernter Aufrufe. Der Standard hat sich inzwischen etabliert. In der Praxis stellten Unternehmen jedoch fest, dass ein Application Server alleine wenig Nutzen bringt, solange er nicht mit anderen Applikationen oder Systemen kommunizieren kann. Die Weiterentwicklung des Standards macht dies deutlich. 1. Zur Interoperabilität von CORBA und EJB wurde das Internet Inter ORB Protokoll (IIOP) von CORBA mit in den EJB Standard aufgenommen und dient als Übertragungsprotokoll für RMI Aufrufe. 2. Die neu hinzugekommene Spezifikation der Java Connector Architecture (JCA) bietet einen Ansatz zum transaktionsgesicherten Zugriff auf Backend Systeme. J2EE und EAI (Enterprise Application Integration) wachsen zusammen. 3. Mit JavaOne wurde von Sun das Thema WebServices aufgegriffen. Ähnlich dem.net Ansatz werden J2EE Applikationen als WebServices verpackt und im Internet file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (9 von 11) [ :32:39]

10 angeboten. JavaOne liefert in dieser Hinsicht einen zu.net durchaus gleichwertigen Ansatz. Entscheidend für die Weiterentwicklung von J2EE ist die bislang ungebrochene Unterstützung durch Herstellerfirmen. Falls es gelingt, die immer noch vorhandenen Probleme des Standards in den nächsten Versionen in den Griff zu bekommen, wird J2EE auch weiterhin eine entscheidende Rolle als Architekturmodell auf dem Application Server Markt spielen,.net als jüngste der Technologien muss erst noch zeigen, ob und inwieweit sie den Erwartungen standhalten kann. Die unterliegenden Microsoft Technologien bieten eine stabile und bewährte Grundlage, so dass davon ausgegangen werden kann, dass diese Architektur tragfähig ist. Mit der Idee der WebServices und der Unterstützung offener Protokollstandards geht Microsoft zum ersten Mal den Weg in Richtung Öffnung nach außen. In einer Welt der globalen Interoperabilität von Anwendungen ist dies eine entscheidende Voraussetzung für.net sich neben J2EE als alternatives Architekturmodell zu behaupten. 9 Marktbeobachtungen Die Weiterentwicklung der Produkte erfolgt zur Zeit mit ungeheurer Dynamik. Der Application Server Markt selbst ist dagegen eher ruhig und wird von den Platzhirschen Bea (WebLogic Server) und IBM (WebSphere) dominiert. Andere Produkte haben wenig Chancen sich dagegen zu behaupten. Völlig neue Felder eröffnen sich hingegen bei der Erweiterung des Application Servers in Richtung Enterprise Application Integration und Webunterstützung. Generell gibt es zur Zeit drei Entwicklungen am Markt zu beobachten. Auf der Serverseite tendieren Hersteller immer stärker zu Integrationsplattformen. Diese bieten zusätzlich zum inzwischen klassischen Application Server, Komponenten zur Anbindung an Backend Systeme, häufig in Kombination mit Workflow Komponenten. Auf der Präsentationsschicht erobern Portal Server den Markt. Sie unterstützen die Entwicklung von Webapplikationen, bieten vereinfachte Anwendungsintegration durch sogenannte Portlets und unterstützen die Anbindung von Content Management Systemen. Weiteres Thema sind WebServices. Sie eignen sich nicht nur für das Internet. Auch im Bereich EAI finden sie verstärkt Einsatz. Backend Systeme bieten ihre Dienste als WebServices innerhalb eines Unternehmens an. Die Kommunikation läuft file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (10 von 11) [ :32:39]

11 über XML Busse. Viele Produkthersteller sehen auf dem Application Server Markt heute keine Chance und versuchen auf einem dieser drei neuen Gebiete Fuß zu fassen und ihre Produkte dahingehend zu erweitern. Der Markt für Integrationsplattformen und Portalserver ist noch in Bewegung. Wie er sich weiterentwickelt, wer Verlierer, wer Gewinner wird, ist zur Zeit völlig offen. Der Kampf hat gerade erst begonnen. file:///s /Daten/cdrom/spektrum/JavaSpektrumArtikel_Appserver_Historie.html (11 von 11) [ :32:39]