Inhalt

1.  EINLEITUNG UND PROBLEMSTELLUNG  3

2.  FUNKTIONALE ANFORDERUNGEN  4

3.  NICHT-FUNKTIONALE ANFORDERUNGEN  6

4.  ÜBERBLICK ÜBER DIE J2EE / JAVA EE SPEZIFIKATION  7

5.  REALISIERUNG DER ANWENDUNG MIT J2EE TECHNOLOGIEN.  23

5.1.  EINGESETZTE SOFTWARE  23

5.2.  INTEGRATIONSSCHICHT (DATENBANKANBINDUNG)  24

5.3.  GESCHÄFTSLOGIKSCHICHT  31

5.4.  INTEGRATIONSSCHICHT (NACHRICHTENDIENST)  39

5.5.  DARSTELLUNGSSCHICHT  43

5.6.  EXPORT DER WEBSERVICES SCHNITTSTELLE  48

6.  REALISIERUNG DER ANWENDUNG MIT JAVA EE TECHNOLOGIEN  51

6.1.  EINGESETZTE SOFTWARE  51

6.2.  INTEGRATIONSSCHICHT (DATENBANKANBINDUNG)  52

6.3.  GESCHÄFTSLOGIKSCHICHT  58

6.4.  INTEGRATIONSSCHICHT (NACHRICHTENDIENST)  65

6.5.  DARSTELLUNGSSCHICHT  67

6.6.  EXPORT DER WEBSERVICES SCHNITTSTELLE  73

7.  VERGLEICH UND BEWERTUNG DER VORGEHENSWEISEN UND LÖSUNGEN  74

7.1.  GEMEINSAMKEITEN DER LÖSUNGEN  74

7.2.  UNTERSCHIEDE DER LÖSUNGEN  75

7.3.  ANALYSE UND BEWERTUNG  78

7.3.1.  TECHNISCHE ANALYSE UND BEWERTUNG  78

7.3.2.  BETRIEBSWIRTSCHAFTLICHE ANALYSE UND BEWERTUNG  83

8.  ZUSAMMENFASSUNG  88

I.  GLOSSAR  91

II.  ABBILDUNGSVERZEICHNIS  97

III.  TABELLENVERZEICHNIS  99

IV.  ABKÜRZUNGSVERZEICHNIS  100

V.  LITERATURVERZEICHNIS  102

2

Stilkonventionen dieser Arbeit

Die folgenden Schriftkonventionen sind in dieser Arbeit zu Grunde gelegt:

• Kursiv wird benutzt für

• Konstante Schriftweite wird benutzt für

• unterstrichener Text wird benutzt für

o Internet Adressen (URLs)

1. Einleitung und Problemstellung

„I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.“ (Hoare, 1980)

Die Java 2 Enterprise Edition (J2EE) Spezifikation hat sich seit ihrer Einführung im Dezember 1999 zum de-facto-Standard in der serverseitigen Softwareentwicklung etabliert. Projekte, die einen stark integrativen Charakter haben, in denen folglich eine Vielzahl von Diensten zumeist unterschiedlicher Hersteller zusammengeführt wird, werden fast ausschließlich mit Hilfe von J2EE Technologien realisiert.

Im Zuge der letzten Jahre wurden Stimmen laut, die zu bedenken gaben, dass die Art und Weise der komponentenbasierten Entwicklung zwar der richtige Weg, aber die Realisierung selbst zu umständlich und zu schwierig sei.

Im Rahmen der am 11. Mai 2006 veröffentlichten Java Enterprise Edition (Java EE) 5 Spezifikation wurde versucht, den Anregungen der kommerziellen Anwender und Entwickler zu entsprechen.

Im Rahmen dieser Arbeit soll untersucht werden, ob und wie die Entwicklung mit Java EE 5 den Entwicklungsprozess im Vergleich zu J2EE beschleunigt und vereinfacht. Um dieses zu analysieren, wird eine mehrschichtige verteilte Applikation zunächst mit Hilfe der J2EE 1.4 Spezifikation umgesetzt. Danach werden alle funktionalen und nichtfunktionalen Anforderungen mit der Java EE 5 Spezifikation nochmals umgesetzt, um einen objektiven Vergleich führen zu können. Abschließend werden die Applikationen anhand betriebswirtschaftlicher und technischer Kriterien untersucht, um zu ermitteln, welche unmittelbaren oder perspektivischen Vorteile bzw. Nachteile sich bei der Verwendung der jeweiligen Spezifikationen ergeben.

2. Funktionale Anforderungen

Zur Erarbeitung der benötigten Ergebnisse wird eine fiktive Auftragsstellung der Fluggesellschaft „Round Trip AG“ zu Grunde gelegt (Abb. 1).

Das Unternehmen möchte einen besseren Zugang zum Kunden finden und eröffnet daher ein Internetportal. Dieses Portal muss die Möglichkeit bieten, einem Kunden alle aktuell verfügbaren Flüge anzubieten. Der Kunde kann, nach erstmaliger Registrierung oder erfolgreicher Anmeldung, Flüge online buchen. Dafür wird bei der Registrierung ein Verfügungsrahmen zur Verfügung gestellt, der für die Buchung von Flügen genutzt werden kann. Zusätzlich können Kunden die bisher getätigten Buchungen online einsehen. Für eine bessere Kundenbindung muss ein Prämiensystem eingeführt werden, das darauf beruht, dass Kunden bei einer Buchung Punkte sammeln, die auf ihrem Konto gutgeschrieben werden.

Abb. 1 Anwendungsfall (Use Case) Diagramm der Anwendung

Im Zuge des entfernten Controllings muss ferner eine Möglichkeit bestehen, die aktuellen Umsätze zu ermitteln. Aufgrund der Tatsache, dass das Angebot der Round Trip AG auch auf einem zentralen Flugportal angeboten werden soll, muss eine SOAP basierte WebServices Schnittstelle zur Verfügung gestellt werden, über die buchbare Flüge ermittelt werden. Das Stornieren von Flügen wird in dieser Version nicht angeboten und ist daher nicht Bestandteil der aktuellen Entwicklung. Ebenso existiert ein dedizierter Service, der Zugriff auf die Systemdatenbank besitzt und die gebuchten Flüge den entsprechenden Fluglinien mitteilt. Dieser Service ist ebenfalls nicht Bestandteil des zu entwickelnden Online Systems im Rahmen dieser Arbeit.

Die folgende Grafik (Abb. 2) zeigt die Grobarchitektur der Anwendung.

Abb. 2 Architekturübersicht

Innerhalb des Webservers wird die webbasierte Anwendung für den Endkunden zur Verfügung gestellt. In dieser Webanwendung existiert ein vom Hauptsystem abgekapselter Bereich, der grundlegende Controlling Funktionalitäten zur Verfügung stellt. Außerdem wird dort auch der WebService, der über das http Protokoll aufgerufen werden kann, installiert.

Beide Komponenten greifen für die Bereitstellung ihrer jeweiligen Aufgaben auf Session Bean Komponenten ¹ zurück, die als entfernte Objekte registriert werden und in denen die fachlichen Anforderungen implementiert werden. Für den Zugriff auf die Datenbank werden Entity Beans ² genutzt, die letztlich eine objektorientierte Interpretation der Relationen der Datenbank darstellen. Für das asynchrone Verarbeiten der Prämienprüfung wird eine entsprechende Session Bean Komponente Nachrichten an den Message Provider senden, um somit eine indirekte Kommunikation mit einer Message Driven Bean ³ aufzubauen. Das grundlegende Zusammenspiel der benannten Objekte wird in Abb. 2 aufgezeigt.

¹ Siehe Kapitel 4, Seite 14

² Siehe Kapitel 4, Seite 16

³ Siehe Kapitel 4, Seite 18

3. Nicht-funktionale Anforderungen

Zunächst wird das System in einer virtuellen Maschine innerhalb eines bestehenden Servers installiert, um ohne zusätzliche Hardwarekosten die Akzeptanz der Lösung zu prüfen. Sollte sich ein Erfolg einstellen, so ist vorgesehen, dass die Applikation in der Lage ist, ihre Last auf mehrere Server zu verteilen sowie eine Ausfallsicherheit zu unterstützen (Abb. 3).

Abb. 3 Diagramm der Endausbaustufe

x

Als weitere Anforderung darf das Verarbeiten der Prämiendaten nicht in das Antwortverhalten des aufrufenden Kunden einfließen und muss somit asynchron verarbeitet werden.

Aktuell soll ein Drittsystem, das auf Microsoft Visual C++ beruht, für die Initialbestückung und die Aktualisierung von Flügen sorgen. Das System muss folglich eine sprachen- und plattformunabhängige Schnittstelle zur Verfügung stellen. Die Entwicklung dieses Windows Programms ist ebenfalls nicht Gegenstand dieser Arbeit.

4. Überblick über die J2EE / Java EE Spezifikation

Zum besseren Verständnis der nachfolgenden Applikationen wird in diesem Kapitel eine kurze Einführung in die Java 2 Enterprise Edition bzw. Java Enterprise Edition 5 gegeben.

J2EE bzw. Java EE (im folgenden Enterprise Java genannt) ist kein eigenständiges Produkt. Es ist vielmehr eine Vielzahl von Spezifikationen, die verschiedene Anwendungsbereiche adressieren und nahezu beliebig miteinander eingesetzt werden können (Baukastenprinzip). Ein Projekt muss somit nicht verpflichtend alle zur Verfügung stehenden Module aus diesem „Baukasten“ nutzen, sondern kann nach Bedarf die gewünschten Spezifikationen einsetzen.

Damit die nun vorgestellten Module in einer Applikation genutzt werden können, wird eine so genannte Middleware, genauer ein Applikationsserver benötigt. Dieser bietet zahlreiche Basisdienste wie verteilte Transaktionen, Sicherheitslösungen, Persistenz-Management etc., die für Unternehmensprozesse und Internet/Intranet-Anwendungen von entscheidender Bedeutung sind. Insbesondere wird dadurch eine klare Trennung zwischen den anwendungsspezifischen Programmteilen und den im Hintergrund erforderlichen Infrastrukturdiensten möglich. Dies bedeutet, dass die Lösung des Problems fokussiert werden kann, was wiederum zu einer Minimierung der Entwicklungskosten und der Fehleranfälligkeit des Programmcodes führt.

Ein Applikationsserver muss im Wesentlichen folgende Aspekte zur Verfügung stellen:

• Namensdienst, zum Registrieren (Binden) von entfernten Objekten

• Transaktionsmonitor, der verteilte Transaktionen unterstützt

• Sicherheitskomponenten, die eine Anmeldung am System ermöglichen

• EJB Container, der die Lebenszyklen der Enterprise JavaBeans koordiniert

• Servlet Container, der die Lebenszyklen von Servlets und JSPs koordiniert

Es ist allerdings branchenüblich, dass auch Funktionalitäten zur Verfügung gestellt werden, die nicht Bestandteil der Enterprise Java Spezifikation sind. Besonders nennenswert sind die folgenden Bereiche:

• Lastverteilung

• Ausfallsicherheit

• Entfernte Administration

• Entfernte Überwachung mit Hilfe von SNMP

Der Markt der Applikationsserver teilt sich in einen kostenfreien ⁴ und kostenpflichtigen Bereich ein. In den vergangenen Jahren war es üblich, mehrere zehntausend Euro für die Lizenzierung eines Applikationsservers zu investieren. Mittlerweile hat sich allerdings der

⁴ Lediglich das Produkt ist kostenfrei. In der Regel zahlt ein Unternehmen für den Support.

Open Source Bereich so weit auch in dem Enterprise Bereich etabliert, dass freie Lösungen durchaus unternehmenskritische Anwendungen betreiben.

Grundsätzlich ist die Aufteilung einer Enterprise Java Anwendung fest definiert (Crupi, 2001, S. 30f). Es handelt sich bei einer solchen Anwendung stets um ein mehrschichtiges verteiltes System mit definierten Schichtübergängen und Kompetenzbereichen. Weiterhin haben die verschiedenen Enterprise Java Komponenten feste Plätze innerhalb dieser Schichten (Abb. 4). Dies ermöglicht, dass auch eher unerfahrene Java Programmierer einen recht guten Leitfaden besitzen, damit eine Applikation nicht bereits in den Anfängen scheitert.

Enterprise Java Anwendungen zeichnen sich somit durch eine strikte Trennung der Schichten aus, die es ermöglicht, dass in Großprojekten zeitgleich an mehreren Teilen der Gesamtanwendung entwickelt werden kann. Zudem besitzt eine solche Anwendung den Vorteil, dass nahezu jede Schicht vollständig ausgetauscht werden kann, ohne dass es zu gravierenden Änderungen in den verbleibenden Schichten kommt. Beispielsweise könnte die komplette Architektur der Datenbankanbindung ersetzt werden durch die Persistenzlösung eines Drittanbieters (z.B. JBoss Hibernate). Die Darstellungs- und die Logikkomponenten würden im Kern unverändert bleiben und nahezu keine Modifikationen in den Schichtgrenzen besitzen 5 .

Eine Enterprise Java Anwendung ist weiterhin keine eigenständige Applikation, die selbständig lauffähig ist, sondern sie kann nur im Kontext eines Applikationsservers betrieben werden ⁶ .

Die folgende Grafik (Abb. 5) stellt einen kleinen Überblick der wichtigsten APIs dar, die von einem Applikationsserver zur Verfügung gestellt werden, um eine mehrschichtige verteilte Applikation zu implementieren. Alle im Folgenden aufgeführten APIs werden in den beiden Lösungen angewandt, um eine (technologisch, nicht funktional) möglichst umfassende Applikation jeweils zur Verfügung zu stellen. Eine Ausnahme bildet lediglich das JSSE API, da die Benutzung von HTTPS bereits Bestandteil des Applikationsservers ist.

Abb. 5 APIs der J2EE / Java EE Spezifikation

⁵ Damit dies auch wirklich so idealisiert funktionieren kann, bedarf es einiger Entwurfsmuster, die z.B. die Schichtübergänge von einander abstrahieren.

⁶ Siehe Erläuterung auf Seite 7

JAAS (Java Authentication and Authorization Service)

JAAS ermöglicht das Authentifizieren von Benutzern oder Subsystemen am Applikationsserver. Die Authentifizierung wird in Providermodule ausgelagert, so dass Passworte, SSL Client Zertifikate, digitale Fingerabdrücke, Single Sign On oder eigene Lösungen eingesetzt werden können, ohne dass die Details der jeweiligen Authentifizierungsvariante berücksichtigt werden müssen. Zusätzlich kann nach einer erfolgreichen Authentifizierung eine Autorisierung definiert werden, um eine Rechteverwaltung innerhalb der Applikation zu ermöglichen.

Dieses Vorgehen wurde von den in UNIX Systemen bekannten Pluggable Authentication Modules (PAM) adaptiert (Jendrock, 2006, S. 25).

JNDI (Java Naming and Directory Interface)

JNDI ist ein Standard API, das eine gemeinsame Schnittstelle für eine Vielzahl von Namensdiensten zur Verfügung stellt: DNS, LDAP, Active Directory, RMI Registry, COS Registry und vieles mehr. Treiber (so genannte Context Factories) wandeln zur Laufzeit die JNDI Aufrufe in die Protokollaufrufe des Namensdienstes um (Abb. 6). Somit ist es möglich, eine Java Anwendung zu schreiben, die ohne Quellcodemodifikationen sowohl eine LDAP Anbindung an das Microsoft Active Directory als auch gleichzeitig die Abfrage von DNS Servern erlaubt (Allamaraju & Avedal, 2002, S. 515-517).

Abb. 6 JNDI Schichtenmodell

CORBA (Common Object Request Broker Architecture) x x

CORBA ist eine Spezifikation der Object Management Group für Middleware Produkte, die das objektorientierte Schnittstellenkonzept umsetzen. Dabei können Dienste in Form von Objekten zur Verfügung gestellt werden, die über Rechner- und Sprachgrenzen hinweg in Anspruch genommen werden können. In der Regel wird für die entfernte Kommunikation der statische Methodenaufruf genutzt (Abb. 7). Dieses Prinzip geht davon aus, dass ein lokaler Stellvertreter (Client Stub) auf der aufrufenden Seite den Aufruf des Programms in Empfang nimmt und mit Hilfe eines

Object Request Brokers (ORB) den Aufruf an das entfernte Ziel schickt. Der Methodenaufruf wird dort vom lokalen ORB in Empfang genommen und an den serverseitigen Stellvertreter (Skeleton) weitergereicht, der den Aufruf an das endgültige Ziel delegiert. Die Ausführung der Methode und der Aufruf können somit auf verschiedenen Rechnern stattfinden. Als Protokoll wird in TCP/IP Netzwerken das Internet Inter-ORB Protocol (IIOP) genutzt.

CORBA bietet eine Vielzahl von Diensten an, die in der regulären J2EE Entwicklung allerdings nicht genutzt werden, da entsprechende eigene Dienste zur Verfügung gestellt werden. Klassisch werden zusätzlich noch der Object Transaction Service (OTS) für verteilte Transaktionen ⁷ genutzt und die Interface Definition Language (IDL) zur sprachenunabhängigen Beschreibung der Schnittstellen der entfernten Objekte (Roman, 2005, S. 683ff).

Abb. 7 statischer CORBA Aufruf

RMI-IIOP (Remote Method Invocation over IIOP)

RMI ist ein Standard API von Sun Microsystems zur Realisierung von entfernten Methodenaufrufen. Primär wurde dieses API mit dem Java Remote Method Protocol (JRMP) genutzt, das nur in homogenen Systemen eingesetzt werden kann. Aufgrund der deutlich einfacheren Handhabung gegenüber CORBA wurde dieses API mit der Option ausgestattet, das JRMP Protokoll gegen das IIOP Protokoll auszutauschen, um es somit auch für die Benutzung in heterogenen Systemen zur Verfügung zu stellen. Dabei wird das Delegationsmodell von CORBA übernommen. Der Dienstleister (Servant) ist hierbei nicht eine Subklasse des Skeletons, sondern der Skeleton aggregiert den Servant. Daher ist in diesem Fall nicht zwingend die Rede von einem Skeleton, sondern von dem so genannten Server Tie 8 . Enterprise JavaBeans bauen im Regelfall auf RMI-IIOP auf (Roman, 2005, S. 30ff).

⁷ Zusammen mit dem 2-Phasen-Commit-Protokoll (2PC).

⁸ Dies beruht darauf, dass die Komponente den Servant wie eine Krawatte umwickelt.

Java Servlets

Servlets sind kompilierte Java Klassen, die während der Ausführung dynamische Web-Seiten erzeugen. Durch Anfragen werden Servlets, sofern noch nicht laufend, erzeugt und gestartet. Diese bearbeiten die Anfrage und liefern eine Antwort an den Client zurück. Somit setzen Servlets das Request-/Response-Modell objektorientiert um. Die Ausgaben werden mit einer print Methode zum Client geschrieben, was die Erstellung von anspruchsvollen Seiten nahezu unmöglich macht (Allamaraju & Avedal, 2002, S. 21-41). Daher werden Servlets fast ausschließlich für Navigationslogik innerhalb der Web Anwendung genutzt (Front Controller) (Crupi, 2001, S. 172-183).

JSP (JavaServer Pages)

JavaServer Pages sind Webdokumente, die aus HTML- oder XML-Tags bestehen. Zusätzlich kann auch Java-Quellcode zur Generierung dynamischer Inhalte eingebettet werden. JavaServer Pages werden beim ersten Aufruf vom Servlet Container in ein Servlet umgewandelt und kompiliert (Abb. 8). Sobald eine JSP kompiliert wurde, ist es technisch einem Servlet gleichgestellt (Allamaraju & Avedal, 2002, S. 123-131).

Abb. 8 Abarbeitung einer JSP Anfrage

JMS (Java Message Service)

JMS ist ein API, das es ermöglicht, Nachrichten über einen so genannten Message Provider (Message Oriented Middleware, kurz MOM) auszutauschen. Es existieren dabei 2 verschiedene Paradigmen:

Beide Paradigmen haben gemeinsam, dass das Versenden und das Empfangen in verschiedenen Transaktionskontexten statt findet. Ist beispielsweise das Versenden der Nachricht Teil einer verteilten Transaktion und schlägt das Versenden fehl, so werden alle in diesem Transaktionskontext durchgeführten Änderungen rückgängig gemacht.

Tritt hingegen bei der Verarbeitung der Nachricht auf der Konsumentenseite ein Fehler auf, weil zum Beispiel die Datenbankaktionen fehlschlagen, wird das Empfangen der Nachricht nicht bestätigt und es findet eine erneute Zustellung statt (Redelivery On Failure) (Monson-Haefel & Chappel, 2001, S. 111-122).

EJB (Enterprise JavaBeans)

Enterprise JavaBeans sind Komponenten für die Erstellung multiuserfähiger, skalierbarer, plattformunabhängiger und transaktionaler Anwendungen. Sie besitzen genau zwei abstrahierende Komponenten, über die ein Client Zugriff auf die

Enterprise JavaBean Komponenten werden grundsätzlich in drei Kategorien unterteilt, um unterschiedliche Anwendungsgebiete innerhalb einer Anwendung zu adressieren (Roman, 2005, S. 28f):

⁹ Eine Ausnahme bilden die Message Driven Beans, die lediglich über das Empfangen einer Nachricht aufgerufen werden.

Message Driven Beans

Java Mail

JPA (Java Persistence API)

JTA (Java Transaction Service)

JSF (JavaServer Faces)

JDBC (Java DataBase Connectivity)

¹⁰ Zumindest solange SQL Anweisungen benutzt werden, die auf allen Systemen verstanden werden.