Vergleich der Anforderungen an EJB 3.xx für Glassfish, Websphere, JBOSS und WebLogic

Aus Winfwiki

Name der Autoren:	Mario Grundmann, Philipp Hoy, Daniel Niesner, Thomas Ahcin
Titel der Arbeit:	"Vergleich der Anforderungen an EJB 3.xx für Glassfish, WebSphere, JBOSS und WebLogic"
Hochschule und Studienort:	FOM Essen

1 Inhaltsverzeichnis

Inhaltsverzeichnis 1 Inhaltsverzeichnis 2 Abkürzungsverzeichnis 3 Abbildungsverzeichnis 4 Tabellenverzeichnis 5 Einleitung 6 Grundlagen 6.1 Webbasierte Middleware 6.2 Application Server 6.3 EJB und Version 3.xx 6.3.1 Komponenten 6.3.1.1 Entity Bean 6.3.1.2 Persistenz 6.3.1.3 Session Bean 6.3.1.4 Klassenarten 6.3.1.5 Message Driven Bean 6.3.1.6 Annotationen 6.3.1.7 Web Services 6.3.2 Transaktionen 6.3.2.1 ACID-Eigenschaft 6.3.2.2 Zugriffsproblematik 6.3.2.3 Zugriffsattribute 6.3.3 EJB QL 6.3.4 Neuerungen 7 Spezifische Anforderungsanalyse 7.1 GlassFish 7.1.1 Hohe Verfügbarkeit und Skalierbarkeit 7.1.2 Hochgradige Performance 7.1.3 Einfache Konfiguration über Profile 7.1.4 Interoperabilität mit .NET 7.1.5 JBI Ready 7.1.6 Ausgeprägte Kommunikationsdienste 7.1.7 Zusammenspiel mit Enterprise Java Beans 7.2 JBoss 7.2.1 Konfiguration 7.2.2 Clustering 7.2.3 Performance 7.2.4 Web Service mit JBoss 7.2.5 Datenbank in JBoss 7.2.6 Zugriffsrechte 7.2.7 Besonderheiten 7.3 Websphere 7.3.1 Varianten 7.3.2 WAS und JAVA 7.3.3 WebSphere goes Cloud Computing 7.3.4 Unterstützte Hard- und Software 7.3.5 Prozessarchitektur 7.3.6 WAS und Persistenz 7.4 WebLogic 7.4.1 Übersicht über Versionen und Umfang 7.4.2 Anforderungen an Hardware 7.4.3 Anforderungen an Software 7.4.4 JDK / Entwicklungsumgebungen 7.4.5 Interaktion mit EJB 7.4.5.1 Transaktionen 7.4.5.2 EJB Klassen 7.4.5.3 WebLogic und EJBGen 7.4.5.4 WebLogic EJB-QL und CMP 8 Fazit und Ausblick 9 Fußnoten 10 Literatur- und Quellenverzeichnis

2 Abkürzungsverzeichnis

Abkürzung	Beschreibung
API	Application Programming Interface
BPEL	Business Process Execution Language
CMP	Container Managed Persist
EIS	Enterprise Information System
EJB	Enterprise JavaBeans
EJB QL	Enterprise JavaBeans Query Language
ESB	Enterprise Service Bus
FTP	File Transfer Protocol
GUI	Graphical User Interface
HADB	High-Availability Database
HP	Hewlet Packard
HTTP	Hypertext Transfer Protocol
HTTPS	Hypertext Transfer Protocol Secure
IEP	Intelligent Event Processor
IIOP	Internet Inter-ORB Protocol
JAAS	Java Authentication and Authorization Service
JAVA EE	Java Platform, Enterprise Edition
JAX	Java, Apache und XML (Akronym)
JBI	Java Business Integration
JDBC	Java Database Connectivity
JDK	Java Development Kit
JEE	siehe JAVA EE
JKS	Java Key Store
JMS	Java Message Service
JPA	Java Server Pages
JVM	Java Virtual Machine
NMR	Normalized Message Router
NSS	Network Security Services
OLTP	Online Transation Processing
Open MQ	Open Message Queue
ORM	Object Relational Mapping
PBC	Protocol Binding Component
RMI	Remote Method Invocation
SMTP	Simple Mail Transfer Protocol
SOAP	Simple Object Access Protocol
SQL	Structured Query Language
UDDI	Universal Description, Discovery and Integration
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
WAS	WebSphere Application Server
WFC	Windows Communication Foundation
WSDL	Web Service Description Language
WSIT	Web Service Interoperability Technology
XML	Extensible Markup Language
XSL	Extensible Stylesheet Language
XSLT	Extensible Stylesheet Language Transformation

3 Abbildungsverzeichnis

Abb.-Nr.	Beschreibung
1	3 Schichten Architektur
2	Webservice-Architektur
3	GlassFish-Logo
4	Speicherreplikation und Komplikationshandling
5	Interaktion von Metro und .NET
6	JBI-Standard in GlassFish
7	Nachrichtenversand über den Publish-Subscribe-Ansatz
8	JBOSS-Logo
9	WebSphere-Logo
10	WebSphere Appilcation Server Prozessarchitektur

4 Tabellenverzeichnis

Tab.-Nr.	Beschreibung
1	Zuordnung der Klassenarten zu den Bean-Typen
2	Zugriffsproblematiken bei Transaktionsverarbeitung
3	Zugriffsattribute von container-managed Transactions
4	Konfigurationsprofile eines Glassfish v2 Anwendungsservers
5	Konfigurationen der JBOSS Installation
6	WebLogic in 32-Bit-Varianten
7	WebLogic in 64-Bit-Varianten

5 Einleitung

  "Standards ... [sind] Objekte, die innerhalb eines bestimmten Anwenderkreises akzeptiert und gemeinsam
  genutzt werden. ... Die Objekte der Standardisierung sind Hardware- oder Softwarekomponenten, wobei
  letztere Standards für Daten, Funktionen und Prozesse umfassen."[1]

Im Rahmen eines Forschungsprojektes der Firma Sun entstand im Jahre 1993 die Programmiersprache Java. Der ursprüngliche Grund für die Entwicklung einer neuen Programmiersprache war die Geburt des World Wide Web einerseits, voranging jedoch der Boom, den dieses zu jener Zeit erfuhr. Es wurde nach einer Möglichkeit gesucht, Internetanwendungen zu entwickeln, die ebenso leistungsstark wie flexibel und kompatibel waren. Vor diesem Hintergrund wurde das Forschungsprojekt, auf dem die Existenz Javas beruht, ins Leben gerufen.^[2] Seit seiner Entstehung wurde Java permanent weiterentwickelt und verbessert. Über mehrere Versionen hinweg wurde die Programmiersprache, die in ihrem Ursprung für die Entwicklung von Internetanwendungen gedacht war, derart überarbeitet, ergänzt und verbessert, dass mit ihr heutzutage weit mehr entwickelt wird, als "lediglich" Applikationen, deren Anwendung vorranging an das World Wide Web gebunden ist. Nichts desto Trotz ist Java vor eben dem Hintergrund entstanden und ist daher "vor diesem .. zu betrachten und .. untrennbar mit dem Internet und seinen Erfordernissen verbunden."^[3] Wegen seiner objektorientierten Architektur und seiner mit den Weiterentwicklungen verbundenen Leistungsstärke ist Java mittlerweile jene Programmiersprache, die in den USA flächendeckend als Standard an den Universitäten eingesetzt wird. Auch an deutschen Universitäten und Hochschulen konnte Java sich weitestgehend als Lehrgegenstand und -Werkzeug etablieren.^[4]

Wegen seiner vielseitigen Einsatzmöglichkeiten fand Java sehr schnell Anklang in der Branche der Anwendungsentwicklung, was dazu beigetragen hat, dass sich - neben der Firma Sun als Vater der Sprache - mehrere Communities bildeten, die bis heute ihren Beitrag zur weiteren Verbesserung und Leistungssteigerung von Java leisten. Über mehrere Versionen hinweg konnten sogar Standardisierungen formuliert und in Java-eigenen Klassen realisiert werden. Ein Teil dieser Klassen zielt auf die Entwicklung objektorientierter und komponentenbasierter verteilter Systeme ab und übernimmt Standardaktionen wie beispielsweise die Bereitstellung von Daten oder die Kommunikation zwischen verschiedenen Anwendungen. Diese Java-Klassen werden unter der Bezeichnung "Enterprise JavaBeans" zusammengefasst und stehen der Welt der Anwendungsentwicklung als mittlerweile fester Bestandteil des JDK (Java Development Kit) zur Verfügung.^[5]

Oftmals macht die Realisierung verteilter Systeme gleichermaßen den Einsatz von Application Servern (zu deutsch "Anwendungsserver") notwendig, um die Geschäftslogik, die mittels der betrieblich eingesetzten Anwendungen abgebildet wird, zentral zugänglich zu machen. Diese Abhandlung befasst sich mit der Thematik des Einsatzes von Anwendungsservern in Verbindung mit Java-basierten Anwendungen. Nach der Darstellung einiger Grundlagen in Bezug auf Anwendungsserver einerseits und den bereits angesprochenen Enterprise JavaBeans andererseits, werden die vier Anwendungsserver "GlassFish", "Websphere", "JBOSS" und "WebLogic" genauer beleuchtet. Anhand der hieraus gewonnenen Erkenntnisse werden zunächst fallspezifische Anforderungen formuliert, bevor in der Schlussbetrachtung ein vergleichendes Resumé aufgestellt wird. Die Ausführungen werden durch ein Fazit und einen ergänzenden Ausblick in die Zukunft der Anwendungsserver bzw. die Zukunft von Java, insbesondere der Enterprise JavaBeans, abgeschlossen.

6 Grundlagen

6.1 Webbasierte Middleware

EJB gehört zu der Gruppe der so genannten Webbasierten Middleware. Middlewareprodukte werden seit Beginn der 90er Jahre eingesetzt. Sie grenzen sich von Ihren eigentlichen Vorgängern, den im erweiterten Sinn ersten Middlewareprodukten, den TP-Monitoren, dahingehend ab, dass sie nicht nur auf einem Rechner unter einem Betriebssystem zu laufen hatten, sondern wurden durch die Client-Server Technologie vor höhere Aufgaben gestellt. Im nächsten Schritt, dem aktuellen Umbruch der Anwendungslandschaften weg von der Client-Server Technologie hin zu webbasierten Anwendungen stellt den Bereich der Middleware vor neue Herausforderungen.^[6]

Die aktuell drei relevanten Gruppen von Webbasierter Middleware sind:

• COBRA

• EJB

• .NET ^[7]

Ein Application Server stellt Dienste in kompakter Form zur Verfügung. Ein Java EE konformer Application Server muss eine Vielzahl von definierten Diensten implementiert haben. Dabei ist im Standard nur die Grundmenge der Programmierschnittstellen (API) festgelegt. Allerdings gibt es keine Vorgaben darüber, wie diese zu implementieren sind. Je nachdem welche Dienste zum Einsatz kommen, bietet der Application Server verschiedene Kommunikationsprotokolle an, wie zum Beispiel HTTP, HTTPS, RMI/IIOP, oder SOAP over HTTP, um zwischen Clients und EJB-Anwendungen Daten austauschen zu können. Darüber hinaus kann ein Anbieter auch weitere Dienste oder Protokolle bereitstellen.^[8]

6.2 Application Server

  "Läuft ein Subsystem, das einen bestimmten Service für a priori unbekannte Clients zur Verfügung stellt,
  auf einer Servermaschine, so nennen wir dieses Subsystem Server. Der Server ist die Ausführung der
  Servicesoftware auf einer einzelnen Maschine."[9]

Ein Application Server bzw. Anwendungsserver sind ein zentraler Bestandteil umfassender Informationsysteme. Ihre Aufgabe besteht darin, eine Laufzeitumgebung bereit zu stellen, innerhalb derer Transaktionsprogramme ausgeführt werden können. Aus diesem Grund werden Anwendungsserver auch häufig als "Transaktionsmonitor"^[10] bezeichnet. Anwendungsserver bzw. Transaktionsmonitore werden im Regelfall immer dann eingesetzt, wenn einen große Benutzergruppe zeitgleich eine Anwendung nutzt. Ein derart geschnürtes Paket, bestehend aus Transaktionsmonitor und entsprechenden Anwendungen, wird aufgrund seiner Zweckmäßigkeit auch als "Transaktionssystem"^[10], die Anwendungen hieraus für sich als "OLTP-Anwendungen" (Online Transaction Processing)^[10] bezeichnet. Die Beschaffenheit der Bedienoberfläche bzw. GUI (Graphical User Interface) solcher Anwendungen ist in den Regelfällen entweder direkt manipulativ, formularbasiert oder kommandozeilenbasiert. Über die Bedienoberflächen wird der größte Teil der vom Benutzer getätigten Eingaben verarbeitet. Hierbei können beispielsweise Plausibilitätsprüfungen und andere Zusammenhänge abgearbeitet werden. In den meisten Fällen ist die räumliche Verteilung der Benutzer, die auf ein Transaktionssystem bzw. die darin enthaltenen OLTP-Anwendungen zugreifen, relativ großflächig. Das Aufgabengebiet eines Transaktionsmonitors setzt sich aus den folgenden Teilbereichen zusammen:

• Transaktionsverwaltung
• Prozessverwaltung
• Kommunikation
• Objekt- und Komponentenverwaltung

Den Mittelpunkt des Aufgabengebietes stellt die Transaktionsverwaltung dar, woraus sich auch der Name "Transaktionsmonitor" ableitet. Jede Transaktion setzt sich hierbei aus einer Folge zusammengehöriger Operationen zusammen. Aufgabe des Transaktionsmonitors ist es nun, alle anstehenden Transaktionen zu koordinieren und abzuwickeln. Die Koordination schließt das Durchführen miteinander verknüpfter Änderungen an verschiedenen Ressourcen ein, wobei die jeweiligen Ressourcenverwalter (beispielsweise Datenbanksysteme) für den reibungslosen Abschluss der einzelnen Änderungen verantwortlich sind und entsprechende Rückmeldungen an den Transaktionsmonitor übergeben.^[11]

Betriebliche Informationssysteme, werden häufig als sogenannte "zweistufige verteilte Systeme"^[12] realisiert. Lokale Arbeitsrechner führen bei diesem Konzept neben der grafischen Darstellung der Anwendungsoberflächen auch die Geschäftslogik aus und kommunizieren im Hintergrund lediglich mit einem Server, der die Geschäftsdaten bereit stellt. Auf diese Weise ist der Einsatz eines Anwendungsservers wenig sinnvoll und wird in den meisten Fällen vernachlässigt. Sobald mehrere hundert, vielleicht sogar tausende Mitarbeiter eines Unternehmens die gleichen Programme nutzen müssen, ist eine Konzeption des entsprechenden betrieblichen Informationssystems auf dreistufiger Basis sinnvoll. Hierbei wird die Ausführung der Geschäftslogik auf einen eigens zu diesem Zweck bereit gestellten Anwendungsserver ausgelagert. Über ihn geschieht dann auch die Kommunikation mit dem Server, der für die Bereitstellung der Geschäftsdaten verantwortlich ist.^[13] Die dreistufige Architektur solcher Informationssysteme - auch im Hinblick auf Enterprise JavaBeans - wird in dem folgenden Abschnitt noch genauer beleuchtet.

Dem Einsatz von Anwendungsservern, in Kombination mit OLTP-Anwendungen, die in der Programmiersprache Java entwickelt wurden, wohnt zusätzlich eine Plattformunabhängigkeit bei. Unter anderem Microsoft Windows, Linux, Solaris und viele weitere Plattformen sind mit javabasierenden Programmen kompatibel. Zwar ist die die Nutzung von Transaktionsmonitoren bzw. Anwendungsservern an einige Konventionen und Entwurfsmuster gebunden, was andererseits aber auch den Vorteil der guten Wartbarkeit, Skalierbarkeit und hohen Flexibilität mit sich bringt. Die Realisierung und Anwendung eines Transaktionsmonitors bzw. Anwendungsservers wird im anschließenden Kapitel EJB 3.x näher erläutert.^[14]

6.3 EJB und Version 3.xx

Unter dem Begriff Enterprise JavaBeans (EJB) ist in erster Linie die Bezeichnung einer einer Spezifikation aus dem Hause Sun Microsystems zu verstehen. Ziel dieser Spezifikation ist es, eine technologische Grundlage für die Entwicklung verteilter, komponentenbasierter Systeme bereitzustellen. Ein fundamentaler Aspekt einer solchen Komponenten-Architektur ist die Schaffung einer Mittelschicht mit geschäftslogischer Orientierung innerhalb mehrschichtiger, verteilter Systeme. So kann die komplette Geschäftslogik innerhalb eines Systems über EJB-basierende Komponenten abgebildet werden. Das funktionale Spektrum der Enterprise JavaBeans sieht neben der Informationsbeschaffung und der Abbildung einer Geschäftslogik jedoch keine Aufbereitung der Daten zu Präsentationszwecken vor.^[15]

Enterprise JavaBeans bilden den zentralen Bestandteil der Java Enterprise Edition (JEE) und dienen zur Implementierung standardisierter Komponenten innerhalb mehrschichtiger verteilter Software Architekturen. Dabei wird unter dem "Verteilten System" verstanden, das eine Vielzahl von Programmen, gleichzeitig miteinander innerhalb einer Applikation interagieren. Bei der hier dargestellten speziellen Form der Client Server Systeme agiert der Client immer als Initiator. Der Server reagiert anschließend auf die Anforderungen des Clients. Das Client Server Konzept ist leicht zu verstehen und hat dadurch den Einzug in vielseitige Netzwerkapplikationen gefunden. Die Unabhängigkeit der Programme und Datenhaltung führte ursprünglich im Bereich des World Wide Webs zu dessen Einführung, wo wir diese Kommunikation am häufigsten finden. Zu sehen an der Kommunikation zwischen verschiedenen Browsern unterschiedlichster Hersteller und Webservern, mit dem Ziel, Daten überall abzufragen und anzeigen zu können.^[16]

Das Hauptaugenmerk von EJBs liegt bei Client Server Systemen auf der sogenannten "3 Schicht Architektur" im englischen three-tier architecture genannt. Dabei wird eine physische Trennung vorgenommen, in der unterschiedliche Prozesse implementiert sind. Der Client bildet dabei die Präsentationsebene. Die Datenbank befindet sich auf der Persistenzebene. Und dazwischen wird die Geschäftslogik abgebildet. Der hier beschriebene EJB-Standard steht für die mittlere Ebene, also die Geschäftslogik. Diese Ebene hat einfach gesprochen die Aufgabe, die Schnittstellen zu den anderen beiden Ebenen sicherzustellen. ^[17]

Die Spezifikation der Enterprise JavaBeans entwickelte sich seit ihrer Entwicklung zu einem weit verbreiteten Industriestandard mit Fokus auf die Entwicklung von verteilten, komponentenbasierten Systemen, der eine hohe Akzeptanz genießt. Hohe Akzeptanz mitunter auch wegen der Einsparungspotenziale, die sich durch den kombinierten Einsatz von EJBs zu Entwicklungszwecken und J2EE-basierenden Anwendungsservern für den anschließenden Betrieb der Geschäftslogik ergeben. Derartige Anwendungsserver verfügen im Regelfall bereits über ergänzende Funktionalitäten in den Bereichen Transaktionshandling, Sicherheitsverwaltung oder auch die Verwaltung nebenläufiger Prozesse bzw. nebenläufiger Komponenten.^[18]

6.3.1 Komponenten

Im Bereich der EJB wird der Begriff der Komponente im Zusammenhang mit dem Container-Component-Architekturmuster verwendet. Dieses Konzept basiert auf die Verteilung der technischen und der logischen Aufgaben innerhalb einer Server-Applikation. Die Logik wird dabei vom Anwendungsentwickler umgesetzt. Die Infrastruktur wird in einem Container, auch Lebensraum genannt zur Verfügung gestellt und ist für den Entwickler möglichst nicht einzusehen und zu beachten. Die Laufzeitumgebung, die Java Vitual Machine, welche als eine Art Container zu verstehen ist, zeigt bereits Einsteigern in der Entwicklung das Prinzip der Architektur, welche unter dem Namen "Seperation of Concerns" bekannt ist. Als ersten Vorteil kann an dieser Stelle die unnötige Portierung der Java Klassen auf ein anderes Betriebssystem genannt werden. Der Container der EJB ist der Application Server. Er übernimmt verschiedenste Aufgaben. Zum Beispiel die Garbage Collection und sorgt für eine Problemlose Portierbarkeit.^[19] Garbage Collection sorgt für die Speicherbereinigung für nicht mehr benötigte Objekte und gibt den nicht mehr benötigten Speicherplatz im Heap selbstständig wieder frei.^[20] Desweiteren wird sichergestellt, das der Aufrufer nur Komponenten aufrufen kann, welche den Berechtigungen des Aufrufers entsprechen. Das Händling der Threads auf dem Application Server, trotz mehrfachen aufrufen der Komponenten ist ebenfalls eine Aufgabe des EJB Containers. Dadurch können viele Clients auf dem Server bedient werden ohne das es zu Überschneidungen beim Zugriff der Instanzen kommt. Der Application Server bedarf damit die Möglichkeit, koordinierend überall einzugreifen, wo Komponenten aufgerufen werden oder Komponenten andere Komponenten aufrufen. Damit all das funktioniert, ist es notwendig, das Komponenten nur über definierte Interfaces aufgerufen werden können und der Application Server die Instanziierung der Komponenten übernimmt. Ansonsten könnte der Application Server seine Infrastrukturaufgaben nicht wahrnehmen.^[21]

Es lassen sich für das Container-Komponenten-Muster drei Arten innerhalb des EJB-Standards unterscheiden. Die Service-Komponente, welche Dienstfunktionen übernimmt ohne sich Informationen über den Aufrufer der Komponente oder des Clients zu merken. Diese Komponente wird im nachfolgendem Teil als Stateless Session Bean beschrieben. Die Session-Komponente kann sich spezifische Daten des Client merken und daher, im Gegensatz zur erst genannten Komponente, Vorgänge über mehrere Aufrufe hinweg verfolgen. Dies ist besonders für Interaktionen mit dem Client notwendig. Diese Tatsache verursacht allerdings einen höheren Aufwand an den Server. Er muss nun die Verwaltung vieler Daten für einen langen Zeitraum übernehmen, was schlussendlich zu Belastungen des Systems führen kann und Strategien zur Datenauslagerung erfordert. Dieses Komponenten-Muster wird im Bereich Stateful Session Bean näher erläutert. Zuletzt wird an dieser Stelle die Entity-Komponenten erwähnt, welche zur Abwicklung der Geschäftsobjekte dient. Sie wird meist nicht direkt, sondern über die beiden ersten Komponenten, der Service- und Session-Komponenten angesprochen. Diese beinhalten die Geschäftslogik. Die Entity-Komponenten besitzen ein eindeutiges Identifikationsmerkmal und repräsentieren somit einen eindeutigen Datensatz aus der Datenbank. Hierbei arbeiten mehrere Clients auf der selben Entity-Komponenten, sprich auf demselben Datensatz. Der Application Server muß nun die möglichen Konflikte des Zugriffes verwalten und die Synchronisation mit der Datenbank regeln. Diese Komponentenart wurde bis EJB 2.1 Entity Bean genannt. Aktuell wird für diese Komponente der Ausdruck Entities bevorzugt gebraucht.^[22]

6.3.1.1 Entity Bean

Ein Entity Bean definiert sich nach dem EJB 2.1 Standard, durch eine persistente Sicht auf die Daten. Alles weitere im nachfolgendem Absatz ist heute spezifisch dem alten Standard zuzurechnen. Daher wird zu erst die Verwendung der ursprünglichen Entity Beans dargestellt. Im zweiten Absatz dann die neue Sichtweise nach dem EJB 3.x Standard.

Die Datenhaltung zum Beispiel in Datenbanken wird über den Application Server vor der Anwendung verborgen. Diese Objekte werden dauerhaft gespeichert und daher auch als langlebige Objekte bezeichnet. Ein Absturz des EJB Containers führt nicht zu einer Löschung des Beans. Nach dem Neustart stehen sie wieder unverändert zur Verfügung. Entity Beans werden durch einen Primarschlüssel eindeutig gehalten und identifizierbar. Um dies zu erreichen, wird ein Attribut oder mehrere Attribute des Beans verwendet. Eine EJB Anwendung kommuniziert über das Entity Bean mit der Persistenzschicht. Dabei enthält das Bean die Daten aus der Persistenzschicht, welche sie repräsentiert. Am häufigsten werden sie verwendet, um die Daten der Geschäftsobjekte aufzunehmen und Fachlichkeiten zu beschreiben. Folgendes Beispiel soll nun die Sichtweise erläutern. Session Beans nehmen Objekte wie Girokonten oder Kunden auf. Die Entity Beans bilden die Geschäftsprozesse ab, welche bei den Objekten im Anwendungsfall durchgeführt werden können.^[23]

Nach dem EJB 3.x Standard ist nur die Sichtweise auf die Persistenz der Daten geblieben. Alles weitere ist einer neuen Definition gewichen. Dabei stellen Entity Beans Objekte einer einfachen Klasse dar, welche mit wenig Logik verknüpft werden. Eine Trennung von Interface und Implementierung wie bei den Session Beans ist nicht vorhanden. Eigenschaften des neu verstandenen Entity Beans sind die Serialisierbarkeit, das vorhanden sein eines Default-Konstruktor, auf dessen Beschreibung wir an dieser Stelle nicht weiter eingehen wollen. Und sie besitzen private Attribute. Dabei werden Entity Beans natürlich weiterhin über die Attribute definiert und eindeutig identifizierbar. Neu dabei ist die mögliche Verwendung der Annotationen. Konzeptionell weist der in Enterprise JavaBeans 3 eingeführte Standard keine großen Parallelen mehr zu den übrigen Bean-Spezifikationen mehr auf. Aus diesem Grund werden die bislang als Entity Beans bekannten Schnittstellen ab jener Version unter der Bezeichnung "Entities" geführt.^[24]

6.3.1.2 Persistenz

  "Verschiedene Typen von Entity-Beans können verschiedene Arten der Persistenz haben, aber alle
  Instanzen desselben Typs von Entity-Bean haben dieselbe Art von Persistenz."[25]

Bei der Verwendung von Enterprise JavaBeans nach dem EJB 3.x Standard werden verschiedene Aufgaben durch den Entity Manager übernommen, und stellen Java Klassen dar, welche durch den EJB Container bereitgestellt werden. Der Manager wird für das Auffinden, Löschen und Abspeichern im sogenannten Persistenz-Kontext benötigt. Dabei werden Aktualisierungen von Instanzen, die bereits verwendet wurden, vorgenommen. Instanzen werden gelöscht, die keine Verwendung mehr haben. Anhand des Primärschlüssels werden die Instanzen eindeutig zugeordnet und sind dadurch auffindbar. Durch die Erfüllung dieser Aufgaben lässt sich der Persistenz-Kontext als Gesamtheit der Entities beschreiben. Der Manager stellt dabei die Methoden zur Verfügung, die der Client benötigt um mit dem Persistenz-Kontext zu kommunizieren, der wiederum die Verwaltung der Datenbank übernimmt.^[26]

Grundsätzlich wird mit der Realisierung von Datenbankzugriffen über Entities das Prinzip des objektrelationalen Mappings, auch als O/R Mapping oder ORM abgekürzt, verfolgt. Dieses Prinzip definiert die Abbildung bzw. Übertragung von Entitätsklassen auf Tabellen bestimmter Datenbanken. Dem Grunde nach sollte es so möglich sein, aus der Struktur einer Entity die zugehörige Datenquelle bzw. die zugehörige Datentabelle mitsamt ihrem Aufbau abzuleiten und im Umkehrschluss eine Entity anhand gegebener Tabellenstrukturen zu erzeugen. Häufig ist es jedoch notwendig, beispielsweise aufgrund gegebener Konventionen wie die Verwendung von Präfixen bei der Festlegung von Tabellennamen, das Verfahren für die Abbildung von Entitätsklassen auf Datentabellen und umgekehrt anzupassen. Diese Möglichkeit besteht über die Nutzung zusätzlicher Annotationen. Im übertragenden Sinne können Annotationen als Eigenschaften beschrieben werden, über welche im Bedarfsfall zusätzliche Parameter an eine Entitätsklasse übergeben werden können.^[27]

6.3.1.3 Session Bean

Mittels der in Enterprise JavaBeans enthaltenen Session Beans wird im Regelfall die Geschäftslogik einer Anwendung realisiert. Ferner wird mit Session Beans der Zugriff auf serverseitige Objekte koordiniert und umgesetzt. Das Funktionsspektrum, welches durch eine Session Bean bereit gestellt wird, kann hierbei beliebigen Ausmaßes sein. Angefangen bei kleinen Diensten bis hin zu komplexen und umfangreichen Abwicklungsprozessen sind der Gestaltung einer Session Bean keinerlei Grenzen gesetzt. Grundsätzlich ist es so, dass sämtliche Daten, die sich in einer Session Bean befinden bzw. die von ebendieser verarbeitet werden, einen nicht-persistenten Charakter besitzen. Im übertragenden Sinne bedeutet dies, dass derart genutzte Daten lediglich im Hauptspeicher des jeweiligen Rechners, nicht jedoch in Datenbanken oder dergleichen mehr abgelegt werden. Demzufolge wäre ein Abschalten oder gar ein Absturz oder Ausfall jenes Rechners, auf dem eine Session Bean zu Verarbeitungszwecken eingesetzt wird, gleichbedeutend mit einem vollständigen Verlust der hierin geführten Daten.^[28]

Session Beans werden typischerweise für die Repräsentation einer Geschäftslogik nach außen eingesetzt. Sie schützen bzw. verbergen hierbei das Gesamtkonzept der jeweiligen Anwendung und geben lediglich ausgewählte Einstiegspunkte nach außen hin frei, über welche dann mit Clients kommuniziert werden kann. Es ist nicht unüblich, dass Session Beans für die Ausführung komplexerer Abläufe hintergründig mit anderen EJBs kommunizieren. All dies geschieht jedoch gekapselt und ist für die Clients nicht ersichtlich.^[28]

In Abhängigkeit von den auszuführenden Aufgaben kann eine Session Bean von zweierlei verschiedenen Typisierungen sein. Die sogenannten "Stateless" Session Beans werden typischerweise für die Ausführung von Prozeduren verwendet, deren Komplexität sich auf einen Methodenaufruf beschränkt. Als Beispiel könnte hier die Preisermittlung für ein bestimmtes Produkt, eine Bohne etwa, heran gezogen werden. Die Arbeit der hierfür verwendeten Stateless Session Bean ist nach der Preisermittlung und in Bezug auf den aufrufenden Client vollständig abgeschlossen. Demzufolge ist es nicht notwendig, clientbezogene Daten dauerhaft bzw. für einen Zeitraum, dessen Länge über die der Preisermittlung hinweg geht, verfügbar zu machen. Genau dieses Verhalten weisen Stateless Session Beans auf. Sie sind zustandslos und darüber hinaus ungebunden, sobald sie ihre Aufgabe erfüllt haben. Der jeweilige EJB-Container entscheidet im Falle einer ungebundenen, zustandslosen Session Bean über deren weitere Verwendung. Sie kann im Bedarfsfall, bezogen auf das obige Beispiel entweder für weitere anstehende Preisermittlungen verwendet oder aber gelöscht werden, um belegten Speicherplatz wieder freigeben zu können.^[29]

Den Stateless Session Beans gegenüber stehen die sogenannten "Stateful" Session Beans. Sie bilden das Pendant zu den Stateless Session Beans, sind also zustandsgebunden bzw. an einen speziellen Client gebunden. Eine solche Systematik bietet sich für die Ausführung komplexerer, miteinander verknüpfter Prozesse an. Nach der Preisermittlung für ein bestimmtes Produkt, sei es auch in diesem Fall eine Bohne, könnte der Kauf letzterer mitsamt dem Druck einer Rechnung ein Prozedere darstellen, für welches sich die Verwendung einer Stateful Session Bean anbietet. Beim Kauf der Bohne könnten kundenspezifische Rabattierungen mit in die Endpreisberechnung einfließen. Erst nachdem der Kauf komplett getätigt ist, kann die Rechnung gedruckt werden. Der Druck der Rechnung ist folglich von dem eigentlichen Kauf abhängig, da hier der kundenspezifische Preis ermittelt wird, der wiederum auf der Rechnung erscheint. Die verwendete Session Bean bildet so eine Art Bindeglied zwischen zwei miteinander verknüpften Prozessen und verändert ihren Zustand entsprechend der Teilergebnisse von Teilprozessen. Es drängt sich die Annahme auf, dass Stateful Session Beans wegen ihrer klassischen, methodenübergreifenden Arbeiten eine gewisse Datenpersistenz gegeben ist. Dies ist jedoch nicht der Fall. Ähnlich wie die Stateless Session Beans haben auch sie einen nicht-persistenten Charakter. Auch hier werden in der Folge also keinerlei Daten dauerhaft verfügbar gehalten. Trotz der Möglichkeit, komplexe Abläufe mit ihnen durchzuführen sollten Stateful Session Beans nicht in Verbindung mit kritischen Daten genutzt werden, da diese bei einem Systemabsturz unweigerlich verloren gehen.^[30]

6.3.1.4 Klassenarten

Klassenart	EJB-Typ
Kontroll-Klasse	Stateless Session Bean
Steuerungs-Klasse	Stateful Session Bean
Entity Klasse ohne Geschäftsmethoden	Entity Bean
Geschäftsmethoden aus Entity-Klasse	Stateless Session Bean
Interface Klasse	Kein Bean-Typ, sondern Dienste des Application Server

Tabelle 1: Zuordnung der Klassenarten zu den Bean Typen, Entnommen aus: Heinisch, C (2007), S. 1105

6.3.1.5 Message Driven Bean

Die Verwendung des Message-Driven Bean lässt sich am besten beschreiben, wenn wir mit der Funktionsweise und Begrifflichkeit des Java Message Service vertraut sind. Daher wird zur Einführung, das Konzept zur nachrichtenbasierten Arbeit mit Java vorgestellt.

Alle bisherigen Bean-Typen richteten sich auf die Remote-Method-Invocation (RMI) aus. Jeder Client kommuniziert dabei mit dem Server über ein konkretes Interface. Die Abhandlung der Methoden erfolgt dann zeitnah mit einer engen Verbindung zwischen dem aufrufenden Client und dem Server. Zur Laufzeit wird dann für den Client eine spezifische Bibliothek benötigt. Dadurch wird eine einfache Modellierung der Programmierung erreicht, was als Vorteil gesehen werden kann.

Die nachrichtenbasierten Systeme, auch Middleware bezeichnet, werden durch ihre "zeitliche Entkopplung asynchroner Aufrufe"^[31] und der Unkenntnis zwischen Sender und Empfänger definiert. Beide nutzen zwar die selbe "Sprache", müssen ansonsten aber nichts voneinander wissen. Erweiterungen auf Ebene des Servers können somit durchgeführt werden, ohne das der Client davon etwas bemerkt. Was hierbei als wesentlicher Vorteil dieser Systeme gesehen wird. Vorraussetzung hierbei ist, das sich an der eigentlichen Systematik der Kommunikation zwischen Client und Server nichts ändert. Nachrichtenbasierte Systeme können, ohne Probleme zu verursachen, auf Clientseite in einer anderen Programmiersprache geschrieben sein, als auf der Serverseite.

Bis zur Einführung des EJB2-Standards durch SUN war es nicht möglich, von Clientseite mittels EJB auf Nachrichten zu warten und den aktuellen Prozess dafür zu unterbrechen. Diese Einschränkung wird mit der Verwendung des Message Driven Bean aufgehoben. Dafür wird ein Stateful Session Bean verwendet, welcher asynchron verwendet arbeitet. In dieser Funktion wird er als zustandsloser Nachrichtenempfänger bezeichnet. Im Bereich der Nachrichten Verarbeitung wird im weiteren auch unter dem Erzeuger der Nachrichten und dem Adressat der Nachricht unterschieden. Beide Nutzer sind dabei in der Lage, der Ausgangspunkt der Nachricht zu sein. Es ist also möglich, das sowohl der Client als auch der Datenbankserver den Empfänger oder Adressat darstellt. Beide Kommunikationspartner sind daher gleichberechtigt. Diese Sichtweise stellt in gewisser Weise ein Peer-To-Peer Netzwerk dar.^[32]

Das gesamte Paket JMS wird von der JEE bereitgestellt und über einen Server ausgeführt. Dabei stellt der Server die Infrastruktur bereit, über welche die Nachrichten zuverlässig vom Sender für den Empfänger bereit gestellt werden. Die Java Programme, welche für den Nachrichtendienst, verwendet werden, nennt man JMS - Java Message Service. Sie beinhalten die JMS-Clients, die als Sender und Empfänger der generierten Nachrichten fungieren. Ein weiterer Bestandteil sind die eigentlichen Nachrichten, die über das System verarbeitet werden. Im weiteren ist der JMS-Provider zu nennen, der das eigentliche Nachrichtentransportsystem zur Verfügung stellt und administrative Funktionen für die Architektur bereitstellt. Damit werden anschließend administrierte Objekte erzeugt und vorkonfiguriert. Diese administrierten Objekte können ConnectionFactory Objekte sein, welche vom Client verwendet werden um die Verbindung zum Dienst aufzunehmen. Andernfalls kann es sich um Destination Objekte handeln, über die der Sender und Empfänger die Nachrichten sendet. Folgende Nachrichtentypen werden zur Verfügung gestellt:

• TextMessage
• MapMessage
• ObjektMessage
• StreamMessage
• ByteMessage^[33]

Die Hauptaufgabe des JMS-Servers ist die Transaktion der Nachrichten. Dabei wird zwischen zwei Varianten unterschieden. Die Daten können transaktional und persistent übergeben werden. Im ersten Fall wird die Nachricht vom Sender an den Empfänger gegeben. Sobald der Empfänger die Nachricht gelesen hat, ist die Transaktion komplett. In der zweiten Variante werden die Nachrichten auch beim Ausfall der Systeme vorgehalten. Das bedeutet, sobald eine Nachricht generiert wurde, wird diese im System abgelegt, auch wenn der Empfänger sie noch nicht abgerufen hat. Dadurch wird die Hauptanforderung der Zuverlässigkeit erreicht, da diese Funktion nicht durch den Programmierer beeinflusst wird. Verantwortlich für diese Sicherheit ist der Serverhersteller des Message Services. Sobald der Empfänger der Nachricht nach einem Ausfall wieder erreichbar ist, wird die Nachricht zugestellt oder kann durch den Empfänger abgerufen werden.^[34]

6.3.1.6 Annotationen

  "Wie der Name Annotation (Anmerkung) bereits verrät, hat eine Annotation ... keinen unmittelbaren Einfluss
  auf den Programmablauf. Sie ist vielmehr als Anweisung an Werkzeuge oder Middleware-Einheiten gedacht,
  sei dies der Compiler, die Web-Service-Implementierung oder eine Implementierung des Java Persistency API."[35]

Von Annotationen spricht man, wenn erzeugter Code mit Metadaten versehen wird, um Methoden zu deklarieren. Durch das vorangestellte @-Zeichen werden die Annotationen erstellt, Klassen, Attribute und Methoden somit beschrieben. So ist es zum Beispiel möglich, mit Befehlen die Ausgabe von Warnmeldungen beim kompilieren des Programms zu unterdrücken oder Suchroutinen für Methoden zu implementieren. Der bei den JavaBeans überall verwendete Komponenten-Standard macht die Einführung dieser Konfigurationsinformationen mittels Metadaten zu einer sinnvollen Option. Bisher wird über XML-Deskriptoren die Verwendung der Annotationen ermöglicht.^[36] Die Bereitstellung erfolgt über eine XML-Datei, welche den Deployment-Deskriptor beinhaltet. Jede Einstellung, die nun definiert wird, muß zu einer Struktur in einer XML-Datei gehören, die in einem spezifischen Pfad für das verwendete Bean hinterlegt wird. Auf einen Auszug der bereits vorhandenen Elemente zur dokumentation der Deskritoren wird an dieser Stelle verzichtet. Es ist durch den EJB 3x Standard nun nicht mehr notwendig, den Umweg über den XML-Deskritor zu gehen. Durch die Hinterlegung der Konfigurationsdaten direkt im Quellcode wird zwar dem eigentlichen Konzept der Code-Änderung widersprochen. Ist allerdings aus Zweckdienlichen Gründen sinnvoll.^[37]

6.3.1.7 Web Services

Netzdienste bzw. Web Services sind mittlerweile zu einen sehr wesentlichen Bestandteil unternehmerischer DV-Lösungen geworden. Sie stellen eine Möglichkeit dar, Hardware, Betriebssysteme, Programmiersprachen und Anwendungen auf hohem Niveau miteinander interagieren zu lassen und so eine systemübergreifende Interoperabilität umzusetzen. Die den Web Services zugrunde liegen Standards wie XML, SOAP oder auch WSDL sorgen für eine flächendeckende Akzeptanz bei namenhaften Unternehmen wie beispielsweise Microsoft, IBM, BEA, JBoss oder Oracle, die Ihre Produkte auf diese Standards ausrichten. Auch Sun Microsystems hat Schnittstellen entwickelt, denen diese Standards zugrunde liegen, und diese innerhalb der Java EE Plattform implementiert. Gleichermaßen wurden die Enterprise JavaBeans ab der Version 3.0 um diese Standards erweitert.

Im Allgemeinen kann ein Web Service als Anwendung verstanden werden, die per Fernzugriff genutzt wird. Spezifiziert werden Web Services unter Nutzung der Web Service Description Language (WSDL) während der Zugriff über das sogenannte Simple Object Access Protocol (SOAP), orientiert an den Vorgaben des WS-I Basic Profile 1.1, funktioniert. WS-I steht hierbei für "Web Service Integration Organization" und stellte einen Zusammenschluss mehrerer Unternehmen dar, u.a. Microsoft, IBM, Oracle und Sun Microsystems, die sich damit befassen die reibunslose Interoperabilität von Web Services über alle Plattformen sicherzustellen. Im Zuge dessen entwickelte dieser Unternehmenszusammenschluss ein Regelwerk, der verschiedene Richtlinien und Vorgaben für die Nutzung von XML, SOAP und WSDL in Kombination miteinander umfasst. Dieses Regelwerk wird als Basic Profile 1.1 bezeichnet.^[38]

Wie bereits angesprochen beinhaltet das Paket der Enterprise JavaBeans neben vielen anderen Funktionalitäten ebenso Lösungen für die Implementierung von Web Services. Diese Lösungen berücksichtigen gleichzeitig das o.g. Regelwerk "Basic Profile 1.1" und stellen somit eine Möglichkeit dar, unter Nutzung von Java schnell und komfortabel zuverlässige Web Services zu realisieren.

Die folgende Illustration verdeutlicht das Bereitstellungs- und Nutzungsprozedere eines Webservice:

Abbildung 2: Webservice-Architektur, Angelehnt an: Finger, P. (2009), S. 41

6.3.2 Transaktionen

  "Eine Transaktion (Transaction, TX) ist eine Folge von elementaren Operationen, die zu einer
  logisch untrennbaren Einheit zusammengefasst sind."[39]

Transaktionen sind ein wichtiger und fundamentaler Bestandteil in der Ausführung verteilter Systeme. In Zusammenarbeit mit einem Transaktionsmonitor stellen Sie den Garant für die reibungslose und robuste Verarbeitung von Daten über mehrere Instanzen hinweg dar. Die Transaktionssystematik ist auf das konkurrierende Wirken multipler unterschiedlicher Komponenten auf gleichermaßen verteilte Datenpools zurückzuführen. Die Tatsache, dass mehrere Komponenten auf ein und dieselben Daten zugreifen macht es erforderlich, die Zugriffe der einzelnen Komponenten kontrolliert abzuwickeln. Dies ist die Aufgabe des Transaktionsmonitors. Im Übertragenden Sinne stellt er eine Art Dirigent dar, der jede von einer Komponente georderte Transaktion in das gesamte Transaktionsorchester einreiht und die einzelnen Transaktionsabwicklungen so koordiniert, dass ein gleichzeitiger Zugriff mehrerer Transaktionen auf eine Ressource vermieden wird.^[40]

Eine Transaktion als solche kann im Groben als eine Aneinanderreihung mehrerer Aktionen beschrieben werden, die für die Umsetzung eines bestimmten Vorhabens notwendig sind. Beispielsweise könnte für den Verkauf einer Bohne der Preis der Bohne ermittelt, die Verbuchung der eigentlichen Zahlung vorgenommen und die Rechnung gedruckt werden. All jene in dem Verkaufsfall durchzuführenden Aktionen würden zu einer Transaktion zusammengefasst und über den Transaktionsmonitor koordiniert abgewickelt. Ob eine Transaktion erfolgreich oder fehlerhaft durchgeführt worden ist, entscheiden bei dessen Abschluss alle an einer Transaktion beteiligten Ressourcen und Komponenten. Eine gesamte Transaktion kann nur dann als erfolgreich abgeschlossen deklariert werden, wenn alle Teilaktionen erfolgreich durchgeführt werden konnten. Übertragen auf das Beispiel des Bohnenverkaufs bedeutet dies, dass der Verkauf erfolgreich war, wenn der Preis der Bohne ermittelt, die Verbuchung der eigentlichen Zahlung vorgenommen und die Rechnung gedruckt werden konnte. Tritt bei einer dieser Teilaktionen ein Fehler auf, sodass diese nicht ordnungsgemäß zum Abschluss gebracht werden konnte, so ist die gesamte Transaktion fehlerbehaftet durchgeführt worden. Konkret könnte der Preis ermittelt und die Zahlung vorgenommen worden sein. Wenn jedoch der Druck der Rechnung fehlschlägt, so gilt die gesamte Transaktion als fehlgeschlagen und die bisherig erfolgreich getätigten Teilaktionen werden wieder rückgängig gemacht, sofern sie zu widerrufende Spuren hinterlassen haben. Hier müsste also die bereits abgewickelte Zahlungsverbuchung widerrufen werden. Bei Transaktionen gilt also "Hop oder Top", "Alles oder Nichts".^[41]

6.3.2.1 ACID-Eigenschaft

Wie bereits erwähnt stellt die transaktionsbasierte Verarbeitungssystematik bei verteilten Systemen fundamentaler Weise einen Garant für die reibungslose Abwicklung ebensolcher Transaktionen dar. Zu diesem Zweck wird eine jede Transaktion unter Einhaltung der sogenannten "ACID-Eigenschaft", die sich aus den folgenden vier Prämissen zusammensetzt, durchgeführt:

Atomicity

Der Begriff "Atomicity" beschreibt die Unteilbarkeit einer Transaktion, also das o.g. Prinzip "Alles oder Nichts". Eine Transaktion gilt also als atomar. Folglich kann es nicht passieren, dass nur ein Teil der an einer Transaktion beteiligten Aktionen erfolgreich durchgeführt wird, während ein anderer Teil fehlschlägt. Eine Transaktion wird also nie "geteilt" - Aktion für Aktion - sondern immer im Ganzen betrachtet und als solches behandelt.^[42]

Consistency

Unter "Consistency" wird die Konsistenzerhaltung in Bezug auf alle während der Durchführung einer Transaktion manipulierten Daten verstanden. Sobald nach der Durchführung einer Transaktion eine Inkonsistenz der Daten festgestellt wird, wird die entsprechende Transaktion bzw. werden die in ihr zusammengefassten Aktionen rückgängig gemacht, um die Datenkonsistenz wiederherzustellen.^[43]

Isolation

Die "Isolation" beschreibt die gekapselte Verarbeitung aller Transaktionen. Konkurrierend zueinander ablaufende Transaktionen werden in der Folge so koordiniert und gesteuert, dass sie nicht auf die unfertigen Zwischenergebnisse einer jeweils anderen Transaktion zugreifen und diese zu Verarbeitungszwecken verwenden können. Auf Datenbankebene wird die Isolation von Daten beispielsweise durch deren Sperrung für den jeweils von einer Transaktion benötigten Zeitraum realisiert. Erst wenn die Transaktion, die Auslöser für die Sperrung der Daten ist, erfolgreich abgeschlossen oder rückgängig gemacht worden ist, werden jene Daten wieder für die Weiterverarbeitung durch andere Transaktionen freigegeben. Die Transaktionsisolation kann mit unterschiedlich hohen Gradierungen durchgeführt werden. Je höher der hierfür angesetzte Isolationsgrad ist, desto robuster können Transaktionen abgearbeitet werden.^[43]

Durability

Der Begriff "Durability" bedeutet übersetzt soviel wie "Beständigkeit" oder "Dauerhaftigkeit" und beschreibt vor dem Hintergrund der hier beleuchteten Transaktionen die dauerhafte Speicherung von Transaktionsergebnissen. Genauer ist hier die dauerhafte Fixierung aller innerhalb einer Transaktion vorgenommenen Änderungen gemeint. All jene Änderungen stehen nach erfolgreichem Abschluss einer Transaktion allen weiterhin noch anstehenden Transaktionen für die Weiterverarbeitung zur Verfügung.

6.3.2.2 Zugriffsproblematik

In Abhängigkeit von der jeweils für eine Transaktion gesetzten Isolationsstufe kann die Abwicklung einer solchen Transaktion mit Problematiken behaftet sein, die vorrangig das Auslesen von Daten bzw. deren Verfälschung betreffen. Die folgende Tabelle listet die unterschiedlichen Kategorisierungen ebendieser Verfälschungsproblematik auf und beschreibt deren Bedeutung:

Name des Problems	Bedeutung	Kurzbeschreibung
Dirty Read	Nicht freigegebene Änderungen	Das "Dirty Read Problem" hängt mit der Datenisolation zusammen und tritt auf, wenn die von einer Transaktion beanspruchten Daten von einer konkurrierenden Transaktion gelesen und verarbeitet werden können.[44]
Non-repeatable Read	Nicht wiederholbares Lesen	Unter dem Begriff "Non-repeatable Read Problem" wird das das lesen unterschiedlicher Daten beim wiederholten Zugriff auf gleiche Datensätze verstanden. Während der Durchführung einer Transaktion werden also beim ersten lesen eines Datensatzes andere Werte ermittelt, als beim wiederholten lesen desselben Datensatzes zu einem späteren Zeitpunkt.[45]
Phantom Read	Phantom-Problem	Das "Phantom Problem" ähnelt faktisch dem zuvor behandelten "Unrepeatable Read Problem". Der Unterschied ist, dass nicht die Daten eines Datensatzes selbst verschieden sind, sondern dass beim Lesen von Daten zu einem späteren Zeitpunkt mit den gleichen Auswahlkriterien eine andere Anzahl an Datensätzen ermittelt wird.[45]

Tabelle 2: Zugriffsproblematiken bei Transaktionsverarbeitung, Angelehnt an: Schäffer, S. (2002), S. 507

6.3.2.3 Zugriffsattribute

Die Verhaltenssteuerung von Transaktionen kann auf zwei unterschiedlichen Arten erfolgen. Zum Einen kann sie direkt vom Programmierer selbst übernommen werden. In diesem Fall obliegt dem Programmierer die Verantwortung festzulegen, an welcher Stelle eine Transaktion beginnt, wann sie endet und in welcher Form sie als erfolgreich abgeschlossen anzusehen ist. Derart vom den Entwicklern selbst spezifizierte Transaktionen werden als "bean-managed Transactions" bezeichnet. Dem gegenüber stehen die sogenannten "Container-managed Transactions". Die Verhaltenssteuerung geschieht hierbei vorrangig über den jeweiligen Container, der die Ausführung einer Transaktion übernimmt. Im direkten Vergleich dieser beiden Möglichkeiten wird klar, dass bean-managed Transaktionen einen größeren Spielraum für die Gestaltung von Transaktionen bieten, jedoch mit verhältnismäßig hohem Mehraufwand in der Programmierung verbunden sind. Dieser zusätzliche Aufwand entfällt bei der Nutzung von container-managed Transaktionen. Allerdings geht mit der Verwendung letzterer eine entsprechend höhere Bindung an vorgegebene Strukturen einher. Die hier vorgegebenen Verhaltensmuster sehen aber dennoch die Möglichkeit vor, über das Setzen von Attributen das Ausführungsverhalten von Transaktionen innerhalb eines bestimmten Rahmens anzupassen. Die folgende Tabelle listet die für container-managed Transaktionen verfügbaren Attributswerte auf und erläutert kurz deren Bedeutung.

Transaktionsattribut	Auswirkung
NotSupported	Wird diese Methode innerhalb einer Transaktion aufgerufen, dann sind evtl. innerhalb von ihr auftretende Fehler kein Grund für den Abbruch der Transaktion
Required	Wird diese Methode innerhalb einer Transaktion aufgerufen, so führen innerhalb von ihr auftretende Fehler zum Abbruch der Transaktion. Wird diese Methode außerhalb einer Transaktion aufgerufen (d.h. der Aufrufer ist selbst nicht Teil einer Transaktion), dann wird mit dieser Methode eine neue Transaktion begonnen. Ist die Methode erfolgreich, wird die Transaktion zuerst comittet, bevor ein Ergebnis an den Methodenaufrufer gesendet wird.
RequiresNew	Wird diese Methode aufgerufen, wird stets eine neue Transaktion begonnen. Ist die Methode erfolgreich, dann wird die Transaktion committet, bevor der Methodenrückgabewert an den Aufrufer gesendet wird. Wird die Methode innerhalb einer anderen Transaktion aufgerufen, dann wird diese Transaktion zunächst für die Ausführung dieser Methode auf Eis gelegt. Erst nach dem (nicht) erfolgreichen Ablauf dieser Methode wird die Transaktion fortgeführt. Der Misserfolg der Methode führt nicht zu einem Scheitern der umschließenden Transakion.
Mandatory	Die Methode muss immer innerhalb einer Transaktion aufgerufen werden. Falls dies nicht geschieht, wirft der Applicationcontainer eine Exception vom Typ TransactionRequired.
Supports	Wird die Methode innerhalb einer Transaktion aufgerufen, dann ist sie auch Teil dieser Transaktion. Wird sie nicht innerhalb einer Transaktion aufgerufen, dann läuft sie ohne Transaktionsunterstützung ab.
Never	Diese Methode darf nicht innerhalb einer Transaktion aufgerufen werden. Falls dennoch, wirft der Applicationcontainer einer RemoteException.

Tabelle 3: Zugriffsattribute von container-managed Transactions, Entnommen aus: Langner, T. (2005), S. 341

6.3.3 EJB QL

EJB QL bezeichnet die Query Language der EJavaBeans. Sie dient dazu, die Entity Beans bzw. deren persistente Daten zu laden.^[46] EJB QL ähnelt SQL, jedoch sind hierbei wichtige Unterschiede zueinander festzustellen und werden nachfolgend beschrieben^[47]:

Vorteile der EJB QL

• EJB QL ist standardisiert und kann übergreifend in verschiedenen EJB-Containern verwendet werden und ist somit portabilitätssteigernd

• EJB-Queries werden validiert und geprüft bevor die jeweiligen entity beans erzeugt werden, unnötiger Datentransfer wird vermieden.

Nachteile der EJB QL

• Es sind keine Kommentare (in der Übertragung) möglich

• Daten sollten aus Zeitersparnis im Long-Format übermittelt werden

• Nützliche Funktionen von SQL, wie beispielsweise die „ORDER BY“-Funktion sind kein Standart und werden nur von einigen Servertypen unterstützt. Diese Einschränkung wirkt sich jedoch gegen den eigentlichen Sinn, nämlich den der Portabilität der Systeme aus.

• Es ist nur eine eingeschränkte Möglichkeit des Vergleiches von String- und Booleanwerten gegeben.

• Ebenso ist kein fixer Dezimalvergleich möglich^[48]

6.3.4 Neuerungen

Die Neuauflage der Enterprise JavaBeans in der Version 3 bringt einige Neuerungen mit sich, die teilweise wesentlichen Auswirkungen im Bereich der Leistungsstärke haben und gleichermaßen den Aufwand auf Seiten der Programmierung verringern. Die Robustheit von verteilten Systemen, insbesondere die Integrität der bearbeiteten Daten, kann unter Nutzung ebendieser Version von Enterprise JavaBeans erheblich gesteigert werden. Eine Reihe dieser Neuerungen wurden in den bisherigen Ausführungen dieser Abhandlung bereits indirekt erwähnt und beschrieben. Der folgende Abschnitt dieser Arbeit dient dazu, alle Neuerungen, die mit Enterprise JavaBeans in der Version 3 umgesetzt worden sind, noch einmal gesammelt darzustellen und so einen Überblick zu verschaffen. So können gleichermaßen die fundamentalen Unterschiede herausgestellt und analysiert werden.

• [Neue Persistenz]: Die bereits behandelten Entity Beans sind in der Version 3 der Enterprise JavaBeans durch die sogenannte "Entities" ersetzt worden. Grundsätzlich umfassen diese Entities dasselbe Funktionsspektrum der ehemaligen Entity Beans, folgen jedoch einem wesentlich schlankeren Modell. Maßgeblich für die Realisierung der neuen Entities war das OpenSource Framework "Hibernate". Die Umsetzung der Entities umfasst ebenfalls die Spezifikation, dass das Persistenz-Management nicht ausschließlich innerhalb, sondern auch außerhalb eines Application Servers funktionieren muss. Testläufe können so einfacher und zielführender bewerkstelligt werden.^[49]
• [Wegfall von Home-Interfaces]: In den früheren Versionen von Enterprise JavaBeans wurden über die Home-Interfaces alle Methoden einer EJB-Komponente bereitgestellt, die zur Steuerung des Lebenszyklus derselben benötigt wurden. Da Rechner bereits aus technischer Sicht nicht die Möglichkeit hatten, EJB-Komponenten über Prozessgrenzen hinweg zu erzeugen, zu laden und dergleichen mehr, musste ein solches Vorhaben grundsätzlich über das Home-Interface der jeweiligen Komponente gelöst werden. Diese Home-Interfaces wurden in der Version 3 der Enterprise JavaBeans ersatzlos gestrichen. Die für Lebenszyklen notwendigen Operationen werden nun mit Hilfe von Komponenten-Lookups umgesetzt, die einen Proxy auf das Business Interface der jeweiligen EJB-Komponente zurückliefern.^[50]
• [Wegfall von Basis-Interfaces]: Der Wegfall der Basis-Interfaces ist vorrangig für die eigentliche Softwareentwicklung von Interesse. Hierüber ist neuerdings festgelegt, dass EJB-Interfaces und Implementierungsklassen keinerlei vordefinierte Basis-Interfaces mehr zu implementieren brauchen. Somit erschließt sich die Möglichkeit Interfaces und deren Implementierung über gewöhnliche Implements-Beziehungen miteinander zu verbinden.^[51]
• [Optionale Callbacks]: In der Version 3 der Enterprise JavaBeans sind Lebenszyklus-Callbacks der SessionBeans nicht länger pflicht, sondern optional. Sie werden über eine entsprechende Annotation als solches gekennzeichnet.^[51]
• [Dependency-Injection]: Unter "Dependency-Injection" wird vereinfacht das Befüllen einer Objekt-Eigenschaft mit einem bestimmten Wert bzw. mit bestimmten Werten von außerhalb verstanden. Die Neuauflage der Enterprise JavaBeans nutzt diese Systematik, um einzelne Komponenten an die Ressourcen zu binden bzw. diese den Komponenten mitzuteilen, die für die anstehenden Verarbeitungsprozeduren benötigt werden. Bislang wurden solche Einstellungen über JDNI-Lookups und die Initiative der EJB vorgenommen. Das Prinzip der Dependency Injektion verlagert diese Aufgabe auf den jeweiligen Container, was eine weitere Entlastung der Komponentenimplementierung bedeutet.^[52]
• [Annotationen]: Neu hinzugekommen sind ebenfalls die sogenannten Annotationen, wie sie bereits an früherer Stelle dieser Abhandlung erläutert worden sind. In früheren Versionen der Enterprise JavaBeans wurden Metadaten einer Komponenten unter Nutzung von Deployment Descriptoren formuliert. Diese Formulierung von Metadaten wurde um die Möglichkeit ergänzt, derartige Vorhaben gleichermaßen über Annotationen zu realisieren. Hierbei sind die Annotationen nicht als Ablösung bzw. Ersatz für die Fomulierung von Metadaten über Deployment Descriptoren zu sehen. Viel mehr stehen beide Möglichkeiten zu Implementierungszwecken zur Verfügung und ergeben kontextbezogen auch gegenläufig einen Sinn - ergänzen sich also.^[53]
• [Methoden-Interceptoren]: Die Aspektorientierung war in vorangegangenen Versionen für die Bereiche Transaktionsmanagement und Zugriffskontrolle der Enterprise JavaBeans zwar bereits gegeben, dies jedoch in eher minimalistischem Maße. Die Methoden-Interceptoren stellen eine Erweiterung dieses Aspektspektrums dar.^[54]

7 Spezifische Anforderungsanalyse

7.1 GlassFish

  "Glas gehört zu den ältesten Werkstoffen der Menschheitsgeschichte.
  Schon bevor die alten Agypter Glas herstellten, dienten natürliche Gläser als Obsidiane unseren Vorfahren als Werkzeug.
  Dieser Werkstoff blickt auf eine lange Erfolgsgeschichte zurück und erlebt gerade in jüngster Zeit unserer technischen
  Zivilisation eine erneute Blüte."[55]

Im zweiten Quartal 2005 startete das Unternehmen Sun Microsystems ein Projekt, welches sich vorrangig auf die Entwicklung eines Anwendungsservers unter Nutzung von Java konzentrierte. Das so ins Leben gerufene Projekt wird seither unter dem Namen "GlassFish" geführt und zog zusätzlich viele weitere Entwickler in seinen Bann. So entstand eine leistungsstarke Gemeinde, die sich bis heute mit der Wartung, vor allem jedoch mit der Weiterentwicklung des Projektes beschäftigt und sich selbst die "GlassFisch Community" nennt. Das erste publizierte Ergebnis der Anstrengungen aller teilnehmenden Entwickler war der "GlassFish v1" Anwendungsserver - der erste, vollständig unter Java entwickelte Open-Source-Anwendungsserver. In Verbindung mit diesem Projekt entstanden einige weitere Subprojekte, die während den Arbeiten an GlassFish ebenfalls von der Gemeinde unterstützt und gefördert wurden. Hierzu zählen u.a. Metro, jMaki, Open Message Queue (Open MQ), Hudson, und Grizzly.^[56]

Die ursprüngliche Zielgruppe, auf die GlassFish v1 ausgerichtet wurde, waren Softwareentwickler. Ziel war es, einen vollständig in Java entwickelten Anwendungsserver bereit zu stellen, mit dessen Hilfe Programmierer, die unter Java arbeiten, ihre entwickelten Anwendungen testen können. Relativ zügig wurde das GlassFish-Projekt unter den Programmierern bekannt. Die Verwendung des frei verfügbaren Anwendungsservers fand mit durchschnittlich 3 Millionen Downloads pro Jahr einen hohen Anklang und konnte sich so verhältnismäßig schnell in der Entwicklerbranche etablieren. Mittlerweile ist der in Java entwickelte Anwendungsserver für viele verschiedene Plattformen, darunter Solaris, Windows und Linux, verfügbar und wird standardmäßig zusammen mit der Entwicklungsumgebung Java NetBeans, die ebenfalls aus dem Hause Sun Microsystems stammt, ausgeliefert.^[56]

Im September 2007 veröffentlichte die GlassFish-Community eine überarbeitete Version des Anwendungsservers, genannt "GlassFish v2". Diese Version des Anwendungsservers verfügt über sämtliche Funktionen der Vorgängerversion. Zusätzlich wurde GlassFish um Funktionen und Komponenten erweitert, die einen Garant für den Einsatz des Servers über die Entwicklergrenze hinaus darstellen. Die mitunter für den unternehmerischen Einsatz entwickelte Version wurde von Sun auf den Namen "Sun Java System Application Server 9.1." getauft und beinhaltet die folgenden Neuerungen, die einen reibungslosen Einsatz im Geschäftsbereich ermöglichen:^[56]

7.1.1 Hohe Verfügbarkeit und Skalierbarkeit

GlassFish v2 bedient sich zweier Technologien, um den geschäftlichen Anforderungen in Bezug auf Verfügbarkeit und Skalierbarkeit Gerecht zu werden. Das "Clustering" als eine dieser zwei Technologien stellt einen Verbund mehrerer GlassFish v2-Instanzen dar, der jeweils einer Domäne zugewiesen werden kann. Die Anzahl an Server-Instanzen innerhalb eines Clusters, sowie die Anzahl einer Domäne zugewiesener Cluster sind hierbei frei konfigurierbar. So ist es möglich, das Leistungspotenzial pro Domäne entsprechend der hier benötigten Ressourcen zu skalieren und dadurch ein konstantes Leistungsniveau zu halten. Den Kern des Clustering stellt das sogenannte "memory replication" - also das Nachbilden bzw. abgleichen des Speichers dar. Hierbei steht jede Serverinstanz mit jeweils einer weiteren Serverinstanz als Interaktionspartner in Kontakt. Die so verbundenen Serverinstanzen tauschen regelmäßig Informationen über Benutzer, Sitzung und zugehörige Daten aus und gleichen diese untereinander ab. Tritt ein Komplikationsfall bei einer der in dem Cluster enthaltenen Serverinstanzen auf, so wird die in der betroffenen Instanz geführte Sitzung über den "Load Balancer" auf eine andere Server-Instanz - den Interaktionspartner - umgeroutet und kann dort verlustfrei weitergeführt werden.^[56]

Die folgende Illustration veranschaulicht die Zusammenhänge zwischen den einzelnen Serverinstanzen und den Vorgang des Umroutens einer Session auf eine andere Instanz:

Abbildung 4: Speicherreplikation und Komplikationshandling, Angelehnt an: java.sun.com

Die zweite Technologie, derer sich GlassFish bedient um einen konstant hohen Verfügbarkeitslevel zu erreichen, ist die sogenannte "High-Availability Database (HADB)" Technologie. Diese wurde bereits in früheren Versionen des Sun Java System Application Server eingesetzt und findet ebenso in GlassFish ihren Platz. Unter Verwendung von HADB wird eine Datenverfügbarkeit von 99,999% innerhalb der Serverumgebung erreicht. Im Gegensatz zu GlassFish selbst ist HADB zwar kein Open-Source-Projekt, steht aber dennoch unentgeltlich zur Verfügung. Durch die Implementierung der HADB-Technologie in GlassFish wird gleichermaßen die Option gegeben, persistente Daten zu erzeugen.^[56] Mittels dieser persistenten Daten ist es beispielsweise möglich, sitzungsbezogenen Daten dauerhaft zu speichern oder transaktionsbezogene Daten derart bereitzustellen, dass mehrere Clients zeitgleich hierauf zugreifen können.^[57]

7.1.2 Hochgradige Performance

GlassFish ist der z.Zt. schnellste Open-Source-Anwendungsserver. So wurden in Tests auf einem Sun Fire T2000 Server durchgeführt, bei denen GlassFish Performance-Werte erzielte, die die Werte marktführender Alternativ-Systeme teilweise bis zu 20 Prozent übertrafen. Mitunter für diesen Performance-Zuwachs verantwortlich war eine Reihe von Technologien im Bereich der Web-Services, die als Paket unter dem bereits erwähnten Namen "Metro" geführt werden und fester Bestandteil von GlassFish sind. Die Konzentration innerhalb des Metro-Pakets liegt dabei in den folgenden Bereichen:^[58]

• Datentransport
• Ausfallsicherheit
• Arbeitsvorgänge
• Sicherheit

7.1.3 Einfache Konfiguration über Profile

Neben der Möglichkeit, das Serververhalten manuell zu konfigurieren und auf die jeweiligen Bedürfnisse eines jeden zuzuschneiden, gibt es bei GlassFish sogenannte Konfigurationsprofile. Die Implementierung dieser Profile in GlassFish beruht auf der Idee, die Serverkonfiguration ohne größeren Zeitaufwand möglichst passgenau einstellen zu können. Zu diesem Zweck unterscheidet GlassFish zwischen drei wählbaren Profilen:^[56]

• Developer (Entwickler)
• Cluster (Gerätegruppe)
• Enterprise (Unternehmen)

Wie seiner Bezeichnung bereits zu entnehmen ist, werden unter Nutzung des Entwicklerprofils Einstellungen und Verhaltensweisen des Servers umgesetzt, die speziell auf den Bereich Softwareentwicklung zugeschnitten sind. Aspekte wie Sicherheit, das Führen einer Aktivitätshistorie oder Speicherreplikation werden hier beispielsweise in den Hintergrund gerückt, während dem schnellen Starten des Servers selbst sowie der darauf befindlichen Anwendungen eine höhere Priorität zugewiesen wird. Das Cluster-Profil sieht Einstellungen vor, die beispielsweise das bereits beschriebene Feature der Clusterbildung aktivieren, um die Systemsicherheit und -verfügbarkeit höchstmöglich anzusiedeln. Das Profil "Enterprise" wurde für den Einsatz von Anwendungsservern in Produktivbetrieben außerhalb der Softwareentwicklung entwickelt, und sieht vorrangig Sicherheitseinstellungen wie beispielsweise das Führen einer Aktivitätshistorie vor.^[56]

Die folgende Tabelle bietet eine Übersicht über die drei implementierten Profile zusammen mit ihren grundlegenden Einstellungen:

Profilbezeichnung	Beschreibung	Developer	Cluster	Enterprise
Security store	Art und Weise, wie mit sensiblen Daten verfahren wird. Es gibt zwei verschiedene Typen des Security store: JKS (Java Key Store), die von Sun eigens entwickelte Variante, und NSS (Network Security Services), eine Sammlung verschiedener Bibliotheken, die vorrangig die plattformübergreifende Entwicklung auf sicherheitsaktivierten Servern unterstützen. Die wählbaren Storetypen können jeweils mit unterschiedlichen Tools konfiguriert werden. Für Enterprise-Lösungen wird typischerweise der NSS-Storetyp präferiert.	JKS	JKS	NSS
Quick startup	Option, die einen schnellen Serverstart ermöglicht.	true (aktiviert)	false (deaktiviert)	false (deaktiviert)
JVM	Konfigurationsparameter für eine Java Virtual Machine.	Konfigurationsparameter für eine Hotspot-VM	Konfigurationsparameter für eine Hotspot-VM	Abhängig von dem vorhandenen JDK
Session replication	Option, um den Replicationsmechanismus zu aktivieren / deaktivieren.	-	"In-memory" Replikation	HADB

Tabelle 4: Konfigurationsprofile eines GlassFish v2 Anwendungsservers, Entnommen aus: java.sun.com

7.1.4 Interoperabilität mit .NET

Wie bereits erwähnt ist, neben vielen anderen Funktions- und Servicepaketen, auch das Paket "Metro" in GlassFish enthalten, welches verschiedene Technologien für den Bereich Webservice bereit stellt. Neben den implementierten Diensten verfügt dieses Paket auch eine Schnittstelle zu dem sogenannten "Windows Communication Foundation" (WFC), dem Webservice-Paket aus Microsofts .NET Framework. Sowie Metro als auch WCF verfügen über einheitliche Webservice-Spezifikationen, die im Allgemeinen als "WS*-Spezifikationen" bezeichnet werden. Hierüber wird eine sichere und transaktionsorientierte Möglichkeit geschaffen, Systemübergreifend zu agieren. Die Implementierung dieser WS*-Spezifikationen im Metro-Paket wird daher als "Web Service Interoperability Technology" (WSIT) bezeichnet.^[56]

Das Prinzip der Interaktion zwischen Metro und dem .NET Framework kann der nachfolgenden Grafik entnommen werden:

Abbildung 5: Interaktion von Metro und .NET, Angelehnt an: java.sun.com

7.1.5 JBI Ready

JBI (Java Business Integration) bezeichnet einen Standard, der auf die Strukturierung von Systemlandschaften abzielt. Er beschreibt Systeme, die eine möglichst hohe serviceorientierte Architektur (SOA) aufweisen und umfangreiche Integrationsmöglichkeiten bieten. "Konzeptionell ist er darauf ausgelegt, mittels einer Vielzahl von Adaptern und Wrappern verschiedene Technologien aufseiten der Service Provider in das System einzubinden und diese unter entsprechenden Service Endpoints freizuschalten."^[59] Die Freischaltung erfolgt hierbei über die JBI-Laufzeitumgebung. Sie enthält mitunter den "Normalized Message Router" (NMR), über welchen Applikationen und implementierte Dienste nachrichtenbasiert miteinander kommunizieren und Daten austauschen können.^[56] Auf diesem Standard basierend ist in GlassFish das "Open ESB" integriert. "ESB" steht hierbei für "Enterprise Service Bus" und beschreibt eine "zentrale Komponente bei der Verbindung von Diensten"^[60], die insbesondere dann sinnvoll eingesetzt werden kann, wenn es sich bei den betreffenden Systemen um SOA-basierte Systeme handelt. Ein ESB ist prinzipiell nichts anderes als ein geschnürtes Funktionspaket, mit dessen Hilfe Standardoperationen wie Meldungsübertragung, Routingaufgaben und die Integration anderer Systeme abgehandelt werden können. Diese grundlegenden Operationen werden innerhalb des JBI-Standards von drei wesentlichen Komponenten übernommen:^[61]

• Binding Component (Empfangen und Senden von Meldungen)
• Service Engine (Schnittstellen und Formatkonvertierungen)
• Normalized Messaging Router (Versand und Routing von Nachrichten)

Da die Open-ESB Implementierung in GlassFish auf dem JBI basiert ist es möglich, dem gegebenen Funktionsumfang zusätzliche Komponenten hinzuzufügen bzw. wieder zu entfernen. So ist es möglich die Systemlandschaft entsprechend der individuellen Bedürfnisse eines Unternehmens oder eines Unternehmensverbundes anzupassen.^[56]

Die folgende Grafik veranschaulicht die Implementierung des JBI-Standards in einem GlassFish Anwendungsserver:

Abbildung 6: JBI-Standard in GlassFish, Angelehnt an: java.sun.com

Die einzelnen Binding Components (in der obigen Grafik mit "BC" abgekürzt) stellen die Schnittstelle zur Außenwelt dar. Sie sind Bestandteil der JBI-Laufzeitumgebung und übernehmen die Aufgabe, Nachrichten, die über verschiedene Protokolle von außen an das System gerichtet werden in NMR-konforme Nachrichten zu übersetzen und im Umkehrschluss, Nachrichten die innerhalb der JBI-Laufzeitumgebung an die Außenwelt gerichtet sind, in das jeweilige Protokollformat zu pressen. Wegen ihrer Verbindung zu speziellen Protokollen werden diese Binding Components im Allgemeinen auch als "Protocol Binding Component" (PBC) bezeichnet.^[62]

7.1.6 Ausgeprägte Kommunikationsdienste

Um eine effiziente Verbindung unterschiedlicher, betriebsübergreifender Softwarelösungen zu forcieren, verfügt GlassFish über eine Implementierung des ebenfalls javabasierten Nachrichtenstandards JMS (Java Message Service). Wie auch im Falle von GlassFish selbst, handelt es sich hierbei um eine Open-Source-Lösung. Geführt unter dem Namen Open Message Queue (Open MQ), stellt diese Open-Source-Lösung einen vollständigen Messaging Server, der sowohl als Integrationsvariante von GlassFish als auch eigenständig ausgeführt werden kann. In letzterem Falle sind Konfigurationseinstellungen über eigens vorhandene Administrationstools problemlos vorzunehmen. Mit Open MQ als Lösung für nachrichtenbasierte Operationen garantiert GlassFish eine zuverlässige Zustellung von Nachrichten in jener Reihenfolge, in der Sie von den jeweiligen Absendern versandt worden sind. Applikationen, die Open MQ für den Nachrichtenaustausch untereinander verwenden, können nach dem Versand einer Nachricht an eine andere Applikation direkt mit der Bearbeitung noch ausstehender Operationen fortfahren, ohne zuvor die Zustellung der Nachricht an ihren Empfänger abwarten zu müssen. Dieses Verfahren wird als "asynchrones" Nachrichtenmanagement bezeichnet. Nachrichten können auf zwei Arten versendet werden: Entweder direkt von Sender zu Empfänger, wobei hier die betreffende Nachricht einer Warteschlange hinzugefügt wird, in der Sie verweilt bis die Anwendung, die als Empfänger vorgesehen ist, diese wieder aus der Warteschlange entfernt und damit gleichzeitig den Empfang der Nachricht quittiert. Im zweiten Fall findet das sogenannte "Publish-Subscribe"-Ansatz Anwendung.^[56] Die sendende Anwendung (Publisher) zielt in diesem Fall nicht direkt auf konkrete Empfänger ab, sondern sendet seine Nachricht an einen zwischengelagerten Verteiler (Topic). Auf diese Weise erfahren alle versendeten Nachrichten quasi eine Unterteilung in verschiedene Nachrichtenklassen. Darüber hinaus ist jede Applikation für sich in der Lage, beliebig viele Klassen von Nachrichten bzw. "Topics" zu abonnieren, wodurch sie automatisch alle Nachrichten empfängt und in der Folge auch als empfangen quittiert, die an die jeweils abonnierten Topics gesendet werden. Die empfangenden Applikationen übernehmen hierbei die Rolle der sogenannten "Subscriber" innerhalb des Publish-Subscribe-Modells. Dadurch, dass der Sender seine Nachricht immer an eine zwischengelagerte Instanz bzw. an eine Topic sendet, bleibt er gänzlich von den Empfängern selbiger unabhängig. Jeder Empfänger erhält im eigentlichen Sinne eine Kopie der in einer Topic bereit gestellten Nachricht.^[63]

Die folgende Illustration veranschaulicht den Nachrichtenversand über den Publish-Subscribe-Ansatz:

Abbildung 7: Nachrichtenversand über den Publish-Subscribe-Ansatz, Angelehnt an: Langner, T. (2005), S. 568

Prinzipiell funktioniert dieses Modell so ähnlich wie es beispielsweise auch beim Rundfunk der Fall ist. Unabhängig davon ob es sich nun um ein Radio oder um einen Fernseher handelt: Grundsätzlich ist es hierbei auch so, dass der jeweilige Endverbraucher (Subscriber) selbst bestimmt, welche Programme bzw. Sendungen (Topics) er von welchem Sender (Publisher) konsumiert. Wenn ein Endverbraucher einen bestimmten Radio- oder Fernsehsender bzw. dessen Sendungen nicht konsumiert - möglicherweise auch über einen längeren Zeitraum hinweg - dann hat dies nicht zur Folge, dass der Sender, dessen Inhalte nicht konsumiert werden auch gleichzeitig die Publikation letzterer einstellt. Er wird seine Inhalte weiterhin publizieren, ist also unabhängig von seinen Konsumenten.

Neben dem beschriebenen Publish-Subscribe-Ansatz unterstützt GlassFish auch die Möglichkeit, Nachrichten über das Point-to-Point (P2P) Verfahren zwischen verschiedenen Anwendungen auszutauschen. Hierbei ist es so, dass jeder Empfänger von Nachrichten über eine Warteschlange verfügt, in welcher zugesandte Nachrichten gesammelt und zur Abholung durch den Empfänger vorgehalten werden. Erst wenn eine Nachricht durch den Empfänger aus der Warteschlange abgeholt worden ist, gilt diese Nachricht als verbraucht und kann in der Folge nicht länger abgerufen werden. Auch wenn ein Empfänger nicht verfügbar ist werden Nachrichten über die Warteschlange vorgehalten und können quasi nachträglich von dem Empfänger abgeholt bzw. konsumiert werden. Dieser Sachverhalt wird "Persistenz" genannt und stellt den wesentlichen Vorteil des P2P-Verfahrens dar.^[64] Werden Nachrichten hingegen über den Publish-Subscribe-Ansatz versendet und ist einer der Subscriber zum Zeitpunkt des Nachrichtenversands nicht verfügbar, so wird ihm auch keine Kopie dieser Nachricht zugesandt. Abhilfe kann hier über die Einrichtung eines dauerhaften Abonnements (Durable Subscriber) geschaffen werden. Bei Nichtverfügbarsein eines Subscribers werden alle ihm zugestellten Nachrichten zwischengespeichert und gesammelt zugestellt, sobald dieser wieder verfügbar ist.^[65]

7.1.7 Zusammenspiel mit Enterprise Java Beans

  "Zusammenkommen ist ein Beginn, zusammenbleiben ist ein Fortschritt, zusammenarbeiten ist ein Erfolg."
   - Henry Ford, 30.07.1863 - 07.04.1947

Nicht alle der oben angeführten Features von GlassFish können direkt mit Enterprise JavaBeans in Verbindung gebracht werden. Einige dieser Features, wie beispielsweise die Konfigurationsmöglichkeit des Servers über eingebundene Profile oder die Interoperabilität mit Microsofts .NET Framework, zielen lediglich darauf ab, den Einsatz von GlassFish möglichst komfortabel zu gestalten und den Server selbst mit einer gewissen Flexibilität zu versehen. Andere Bereiche des Servers lassen jedoch verschiedene Verbindungen zu Enterprise JavaBeans erkennen, die sich in Summe über nahezu das gesamte Spektrum des EJB-Paketes ab der Version 3 erstrecken.

EJB Entity Bean

Im Bereich der Verfügbarkeit und Skalierbarkeit wird über die integrierte HADB-Technologie Datenpersistenz nutzbar, die mittels der über EJB bereit gestellten Entity Beans umgesetzt wird. GlassFish nutzt diese Technologie, um einzelne Sitzungen über einen längeren Zeitraum hinweg erhalten zu können und die Daten solcher Sitzungen im Bedarfsfall mehreren Teilnehmern bzw. mehreren Clients zur Verfügung zu stellen. Die Bindung an EJB bzw. die Nutzung der Entity Beans in diesem Bereich bringt gleichermaßen den Vorteil mit sich, dass in Sitzungen genutzte Daten über beispielsweise einen Serverabsturz hinaus bestehen bleiben.^[66]

EJB Message Driven Bean

Die Möglichkeit der asynchronen Nachrichtenverarbeitung in GlassFish stützt sich auf die Systematik der Message Driven Beans aus dem Paket der Enterprise Java Beans. Die Message Driven Beans fungieren hierbei ähnlich "wie ein Message Listener eines Java Message Service (JMS) ..., welcher wiederum einem Java Event Listener ähnlich ist, jedoch anstelle von Ereignisse Nachrichten verarbeitet."^[67]. Asynchron bedeutet, dass die Verarbeitungsprozedur, die beim Eintreffen einer Nachricht angestoßen wird, unabhängig von dem Absender der Nachricht ist. Besser noch: Der Absender einer Nachricht ist unabhängig von der Verarbeitungsprozedur, die seine Nachricht über die Message Driven Bean auslöst - muss also nicht auf ein Verarbeitungsergebnis warten. Als Beispiel könnte ein automatisierter Druck von Rechnungen herangezogen werden: Das Modul, welches Bestellungen entgegen nimmt, diese Bucht und zuletzt den Druck von Rechnungen auslöst, kann auch weiterhin Bestellungen entgegennehmen und diese Buchen, während das Modul für den eigentlichen Rechnungsdruck das relativ aufwendige und zeitintensive Druckprozedere durchführt.^[68]

EJB Webservice

Da Open ESB der JBI-Standard zugrunde liegt und Open ESB Bestandteil von GlassFish ist, kann hieraus eine Verbindung zum Webservice des EJB-Pakets hergeleitet werden. Über verschiedene Instanzen innerhalb von GlassFish, vor allem aber innerhalb der JBI-Laufzeitumgebung, wird der Webservice für die Außenwelt zugänglich gemacht. Die verschiedenen Binding Components der JBI-Laufzeitumgebung dolmetschen dabei im übertragenden Sinne die Anfragen, die von der Außenwelt mittels verschiedener Protokolle gestellt werden so, dass eine reibungslose Weiterverarbeitung innerhalb der JBI-Laufzeitumgebung über den Normalized Message Router möglich wird. Über die Sun Java EE Engine werden Anfragen zum Webservice der Enterprise JavaBeans weiter gereicht und gelangen im Umkehrschluss hierüber auch wieder - über die JBI-Laufzeitumgebung und schließlich die jeweils entsprechenden Binding Components - in die Außenwelt zurück.

EJB Session Bean

Wie bereits zu oberst erwähnt besteht in GlassFish die Möglichkeit, über den implementierten JBI-Standard und unter Nutzung der Webservices Teile einer Geschäftslogik für die Außenwelt freizugeben. Für derartige Funktionen sind die ebenfalls bereits vorgestellten Session Beans von elementarer Bedeutung. Sie stellen im übertragenden Sinne die direkte Schnittstelle zwischen externen Clients und der internen Geschäftslogik dar und stellen vorgegebene Methoden für das Zusammenspiel von Clients und Geschäftslogik zur Verfügung. In Abhängigkeit von der Komplexität der innerhalb der bereitgestellten Methoden durchzuführenden Aktionen sind Stateless Session Beans ebenso von Belang wie ihr Pendant, die Stateful Session Beans.

7.2 JBoss

Der JBoss Application Server mit seinen Plattformen und Framework-Distrubutionen wurde vom Unternehmen Red Hat entwickelt und ist einer der verbreitetsten Java Application Server. Das Unternehmen selbst beschreibt sich als führender Anbieter für Middleware Software in der Enterprise Klasse. Die Software selbst ist als Open Source Projekt frei im Internet abrufbar und einsetzbar.^[69]

7.2.1 Konfiguration

JBoss ist stark konfigurierbar, was sich durch den sogenannten JMX Mikrokernel ergibt. Dieser Kernel verwaltet die Beans, welche die zahlreichen Services im Server verwendbar macht. Die Kernfunktionen stehen nach der Installation ohne weitere Konfigurationen zur Verfügung. In der Serverdokumentation wird der Kernel als Rückgrat des Servers beschrieben. Was darauf zurück zu führen ist, das in der Minimalkonfiguration der Kernel des Servers für alle autonomen Kernfunktionen funktionsfähig ist. An das Rückgrat lassen sich anschließend verschiedenste Anwendungen, Bildlich gesprochen, anhängen. Dadurch wird ein hohes Maß an Flexibilität erreicht. Diese flexible Nutzung des JBoss Servers lassen ihn für kleine Anwendungen ebenso sinnvoll einsetzen, wie für große Server Applikationen. Als Standard-Konfiguration lassen sich, wie in der nachfolgenden Tabelle dargestellt, zwei Server Konfigurationen wählen.

Konfiguration	Beschreibung
Minimal	Bei der minimalen Konfiguration werden nur die Services zur Verfügung gestellt, die in einer einfachen Anwendung benötigt werden. EJB werden bei dieser Installation nicht unterstützt. ebenso wie Webservices, JMS und weiterer High-Level Services.
Default	Bei der Default Konfiguration werden die gebräuchlichsten J2EE Services installiert. Das nachfolgend beschriebene Clustering muss allerdings zusätzlich konfiguriert werden.

Tabelle 5: Konfigurationen der JBoss Installation, Vgl. Richards, N (2006), S. 9

Bei der Default Konfiguration ist der EJB 3.0 spezifische Container verfügbar, wenn der JBoss Server mit einer aktuellen Version installiert wird. Alle bisher beschriebenen Beantypen können somit ohne weitere Konfiguration oder Installation von weiteren Javaklassen verwendet werden.^[70]

7.2.2 Clustering

Einer der wichtigsten Eigenschaften eines verteilten Softwaresystems besteht in der Skalierbarkeit der JEE Anwendung. Dies ist auch eines der wichtigsten Merkmale dieser Architektur, mit der umfangreich geworben wird. Thematisiert wird beim Thema Skalierbarkeit, wie viele Transaktionen und Benutzeranfragen bearbeitet werden können, ohne die Sicherheit des Systems zu gefährden. EJB Clustering mittels JBoss lässt sich mit drei zu erfüllenden Merkmalen einfordern die durch den JBoss Application Server angeboten werden. Die Lastverteilung, Erreichbarkeit und die Fehlertoleranz. Die Lastverteilung kann dabei durch Verwendung mehrerer Server erreicht werden. Diese können die Performance in einem sogenannten Cluster erhöhen. Die Erreichbarkeit der Serverdienste soll möglichst hoch sein. Außerdem ist Transaktionssicherheit und Datenkonsistenz beim auftreten von Fehler sehr wichtig. Um diesen Anforderungen gerecht zu werden, ist es möglich, jedem JBoss Server einer Partition zuzuordnen. Begrifflich ist ein Cluster das selbe wie eine Partition. Allerdings wird beim JBoss Applikation Server in diesem Zusammenhang hauptsächlich der Begriff Partition verwendet. Nun ist es möglich mehrere Server in einer Partition laufen zu lassen. Die JBoss Instanzen können dabei mehreren Partitionen zugeordnet werden. Dadurch entstehen Knotenpunkten mehrere Partitionen. Der Nutzen dieser Partitionierung kann folgendermaßen beschrieben werden. Sobald ein Client eine Anfrage an einen Server stellt, und seine Anfrage nicht entsprechend weitergeleitet wird, kann der Client eine weitere Anfrage senden um einen anderen Server zu erreichen. Dieses Clientseitige vorgehen wird "Failover Client managed" bezeichnet. Ein weiteres Konzept ist das "Dispatcher Managed Failover". Hierbei wird eine Anfrage durch eine Komponente, dem Dispatcher, verwaltet. Bei einer fehlerhaften Anfrage an den Serverdienst werden die Daten durch den Dispatcher neu vom Client angefordert und an einen anderen Server weiterleiten. Fällt der Dispatcher aus, ist die Datensicherheit und Konsistenz wieder gefährdet. Die Dritte Möglichkeit ist die Verwendung des "Smart Proxy". Dabei wird bei jeder Anfrage die der Client ausführt, eine Liste über die verfügbaren Zielknoten von einem Proxyserver geladen. Diese Variante ermöglicht es, die Lastverteilung und Datensicherheit zur Laufzeit zu ändern. Veränderung der Topologie der Partitionen werden ebenfalls übermittelt. Nachteilig ist zu erwähnen, das die Abhängigkeit des Client vom Proxy an dieser Stelle gewährleistet sein muss. Als letzte Variante ist der "Clustered Naming Service" zu nennen. Dabei wird bei der Anfrage des Clients auf eines der Knotenpunkte jedes gebundene Objekt auf alle anderen Knotenpunkte repliziert. Dadurch beinhaltet jeder Knoten jede Information, die angefragt wird, und kann gegebenenfalls angesprochen werden, sollte es zu einem Ausfall kommen.^[71]

7.2.3 Performance

Die Performance in Bezug auf die Antwortzeiten, spricht die Reaktion des Systems auf die Anfragen der Benutzer, wird nun folgend beschrieben. Dabei kann die Antwortzeit von einer Benutzeranfrage zur nächsten sehr viel länger dauern, selbst wenn es sich dabei um die gleiche Anforderung handelt. Um dies Messbar zu machen, ist es daher Sinnvoll, immer die gleiche Anforderung an das System zu stellen, um die durchschnittliche Antwortzeit zu messen. Die Verarbeitungszeit lässt sich dabei von der Antwortzeit abgrenzen. Dabei wird bei der Verarbeitungszeit der Zeitpunkt vom Empfang der Anforderung des Systems bis zur Rückgabe der Anforderung an den Client berücksichtigt. Die Antwortzeit ist der Zeitabschnitt, der von der Benutzereingabe, sprich der Anforderung des Clients, bis zum erreichen dessen im System und Rückgabe der Antwort an den Client benötigt wird. Dieser Zeitabschnitt ist dadurch immer länger, als die Verarbeitungszeit. Dies Antwortzeit hängt im wesentlichen vom Kommunikationsnetzwerk ab. Der Datendurchsatz wird im Bezug auf die Performance ebenfalls bewertete. Dabei wird geschaut, wie viele Benutzeranfragen innerhalb eines bestimmten Zeitpunktes an das System gerichtet möglich sind. In der Praxis wird dafür ein sogenanntes SLA (Service Level) verwendet. Im SLA ist dann geregelt, wie hoch die Antwortzeit und der Datendurchsatz sein muss. Es gibt allerdings keine festgelegten Regeln, um für den JBoss Application Server die beste Performance zu erreichen. Dies hängt unter anderem von der Anzahl der Benutzer und auch der Datenmengen, die bewegt werden wollen, ab.^[72] Da es möglich ist, den Application Server und auch den Datenbankserver auf dem selben Rechner laufen zu lassen, oder aber beides getrennt, möglicherweise viele Application Server mit vielen Rechner zu betreiben, wird an dieser Stelle auf Rechenbeispiele zur Hardwareausstattung verzichtet.

7.2.4 Web Service mit JBoss

Durch die Integration von Web Services in die J2EE Version 1.4, muss dieser Dienst von jedem Application Service unterstützt werden. Vorher wurde ab der JBoss Version 3.2 das AXIS Projekt im JBoss integriert, welches später unter JBoss.NET modifiziert zum Einsatz kam. Die Folge der Integration des Web Sevices in die J2EE ist, das die Entwickler das Paket ändern mussten, da AXIS den Standard nicht voll erfüllen konnte. Daher wurde die Bibliothek angepasst und es entstand das Projekt JBossWS, Web Services for Enterprise Editon. Diese Bibliotheken entsprechen den Richtlinien des Web Services mittels EJB und die Herstellerunabhängigkeit wird gewahrt.

Laut Definition eines Web Services, sind diese von Natur aus zustandlos. Daraus ergibt sich, das für die Nutzung von EJBs bei Web Services nur zustandlose Session Beans verwendet werden können. Diese Beans haben die Aufgabe, den Clients alle Werte aus der Datenbank zu liefern. Dabei werden lokale und auch entfernte Clients unterstützt, um den Ansatz der Serviceorientierung zu erfüllen.^[73] Ein genaues Beispiel zur Einrichtung des Webservices wird an dieser Stelle aufgrund es Umfang und dessen Komplexität nicht gezeigt.

7.2.5 Datenbank in JBoss

Die Verwendung von Datenbanken mit JBoss wird, sofern sie mit EJBs realisiert wird, mit Entity Beans durchgeführt. Genauer gesagt, verwendet man dafür die CMPs, um den Verbindungsaufbau zur Datenbank zu realisieren und die SQL Abfragen durchzuführen. Diese Aufgabe übernimmt der JBoss Application Server. An dieser Stelle wird auf den direkte Zugriff vom Client auf die Datenbank nicht Bezug genommen. Diese Vorgehensweise ist allerdings ebenso möglich. Beim Einsatz des Application Servers kennt der Client bei seinen Anfrage, die Java Klassen nicht, die für den eigentlichen Datenbankzugriff verantwortlich sind. Der Entwickler der Anwendungssoftware braucht somit nicht mehr für die Programmierung der SQL Statements selbst zu sorgen. Diese können eigens per Konfiguration des Servers hinterlegt werden. Diese Vorgehensweise entspricht der Objektorientierten Sicht beim Zugriff auf relationale Datenbanken. Obwohl CMPs nicht abhängig vom Hersteller des Application Servers sind, gibt es dennoch in Bezug auf den JBoss Server Unterschiede. Im Deployment Deskriptor wird per Konfiguration festgelegt, auf welche Datenbank zugegriffen wird, wie die Spalten der Tabellen oder sogar dessen Namen definiert sind. Der Aufwand der Implementierung der Entity Beans bei Nutzung der CMP in JBoss ist daher etwas größer.^[74]

Die Entity Beans werden bei der Verwendung der Datenbank teilweise im Speicher gehalten. Dadurch das mehrere Clients die Beans verwenden können, ergeben sich daraus ggf. Probleme. Die Änderungen der Daten gelten für alle Clients, die über den selben Knoten ihre Anfragen stellen. Auch wenn diese Daten nur im Speicher zur Verfügung stehen. Beim Einsatz von mehreren Knoten bzw. Partitionen, wie im Kapitel Clustering beschrieben, werden die im Cache gespeicherten Daten nicht repliziert und dadurch nicht auf allen Partitionen aktuell gehalten. Aus diesem Grund müssen die Entity Beans entwertet werden. Den anderen Partitionen wird dabei mitgeteilt, das die Instanz nicht mehr gültig ist und gelöscht werden muss. Wird auf den selben Bean eine Anfrage gestellt, werden die Daten neu aus der Datenbank geladen. Der Vorteil dabei ist, das der Nachrichtenverkehr zur Entwertung der Instanzen geringer ist, als die eigentliche Replikation. Der Netzwerkverkehr wird bei dieser Vorgehensweise minimiert.

Es gibt allerdings auch Fälle, in der eine Anwendungen lange Zeit vorgehalten wird, ohne das sie aktiv ist. Die Verwaltung des Caches spielt in diesem Szenario eine große Rolle. Durch Passivierung wird in einem solchen Fall erreicht, das der zur Zeit nicht benötigte Cache in einem Sekundären Speicher geladen wird, sobald er anderweitig benötigt wird. Dafür wird ebenfalls die Datenbank oder zum Beispiel eine Festplatte verwendet. Wird die Anwendung nun wieder aktiviert, sorgt der Session Manager dafür, das die Daten zurückgeholt werden. Der Nachteil dieser Vorgehensweise ist die Verlangsamung der Antwortzeiten.^[75]

7.2.6 Zugriffsrechte

Die Nutzerverwaltung bzw. Rechteüberprüfung erfolgt hierbei durch das JAAS. Über diesen Dienst wird unter anderem der Login verwaltet, in dem Informationen über den Nutzer und dessen Passwort innerhalb einer Nutzerverwaltung geprüft wird. Die Nutzerverwaltung selbst kann auf verschiedene Weise angelegt sein. Als XML-Datei oder auch in der Datenbank selbst.^[76] JAAS wird aber nicht nur verwendet, um die Zugriffe auf die Datenbank zu steuern. Sie ist vielmehr dazu da, das Ausführen aller Instanzen zu verwalten. Dies beinhaltet auch den Zugriff auf einzelne Domänen und oder Klassen der Anwendung. Über die Anmeldemodule wird das Verhalten über die Sicherheitsdomäne gesteuert. Durch anlegen verschiedener Anmeldemodule wird eine Vielzahl von Sicherheitsdomänen mit verschiedensten Rechten erstellt. Die Anmeldung über JAAS wird nun nachfolgend dargestellt.

Sobald der Client sich nun über JAAS anmeldet, bekommt er seine Anmeldeinformationen und ist fortan für JBoss identifiziert. Die Anmeldung selbst erfolgt über Instanzen. Dabei wird die Anmeldeinstanz, welche nur einmal erzeugt wird, mit allen vorhandenen EJB-Methoden verknüpft. Zu beachten ist dabei, das der Client durch seine Instanz, die er auf dem Application Server hinterlässt, authentifiziert ist. Nicht der Benutzer selbst. Um die Anmeldung nun fortzuführen, erstellt der Client ein Bean, welches einen Aufruf einer JBoss Methode zur Folge hat. Die Benutzerinformationen werden dabei übergeben. Der Bean wird einer Anmeldedomäne zugeordnet, durch den Aufruf des Client. Abschließend prüft der Sicherheitsinterceptor die Authentifizierung in der entsprechenden Domäne. Die Prüfung bezieht sich dabei auf die Berechtigung des Benutzers zum Aufruf der angeforderten Methode. Ist die Prüfung erfolgreich, ist die Anmeldung des Clients vollständig und der Aufruf erfolgt.^[77]

7.2.7 Besonderheiten

Für einige Bereiche bieten die Server Hersteller selbst erstellte Erweiterungen an, die so nicht in der J2EE Spezifikation enthalten sind. Dabei werden die EJB-Container des Application Servers um Features ergänzt oder vorhandene Klassen erweitert. Beim JBoss sind dies unter anderem EJB-QL, eine SQL vereinfachte Sprache, die zur Erhöhung ihres Nutzen, durch den Hersteller erweitert wird. Auch bei der Verwendung von JAAS werden eigene Klassen und Methoden zur Verfügung gestellt, da die Spezifikationen nicht detailliert genug sind.^[78]

7.3 Websphere

WebSphere war ursprünglich der Name für den von IBM vertriebenen Application Server. Mit der Zeit dennoch wurde der WebSphere Application Server (WAS) um einige Produkte, wie zum Beispiel WebSphere MQ (Message Queueing) oder WebSphere Portal Server, ergänzt und bezeichnet heute somit eine ganze Produktlinie für Anwendungsintegration, Entwicklungsumgebung und Infrastruktur. Der WAS an sich ist eine Laufzeitumgebung für Java Platform, Enterprise Edition (Java EE) Anwendungen. ^[79]

7.3.1 Varianten

Der im Gegensatz zu JBOSS und GlassFish kommerziell vermarktete WAS ist im September 2008 in der Version 7 erschienen und bietet vollständige Unterstützung für Java EE 5.0, EJB 3.0, JPA, JDK 6.0. Zusätzlich zu den verschiedenen Varianten (Express, Base, Network Deployment, z/OS) stellt IBM mit der Community Edition 2.1 eine frei verfügbare Variante bereit des WAS bereit, welche komplett aus OpenSource besteht. Allerdings bietet diese Variante nicht alle Merkmale der kommerziellen Varianten, so fehlt zum Beispiel die Unterstützung für JDK 6.0. ^[80]

7.3.2 WAS und JAVA

Dass der WAS ein Java EE Application Server ist kommt nicht von ungefähr. IBM als einer der umsatzstärksten IT-System und –Technologieanbieter hatte stets das Problem für die heterogene Systemlandschaft viele Programmiersprachen unterstützen zu müssen. So erkannte IBM früh das Potential von Java für sich und gilt heute als einer der größten Förderer. Somit wurde IBM zu einem der meist engagierten Partner von SUN, dem Entwickler von Java, trotz der intensiven Konkurrenz auf Geschäftsfeldern, wie z.B. dem Application Server. ^[79]

7.3.3 WebSphere goes Cloud Computing

Im Rahmen der Impact 2009 hat IBM mit dem WebSphere Application Server Hypervisor Edition eine weitere Variante zur Verfügung gestellt, die für den Einsatz in den immer beliebter werdenden privaten Clouds optimiert wurde. So wurde die Software extra für den Betrieb auf von virtualisierter Hardware, zum Beispiel VMWare, erstellt. ^[81]

7.3.4 Unterstützte Hard- und Software

Um möglichst allen Anforderungen gerecht und in vielen verschiedenen Umgebungen eingesetzt werden zu können, unterstützt der WAS eine Vielzahl an Hard- und Software. Deswegen stellt die Aufzählung der wichtigsten Komponenten keine vollständige Liste dar. Genauere Details können unter anderem der Quelle entnommen werden.^[82]

Hardware

• IBM POWER Prozessoren
• PA-RISC Prozessoren
• Intel Itanium 2 Prozessoren
• Intel Pentium Prozessoren mit 500 MHz oder schneller / Intel EM64T oder AMD Opteron
• IBM System z Prozessoren
• SPARC Prozessoren

Betriebssysteme

• Microsoft Windows
• IBM AIX
• Linux
• Sun Solaris
• HP-UX
• IBM z/OS

Webserver

• Apache HTTP
• IBM HTTP Server für WebSphere
• Internet Information Services (IIS)
• Lotus Domino Enterprise Server
• Sun Java System Webserver
• Apache Geronimo

Datenbanken

• IBM DB2
• Oracle
• Microsoft SQL Server
• Sybase
• Informix
• WebSphere Information Integrator

Directoryserver

• Windows Active Directory
• Sun Java Directory Server
• Lotus Domino Enterprise Server
• IBM Tivoli Directory Server
• IBM z/OS Integrated Security Services
• IBM z/OS.e Security Server

7.3.5 Prozessarchitektur

Die mit Abstand meistgenutzten Verfahren um auf WebSphere Applikationen zuzugreifen ist über einen Browser der über ein Servlet oder ein JSP die Daten auf einer Webseite darstellt oder direkt durch eine Java Desktop Anwendung. In beiden Fällen kann so auf ein EJB des WAS zugegriffen werden.

Die "schlankere" Form der Clientkonfiguration ist die Webanfrage, da nicht mehr als ein Browser benötigt wird. Allerdings sind Webseiten bei sehr großen Datenmengen oder für schnelle Anwendungsinteraktion nicht so sehr geeignet. Für diese Anwendungsfälle eignet sich eher eine Java Desktop Client Applikation. Der Zugriff erfolgt dann meist über das Internet Inter-ORB Protocol (IIOP) oder über Remote Method Invocation (RMI). Bei der Anfrage über eine Webseite wird der Inhalt mit Hilfe von serverseitigen Servlets oder Java Server Pages (JSP) generiert. Beide Techniken ähneln sich sehr, da JSPs vom WebContainer in Servlets übersetzt werden. Servlets erweitern die Funktionalität eines Webservers indem sie in die zugewiesene Java Virtual Machine (JVM) geladen und dort ausgeführt werden. Der generierte Output wird an den Webbrowser zurückgeliefert. Anhand eines Aufrufs einer JSP soll der Vorgang noch einmal verdeutlicht werden (Vergleiche hierzu auch Schematische Darstellung Abb. 10). Auf Clientseite wird ein Browser gestartet und eine Zieladresse (URL) übergeben. Ein PlugIn im Webbrowser fängt den Request ab und leitet diesen an eine Instanz des WAS weiter. Das PlugIn stellt diese Beziehung aus einer Host+URL Kombination, die in einem XML-Konfigurationsfile vorliegen muss, her. Dabei ist eine WAS Instanz eine JVM die theoretisch beliebig viele JEE Anwendungen bereitstellen kann. Anhand der URI kann der WAS die vorgesehene JEE Anwendung aufrufen. Diese kann dann zum Beispiel weitere Enterprise Anwendungen aufrufen oder Inhalt aus einer Datenbank abrufen. Am Ende jedoch wird dem Benutzer ein Ergebnis in Form einer Webseite im Browser angezeigt, nachdem die Daten dem JSP vom Webbrowser aufbereitet wurden. ^[83]

7.3.6 WAS und Persistenz

Mit dem im WAS Environment integrierten Versionen von EJB3.0 und Java EE 5 (bzw. Java EE 6) wurden auch neue Persistenz-Funktionen bzw. die Java Persistence API (JPA) eingeführt. Der WAS 7 realisiert die Persistenz-Funktionen durch die Implementation von Apache OpenJPA, ebenso wie bereits die Apache Axis2 Web Service Engine implementiert wurde.^[84] Die Funktionen stehen auch direkt den Webclients oder Java Clients zur Verfügung und nicht nur den Anwendungen im EJB Container.^[85]

7.4 WebLogic

WebLogic von Oracle ist wie IBMs WebSphere eine kommerzielle Serveranwendung. WebLogic wurde von der Firma BEA 1990er Jahren entwickelt und erstmalig eingesetzt. BEA wurde im Jahr 2008 von ORACLE aufgekauft, das Produkt WebLogic ist somit seit diesem Zeitpunkt Bestandteil des ORACLE Produktportfolios und wird unter dem Namen Oracle WebLogic Server vertrieben.^[86]

7.4.1 Übersicht über Versionen und Umfang

Web Logic ist in drei verschiedenen Editionen erhältlich, der Standart- und der Enterprise-Edition sowie der WebLogic Suite. Die Versionen unterscheiden sich in der Anzahl der enthaltenen "Bausteine". Die nächsthöhere Version enthält immer alle "Bausteine" der kleineren Version, die letzte Version beinhaltet somit sämtliche Bausteine. Interessanteste Veränderung von der Standart- zur Enterprise-Edition ist die in der Standart-Edition nicht vorhandene Komponente Oracle WebLogic Clustering. ^[87]

7.4.2 Anforderungen an Hardware

Für die aktuelle Version 10.3 von WebLogic werden seitens Oracle einige Hard- und Softwarekombinationen als mögliche Systemkonfigurationen zusammen mit einem jeweils zu der entsprechenden Konfiguration passenden JDK genannt. Während hardwareseitig lediglich ein Prozessor der Intel-x86 Serie genannt wird, sind in dem für Serversysteme interessanteren 64-Bit-segment eine Reihen von untertützten Prozessortypen angegeben. Diese sind:

• Itanium-2
• PA-RISC
• POWER
• Intel EM64T
• AMD 64
• Sun SPARC^[88]

7.4.3 Anforderungen an Software

WebLogic ist unter verschiedenen Betriebssystemen lauffähig. Die aktuelle Version 10.3 benötigt als Plattform eines der nachfolgend angeführten Betriebssysteme. Der jeweilige benötigte Stand ist sofern angegeben in den nachtehenden Klammern spezifiziert:

• AIX 5.3 TL7+
• HP-UX 11iV2 (11.23)
• SLES 9 (SP3+)
• SLES 10
• Solaris 9
• Solaris 10
• Oracle Enterprise Linux 4 (Update 6+)
• Oracle Enterprise Linux 5.x
• Oracle Enterprise Linux 4 (Update 6+) on Oracle VM
• Red Hat Enterprise Linux 4 (Update 3+)
• Red Hat Enterprise Linux 5.x
• Windows 2003 with SP1+ (includes Windows 2003 R2)
• Windows 2008 (includes SP1+)^[88]

7.4.4 JDK / Entwicklungsumgebungen

Als Entwicklungsumgebungen bzw. Java Development Kits (JDK) werden seitens Oracle die folgenden Typen und Versionen genannt:

• HP 6.0_01+
• HP 6.0_02+
• IBM 1.6.0 (SR2, SR4)
• Azul 1.6 (AVM 2.5.0.2)
• JRockit 6.0 (R27.6.0+)
• Sun 1.6.0_05+^[88]

	32 Bit JDK
Prozessor / OS	Azul 1.6 (AVM 2.5.0.2)	JRockit 6.0 (R27.6.0+)	Sun 1.6.0_05+
Intel (x86) Windows 2003 with SP1+ (includes Windows 2003 R2)		X	X
Intel (x86) Windows XP ("Client Only" and "Development" Support)		X	X
Intel (x86) Windows Vista ("Client Only" and "Development" Support)		X	X
Intel (x86) SLES 9 (SP3+)		X
Intel (x86) SLES 10		X
Intel (x86) Oracle Enterprise Linux 4 (Update 6+)		X
Intel (x86) Oracle Enterprise Linux 5.x		X
Intel (x86) Oracle Enterprise Linux 4 (UL1+)		X
Intel (x86) Oracle Enterprise Linux 5.x on Oracle VM		X
Intel (x86) Red Hat Enterprise Linux 4 (UL1+)	X	X
Intel (x86) Red Hat Enterprise Linux 5.x	X	X
Intel (x86) Solaris 9			X
Intel (x86) Solaris 10			X

Tabelle 6: WebLogic in 32-Bit-Varianten, Angelehnt an: http://www.oracle.com/technology/software/products/ias/files/oracle_wlp_certification_10gr3_matrix.xls

	32 Bit JDK						64 Bit JDK
Prozessor / OS	Azul 1.6 (AVM 2.5.0.2)	HP 6.0_01+	HP 6.0_02+	IBM 1.6.0 (SR2, SR4)	JRockit 6.0 (R27 6.0+)	Sun 1.6.0_05+	Azul 1.6 (AVM 2.5.0.2)	HP 6.0_01+	HP 6.0_02+	IBM 1.6.0 (SR2, SR4)	JRockit 6.0 (R27 6.0+)	Sun 1.6.0_05+
Intel EM64T, AMD64 Oracle Enterprise Linux 4 (Update 6+)					X					X
Intel EM64T, AMD64 Oracle Enterprise Linux 4 (Update 6+) on Oracle VM					X					X
Intel EM64T, AMD64 Oracle Enterprise Linux 5.x					X					X
Intel EM64T, AMD64 Oracle Enterprise Linux 5.x on Oracle VM					X					X
Intel EM64T, AMD64 Red Hat Enterprise Linux 4 (Update 3+)	X				X		X			X
Intel EM64T, AMD64 Red Hat Enterprise Linux 5.x	X				X		X			X
Intel EM64T, AMD64 SLES 10					X					X
Intel EM64T, AMD64 SLES 9 (SP3+)					X					X
Intel EM64T, AMD64 Solaris 10						X
Intel EM64T, AMD64 Solaris 9						X
Intel EM64T, AMD64 Windows 2003 with SP1+ (includes Windows 2003 R2)					X					X
Intel EM64T, AMD64 Windows 2008 (includes SP1+)					X					X
Itanium-2 HP-UX 11iV2 (11.23)		X						X
Itanium-2 HP-UX 11iV3 (11.31)		X						X
PA-RISC HP-UX 11iV1 (11.11)			X
PA-RISC HP-UX 11iV2 (11.23)			X
PA-RISC HP-UX 11iV3 (11.31)			X
POWER AIX 5.3 TL7+	X			X			X		X
POWER AIX 6.1 Gold (6.1 TL0+)				X					X
Sun SPARC Solaris 10	X					X	X			X	X
Sun SPARC Solaris 9	X					X	X			X	X

Tabelle 7: WebLogic in 64-Bit-Varianten, Angelehnt an: http://www.oracle.com/technology/software/products/ias/files/oracle_wlp_certification_10gr3_matrix.xls

7.4.5 Interaktion mit EJB

7.4.5.1 Transaktionen

WebLogic unterstützt zwei EJB-Transaktionstypen, die Container-managed Transaktion sowie die Bean-managed Transaktion. Im ersteren verwendet der EJB-Container die Standart-XML-Informationen um die Befehlsinformationen zu verarbeiten, im zweiten sind die jeweiligen befehle im EJB-Container hinterlegt, spezielle Befehlsaufrufe wie begin und rollback sind nicht explizit im Befehl aufzuführen^[89]

7.4.5.2 EJB Klassen

WebLogic unterstützt die nachfolgend aufgeführten Klassen:

• Session beans
• Entity beans
• Message-Driven Beans

Diese Klassen sind in dem WebLogic package WebLogic.ejp enthalten und sind sämtlichst abstrakte Klassen. Die Klassenbezeichnung im package sind entsprechend der vorgenannten Auflistung

• GenericSessionBean
• GenericEntityBean
• GenericMessageDrivenBean^[90]

7.4.5.3 WebLogic und EJBGen

EJBGen ist ein Codegenerator für die EJB 2.0. EJBGen wird von WebLogic unterstützt, hierdurch vermindert sich der Konfigurationsaufwand erheblich. An Stelle einer Vielzahl von Java-Klassen und XML-Dateien muss lediglich eine Java-Datei hinterlegt werden, mit dieser können nun mit Hilfe von EJBGen nahezu alle anderen Einstellungen automatisch vorgenommen werden.^[91] . Um EJBGen in WebLogic zu muss es über die Kommandozeile aktiviert werden.^[92]

7.4.5.4 WebLogic EJB-QL und CMP

WebLogic unterstützt den vollen Umfang der der EJB-QL. Der Funktionsumfang der EJB-QL wird aber WebLogic intern deutlich erweitert, so z.B. um

• DISTINCT und ORDER –Befehle
• Unterabfragen
• Aggregatfunktionen wie COUNT, AVG, MIN, MAX ^[93]

Ein weiterer Vorteil ist die Möglichkeit zur Verwendung von CMP, der Container Managed Persistence. Durch Verwendung von einzelnen CMP entity beans ist WebLogic in der Lage, Eigenschaften wie beispielsweise Fremdschlüssel oder Attribute auf eine Vielzahl von Tabellen anzuwenden. Dies geschieht mit Hilfe einer XML-Datei, der weblogic-cmp-rdbms-jar.xml, in welcher Tabelle- und Feldeigenschaften hinterlegt sind.^[94]

8 Fazit und Ausblick

  "Mehr als die Vergangenheit interessiert mich die Zukunft, denn in ihr gedenke ich zu leben."
   - Albert Einstein, 14.03.1879 - 18.04.1955

Die Ausarbeitungen, die in der hier vorliegenden Abhandlung durchgeführt worden sind, umfassen ein verhältnismäßig großes Informationsspektrum. Nachdem grundlegenden Funktionsweisen und typische Einsatzgebiete von Anwendungsservern beleuchtet wurden, stellte die Analyse der Enterprise JavaBeans als Bestandteil von Softwarelösungen einen der Hauptdiskussionsgegenstände dar. Neben einer genaueren Betrachtung der in dem Gesamtpaket der Enterprise JavaBeans enthaltenen, einzelnen Beantypen konnte die Bedeutung und Funktion ebendieser im Rahmen des Gesamtpaketes geklärt werden. An die Bearbeitung grundlegender Thematiken, die den Wissenssockel für die weiteren Ausführungen darstellen, schließt sich die spezifische Anforderungsanalyse an. Hierin galt es, jeden einzelnen der insgesamt vier betrachteten Server im Hinblick auf Aufbau, Funktionsumfang und Funktionsweise sowie Distributionen zu analysieren, um in jedem Fall eine individuelle Analyse des jeweiligen Servers, bezogen auf Enterprise JavaBeans vornehmen zu können. Es konnte nicht für alle der hier behandelten Server gleichermaßen ausführliche Literatur ausfindig gemacht werden, was die Umsetzung der ursprünglichen Idee eines gänzlich einheitlichen Aufbaus der einzelnen spezifischen Anforderungsabschnitte schwierig gestaltete. Statt dessen variieren die Ausführungen im Hinblick auf ihre Strukturierung, was jedoch die Analyse der einzelnen Server in Bezug auf die Nutzung von Enterprise JavaBeans nicht beeinträchtigte. Insofern konnten zielführende Resultate erreicht werden, nicht jedoch auf dem ursprünglich angedachten Wege.

Anforderungen an Enterprise JavaBeans im eigentlichen Sinne, bezogen auf die in dieser Abhandlung diskutierten Anwendungsserver, lassen sich nur schwierig formulieren. Enterprise JavaBeans verkörpern einen Standard und stellen Methoden zur Nutzung dieses Standards bereit. Dieses Paket kann grundsätzlich in der Softwareentwicklung genutzt werden. Die angesprochenen Methoden in Enterprise JavaBeans können vorrangig im Entwicklungsbereich mehrschichtiger, verteilter Systeme eingesetzt werden, was auch die Kennzeichnung der JavaBeans als "Enterprise" JavaBeans begründet. Mehrschichtige, verteilte Systeme weisen typischerweise ein Zusammenspiel mit Anwendungsservern auf. Hierin besteht die Verbindung zwischen Enterprise JavaBeans und Anwendungsservern im Allgemeinen. Die Anwendungsserver als solche können aber keinerlei Einfluss auf Enterprise JavaBeans nehmen oder deren Funktionsweise oder Funktionsumfang bestimmen. Sie können daher keinerlei Anforderungen im eigentlichen Sinne an Enterprise JavaBeans stellen. Entweder sie nutzen die gebotene Standardisierung mitsamt der bereitgestellten Funktionen, oder sie nutzen sie nicht. Gleichwohl lässt sich eine unterschiedliche Nutzungsintensität bezüglich Enterprise JavaBeans auf Seiten der vier Server feststellen.

Dem Grunde nach decken alle vier Server das volle Funktionsspektrum, das von Enterprise JavaBeans durch die einzelnen implementierten Beantypen bereit gestellt wird, ab bzw. nutzen dieses. Während jedoch Glassfish beispielsweise eine Konfiguration des Servers über vordefinierte Profile vorsieht und damit einen gewissen Komfort umsetzt, gestaltet sich eine entsprechende Konfiguration für andere Server weitaus weniger komfortabel. Dem entgegen stehen im Umkehrschluss detailliertere Konfigurationsmöglichkeiten zur Verhaltenssteuerung der verbleibenden drei Server. Teilweise kann für bestimmte Bereiche die explizite Nutzung bzw. Erzeugung von Beans angeordnet werden. Auf diese Weise kann eine bedarfsorientierte Konfiguration der Server vorgenommen werden, um beispielsweise die Verfügbarkeit oder die Persistenz der Daten zu erhöhen. Über eine solche Konfigurationsmöglichkeit verfügt der Websphere Anwendungsserver von IBM. Er bietet neben vielen anderen Einstellungsoptionen die Möglichkeit, einzelne EJB-Module zu bilden zu zu paketieren. Ein Modul kann sich hierbei immer aus mehreren einzelnen Beans des Enterprise JavaBeans Ensembles zusammensetzen. Darüber hinaus umfasst der Websphere Anwendungsserver eine Reihe IBM-spezifischer Erweiterungen für Enterprise JavaBeans, die ebenfalls einen Indikator für eine ggf. höhere Nutzungsintensität darstellen.

Enterprise JavaBeans als unterstützende und maßgebende Komponente in der Entwicklung mehrschichtiger und verteilter Systeme genießt eine immer größer werdende Akzeptanz. Nicht zuletzt liegt dies an deren stetiger Weiterentwicklung. Die hier vorliegende Abhandlung beschreibt in dem Teil der Grundlagenbetrachtung mitunter einige Neuerungen, die Enterprise JavaBeans 3 von ihren Vorgängerversionen unterscheiden. Aus den dort diskutierten Neuerungen geht hervor, dass eine immer einfachere Anwendung von Enterprise JavaBeans angestrebt wird, um deren implementierung in Softwareprojekten zu erleichtern. Gleichermaßen schreitet die Entwicklung der einzelnen Komponenten des Enterprise JavaBeans Paketes derart voran, dass deren Leistung eine regelmäßige Zunahme erfährt. Bereits Heute sind Enterprise JavaBeans zu einem absolut wesentlichen Bestandteil in der Entwicklung verteilter Systeme geworden. Die angesprochenen Änderungen und Entwicklungen untermauern diese Feststellung. Wird der Blick in die Zukunft gerichtet, so lassen die Ausführungen dieser Abhandlung den Rückschluss zu, dass die Enterprise JavaBeans weiterhin einen relevanten und substanziellen Teil in der Entwicklung o.g. Systeme darstellen wird. Hierzu tragen neben der stetigen Weiterentwicklung und Verbesserung der Komponenten vor allem auch die bislang implementierten Standardisierungen bei, die viele, aus unternehmerischer Sicht ökonomische Belange bedienen. Dinge wie Datenpersistenz, Datensicherheit oder Hochverfügbarkeit sind und werden in der Unternehmenswelt immerzu fundamentale Kriterien sein. Grundsätzlich ist Enterprise JavaBeans eine Umsetzung solcher Standards, die ebendiese Kriterien für die Gestaltung unternehmerisch eingesetzter, verteilter Systeme berücksichtigt. Im weitesten Sinne wird hiermit ein Garant für einen großen Teil der Anforderungen an mehrschichtige, verteilte System geboten. Demzufolge wäre ein weiterer Anstieg der Akzeptanz dieser Komponenten nicht undenkbar.

9 Fußnoten

1. ↑ Vgl. Österle, H. (2001), S. 253
2. ↑ Vgl. Louis, D. (2007), S. 17
3. ↑ Louis, D. (2007), S. 17
4. ↑ Vgl. Louis, D. (2007), S. 18
5. ↑ Vgl. Heldt, S. et al. (2003), S. 47
6. ↑ Vgl. Sneed, H. et al. (2003), S. 114 f.
7. ↑ Vgl. Sneed, H. et al. (2003), S. 115
8. ↑ Vgl. Heldt et al. (2004), S.71
9. ↑ Borghoff, U. et al. (1999), S. 21 f.
10. ↑ ^{10,0 10,1 10,2} Siedersleben, J. (2002), S. 137
11. ↑ Vgl. Siedersleben, J. (2002), S. 139 f.
12. ↑ Siedersleben, J. (2002), S. 140
13. ↑ Vgl. Siedersleben, J. (2002), S. 143
14. ↑ Vgl. Ten Hompel, M. et al. (2007), S. 245
15. ↑ Vgl. Heldt, S. et al. (2003), S. 46
16. ↑ Vgl. Eberling, W. et al. (2007), S. 7-8
17. ↑ Vgl. Eberling, W. et al. (2007), S. 10
18. ↑ Vgl. Heldt, S. et al. (2003), S. 47
19. ↑ Vgl. Eberling, W. et al. (2007), S. 13
20. ↑ Vgl. Heinisch, C. et al. (2007), S. 336
21. ↑ Vgl. Eberling, W. et al. (2007), S. 13
22. ↑ Vgl. Eberling, W. et al. (2007), S. 14-15
23. ↑ Vgl. Heldt, S. et al. (2003), S. 247
24. ↑ Vgl. Eberling, W. et al. (2007), S. 78-79
25. ↑ Wutka, M. (2002), S. 172
26. ↑ Vgl. Heinisch, C. et al. (2007), S. 307
27. ↑ Eberling, W. et al. (2007), S. 91 f.
28. ↑ ^{28,0 28,1} Vgl. Heldt, S. (2003), S. 155
29. ↑ Vgl. Heldt, S. et al. (2003), S. 155 f.
30. ↑ Vgl. Heldt, S. et al. (2003), S. 157 f.
31. ↑ Vgl. Eberling, W. et al. (2007), S. 155
32. ↑ Vgl. Eberling, W. et al. (2007), S. 155 - 156
33. ↑ Vgl. http://java.sun.com/products/jms/
34. ↑ Vgl. Eberling, W. et al. (2007), S. 155 - 157
35. ↑ Daum, B. (2007), S. 181
36. ↑ Vgl. Eberling, W. et al. (2007), S. 19
37. ↑ Vgl. Eberling, W. et al. (2007), S. 14
38. ↑ Vgl. Burke, B. et al. (2006), S. 425
39. ↑ Schäffer, S. (2002), S. 467
40. ↑ Vgl. Heldt, S. et al. (2003), S. 446 f.
41. ↑ Vgl. Heldt, S. et al. (2003), S. 447
42. ↑ Vgl. Heldt, S. et al. (2003), S. 447 f.
43. ↑ ^{43,0 43,1} Vgl. Heldt, S. (2003), S. 448
44. ↑ Vgl. Heldt, S. et al. (2003), S. 451
45. ↑ ^{45,0 45,1} Vgl. Heldt, S. (2003), S. 453
46. ↑ Vgl. Heldt, S. (2003), S. 315ff
47. ↑ Vgl. Fleury M. (2004), S. 514 ff
48. ↑ Vgl. http://onjava.com/pub/a/onjava/2001/09/19/ejbql.html?page=3
49. ↑ Vgl. Eberling, W. et al. (2007), S. 21
50. ↑ Vgl. Heldt, S. et al. (2003), S. 89; Eberling, W. et al. (2007), S. 21 f.
51. ↑ ^{51,0 51,1} Vgl. Eberling, W. (2007), S. 22
52. ↑ Vgl. Werner, D. (2007), S. 426; Eberling, W. et al. (2007), S. 22
53. ↑ Vgl. Eberling, W. et al. (2007), S. 22
54. ↑ Vgl. Eberling, W. et al. (2007), S. 22 f.
55. ↑ Dick, S. et al. (2000), S. 102
56. ↑ ^{56,00 56,01 56,02 56,03 56,04 56,05 56,06 56,07 56,08 56,09 56,10} Vgl. http://java.sun.com/developer/technicalArticles/glassfish/GFv2OpenforBusiness
57. ↑ Vgl. Bengel, G. (2004), S. 304
58. ↑ Vgl. https://metro.dev.java.net/discover
59. ↑ Mathas, C. (2007), S. 144
60. ↑ Liebhart, D. (2007), S. 136
61. ↑ Vgl. Liebhart, D. (2007), S. 136
62. ↑ Vgl. Masak, D. (2007), S. 169
63. ↑ Vgl. Langner, T. et al. (2005), S. 568
64. ↑ Vgl. Heinzl, S. et al. (2005), S. 215
65. ↑ Vgl. Heinzl, S. et al. (2005), S. 216
66. ↑ Vgl. Bengel, G. (2004), S. 304
67. ↑ Schäffer, S. (2002), S. 453
68. ↑ Vgl. Schäffer, S. (2002), S. 453
69. ↑ Vgl. http://www.jboss.de/company/
70. ↑ Vgl. Richards, N. et al. (2006), S. 9
71. ↑ Vgl. http://www.oio.de/public/java/ejb/jboss-clustering.htm
72. ↑ Vgl. Jamae, J. et al. (2009), S. 414, 415
73. ↑ Vgl. Langner, T. et al. (2005), S. 393-395
74. ↑ Vgl. Langner, T. et al. (2005), S. 171-172
75. ↑ Vgl. Jamae, J. et al. (2009), S. 365-366
76. ↑ Vgl. Rambow, M. (2007), S. 83
77. ↑ Vgl. Fleury, M. et al. (2006), S. 380-382
78. ↑ Vgl. Rambow, M. (2007), S. 84
79. ↑ ^{79,0 79,1} Vgl. Schäffer, S. et al. (2002), S.44 ff.
80. ↑ Vgl. IBM (2010), passim
81. ↑ Vgl. Mettler, R. (2010)
82. ↑ Vgl. Agopyan, A. et al. (2009), S.18 ff.
83. ↑ Vgl. Brown, K. et al. (2003), S. 46 f.
84. ↑ Vgl. Renouf, C. (2009), S. 172
85. ↑ Vgl. SUN (2010), passim
86. ↑ Vgl. http://www.oracle.com/corporate/press/2008_apr/bea-closes-rls.html
87. ↑ Vgl. http://www.oracle.com/appserver/appserver_family.html
88. ↑ ^{88,0 88,1 88,2} Vgl. http://www.oracle.com/technology/software/products/ias/files/oracle_wlp_certification_10gr3_matrix.xls
89. ↑ Vgl. Mountjoy, J. et al. (2004), S. 316 ff
90. ↑ Vgl. Mountjoy, J. et al. (2004), S. 316 ff
91. ↑ Vgl. Mountjoy, J. et al. (2004), S. 279 ff
92. ↑ Vgl. Mountjoy, J. et al. (2004), S. 285 ff
93. ↑ Vgl. Nyberg G. et al. (2003), S. 248 ff.
94. ↑ Vgl. Nyberg G. et al. (2003), S. 248 ff.

10 Literatur- und Quellenverzeichnis

Agopyan, Arden; Huebler, Hermann; Puah, Tze; Schulze, Thomas; Vilagliu, David Soler; Keen, Martin	WebSphere Application Server V7.0: Concepts, Planning, Design, 1. Aufl., REDBOOKS (2009), Abgerufen am 04.01.2010 von Site: http://www.redbooks.ibm.com/redbooks/pdfs/sg247708.pdf
Bengel, Günther	Verteilte Systeme: Grundlagen und Praxis des Client-server-computing. Inklusive aktueller Technologien wie Web-services U. A. Für Studenten und Praktiker, 3. Aufl., Vieweg+Teubner Verlag (2004) ISBN-10: 3528257385, ISBN-13: 9783528257385
Biberger, Ulrich	Open-source Enterprise Service Bus Lösungen im Vergleich, 1. Aufl., GRIN-Verlag (2009) ISBN-10: 364037164X, ISBN-13: 9783640371648
Borghoff, Uwe M.; Schlichter, Johann H.	Rechnergestutzte Gruppenarbeit: Eine Einfuhrung in Verteilte Anwendungen, 2. Aufl., Springer Verlag (1999) ISBN-10: 3540628738, ISBN-13: 9783540628736
Brown, Kyle; Craig, Gary; Hester, Greg; Pitt, David	Enterprise Java programming with IBM WebSphere, 2. Aufl., IBM Press (2003) ISBN-10: 032118579X
Burke, Bill; Monson-Haefel, Richard	Enterprise JavaBeans 3.0, 5. Aufl., O'Reilly Media (2006) ISBN-10: 059600978X, ISBN-13: 9780596009786
Daum, Berthold	Java 6, 1. Aufl., Pearson Education (2007) ISBN-10: 3827324688, ISBN-13: 9783827324689
Dick, Stefan; Kecke, Hans Joachim	Industriearmaturen 2000, 1. Aufl., Vulkan-Verlag GmbH (2000) ISBN-10: 3802727207, ISBN-13: 9783802727207
Eberling, Werner; Leßner, Jan	Enterprise JavaBeans 3 Das ejb3-praxisbuch für ein- und Umsteiger, 1. Aufl., Hanser Verlag (2007) ISBN-10: 3446410856, ISBN-13: 9783446410855
Finger, Patrick; Zeppenfeld, Klaus	SOA und Webservices, 1. Aufl., Springer Verlag (2009) ISBN-10: 3540769900, ISBN-13: 9783540769903
Fleury, Marc; Stark, Scott; Richards, Norman	JBoss 4.0, 1. Aufl., Pearson Education (2006) ISBN-10: 3827323193, ISBN-13: 9783827323194
Heinzl, Steffen; Mathes, Markus	Middleware in Java: Leitfaden zum Entwurf verteilter Anwendungen- Implementierung von verteilten Systemen über JMS- verteilte Objekte über RMI und CORBA, 1. Aufl., Vieweg+Teubner Verlag (2005) ISBN-10: 3528059125, ISBN-13: 9783528059125
Heinisch, Cornelia; Goll, Joachim; Müller-Hofmann, Frank	Java als erste Programmiersprache: Vom Einsteiger zum Profi, 5. Aufl., Vieweg+Teubner Verlag (2007) ISBN-10: 3835101471, ISBN-13: 9783835101470
Heldt, Stefan; Zuzmann, Henning	Enterprise JavaBeans komplett, 1. Aufl., Oldenbourg Wissenschaftsverlag (2003) ISBN-10: 3486273795, ISBN-13: 9783486273793
IBM (2010)	Choose an IBM WebSphere Application Server configuration to suit your business needs, Abgerufen am 04.01.2010 von Site: ftp://ftp.software.ibm.com/common/ssi/pm/sp/n/wsd14023usen/WSD14023USEN.PDF
Jamae, Javid; Johnson, Peter	JBoss im Einsatz: Den JBoss Application Server konfigurieren, 1. Aufl., Hanser Verlag (2009) ISBN-10: 3446415742, ISBN-13: 9783446415744
Langner, Torsten; Reiberg, Daniel	J2EE und JBoss: Grundlagen und Profiwissen ; verteilte Enterprise-Applikationen auf Basis von J2EE, JBoss & Eclipse, 1. Aufl., Hanser Verlag (2005) ISBN-10: 3446405089, ISBN-13: 9783446405080
Masak, Dieter	SOA?: Serviceorientierung in Business und Software, 1. Aufl., Springer Verlag (2007) ISBN-10: 3540718710, ISBN-13: 9783540718710
Mathas, Christoph	SOA intern: Praxiswissen zu serviceorientierten It-systemen, 1. Aufl., Hanser Verlag (2007) ISBN-10: 3446411895, ISBN-13: 9783446411890
Mettler, Rebecca	New IBM Appliance Delivers Enterprise Cloud Services, Abgerufen am 04.01.2010 von Site: http://www-03.ibm.com/press/us/en/pressrelease/27392.wss
Mountjoy, Jon, Chugh, Avinash	Weblogic (Definitive Guides) , 1. Aufl., O'Reilly Media (2004) ISBN-10: 059600432X, ISBN-13: 978-0596004323
Nyberg, Gregory; Patrick, Robert; Bauerschmidt, Paul; McDaniel, Jeffrey; Mukherje, Raja	Mastering BEA WebLogic Server – Best Practices for Buliding an Deploying J2EE Applications , 1. Aufl., Wiley Publishing Inc, Indianapolis, USA (2003) ISBN: 0-471-28123-X
Ort, Ed	GlassFish v2: Open for Business, Abgerufen am 09.11.2009 von Site: http://java.sun.com/developer/technicalArticles/glassfish/GFv2OpenforBusiness/
Österle, Hubert; Fleisch, Elgar; Alt, Rainer	Business Networking in der Praxis, 1. Aufl., Springer Verlag (2001) ISBN-10: 3540413707, ISBN-13: 9783540413707
Rambow, Mark	Implementierung einer Referenzanwendung für den JBoss Application Server unter Verwendung der Java 2 Enterprise Edition, 1. Aufl., GRIN Verlag (2007) ISBN-10: 3638820602, ISBN-13: 9783638820608
Renouf, Colin	Pro IBM WebSphere Application Server 7 Internals, 1. Aufl., APress (2009) ISBN-10: 1430219580, ISBN-13: 9781430219583
Richards, Norman; Griffith, Sam	JBoss - das Entwicklerheft, 1. Aufl., O'Reilly Germany (2006) ISBN-10: 3897214369, ISBN-13: 9783897214361
Schäffer, Stefan; Schilder, Walter	Enterprise Java mit IBM WebSphere.: J2EE-Applikationen effizient entwickeln, 1. Aufl., Addison-Wesley (2002) ISBN-10: 382731898X, ISBN-13: 9783827318985
Siedersleben, Johannes	Softwaretechnik: Praxiswissen für Softwareingenieure, 1. Aufl., Hanser Verlag (2002) ISBN-10: 3446218432, ISBN-13: 9783446218437
Sneed, Harry M.; Sneed, Stephan H.	Web-basierte Systemintegration: so überführen Sie bestehende Anwendungssysteme in eine moderne Webarchitektur, 1. Aufl., Vieweg+Teubner Verlag (2003) ISBN-10: 3528058374, ISBN-13: 9783528058371
SUN (2010)	Java Persistence API: Improve Performance, Abgerufen am 04.01.2010 von Site: http://java.sun.com/javaee/technologies/persistence.jsp
Ten Hompel, Michael; Schmidt, Thorsten	Warehouse Management: Organisation und Steuerung von Lager- und Kommissioniersystemen, 3. Aufl., Springer Verlag (2007) ISBN-10: 354074875X, ISBN-13: 9783540748755
Werner, Dieter	Taschenbuch der Informatik, 6. Aufl., Hanser Verlag (2007) ISBN-10: 3446407545, ISBN-13: 9783446407541
Winkler, Sabine	EJB Clustering mit JBoss, (2003), Abgerufen am 06.01.2010 von Site: http://www.oio.de/public/java/ejb/jboss-clustering.htm
Wutka, Mark	J2EE developers guide, 1. Aufl., Pearson Education (2002) ISBN-10: 3827262267, ISBN-13: 9783827262264