Thema: Application Server

Informatik-Anwendungen II WS 2003/2004 Thema: Application Server Bearbeiter : Ines Bilsing, S707678 Sarah Maidorn, S707746 Datum : 09. Dezember 2003

I. Abstract Aus der Motivation heraus ein Themengebiet der Informatik nicht nur aus dem kaufmännischen, sondern auch aus dem technischen Augenwinkel zu betrachten, entstand die Semesterarbeit der Lehrveranstaltung Informatik-Anwendungen II bei Herrn Prof. Dr. Godbersen. In unserer Semesterarbeit für die Lehrveranstaltung Informatik-Anwendungen II, versuchen wir unserem Leser die Bedeutung und Funktionsweise eines Application Servers darzulegen. Da es noch keine genaue und vor allem einheitliche Definition des Begriffes Application Server gibt, wollen wir versuchen, den Begriff einzukreisen und soweit uns möglich auch zu definieren. Des weiteren werden wir auf die Architektur und den Aufbau des Application Servers eingehen und die Aufgaben eines Application Servers beschreiben. Wir werden außerdem auf die Entwicklung eines Application Servers eingehen. Da sich seit 1999 kontinuierlich Veränderungen in diesem Bereich ereignet haben, werden wir versuchen einen kurzen historischen Rückblick zu geben. Dabei werden hauptsächlich die Marktführer im Bereich des Application Servers von 1999-2001 betrachtet. Sofern möglich wollen wir dem Leser auch aufzeigen, welche Unterschiede zwischen den einzelnen Produkten der jeweiligen Hersteller existieren. Ziel der Arbeit ist es, einen kurzen und weitreichenden Überblick zu geben. Der begrenzte Rahmen der Semesterarbeit lässt es zwar nicht zu eine gewisse Tiefe zu überschreiten, dennoch waren wir bedacht alle relevanten Themengebiete mit einzubeziehen und zu erörtern. Ines Bilsing, Sarah Maidorn Page 2 of 2

II. Abkürzungsverzeichnis CGI CORBA DBMS EDI EJB HTML HTTP IIOP JDBC JMS ODBC SOAP UDDI WSDL XML Common Gateway Interface Common Object Request Broker Architecture Data Base Management System Electronic Data Interchange Enterprise JavaBean HyperText Markup Language HyperText Transfer Protocol Internet Inter ORB Protocol Java Database Connectivity Java Message Service Open Database Connectivity Simple Object Access Protocol Universal Description, Discovery and Integration Web Services Description Language Extensible Markup Language III. Abbildungsverzeichnis Abbildung 1: Komponenten eines Applikation Servers...7 Abbildung 2: 3-Schichten Architektur...8 Abbildung 3: Aufbau des Application Server...11 Abbildung 4: 3-Tier Architektur...14 Ines Bilsing, Sarah Maidorn Page 3 of 3

IV. Inhaltsverzeichnis 1. EINLEITUNG...5 2. GRUNDLAGEN...6 2.1 DEFINITION EINES APPLICATION SERVER...6 2.2 AUFGABEN EINES APPLICATION SERVER...7 2.3 EIGENSCHAFTEN EINES APPLICATION SERVER...9 2.4 ARCHITEKTUR DES APPLICATION SERVER...11 2.5 FUNKTIONSWEISE DER DATENÜBERTRAGUNG...13 3. ENTWICKLUNG DES APPLICATION SERVER...14 3.1 3-TIER-MODELL...14 3.2 VORTEILE DER SCHICHTENBILDUNG...15 3.3 ENTWICKLUNG VOM 2-TIER HIN ZUM 3-TIER MODELL...15 4. VERGLEICH...16 4.1 EINSATZGEBIETE DES APPLICATION SERVER...16 4.2 ARTEN DES APPLICATION SERVER...16 4.3 ENTWICKLUNG VON JAVA ZU J2EE...17 5. MARKETING...19 5.1 MARKETINGKONZEPT DES APPLICATION SERVER...19 6. FAZIT...26 Ines Bilsing, Sarah Maidorn Page 4 of 4

1. Einleitung Der Begriff Application-Server ist mehr eine Marketingbezeichnung als ein einheitliches technisches Konzept. In der Regel wird darunter eine Server Softwareumgebung verstanden, die bestimmte Funktionen erfüllt. So werden Anwendungen bereitgestellt, die auf den Clients beispielsweise im Browserfenster angezeigt werden, aber auf dem leistungsstarken Server ausgeführt werden.[dre01] Der Application Server vereinfacht die Anwendungsentwicklung durch die Bereitstellung einer Vielzahl von Diensten, wie Netzwerk-Services, verteilte Objekte, Directory-Services, Messaging, Event Handler, Security, Transaktionssteuerung, Multi-Processing, Datenbank- Connectivity. Mit der wachsenden Popularität von Java, CORBA und von Internet und Intranet als Basis für verteilte Applikationssysteme stellt die Umsetzung von Anwendungen eine neue Herausforderung dar. Die Entwicklung der sogenannten Application Server bildet die Grundlage der Entwicklung neuer webbasierter Anwendungen.[Lan01] Ines Bilsing, Sarah Maidorn Page 5 of 5

2. Grundlagen 2.1 Definition eines Application Server Motivation Der Application Server wurde aus mehreren Gründen heraus entwickelt. Zum einen sollten Geschäftsanwendungen im Internet möglich sein. Dies sollte durch nachfolgende Ideen verwirklicht werden: ƒmehrstufige Architekturen (Geschäftslogik) ƒintegration von Legacy-Systemen Eine komplexe Entwicklung, die Teil eines solchen Application Server ist, sollte zudem folgende Bereiche abdecken: ƒsicherheitsanforderungen ƒtransaktionsunterstützung ƒheterogene Umgebung Aus dieser Motivation heraus ist das Ziel entstanden, mit dem Application Server ein modulares, hoch-skalierbares und robustes System bereitzustellen. Dieses System sollte aber trotzdem dynamisch genug sein, um die sich schnell ändernden Businessanforderungen erfüllen zu können. Begriff Der Application Server kann als Zusammenwachsen von Nischentechnologien angesehen werden. Er vereinigt Middleware-Technologien miteinander: ƒweb-server ƒtransaktionsmonitore ƒobject Request Broker ƒsicherheitslösungen ƒdatenbankzugriffslösungen Letztendlich kann man den Application Server auch als Entwicklungsumgebung und Managementlösung ansehen.[mag01] Ines Bilsing, Sarah Maidorn Page 6 of 6

2.2 Aufgaben eines Application Server Beschreibung Application Server sind Programmpakete, die Techniken wie CORBA 1, HTTP, Enterprise Java Beans (EJB) und Programmiersprachen wie JAVA, Perl, C++ unterstützen und mehrere bisher getrennt erhältliche Middleware-Produkte zu einem Produkt zusammenfassen. Abbildung 1: Komponenten eines Applikation Servers Quelle: Universität Stuttgart, Clemens Dorda Application Server Techniken für Web-Anwendungen Application Server bieten dem Systemadministrator eine integrierte Bedienoberfläche, mit der die verschiedenen Komponenten und Services installiert und verwaltet werden können. Durch die Zusammenfassung mehrerer bisher getrennter Middleware-Funktionalitäten bilden Application Server das Bindeglied zwischen den Clients auf der einen Seite, die über HTTP und IIOP mit dem Application Server kommunizieren, und der Datenbank auf der anderen Seite, mit der der Application Server mit Hilfe proprietärer Datenbankschnittstellen oder offener Standards wie ODBC/JDBC kommuniziert (siehe Abbildung 2). Die Anwendungen, die für Application Server erstellt werden, zeichnen sich dadurch aus, dass sie im Gegensatz zum klassischen Java-Applet die Anwendungslogik soweit wie 1 siehe Abkürzungsverzeichnis Ines Bilsing, Sarah Maidorn Page 7 of 7

möglich auf dem Server durchführen. Der Client hingegen muss sich nun nicht mehr um die Verarbeitung der Anwendungsdaten kümmern und dient somit ausschließlich der Präsentation der Anwendung. Dadurch können sicherheits- und geschäftskritische Verarbeitungsvorgänge weitgehend weg vom Client hin zum Application Server verlagert werden, weswegen auch in Abbildung 2 die bei Application Server übliche Einteilung in ƒpresentation (Client) ƒbusiness Logic (Application Server + Komponentenapplikationen) ƒdata/ressoure (Datenbanken) vorgenommen wurde. Abbildung 2: 3-Schichten Architektur Quelle: Universität Stuttgart, Clemens Dorda Application Server Techniken für Web-Anwendungen Leistungsumfang Der Application Server ist im übertragenen Sinne ein Rahmen für die Verarbeitung von Business Logik. Mit ihm sind Verbindungen für Back-End-Systeme möglich, denn mit dem Application Server wird eine Brücke zu allen eingesetzten Datenhaltungssystemen geschlagen: ƒdatenbanken ƒlegacy-systeme ƒtransaktionsmonitore Ines Bilsing, Sarah Maidorn Page 8 of 8

Verbindungen zu Front-Ends über: ƒweb Clients ƒrich Clients Web Application Server Der Web Application Server ist eine typische Komponente des Application Servers. An vorderster Front des Application Servers steht der Webserver, der alle Anfragen des Clients, die er direkt verarbeiten kann, selbst ausführt (z.b. die meisten HTTP Anfragen und die CGI-Skriptaufrufe) alle anderen Abfragen aber direkt an die darunterliegende Schicht, dem eigentlichen Application Server, übergibt, wo die Anfrage dann an die entsprechende durch sogenannte Container (Komponenten-Laufzeitumgebung) eingebettete Komponente/Applikation geleitet und von dieser verarbeitet wird. Das Ergebnis wird anschließend an den Client-Browser zurückgeschickt.[aix01] 2.3 Eigenschaften eines Application Server Unterstützung verschiedener Clients Unterstützt werden sowohl HTML, Java-Applets als auch Standalone-Applikationen. Auch eine HTML-Generierung ist möglich. Durch den Application Server wird die Anwendungslogik und die Benutzerschnittstelle voneinander getrennt. Ein Common Gateway Interface (CGI) für Web-Server ermöglicht die Auftragsabwicklung mittels Browser. Entwicklungsunterstützung Wie eingangs erwähnt, ist der Application Server eine Entwicklungsumgebung. Durch ihn ist es möglich Web-Benutzerschnittstellen zu entwickeln und Geschäftskomponenten zu installieren. Automatisierung von wiederkehrenden Aufträgen nach vordefinierten Zeiten und Intervallen. Gewährleistung von Skalierbarkeit und Verfügbarkeit Eine besondere Eigenschaft des Application Servers ist ebenfalls das Verbindungsmanagement. Durch dieses entsteht ein Lastausgleich und ein Fehlermanagement unterstützt die Fehlerkontrolle. Ines Bilsing, Sarah Maidorn Page 9 of 9

Sicherheitstechniken Durch die Bereitstellung von Verschlüsselungstechniken für Signierung (digitale Unterschriften) und sichere Kanäle (Secure Socket Layer) wird eine gewisse Sicherheit garantiert. Transaktionsmanagement in verteilten Umgebungen Über verteilte Systeme werden Transaktionen sichergestellt: ƒ2 Phasen-Commit-Protokolle ƒtransaktionsmonitore Für Web-Clients existiert ein Sessionmanagement. Berichtsergebnisse können als E-Mail- Anhang versandt werden. Mitteilung über die Auftragsbeendigung erfolgen per E-Mail. Datenbankzugriffe Datenbanken werden zur persistenten Speicherung von Geschäftsobjekten eingebunden. Auf Legacy-Daten kann zugegriffen werden. Performance-Monitoring Das Laufzeitverhalten der Applikation wird durch den Application Server überwacht und Engpässe aufgespürt. Nutzbarmachung der Leistungsfähigkeit von 32-Bit Windows NT- Maschinen. Entlastung der Clients durch fehlertolerante Servertechnologie für Anwendungen. PCs werden zum Schaffen von Freiräumen für andere Aufgaben entlastet und die Netzwerkbelastung minimiert. Applikationsmanagement und konfiguration Es entsteht eine zentrale Verwaltung und Fehlerüberwachung. Außerdem werden Applikationen installiert und gepflegt über das Applikationsmanagement und konfiguration. Immer wieder erfolgt ein Lastausgleich. Ines Bilsing, Sarah Maidorn Page 10 of 10

2.4 Architektur des Application Server An dieser Stelle wird die Architektur des Application Server näher betrachtet. Der Application Server ist das Herzstück einer verteilten Applikation, da alle Verbindungswege dort zusammenlaufen. Er stellt eine Verbindung zwischen der Client-Anwendung z.b. einem Web-Browser und einem Datenbank-Server her. Man nennt den Application Server auch Middle Tier Server, da er die zentrale Schnittstelle darstellt, an der die drei Schichten (Tier) zusammenkommen. Ein kleiner Client stellt eine Verbindung zu einem Rechner her, der wiederum Client für einen Datenbankserver ist. Der Application Server dient somit der Bereitstellung der Logik für die Verarbeitungsprozesse. Abbildung 3: Aufbau des Application Server Quelle: eigene Darstellung in Anlehnung an die Quelle [Mag01] Der Application Server fasst verschiedene Middleware-Komponenten in einem Server zusammen. Zu diesen Komponentendiensten zählen zum Beispiel CORBA und EJBs, sowie HTTP und CGI als traditionelle Webtechniken. Ines Bilsing, Sarah Maidorn Page 11 of 11

Die Common Object Request Broker Architecture (CORBA) ist ein Remote Procedure Calls (RPC-) Verfahren. RPCs sind Methoden, mit denen ein Programm eine Prozedur eines anderen Programms über ein Netzwerk wie z.b. das Internet aufrufen kann. Die Enterprise JavaBean (EJB) ist eine Komponente, die Business-Logik enthält oder Daten der Datenbank repräsentiert. Sie dienen zur Erstellung verteilter komponentenbasierter Anwendungen, daher werden sie auch von mehreren Anwendungen gleichzeitig genutzt. Bei der Webtechnik des Common Gateway Interface (CGI) handelt es sich um ein weitverbreitetes Programm zur Generierung dynamischer HTML-Seiten. Auf der Anwendungsebene wird unter anderem das HyperText Transfer Protocol (HTTP) implementiert, dieses definiert die Kommunikation zwischen einem (HTTP-)Client und einem (HTTP-)Server, also den Datentransfer des Webs. (vgl. [Wif01]) Als Programmiersprachen werden vorrangig für die Serverseite Java und C++ unterstützt und auf der Client-Seite die Sprachen HTML und Java. Durch die integrierte Bedienoberfläche ermöglicht der Application Server die Installation und Verwaltung verschiedener Komponenten und Services. Durch diese komponentenorientierte Architektur wird die Entwicklung von objektorientierten Anwendung gerade für den Enterprise-Einsatz ermöglicht. Diese Anwendungen müssen entwickelt, deployed und in verteilten Umgebungen ausgeführt werden. Damit die Anwendung einsatzfähig ist, benötigt man zusätzlich noch ein Transaktions- und Sicherheits-Management sowie eine Datenbankanbindung. Eine Transaktion ist ein Verbund von SQL-Anweisungen, bei dem entweder alle Anweisungen oder keine ausgeführt werden. Jeder Benutzerauftrag wird als Transaktion bezeichnet. Das Transaktions-Management dient zum Starten und Beenden von Transaktionen, es kennzeichnet die Transaktionsgrenzen und ist für die Festschreibung oder das Zurückrollen einer Transaktion verantwortlich. Das Sicherheits-Management überwacht die Zugangsberechtigung auf Grundlage eine vordefinierten Policy. Zu seinen Komponenten gehören unter anderem die Schlüsselverteilungszentren, die Zertifizierungsstellen und Firewalls. Ines Bilsing, Sarah Maidorn Page 12 of 12

Wie kriege ich die Software portabel? Die Software bzw. Anwendungslogik liegt auf dem Application Server. Die Anwendungen werden im Application Server, der zentral verwaltet wird, deployed. Danach werden den Nutzern diese Anwendungen über das Internet oder private Netzwerke zur Verfügung gestellt. Der Application Server als Middleware stellt Komponenten und Standards bereit, die eine Kommunikation zwischen Client und Server ermöglichen unabhängig von der Hardwareumgebung. Dadurch sind die Anwendungen problemlos einsetzbar und beim Eintreten von Änderungen an den Anwendungen entsteht ein geringerer Entwicklungsaufwand und damit geringere Kosten. Der geringere Aufwand wird dadurch erzielt, dass die Anwendungen einmal zentral im Application Server abgelegt sind und diese bei Änderungen dann auch nur einmal zentral auf diesem bearbeitet werden müssen. Application Server als schnellerer Zugriff für Clients Da die Middleware die Geschäftslogik der Anwendung implementiert, wird der Client entlastet. Man spricht auch von thin client schlanker Client. Somit ergibt sich der Vorteil, dass bei Eintreten von Änderungen, lediglich die mittlere Schicht betroffen ist. Hauptziel des Application Servers ist es, ein modulares, hoch-skalierbares und robustes System zu sein. Im Gegensatz dazu muss er dynamisch genug sein, um schnell die sich ständig ändernden Business-Anforderungen erfüllen zu können. 2.5 Funktionsweise der Datenübertragung Die Kommunikation zwischen Client und Application Server erfolgt über HTTP und IIOP. Das Internet Inter ORB Protocol (IIOP) ist ein Protokoll, um mit verteilten Objekten zu arbeiten. Über das Protokoll kann jedes Objekt in seiner Programmiersprache angesprochen werden. Es bildet die Grundlage der CORBA-Technologie. Die Definition für die Anforderung von Web-Seiten durch einen Web-Client bzw. die Übertragung von Servern zu Clients erfolgt durch das HyperText Transfer Protocol, (HTTP). Für die Datenbankkommunikation wird über Datenbankschnittstellen und offene Standards wie JDBC / ODBC gearbeitet. Das JDBC-Protokoll stellt eine standardisierte Schnittstelle für den Datenbankzugriff dar. Dadurch ist eine nahtlose Integration mit jeder Datenbank möglich. Das ODBC-Protokoll ist ein von Microsoft definierter Standard für SQL-Zugriffe auf Datenbanken. Ines Bilsing, Sarah Maidorn Page 13 of 13

3. Entwicklung des Application Server 3.1 3-Tier-Modell Abbildung 4: 3-Tier Architektur Quelle: eigene Darstellung in Anlehnung an die Quelle [Hra01] Die erste Tier bzw. Schicht ist die Präsentationsebene. Sie liegt beim Client und stellt den Front-End dar. Die zweite Tier wird durch den Application Server gebildet. Er stellt damit die Applikationsebene dar, in der die Anwendungslogik bereitgestellt wird. Auf der Back-End Seite, die durch das dritte Tier dargestellt wird, ist die Datenbank mit allen persistenten Daten angebunden. Bei den Datenbank-Servern kann es sich um einen Data Base Management System (DBMS) handeln. Dieses Datenbankverwaltungssystem übernimmt die physische Datenorganisation. Die Verbindung zum Applikation Server wird mit Hilfe von JDBC oder ODBC aufgebaut. Der Datenbankserver kann auch ein Enterprise Resource Planning-System (ERP-System) oder ein Legacy-System sein. Diese nutzen die IBM MQ-Series als Ines Bilsing, Sarah Maidorn Page 14 of 14

Verbindungsprotokoll zum Application Server. Ein Alt-System, das schon seit Jahren im Einsatz ist, wird als Legacy-System bezeichnet. 3.2 Vorteile der Schichtenbildung Die Vorteile der Schichtenbildung liegen bei der Entwicklung von Anwendungen darin, dass die Entwickler durch die Unterteilung in Präsentations-, Anwendungs- und Datenschicht gezielter eingesetzt werden können. Durch den komponentenbasierte Aufbau der Anwendungen kann eine unabhängigere Entwicklungsarbeit stattfinden. Ein weiterer Vorteil ist der einfachere Austausch von Software innerhalb einer Schicht, welcher durch die standardisierten Schnittstellen ermöglicht wird. Die Offenheit der Schnittstellen, als dritter Vorteil, ruft eine Vereinfachung bei der Integration vorhandener und neuerer Technologien hervor. 3.3 Entwicklung vom 2-Tier hin zum 3-Tier Modell Bei der 2-Tier Architektur werden lediglich SQL Anfragen vom Client an den Server geschickt und der Client bearbeitet dann dessen Antworten. Die Unternehmenslogik liegt bei diesem Modell auf den einzelnen Clients, was zu Verwaltungsproblemen führen kann. Dadurch das der Server die SQL Anweisungen ausführt und immer nur eine konkrete Antwort schickt, sinkt die Netzbelastung, was wiederum eine höhere Skalierbarkeit hervorruft. Die 3-Tier Architektur ermöglicht eine höhere Skalierbarkeit durch die Zwischenschaltung eines weiteren Servers, dem Application Server. Dieser verwaltet alle Anwendungen und Transaktionen. Somit wird die Unternehmenslogik mehr auf die Mittelschicht verlegt. Durch diese Verlagerung und zentrale Ablage der Daten wird der Aufwand bei Anpassung der Anwendungen an den Markt bzw. Kundenanforderungen erheblich gesenkt, da nicht mehr jeder Client individuell angepasst werden muss, sondern lediglich einmal die Anwendungen auf dem Application Server. Dies zählt mit zu den Hauptvorteilen der Einführung der dritten Tier. (vgl. [Wex01]) Ines Bilsing, Sarah Maidorn Page 15 of 15

4. Vergleich 4.1 Einsatzgebiete des Application Server Für den IT-Verantwortlichen eines Unternehmens stellt sich die Frage, wann braucht das Unternehmen einen Application Server. Die Frage kann so beantwortet werden, wenn das Unternehmen einige der folgenden Aspekte für seine IT benötigt: ƒoffene, skalierbare Anwendungen ƒwiederverwendbare Komponenten ƒwebanwendungen ƒdienste (Webservices) ƒsicherheit ƒrollen, Rechte ƒtransaktionen ƒherstellerunabhängigkeit ƒdatenbankunabhängigkeit (vgl. [Ora03]) 4.2 Arten des Application Server Wenn die Entscheidung für den Einsatz eines Application Servers gefallen ist, müssen die IT- Verantwortlichen aus der Fülle an Anbietern und Produkten, den für ihre IT-Landschaft und Bedürfnisse passenden auswählen. An dieser Stelle werden drei Application Server etwas genauer auf ihre Zusammensetzung hin dargestellt. Oracle Application Server Der Oracle Application Server bietet eine J2EE konforme Laufzeitumgebung. Als Skriptsprachen können zusätzlich Perl und PL/SQL verwendet werden. Zudem bietet der Server Web Services mit den offenen Standards SOAP, WSDL und UDDI an. Oracle hat eine eigene integrierte Entwicklungsumgebung und eine eigene Portaltechnologie in den Application Server integriert. Mit Hilfe von SOAP, XML und SMS wird Mobile Computing unterstützt. Des weiteren stehen eine Reihe von eigenen Servererweiterungen wie Load Balancing, Cluster Server, Single Sign On zur Verfügung, wie auch eine große Bandbreite an Connectivity-Möglichkeiten zu Alt-Systemen durch JMS, EDI, JDBC oder auch XML. (vgl. [Ora03]) Ines Bilsing, Sarah Maidorn Page 16 of 16

IBM WebSphere Application Server Der WebSphere unterstützt die Webservices ebenfalls mit den offenen Standards SOAP, WSDL, UDDI sowie XML und J2EE. Als Verbindungsstandards für die Integration von Alt- Systemen werden CORBA und ActiveX angeboten. Der Application Server von IBM hat seine Leistungsfähigkeit durch dynamisches Reload von EJBs und veränderten Caching- Methoden verbessert. Die Plattformen Linux, AIX, HP-Unix, Solaris, Windows (NT, 2000, 2003) sowie iseries können dem Application Server zugrunde liegen. Von IBM gibt es verschiedene Versionen des IBM WebSphere Application Server. Den oben beschriebenen WebSphere Application Server (WAS) und WAS Network Deployment, den WebSphere Application Server Express, den WebSphere Application Server Enterprise und den WebSphere Application Server für z/os. Mit diesen vier Versionen wird IBM den verschiedenen Kundenbedürfnissen und Unternehmensanforderungen gerecht. (vgl. [IBM01]) Sun ONE Application Server Der Sun ONE Application Server ist J2EE kompatibel und unterstützt JSP-, Java Servlet- und EJB-basierte Anwendungen. Der Server bietet wie die beiden zuvor beschriebenen Server die Webservices mit SOAP und WSDL an, aber auch JAXM, JAXP und JAXR. Als Entwicklungsumgebung stehen Sun ONE Studio 4 und Sun ONE Application Framework zur Verfügung, die problemlos integriert werden können. Als Plattformen werden wie beim IBM Server Solaris, Windows 2000 & XP, Linux, HP-UX und AIX unterstützt. (vgl. [SUN01]) Die Auswahl an Application Servern ist groß. Wie man an den drei Beispielen sieht, unterscheiden sich die Application Server auf den ersten Blick nicht sonderlich. Daher muss ein IT-Verantwortlicher eines Unternehmens bei der Auswahl eines Servers sehr genau wissen, welche Anforderungen an den Application Server gestellt werden, um den idealen zu finden. 4.3 Entwicklung von Java zu J2EE Die Firma Sun Microsystems entwickelte zu Beginn der neunziger Jahre mit Java eine objektorientierte, Hardware-unabhängige Programmiersprache, die sowohl für eigenständige Programme als auch Client/Server-Anwendungen im Internet genutzt werden kann. So ist es mit Java möglich kleine Programme in selbst erstellten Seiten ablaufen zu lassen, das könnten Ines Bilsing, Sarah Maidorn Page 17 of 17

z.b. eine Datenbankschnittstelle oder einfache Animationen sein. Der Vorteil von Java z.b. gegenüber CGI ist, dass die WWW-Server weniger belastet sind, da die Programme auf dem Client laufen und von diesem eine direkte Kommunikation mit der Datenbank erfolgt. Java wurde in den kommenden Jahren immer weiterentwickelt, doch mit der Zeit wuchsen die Ansprüche an die Anwendungen. Die Wirtschaft wollte verteilte, robuste und skalierbare Anwendungen. Diese Anforderungen konnte die Standard Edition Javas nicht erfüllen. Seit 1999 gibt es daher die Java 2 Enterprise Edition, J2EE. Sie setzt sich aus verschiedenen Technologien zusammen, die zuvor entweder als Erweiterungen der Standard Edition verfügbar waren oder im Rahmen von J2EE neu entwickelt wurden. Diese neuen Technologien sind auf die Ansprüche und Anwendungsfälle von mittleren und großen Unternehmen zugeschnitten, wobei das Internet als Informationsmedium dient. Durch J2EE wurde eine Architektur zur Entwicklung von komplexen Anwendungen und deren Ausführung in verteilten Systemen geschaffen. Diese komplexen Anwendungen müssen höhere Systemanforderungen erfüllen, wie zum Beispiel einem Transaktionsmanagement, verteilten Datenbankzugriffen und einer hohen Anzahl an Client-Zugriffen. Durch den Einsatz von J2EE findet zudem eine stärkeren Konzentration auf die Business-Logik statt. Zu den Aufgabengebieten der Java 2 Enterprise Edition zählen: ƒdatenbankzugriff ƒdynamische Internetseiten ƒenterprise JavaBeans ƒmiddle-tier-server ƒplattform-unabhängige Kommunikation ƒsicherheit ƒtrennung der Anwendungsschwerpunkte ƒverteilte Systeme ƒweb-server-einsatz All diese Komponenten sind in J2EE integriert, wobei der Fokus jedoch bei der Entwicklung verteilter Anwendungssysteme liegt. Gründe hierfür sind vor allen Dingen die Kostenreduzierung und die Verringerung der Informations- und Reaktionszeit für ein Unternehmen. Ines Bilsing, Sarah Maidorn Page 18 of 18

J2EE setzt sich wie erläutert aus verschiedenen Technologien zusammen. An dieser Stelle sollen davon jedoch nur einige genauer betrachtet werden. Als erstes das Java Servlet mit dem dynamische HTML-Codierung erzeugt werden kann, wodurch immer aktuelle Informationen dem Anwender bereitgestellt werden. Zu dem kommt die bessere Leistungsfähigkeit der Servlets im Vergleich zu anderen Technologien wie z.b. CGI hinzu. Als zweites wären die JavaServer Pages (JSP) zu erwähnen. Diese sind wie Servlets in der Lage, dynamische HTML-Codes zu generieren, wobei sie zusätzlich noch Web-Server-unabhängig einsetzbar sind. Als letztes werden die Enterprise JavaBeans betrachtet, welche die Kerntechnologie von J2EE darstellen. Zu beachten ist, dass es sich dabei nicht um JavaBeans handelt. Die EJBs stellen innerhalb von unternehmensweiten Anwendungen eine Funktionalität zur Verfügung und besitzen Schnittstellen zur Integration von Anwendungs- bzw. Application Servern. (vgl. [Her01]) 5. Marketing 5.1 Marketingkonzept des Application Server Geschichte des Application Server Im Jahr 2000 wurden die Komponenten des Java 2 Enterprise Edition (J2EE) aus Gründen des Marketings in neun Produkte eingebaut. Die Strategie der Hersteller hat sich seitdem kontinuierlich gewandelt. Nicht mehr der Fokus auf die Kernprodukte ist entscheidend, sondern die integrierte Vielfalt an J2EE Leistungen bis hin zu avoiding commodization by leveraging J2EE Servers als Plattform für WebServices, Wireless and EAI Entwicklung. Die Java Server Seite des Marktes Anfang des Jahres 2000 Vor dem Jahr 2000 war die Zukunft für den Markt der Java Middleware sehr unsicher. Die Beliebtheit der Java Application Programming Interfaces (API) wie zum Beispiel Servlets, Java Server Pages (JSP) und Marktanteile der Enterprise Java Beans (EJB), löste eine Welle von Start-ups aus, die Server Produkte entwickelten, um jedes der APIs zu implementieren. Der Fokus dieser Hersteller lag auf dem Entwickeln und Vertreiben der API-spezifischen Produkte. Am Anfang des Jahres 2000 erblickten klare Marktführer wie Jrun das Spektrum an Produkten der Präsentationsschicht für sich, wie zum Beispiel Servlet/JSP Maschinen. Ines Bilsing, Sarah Maidorn Page 19 of 19

Ende 1999 und Anfang 2000 gab es über 30 Hersteller der EJB Application Server. Nichts desto trotz hatten nur einige wenige eine komplette EJB 1.0 Implementation. Das Augenmerk der Industrie lag auf dem EJB Application Server und Unternehmen kämpften darum, als bevorzugte Hersteller von EJB Servern bekannt zu sein. Da aber jeder EJB Server die EJB Spezifikation implementieren musste, fingen Unternehmen an, sich auf dem Markt zu positionieren in dem sie in komplementäre Features investierten, die nicht in den Spezifikationen gefunden werden konnten, wie Clusterung und Datenspeicherung. J2EE Projektmanager standen nun vor der Aufgabe die geeignete Software auszuwählen. Sie mussten zwischen verschiedenen Produkten von unterschiedlichen Herstellern wie zum Beispiel Web Servern, Servlet/JSP Engines, EJB Application Servern und Datenbanken wählen. Da aber wenige Hersteller komplette Produktpaletten für den Bereich J2EE APIs anboten, bauten die J2EE Projekte meistens auf Produkten von bis zu 4 verschiedenen Unternehmen auf. Dies war Anfang 2000 nicht ungewöhnlich. Im Bezug auf den entgültigen Release der J2EE 1.0 Spezifikation fing eine Minderheit vorausdenkender Unternehmen an, ihren Fokus auf das Anbieten von kompletten Systemen für J2EE Produkte zu legen, von Web Servern bis hin zu EJB Application Servern. Diese Unternehmen erkannten, dass ein komplettes Angebot der Schlüssel zum Gewinn der Herzen der Projektmanager war, die sich mit cross-vendor Produkt Integration Themen beschäftigten. Ende 1999 war BEA eines der wenigen Unternehmen, die ein komplettes in-house built suite Produkt hatten. BEA Weblogic beinhaltet einen Web Server, Servlet/JSP Maschine und EJB Application Server. IBM hatte auch ein Komplettangebot (WebSphere). Obwohl der Support von WebSphere für die neuesten Servlets, JSPs und EJB APIs weit hinter der Konkurrenz lagen, war IBM der first-to-market mit ihrem mächtigen EJB RAD Tool basierend auf dem beliebten Visual Age DIE. Gemstone System beschloss ihren Application Server mit einer third party Servlet/JSP Maschine einzupacken. Im Fall von Gemstones war die New Atlanta Servlet Maschine gebündelt mit einem Gemstone/J Application Server. Orion, ein Unternehmen aus Europa, war auch unter den ersten, die die gesamte Palette des J2EE APIs unterstützten. Dessen freie Entwickler und non-profit Lizenzen machten Orion Server zu einem Favoriten in der Entwicklungsgesellschaft. Ines Bilsing, Sarah Maidorn Page 20 of 20

Für den Markt des Application Server wird das Jahr 2000 das Jahr des Wettbewerbes um komplementäre Produkte zu J2EE. Hersteller mobilisierten eine Menge an Entwicklern, Presseschreibern und Mitteln im Unternehmen zur Akquisition, um J2EE Komplementarität zu erreichen. Der erste Schritt zu einer Komplementarität war eine komplette Reihe zu J2EE anzubieten. Zweitens mussten ihre Produkte eine Sun J2EE Komplementarität Testreihe bestehen, die aus ungefähr 5000 Tests bestand, entwickelt, um aufzuzeigen, dass der komplementäre Application Server jede J2EE Applikation durchführen kann. Oracle Corporation wurde ein J2EE Lizenzpartner Ende Mai 2000, und proklamierte eine ganzheitliche JSP, Servlet und EJB Unterstützung im Juli 2000. Bluestone, ein traditionelles Middleware Unternehmen, verkündete eine Servlet und JSP Unterstützung zur Ergänzung ihres beliebten Sapphire/Web EJB Server entwickelt zu haben mit ihrer Produkteinführung des neuen Total-E-Server im Juli 2000. Am Ende des Sommers 2000 hatten J2EE Projektmanager eine ganze Reihe an Produktergänzungen aus dem sie auswählen konnten. Nun da J2EE Hersteller die J2EE Produktangebote vervollständigt und integriert hatten, wechselte der Fokus zu J2EE Komplementarität. SUN nutzte den Vorteil, den es als J2EE Spezifikationsprovider hatte, um den ersten Schritt als komplementären J2EE Server mit ihrem Iplanet Application Server im Juni 2000. Am Ende des Jahres 2000 hatte nur eine kleine Fraktion andere Hersteller wirkliche Versionen ihrer Produkte zum downloaden. Nichts desto trotz, schafften es alle wirkliche Implementierungen rechtzeitig anzubieten, um ihre J2EE Kompatibilität mit der Sun Microsystems Pressekonferenz Ende Januar zu verkünden. Nun stellte sich aber die Frage, wie man zwischen den Herstellern auswählen sollte, sobald alle Hersteller J2EE Kompatibilität anboten? Was würde einen $1500 Orion Application Server von einem $30,000 Bluestone Total-E-Server unterscheiden? Eine unbeliebte Vermutung war, dass kleinere Hersteller, die es sich nicht leisten konnten, beste Qualität herzustellen oder die über kleinere Marketingbudgets verfügten, in kurzer Zeit verschwinden würden. Zwei oder drei Industriegiganten würden dann die einzigen Anbieter von J2EE Servern sein. Das hätte eine totale Restrukturierung der bisherigen Industrie bedeutet. Zuvor war dies schon einmal bei AQL Standards passiert. Nur noch drei Hersteller dominieren das Gebiet der Datenbank: Oracle, IBM und Microsoft. Die Standardisierung der J2EE Kompatibilität hatte einen enormen Druck auf die Hersteller ausgeübt, sich von einander zu Ines Bilsing, Sarah Maidorn Page 21 of 21