WS 2003/04

Copyright (c) 2004

Kopieren, Verbreiten und/oder Modifizieren ist unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder einer späteren Version, veröffentlicht von der Free Software Foundation, erlaubt. Es gibt keine unveränderlichen Abschnitte, keinen vorderen Umschlagtext und keinen hinteren Umschlagtext

Eine Kopie des Lizenztextes ist der Diplomarbeit am Ende unter dem Titel The GNU Free Documentation License beigelegt.

Ich und mein Referent, wir waren uns von Anfang an über Verteilte Systeme in Java einig: Seitdem ich auf der ersten Sitzung mit einem vollem Mund Kaffee husten musste… .

Ich danke Prof. Dr. Dohmann für seine freundliche Unterstützung als Diplomvater. Masroor Ahmad Fulda 2004

4

0  INHALTSVERZEICHNIS  

0  INHALTSVERZEICHNIS  4

1  AUFBAU UND ZIELE  8

1.1  THEORETISCHER TEIL  8

1.2  PRAKTISCHER TEIL  8

1.3  VERSIONEN  8

2  SOFTWAREARCHITEKTUR  10

2.1  ANFORDERUNGEN  10

2.2  GRUNDLEGENDE KONZEPTE  11

2.3  MAKRO-/ MIKRO- UND TECHNISCHE EBENE  12

2.4  SCHICHTENMODELL  12

2.4.1  Präsentationsschicht  13

2.4.2  Anwendungsschicht  13

2.4.3  Persistenzschicht  13

3  VERTEILTE SYSTEME  14

3.1  DEFINITION  14

3.2  MERKMALE.  15

3.3  KOMMUNIKATIONS- UND KOORDINATIONSMECHANISMEN  16

3.3.1  Nachrichtenaustausch  16

3.3.2  Remote Procedure Call (RP)C  17

3.3.3  Netzbetriebssysteme  18

3.3.4  Entfernte Datenbankzugriffe  19

3.3.5  Verteilte Objektsysteme.  19

3.3.6  Web Services  20

3  4 NACHTEILE  21

5

4  VERTEILUNGSPLATTFORMEN.  23

4.1  DEFINITION  23

4.2  GRUNDLEGENDE MERKMALE.  24

4.2.1  Operationale Interaktion.  25

4.2.2  Entfernte Interaktion  25

4.2.3  Transparenz  26

4.2.4  Portabilität und Interoperabilität  28

4.3  BASISDIENSTE  29

4.3.1  Verzeichnisdienste.  29

4.3.2  Managementdienste  30

4.3.3  Persistenzdienste  30

4.3.4  Messagingdienste  31

4.3.5  Transaktionsdienste  32

5  J2EE ALS STANDARDARCHITEKTUR.  33

5.1  EINFÜHRUNG.  33

5.2  ARCHITEKTUR.  34

5.2.1  Applet Container  34

5.2.2  Application Client Container  35

5.2.3  Web Container  35

5.2.4  EJB Container.  35

5.3  LAUFZEITUMGEBUNG.  36

5.3.1  Kommunikationsprotokolle  36

5.3.2  Datenbankzugriff.  38

5.3.3  Namens- und Verzeichnisdienst  39

5.3.4  Transaktionsmonitor  40

5.3.5  Messaging System  41

5.4  EJB-KOMPONENTENMODELL.  42

5.3.1  Bean-Typen  42

5.3.2  Aufbau einer EJB  43

5.3.3  Weitergabe-Deskriptoren.  46

5.3.4  EJB-Aufrufe.  48

5  4 J2EE KONFORME APPLICATION SERVER  51

6

6  JMX ARCHITEKTUR  53

6.1  EINFÜHRUNG.  53

6.2  ÜBERBLICK  54

6.2.1  Instrumentation Level  54

6.2.2  Agent Level.  55

6.2.3  Distributed Services Level  55

6.3  ARCHITEKTURELEMENTE  56

6.3.1  MBean Server.  56

6.3.2  MBeans.  57

6.3.3  JBoss XMBeans.  60

6.3.4  Protokoll Adapter und Connectors  61

7  JBOSS -INSTALLATION UND KONFIGURATION.  63

7.1  ÜBERBLICK  63

7.2  EINRICHTEN DER UMGEBUNG  64

7.2.1  Java Developement Kit  65

7.2.2  JBoss Application Server  66

7.2.3  MySQL  68

7.2.4  Jakarta Tomcat  71

7.3  VERZEICHNISSTRUKTUR.  74

7.3.1  /bin  74

7.3.2  /client.  74

7.3.3  /docs  74

7.3.4  /lib  75

7.3.5  /server.  75

7.3.6  /server/ /conf.  75

7.3.7  /server/ /data  75

7.3.8  /server/ /deploy.  75

7.3.9  /server/ /lib  76

7.3.10  /server/ /log, /server/ /temp und /server/ /work.  76

7.4  KONFIGURATIONSDATEIEN  76

7.4.1  jboss-service.xml  77

7.4.2  -service.xml  78

7.4.3  standardjaws.xml  80

7.4.4  standardjboss.xml  81

7.5  STARTVORGANG  82

8  JBOSS - ADMINISTRATION UND DEPLOYMENT.  85

8.1  MANAGEMENTDIENSTE  85

8.1.1  JBoss Management Console  85

8.1.2  Administration Console.  88

8.2  DEPLOYMENT AM BEISPIEL.  89

8.2.1  jboss.xml.  89

8.2.2  jaws.xml.  90

8.2.3  Kompilieren, Packen und Deployen.  92

8  2 4 Testlauf  94

7

9  FREIE SOFTWARE  96

9.1  DEFINITION  96

9.2  ABGRENZUNG  98

9.2.1  Open Source  98

9.2.2  Freeware  98

9.2.3  Shareware  99

9.2.4  Public Domain  99

9.3  VORZÜGE FREIER SOFTWARE  99

9.3.1  Qualität des Quellcodes  99

9.3.2  Zukunftssicherheit  100

9.3.3  Kollektiver Lernprozess  101

9.4  OPEN SOURCE IN DER PRAXIS  102

9.4.1  Organisation und Ablauf.  102

9.4.2  Finanzierung  104

9.5  LIZENZEN DER FREIEN SOFTWARE  105

9.5.1  GNU General Public License  106

9.5.2  BSD License  106

9.6  OPEN SOURCE IN ENTERPRISE UMBEGUNGEN  107

10  ANHANG  109

10.1  LITERATUR- UND WEBVERZEICHNIS  109

10.1.1  Softwarearchitektur (Kapitel 2)  109

10.1.2  Verteilte Systeme (Kapitel 3)  110

10.1.3  Verteilungsplattformen (Kapitel 4)  111

10.1.4  J2EE als Standardarchitektur (Kapitel 5)  111

10.1.5  JMX Architektur (Kapitel 6)  112

10.1.6  JBoss - Installation und Konfiguration (Kapitel 7)  113

10.1.7  Freie Software (Kapitel 9)  114

10.2  ABBILDUNGSVERZEICHNIS  116

10.3  ABKÜRZUNGSVERZEICHNIS.  118

10.4  GLOSSAR.  120

  10 5 EIDESSTATTLICHE ERKLÄRUNG  126

1.1 THEORETISCHER TEIL

Die vorliegende Diplomarbeit hat das Ziel, sich mit dem J2EE konformen JBoss Application Server als Freie Software und Verteilungsplattform auseinander zu setzen. Da ein Verständnis über die Funktionsweise von Verteilungsplattformen ein Basiswissen über verteilte Systeme voraussetzt, behandelt die Diplomarbeit kapitelweise die theoretischen Hintergründe und bietet anschließend eine knappe Einführung in die von Sun Microsystems spezifizierte J2EE-Standardarchitektur, sowie dem, vom JBoss verwendeten JMX-Management-Ansatz.

Ein sehr interessanter Aspekt im Zusammenhang mit JBoss ist das Phänomen der Freien Software. Nach einer weitreichenden Einführung in die Thematik soll versucht werden, die Konsequenzen qualitativ am Beispiel der Middleware aufzuzeigen.

1.2 PRAKTISCHER TEIL

Der praktische Teil konzentriert sich, neben mehreren Quellcodebeispielen, vor allem auf die schrittweise Installation und Konfiguration einer JBoss Application Server Umgebung, sowie dem exemplarischen Einbinden einer Test-Applikation.

1.3 VERSIONEN

Die Grundlage aller Betrachtungen in dieser Diplomarbeit bilden folgende Softwareversionen und Spezifika:

Java 2 Platform, Standard Edition (J2SE) 1.4.2 ¹ Java 2 Platform, Enterprise Edition (J2EE) 1.2.1 ² JBoss 3.2.2 Latest Scott Release ³ Apache Jakarta Tomcat 4.1.27 Stable ⁴

MySQL 4.0.16 Production Release 5

¹ [SunJ2SE03] ² [SunJ2EE03] ³ [JBoss03] ⁴ [Jakarta03]

⁵ [MySQL03]

2.1 ANFORDERUNGEN

Die zunehmend steigenden Anforderungen an die Architektur moderner Software, bedingt durch zahlreiche neue Faktoren, wie zum Beispiel dem gestiegenen Vernetzungsgrad oder dem verstärkten Bedürfnis nach Integration, verlangen nach immer besser durchdachten Mustern und Lösungswegen. Die Disziplin der Softwarearchitektur, welche die Softwarekomponenten und deren Verbindungen und Interaktionen untereinander definiert, ⁶ spielt im Softwareentwicklungsprozess daher eine immer wichtiger werdende Rolle.

Sowohl traditionelle Anforderungen, wie beispielsweise die Konfigurierbarkeit oder die Erweiterbarkeit der Systeme, als auch die aus dem verteilten Charakter resultierenden Konsequenzen wie etwa die Mehrbenutzerfähigkeit ⁷ müssen durch die zugrunde liegende Architektur abgedeckt werden. Letztendlich ist es auch der Entwicklungsprozess der Software selber, der durch einen höheren Organisationsaufwand profitiert. Die Wiederverwendbarkeit der Komponenten ist ein Aspekt davon.

⁶ Vgl. [Bredemeyer03]

⁷ Stichworte: Synchronisation und Transaktionsmanagement

2.2 GRUNDLEGENDE KONZEPTE

Idealerweise sollten Softwarekomponenten zwei wesentliche Merkmale aufweisen: Eine starke Kohärenz ⁸ und eine lose Kopplung. Ein kohärentes Teilsystem ist funktional eindeutig abgegrenzt; hat also einen klar definierten Verantwortungsbereich. Das aus dem Smalltalk stammende MVC ⁹ -Konzept ist einer der prominentesten Beispiele hierfür (Siehe →ABBILDUNG 2.1). Durch das gesonderte Betrachten der formalen und der technischen Aspekte wird eine Trennung der Programmlogik von der jeweiligen Präsentation und den Benutzerinteraktionen herbeigeführt ¹⁰ . Die gewonnene lose Kopplung vereinfacht den Austausch der einzelnen Schichten enorm. Denn dadurch werden Abhängigkeiten zu anderen Teilsystemen minimiert, so dass bei einer Änderung des Gesamtsystems nicht unbedingt jedes Teilsystem betroffen ist. Ist von diesen schmalen Schnittstellen zwischen den Teilkomponenten die Rede, spricht man von einem ʺrobustenʺ System ¹¹ .

Abbildung 2.1: MVC Konzept

⁸ lat. Zusammenhang ⁹ MVC = Model View Controller ¹⁰ Vgl. [SUNWebTier03] ¹¹ Vgl. [DunkelHulitschke03] S.4

2.3 MAKRO-/ MIKRO- UND TECHNISCHE EBENE

Der Begriff der Softwarearchitektur findet auf unterschiedlichen Ebenen innerhalb eines Softwaresystems seinen Ausdruck. Während die Makroarchitektur die grundlegenden Komponenten und Teile des Gesamtsystems spezifiziert, widmet sich die Mikroarchitektur der internen Funktionsweise. Des weiteren werden Maßnahmen, die der konkreten technischen Realisierung vorangehen, unter der technischen Architektur zusammengefasst ¹² . 2.4 SCHICHTENMODELL

Eine sehr gängige Praxis in der Softwarearchitektur ist die Zerlegung des Systems in Schichten, analog zu einem Protokollstack. Eine Schicht bietet den darüber liegenden Schichten so genannte Dienste an, die ihrerseits die anstehenden Aufgaben an die unteren Schicht weiter delegieren. Als Ergebnis erhält man neben der Kohärenz und der losen Kopplung auch die Möglichkeit, die Schichten über ein Netzwerk zu verteilen. Das Drei-Schichten-Modell ist die am häufigsten anzutreffende Variante. Die Verwandtschaft zum MVC-Muster ist nicht zu verkennen.

Abbildung 2.2: Drei-Schichten-Architektur

¹² Vgl. [DunkelHolitschke03] S.15

Die eindeutig abgegrenzten Schichten unterliegen dabei unterschiedlichen, für ein Anwendungssystem typischen, Verantwortlichkeiten:

2.4.1 Präsentationsschicht

Die Präsentationsschicht ist für das Erzeugen und Verwalten einer geeigneten grafischen Benutzeroberfläche ¹³ zuständig. Das Steuern der Interaktion mit dem Benutzer fällt ebenso in den Aufgabenbereich der Präsentationsschicht, wie die sachgerechte Darstellung der fachlichen Information auf dem Ausgabegerät. Das erstere geschieht üblicherweise mit Hilfe von Interaktionselementen, wie etwa Textfeldern, Radiobuttons oder Checkboxen. MVC-Analogie: View

2.4.2 Anwendungsschicht

Hier ist die Programmlogik angesiedelt. Die für das Anwendungsziel relevanten Funktionen, Prozesse und Steuerungsmechanismen werden in der Anwendungsschicht realisiert. Die an das Anwendungssystem gestellten Anforderungen beeinflussen dabei stark die Funktionalität dieser Schicht. MVC-Analogie: Controller

2.4.3 Persistenzschicht

In dieser Schicht werden Dienste angeboten, die ein dauerhaftes Ablegen der anwendungsspezifischen Daten auf Sekundärspeichern (Magnetplatten und andere Formen von Massenspeichern) erlauben. Eine gängige Praxis ist der Einsatz von relationalen Datenbanksystemen. MVC Analogie: Model

¹³ auch: GUI - Graphical User Interface

3.1 DEFINITION

In der Fachliteratur findet sich für die Erklärung des Begriffes „Verteilte Systeme“ eine Vielzahl von Ansätzen. Besonders zutreffend erscheinen folgende Definitionen:

„Ein verteiltes System ist eine Kollektion unabhängiger Computer, die den Benutzern als ein Einzelcomputer erscheinen.“ 14

„Ein Verteiltes System ist ein informationsverarbeitendes System, das eine Vielzahl von eigenständigen Rechnern enthält, die über ein Kommunikationsnetzwerk miteinander kooperieren, um ein angestrebtes Ziel zu erreichen.“ 15

Eine Klassifikation verteilter Systeme mit MIMD-Architektur ¹⁶ kann über die Kommunikationsart als Unterscheidungsmerkmal erfolgen. Entweder tauschen die autonomen Einheiten ihre Daten über einen gemeinsam zugreifbaren Speicher aus, oder im Falle privater Speicher, mittels Nachrichtenaustausch über eine Netzwerkinfrastruktur. →ABBILDUNG 3.1 verdeutlicht dies.

¹⁴ Vgl. [TanenbaumSteen03] ¹⁵ Vgl. [Bapat94]

¹⁶ Klassifikation der Rechnerarchitekturen nach Michael J. Flynn.

Abbildung 3.1: Taxonomie von Mehrrechnersystemen 17

Verteilte Systeme mit privatem Speicher sind in der Praxis, vor allem durch die rasche Entwicklung des Internets in den letzten Jahren, am häufigsten anzutreffen. 3.2 MERKMALE

Der Begriff der autonomen Einheit ist bewusst abstrakt gewählt, weil man darin neben der physikalischen Sicht auf die Rechnerarchitektur auch die logische Sicht auf die Anwendungsebene, zum Beispiel die der gemeinsam kooperierenden Prozesse, zu verstehen hat. Der Gegenstand der Verteilung kann über Zustände hinaus auch Verhalten beinhalten. So ist die Verteilung und Bereitstellung von Programmlogik durch entsprechende Funktionen oder Prozesse ein wichtiges Merkmal verteilter Systeme. Die Verstreuung autonomer Programmteile oder Daten über ein Netzwerk führt zu einer starken Dezentralisierung und je nachdem zu einem hohen Grad an Redundanz. Die Vorteile dieser Redundanz liegen in einer höheren Verfügbarkeit. Durch eine Parallelisierung der Prozesse kann die Rechenleistung, sofern genügend

¹⁷ In Anlehnung an [Weber98] S.5

Ressourcen vorhanden sind und diese nicht durch „Hazards“ (Abhängigkeiten) beeinträchtigt werden ¹⁸ , nahezu linear gesteigert werden.

Verteilte Systeme unterstützen darüber hinaus auch die Abbildung wirtschaftlicher Prozesse und Kommunikationskanäle zwischen Unternehmen und Unternehmensbereichen. Durch den Nachrichtenaustausch zwischen Rechnern können betriebliche Abläufe durch einen guten Datenfluss und der Vermeidung von Medienbrüchen mit einer höheren Effizienz durchgeführt werden. Diese Tatsache deckt sich durchaus mit der Forderung nach Wirtschaftlichkeit in den Unternehmenszielen ¹⁹ .

Charakteristisch für verteilte Systeme ist auch deren Skalierbarkeit. Bei der Definition einheitlicher Schnittstellen lassen sich Teile des Systems ohne großen Aufwand anfügen, ersetzen oder entfernen, so dass solche Operationen mitunter einfacher durchzuführen sind, als auf manchen lokalen Systemen.

3.3 KOMMUNIKATIONS- UND KOORDINATIONSMECHA-

NISMEN

Verteilte Systeme kann man, wie erwähnt, auf unterschiedlichen Abstraktionsebenen realisieren. Meist entscheidet der Anwendungsbereich über die konkrete Ausprägung. Nachfolgend wird versucht, Systeme unterschiedlicher Komplexitätsgrade, sowie deren Beziehungen zueinander zu umreißen.

3.3.1 Nachrichtenaustausch

¹⁸ Vgl. [Dohmann02] ¹⁹ Vgl. [BornPartner03]

Abbildung 3.2: Nachrichtenaustausch

Der Nachrichtenaustausch ist die einfachste Form der Datenübermittlung, bei der eine Folge von Bytes unter Zuhilfenahme eines Kommunikationsmediums zwischen zwei Prozessen transportiert wird. Es kann sich dabei entweder um eine mitteilungsorientierte oder eine auftragsorientierte Nachrichtenübertragung handeln, deren Übertragung synchron oder asynchron zwischen einem Client und dem Server stattfindet ²⁰ . Die hierbei verwendeten Send-Receive-Operationen sind die elementaren Grundbausteine verteilter Software.

3.3.2 Remote Procedure Call (RPC)

Abbildung 3.3: Remote Procedure Call (RPC)

Diese Technik sieht entfernte Prozeduraufrufe, also die Ausführung bestimmter Programmteile über das Netzwerk vor. Ein monolithisches Programm wird hierzu in unabhängige Module zerlegt und jedes einzelne unter Verwendung eines festgelegten Zugriffsverfahrens freigegeben. Die tatsächliche Kommunikation läuft mittels einem simplem Nachrichtenaustausch zwischen speziellen server- und clientseitigen Programmteilen, den so genannten Stubs, ab. Sie haben die Aufgabe, die teils sehr komplex gestrickten entfernten Prozeduraufrufe für den Programmierer transparent zu halten.

²⁰ Vgl. [PuderRömer01] S.11-13

3.3.3 Netzbetriebssysteme

Abbildung 3.4: Netzbetriebssysteme

Das Konzept der Netzwerkbetriebssysteme stammt aus dem LAN-Bereich, welches eine Vernetzung von Arbeitsrechnern zum Zwecke des Dokumenten- und Ressourcenaustauschs vorsieht. Im Prinzip sind darunter alle Betriebsysteme zu verstehen, die den Anwendern und Programmen Kommunikationsmöglichkeiten in Form von integrierten Betriebsmitteln zur Verfügung stellen. Meist ist der umgebenden Netzwerkinfrastruktur ein so genannter Dokumenten- oder Druckerserver als zentrale Einheit zugeordnet, welcher den Clients einen benutzerfreundlichen Zugriff auf die gemeinsam zu nutzenden Ressourcen ermöglicht ²¹ .

²¹ Weiterführende Literatur: [Kubitzky95]

3.3.4 Entfernte Datenbankzugriffe

Abbildung 3.5: Entfernte Datenbankzugriffe

Zur Tätigung entfernter Datenbankzugriffe erlaubt ein Datenbankserver seinen Clients mittels einer Abfragesprache einen standardisierten Zugriff auf seine Datenbestände. Als Voraussetzung müssen die Clients das notwendige Wissen über die jeweilige Implementierung besitzen, das über herstellerspezifische Treiber oder Client-Programme zur Verfügung gestellt wird. Das relationale Datenmodell mit der Abfragesprache SQL ²² hat sich bislang in diesem Umfeld besonders gut durchgesetzt. Der Schwerpunkt dieser Technik liegt überwiegend auf der Verteilung von Daten, weniger auf die der Anwendungslogik, zumal entsprechende serverseitige Funktionen zwecks Performancesteigerung von den Datenbankherstellern immer häufiger mitgeliefert werden.

3.3.5 Verteilte Objektsysteme

²² SQL = Structured Query Language

Abbildung 3.6: Verteilte Objektsysteme

In Objektsystemen sind, wie der Name schon sagt, vorrangig die Objekte samt ihrer Eigenschaften und Methoden Gegenstand der Verteilung. Grundlage für die Verteilung der Objekte bilden mehrere eng kooperierende Dienste, die in einer Verteilungsplattform zusammengefasst, komplexe modellgestützte Anwendungsarchitekturen ermöglichen. Der Kommunikationsmechanismus wird in verteilten Objektsystemen stets aus RPCs aufgebaut ²³ .

3.3.6 Web Services

Abbildung 3.7: Web Services im Internet

Die relativ neuen vom W3C-Konsortium verabschiedeten Standards für das Betreiben so genannter „Web Services“ werden die Zukunft verteilter Systeme und deren Integrationskonzepte maßgeblich prägen. Als Basis dienen eine Reihe technologieunabhängige Schnittstellen, allen voran die Beschreibungssprache XML ²⁴ , welche die „Web Services“ in ihrer Funktion und Architektur bis hin zur Distribution dieser begleiten. Das Ergebnis ist ein dicht gestricktes, aber homogenes Netzwerk interoperabler (Siehe →KAPITEL 4.2.4

²³ Vgl. [PuderRömer01] S.23 ²⁴ Extensible Markup Language

VERTEILUNGSPLATTFORMEN - GRUNDLEGENDE MERKMALE - PORTABILITÄT UND INTEROPERABILITÄT) Dienste ²⁵ auf der Basis von HTTP ²⁶ . 3.4 NACHTEILE

Neben den Vorteilen hat die Verteilung aber auch eine Reihe von nachteiligen Effekten aufzuweisen. Je granulierter das verteilte System nämlich gestrickt ist, desto mehr potentielle Fehlerquellen birgt das System als Ganzes. Denn mit jedem neuen Element vergrößert sich die Angriffsfläche und der Aufwand, Fehler oder Sicherheitslücken zu finden und zu beheben.

Aus einer willkürlich gewählten Redundanz resultiert für die Datenverwaltung gleichzeitig das Problem der Datenkonsistenz und Datensicherheit. Existieren Daten, die einen gleichen Sachverhalt modellieren, an mehreren Stellen im System, so ist im Falle einer Datenänderung an einer Stelle, eine Aktualisierung an sämtlichen anderen Stellen unbedingt vorzunehmen. Überschneiden sich jedoch Aktualisierungsvorgänge, kann es zu Konflikten oder Verfälschungen kommen.

Die Kontrolle nebenläufiger Zugriffe auf gemeinsame Datenbestände erfordert ein ausgeklügeltes Transaktionsmanagement, welches einen wichtigen Stellenwert bei der Realisierung verteilter Systeme haben muss.

Letztlich ist das Phänomen der Heterogenität in verteilten Systemen gegenwärtig. Da sich verschiedenste Systeme im Bereich der Rechnerarchitekturen und auf Betriebssystem- und Anwendungsebene im Markt etabliert haben, werden die Stimmen nach einer Integration dieser immer lauter ²⁷ . Gerade verteilte Systeme leiden aufgrund ihres integrativen Charakters an der Vielzahl von unterschiedlichen Technologien und Plattformen. Durch Vertei-

²⁵ Offizielle ²⁶ HTTP = HyperText Transfer Protocol ²⁷ Stichwort: EAI - Enterprise Application Integration

lungsplattformen standardisierte Zugriffe bieten zwar einen gewissen Grad an Portierbarkeit des Programmcodes, beschränken sich aber dennoch auf das zugrunde liegende Komponentenmodell.

Durch einen völlig neuen Ansatz verspricht die OMG ²⁸ mit der MDA ²⁹ , dem gerecht zu werden. Das Ziel der MDA dabei ist es, eine gänzliche Unabhängigkeit von der vorhandenen technischen Implementierung zu erzielen. Erreicht wird dies durch eine Abstrahierung der Programmlogik durch spezielle Modellierungssprachen und Konzepte. Jedoch existieren bis dato keine ausgereiften Produkte, die die nötigen Transformationen und die Codegenerierung reibungslos vollziehen, sodass das Potential von MDA genügend erschöpft werden kann ³⁰ . Einen weiteren Lichtblick stellen die oben bereits behandelten „Web Services“ dar, die im Einvernehmen wichtiger großer Softwarehersteller wie etwa Sun Microsystems und Microsoft als allgemein gültigen Standard empor gehoben wurden.

²⁸ OMG - Object Management Group ²⁹ MDA - Model Driven Architecture ³⁰ Vgl. [Frankel03] Preface xvi

4.1 DEFINITION

Eine Verteilungsplattform, zu Englisch Middleware ³¹ , bietet allgemein einsetzbare Dienste an, um das Entwickeln, Betreiben und Pflegen von verteilten Systemen zu realisieren. Verteilungsplattformen bilden also eine Mittelschicht zwischen der Anwendung und dem darunter liegenden Betriebssystem ³² . →ABBILDUNG 4.1 verdeutlicht dies.

Abbildung 4.1: Verteilungsplattform als Mittelschicht

³¹ Middleware: Software zwischen Betriebssystem und Anwendung ³² Vgl. [PuderRömer01] S.23

Eine weitere Sichtweise von Middleware ergibt sich aus dem modifiziertem OSI-Referenzmodell nach Tanenbaum:

Abbildung 4.2: Middleware im OSI-Referenzmodell

Middleware bildet demnach die Schnittstelle zwischen der Anwendung und dem Internet. Der fundamentale Zweck besteht darin, dass eine Middleware Lösung die Unterschiede der darunter liegenden Systeme einkapselt; sozusagen den Zugang der Anwendung ins Netz „homogenisiert“.

4.2 GRUNDLEGENDE MERKMALE

Um den Aufgaben gerecht zu werden, müssen Verteilungsplattformen eine Reihe von Anforderungen erfüllen, die von Fall zu Fall unterschiedlich ausgeprägt sein können. Dabei konzentriert sich die Diplomarbeit hauptsächlich auf objektorientierte Anwendungen, d.h. auf verteilte Objektsysteme.

4.2.1 Operationale Interaktion

Abbildung 4.3: Operationale Interaktion

Unmittelbar aus der Definition des Objektmodells leitet sich die Forderung nach der Interaktion ab. Darunter ist generell die Möglichkeit des Austauschs von Nachrichten innerhalb der Objekte gemeint.

4.2.2 Entfernte Interaktion

Abbildung 4.4: Entfernte Interaktion

Die entfernte Interaktion, eine logische Voraussetzung verteilter Systeme, erlaubt die Kommunikation zwischen entfernten Objekten. Dies geschieht durch Methodenaufrufe verschieden lokalisierter Objekte mittels Nachrichtenaustausch. In diesem Kontext ist die Wichtigkeit der Steuerung des zeitlichen Ablaufs der Interaktionen ³³ zu nennen. Allgemein kann man auch von einem Austausch verteilter Ressourcen sprechen, wenn beispielsweise Peripherie angeschlossen ist.

³³ Stichwort: Synchronisation und Transaktionsmanagement

4.2.3 Transparenz

Abbildung 4.5: Transparenter Zugriff

Das Hauptmerkmal einer Verteilungsplattform ist die transparente Bedienung, also das Verbergen der tatsächlichen Implementierung, sowie die Heterogenität der beteiligten Elemente den Entwicklern gegenüber. Die Komplexität des verteilten Systems mitsamt den Kommunikations- und Steuerungsmechanismen wird überdeckt; dadurch wir eine Transparenz für einen effizienteren Umgang simuliert.

Eine hohe Transparenz berücksichtigt mehrere Gesichtspunkte ³⁴ : Technologietransparenz: Die verwendeten Technologien bleiben verborgen. Ortstransparenz:

Der Zugriff auf lokale oder entfernte Objekte erfolgt gleichermaßen. Zugriffstransparenz:

Auf alle Objekte wird auf dieselbe Art und Weise zugegriffen. Ausfalltransparenz:

Fehler im Netz werden vom System möglichst gut maskiert.

³⁴ Vgl. [PuderRömer01] S.10

Prozesstransparenz:

Der Ausführungsort einer Methode hat keinen Einfluss auf deren Funktion. Ressourcentransparenz:

Die verwendeten Ressourcen sind einheitlich freigegeben. Migrationstransparenz:

Die Migration (z.B. das Verschieben von einem Subnetz ins andere) geschieht so, dass die Arbeitsfähigkeit nicht beeinträchtigt wird. Skalierungstransparenz:

Ohne Modifikation der Programmteile ist eine Erweiterung des Objektsystems problemlos möglich. Leistungstransparenz:

Die dynamische Konfigurierung (Lastverteilung) des Systems zur Performancesteigerung ist ohne Nebenwirkungen möglich.

Synchronisationstransparenz:

Mehrere Benutzer oder Anwendungsprogramme können gleichzeitig auf ein Objekt zugreifen ohne sich gegenseitig unwillkürlich zu beeinflussen. Replikationstransparenz:

Benutzer greifen auf replizierte Objekte so zu, als seien diese nur einmal vorhanden.

Eine absolute Transparenz kann nie gewährleistet werden, da in der Praxis öfters Situationen eintreten, die auf die Verteiltheit hindeuten. So können entweder eine schlechte Netzverbindung, oder auch eine etwaige temporäre

Abwesenheit von Objekten während einer Offline-Migration zur Aufhebung der Transparenz führen.

4.2.4 Portabilität und Interoperabilität

Abbildung 4.6: Schnittstellen einer Verteilungsplattform

Heterogenität ist in einer Verteilungsplattform an zwei Stellen angesiedelt, die schematisch gesehen horizontal und vertikal angeordnet werden können. Die horizontale Schnittstelle liegt zwischen der Anwendung und der Verteilungsplattform und beschreibt die Menge aller für den Zugriff auf die bereitgestellten Dienste notwendigen Schnittstellen. Die Kompatibilität des Quellcodes zu anderen Verteilungsplattformen wird als Portierbarkeit bezeichnet und wird üblicherweise über einheitlich standardisierte Programmier-APIs ³⁵ und Management Komponenten realisiert.

Können zwei Instanzen einer Verteilungsplattform miteinander kommunizieren, sind sie also Bestandteil eines gemeinsamen verteilten Systems, so spricht man von Interoperabilität, die der vertikalen Schnittstelle entspringt. Interoperable Verteilungsplattformen benutzen einheitliche Kommunikati-

³⁵ Programmierschnittstelle: API - Application Programming Interface

onsprotokolle, um die Kompatibilität zu Produkten anderer Hersteller zu gewähren. Eines davon ist das RMI ³⁶ oder das relativ neue SOAP ³⁷ .

4.3 BASISDIENSTE

Neben den grundlegenden und notwendigen Anforderungen, wie etwa der entfernten Interaktion der Objekte, schmücken sich Verteilungsplattformen mit einer großen Palette an zusätzlichen Basisdiensten, die das Entwickeln und Betreiben verteilter Anwendungen unterstützen und vereinfachen. Einige wichtige Basisdienste sollen im Folgenden vorgestellt werden:

4.3.1 Verzeichnisdienste

Abbildung 4.7: Verzeichnisdienst

Damit Objekte zum Ausführen entfernter Operationen auf einfache und flexible Weise lokalisiert werden können, wird ein Auskunftsdienst im Stil eines Adressbuchs eingeführt. Ziel dieses Dienstes ist es, mittels einfach handhabbarer Namen ein dynamisches Binden, also das Lokalisieren des konkreten Objektes zur Laufzeit, zu ermöglichen. Verzeichnisdienste werden meist hierarchisch organisiert und in der Praxis auch für eine Vielzahl anderer verteilter Ressourcen genutzt.

³⁶ RMI - Remote Method Invocation ³⁷ Vgl. [W3CSOAP03] (SOAP - Simple Object Access Protocol)

4.3.2 Managementdienste

Unter den Management-Komponenten sind all diejenigen Bestandteile einer Verteilungsplattform zusammengefasst, die den Administratoren und Betreibern als eine Benutzungsschnittstelle zwecks Anpassung und Konfiguration der Middleware dienen. Darunter fallen neben grundlegenden Netzwerkeinstellungen, wie etwa die Belegung der Portnummern auch die Konfiguration der Basisdienste, wie zum Beispiel die lokalen Datenbankeinstellungen der Persistenz-Komponenten. Ausgereifte kommerzielle Produkte beinhalten zusätzlich zu den Management-Komponenten, die in Form von grafischen Benutzungsoberflächen bestehen, auch komplette Build-Systeme, welche den Entwicklern in der Programmierung, als auch beim Debugging ³⁸ und dem Deploy-Vorgang ³⁹ über die Arme greifen.

4.3.3 Persistenzdienste

Abbildung 4.8: Persistente Objekte

Da verteilte Unternehmenssoftware in der Regel große Datenmengen bearbeitet, ist ein durchgängiger Lebenszyklus für die beteiligten Objekte, die die Daten kapseln, zwingend erforderlich. Um dies zu erreichen, werden Objektzustände zu fest gelegten Zeitpunkten auf sekundären Speichermedien übertragen, wo sie längerfristig auch über System-Neustarts hinweg aufbewahrt werden. Üblicherweise werden die Objektzustände von einem Per- ³⁸ Debuging:Finden und Eliminieren von Fehlern in Hardware und Software (Wikipedia.org) ³⁹ Deploying: Installation einer verteilten Anwendung auf eine Verteilungsplattform

sistenz-Manager auf das relationale Datenmodell überführt ⁴⁰ , wonach sie dann in einer Datenbank abgelegt werden. Flache Dateien mit serialisierten Objekten oder die neueren objektorientierten Datenbanken treten in der Praxis seltener auf und spielen als Persistenzmedium in der heutigen Middleware eher eine untergeordnete Rolle.

4.3.4 Messagingdienste

Abbildung 4.9: Objekte in asynchroner Kommunikation

Ein Messaging System erweitert die klassischen entfernten Methodenaufrufe um die asynchrone und damit die parallele Verarbeitung. Während bei synchronen Methodenaufrufen das aufrufende Objekt auf das Ende der serverseitigen Verarbeitung warten muss, kann es seine Arbeit unter Verwendung eines Messaging-Systems unmittelbar nach einem Methodenaufruf, das indirekt über einen asynchronen Nachrichtenversand implementiert ist, fortsetzen. Asynchroner Nachrichtenversand unterscheidet sich im Wesentlichen durch zwei Kommunikationsmodelle, und zwar dem Point-to-Point- und dem Publish-and-Subscribe-Modell ⁴¹ .

⁴⁰ Stichwort: Objekt-Relationales Mapping ⁴¹ [DennigerPeters02] S.246-248

4.3.5 Transaktionsdienste

Abbildung 4.10: Transaktionsdienst

Die Transaktionssteuerung hat die Aufgabe, eine gewisse Fehlertoleranz bei der zeitlich verzahnten Ausführung von Transaktionen ⁴² zu gewährleisten. Da beim parallelen Zugriff auf verteilte Datenbestände eine Vielzahl unterschiedlicher Synchronisations-Probleme auftreten können, bedienen sich die Steuerungsmechanismen einem in der Fachliteratur als ACID-Prinzip bekanntem Konzept. Demnach müssen Transaktionen bestimmte Eigenschaften, wie beispielsweise eine Unteilbarkeit (Atomarität) besitzen, um reibungslos ablaufen zu können ⁴³ . Verteilungsplattformen bieten dem Anwendungsentwickler solcherlei Kontrollmechanismen entweder automatisch oder explizit durch APIs.

⁴² Tranaktion: eine logisch zusammengefasste Menge datenändernder Operationen ⁴³ Vgl. [VossenGross93] S.28-30

5.1 EINFÜHRUNG

Die Java 2 Plattform, Enterprise Edition, kurz J2EE, ist die Standardarchitektur für das Erstellen und Betreiben von verteilten Anwendungen in der Programmiersprache Java. Die Firma Sun Microsystems bietet durch die im April 2003 jüngst aktualisierte „J2EE v1.4 Specification“ ⁴⁴ einen Satz von Technologien und Architekturvorgaben, die eine standardisierte und daher herstellerunabhängige Plattform für Enterprise Lösungen ermöglichen soll. Diese beinhaltet, neben dem eigenständig in der „EJB ⁴⁵ v2.1 Specification“ verankerten EJB Komponentenmodell, auch präzise Aussagen über die zu verwendenden Basisdienste und deren Schnittstellen. J2EE richtet sich vornehmlich an Hersteller von Application Server Produkten, die durch Einhalten vorgegebener Standards ein Höchstmaß an Interoperabilität und Portierbarkeit der verteilten Software sicherstellen können ⁴⁶ .

⁴⁴ Download unter [SunJ2EEDownload03] ⁴⁵ EJB - Enterprise Java Beans ⁴⁶ Vgl. [SUNJ2EESpec03] S.16

5.2 ARCHITEKTUR

Abbildung 5.1: J2EE Architektur 47

Die Makroarchitektur der J2EE Spezifikation sieht im Allgemeinen vier Makro-Architektur-Komponententypen (Siehe →KAPITEL 2.3 SOFTWAREARCHITEK- TUR -MAKRO-/ MIKRO UND TECHNISCHE EBENE) in Form von so genannten „Containern“ vor, aus denen sich ein verteiltes System zusammensetzen lässt.

5.2.1 Applet Container

Die im Applet Container befindlichen Applets bieten Nutzern eine, zum Beispiel mit Hilfe von Swing ⁴⁸ erstellte, grafische Benutzungsschnittstelle für den Zugriff auf die verteilten Ressourcen und werden üblicherweise über einen Browser zur Laufzeit in den lokalen Speicher geladen. Applets arbeiten auf der client-seitigen Virtual Machine aus Sicherheitsgründen in einem geschützten Bereich ⁴⁹ und sind daher in ihrer Funktionalität stark eingeschränkt.

⁴⁷ In Anlehnung an [SUNJ2EESpec03] Figure J2EE.2-1 ⁴⁸ Der Klassiker für eine umfangreiche Einführung: [EcksteinLoyWood98] ⁴⁹ Java „Sandbox“ Prinzip

5.2.2 Application Client Container

Vollwertige Java-Programme bieten ebenfalls eine GUI für die Nutzer, jedoch sind sie, im Gegensatz zu Applets, auf der Client-Seite vorinstalliert und unterliegen keinen Sicherheitsbeschränkungen, was etwa den Zugriff auf das lokale Dateisystem oder das zu verwendende Kommunikations-Protokoll anbelangt. Ihnen ist der volle Zugriff auf die in der J2EE spezifizierten Kommunikationsmöglichkeiten gestattet.

5.2.3 Web Container

Dynamisch generierte Webseiten, die über einen herkömmlichen Internet Browser betrachtet werden können ⁵⁰ , bieten die flexibelste Form der Benutzungsschnittstelle. Durch die Verlagerung der Interaktionslogik auf den Server können Anpassungen an der GUI ohne Probleme zentral durchgeführt werden. Die Bearbeitung der HTTP-Anforderungen erfolgt serverseitig durch Java Servlets oder JSPs ⁵¹ , welche ungehinderten Zugriff auf alle Java APIs haben können ⁵² . Thin Clients werden häufig als Paradebeispiel für die Präsentationsschicht in einer Drei-Schichten-Architektur (Siehe →KAPITEL

2.4.1 SOFTWAREARCHITEKTUR - SCHICHTENMODELL -PRÄSENTATIONSSCHICHT) angeführt.

5.2.4 EJB Container

Der EJB-Container fungiert als zentrale Komponente in der J2EE-Architektur. Er ist für die Bereitstellung der zu verteilenden Programmlogik in Form von EJB-konformen Geschäftsobjekten zuständig und dient deshalb als Basis für eine J2EE-konforme Verteilungsplattform, an der zusätzliche Containerkomponenten und Dienste gekoppelt werden. Auf die Anforderungen des EJB-Komponentenmodells wird in →KAPITEL 5.4 J2EE ALS STANDARDARCHITEK- ^{TUR - EJB-KOMPONENTENMODELL Bezug genommen. Im Schichtenmodell ent-} spricht der EJB-Container der Anwendungsschicht.

⁵⁰ Häufig in diesem Kontext als „Thin Clients“ bezeichnet ⁵¹ JSP - Java Server Pages ⁵² Vgl. [HunterCrawford98] S.11

5.3 LAUFZEITUMGEBUNG

Wichtiger Bestandteil der J2EE ist deren einheitlich festgelegter Zugriff auf allgemein einsetzbare Dienste, die im Hinblick auf die Basisdienste eine Verteilungsplattform erst als solche ermöglichen. Einige wichtige, in der Spezifikation aufgeführte, sowie deren durch APIs realisierte Zugangspunkte seien hier kurz aufgezählt.

5.3.1 Kommunikationsprotokolle

Die Voraussetzung für eine Interaktion verteilter Objekte (Siehe →KAPITEL

4.2.2 VERTEILUNGSPLATTFORMEN - GRUNDLEGENDE MERKMALE - ENTFERNTE INTERAKTION), aber auch für den Datenaustausch der Komponenten untereinander ist der Zugang zu gemeinsamen Kommunikationsprotokollen.

HTTP (Hypertext Transfer Protocol)/ HTTPS (Hypertext Transfer Protocol Secure)

Diese im Internet sehr verbreiteten Protokolle spielen für Thin Clients, aber auch für den Zugriff auf Web Services (Siehe →KAPITEL 3.3.6 VERTEILTE SYS- TEME -KOMMUNIKATIONS- UND KOORDINATIONSMECHANISMEN - WEB SERVI- ^{CES), eine tragende Rolle.}

Benötigte Bibliotheken (Java Packages): Standard APIs für die Netzwerkkommunikation java.io.* in Java

Servlet / JSP APIs für die serverseitige Bearbeitung javax.servlet.* von HTTP-Anfragen

RMI (Remote Method Invocation)

Das von Sun Microsystems entwickelte RMI ist in Java die Grundlage für die Kommunikation verteilter Objekte untereinander, d.h. also für die Interoperabilität von Verteilungsplattformen. RMI-IIOP ⁵³ unterstützt darüber hinaus auch die Kommunikation mit CORBA ⁵⁴ Objekten.

Benötigte Bibliotheken (Java Packages): Standard APIs für die client-/ oder server- java.rmi.*

IIOP (Internet InterOrb Protocol)

IIOP ist das von der OMG in CORBA definierte Protokoll für die Kommunikation zwischen zwei ORBs ⁵⁵ , die äquivalent zu den EJBs in einem EJB-Container, CORBA-Objekte aufnehmen.

Benötigte Bibliotheken (Java Packages): org.omg.CORBA.* - OMG CORBA APIs für Java

- APIs für den Zugriff auf CosNaming, dem org.om.CosNaming.* Verzeichnisdienst in CORBA

⁵³ RMI-IIOP - Remote Method Invocation over the Internet InterOrb Protocol ⁵⁴ CORBA - Common Object Request Broker Architecture, Standardarchitektur der OMG für verteilte Objektsysteme

⁵⁵ ORB - Object Request Broker, Container für verteilte Objekte in CORBA

5.3.2 Datenbankzugriff

Abbildung 5.2: Datenbankzugriff über JDBC

Ein abstrahierter Zugriff auf relationale Datenbanken erlaubt nicht nur deren einfachen Austausch, sondern auch die Portierbarkeit der Anwendung, die sich darauf stützt. J2EE hält dafür die JDBC ⁵⁶ API bereit, die mit Hilfe eines austauschbaren datenbankspezifischen Treibers (JDBC-Driver) den Zugriff vereinheitlicht. Persistenz-Manager (siehe →Kapitel 4.3.3 VERTEILUNGSPLATT- FORMEN - BASISDIENSTE - PERSISTENZDIENSTE)nutzen in der Regel JDBC-Datenquellen als Speicherort.

Benötigte Bibliotheken (Java Packages): Standard APIs für den Zugriff auf relatio- java.sql.*

Diverse Erweiterungen javax.sql.* (Connection Pooling u.s.w.)

⁵⁶ JDBC - Java Database Connectivity

5.3.3 Namens- und Verzeichnisdienst

Abbildung 5.3: Möglichkeiten der JNDI API

Die Möglichkeit, Komponenten und Dienste einer Verteilungsplattform über einfache Namen anzusprechen, ist für die darauf stützenden Anwendungen von essentieller Bedeutung (Siehe →KAPITEL 4.3.1 - VERTEILUNGSPLATTFOR- MEN -BASISDIENSTE - VERZEICHNISDIENSTE). Mit der JNDI ⁵⁷ API verfolgt Sun Microsystems den Weg, zusammen mit existierenden Verzeichnisdiensten (LDAP ⁵⁸ , DNS ⁵⁹ , u.s.w) auch den Zugang zu J2EE-spezifischen Ressourcen, Geschäftobjekte eingeschlossen, auf eine transparente Weise zu vereinheitlichen. Die Vorzüge der JNDI API liegen zudem in der Möglichkeit, neue Ressourcen dynamisch in das System zu integrieren ⁶⁰ .

Benötigte Bibliotheken (Java Packages): Standard APIs für den Zugriff auf einen javax.naming.* Namensraum

⁵⁷ JNDI - Java Naming and Directory Interface ⁵⁸ LDAP - Lightweight Directory Access Protocol ⁵⁹ DNS - Domain Name System

⁶⁰ Bei der Erweiterung des Namensraums in einem Verzeichnisdienst spricht man von „Binding“

5.3.4 Transaktionsmonitor

Abbildung 5.4: Kommunikationswege bei EJB-Transaktionen

Die in →KAPITEL 4.3.5 - VERTEILUNGSPLATTFORMEN - BASISDIENSTE - TRANS- AKTIONSDIENSTE besprochene Notwendigkeit eines Kontrollmechanismus bei transaktionalen Systemen wird durch die Einführung eines in der J2EE-Architektur zentral verfügbaren Transaktionsmanagers erfüllt. Der von den Herstellern via JTS ⁶¹ zu implementierende Transaktionsmanager hat laut Spezifikation die Aufgabe, den an einer Transaktion beteiligten Komponenten via JTA ⁶² einen Transaktionsmonitor bereitzustellen, der die Operationen zu koordinieren und zu synchronisieren hat. Die beteiligten Elemente können Clients, Objekte im EJB-Container, oder etwa die Datenbank sein.

Benötigte Bibliotheken (Java Packages): JTA APIs für den Zugriff auf javax.transaction.* einen Transaktionsmonitor JTS APIs für die Entwicklung org.omg.CosTransactions.*

eines Transaktionsmonitors nach OTS ⁶³ 1.1

⁶¹ JTS - Java Transaction Service ⁶² JTA - Java Transaction API ⁶³ OTS - Object Transaction Service - Standard der OMG

5.3.5 Messaging System

Abbildung 5.5: JMS Client

Eine weitere von der J2EE geforderte Komponente ist ein Messaging System (Siehe →KAPITEL 4.3.4 VERTEILUNGSPLATTFORMEN - BASISDIENSTE -MESSAGING DIENSTE), das seine Funktionalität über die JMS ⁶⁴ API zugänglich macht ⁶⁵ . JMS-Implementierungen, auch JMS-Provider genannt, bieten verteilten Anwendungen auf der J2EE-Plattform die Möglichkeit des asynchronen Nachrichtenversands mittels einer standardisierten Schnittstelle.

Benötigte Bibliotheken (Java Packages): javax.jms.* JMS API für das Erstellen und Empfangen

von asynchronen Nachrichten im

Auf eine detaillierte Beschreibung aller in der J2EE spezifizierten Punkte wird hier verzichtet, da es den Rahmen der Diplomarbeit sprengen würde.

⁶⁴ JMS = Java Messaging System ⁶⁵ Vgl. [SunJMS03]

5.4 EJB-KOMPONENTENMODELL

Die EJB-Komponenten-Architektur wird von Sun Mircosystems gesondert spezifiziert ⁶⁶ und beschreibt im Generellen den Aufbau und die Struktur von verteilten Geschäftsobjekten, kurz „Beans“, die im idealen Fall ohne Codeänderung auf beliebigen J2EE/EJB-konformen Verteilungsplattformen installiert werden können. Hier fließen vor allem Konzepte ein, die wichtige Basisdienste wie zum Beispiel die Transaktionskontrolle oder die Persistenz der Beans betreffen.

5.3.1 Bean-Typen

Um eine effiziente Abbildung firmenspezifischer Abläufe auf das Objektmodell zu erzielen, definiert die EJB-Spezifikation drei Arten von Enterprise Java Beans (EJBs), die sich im Wesentlichen durch ihre Einsatzmöglichkeiten unterscheiden ⁶⁷ . Session Beans

Session Beans sind dafür gedacht, typische Abläufe oder Vorgänge der Geschäftlogik zu modellieren, wie zum Beispiel das Erzeugen einer neuen Rechnung oder das Anlegen eines neuen Kunden. Session Beans können daher als der verlängerte Arm des Clients verstanden werden, da sie konkrete Operationen an den Datenbeständen ausführen und als verteilte Objekte zentral auf dem Server liegen. Ob eine Session Bean als zustandsbehaftet (Stateful) oder zustandslos (Stateless) deklariert ist, gibt Auskunft darüber, ob die Eigenschaften einer Instanz über mehrere Client-Aufrufe hinweg erhalten bleiben, also exklusiv zur Verfügung stehen, oder nicht. Entity Beans

Entity Beans hingegen repräsentieren eine konkrete Entität innerhalb der Geschäftlogik, wie zum Beispiel ein Kunde oder eine Rechnung. Es ist dem-

⁶⁶ Siehe: ⁶⁷ Vgl. [SunEJBSpec01] S.47 - 49

nach die Aufgabe der Entity Beans, die dem Modell zugrunde liegenden Daten zu kapseln und über einfache Schnittstellen zugänglich zu machen. Entity Beans halten ihren Zustand mit Hilfe eines Persistenzdienstes dauerhaft persistent. Dies kann automatisch (CMP - Container Managed Persistence), oder vom Programmierer explizit ausprogrammiert (BMP - Bean Managed Persistence) geschehen. Message Driven Beans

Message Driven Beans dienen im EJB-Komponentenmodell als Empfänger von asynchronen Nachrichten und reagieren demnach auf Ereignisse, die von Clients oder Beans ausgelöst werden. Message Driven Beans modellieren, genauso wie Session Beans, konkrete Abläufe und Aktionen innerhalb der Geschäftslogik.

5.3.2 Aufbau einer EJB

Eine EJB ist insgesamt aus drei Java-Klassen zusammengesetzt, die bei einem entfernten oder lokalen Aufruf unterschiedliche Funktionen erfüllen ⁶⁸ :

MeinObjektHome.class

MeinObjektRemote.class

MeinObjektBean.class

Das Home-Interface, gekennzeichnet durch das Suffix “Home”, ist der erste Zugangspunkt für den Client, um eine Bean aufzurufen. Über das Home-Interface kann der Client eine neue Bean-Instanz erzeugen, oder eine vorhandene erfragen. Die konkrete Implementierung dieses Vorganges ist dem EJB-Container vorbehalten; aus diesem Grund legt der Bean-Programmierer in dieser Klasse lediglich die Methodenrümpfe durch ein Java Interface fest:

⁶⁸ Bei ausschließlich lokalen Inter-Bean Aufrufen besteht zusätzlich die Option eines LocalHomeInterface.

}

Zum einen handelt es sich bei den Methoden um create-Methoden, also Funktionen für das Erzeugen einer Instanz, sowie um Finder-Methoden, die mittels eines Suchparameters ein bestimmtes Bean oder eine Menge von Beans zurückgeben. Damit Beans eindeutig referenziert werden können, besitzt jede Instanz einen eindeutigen Primärschlüssel, der im obigen Fall vom Typ String ist. Das Remote-Interface ist dasjenige Objekt, das vom EJB-Container zurückgegeben wird, um konkret mit der Geschäftlogik der angeforderten Bean(s) zu operieren. Es handelt sich dabei ebenfalls um eine Schnittstellendefinition, die aber im Gegensatz zum Home-Interface genaue Auskunft über die implementierten Funktionen des Geschäftsobjektes gibt. Der Zugriff auf die Logik einer EJB erfolgt stets über das Remote-Interface.

Die Implementierung der eigentlichen Geschäftslogik ist in der Bean-Klasse lokalisiert. Sie nimmt die Aufrufe des Remote-Interface entgegen und bear- beitet diese im EJB-Container.

Der Grund, weshalb zahlreiche leere Methoden im Beancode stehen, liegt in der EJB-Spezifikation, die einen bestimmten Satz notwendiger systemspezifischer Methoden für jede Bean-Klasse vorschreibt. Sie haben überwiegend die Aufgabe, die Bean über ihre Laufzeitumgebung oder ihren Lebenszyklus zu

informieren. Dass die Signatur der funktionalen Methoden mit denen des Remote-Interfaces übereinstimmen muss, ist selbstverständlich.

5.3.3 Weitergabe-Deskriptoren

Die Migration oder Weitergabe eines EJB-Verbundes, welches möglicherweise eine eigenständige und in sich abgeschlossene verteilte Applikation bildet, erfolgt in der EJB-Spezifikation über so genannte „EJB-JAR-Files“. Eine EJB-JAR-Datei ist ein zip-komprimiertes Java-Archiv, welches die vorkompilierten Java-Klassen der Applikation, sowie einen Satz von XML-Dateien, auch Weitergabe-Deskriptoren genannt, zwecks Beschreibung und Konfiguration enthält ⁶⁹ . Um die nötige Portierbarkeit herbeizuführen, schreibt die Spezifikation das Vorhandensein einer ejb-jar.xml Datei unter den Deskriptoren vor, die neben den Metadaten der EJBs auch Auskunft über deren Schnittstellen zum EJB-Container zu liefern hat. Plattformspezifische Einstellungen hingegen, wie etwa die Konfiguration des Persistenzmanagers, werden in einer gesonderten XML-Datei behandelt. Der Aufbau dieser XML-Dateien variiert von Hersteller zu Hersteller. Eine typische mit Kommentaren versehene ejb-jar.xml sei im Folgenden zur Veranschaulichung dargestellt:

⁶⁹ Vgl. [SunEJBSpec01] S.487

Durch die Auslagerung aller wichtigen Informationen bezüglich der verwendeten Schnittstellen und den erforderlichen Diensten aus dem Programmcode, ist eine problemlose Konfiguration und Installation des EJB-Verbundes auf beliebigen EJB-Container-Implementierungen möglich. Der Deployer, in der Rollendefinition von Sun Microsystems zuständig für das Installieren der EJBs, besitzt mit der ejb-jar.xml somit ein Werkzeug zur individuellen Anpassung des Verbundes auf die Ziel-Umgebung und umgekehrt. Eine vollständige Beschreibung der Elemente findet man in der EJB-Spezifikation ⁷⁰ oder in der oben aufgeführten DTD ⁷¹ .

5.3.4 EJB-Aufrufe

Der client-seitige Aufruf einer entfernten EJB erfolgt in mehreren Schritten und soll anhand eines Beispielcodes kurz erläutert werden.

⁷⁰ Download der Spezifikation und der Klassen: [SunEJBDownload] ⁷¹ DTD = Data Type Definition

Wie der in →KAPITEL 4.2.3 - VERTEILUNGSPLATTFORMEN - GRUNDLEGENDE

MERKMALE TRANSPARENZ behandelte Aspekt der Maskierung in einer J2EE Umgebung zum Tragen kommt, wird hier besonders gut deutlich: Technologietransparenz

Das Wissen über die konkrete Umsetzung der Geschäftslogik bleibt dem EJB-Container vorbehalten. Der Client verwendet lediglich die bereitgestellten Interfaces, um darauf zu zugreifen. Ortstransparenz

Der Zugriff auf lokale oder entfernte Objekte funktioniert stets nach dem gleichen, oben aufgeführten, Prinzip. In welchem Container die EJBs letztlich lokalisiert sind, spielt keine Rolle. Zugriffstransparenz

Welche Bean-Instanz von welchem Typ (Entity Bean oder Session Bean) aufgerufen wird, ist irrelevant. Der Aufruf folgt immer dem gleichen, oben aufgeführten, Muster. Ausfalltransparenz

Ist der J2EE-Server von dem jeweiligen Hersteller ausfallsicher implementiert, bemerkt der Client bestenfalls gar nichts. Prozesstransparenz

Der Ausführungsort der Geschäftsmethoden einer Bean hat keinen Einfluss auf ihre Funktionen, da bis auf die Interfaces keine Referenzen zur Client-Umgebung existieren. Ressourcentransparenz

JNDI ermöglicht den einheitlichen Zugriff auf nahezu alle Ressourcen in einer J2EE- Umgebung. Migrationstransparenz

Sofern der J2EE-Server einen Hot-Deploy-Vorgang unterstützt, geschieht das Migrieren auf eine Weise, die die Arbeitsfähigkeit der Beans zu keinem Zeitpunkt beeinträchtigt. Skalierungstransparenz

Mittels Deskriptoren ist das Verzweigen von EJB-Aufrufen ohne Modifikation des Programmcodes möglich. Dies erlaubt eine nahtlose Integration von neuen EJBs. Leistungstransparenz

Eine dynamische Konfigurierung des Systems zur Performancesteigerung ist, sofern der J2EE-Server die Möglichkeit bietet, ohne Nebenwirkungen möglich.

Synchronisationsstransparenz

Der Transaktionsdienst stellt sicher, dass mehrere Clients gleichzeitig auf eine EJB oder einer anderen Ressource zugreifen, ohne sich gegenseitig unbeabsichtigt zu beeinflussen. Replikationstransparenz

Beim Aufruf einer EJB erfährt der Client nichts über weitere Objekte im Pool.

5.4 J2EE KONFORME APPLICATION SERVER

Die in der Spezifikation beschriebenen Punkte zählen zu einem nötigen Minimum des J2EE Standards und werden üblicherweise von den Application Server Herstellern mit einer breiten Palette zusätzlicher Funktionen angereichert. Dazu zählen meist übergeordnete Managementdienste oder die Unterstützung zusätzlicher Kommunikationsprotokolle. Aussagen bezüglich der Realisierung einer Lastverteilung oder einer Ausfallsicherheit werden bewusst vermieden - hier sind die Hersteller auf sich allein gestellt und konkurrieren folglich miteinander.

J2EE Application Server Produkte unterscheiden sich in erster Linie hinsichtlich ihrer Architektur und Implementierung der geforderten Basisdienste. Während die von Sun Microsystems vorgegebene Makroarchitektur durchgehend verfolgt wird, ergeben sich jedoch große Unterschiede in der Art und Weise, wie diese intern realisiert und konfiguriert werden. Die Integration arbeitserleichternder Zusatzdienste, wie zum Beispiel eigene Build-, Logging- oder Sicherheits-Systeme sind zwar von einem gewissen Vorteil, sollten aber aufgrund ihres proprietären Charakters und den daraus resultierenden Einschränkungen für den Code mit Vorsicht genossen werden.

Um die Kompatibilität der Produkte zueinander offiziell zu untermauern, erhalten Application Server Produkte von Sun Microsystems das Prädikat „100% J2EE konform“ in Form einer Lizenz - sofern sie alle die in der Spezifikation aufgelisteten Dienste und Normen, einhergehend mit langen und aufwändigen Testphasen unter Beweis gestellt haben. Nichtsdestotrotz brüsten sich viele Application Server Hersteller mit diesem Anhängeschild, auch ohne diese Lizenz erworben zu haben; zur Verärgerung von Sun Microsystems, die ihrerseits nämlich horrende Beträge für das Verteilen dieser Lizenz zu erwirtschaften sucht. ⁷²

⁷² Vgl. [LaMonica03]

Als rein marktstrategischen Schritt begründet Marc Fleury, Mitbegründer der JBoss Group, die jüngst durch das JBoss-J2EE-Gründer-Programm in Gang gesetzte Durchführung des Zertifizierungsprozesses auf den JBoss Application Server ⁷³ . Infolge dieses Gleichziehens ist mit einer Verbesserung der Marktposition von JBoss in Zukunft mit hoher Wahrscheinlichkeit zu rechnen.

⁷³ Vgl. [Kunert03]

6.1 EINFÜHRUNG

Der zunehmende Bedarf der Industrie, verteilte dienstorientierte Systeme in einer allgemein zugänglichen und flexiblen Art und Weise zu steuern und zu überwachen, führte zu dem Entwurf einer Architektur der dritten Generation, die herkömmliche, überwiegend starre und nicht-standardisierte Mechanismen ablösen soll ⁷⁴ .

Die von Sun Microsystems spezifizierten Java Management Extensions (JMX) stellen eben solchen Netzwerkumgebungen einen Satz von Entwurfsmustern und APIs in einer ganzheitlichen Management-Architektur bereit. Ohne großen Änderungsaufwand sollen so Java Applikationen in die Lage versetzt werden, heterogene und zur Laufzeit erweiterbare Systeme zentral zu koordinieren. Die rasch ändernden Informationsmodelle und Kommunikationsschnittstellen, die Management Lösungen zwecks Integration zu bewältigen haben, werden durch eine dynamisch erweiterbare Protokollunterstützung handhabbar - eine entscheidende Stärke dieser Architektur. So ist es nicht verwunderlich, dass auch komplexe Java-Softwaresysteme, von Grund auf JMX als Basisarchitektur verwenden, und von den Vorzügen profitieren, die es für deren Konfigurierbarkeit und Administrierfähigkeit mit sich bringt. JBoss ist eines davon.

Gleichwohl die Möglichkeiten sehr groß und vielschichtig angelegt sind, finden Java-Programmierer einen sehr schnellen Einstieg in die JMX Technologie, da sie hauptsächlich auf bereits existierende Konzepte, und zwar die der weit verbreiteten JavaBeans Komponentenarchitektur, beruht ⁷⁵ . Die Java-

⁷⁴ Vgl. ⁷⁵ Vgl. [JMXFAQ03]

Beans Komponentenarchitektur, übrigens nicht zu verwechseln mit dem Enterprise Java Beans Komponentenmodell, definiert durch eine kleine Sammlung standardisierter APIs den einheitlichen Zugriff auf Java-Objekte ⁷⁶ . Eines der wichtigsten Vorgaben für jedes JavaBeans Objekt ist beispielsweise die Realisierung einer Datenkapselung mittels setter- und getter-Methoden.

6.2 ÜBERBLICK

Die JMX-Architektur unterteilt sich in drei grundlegende Schichten ⁷⁷ :

Abbildung 6.1: Schichten der JMX Architektur

6.2.1 Instrumentation Level

Im „Instrumentation Level“ sind die zu steuernden bzw. zu überwachenden Ressourcen angesiedelt. Ressourcen im engeren Sinne sind dahingehend

⁷⁶ Vgl. [SUNJavaBeans03] ⁷⁷ Vgl. [SunJMXSpec02] S.20 - 24

auch als solche zu verstehen, wenn sie als Java-Objekte, unabhängig vom Ort der Ausführung, eine festgelegte Menge von Methoden mit genormten Namen und Signaturen implementieren. Die Spezifikation prägt für solche Objekte den Begriff der MBeans (Mananagement Beans). In der Praxis fungieren MBeans häufig als Kapsel bereits bestehender Objekte ⁷⁸ oder konfigurierbarer Geräte jeglicher Art; somit erweitern sie diese um die Fähigkeit, innerhalb der JMX-Architektur einheitlich administriert werden zu können. Nachfolgend sollen diese Ressourcen als „instrumentierte Ressourcen“ bezeichnet werden.

6.2.2 Agent Level

Der als „Agent Level“ bezeichneten mittleren Schicht obliegt in der JMX-Architektur die Steuerung und Koordinierung der MBeans, die es mittels Software-Agenten realisiert. Die Idee der Software-Agenten stammt aus dem Forschungsgebiet der Künstlichen Intelligenz. Man versteht darunter autonome Programmeinheiten, die sich von herkömmlichen Programmen dahingehend unterscheiden, dass sie durch gegenseitiges Kommunizieren und Koordinieren synergetisch ein intelligentes System bilden ⁷⁹ . In diesem Fall spielen die Agenten, die auch selber als MBeans implementiert sind, die Rolle von Vermittlern zwischen den Schnittstellen der darüber liegenden „Distributed Services Level“ Schicht und den darunter liegenden instrumentierten Ressourcen. Die zentrale Instanz des MBean Servers registriert und überwacht diese. Daneben schreibt die Spezifikation auch das Vorhandensein einiger Mehrzweckdienste vor, wie zum Beispiel einen Timer-Dienst.

6.2.3 Distributed Services Level

Management Clients, die den Nutzern eine Benutzungsschnittstelle für den unmittelbaren Zugriff auf die zu administrierenden Ressourcen liefern, werden in der „Distributed Services Level“ Schicht zusammengefasst. Da solche

⁷⁸ Instanzen von sogenannten „Wrapper-Klassen“ ⁷⁹ Vgl. [Hendler99]

Clients in der Praxis verschiedenartig und häufig auch entfernt lokalisiert sind, erhalten sie Zugriff auf den MBean Server und den MBeans über standardisierte, meist einem Kommunikationsprotokoll zugeordnete Zugangspunkte. Theoretisch können Management Clients von komplexen Systemen instrumentierte Ressourcen aus mehreren MBean-Servern zu einer für den Nutzer logischen Sicht zusammenfassen.

Ein nahe liegendes Beispiel wäre etwa das eines J2EE Application Servers, der über eine zentrale GUI den Administratoren einerseits die Konfiguration der Container, aber auch das Ändern von Einstellungen eines entfernt lokalisierten JMX-kompatiblen Datenbanksystems erlaubt. Der Administrator erfährt bestenfalls gar nichts von der ihm angebotenen abstrahierten, logischen Sicht auf das Gesamtsystem.

6.3 ARCHITEKTURELEMENTE

Um die Funktionsweise von JMX besser verstehen zu können, werden die einzelnen Architekturelemente im Folgenden näher beschrieben.

6.3.1 MBean Server

Dem MBean Server obliegt in erster Linie die Aufgabe, die notwendigen MBeans zu instanziieren und mit einer eindeutigen Kennung versehen, dem „object name“, in einem zentralen Verzeichnis (Registry) zu verwalten. Die Instanziierung eines MBeans kann dabei entweder vom MBean Server selbst, anderen MBeans oder einem Management Client angestoßen werden. Die Verwaltung der MBeans schließt aber auch eine Validierung der vereinbarten Schnittstellen ein, so dass der MBean Server neben dem Aufdecken der unterstützten Operationen vornehmlich auch mit der Überprüfung der zu instanziierenden MBeans betraut ist. Mit der Reflection API bietet Java das

nötige Werkzeug, die Struktur und den Aufbau von Klassen zu untersuchen ⁸⁰ .

Die praktische Arbeit mit dem MBean Server erweist sich als recht einfach. Die codespezifische Repräsentation des MBean Servers ist über ein eigens kreiertes Java-Interface realisiert. Java Objekte, die als MBean Server Instanz fungieren, implementieren das MBeanServer Interface und tragen damit die Sorge dafür, dass ein fest vorgegebener Satz an Methoden vorhanden ist, die dem Zweck des MBeans Servers gemäß, die gewünschten Operationen zur Verfügung stellen. Die Referenz zu einer MBean Server Instanz erhält man entweder über eine statische Factory Klasse, oder einen Namens- und Verzeichnisdienst. Die Fehlerbehandlung durch Exceptions ist in den nachfolgenden Codebeispielen nicht berücksichtigt.

6.3.2 MBeans

Wie bereits ausgeführt, werden Java-Objekte, sofern sie eine bestimmte Menge an festgelegten Methoden implementieren, als MBeans bezeichnet. Zudem besitzen sie einen eindeutigen Namen, der innerhalb eines Namensraumes hierarchisch angeordnet werden kann. Im folgenden Beispiel wird das „Management Interface“ eines simplen MBean durch ein Interface definiert, innerhalb einer Wrapper-Klasse „operationalisiert“ und schließlich dem MBeanServer übergeben.

⁸⁰ Vgl. [Green03]

Die Realisierung der notwendigen Schnittstellen erfolgt in einer Klasse, die denselben Namen, ohne das Suffix „MBean“, trägt:

Die interne Realisierung und das konkrete Verfahren für den Zugriff auf die Ressource unterscheiden sich von Fall zu Fall. Es kann sich dabei um andere Java-Objekte in der Virtual Machine handeln, aber auch um externe Ressourcen, die über ein spezielles API angesprochen werden. Die Registrierung beim zuvor instanziierten MBeanServer vollzieht sich durch wenige Zeilen Code:

Um den Anforderungen einer dynamischen Laufzeitumgebung gerecht zu werden, gibt es neben den Standard MBeans, deren Schnittstellen zu Beginn

über ein Interface festgelegt werden, auch die Dynamic MBeans, deren Schnittstellen sich zur Laufzeit ändern können ⁸¹ . Dynamic MBeans offenbaren ihre Funktionalität eigenständig, indem sie allesamt das Dynamic MBean Interface implementieren; Das Dynamic Bean Interface schreibt unter anderen das Vorhandensein von Methoden vor, über die sich auf die interne Struktur der betreffenden Klassen schließen lässt. Ein Ausschnitt aus der offiziellen API Dokumentation von Sun soll hier einem besseren Verständnis dienen ⁸² :

Darüber hinaus gibt es noch andere MBean Typen, sowie eine große Zahl an Hilfsklassen, Datenstrukturen, Exceptions, sowie Klassen für das Ereignismodell und anderen Mehrzweckdiensten.

⁸¹ Vgl. [SunJMXSpec02] S.40

⁸² Vgl. [SunJ2EEAPIDoc03] Interface javax.management.DynamicMBean

6.3.3 JBoss XMBeans

Aus der Notwendigkeit heraus, das Verwalten von MBeans in einer komplexen Architektur wie die des JBoss zu vereinfachen, veröffentlichten die Entwickler eine eigene MBean Implementierung ⁸³ . Die mit dem Präfix „X“ versehenen MBeans unterscheiden sich von ihren Geschwistern, neben ihrer eingebauten Fähigkeit zur Persistenz und einer Abhängigkeitsprüfung, im Wesentlichen dadurch, dass sie einen XML-getriebenen Start- und Konfigurationsvorgang unterstützen. Das Herzstück der XMBeans ist die XML-DTD, die das Modell für die zu betrachtenden XML-Konfigurationsdateien vorgibt. Ein Studium der einzelnen Elemente und deren Funktionsweise ist von Vorteil - möchte man den softwaretechnischen Aufbau des, wie eingangs erwähnt, auf JMX basierenden JBoss Application Server besser verstehen oder gar um eigens entwickelte MBean Dienste erweitern. Ein Ausschnitt aus einer solchen XML-Datei soll das Prinzip verdeutlichen:

Neben dem Namen der zu ladenden XMBean Klasse können Attribute, ebenfalls in Form von Klassen, als Startparameter weitergereicht werden. Die vollständige DTD ist jeder JBoss Distribution beigelegt.

⁸³ [StarkJBoss03] S.73

6.3.4 Protokoll Adapter und Connectors

Protokoll Adapter und Connectors sind die Schnittstellen der JMX-Architektur zur Außenwelt. Management Clients kommunizieren mit dem MBeanServer entweder über die von den JMX-APIs zur Verfügung gestellten Dienste durch einen Connector, oder aber sie greifen auf die MBeans über ein festgelegtes Protokoll zu, das durch einen Protokoll Adapter möglich wird. Ein häufig verwendeter Protokoll Adapter ist der des SNMP ⁸⁴ Protokolls oder der HTML-Protokoll-Adapter. Letzterer erlaubt ein kinderleichtes Navigieren mit einem Webbrowser. Folgende Schritte sind für das Einbinden des HTML-Adapters notwendig:

Nach einem erfolgreichen Kompiliervorgang unter Verwendung der Referenz Implementierung von Sun sollte sich bei Eingabe der URL: http://localhost:8080 folgendes Bild ergeben:

⁸⁴ SNMP = Simple Network Management Protocol

62

  Abbildung 6 2: JMX Agent View des HTML Adapters  

7 JBOSS -INSTALLATION UND KONFI-

7.1 ÜBERBLICK

JBoss ist ein freier ⁸⁵ , J2EE kompatibler, auf der JMX-Architektur basierender Application Server. Die Weiterentwicklung und Pflege des JBoss Application Servers wird hauptsächlich von der gleichnamigen, weltweit operierenden JBoss Group ⁸⁶ vorangetrieben, die es sich zum Ziel gesetzt hat, JBoss zu einer ernst zu nehmenden Konkurrenz der auf dem Markt befindlichen kommerziellen Application Server Produkte auszubauen. Als Lizenz gilt die LGPL

(Siehe →KAPITEL 9.5.1 FREIE SOFTWARE - LIZENZEN - GNU GENERAL PUBLIC

LICENSE).

JBoss setzt bei der Integration der von der J2EE Spezifikation geforderten Basisdienste gänzlich auf die JMX Infrastruktur, die eine modulare, dynamisch erweiterbare Softwarearchitektur für diesen Zweck bereithält.

Zu den Basiskomponenten des JBoss zählen der JBossServer als EJB Container, JBossMQ als Messaging Dienst, JBossTX als Transaktionsdienst, JBossCMP als Persistenzmanager, JBossSX als Sicherheitsdienst und JBossCX als Schnittstellendienst via Connectors. JMX fungiert für das Zusammenspiel dieser Komponenten als Bus ⁸⁷ (Siehe →ABBILDUNG 7.1).

⁸⁵ Siehe Kapitel 8 Freie Software ⁸⁶ [JBossGroup03] ⁸⁷ Vgl. [StarkJBoss03] S.18

Abbildung 7.1: JMX als Datenbus in einer J2EE Umgebung 88

Als Web Container können wahlweise Jakarta Tomcat ⁸⁹ oder Jetty ⁹⁰ als integ- riertes Bundle installiert werden. Theoretisch ist jedoch die Integration eines beliebigen Servlet Containers möglich.

Ein oft zitiertes Highlight von JBoss ist seine Hot-Deploy Funktion. Wie der Name schon ausdrückt, wird dadurch die Fähigkeit beschrieben, J2EE Komponenten zur Laufzeit anzufügen oder zu entfernen - eine wesentliche Voraussetzung zur Gewährleistung der Migrations- und Skalierungstransparenz in einer Verteilungsplattform (Siehe →KAPITEL 4.2.3 VERTEILUNGSPLATTFOR- MEN -GRUNDLEGENDE MERKMALE - TRANSPARENZ). Wie die Hot-Deploy Funktion arbeitet, wird in den nachfolgenden Kapiteln ausführlich erklärt.

7.2 EINRICHTEN DER UMGEBUNG

Das Betreiben einer J2EE Umgebung setzt neben dem JBoss Application Server das Vorhandensein zusätzlicher Software zwingend voraus. So wird zum einen eine relationale Datenbank für die Ablage der Persistenzdaten benötigt, sowie ein Web Container für das Betreiben von Thin Clients. Als Datenbank soll die Installation der kostenlos verfügbaren MySQL ⁹¹ Datenbank ex- emplarischbeschrieben werden; für den Webcontainer fällt die Wahl auf

⁸⁸ In Anlehnung an [StarkJBoss03] S.19 ⁸⁹ [JakartaTomcat03] ⁹⁰ [Jetty03] ⁹¹ [MySQL03]

Tomcat, ein Produkt des Jakarta Projektes der Apache Software Foundation ⁹² . Allen voran müssen natürlich auch eine Java Virtual Machine, sowie die nötigen Bibliotheken auf dem Zielsystem, in diesem Fall eine Microsoft Windows 2000 Plattform, vorhanden sein.

7.2.1 Java Developement Kit

Abbildung 7.2: Neues Java Logo

Die „HotSpot Virtual Machine“ von Sun Microsystems kann von der offiziellen Website bezogen werden ⁹³ . JBoss benötigt mindestens die Version 1.3.1 einer lauffähigen J2SE (Java 2 Standard Edition). Die Installation der EXE-Version der J2SE 1.4.2 verläuft weitestgehend automatisch; eine erfolgreiche Installation lässt sich wie folgt auf der Kommandozeilenebene überprüfen:

⁹² [ApacheGroup03] ⁹³ [SunJ2SEDownload03]

7.2.2 JBoss Application Server

Abbildung 7.3: Offizielles JBoss Logo

Bei der Installation von JBoss bieten sich zwei Möglichkeiten an: Zum einen kann eine vorkompilierte Version von den Seiten der JBoss Group heruntergeladen und installiert werden, oder aber der Build-Prozess wird selbst in die Hand genommen und das Kompilieren der Quelltexte eigenständig durchgeführt. Das manuelle Erzeugen der JBoss Implementierung hat den Vorteil, dass jeweils die aktuell verfügbare Version bezogen und installiert wird.

Der Zugriff auf das Quellcode Repository von Sourceforge.net (Siehe →KA- PITEL 9.4 FREIE SOFTWARE - OPEN SOURCE IN DER PRAXIS) kann über das Java-Tool jCVS ⁹⁴ erfolgen:

E:\jCVS-5.4.1\bin>java -jar jcvsii.jar

Um die Quelltexte aller Komponenten der aktuellen Version von JBoss „auszuchecken“, sind folgende Einstellungen in der GUI von jCVS vorzunehmen:

⁹⁴ Siehe [jCVS03]

Abbildung 7.4: Auschecken von JBoss mit jCVS

Mit der Angabe von „jboss-head“ als CVS-Modul wird das Herunterladen der jeweils aktuellen Version sichergestellt. Der Ladeprozess kann mehrere Minuten in Anspruch nehmen und liefert eine vollständige Sammlung der für das Kompilieren benötigten Quellcodes einschließlich der Installationsskripte, die durch folgende Batchdatei in Gang gesetzt werden:

E:\JBoss_3.2.2\jboss-head\build>build.bat

Um die frische JBoss Installation zu testen, führe man folgendes Skript aus:

E:\JBoss_3.2.2\jboss-head\build\output\jboss-3.2.2\bin>run.bat

Zweckreich ist in diesem Zusammenhang die Definition einer %JBOSS_HOME% Umgebungsvariable, die lästige Eingaben während der Arbeit erspart. Sieht die Ausgabe am Ende einer langen Kette von Systemmeldungen folgendermaßen aus, dann ist der JBoss Application Server erfolgreich auf dem System installiert:

22:07:09,495 INFO [Server] JBoss (MX MicroKernel) [3.2.2 (build: CVSTag=JBoss_3_2_2 date=200310182216)] Started in 42s:361ms

7.2.3 MySQL

Abbildung 7.5: MySQL Logo

Wenngleich die leichtgewichtige Hypersonic DB ⁹⁵ jeder JBoss Distribution beiliegt, soll die Integration einer separaten Datenbank, der MySQL, als Beispiel erklärt werden. Die MySQL Datenbank erfreut sich in der freien Entwicklergemeinde einer besonders großen Popularität, nicht nur wegen ihrer freien Lizenz, sondern auch aufgrund der einfachen Handhabung und der breiten Unterstützung. MySQL lässt sich ohne großen Aufwand durch einen ebenfalls frei verfügbaren JDBC-Treiber an ein beliebiges Java-System koppeln. Eine Installationsdatei kann direkt über das Entwicklerteam von MySQL, der MySQL BA. ⁹⁶ bezogen werden. Für die Einsicht der Daten in den Tabellen kann das kostenlose MySQL-Front ⁹⁷ Tool eingesetzt werden, welches auch die Verwaltung und Administrierung des laufenden MySQL Servers über eine intuitiv zu bedienende GUI ermöglicht:

⁹⁵ [HyperSonic03] ⁹⁶ [MySQL03] ⁹⁷ [MySQLFront03]

Abbildung 7.6: MySQL-Front

Der JDBC Treiber wird als „MySQL Connector“ auf der offiziellen Website von MySQL angeboten, wobei die im Root des heruntergeladenen TAR- oder ZIP Verzeichnisses befindliche JAR-Datei von größter Bedeutung ist. Diese im JAR-Format befindliche Java-Bibliothek muss nämlich in den /lib Ordner der JBoss Installation kopiert werden - damit erhält der Application Server den Zugriff darauf, und die Voraussetzung, mit dem MySQL Server kommunizieren zu können.

Die logische Repräsentation der MySQL Datenbank innerhalb der J2EE Programme wird nicht, wie vermutet, durch ein direktes Verwenden des JDBC-Treibers geschaffen, sondern über eine abstrakte Datenbankschnittstelle, Da- taSource genannt.Durch eine neu anzulegende Konfigurationsdatei im /deploy Ordner der JBoss Installation können DataSources zentral durch den Namens- und Verzeichnisdienst verwaltet werden. In /docs/examples/jca/mysql-ds.xml befindet sich eine Vorlage, die den Verhältnissen entsprechend angepasst werden muss:

Dadurch ist der Weg für einen datenbankunabhängigen, und ohne großen Aufwand auf eine andere Plattform portierbaren Code für die Persistierung geebnet. Der Aufruf, beispielsweise aus einer BMP-EJB, könnte dann folgendermaßen aussehen:

...

7.2.4 Jakarta Tomcat

Abbildung 7.7: Tomcat Logo

Als Referenzimplementierung ⁹⁸ der Servlet/JSP-Spezifikation genießt Jakarta Tomcat eine Sonderstellung unter den Webcontainern und soll auch in unserem Fall eingesetzt werden. Das von der JBoss Group bereitgestellte JBoss-Tomcat Bundle aber wird bewusst ausgeklammert, stattdessen wird auf die Integration einer eigenständigen, vom JMX-Bus entkoppelten Tomcat Instanz detaillierter eingegangen. Diese Vorgehensweise erlaubt es, Rückschlüsse auf das Einbinden beliebiger anderer Web Container (Siehe →KAPITEL 5.2.3 J2EE ALS STANDARDARCHITEKTUR - ARCHITEKTUR - WEB CONTAINER) in den JBoss zu ziehen.

Für den „heißen“ Betrieb empfiehlt Jakarta den Einsatz einer stabilen Version von Tomcat; zu diesem Zeitpunkt ist es die Version 4.1.x, die in absehbarer Zeit durch die Version 5.0 ersetzt werden wird. Nach Beendigung des Installationsvorganges durch den Windows-Installer kann man einige Feinabstimmungen in der zentralen Konfigurationsdatei /conf/server.xml vornehmen. Eine wichtige Stellschraube ist der Port, auf dem die HTTP-Anfragen entgegen zu nehmen sind:

⁹⁸ Vgl. [JakartaTomcat03]

Um Konflikte mit dem MBeanServer von JBoss zu vermeiden, sollte die JMX-Unterstützung von Tomcat deaktiviert werden:

Der leichten Handhabung wegen bietet es sich auch an, die Konfiguration des Namens- und Verzeichnisdienstes auf globaler Ebene zu verankern. Dadurch erspart man sich die wiederholte Angabe des JNDI-Providers bei den Zugriffen auf die verteilten Ressourcen im Code. Um dies zu bewerkstelligen, genügt meist ein einfaches Ersetzen der im rt.jar Archiv der Java Virtual Machine befindlichen jndi.properties Datei durch die gleichnamige, im /server/default/conf/ Ordner der JBoss Installation vorhandenen Properties-Datei. Dies, weil hier alle JBoss-spezifischen JNDI-Einstellungen vorkonfiguriert sind:

Als letzten Schritt muss den Webapplikationen im Tomcat eine Sammlung von Bibliotheken für die Kommunikation mit dem JBoss Application Server bereitgestellt werden. Der einfachste Weg ist, den gesamten Inhalt des /client Ordners von JBoss in den /shared/lib Ordner der Tomcat Installation zu stellen. Eine geglückte Installation lässt sich nach dem Start, alternativ zum NT-Dienst durch das Ausführen eines Skriptes in der DOS- Konsole, mit einem Internetbrowser verifizieren:

/bin/catalina run

Abbildung 7.8: Jakarta Tomcat Startseite

7.3 VERZEICHNISSTRUKTUR

Die Verzeichnisstruktur einer JBoss Installation sieht wie folgt aus:

/bin

/client

/docs

/lib

/server

/all

/default

/conf

/data

/deploy

/lib

/log

/tmp

/work

/minimal

7.3.1 /bin

Hier befinden sich alle notwendigen Skripte, um den JBoss Server zu starten, sowie eine Reihe von JAR-Dateien, die als Einstiegspunkt benötigt werden.

7.3.2 / client

In diesem Ordner befinden sich alle, für einen JBoss-Client relevanten, Bibliotheken. Applikations- und Web Container, die auf J2EE Komponenten innerhalb des JBoss Application Servers zugreifen wollen, müssen diese in ihren Klassenpfad aufnehmen.

7.3.3 /docs

Eine Dokumentation von JBoss ist an dieser Stelle, wider Erwarten, nicht vorzufinden. Vielmehr sind hier sämtliche DTDs, sowie mehrere Vorlagen für die XML-Konfigurationsdateien abgelegt.

7.3.4 /lib

Im diesem Ordner finden die Programmklassen von JBoss ihren Platz. Der Inhalt sollte, um Fehler zu vermeiden, möglichst nicht verändert werden.

7.3.5 /server

An dieser Stelle haben Systemadministratoren die Option, mehrere Konfigurationen, jeweils durch ein gesondertes Unterverzeichnis, in einer einzigen JBoss Installation unterzubringen. Nach einer neuen Installation existieren zwei voreingestellte Konfigurationen: mit /all werden sämtliche Komponenten und Basisdienste gestartet, während /minimal nur die für den Start nötigsten Komponenten lädt. Die Auswahl der zu verwendenden Konfiguration wird beim Aufruf des Startskriptes getroffen. Zum Beispiel: run --configuration=minimal

7.3.6 /server/../conf

Jeder Server Konfiguration wird ein Satz von Konfigurationsdateien zugeordnet, die sich in diesem Ordner befinden. Die einzelnen, überwiegend im XML Format befindlichen Konfigurationsdateien, werden in dem nachfolgenden Kapitel näher erläutert.

7.3.7 /server/../data

Das /data Unterverzeichnis ist für die Ablage der Datenbanken reserviert, die der Persistenzdienst zur Speicherung der Objektdaten benötigt. Idealerweise kann hier die MySQL Datenbank installiert werden.

7.3.8 /server/../deploy

Der /deploy Ordner dient innerhalb der Verzeichnisstruktur als zentrale Ablage der einzubindenden Server Komponenten und spielt dabei eine besondere Rolle. Die Hot-Deploy Funktion von JBoss überprüft nämlich in re- gelmäßigen Abständen dessen Inhalt und reagiert je nach Veränderung mit

einer Installation oder Deinstallation der betreffenden Komponenten. Diese können sowohl J2EE Komponenten, als auch JBoss spezifische Module sein.

7.3.9 /server/../lib

J2EE Applikation, die Gebrauch von zusätzlichen Java-Bibliotheken machen, erhalten über den /lib Ordner den Zugriff zu diesen.

7.3.10 /server/../log, /server/../temp und /server/../work Das /log Verzeichnis ist für das Speichern der zur Laufzeit auftretenden System- oder Logmeldungen vorgesehen. Der JBoss Application Server setzt dabei auf eine intensive Zusammenarbeit mit dem Logging Framework von Apache, genannt Log4j ⁹⁹ . Die Feinanpassung dieses Logging-Systems geschieht mit Hilfe der im /conf Ordner lokalisierten log4j.xml Konfigurationsdatei. In den /temp und /work Unterordnern werden die temporären Dateien gehalten. Zur Laufzeit sollten diese möglichst nicht verändert werden.

7.4 KONFIGURATIONSDATEIEN

Die systemspezifische Anpassung des JBoss Application Servers ist mehrheitlich durch XML-Dateien gelöst. Diese Tatsache erlaubt zum einen, die Konfiguration über eigens geschriebene grafische Benutzungsschnittstellen mittels der XML-APIs vorzunehmen; darüber hinaus verhilft das XML-Format aber auch zu einem schnellen Überblick auf die Struktur und Semantik, sofern man einen Texteditor bevorzugt.

Die Konfigurationseintellungen sind an zwei Stellen angesiedelt: Der /conf Ordner, der überwiegend für die Konfiguration systemweiter Basisdienste gedacht ist, sowie der /deploy Ordner, in dem erweiterte Dienste, wie zum

⁹⁹ [Log4jProject03]

Beispiel JMX-Connectors, konfiguriert werden können. Einige wichtige Dateien in /conf seien kurz vorgestellt:

7.4.1 jboss-service.xml

Nach der Initialisierung des als Mikrokernel von JBoss fungierenden MBean-Servers, werden einige grundlegende Basisdienste in der Form von XMBeans (Siehe →Kapitel 6.3.3 JMX-ARCHITEKTUR - ARCHITEKTURELEMENTE - JBOSS

XMBEANS) - über die jboss.service.xml geladen. Darunter zählen verschiedenartige Deployer Dienste, das Logging System und der Namens- und Verzeichnisdienst. Optional werden in erweiterten Server Konfigurationen etwaige Klassenlader und Dienste, die die Transaktions- und Sicherheitsdienste betreffen, geladen. Leider ist eine vollständige Betrachtung dieser XMBeans im Rahmen dieser Arbeit nicht möglich - einige der wichtigsten Einstellgrößen für den JBoss sollen aber nicht unerwähnt bleiben.

Das PooledInvoker MBean verwaltet alle gepoolten, also temporär passivierten Netzwerkverbindungen. Je nach Ausstattung der Hardware können die markierten Werte zwecks Performancesteigerung verändert werden:

...

Die automatische Installation und Deinstallation von Komponenten, seien diese serverspezifisch, also J2EE-Architekturelemente und erweiterte Basisdienste, oder anwendungsspezifisch, also von den Server Betreibern selber entwickelt, obliegt den so genannten ʺDeployernʺ. Der als MBean realisierte Deploy-Dienst überprüft dazu in regelmäßigen Abständen das Deploy-Verzeichnis der jeweiligen JBoss-Installation, und übergibt, abhängig von der Dateiendung, das neu hinzugefügte, manipulierte oder entfernte Objekt an

spezielle Deployer weiter. Im JBoss gibt es JAR-Deployer für Java-Archive und Bibliotheken, EAR-Deployer für das Entpacken kompletter J2EE Applikationen, SAR-Deployer für benutzerdefinierte Basisdienste, WAR-Deployer für Webapplikationen, sowie EJB-Deployer für die Installation von Enterprise Java Beans. Das für die Weiterleitung zuständige MainDeployer MBean lässt sich an dieser Stelle anpassen:

Wichtige Einstellgrößen sind die zu überprüfenden Verzeichnisse, das Scan-Intervall, sowie ein Sorter- und ein Filterobjekt, mittels derer die Reihenfolge der zu installierenden Komponenten festgelegt oder das Deployment auf bestimmte Komponententypen eingrenzt werden kann.

7.4.2 *-service.xml

Alternativ zur jboss-service.xml lassen sich auch individuell angepasste JBoss Systeme durch *.service.xml Dateien im /deploy Ordner zusammenstellen. JBoss Group empfiehlt, für jeden Zusatzdienst eine eigene XMBean-XML-Datei mit dieser Endung zu versehen, damit sie ohne weiteres der automatischen Hot-Deplay Funktion übergeben, als auch von den Basisdiensten getrennt konfiguriert werden kann. Einer der standardmäßig installierten Zusatzdienste, der Emailservice, ist der ʺdefaultʺ Server Konfiguration beigelegt. Sinn und Zweck dieses Dienstes ist der einheitliche und abstrahier- te Zugriff auf ein Mailkonto zum Versenden und Empfangen von Emails.

Die Kontoeinstellungen werden, vom Code ausgelagert, als Attribute während des Dienststarts in der mail-service.xml übergeben:

Äquivalent dazu ist auch die Funktionsweise der restlichen *service.xml Dateien im /deploy Ordner zu verstehen.

7.4.3 standardjaws.xml

Äquivalent zur standardjbosscmp-jdbc.xml für die EJB Spezifikation 2.x kann der Persistenzdienst JBossCMP für die EJB Spezifikation 1.x durch die standardjaws.xml konfiguriert werden. Der Persistenzmechanismus beider Spezifika unterscheidet sich nämlich nur geringfügig, vordergründig durch die in 2.x eingeführte EJB-QL Abfragesprache. Neben der Standardeinstellung für die zu verwendende Datenbank kann zudem das objektrelationale Mapping (Siehe →KAPITEL 4.3.3 VERTEILUNGSPLATTFORMEN - BA- SISDIENSTE -PERSISTENZDIENST) an dieser Stelle gezielt gesteuert werden. Nachfolgend ein Ausschnitt:

Die Referenz der zum Installationszeitpunkt festgelegten DataSource gibt dem Persistenzmanager den Hinweis auf die Ziel-Datenbank. Da sich die Abbildung der persistenten Java-Objekte auf die SQL-Typen von Hersteller zu Hersteller unterscheidet, beinhaltet die standardjaws.xml voreinge- stellte Zuordnungen für etwa ein Dutzend unterschiedlicher Datenbankpro-

dukte. Für einen standardmäßigen Einsatz von MySQL sollten die obigen Einstellungen gewählt werden.

7.4.4 standardjboss.xml

Die Anpassung des EJB Containers lässt sich mit der standardjboss.xml sehr granuliert vornehmen. Das modulare Design kommt dadurch zum Tragen, indem für jeden EJB-Typ ein eigenständiger Verbund von Klassen für die Bearbeitung bereitgestellt werden kann. Diese nehmen unterschiedliche Aufgaben wahr: die Verwaltung des Lebenszyklus, der Sicherheitsrichtlinien, oder das Generieren der für die Kommunikation notwendigen Stubs. Ein „Interceptor“-Mechanismus erlaubt zudem das Einbinden von Filterklassen innerhalb einer Aufrufkette. Kundige Systementwickler schätzen diesen hohen Grad der Flexibilität; der Preis liegt aber in einer sehr zeitintensiven Auseinandersetzung mit dem Quellcode, für die auch der Umfang dieser Arbeit nicht ausreicht. Ein Ausschnitt:

Einige interessante Einstellungsmöglichkeiten bieten sich in Bezug auf die Verwaltung des EJB-Pools. So lässt sich an dieser Stelle die Kapazität des Ca-

che-Pools, dessen Verwaltung, sowie die Kriterien für das Löschen passivierter, also vorübergehend stillgelegter EJBs bestimmen. Genaue Anweisungen und Tipps bezüglich der Container-Konfiguration und den enthaltenen XML-Elementen kann man in der offiziellen JBoss Dokumentation nachschlagen.

7.5 STARTVORGANG

Eine Analyse der Systemmeldungen während des Startvorgangs gibt aufschlussreiche Information über den Startvorgang selbst, sowie über die in der Architektur eingebundenen Elemente. In der Minimal-Server-Konfiguration sind die Aufrufe leicht zu überschauen.

Zu Beginn werden alle relevanten Pfade der Ziel-Umgebung, einschließlich dem Speicherort der jboss-service.xml ermittelt.

Ermitteln von Informationen über das Zielsystem, und der Java Virtual Machine:

Starten und Initialisieren der Deploy-Dienste:

Installation der in der jboss-service.xml aufgeführten Basisdienste:

Installation des in →Kapitel 7.2.3 JBOSS - INSTALLATION UND KONFIGURATION

- EINRICHTEN DER UMGEBUNG - MYSQL beschriebenen DataSource Objektes:

Der in →Kapitel 7.4.2 JBOSS - INSTALLATION UND KONFIGURATION - KONFIGU- RATIONSDATEIEN - *-SERVICE.XML besprochene Maildienst:

Der Startvorgang ist nach einer Bearbeitung eventueller benutzerdefinierter Dienste abgeschlossen.

8.1 MANAGEMENTDIENSTE

In Application Server Produkten integrierte Managementdienste unterstützen die Arbeit von Administratoren und Anwendungsentwicklern, indem sie eine einheitliche, benutzerfreundliche Konfigurationsschnittstelle für die Einsicht und Manipulation der Systemeinstellungen bereithalten (Siehe →Kapitel 4.3.2 VERTEILUNGSPLATTFORMEN - BASISDIENSTE - MANAGEMENT- DIENSTE). Durch Installation von JMX-Protokoll-Adaptern bietet sich in JBoss ein effizienter Weg dies zu tun - schließlich sollen die Vorzüge der JMX Architektur nicht unberücksichtigt bleiben. Ein anderer Ansatz zur technischen Realisierung ist der Gebrauch von Applets und Webapplikationen, die in einem integriertem Web Container Zugriff auf die Systemparameter erhalten. Beide Möglichkeiten erlauben ein entferntes Management der JBoss Application Servers über einen Thin Client.

8.1.1 JBoss Management Console

Die Voraussetzung für den Betrieb der als HTML-Adapter realisierten JMX Management Console ist neben einem integrierten Web Container (Für Jetty: /jbossweb-jetter.sar Ordner) das Webarchiv jmx-console.war. Sind beide Archive in /deploy vorhanden, lässt sich, je nach Konfiguration, durch Eingabe von http://localhost:8080/jmx-console die Konsole in einem üblichen Internet-Browser aktivieren:

Abbildung 8.1: JBoss Management Console - JMX Agent View

Die Ansicht dieses JMX-Adapters liefert natürlich einen weitaus komplexe- MBean Struktur-Baum, als in dem Beispiel von →Kapitel 6.3.4 JMX-ARCHITEKTUR - ARCHITEKTURELEMENTE - JMX ADAPTER UND CONNECTORS. Der Namensraum der MBeans besteht aus dem Root-Element „jboss“; alle instanziierten MBeans werden durch eine zweite Hierarchiestufe klassifiziert. Die während der Laufzeit änderbaren Eintellungen können hier zentral verwaltet werden. Ein Klick, beispielsweise auf den JNDI-View Dienst, gibt eine kurze Beschreibung, sowie die in der MBean enthaltenen Attribute und Operationen wieder.

Abbildung 8.2: JBoss Management Console - MBean View

Der JNDI-View Dienst ermöglicht die Einsicht in den JNDI Namensraum eines laufenden JBoss Systems. Durch die Ausführung der list()- Operation kann zum Beispiel der vollständige Inhalt des Verzeichnisses ausgegeben werden - ein sinnvolles Hilfsmittel bei der Verwaltung oder Einführung neuer JNDI Ressourcen.

8.1.2 Administration Console

Ergonomisch besser gestaltet zeigt sich die „Administration Console“, lokalisiert in der web-console.war im /deploy/management Ordner. Durch den Aufruf von http://localhost:8080/web-console wird sie gestartet:

Abbildung 8.3: Administration Console

Ein Java Applet im linken Frame des Browserfenster dient der Navigation innerhalb der Konsole. Die „Administration Console“ erweist sich, neben dem eingebauten HTML-Adapter, bei der Überwachung von EJBs und Servlets als besonders nützlich. Die vorhandenen Möglichkeiten zur Überwachung und Statistik sind schnell erfasst und intuitiv zu bedienen.

8.2 DEPLOYMENT AM BEISPIEL

Die Installation einer J2EE-Anwendung auf den JBoss Application Server soll im Folgenden exemplarisch anhand eines Referenz-EJB-Verbundes erklärt werden. Der Gegenstand der Anwendung, das Verwalten von Primärschlüssel-Eigenschaft-Tupeln, wurde bereits im →Kapitel 5.4 - J2EE ALS STAN- DARDARCHITEKTUR - EJB-KOMPONENTENMODELL Quelltextbeispiel angeführt. Um die Anwendung im JBoss zu deployen, ist noch die Anpassung eines JBoss spezifischen Weitergabe-Deskriptors vonnöten, sowie das Kompilieren und das Erzeugen eines Java Archivs im JAR-Format. Üblicherweise vollziehen sich diese Schritte mit Hilfe einer integrierten Entwicklungsumgebung viel rasanter.

8.2.1 jboss.xml

Neben der ejb-jar.xml erhalten J2EE-Entwickler mit einem zusätzlichen, JBoss spezifischen Weitergabe-Deskriptor, die Möglichkeit, den zu installierenden EJB-Verbund auf die Gegebenheiten der jeweiligen JBoss Instanz einzustellen. In der jboss.xml lassen sich vorwiegend die JNDI Namen der EJBs, sowie deren, zuvor in der ejb-jar.xml deklarierten Referenzen zu anderen Ressourcen und EJBs verzweigen. Den im →Kapitel 5.4 - J2EE ALS

STANDARDARCHITEKTUR - EJB-KOMPONENTENMODELL eingeführten Beispiel folgend, sähe die XML-Datei so aus:

8.2.2 jaws.xml

Soll die Persistenz der zu installierenden EJBs „container-managed“, also vom Persistenzmanager automatisiert durchgeführt werden, ist ein zusätzlicher Deskriptor erforderlich. Diese herstellerspezifische Konfigurationsdatei dient als Brücke zwischen den in der Logik verankerten persistenten Attributen und dem Persistenzdienst des Application Servers, in diesem Fall JBossCMP oder Jaws für die ältere EJB Spezifikation 1.x. Die JBossspezifische jaws.xml enthält die Definition der finder-Methoden, sowie die Namen der zu verwendenden Tabellen- und Spaltennamen in der relationalen Datenbank. Ein typischer Deskriptor dieser Sorte sieht folgendermaßen aus:

Die Beschreibung der finder-Methoden, mittels der die konkreten EJB Instanzen gefunden werden, unterliegt dabei einem festgelegten Syntax. Bei JBoss dient ein in geschweiften Klammern eingeschlossener Index als Platzhalter für die übergebenen Suchparameter, die innerhalb einer SQL konformen WHERE-Klausel eingesetzt sind. Die Angabe des JNDI Namen des serverweit konfigurierten DataSource Objektes (Siehe →Kapitel 7.2.3 JBOSS -INSTALLATION UND KONFIGURATION - EINRICHTEN DER UMGEBUNG - MYSQL) genügt, um das zu verwendende Persistenzmediums für die Objektdaten zu bestimmen.

8.2.3 Kompilieren, Packen und Deployen

Das Überführen der Quellcodes in den Bytecode erfolgt unter Einbindung der J2EE Bibliotheken auf der Kommandozeilenebene mit folgendem Aufruf:

javac -classpath %JBOSS_HOME%\client\jboss-j2ee.jar *.java

Sind die Quellcodes erfolgreich kompiliert, können anschließend die Deskriptoren, der Spezifikation gemäß, in einen Unterordner namens /WEB-INF verschoben werden. Die Anordnung der Dateien sollte dann vor dem Umwandeln in das handliche JAR-Format dieser Struktur entsprechen:

\ MeinObjektBean.class MeinObjektHome.class MeinObjektRemote.class \WEB-INF ejb-jar.xml jboss.xml jaws.xml

Die Java 2 Standard Edition stellt für das Erzeugen von Java-Archiven ein kleines Komprimierungstool zur Verfügung, das auf diese Weise benutzt wird:

Ohne weiteres Zutun kann nun die neu generierte JAR-Datei in das /deploy Verzeichnis der JBoss Installation abgelegt werden. Nach wenigen Sekunden wird der Deployer aktiv und erzeugt automatisch die notwendigen Stubs und bindet diese mit den neuen EJBs in das bestehende System ein. Eventuelle Neueinträge in der Tabellenstruktur werden ebenfalls eigenständig eingefügt. Der Vorgang lässt sich im Ausgabefenster von JBoss verfolgen:

8.2.4 Testlauf

Um das deployte Bean zu testen, bietet sich einerseits eine herkömmliche textbasierte Java-Anwendung an, oder auch eine JSP im Web Container. Um auch gleichzeitig die Zusammenarbeit mit dem Tomcat zu überprüfen, ist letzteres vorzuziehen. Der Inhalt der JSP sähe wie folgt aus:

Die JSP-Datei kann zum Beispiel als test.jsp im /webapp/ROOT Verzeichnis der Tomcat Installation liegen. Den Zugriff auf die Bibliotheken erhält die JSP über den /shared/lib Ordner - an dieser Stelle sollte eine Kopie der meineobjekte.jar vorhanden sein. Ob sich die Mühe gelohnt hat, erfährt man über den Internet Browser:

Abbildung 8.4: Aufruf der Test-JSP

Eine ausgereifte Applikation mit der hier beschriebenen JBoss Application Server Umgebung kann man bei „System2Teach“, einem Projekt des Hochschulverbands „Hochschulen für Gesundheit“ in Aktion sehen ¹⁰⁰ .

¹⁰⁰ Siehe: http://www.hochges.de

9.1 DEFINITION

Die Geschichte der Freien Software geht auf den Anfang der 70er Jahre zurück, als der Programmierer und Hacker, sowie Gründungsvater der Freien Software, Richard Stallman, in der zunehmenden Kommerzialisierung der Software und der Geburtsstunde der ersten „reinen“ Softwareunternehmen eine Einschränkung der Freiheit der Anwender, sowie des freien Informationsflusses in der Softwareentwicklung befürchtete ¹⁰¹ . Durch das Verfassen des GNU ¹⁰² -Manifestes, sowie der Entwicklung eines „freien“ Betriebssystems legte er den entscheidenden Grundstein für die Philosophie der Freien Software und untermauerte diese durch zahlreiche Argumente gesellschaftlicher und sozioökonomischer Art.

Abbildung 9.1: „GNU’s not Unix!“ Logo

Zu den grundlegenden Eigenschaften Freier Software gehört es, dass sie (1) ohne Einschränkungen benutzt werden darf, (2) der Quelltext der Software einsehbar, sowie für jedermann änderbar ist und (3) die Software in ihrer ursprünglichen oder veränderten Form ausschließlich unentgeltlich weitergereicht werden darf ¹⁰³ . Richard Stallman fasst die Motivation, aus der das GNU-Projekt heraus entstanden ist, folgendermaßen zusammen:

¹⁰¹ Vgl. [Grassmuck01] S. 217 - 219 ¹⁰² selbstbezügliche Abkürzung: GNU - GNU is not Unix! ¹⁰³ Vgl. [SnoopyMüller99] S.12 - 15

ʺJede Entscheidung, die jemand trifft, beruht auf den Wertvorstellungen und Zielen dieser Person. Menschen können viele verschiedene Wertvorstellungen und Ziele haben; Ruhm, Geld, Liebe, Überleben, Spaß und Freiheit sind nur einige der Ziele, die ein guter Mensch haben kann. Wenn das Ziel darin besteht, anderen ebenso wie sich selbst zu helfen, nennen wir das Idealismus. Meine Arbeit an Freier Software ist von einem idealistischen Ziel motiviert: Freiheit und Kooperation zu verbreiten. Ich möchte dazu beitragen, dass sich Freie Software verbreitet, um proprietäre Software zu ersetzen, die Kooperation verbietet, und damit unserer Gesellschaft zu einer besseren zu machen.ʺ (Richard Stallmann, 1998)

Freie Software, die nicht nur als ein Produkt, sondern auch als ein Prozess zu verstehen ist ¹⁰⁴ , definiert somit eine bestimmte Form der Gemeinnützigkeit im Bereich der Softwareentwicklung. Der nötige Reiz, als volontärer Mitstreiter der Freien Software zu wirken, kann aber neben uneigennützigen, etwa der Förderung einer kollektiven Identität, auch aus persönlichen Motiven, wie zum Beispiel der Suche nach neuen Herausforderungen oder einem zu erstrebenden Wissenszuwachs, herrühren.

Dem gegenüber steht das allgemein bekannte Modell der proprietären Software, die dem Anwender nicht die Software selbst, sondern lediglich die Nutzungsrechte derselben in einer eingeschränkten Form und unter Abgabe eines finanziellen Entgeltes zur Verfügung stellt. Oftmals wird zur Beschreibung kommerzieller Software das Bild der „black-box“ geprägt, die in einer verpackten und von außen nicht einsehbaren Form dargeboten wird - ein fauler Kompromiss zum Schutz des geistigen Eigentums, so die Gegner.

¹⁰⁴ Vgl. [Grassmuck01] S. 246

9.2 ABGRENZUNG

9.2.1 Open Source

Freie Software wird in Fachkreisen immer häufiger durch den Begriff des Open Source ersetzt, wohingegen Open Source der wortwörtlichen Bedeutung nach lediglich ein Merkmal beschreibt, und zwar, dass die Quelltexte der Software für jedermann einsehbar vorliegen. Die Angabe, eine Software sei Open Source macht demzufolge keine Aussage darüber, ob diese manipuliert oder unter welchen Bedingungen sie betrieben werden darf. Dass sich der synonyme Gebrauch des Begriffes Open Source stellvertretend für Freie Software immer stärker durchgesetzt hat, so jedenfalls wird vielfach in der Szene postuliert, ist auf die politisch gesehen negative Konnotation des Anhängsels „frei“ zurückzuführen. Die Fangemeinde der „freien Software“ nämlich hält sich in erster Linie nicht an die praktischen Vorteile der Quelltextoffenheit fest, sondern vordergründig an ihren ethischen Beweggründen.

ʺOpen Source ist eine Methode, Freie Software dagegen eine soziale Bewegung“ 105

9.2.2 Freeware

Bei Freeware handelt es sich um copyright-geschützte Software, die kostenlos, aber ohne Änderungsfreiheit vertrieben werden darf. Meist verweisen die Autoren von Freeware aber auf die Möglichkeit, sich durch Spenden ¹⁰⁶ an der Weiterentwicklung des Softwareproduktes zu beteiligen. Unternehmen vertreiben Freeware, mit dem Ziel, sich marktstrategisch besser zu positionieren; Adobe Systems Incorporated hat dies mit dem Acrobat Reader eindrucksvoll bewiesen ¹⁰⁷ .

¹⁰⁵ Vgl. [GNUOpenSource03] ¹⁰⁶ engl. donations ¹⁰⁷ Siehe: http://www.adobe.de

9.2.3 Shareware

Eine häufig anzutreffende Form der Software bildet die Shareware, die mit der Intention, möglichst viele Anwender zu erreichen, meist in einer abgespeckten oder für einen bestimmten Nutzungszeitraum verfügbaren Version in Umlauf gebracht wird. Durch das Aufwenden einer Registrierungsgebühr kann diese, sofern es erwünscht wird, zu einer voll funktionstüchtigen Software freigeschaltet werden. Ein Klassiker der Shareware ist das Komprimierungstool WinZip ¹⁰⁸ .

9.2.4 Public Domain

Im Falle der Public Domain Software verzichten die Urheber gänzlich auf ihre Ansprüche und erklären das Werk zum „Allgemeingut“, das beliebig vervielfältigt und ohne Einschränkungen benutzt werden darf ¹⁰⁹ . Public Domain Software unterscheidet sich von der Freien Software im Wesentlichen dadurch, dass sie keinerlei restriktiven Lizenzbedingungen, wie in dem folgenden →Kapitel 9.5 - FREIE SOFTWARE - LIZENZEN DER FREIEN SOFTWARE näher erläutert wird, unterliegt.

9.3 VORZÜGE FREIER SOFTWARE

Aus den grundlegenden Merkmalen der Freien Software ergeben sich für das resultierende Softwareprodukt eine Reihe von Vorteilen, die folgendermaßen charakterisiert werden können:

9.3.1 Qualität des Quellcodes

Durch die geforderte Quelltextoffenheit werden Anwendungsentwickler indirekt dazu angehalten, nicht nur die Funktionalität effizient zu programmieren, sondern auch entsprechend gut zu strukturieren. Schließlich ist die Lesbarkeit eines Quelltextes maßgeblich für die Akzeptanz und damit der Möglichkeit, dass er stetig in einem sich selbst überlassenen Prozess inner- ¹⁰⁸ Siehe:http://www.winzip.de ¹⁰⁹ Vgl. [Gehring96]

100

halb der offenen Entwicklergemeinde verbessert wird, mit verantwortlich. Die Wahrscheinlichkeit, auf Programmfehler zu stoßen, die häufig auch sicherheitsrelevante Aspekte betreffen, liegt im Gegensatz zu proprietärer Software weitaus höher. Da sich die „Open Source“-Gemeinde aus einer großen Zahl ambitionierter Bastler und Tüftler zusammensetzt, kann ein weitaus größeres Potential entwickelt werden, vorhandene Sicherheitslücken aufzudecken und diese auch innerhalb einer kurzen Reaktionszeit durch Sicherheitsupdates in der Form von Patches („Bugfixes“) zu schließen ¹¹⁰ . Der offene Quelltext dient dabei als wesentliche Voraussetzung.

9.3.2 Zukunftssicherheit

Die Zukunftssicherheit von Softwaresystemen ist aufgrund ihrer kostenintensiven Einführung und den pflege- und wartungsbedingten Folgekosten generell ein wichtiges Entscheidungskriterium. Eine Notwendigkeit zur Durchführung von Änderungen und Anpassungen entsteht aus vielerlei Anlässen. Zum einen spielen, vor allem in betriebswirtschaftlichen Anwendungen, die Anpassung der Geschäftlogik an die jeweils geltenden Rechtsbestimmungen, aber auch veränderte Rahmenbedingungen betreffend den Arbeitsabläufen in einer Unternehmung eine große Rolle. Nicht selten stehen Systembetreiber bei den häufig in der Wirtschaft üblichen Fusionierungen und strukturellen Umbrüchen vor einem immensen Integrations- und Anpassungsbedarf, der weit über die herkömmlichen und ursprünglich vorgesehenen Konfigurationsmöglichkeiten der zu integrierenden Systeme hinaus geht.

Durch die Tatsache, dass sich der Quelltext Freier Software ohne urheberrechtliche Bedenken verändern lässt, ergibt sich für Systementwickler eine viel bessere Ausgangslage, um dem oben beschriebenem Szenario Herr zu werden. Eventuelle Abhängigkeiten seitens der Herstellerfirmen, was die Lizenzierung betrifft, entfallen ebenso, wie die naturgemäßen Grenzen der ¹¹⁰ Vgl. [HeiseNews00]

101

Konfigurierbarkeit proprietärer Software. Die offenen Datenaustauschformate erlauben es, ohne Restriktionen, ein jedes System an ein anderes zu koppeln und auf unternehmensspezifische Feinheiten abzustimmen ¹¹¹ . Dies kann geschehen, ohne auf die Professionalität und den Bekanntheitsgrad der Software zu verzichten.

Auch die Unabhängigkeit von einem Softwarehersteller wird letztlich als Argument aufgeführt, da er als alleiniger Lieferant für sich das Recht beansprucht, welche Produktlinie in Zukunft gepflegt werden soll. Abgesehen eines Bankrotts dessen, kann es schlimmstenfalls dazu kommen, dass ein proprietäres System unbrauchbar wird - da keine Produktaktualisierungen mehr folgen.

9.3.3 Kollektiver Lernprozess

Neben den vorrangig wirtschaftlich orientierten Vorzügen gibt es noch eine Menge andere, die weniger offensichtlich, aber sehr bedeutend in ihrer Wirkung sind. Der allgemeine Schub an informationstechnischem Know-how, der durch das Studium von Quelltexten und deren Arbeitsweise einhergeht, ist hinlänglich bekannt. Der kommerzielle Bereich kann diesen Nutzen für sich nur bedingt in Anspruch nehmen, da erstens die Quelltexte nicht offen liegen und zweitens die durch proprietäre Software erworbenen Kenntnisse häufig nur auf der Anwendungsebene eines bestimmten Produktes beschränkt sind.

Der kollektive Lern- und Bildungsprozess trägt oftmals schon in der beruflichen Ausbildung, beispielsweise im universitären Bereich, seine Früchte. Da der Einsatz kommerzieller Lösungen in wissenschaftlichen Projekten, aber auch generell der Betrieb von informationellen Infrastrukturen nicht immer finanziell vertretbar ist, greift man häufig auf die kostenlos verfügbaren „freien“ Lösungen zurück. So besitzen viele Akademiker, die neu in das Be-

¹¹¹ Vgl. [Grassmuck01] S.359

102

rufsleben eintreten, fortgeschrittene Fertigkeiten im Umgang mit Freier Software; dies kann sich etwa auf kürzere Schulungs- und Einarbeitungszeiten beim Arbeitgeber niederschlagen.

9.4 OPEN SOURCE IN DER PRAXIS

9.4.1 Organisation und Ablauf

Den Startschuss für ein Open Source Projekt liefern neben marketingorientierten Firmen üblicherweise erfahrene Programmierer, die als Individuen, oder aber auch als eine geschlossene Gruppe versierter IT-Anwender mit einer neuen Idee in die Öffentlichkeit treten ¹¹² . Zunächst im kleinen Kreis, später auf speziellen Kommunikationsplattformen im Internet werden daraufhin engagierte Mitarbeiter und Begeisterte gesucht, die auf freiwilliger Basis ihre Arbeitskraft beisteuern. Die Arbeitsabläufe folgen weitestgehend erprobten Schemata, die sich durch flache Hierarchien, einem verstärkten Nutzen des Internets, sowie einer starken Anlehnung an die Endanwender, auszeichnen.

Öffentlich zugängliche Kommunikationsplattformen in Form von „Project Homepages“ fungieren für die jeweiligen Projekte als wichtiges Arbeitswerkzeug. Sie dienen als Visitenkarte im Internet und bieten neben den aktuellen Projektstatus eine Reihe weiterer Informationen in Form von Mehrzweckdiensten an. Um ein problemloses Arbeit an den Quelltexten seitens mehrerer Entwickler zu ermöglichen, kommt das CVS ¹¹³ , ein freies Versionsverwaltungssystem, zum Einsatz. Ferner werden der Kommunikation förderlichen Dienste, wie beispielsweise Mailinglisten, Foren oder etwa Dokumentationen und Patches bereitgestellt, die jeweils auf beide Zielgruppen, Entwickler und Endanwender, zugeschnitten sein können. Für weniger erfahrene Nutzer bieten so genannte „Feature Requests“ einen interessanten Anlaufpunkt, sich durch eigene Ideen und Vorschläge unmit- ¹¹² Vgl. S.235-236 ¹¹³ CVS - Concurrent Versions System

Anlaufpunkt, sich durch eigene Ideen und Vorschläge unmittelbar in das Projektgeschehen einzubinden.

Einer der prominentesten Websites, die solcherlei Dienste für Open Source Projekte bereitstellt, ist das mittlerweile über 70.000 Projekte umfassende Sourceforge.net ¹¹⁴ .

Abbildung 9.2: Sourceforge.net

In der Praxis hat sich gezeigt, dass ungeachtet der losen und informellen Arbeitsbeziehungen sehr erfolgreiche Softwarelösungen entstanden sind. Überraschend ist auch der große Zulauf seitens professioneller Entwickler, die sich gerne mal in Open Source Projekten auch ehrenamtlich involvieren ¹¹⁵ .

¹¹⁴ Siehe: http://www.sourceforge.net ¹¹⁵ Am Beispiel von JBoss: [SourceforgeMem03]

9.4.2 Finanzierung

Die Geschäftsmodelle der Freien Software sind neben dem Distributionsgeschäft vor allem im Bereich der Dienstleistungen angesiedelt ¹¹⁶ . Es hat sich eine beachtlicher Markt von kleinen Dienstleistungsunternehmen gebildet, die einen Mix aus mehreren Strategien im Portfolio verfolgen. Beim Vertrieb Freier Software werden meist neben dem Hauptprogramm auch nützliche Funktionen und Zusatzprogramme zu einem in sich abgeschlossenen Softwarepaket gebündelt. Derlei Pakete verhelfen Laien zu einem besseren Einstieg und bieten eine recht umfangreiche Sammlung zusammenhängender Software, die sonst mühselig im Internet zu sammeln wäre. Vor allem Linux Distributoren haben sich dieses Geschäftsfeld zu eigen gemacht ¹¹⁷ . Der Bereich des Consulting spielt eine ebenso große Rolle; darunter fällt die Beratung und Unterstützung großer Unternehmen beim Durchführen ihrer, auf Freier Software basierenden IT-Projekte. Daneben stellen Seminare und Schulungen, angeboten durch spezielle Tagungen, in denen Mitarbeiter unternehmensinterner Abteilungen auf einen professionellen Einsatz in ihrer Firma vorbereitet werden, einen rasant wachsenden Markt innerhalb der Open Source Branche dar. Nicht zuletzt bietet der Support einen wichtigen Kernbereich, der nach einer einmaligen Einführung einer Open Source Lösung auch während ihres Betriebes als Geldquelle erhalten bleibt.

¹¹⁶ Vgl. [Hetze99]

¹¹⁷ Prominentes Beispiel: http://www.suse.de

9.5 LIZENZEN DER FREIEN SOFTWARE

Software ist in Deutschland durch das Urheberrechtsgesetz auch ohne eine explizite Angabe des Autors des Werkes, also dem Programmierer, urheberrechtlich geschützt ¹¹⁸ . Das heißt, dass die Software ohne Einverständnis des Urhebers weder benutzt, vervielfältigt oder bearbeitet werden kann. Die normalerweise einem Softwarepaket beigelegte Lizenzvereinbarung dient dann als ein zusätzlicher Kontrakt, den der Verfasser dazu nutzt, den Käufern Nutzungsrechte einzuräumen, die einen sinnvollen Gebrauch der Software möglich machen. Freie Software nutzt ebenfalls die Lizenzvereinbarungen; jedoch nicht, um Nutzungsrechte zu erteilen, sondern um die Voraussetzungen für ihren Fortbestand zu sichern. In den Nutzungsbedingungen Freier Software finden sich demnach auch alle wesentlichen im →Kapitel 9.1 - FREIE SOFTWARE - DEFINITION angesprochenen Klauseln wieder, wovon die so genannte „Virus-Klausel“ in diesem Zusammenhang die wichtigste ist. Mit der Forderung geknüpft, dass verschiedene Ausführungen der Software, seien diese in der ursprünglichen oder in der veränderten Fassung, ausschließlich wieder als Freie Software weiter verbreitet werden dürfen, wird eine Kommerzialisierung schon im Keim erstickt. Da hierdurch, je nach Lizenz, auch integrierte, nicht-freie Programmmodule unter die freie Lizenz gestellt werden müssen, spricht man von einer „Open Source Epidemie“, die immer mehr Software mit ihrer Lizenz „ansteckt“. In der Praxis haben sich hunderte, in ihrer Funktion größtenteils ähnelnde Lizenzen durchgesetzt. Als Pioniere gelten nach wie vor die von Richard Stallmann verfasste GNU Lizenz, oder etwa die von der Berkely Group initiierte BSD-Lizenz. Alle weiteren Lizenzen siedeln sich überwiegend an diese beiden an und tragen eher den Charakter einer Feinabstimmung.

¹¹⁸ Vgl. [Urhg03]

9.5.1 GNU General Public License

Die GNU General Public License (GPL), auch „Copyleft“ genannt, vereint in sich alle zuvor theoretisch ausgearbeiteten Merkmale der Freien Software. Auf den WWW-Seiten der GNU Projektes ¹¹⁹ lässt sie sich in ihrem vollen Umfang betrachten und nach Belieben auch für eigene Projekte verwenden. Es existiert darüber hinaus auch eine L-GPL (Lesser- oder Library GPL), die vorrangig für Programmbibliotheken zum Einsatz kommt. Sie unterscheidet sich von der ursprünglichen GPL hauptsächlich durch das Fehlen der „Virus-Klausel“ und macht sie deswegen besonders für Hersteller kommerzieller Software interessant, die ihre proprietären Softwarelösungen ohne Bedenken mit Codesegmenten Freier Software bestücken wollen.

9.5.2 BSD License

Die BSD ¹²⁰ License wurde ursprünglich von der Berkely Group, einer Forschungsgruppe der Berkely Universität in Kalifornien, die maßgeblich an der Verbreitung von Unix beteiligt war, verfasst. Die Lizenz, die unter anderem jeder Softwaredistribution, die ihr unterliegt, beigelegt werden muss, beinhaltet den Namen der Universität, sowie einen fest definierten Text bezüglich ihres Zweckes und einen Haftungsausschluss. ¹²¹ Da Freie Software unter der BSD Lizenz auch in manipulierter Form kommerziell vertrieben werden darf, ähnelt sie der L-GPL aus dem Hause GNU und genießt eine große Beliebtheit in der „Open Source“- Szene.

¹¹⁹ Vgl. [GNULic91] ¹²⁰ BSD - Berkeley Software Distribution ¹²¹ Vgl. [BSDLic99]

9.6 OPEN SOURCE IN ENTERPRISE UMBEGUNGEN

Die Vorzüge des Einsatzes Freier Software in verteilten Geschäftsanwendungen, speziell im Bereich der Application Server, zu denen sich auch der JBoss zählen kann, sollen an dieser Stelle näher beleuchtet werden. Die nachfolgend aufgezählten Punkte erheben nicht den Anspruch auf Vollständigkeit und können im Rahmen dieser Diplomarbeit unmöglich ausschöpfend in der Praxis nachgewiesen werden. Vielmehr handelt es sich dabei um eine Sammlung von Argumenten, die häufig von Distributoren selber angeführt werden, sowie um eine Reihe eigens gewonnener theoretischer Erkenntnisse, die sich aus der Betrachtung der Eigenschaften von Freier Software, sowie der von typischen Enterprise-Umgebungen ergeben haben.

Proprietäre Application Server Produkte werden üblicherweise im Markt für sehr hohe Preise angeboten ¹²² . Der Grund hierfür liegt einerseits in den niedrigen Verkaufszahlen, aber auch in der Komplexität der meist in sehr kurzen Abständen zu aktualisierenden Produktfamilien. Bei Freier Software entfällt der Anschaffungspreis komplett, und damit auch die Möglichkeit, eine falsche Sachinvestition getätigt zu haben.

Die Aufgabe von Softwarearchitekten besteht heutzutage kaum noch in der Entwicklung und Planung komplett neuer Softwarelösungen, sondern äußert sich vielmehr in der Integration und Erweiterung bereits bestehender Systeme. So zählt die Fähigkeit der Middleware, sich nahtlos in existierende, mehrere Anwendungen umspannende Systeme zu integrieren, zu den wichtigsten Qualitätsmerkmalen. Die Quelloffenheit Freier Software erlaubt eine uneingeschränkte Anpassung der Software, sei diese bei den Datenaustauschformaten, den verwendeten Protokollen oder anderen Schnittstellen(ebenen) angesiedelt.

¹²² Siehe: http://www.edv-buchversand.de/borlandshop/

Ein oft vernachlässigter Aspekt betrifft die vorhandenen Tools und Hilfsprogramme, die vor allem im Open Source Bereich eine eigene Dynamik entwickelt haben und nicht selten aus einer Notwendigkeit in einem etablierten Open-Source-Projekt heraus entstanden sind. Wo nämlich proprietäre Middleware speziellen anwendungsspezifischen Anforderungen von Natur aus nicht entgegen kommen kann, sind „Work-Arrounds“ in Projekten mit Open Source Software Alltag. Die äußerst populär gewordenen und mittlerweile auch von kommerziellen Produkten unterstützten Tools Ant ¹²³ oder das Struts Framework ¹²⁴ beweisen eindrucksvoll dieses Potential.

Kurzum, die künftige Entwicklung des Softwaremarktes, speziell im Bereich der Middleware, darf in diesem Zusammenhang mit Spannung verfolgt werden. Neben JBoss bestehen mit JOnAS ¹²⁵ und OpenEJB ¹²⁶ drei konkurrenzfähige Produkte, die jetzt schon am Marktanteil-Kuchen der proprietären Mitstreiter knabbern.

¹²³ Siehe: http://ant.apache.org/ ¹²⁴ Siehe: http://jakarta.apache.org/struts/ ¹²⁵ Siehe: http://jonas.objectweb.org/ ¹²⁶ Siehe: http://openejb.sourceforge.net/

10.1 LITERATUR- UND WEBVERZEICHNIS

10.1.1 Softwarearchitektur (Kapitel 2) [SunJ2SE03] Sun Microsystems, Inc.: „Java 2 Platform, Standard Edi- tion (J2SE)“ - http://java.sun.com/j2se/ (Okt. 2003) [SunJ2EE03] Sun Microsystems, Inc.: „Java 2 Platform, Enterprise Edi- tion (J2EE)“ - http://java.sun.com/j2ee/ (Okt. 2003) [JBoss03] The JBoss Group, LLC: „JBoss :: Professional Open Source“ - http://www.jboss.org (Okt. 2003) [Jakarta03] Apache Software Foundation: „The Jakarta Site - Apache Tomcat“ - http://jakarta.apache.org/tomcat/ (Okt. 2003) [MySQL03] MySQL AB.: „MySQL: The World’s Most Popular Open Source Database“ - http://www.mysql.org (Dez. 2003) [Bredemeyer03] Bredemeyer, Dana: ʺResources for Software Architectsʺ - PFP Software GmbH - http://www.thesite.de/Architektur.shtml (Okt. 2003) [SunWebtier03] Sun Microsystems Inc.: “Designing Enterprise Applica- tions with the J2EE Platform, Second Edition - 4.4. Web- Tier Application Framework Design” http://java.sun.com/blueprints/guidelines/designing_ente rprise_applications_2e/web-tier/web-tier5.html (Okt. 2003) [DunkelHolitschke03] Dunkel, Jürgen und Holitschke, Andreas: „Soft- warearchitektur in der Praxis“ - Berlin / Springer Verlag 2003

10.1.2 Verteilte Systeme (Kapitel 3) [TanenbaumSteen03] Tanenbaum, Andrew S. van Steen, Maarten: „Ver- teilte Systeme - Grundlagen und Paradigmen“ - Mün- chen / Pearson Studium 2003 [Bapat94] Bapat, Subodh: „Object-Oriented Networks - Models for Architecture and Management“- New Jersey / Prentice Hall 1994 [Weber98] Weber, Michael: „Verteilte Systeme“ - Heidelberg-Berlin / Spektrum Akademischer Verlag 1998 [Dohmann02] Dohmann, Helmut: „Verteilte multimediale Systeme“ - Skriptum der Lehrveranstaltung „MI-Systeme“ in der FH Fulda, 2002 [BornPartner03] Born & Partner: Infobroschüre „Digitales Vorgangsmanagement“ - http://www.bornundpartner.com/navigation/Angebot_fr ame.htm (Nov. 2003)

[PuderRömer01] Puder, Arno und Römer, Kay: „Middleware für verteilte Systeme“ - Heidelberg / dpunkt Verlag 2001 [Kubitzky95] Kubitzky, Stephan: „Netzwerk-Betriebssysteme - Auswahl und Einsatz in der Praxis“ - Freiburg / Haufe 1995 [W3CWebservices03] W3C - World Wide Web Consortium - “Web Services Activity” - http://www.w3.org/2002/ws/ (Okt 2003) [Frankel03] Frankel, S. David: „Model Driven Architecture - Applying MDA to Enterprise Computing“- Indianapolis (USA) / Wiley Publishing Inc.

10.1.3 Verteilungsplattformen (Kapitel 4)

[PuderRömer01] Puder, Arno und Römer, Kay: „Middleware für verteilte Systeme“ - Heidelberg / dpunkt Verlag 2001 [W3CSOAP03] W3C - World Wide Web Consortium - “Simple Object Access Protocol (SOAP) 1.1”http://www.w3.org/tr/soap/(Okt 2003)

[DennigerPeters02] Denninger, Stefan und Peters Ingo: “Enterprise Java Beans 2.0” - München / Addison-Wesley Verlag 2002 [VossenGross93] Vossen, Gottfried und Gross-Hardt Margret: “Grundlagen des Transaktionsverarbeitung” - München / Bonn / Addison-Wesley Verlag 1993

10.1.4 J2EE als Standardarchitektur (Kapitel 5) [SunJ2EEDownld03] Sun Microsystems, Inc.: „Java 2 Platform, Enter- prise Edition (J2EE) - Download & Specifications“ - http://java.sun.com/j2ee/download.html (Okt. 2003) [SunJ2EESpec03] Sun Microsystems, Inc.: “Java 2 Platform Enterprise Edi- tion Specification, v1.4” Pre-FCS, Proposed Final Draft 3 [EcksteiLoyWood98] Eckstein, Robert und Loy, Marc und Wood, Dave: „Java Swing“ - USA / O’Reilly 1998 [HunterCrawford98] Hunter, Jason und Crawford, William: „Java Serv- let Programming“ - USA / O’Reilly 1998 [SunJMS03] Sun Microsystems, Inc.: „Java Message Service“- http://java.sun.com/products/jms/ (Nov. 2003) [SunEJBSpec01] Sun Microsystems, Inc.: “Sun Microsystems Enterprise JavaBeans Specification, Version 2.0” Final Release [SunEJBDownload] Sun Microsystems, Inc.: “Enterprise JavaBeans Technol- ogy Downloads & Specifications” - http://java.sun.com/products/ejb/docs.html (Nov. 2003)

[LaMonica03] LaMonica, Martin: “Clash over Java standards heats up”

- ZDNet News 30. Mai 2003 - http://zdnet.com.com/2100- 1104-1011771.html?tag=nl (Dez. 2003) [Kunert03] Kunert, Karsten: “Branchengrößen bilden JBoss J2EE G.P.“

http://www.pressrelations.de/index.cfm?start_url=http% 3A//www.pressrelations.de/search/release.cfm%3Fr%3D 139940%26style%3D (Dez. 03)

10.1.5 JMX Architektur (Kapitel 6) [JMXWhiteP99] Sun Microsystems, Inc.: “Java Management Extensions White Paper - Dynamic Managemt for the Service Age”

- Palo Alto / USA 1999 [JMXFAQ03] Sun Microsystems, Inc.: “Java Management Extentions (JMX) Frequenty Asked Questions”http://java.sun.com/products/JavaManagement/faq.html (Dez. 2003)

[SunJavaBeans03] Sun Microsystems, Inc.: “JavaBean - The Only Component Architecture for Java Technology”http://java.sun.com/products/javabeans/ (Dez. 2003) [SunJMXSpec02] Sun Microsystems, Inc.: “Java Management Extensions Instrumentation and Agent Specification, v.1.2” Maintenance Release - Santa Clara / USA 2002 [Hendler99] Hendler, James: „Is There an Intelligent Agent in Your Future?“ - nature.com - the world’s best science on your desktop - 1999

http://www.nature.com/nature/webmatters/agents/agent s.html (Dez. 2003) [Green03] Green, Dale: “Trail: The Reflection API” - The Java Tuto- rial - Sun Microsystems, Inc. -

http://java.sun.com/docs/books/tutorial/reflect/ (Dez. 2003) [SunJ2EEAPIDoc03] Sun Microsystems, Inc.: “JavaTM 2 Platform Enterprise Edition, v 1.4 API Specification”http://java.sun.com/j2ee/1.4/docs/api/index.html (Dez. 2003) [SunJMXRefImpl03] Sun Microsystems, Inc.: “Java Management Extensions Download Information” - Download Reference Implementation

http://java.sun.com/products/JavaManagement/downloa d.html (Dez. 2003)

10.1.6 JBoss - Installation und Konfiguration (Kapitel 7) [JBossGroup03] JBoss Group, LLC. : “JBoss Group - Professional Open Source” - http://www.jbossgroup.com (Dez. 2003) [StarkJBoss03] Stark, Scott and The JBoss Group: “JBoss Administration and Development Third Edition (3.2.x Series)” JBoss Group LLC, Atlanta / USA 2003

[JakartaTomcat03] Apache Group: “The Jakarta Project - Apache Tomcat“http://jakarta.apache.org/tomcat/ (Dez. 2003) [Jetty03] Mort Bay Consulting: “Jetty Java HTTP Servlet Server”http://jetty.mortbay.org/jetty/ (Dez. 2003) [HyperSonic03] Sourceforge.net: “hsqldb - 100% Java Database”http://hsqldb.sourceforge.net/ (Dez. 2003) [MySQL03] MySQL AB.: „MySQL: The World’s Most Popular Open Source Database“ - http://www.mysql.org (Dez. 2003) [ApacheGroup03] The Apache Software Foundation - http://www.apache.org (Dez. 2003)

[SunJ2SEDownld03] Sun Microsystems, Inc.: “J2SE Downloads - The Source for Java Developers”http://java.sun.com/j2se/downloads/ (Dez. 2003) [jCVS03] “jCVS.org Homepage” - http://www.jcvs.org/ (Dez. 2003) [MySQLFront03] “MySQL Front” - http://www.mysqlfront.de/ (Dez. 2003)

10.1.7 Freie Software (Kapitel 9) [Grassmuck01] Grassmuck, Volker: „Freie Software - Zwischen Privat- und Gemeineigentum“ - Bonn / Bundeszentrale für poli- tische Bildung 2001

[SnoopyMüller99] Snoopy und Müller, Martin: „Open Source -kurz & gut“

- Köln / O’Reilly 1999 [GNUOpenSource03] gnu.org - „Why ‚Free Software’ is better than ‚Open Source’“- http://www.gnu.org/philosophy/freesoftware-for-freedom.html (Dez. 2003) [Gehring96] Gehring, Robert: “Freeware, Shareware und Public Domain” - Studienarbeit bei der TU Berlin - http://ig.cs.tuberlin.de/sa/043/ (Dez. 2003) [HeiseNews00] Heise Online News - „Bugfixes für Open-Source-Software schneller verfügbar als für ‚Kommerzware’“http://www.heise.de/newsticker/data/hps-18.01.00-000/ (Dez. 2003) [SourceforgeMem03] Sourceforge.net - “Project Member List” von JBoss

- http://sourceforge.net/project/memberlist.php?group_id= 22866 (Dez. 03) [Hetze99] Hetze, Sebastian: “Wirtschaftliche Aspekte von Freier Software” - Telepolis - Magazin der Netzkultur 1999http://www.heise.de/tp/deutsch/special/wos/6465/1.html (Dez. 2003)

[Urhg03] Urheberrechtsgesetz - UrhG der Bundesrepublik Deutschland, Stand September 2003: Abschnitt 2, §2 Geschützte Werke [GNULic91] Free Software Foundation, Inc.: “GNU General Public License” - Boston (USA)http://www.gnu.org/licenses/gpl.html (Dez. 2003) [BSDLic99] University of California: „The BSD License“ 1999 - Open Source Initiative

http://www.opensource.org/licenses/bsd-license.php (Dez. 2003)

116

10.2  ABBILDUNGSVERZEICHNIS  

  Abbildung 2.1: MVC Konzept  

  Abbildung 2.2: Drei-Schichten-Architektur  

  Abbildung 3.1: Taxonomie von Mehrrechnersystemen  

  Abbildung 3.2: Nachrichtenaustausch  

  Abbildung 3.3: Remote Procedure Call (RP)C  

  Abbildung 3.4: Netzbetriebssysteme.  

  Abbildung 3.5: Entfernte Datenbankzugriffe.  

  Abbildung 3.6: Verteilte Objektsysteme  

  Abbildung 3.7: Web Services im Internet  

  Abbildung 4.1: Verteilungsplattform als Mittelschicht  

  Abbildung 4.2: Middleware im OSI-Referenzmodell  

  Abbildung 4.3: Operationale Interaktion.  

  Abbildung 4.4: Entfernte Interaktion  

  Abbildung 4.5: Transparenter Zugriff.  

  Abbildung 4.6: Schnittstellen einer Verteilungsplattform  

  Abbildung 4.7: Verzeichnisdienst.  

  Abbildung 4.8: Persistente Objekte.  

  Abbildung 4.9: Objekte in asynchroner Kommunikation  

  Abbildung 4.10: Transaktionsdienst.  

  Abbildung 5.1: J2EE Architektur.  

  Abbildung 5.2: Datenbankzugriff über JDBC  

  Abbildung 5.3: Möglichkeiten der JNDI API  

  Abbildung 5.4: Kommunikationswege bei EJB-Transaktionen.  

  Abbildung 5.5: JMS Client.  

  Abbildung 6.1: Schichten der JMX Architektur  

  Abbildung 6 2: JMX Agent View des HTML Adapters  

117

  Abbildung 7.1: JMX als Datenbus in einer J2EE Umgebung  

  Abbildung 7.2: Neues Java Logo.  

  Abbildung 7.3: Offizielles JBoss Logo  

  Abbildung 7.4: Auschecken von JBoss mit jCVS  

  Abbildung 7.5: MySQL Logo.  

  Abbildung 7.6: MySQL-Front.  

  Abbildung 7.7: Tomcat Logo  

  Abbildung 7.8: Jakarta Tomcat Startseite.  

  Abbildung 8.1: JBoss Management Console - JMX Agent View  

  Abbildung 8.2: JBoss Management Console - MBean View  

  Abbildung 8.3: Administration Console.  

  Abbildung 8.4: Aufruf der Test-JSP.  

  Abbildung 9.1: „GNU’s not Unix “ Logo.  

  Abbildung 9.2: Sourceforge.net.  

118

10.3 ABKÜRZUNGSVERZEICHNIS

ACID Atomicity, Consistency, Isolation, and Durability API Application Programming Interface BMP Bean Managed Persistence BSD Berkeley Software Distribution CMP Container Managed Persistence CORBA Common Object Request Broker Architecture CVS Concurrent Versions System DNS Domain Name System DOS Disk Operating System DTD Data Type Definition EAI Enterprise Application Integration EAR Enterprise Archive EJB Enterprise Java Beans EXE Executable GNU GNUs not Unix! GPL General Public License GUI Graphical User Interface HTTP Hypertext Transfer Protocol J2EE Java 2 Enterprise Edition J2SE Java 2 Standard Edition JAR Java Archive JCA Java Connector Architecture JDBC Java Database Connectivity JMS Java Messaging System JMX Java Management Extensions JNDI Java Naming and Directory Service JSP Java Server Page JTA Java Transaction API JTS Java Transaction Service

119

LAN Local Area Network LDAP Lightweight Directory Access Protocol LGPL Lesser/Library General Public License MDA Model Driven Architecture MIMD Multiple Instruction Multiple Data (Flynn) MVC Model View Controller OMG Object Management Group ORB Object Request Broker OSI Open Systems Interconnection OTS Object Transaction Service PK Primary Key RAR Resource Archive RMI Remote Method Invocation

RMI-IIOP Remote Method Invocation over the Internet InterOrb Protocol RPC Remote Procedure Call SAR Service Archive SIMD Single Instruction Multiple Data (Flynn) SISD Single Instruction Single Data (Flynn) SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SQL Structured Query Language WAR Web Archive XML Extensible Markup Language

10.4 GLOSSAR

ACID-Prinzip Gewährleistung von Eigenschaften, die Transaktionen besitzen müssen, um reibungslos synchron ablaufen zu können APIs Programmierschnittstellen, meist zusammengefasst in Programmbibliotheken Applets Besonders für das Internet geeignete →Java Programme mit eingeschränkerter Funktionalität BMP Persistenzmodell in →J2EE, bei dem die Persistierung eines →Java Objektes explizit implementiert werden muss BSD Von der gleichnamigen Forschungsgruppe der Berkeley Universität verfasste Softwarelizenz für →Freie Software

Classloader Instanzen in einem →Java System, die für die Bereitstellung der Klassen zwecks Instanziierung zuständig sind CMP Persistenzmodell in →J2EE, das eine Automatisierung der Persistenz von →Java Objekten durch einen Persistenzmanager Connectors Allgemeiner oder spezieller (→JMX) Schnittstel- lenmechanismus in →Java Container Laufzeitumgebung für verteilte Objekte oder (Web)-Applikation in →J2EE CORBA Standardarchitektur der →OMG für verteilte objektorientierte Systeme CVS Freies Versionsverwaltungssystem →Java Objekt für den abstahierten Zugriff auf DataSource eine Datenbank

Debugging Finden und Eliminieren von Fehlern in Hardware und Software Deployer Dienst zur Ausführung des →Deploy-Vorgangs Deploy-Vorgang Vorgang der Installation einer Applikation auf der Verteilungsplattform Deskriptoren Konfigurationsdateien im →XML Format DTD Beschreibung der Metadaten einer →XML Datei EJBs Verteilte →Java Objekte in →J2EE →EJB Typ zur Modellierung von Entitäten und Entity Beans Objekten aus der realen Welt Entwurfsmuster Bewährte Lösungen für typische Probleme in der Softwareentwicklung Exceptions Mechanismus zur Fehlerbehandlung in →Java Factory Klasse Bestandteil eines →Entwurfsmusters zur Erzeugung von →Java Objekten Feature Requests Vorschläge für das Implementieren oder Ändern der Funktionalität einer Software seitens der Nutzer Freeware Kostenlose copyright-geschützte Software Freie Software Quelloffene Software, die ohne Einschränkungen benutzt, manipuliert und ausschließlich kostenlos weitergegeben werden darf GNU Ein im Jahr 1984 gegründetes Projekt zur Schaffung eines „freien“ Betriebssystems GPL Softwarelizenz für →Freie Softare aus dem →GNU Projekt

Hazards Abhängigkeit zwischen Prozessen, die ein gleichzeitiges Ausführen verhindern Heterogenität Verschiedenartigkeit in einem System

Home-Interface Client-seitige Schnittstelle für den Zugriff auf den Lebenszyklus von →EJBs

→Deploy-Vorgang im laufenden Betrieb Hot-Deploy HTML Beschreibungssprache für die Darstellung von Dokumenten im Web HTTP Internetprotokoll der Anwendungsschicht IIOP Protokoll für die Kommunikation zweier →ORBs

Interoperabilität Kompatibilität zwischen zwei Verteilungsplattformen J2EE Spezifikation der Firma Sun Microsystems für das Entwickeln und Betreiben von Enterprise Software in →Java J2SE Laufzeitumgebung und Entwicklertools für das Erstellen und Betreiben von →Java Programmen JAR Dateiformat zurArchivierung von →Java Klassen- und Bibliotheken Java Plattformunabhängige, interpretierte, objektorientierte Programmiersprache Jaws Persistenzmanager in →JBoss für die →EJB-Spezifikation 1.x

→EJB-→Container in →JBoss JBossServer

→Java →APIs für den Zugriff auf Datenbanken JDBC JMS System und Name der →APIs für die Realisierung von →Messaging-Systemen in →Java JMX Architektur für die Steuerung und Überwachung dienstorientierter Systeme in →Java JNDI System und Name der →APIs für den Zugriff auf Namens- und Verzeichnisdienste in →Java

→HTML Code und darin eingebeteter →Java JSP

Code für die Bearbeitung von →HTTP-Anfragen

→Java →APIs für den Zugriff auf einen Transak- JTA tionsmonitor

→Java →APIs für das Implementieren eines JTS Transaktionsmonitors Kohärenz Funktionale Abgrenzung von Programmmodulen Lizenzvereinbarung Rechtlich bindende Zusatzvereinbarung für die Nutzung einer Software Log4j Logging Framework der Apache Foundation

→Java Objekte, die innerhalb der →JMX Archi- MBeans

tektur angesprochen werden können MBeanServer Zentrale Instanz zur Steuerung und Koordination innerhalb der →JMX-Architektur MDA Modellgetriebene Anwendungsentwicklung →EJB Typ für die Bearbeitung von asynchronen Message Driven Beans Nachrichten Messaging System System für das Versenden und Empfangen von asynchronen Nachrichten MIMD-Architektur Rechnerarchitektur mit der Fähigkeit, mehrere Operationen auf mehreren Daten gleichzeitig auszuführen MVC-Konzept Paradigma, das die Aufteilung eines Systems in drei Schichten für Steuerung, Präsentation, und Datenhaltung vorsieht

→Open Source Datenbank unter der →GPL Li- MySQL zenz Offline-Migration Form der Anpassung eines Systems in zurückge- fahrenem Zustand

OMG Internationales Konsortium zur Verabschiedung von Standard betreffend objektorientierter Softwareentwicklung Open Source Synonym für →Freie Software

→Container für verteilte Objekte in →CORBA ORB OSI-Referenzmodell Theoretisches Modell einer Netzwerkkommunikation mit 7 Schichten OTS Standard der →OMG bezüglich des Verfahrens von Transaktionsdiensten Patches Softwareupdates zur Behebung von Fehlern und Sicherheitslücken Portierbarkeit Fähigkeit einer Anwendung, auf mehreren Plattformen zu laufen Proprietäre Software Kommerziell vertriebene Software, die den Anwender nur das Nutzungsrecht zugesteht Public Domain Software, die unter Allgemeingut fällt Remote-Interface Client-seitige Schnittstelle für den Zugriff auf die Funktionalität von →EJBs RMI Protokoll für den entfernten Aufruf von →Java Objekten RPC Entfernte Prozeduraufrufe über ein Kommunikationsmedium

→Java Klassen zur Bearbeitung von →HTTP- Servlets Anfragen

→EJB Typ zur Modellierung von Abläufen und Session Beans Aktionen Shareware Kostenlos verfügbare Software mit Einschränkungen SNMP Protokoll für das entfernte Warten und Managen von Softwaresystemen

SOAP Leichtgewichtiges Protokoll für den entfernte Austausch von Daten zwischen zwei Anwendungen Stubs Programmteile eines →RPC für den transparenten Zugriff Thin Client Überwiegend browser-gestützte Client-Software für die Darstellung der Präsentationslogik Tomcat Referenzimplemetierung der →Servlet/→JSP Spezifikation Transaktionssteuerung Steuerung und Koordination von zeitlich verzahnten Transaktionen, um Synchronisationsprobleme zu vermeiden Virtual Machine Laufzeitumgebung, die für das Ausführen von →Java Programmen notwendig ist (Bytecode In-

terpreter) Web Services Verteilte Dienste mit einem standardisierten Zugriffsverfahren mittels →XML und →HTTP Wrapper Klasse, die als funktionale Hülle einer anderen Klasse dient

→MBean Implementierung der →JBoss Group XMBeans XML Dateiformat für das Speichern von strukturierten Daten mit Hilfe von Tags

10.5 EIDESSTATTLICHE ERKLÄRUNG

Hiermit erkläre ich, Masroor Ahmad, geboren am 24. September 1979 in Köln, dass die vorliegende Diplomarbeit mit dem Titel

Der freie J2EE-Application-Server „JBoss“

von mir selbständig verfasst und keine Quellen, außer die im Literatur- und Webverzeichnis aufgeführten, zitiert wurden.

Fulda, den 5. Januar 2004 Masroor Ahmad

The GNU Free Documentation License

Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or

processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using publicstandard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

• A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

• B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

• C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

• D. Preserve all the copyright notices of the Document.

• E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

• F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

• G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

• H. Include an unaltered copy of this License.

• I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

• J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

• K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

• L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

• M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

• N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

• O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.