Vergleichsweise Implementierung und Bewertung von Software-Lösungen für mehrschichtige verteilte Applikationen im E-Commerce Bereich auf der Basis von J2EE 1.4 und Java EE 5

Inhalt

1. EINLEITUNG UND PROBLEMSTELLUNG

2. FUNKTIONALE ANFORDERUNGEN

3. NICHT-FUNKTIONALE ANFORDERUNGEN

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

5. REALISIERUNG DER ANWENDUNG MIT J2EE TECHNOLOGIEN
5.1. EINGESETZTE SOFTWARE
5.2. INTEGRATIONSSCHICHT (DATENBANKANBINDUNG)
5.3. GESCHÄFTSLOGIKSCHICHT
5.4. INTEGRATIONSSCHICHT (NACHRICHTENDIENST)
5.5. DARSTELLUNGSSCHICHT
5.6. EXPORT DER WEBSERVICES SCHNITTSTELLE

6. REALISIERUNG DER ANWENDUNG MIT JAVA EE TECHNOLOGIEN
6.1. EINGESETZTE SOFTWARE
6.2. INTEGRATIONSSCHICHT (DATENBANKANBINDUNG)
6.3. GESCHÄFTSLOGIKSCHICHT
6.4. INTEGRATIONSSCHICHT (NACHRICHTENDIENST)
6.5. DARSTELLUNGSSCHICHT
6.6. EXPORT DER WEBSERVICES SCHNITTSTELLE

7. VERGLEICH UND BEWERTUNG DER VORGEHENSWEISEN UND LÖSUNGEN
7.1. GEMEINSAMKEITEN DER LÖSUNGEN
7.2. UNTERSCHIEDE DER LÖSUNGEN
7.3. ANALYSE UND BEWERTUNG
7.3.1. TECHNISCHE ANALYSE UND BEWERTUNG
7.3.2. BETRIEBSWIRTSCHAFTLICHE ANALYSE UND BEWERTUNG

8. ZUSAMMENFASSUNG

I. GLOSSAR

II. ABBILDUNGSVERZEICHNIS

III. TABELLENVERZEICHNIS

IV. ABKÜRZUNGSVERZEICHNIS

V. LITERATURVERZEICHNIS

Stilkonventionen dieser Arbeit

Die folgenden Schriftkonventionen sind in dieser Arbeit zu Grunde gelegt:

- Kursivwird benutzt für
- erstmalig eingeführte und neue Begriffe
- im Kontext wichtige Begriffe
- wichtige Kommentare oder Zitate im Fließtext

- Konstante Schriftweite wird benutzt für
- wichtige Quellcodefragmente
- im Fließtext aufgeführte Java Schlüsselwörter
- im Fließtext aufgeführte Dateinamen

- unterstrichener Text wird benutzt für
- 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 anhandbetriebswirtschaftlicherundtechnischerKriterien 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.

Abbildung in dieser Leseprobe nicht enthalten

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.

Abbildung in dieser Leseprobe nicht enthalten

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 dashttpProtokoll aufgerufen werden kann, installiert.

Beide Komponenten greifen für die Bereitstellung ihrer jeweiligen Aufgaben auf Session Bean Komponenten¹ zurück, die alsentfernte Objekteregistriert 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.

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).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 Diagramm der Endausbaustufe

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 folgendenEnterprise Javagenannt) 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 einApplikationsserverbenö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 anwendungs- spezifischen Programmteilen und den im Hintergrund erforderlichen Infrastrukturdiensten möglich. Dies bedeutet, dass dieLösungdes 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

Open SourceBereich 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.

DieClientschicht bietet Zugriff auf die Applikation. Dies kann entweder ein Browser (Thin Client) sein, eine eigenständige Applikation (Fat Client), die in einer beliebigen Programmiersprache entwickelt wurde oder ein mobiles Endgerät, zum Beispiel ein Mobiltelefon.

DieDarstellungsschichtist oftmals gleichzusetzen mit der Webschicht, da die meisten Anwendungen über eine Webdarstellung bzw. einen WebService verfügen. Webkomponenten zeichnen sich dadurch aus, dass sie keine Anwendungslogik besitzen, sondern lediglich auf die Funktionalitäten der Geschäftslogikschicht zurückgreifen.

DieGeschäftslogikschichtist der Kern der Applikation und implementiert die fachlichen Anforderungen. Da eine strikte Trennung zwischen Logik und Darstellung erfolgt, kann diese Schicht unverändert bleiben, wenn sich die Art der Darstellung ändert.

Die Integrationsschicht abstrahiert den Zugriff auf Ressourcen wie Datenbank, Fremd- und Altsysteme. Da die Geschäftslogikkomponenten lediglich durch diese hier definierten Komponenten Zugriff auf die Unternehmensressourcen erhalten, kann diese Schicht nahezu vollständig ausgetauscht werden, ohne dass es Einfluss auf Darstellung und Logik hat.

DieRessourceschichtbeinhaltet die zumeist bereits vorhandenen Systeme eines Unternehmens, die im Rahmen der Anwendung nachgenutzt werden. Zumeist ist dies eine relationale Datenbank oder ein Host System.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4 J2EE Schichten

Abbildung in dieser Leseprobe nicht enthalten

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⁵.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5 APIs der J2EE / Java EE Spezifikation

- 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 bekanntenPluggable 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 genannteContext 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 dasMicrosoft Active Directoryals auch gleichzeitig die Abfrage von DNS Servern erlaubt (Allamaraju & Avedal, 2002, S. 515-517).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6 JNDI Schichtenmodell

- CORBA (Common Object Request Broker Architecture)

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

Abbildung in dieser Leseprobe nicht enthalten

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 dasInternet 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 derObject Transaction Service (OTS)für verteilte Transaktionen⁷ genutzt und dieInterface Definition Language (IDL)zur sprachenunabhängigen Beschreibung der Schnittstellen der entfernten Objekte (Roman, 2005, S. 683ff).

Abbildung in dieser Leseprobe nicht enthalten

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 demJava 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 einemSkeleton, sondern von dem so genanntenServer Tie⁸. Enterprise JavaBeansbauen im Regelfall aufRMI-IIOPauf (Roman, 2005, S. 30ff).

- 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).

Abbildung in dieser Leseprobe nicht enthalten

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:

1. Point To Point (P2P)basiert auf dem Prinzip der Nachrichtenwarteschlangen (Queues). Dabei versendet ein Sender eine Nachricht an eine Warteschlange. Die eingegangene Nachricht wird nun vongenau einemEmpfänger verarbeitet, selbst wenn mehrere Empfänger registriert sind. Ist kein Empfänger beim Eintreffen der Nachricht registriert, wird die Nachricht bis zum Erreichen eines Zeitlimits gespeichert. Diese Kommunikationsform wird vorwiegend für redundant ausgelegte Systeme angewandt, bei denen wichtig ist, dass die anstehende Aktiongenau einmalausgeführt wird (Abb. 9).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9 Point to Point Paradigma

- Publisher Subscriber (PubSub)basiert auf dem Anmelde-Versender-Prinzip, bei dem die eingegangene Nachricht an einTopicgesendet wird. Alle dort registrierten Abonnementen empfangen eine Kopie der Nachricht (Abb. 10). Ist kein Abonnement beim Eintreffen der Nachricht registriert, geht die Nachricht unbearbeitet in die so genannteDead Message Queue, dem Speicherort für nicht konsumierte Nachrichten. Alternativ kann sich ein Abonnement „dauerhaft einschreiben“ (Durable Subscription), um das System darüber zu informieren, dass es Nachrichten, die in der Abwesenheit eingehen, zu speichern.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 10 Publisher Subscriber Paradigma

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 eigentliche EJB erhält⁹. Man spricht im Allgemeinen dabei von den so genanntenSichtenauf Enterprise Java Beans. Die„entferne Sicht“erlaubt es, eine EJB Komponente in einem heterogenen, verteilten System über das Netzwerk aufzurufen, während die„lokale Sicht“den Aufruf innerhalb des Applikationsservers ohne die Verwendung des Netzwerks ermöglicht (Abb. 12). Eine Sicht wird dabei stets durch die folgenden zwei Objekte definiert (DeMichiel, 2003, S. 53-58).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 11 EJB Technologiestack

Abbildung in dieser Leseprobe nicht enthalten

Abb. 12 EJB Sichten

EJBObject. Dieses delegiert die Aufrufe dann an die EJB (Roman, 2005, S. 37-48).

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

oSession Beans

Session Beans beinhalten dieGeschäftslogik, also die fachlichen Anforderungen einer Applikation.

Je nach Einsatz der Session Bean kann unterschieden werden zwischen zustandslosen Session Beans (Stateless Session Beans) und zustandsbehafteten Session Beans (Stateful Session Beans).

Zustandslose Session Beanswerden im Applikationsserver in einem Objektpool verwaltet und sind daher gut skalierbar, da die Größe und das Verhalten des Objektpools vom Administrator definiert werden kann. Die Session Bean wird bei der Ankunft eines Methodenaufrufes kurzzeitig den Objektpool verlassen und die Methode ausführen, um unmittelbar danach wieder in den Pool zurückzukehren, um für weitere Aufrufe zur Verfügung zu stehen (Abb. 13) (Roman, 2005, S. 81f). Somit kann eine bestehende EJB Applikation durch geeignete Konfigurationsänderungen den steigenden Anforderungen der Gesamtanwendung ohne Quellcodemodifikation gerecht werden. Allerdings müssen bei jedem Methodenaufruf alle benötigten Informationen erneut übergeben werden. Sie eigenen sich aufgrund ihrer Zustandslosigkeit besonders für redundante Systeme (Cluster), da keine Datenreplizierung notwendig ist.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 13 entfernter Aufruf einer zustandslosen Session Bean

Zustandsbehaftete Session Beansstehen einem Client exklusiv zur Verfügung und können ihren Zustand aufrechterhalten. Somit wird sichergestellt, dass bei jedem Aufruf der aktuelle Zustand in der Session Bean vorhanden ist (Abb. 14). Zustandsbehaftete Session Beans können aufgrund der Zustandsspeicherung nicht in einem Objektpool gehalten werden (Roman, 2005, S. 85f).

Sie sind somit grundsätzlich weniger skalierbar und ein Serverausfall innerhalb eines Clusters ist schwieriger zu kompensieren, da der Applikationsserver während der aktiven Zeit einer zustandsbehafteten Session Bean den Zustand auf weitere Knotenrechner des Clusters replizieren muss. Daher erzeugen sie eine gewisse Grundlast, die dazu führt, dass in der Praxis der Großteil der Anwendungslogik mit Hilfe von zustandslosen Session Beans entwickelt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 14 entfernter Aufruf einer zustandsbehafteten Session Bean

Um den Speicherverbrauch dennoch etwas zu optimieren, können zustandsbehaftete Session Beans kurzzeitig aus dem Speicher entnommen werden, sofern sie sich nicht gerade in der Ausführung einer Methode befinden. Das bedeutet, dass der aktuelle Zustand in die Datenbank oder auf das lokale Dateisystem abgelegt und die Instanz wieder freigegeben wird, wenn ein Client über einen längeren Zeitraum die Session Bean nicht genutzt hat. Ruft der Client nach einer solchen Passivierung eine Methode auf, so wird die Session Bean wieder reaktiviert. Dabei wird eine neue EJB erzeugt, diese mit dem EJBObject verknüpft und der alte Zustand rekonstruiert. Dies geschieht für den Client völlig transparent.

Die lokale oder entfernte Referenz auf eine Session oder Entity Bean wird in der Regel mit Hilfe des Namensdienstes zur Verfügung gestellt, in dem die Komponenten unter einem eindeutigen Namen registriert sind.

- Entity Beans

Mit Hilfe von Entity Beans werden diepersistenten Dateneiner Applikation in Form von Objektmodellen definiert und abstrahieren den Zugriff auf die Datenbank. Es kann angegeben werden, ob der Applikationsserver die Persistenzanbindung realisieren soll (Container Managed Persistence) oder ob der Entwickler die Datenbankabfragen in der Entity Bean in Form von SQL Statements implementiert (Bean Managed Persistence).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 15 entfernter Aufruf einer Entity Bean

Für die Erstellung von Beziehungen untereinander (z.B. Kunde-Hat-Adressen) stellt die Spezifikation deklarative Beziehungen zur Verfügung (Container Managed Relations, kurz CMR), die beliebige Kardinalitäten und auch ein kaskadierendes Verhalten beim Entfernen von Datensätzen besitzen können.

Für die Suche nach bestimmten Entitäten anhand von Suchkriterien wird eine eigene Metasprache definiert (EJB-Query Language, kurz EJB-QL), die zur Laufzeit in das entsprechende SQL für die Zieldatenbank umgewandelt wird (DeMichiel, 2003, S. 235f). Somit kann gewährleistet werden, dass während der Entwicklung nicht ein spezielles Datenbanksystem zu Grunde gelegt werden muss, was vor allem bei Lösungen für einen Massenmarkt ein signifikanter Vorteil ist.

J2EE Clients (Session Beans, Servlets) werden also nicht direkt SQL Anweisungen an die Datenbank senden, sondern statt dessen eine Zustandsänderung der Entity Bean erzeugen, um darüber die Daten der Datenbank zu aktualisieren (Abb. 15). Wie häufig die Zustandsänderung der Entity Beans in die Datenbank publiziert wird und ob Änderungen, die direkt in der Datenbank gemacht wurden (z.B. über Drittanwendungen außerhalb des Applikationsservers), auch eine Aktualisierung der Entity Beans zur Folge haben, wird ebenfalls deklarativ festgelegt (Roman, 2005, S. 119ff).

- Message Driven Beans

Message Driven Beans dienen derasynchronen Abarbeitungvon Ereignissen und können nicht direkt aufgerufen werden. Sie besitzen folglich keinEJBHomeund keinEJBObject. In der Regel benutzen sie JMS, um Nachrichten asynchron zu konsumieren. In der J2EE Spezifikation 1.4 dürfen aber auch herstellerabhängige APIs genutzt werden. So ist es zum Beispiel auch möglich, eine Email Adresse mit einer Message Driven Bean zu verknüpfen (DeMichiel, 2003, S. 333).

Message Driven Beans unterstützen beide Nachrichten Paradigmen (Publisher Subscriberbzw. Point to Point) und werden wie zustandslose Session Beans in einem Objektpool verwaltet. Muss eine ankommende Nachricht konsumiert werden, verlässt eine Message Driven Bean kurzzeitig den Pool, arbeitet die Nachricht ab und begibt sich unmittelbar danach wieder zurück in den Pool, um für weitere Nachrichten zur Verfügung zu stehen (Abb. 16) (Roman, 2005, S. 217ff).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 16 Nachrichtenempfang einer Message Driven Bean

- Java Mail

Der Versand von E-Mails mit dem SMTP Protokoll und der Empfang mit dem POP3 bzw. dem IMAP Protokoll wird mit Hilfe dieses APIs ermöglicht (Allamaraju & Avedal, 2002, S. 255-258). Innerhalb eines Applikationsservers ist es den EJB Komponenten allerdings nicht gestattet, eine direkte Socket Kommunikation über die Standardports (POP3:110, IMAP:143 bzw. SMTP:25) herzustellen (DeMichiel, 2003, S. 563). Der Applikationsserver stellt daher die entsprechenden Mail Sitzungen zur Laufzeit zur Verfügung, die der Administrator dafür zuvor registriert haben muss.

- JPA (Java Persistence API)

JPA kapselt den Zugriff auf die Datenbank in Form eines Persistenzmechanismus, der in der Lage ist, Objekte im Speicher der virtuellen Maschine auf Datenbanktabellen abzubilden. Verändert sich zum Beispiel der Zustand eines Objekts innerhalb der virtuellen Maschine, so wird das JPA diesen neuen Zustand in die Datenbank schreiben.

Dieses Prinzip entspricht grundsätzlich der Idee der Entity Beans, allerdings deutlich leichtgewichtiger. Während Entity Beansselbstdie Fähigkeit besitzen, sich persistent abzubilden, existiert bei JPA ein so genannterEntity Manager, der die CRUD (Create-Read-Update-Delete) Operationen zur Verfügung stellt (Burke

& Monson-Haefel, 2006, S. 75-82), um die Entitäten in der Persistenzschicht abzubilden.

- JTA (Java Transaction Service)

In den meisten J2EE Applikationen müssen Zugriffe auf verschiedene unabhängige Systeme (mehrere Datenbanken, Fremdsysteme usw.) zu einer atomaren Aktion zusammengefasst werden, um einen konsistenten Endzustand zu gewährleisten. Hierfür wird das JTA API zur Verfügung gestellt, das sowohl lokale Transaktionen (TX) als auch verteilte Transaktionen (XA) unterstützt.

Transaktionen zeichnen sich dadurch aus, dass sie die so genannten ACID Eigenschaften erfüllen. Diese sagen aus, dass Aktionen, die innerhalb einer Transaktion durchgeführt wurden,atomar,konsistentunddauerhaftundisoliertdurchgeführt werden müssen:

- Atomicity
- Transaktionen werden vollständig oder gar nicht durchgeführt.

- Consistency
- War die Datenbank vor der Transaktion konsistent, so ist sie es auch nach der Transaktion

- Isolation
- Transaktionen beeinflussen sich nicht gegenseitig, sie sind von einander isoliert

- Durability
- Das Ergebnis der Transaktion wird dauerhaft gespeichert.

Wird JTA in der EJB Schicht genutzt, gibt es zudem die Möglichkeit, die Transaktionssteuerung deklarativ (Container Managed Transactions, kurz CMT) in einer XML Datei oder alternativ im Java Programmcode (Bean Managed Transactions, kurz BMT) zu definieren (DeMichiel, 2003, S. 363).

In der Regel wird die deklarative Variante bevorzugt, da somit die logische Implementierung von der transaktionalen Steuerung getrennt wird, was zu einer besseren Wartbarkeit der Applikation führt.

CMT stellt dafür sechs verschiedene Transaktionsattribute zur Verfügung, die auf Methodenebene vergeben werden (Roman, 2005, S. 317-322). Teilweise stammen diese bereits aus der Microsoft COM+ Technologie:

- REQUIRED
- Wenn beim Aufruf der Methode noch keine Transaktion gestartet wurde, wird nun eine gestartet. Ist allerdings beim Aufruf der Methode eine aktive Transaktion vorhanden, wird diese Methode mit in die Transaktion aufgenommen.

- REQUIRES NEW
- Es wird immer beim Aufruf dieser Methode eine neue Transaktion begonnen. Ist bereits eine aktive Transaktion vorhanden, wird diese für die Dauer der neuen Transaktion suspendiert und danach weitergeführt. Das Ergebnis der neuen Transaktion hat keinen Einfluss auf die bereits vorhandene Transaktion.

- MANDATORY
- Es muss bereits eine aktive Transaktion vorhanden sein, wenn diese Methode aufgerufen wird. Existiert beim Aufruf keine aktive Transaktion, wird eineExceptiongeworfen.

- NOT SUPPORTED
- Diese Methode unterstützt keine Transaktion. Ist beim Aufruf dieser Methode eine aktive Transaktion vorhanden, so wird diese für die Dauer des Methodenaufrufs suspendiert und danach weitergeführt.

- SUPPORTS
- Diese Methode unterstützt Transaktionen. Ist beim Aufruf dieser Methode eine aktive Transaktion vorhanden, so wird diese Methode mit aufgenommen. Existiert hingegen keine aktive Transaktion, wird die Methode ohne Transaktion ausgeführt.

- NEVER
- Diese Methode unterstützt keine Transaktionen. Ist beim Aufruf dieser Methode eine aktive Transaktion vorhanden, so wird eineExceptiongeworfen.

Transaktionen im J2EE Umfeld beziehen sich somit nicht ausschließlich auf Datenbank Transaktionen, sondern sind deutlich abstrakter zu sehen, da nahezu alle Aktionen in den genutzten Systemen zu Transaktionen zusammengefasst werden können.

Weiterhin ist anzumerken, dass keine verschachtelten Transaktionen (Nested Transactions) unterstützt werden, sondern lediglich flache Transaktionsstrukturen (Flat Transactions). Dies beruht auf dem Wunsch, möglichst vielen Systemen die

Möglichkeit zu bieten, in das J2EE Transaktionsverhalten integriert zu werden (DeMichiel, 2003, S. 356).

- JSF (JavaServer Faces)

Dieses API bietet eine Möglichkeit, eine Webanwendung mit Hilfe desModel- View-ControllerPrinzips zu realisieren. Dabei wird erreicht, dass die Darstellung von der Logik getrennt werden kann, was zu einer deutlich besseren Wartbarkeit des Quellcodes führt. Ein im API integrierter Controller (FacesController) steuert den Programmfluss der einzelnen Web Komponenten.

Außerdem bietet JSF eine Vielzahl von XML Elementen, mit denen oft genutzte Aktionen gekapselt werden wie zum Beispiel das Aufbauen und Visualisieren von Tabellen mit Listeninhalten oder das Validieren von Eingabefeldern(Jendrock, 2006, S. 20).

- JDBC (Java DataBase Connectivity)

Der Zugriff auf Datenbanksysteme wird mit Hilfe von JDBC abstrahiert, so dass das zu Grunde liegende Datenbanksystem weitestgehend offen bleiben kann¹⁰. Ähnlich wie bei JNDI wird auch hier das eigentliche System durch einen Treiber eingebunden, der die generischen JDBC Aufrufe so umwandelt, dass die Datenbank die Aufrufe verarbeiten kann (Abb. 17) (Allamaraju & Avedal, 2002, S. 158f).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 17 JDBC Schichtenmodell

Wird JDBC innerhalb eines Applikationsservers eingesetzt, werden Verbindungen zur Datenbank nicht selbst hergestellt (DriverManager.getConnection), sondern mit Hilfe einesConnectionpoolsvom Applikationsserver zur Verfügung gestellt, der zuvor vom Administrator konfiguriert und zur Verfügung gestellt wurde. Ferner nutzt das JPA API für die Ausführung der generierten SQL Statements dieses API.

- JAX-RPC (Java API for XML-based Remote Procedure Calls)

Das JAX-RPC API ermöglicht die Bereitstellung und den Aufruf von Remote Procedure Calls auf XML Basis. Dafür wird in der Regel das SOAP Protokoll zur Verfügung gestellt. JAX-RPC unterstützt den statischen Methodenaufruf mit Stubs (Abb. 18) sowie den dynamischen Aufruf, bei dem die Aufrufdaten zur Laufzeit ermittelt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 18 statischer Aufruf eines WebServices mit JAX-RPC

Ab Java EE 5 wird JAX-RPC abgelöst durch dasJava API for XML WebServices (JAX-WS), das sich vor allem dadurch auszeichnet, dass es eine einfachere Verwendung ermöglicht (Jendrock, 2006, S. 21).

- JSSE (Java Secure Socket Extension)

Dieses API ermöglicht eine sichere Kommunikation überTransport Layer Security (TLS)bzw. Secure Sockets Layout (SSL), also zum Beispiel die Benutzung von HTTPS, LDAPS, SMTPS usw. (Jendrock, 2006, S. 906).

5. Realisierung der Anwendung mit J2EE Technologien

Im Folgenden wird die Realisierung der J2EE Lösung anhand von ausgewählten Komponenten exemplarisch dargestellt. Dabei entspricht die Reihenfolge der Unterkapitel der Vorgehensweise bei der Entwicklung der Software.

Begonnen wird mit der Integration der Persistenzschicht mit Hilfe der CMP Entity Beans Technologie. CMP Entity Beans werden von Session Beans genutzt, die ihrerseits die Geschäftslogikschicht abbilden. Die Kommunikation zwischen diesen beiden Komponenten wird in Großprojekten nochmals durch das Entwurfsmuster derData Access Objects(Crupi, 2001, S. 390-396) entkoppelt, die durch eineAbstract Factory(Gamma, 1995, S. 87-95) eingebunden werden. In der aktuellen Arbeit wird eine Entkopplung dieser Schichten aufgrund nicht ändernder Anforderungen nicht implementiert.

Im darauf folgenden Schritt wird die Integration der Nachrichtensoftware (Message Oriented Middleware, kurz MOM) vorgestellt, die alle Nachrichten, die eine Session Bean sendet, empfängt. Eine registrierte Message Driven Bean wird die eingegangenen Nachrichten asynchron konsumieren und weiterverarbeiten.

Im nächsten Abschnitt wird der Entwurf der Webanwendung dargestellt. Hierbei wird konsequent dasModel-View-ControllerPrinzip mit J2EE Technologien in einem selbst entwickelten Framework umgesetzt.

Die von der Kernfunktion gesondert zu betrachtende Möglichkeit, Teile der Applikation als WebService zur Verfügung zu stellen, wird im letzten Kapitel behandelt. Es wird kurz aufgezeigt, mit welchen Hilfsmitteln WebServices zur Verfügung gestellt werden und welche Technologien eingesetzt werden, damit eine Microsoft .NET C# Anwendung diesen WebService konsumieren kann.

Zu Beginn eines Kapitels wird ein Komponentendiagramm dargestellt, das anzeigt, welcher Teil der Applikation analysiert wird, um eine bessere Orientierung des Lesers zu ermöglichen.

Für alle folgenden Kapitel gilt, dass ein grundlegendes Verständnis für die Lösung erzeugt werden soll, um somit die Unterschiede bei der Realisierung mit Java EE Technologien erkennen zu können. Daher werden tiefergehende technische Details weitestgehend ausgeklammert.

5.1. Eingesetzte Software

Als Grundlage dient die aktuelleJava 2 Standard Edition 1.6von Sun Microsystems (http://java.sun.com). Als Middleware System wird einJBoss Application Server 4.2.2der JBoss Group (http://www.jboss.org) eingesetzt, der über einen integrierten Transaktionsmonitor und über einen eingebetteten Message Provider verfügt. Als relationales Datenbankmanagementsystem wird eineOracle 10 XEgenutzt (http://www.oracle.com).

Die vorgestellte Software wird auf einem Sun Solaris 10 (http://www.sun.com) Betriebssystem installiert.

[...]

---

¹ Siehe Kapitel 4, Seite 14

² Siehe Kapitel 4, Seite 16

³ Siehe Kapitel 4, Seite 18

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

⁵ 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

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

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

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

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