Inhaltsverzeichnis
1 Aufbau und Ziele
1.1 Theoretischer Teil
1.2 Praktischer Teil
1.3 Versionen
2 Softwarearchitektur
2.1 Anforderungen
2.2 Grundlegende Konzepte
2.3 Makro-/ Mikro- und technische Ebene
2.4 Schichtenmodell
2.4.1 Präsentationsschicht
2.4.2 Anwendungsschicht
2.4.3 Persistenzschicht
3 Verteilte Systeme
3.1 Definition
3.2 Merkmale
3.3 Kommunikations- und Koordinationsmechanismen
3.3.1 Nachrichtenaustausch
3.3.2 Remote Procedure Call (RPC)
3.3.3 Netzbetriebssysteme
3.3.4 Entfernte Datenbankzugriffe
3.3.5 Verteilte Objektsysteme
3.3.6 Web Services
3.4 Nachteile
4 Verteilungsplattformen
4.1 Definition
4.2 Grundlegende Merkmale
4.2.1 Operationale Interaktion
4.2.2 Entfernte Interaktion
4.2.3 Transparenz
4.2.4 Portabilität und Interoperabilität
4.3 Basisdienste
4.3.1 Verzeichnisdienste
4.3.2 Managementdienste
4.3.3 Persistenzdienste
4.3.4 Messagingdienste
4.3.5 Transaktionsdienste
5 J2EE als Standardarchitektur
5.1 Einführung
5.2 Architektur
5.2.1 Applet Container
5.2.2 Application Client Container
5.2.3 Web Container
5.2.4 EJB Container
5.3 Laufzeitumgebung
5.3.1 Kommunikationsprotokolle
5.3.2 Datenbankzugriff
5.3.3 Namens- und Verzeichnisdienst
5.3.4 Transaktionsmonitor
5.3.5 Messaging System
5.4 EJB-Komponentenmodell
5.3.1 Bean-Typen
5.3.2 Aufbau einer EJB
5.3.3 Weitergabe-Deskriptoren
5.3.4 EJB-Aufrufe
5.4 J2EE konforme Application Server
6 JMX Architektur
6.1 Einführung
6.2 Überblick
6.2.1 Instrumentation Level
6.2.2 Agent Level
6.2.3 Distributed Services Level
6.3 Architekturelemente
6.3.1 MBean Server
6.3.2 MBeans
6.3.3 JBoss XMBeans
6.3.4 Protokoll Adapter und Connectors
7 JBoss –Installation und Konfiguration
7.1 Überblick
7.2 Einrichten der umgebung
7.2.1 Java Developement Kit
7.2.2 JBoss Application Server
7.2.3 MySQL
7.2.4 Jakarta Tomcat
7.3 Verzeichnisstruktur
7.3.1 /bin
7.3.2 /client
7.3.3 /docs
7.3.4 /lib
7.3.5 /server
7.3.6 /server/../conf
7.3.7 /server/../data
7.3.8 /server/../deploy
7.3.9 /server/../lib
7.3.10 /server/../log, /server/../temp und /server/../work
7.4 Konfigurationsdateien
7.4.1 jboss-service.xml
7.4.2 *-service.xml
7.4.3 standardjaws.xml
7.4.4 standardjboss.xml
7.5 Startvorgang
8 JBoss – Administration und Deployment
8.1 Managementdienste
8.1.1 JBoss Management Console
8.1.2 Administration Console
8.2 Deployment am Beispiel
8.2.1 jboss.xml
8.2.2 jaws.xml
8.2.3 Kompilieren, Packen und Deployen
8.2.4 Testlauf
9 Freie Software
9.1 Definition
9.2 Abgrenzung
9.2.1 Open Source
9.2.2 Freeware
9.2.3 Shareware
9.2.4 Public Domain
9.3 Vorzüge Freier Software
9.3.1 Qualität des Quellcodes
9.3.2 Zukunftssicherheit
9.3.3 Kollektiver Lernprozess
9.4 Open Source in der Praxis
9.4.1 Organisation und Ablauf
9.4.2 Finanzierung
9.5 Lizenzen der Freien Software
9.5.1 GNU General Public License
9.5.2 BSD License
9.6 Open Source in Enterprise Umbegungen
10 Anhang
10.1 Literatur- und Webverzeichnis
10.1.1 Softwarearchitektur (Kapitel 2)
10.1.2 Verteilte Systeme (Kapitel 3)
10.1.3 Verteilungsplattformen (Kapitel 4)
10.1.4 J2EE als Standardarchitektur (Kapitel 5)
10.1.5 JMX Architektur (Kapitel 6)
10.1.6 JBoss – Installation und Konfiguration (Kapitel 7)
10.1.7 Freie Software (Kapitel 9)
10.2 Abbildungsverzeichnis
10.3 Abkürzungsverzeichnis
10.4 Glossar
10.5 Eidesstattliche Erklärung
Im Namen Allahs, des Gnädigen, des Barmherzigen!
Für Mama, Papa und Khola
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
1 Aufbau und Ziele
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[1]
Java 2 Platform, Enterprise Edition (J2EE) 1.2.1[2]
JBoss 3.2.2 Latest Scott Release[3]
Apache Jakarta Tomcat 4.1.27 Stable[4]
MySQL 4.0.16 Production Release[5]
2 Softwarearchitektur
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,[6] 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[7] 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.
2.2 Grundlegende Konzepte
Idealerweise sollten Softwarekomponenten zwei wesentliche Merkmale aufweisen: Eine starke Kohärenz[8] und eine lose Kopplung. Ein kohärentes Teilsystem ist funktional eindeutig abgegrenzt; hat also einen klar definierten Verantwortungsbereich. Das aus dem Smalltalk stammende MVC[9] -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[10]. 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[11].
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: MVC Konzept
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[12].
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 in dieser Leseprobe nicht enthalten
Abbildung 2.2: Drei-Schichten-Architektur
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[13] 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
3 Verteilte Systeme
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[16] 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.
Abbildung in dieser Leseprobe nicht enthalten
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 Ressourcen vorhanden sind und diese nicht durch „Hazards“ (Abhängigkeiten) beeinträchtigt werden[18], 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[19].
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 Koordinationsmechanismen
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
Abbildung in dieser Leseprobe nicht enthalten
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[20]. Die hierbei verwendeten Send-Receive-Operationen sind die elementaren Grundbausteine verteilter Software.
3.3.2 Remote Procedure Call (RPC)
Abbildung in dieser Leseprobe nicht enthalten
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.
3.3.3 Netzbetriebssysteme
Abbildung in dieser Leseprobe nicht enthalten
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[21].
3.3.4 Entfernte Datenbankzugriffe
Abbildung in dieser Leseprobe nicht enthalten
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[22] 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
Abbildung in dieser Leseprobe nicht enthalten
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[23].
3.3.6 Web Services
Abbildung in dieser Leseprobe nicht enthalten
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[24], 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 Verteilungsplattformen – Grundlegende Merkmale – Portabilität und Interoperabilität) Dienste[25] auf der Basis von HTTP[26].
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[27]. Gerade verteilte Systeme leiden aufgrund ihres integrativen Charakters an der Vielzahl von unterschiedlichen Technologien und Plattformen. Durch Verteilungsplattformen 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[28] mit der MDA[29], 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[30]. 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.
4 Verteilungsplattformen
4.1 Definition
Eine Verteilungsplattform, zu Englisch Middleware[31], 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[32]. ®Abbildung 4.1 verdeutlicht dies.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4.1: Verteilungsplattform als Mittelschicht
Eine weitere Sichtweise von Middleware ergibt sich aus dem modifiziertem OSI-Referenzmodell nach Tanenbaum:
Abbildung in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
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[33] zu nennen. Allgemein kann man auch von einem Austausch verteilter Ressourcen sprechen, wenn beispielsweise Peripherie angeschlossen ist.
4.2.3 Transparenz
Abbildung in dieser Leseprobe nicht enthalten
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[34]:
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.
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 in dieser Leseprobe nicht enthalten
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[35] 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 Kommunikationsprotokolle, um die Kompatibilität zu Produkten anderer Hersteller zu gewähren. Eines davon ist das RMI[36] oder das relativ neue SOAP[37].
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 in dieser Leseprobe nicht enthalten
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.
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[38] und dem Deploy-Vorgang[39] über die Arme greifen.
4.3.3 Persistenzdienste
Abbildung in dieser Leseprobe nicht enthalten
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 Persistenz-Manager auf das relationale Datenmodell überführt[40], 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 in dieser Leseprobe nicht enthalten
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 server-seitigen 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[41].
4.3.5 Transaktionsdienste
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4.10: Transaktionsdienst
Die Transaktionssteuerung hat die Aufgabe, eine gewisse Fehlertoleranz bei der zeitlich verzahnten Ausführung von Transaktionen[42] 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[43]. Verteilungsplattformen bieten dem Anwendungsentwickler solcherlei Kontrollmechanismen entweder automatisch oder explizit durch APIs.
5 J2EE als Standardarchitektur
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“[44] 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[45] 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[46].
5.2 Architektur
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5.1: J2EE Architektur[47]
Die Makroarchitektur der J2EE Spezifikation sieht im Allgemeinen vier Makro-Architektur-Komponententypen (Siehe →Kapitel 2.3 Softwarearchitektur – 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[48] 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[49] und sind daher in ihrer Funktionalität stark eingeschränkt.
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[50], 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[51], welche ungehinderten Zugriff auf alle Java APIs haben können[52]. 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 Standardarchitektur - EJB-Komponentenmodell Bezug genommen. Im Schichtenmodell entspricht der EJB-Container der Anwendungsschicht.
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 Systeme – Kommunikations- und Koordinationsmechanismen – Web Services), eine tragende Rolle.
Benötigte Bibliotheken (Java Packages):
Abbildung in dieser Leseprobe nicht enthalten
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[53] unterstützt darüber hinaus auch die Kommunikation mit CORBA[54] Objekten.
Benötigte Bibliotheken (Java Packages):
Abbildung in dieser Leseprobe nicht enthalten
IIOP (Internet InterOrb Protocol)
IIOP ist das von der OMG in CORBA definierte Protokoll für die Kommunikation zwischen zwei ORBs[55], die äquivalent zu den EJBs in einem EJB-Container, CORBA-Objekte aufnehmen.
Benötigte Bibliotheken (Java Packages):
Abbildung in dieser Leseprobe nicht enthalten
5.3.2 Datenbankzugriff
Abbildung in dieser Leseprobe nicht enthalten
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[56] API bereit, die mit Hilfe eines austauschbaren datenbankspezifischen Treibers (JDBC-Driver) den Zugriff vereinheitlicht. Persistenz-Manager (siehe →Kapitel 4.3.3 Verteilungsplattformen - Basisdienste - Persistenzdienste) nutzen in der Regel JDBC-Datenquellen als Speicherort.
Benötigte Bibliotheken (Java Packages):
Abbildung in dieser Leseprobe nicht enthalten
5.3.3 Namens- und Verzeichnisdienst
Abbildung in dieser Leseprobe nicht enthalten
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 – Verteilungsplattformen – Basisdienste - Verzeichnisdienste). Mit der JNDI[57] API verfolgt Sun Microsystems den Weg, zusammen mit existierenden Verzeichnisdiensten (LDAP[58], DNS[59], 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[60].
Benötigte Bibliotheken (Java Packages):
Abbildung in dieser Leseprobe nicht enthalten
5.3.4 Transaktionsmonitor
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5.4: Kommunikationswege bei EJB-Transaktionen
Die in →Kapitel 4.3.5 – Verteilungsplattformen – Basisdienste – Transaktionsdienste 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[61] zu implementierende Transaktionsmanager hat laut Spezifikation die Aufgabe, den an einer Transaktion beteiligten Komponenten via JTA[62] 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):
Abbildung in dieser Leseprobe nicht enthalten[63]
5.3.5 Messaging System
Abbildung in dieser Leseprobe nicht enthalten
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[64] API zugänglich macht[65]. 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):
Abbildung in dieser Leseprobe nicht enthalten
Auf eine detaillierte Beschreibung aller in der J2EE spezifizierten Punkte wird hier verzichtet, da es den Rahmen der Diplomarbeit sprengen würde.
5.4 EJB-Komponentenmodell
Die EJB-Komponenten-Architektur wird von Sun Mircosystems gesondert spezifiziert[66] 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[67].
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 demnach 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[68]:
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:
import java.rmi.*;
import javax.ejb.*;
import java.util.*;
public interface MeinObjektHome extends EJBHome
{
public MeinObjektRemote create(String eigenschaft, String PK)
throws RemoteException, CreateException;
public MeinObjektRemote findByPrimaryKey(String PK)
throws RemoteException, FinderException;
public Collection findAll()
throws RemoteException, FinderException;
public Collection findByEigenschaft(String eigenschaft)
throws RemoteException, FinderException;
}
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.
import java.rmi.*;
import javax.ejb.*;
public interface MeinObjektRemote extends EJBObject
{
public String getPK() throws RemoteException;
public String getEigenschaft() throws RemoteException;
public void setEigenschaft(String eigenschaft)
throws RemoteException;
public void setPK(String PK) throws RemoteException;
}
Die Implementierung der eigentlichen Geschäftslogik ist in der Bean-Klasse lokalisiert. Sie nimmt die Aufrufe des Remote-Interface entgegen und bearbeitet diese im EJB-Container.
import java.rmi.*;
import java.util.*;
import javax.ejb.*;
import javax.naming.*;
public class MeinObjektBean implements EntityBean
{
private EntityContext entityContext;
public String eigenschaft;
public String PK;
public String ejbCreate(String PK, String eigenschaft)
throws CreateException
{
this.setPK(PK);
this.setEigenschaft(eigenschaft);
return null;
}
public void ejbPostCreate(String eigenschaft)
throws CreateException {}
public void ejbLoad() {}
public void ejbStore() {}
public void ejbRemove() throws RemoveException {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setEntityContext(EntityContext entityContext)
{
this.entityContext = entityContext;
}
public void unsetEntityContext()
{
entityContext = null;
}
public String getEigenschaft()
{
return eigenschaft;
}
public String getPK()
{
return PK;
}
public void setEigenschaft(String eigenschaft)
{
this.eigenschaft = eigenschaft;
}
public void setPK(String PK)
{
this.PK = PK;
}
}
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[69]. 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:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
<!—- Wurzel-Element der Datei ist ejb-jar -->
<ejb-jar>
<description> Beispiel EJB-Verbund </description>
<!-- Metadaten jeder Bean im Verbund -->
<enterprise-beans>
<entity>
<ejb-name> MeinObjekt </ejb-name>
<home> MeinObjektHome </home>
<remote> MeinObjektRemote </remote>
<ejb-class> MeinObjektBean </ejb-class>
<persistence-type> Container </persistence-type>
<prim-key-class> String </prim-key-class>
<reentrant> False </reentrant>
<!-- Angaben zu persisten Datenfeldern -->
<cmp-field><field-name> eigenschaft </field-name></cmp-field>
<primkey-field> eigenschaft </primkey-field>
<!-- Im Code verwendete Umgebungsvariablen -->
<env-entry>
<env-entry-name> debug </env-entry-name>
<env-entry-type> java.lang.Boolean </env-entry-type>
<env-entry-value> true </env-entry-value>
</env-entry>
<!-- Im Code verwendete Ressourcen (hier eine Datenbank) -->
<resource-ref>
<res-ref-name> jdbc/DataSource </res-ref-name>
<res-type> javax.sql.DataSource </res-type>
<res-auth> Container </res-auth>
</resource-ref>
<!-- Im Code verwendete Referenzen zu anderen EJBs -->
<ejb-ref>
<ejb-ref-name> AnderesObjekt </ejb-ref-name>
<ejb-ref-type> Entity </ejb-ref-type>
<home> AnderesObjektHome </home>
<remote> AnderesObjektRemote </remote>
<ejb-link> AnderesObjekt </ejb-link>
<ejb-ref>
</entity>
</enterprise-beans>
<!-- Forderung nach Transaktionssicherheit -->
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name> MeinObjekt </ejb-name>
<method-name> * </method-name>
</method>
<trans-attribute> Required </trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
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[70] oder in der oben aufgeführten DTD[71].
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.
try
{
// JNDI Verzeichnisdienst initialisieren
InitialContext jndiContext = new InitialContext();
// Entferntes Objekt mittels JNDI referenzieren
Object ref = jndiContext.lookup("MeinObjekt");
// Eine Home-Interface Instanz kreieren
MeinObjektHome home = (MeinObjektHome)
PortableRemoteObject.narrow (ref, MeinObjektHome.class);
// Aus dem Home-Interface ein Remote-Interface erzeugen
MeinObjektRemote remote = home.create();
// Zugriff auf die Geschäftslogik über das Remote-Interface
remote.setEigenschaft("Test");
}
catch (Exception e)
{
e.printStackTrace();
}
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.[72]
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[73]. Infolge dieses Gleichziehens ist mit einer Verbesserung der Marktposition von JBoss in Zukunft mit hoher Wahrscheinlichkeit zu rechnen.
6 JMX Architektur
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[74].
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[75]. Die JavaBeans Komponentenarchitektur, übrigens nicht zu verwechseln mit dem Enterprise Java Beans Komponentenmodell, definiert durch eine kleine Sammlung standardisierter APIs den einheitlichen Zugriff auf Java-Objekte[76]. 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[77]:
Abbildung in dieser Leseprobe nicht enthalten
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 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[78] 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[79]. 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 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[80].
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.
// Zu importierende Bibliotheken
import javax.management.*;
// MBeanServer Instanzen
MBeanServer ersterMBeanServer;
MBeanServer zweiterMBeanServer;
// MBeanServer Instanz über das Factory Entwurfsmuster erzeugen
ersterMBeanServer = MBeanServerFactory.createMBeanServer();
// MBeanServer Instanz über JNDI holen
javax.naming.InitialContext ctx = new javax.naming.InitialContext();
zweiterMBeanServer = (MBeanServer) ctx.lookup("java:comp/MBeanServer");
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.
public interface SimpleResourceMBean
{
public String getEigenschaft();
public void setEigenschaft(String eigenschaft);
}
Die Realisierung der notwendigen Schnittstellen erfolgt in einer Klasse, die denselben Namen, ohne das Suffix „MBean“, trägt:
public class SimpleResource implements SimpleResourceMBean
{
public String getEigenschaft()
{
// Eigenschaft aus der Ressource lesen
...
return eigenschaft;
}
public void setEigenschaft(String eigenschaft)
{
// Eigenschaft der Ressource weitergeben
...
}
}
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:
// Wrapper-Klasse erzeugen
SimpleResource sr = new SimpleResource();
// Eindeutigen Objektnamen festgelegen
ObjectName objektName = new
ObjectName("MeineRessourcen:name=EineResource");
// MBean beim Server registrieren ersterMBeanServer.registerMBean(sr, objektName);
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[81]. 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[82]:
Abbildung in dieser Leseprobe nicht enthalten
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.
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[83]. 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:
Abbildung in dieser Leseprobe nicht enthalten
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.
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[84] 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:
// Eindeutigen Objektnamen festgelegen
ObjectName adapterName =
new ObjectName ("MeineRessourcen: name=htmladapter");
// HTML Adapter erzeugen und Port für die http Anfragen festlegen
com.sun.jdmk.comm.HtmlAdaptorServer adapter =
new com.sun.jdmk.comm.HtmlAdaptorServer();
adapter.setPort(8080);
// Adapter registrieren und starten
ersterMBeanServer.registerMBean(adapter, adapterName);
adapter.start();
Nach einem erfolgreichen Kompiliervorgang unter Verwendung der Referenz Implementierung von Sun sollte sich bei Eingabe der URL:
http://localhost:8080 folgendes Bild ergeben:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6.2: JMX Agent View des HTML Adapters
7 JBoss –Installation und Konfiguration
7.1 Überblick
JBoss ist ein freier[85], 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[86] 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[87] (Siehe ®Abbildung 7.1).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7.1: JMX als Datenbus in einer J2EE Umgebung[88]
Als Web Container können wahlweise Jakarta Tomcat[89] oder Jetty[90] als integriertes 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 Verteilungsplattformen – 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[91] Datenbank exemplarisch beschrieben werden; für den Webcontainer fällt die Wahl auf Tomcat, ein Produkt des Jakarta Projektes der Apache Software Foundation[92]. 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 in dieser Leseprobe nicht enthalten
Abbildung 7.2: Neues Java Logo
Die „HotSpot Virtual Machine“ von Sun Microsystems kann von der offiziellen Website bezogen werden[93]. 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:
E:\j2sdk1.4.2_02\bin> java -version
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
7.2.2 JBoss Application Server
Abbildung in dieser Leseprobe nicht enthalten
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 →Kapitel 9.4 Freie Software – Open Source in der Praxis) kann über das Java-Tool jCVS[94] 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:
Abbildung in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
Abbildung 7.5: MySQL Logo
Wenngleich die leichtgewichtige Hypersonic DB[95] 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.[96] bezogen werden. Für die Einsicht der Daten in den Tabellen kann das kostenlose MySQL-Front[97] Tool eingesetzt werden, welches auch die Verwaltung und Administrierung des laufenden MySQL Servers über eine intuitiv zu bedienende GUI ermöglicht:
Abbildung in dieser Leseprobe nicht enthalten
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, DataSource 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:
<?xml version="1.0" encoding="UTF-8"?>
<!-- =========================================================== -->
<!-- -->
<!-- JBossServer Configuration -->
<!-- -->
<!-- =========================================================== -->
<!-- $Id: mysql-ds.xml,v 1.1 2002/07/22 22:57:24 d_jencks Exp $ -->
<!-- =========================================================== -->
<!-- Datasource config for MySQL using 2.0.11 driver -->
<!-- =========================================================== -->
<datasources>
<local-tx-datasource>
<jndi-name>
db/MySqlDS
</jndi-name>
<connection-url>
jdbc:mysql://localhost:3306/jbossdb
</connection-url>
<driver-class>
org.gjt.mm.mysql.Driver
</driver-class>
<user-name> user </user-name>
<password> secret </password>
</local-tx-datasource>
</datasources>
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:
Abbildung in dieser Leseprobe nicht enthalten
7.2.4 Jakarta Tomcat
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7.7: Tomcat Logo
Als Referenzimplementierung[98] 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:
...
<!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 80 -->
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="80" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="100" debug="0" connectionTimeout="20000"
useURIValidationHack="false"
disableUploadTimeout="true" />
...
Um Konflikte mit dem MBeanServer von JBoss zu vermeiden, sollte die JMX-Unterstützung von Tomcat deaktiviert werden:
<!-- Uncomment these entries to enable JMX MBeans support -->
< ! --Listener className=
"org.apache.catalina.mbeans.ServerLifecycleListener"
debug="0"/-->
< ! --Listener className=
"org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
debug="0"/-->
...
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:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
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 in dieser Leseprobe nicht enthalten
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 regelmäß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[99]. 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 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 MBeanServers, 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:
...
<mbean code="org.jboss.invocation.pooled.server.PooledInvoker"
name="jboss:service=invoker,type=pooled">
<attribute name="MaxPoolSize"> 300 </attribute>
<attribute name="ClientMaxPoolSize"> 300 </attribute>
<attribute name="SocketTimeout"> 60000 </attribute>
...
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:
...
<mbean code="org.jboss.deployment.scanner.URLDeploymentScanner"
name="jboss.deployment:type=DeploymentScanner,flavor=URL">
<depends optional-attribute-name="Deployer">
jboss.system:service=MainDeployer
</depends>
<attribute name="URLComparator">
org.jboss.deployment.DeploymentSorter </attribute>
<attribute name="Filter">
org.jboss.deployment.scanner.DeploymentFilter< /attribute>
<attribute name="ScanPeriod"> 5000 </attribute>
<attribute name="URLs"> deploy/ </attribute>
</mbean>
...
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 abstrahierte 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:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<!--$Id:mail-service.xml,v 1.4 2002/06/01 02:06:46 starksm Exp $ -->
<server>
<classpath codebase="lib"
archives="mail.jar, activation.jar, mail-plugin.jar"/>
<!-- ========================================================= -->
<!-- Mail Connection Factory -->
<!-- ========================================================= -->
<mbean code="org.jboss.mail.MailService"
name="jboss:service=Mail">
<attribute name="JNDIName"> java:/Mail </attribute>
<attribute name="User"> nobody </attribute>
<attribute name="Password"> password </attribute>
<attribute name="Configuration">
<configuration>
<property name="mail.store.protocol" value="pop3"/>
<property name="mail.transport.protocol" value="smtp"/>
<property name="mail.user" value="nobody"/>
<property name="mail.pop3.host"
value="pop3.host.domain.com"/>
<property name="mail.smtp.host"
value="smtp.host.domain.com"/>
<property name="mail.from"
value="nobody@host.domain.com"/>
<property name="mail.debug" value="false"/>
</configuration>
</attribute>
</mbean>
</server>
Ä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 objekt-relationale Mapping (Siehe →Kapitel 4.3.3 Verteilungsplattformen - Basisdienste – Persistenzdienst) an dieser Stelle gezielt gesteuert werden. Nachfolgend ein Ausschnitt:
...
<jaws>
<datasource> java:/db/MySQlDS </datasource>
<type-mapping> mySql </type-mapping>
<debug>false</debug>
<default-entity>
<create-table>true</create-table>
<remove-table>false</remove-table>
<tuned-updates>true</tuned-updates>
<read-only>false</read-only>
<time-out>300</time-out>
<row-locking>false</row-locking>
<read-ahead>false</read-ahead>
</default-entity>
...
<type-mapping-definition>
<name> mySQL </name>
<mapping>
<java-type>java.lang.Float</java-type>
<jdbc-type>FLOAT</jdbc-type>
<sql-type>FLOAT</sql-type>
</mapping>
<mapping>
<java-type>java.lang.Boolean</java-type>
<jdbc-type>TINYINT</jdbc-type>
<sql-type>TINYINT</sql-type>
</mapping>
...
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 voreingestellte Zuordnungen für etwa ein Dutzend unterschiedlicher Datenbankprodukte. 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:
...
<container-configuration>
<container-name> Standard BMP EntityBean </container-name>
...
<container-interceptors>
<interceptor>
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor
</interceptor>
<interceptor>
org.jboss.ejb.plugins.LogInterceptor
</interceptor>
<interceptor>
org.jboss.ejb.plugins.SecurityInterceptor
</interceptor>
...
<cache-policy-conf>
<min-capacity> 50 </min-capacity>
<max-capacity> 1000000 </max-capacity>
<overager-period> 300 </overager-period>
<max-bean-age> 600 </max-bean-age>
<resizer-period>400</resizer-period>
<max-cache-miss-period>60</max-cache-miss-period>
<min-cache-miss-period>1</min-cache-miss-period>
...
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 Cache-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.
====================================================================
.
JBoss Bootstrap Environment
.
JBOSS_HOME: D:\JBOSS3.2.2\bin\\..
.
JAVA: D:\J2SDK1.4.2\bin\java
.
JAVA_OPTS: -Dprogram.name=run.bat
.
CLASSPATH: ;D:\J2SDK1.4.2\lib\tools.jar;D:\JBOSS3.2.2\bin\\run.jar
.
====================================================================
.
[Server] Starting JBoss (MX MicroKernel)...
[Server] Release ID: JBoss [WonderLand] 3.2.2 (build: CVSTag=JBoss_3_2_2 date=200311041533)
[Server] Home Dir: D:\JBOSS3.2.2
[Server] Home URL: file:/D:/JBOSS3.2.2/
[Server] Library URL: file:/D:/JBOSS3.2.2/lib/
[Server] Patch URL: null
[Server] Server Name: minimal
[Server] Server Home Dir: D:\JBOSS3.2.2\server\minimal
[Server] Server Home URL: file:/D:/JBOSS3.2.2/server/minimal/
[Server] Server Data Dir: D:\JBOSS3.2.2\server\minimal\data
[Server] Server Temp Dir: D:\JBOSS3.2.2\server\minimal\tmp
[Server] Server Config URL: file:/D:/JBOSS3.2.2/server/minimal/conf/
[Server] Server Library URL: file:/D:/JBOSS3.2.2/server/minimal/lib/
[Server] Root Deployement Filename: jboss-service.xml
[Server] Starting General Purpose Architecture (GPA)...
Ermitteln von Informationen über das Zielsystem, und der Java Virtual Machine:
[ServerInfo] Java version: 1.4.2,Sun Microsystems Inc.
[ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc.
[ServerInfo] OS-System: Windows 2000 5.0,x86
Starten und Initialisieren der Deploy-Dienste:
[ServiceController] Controller MBean online
[MainDeployer] Creating
[MainDeployer] Created
[MainDeployer] Starting
[MainDeployer] Started
[JARDeployer] Creating
[JARDeployer] Created
[JARDeployer] Starting
[MainDeployer] Adding deployer: org.jboss.deployment.JARDeployer@4e79f1
[JARDeployer] Started
[SARDeployer] Creating
[SARDeployer] Created
[SARDeployer] Starting
[MainDeployer] Adding deployer: org.jboss.deployment.SARDeployer@12d263f
[SARDeployer] Started
[Server] Core system initialized
[MainDeployer] Starting deployment of package:
file:/D:/JBOSS3.2.2/server/minimal/conf/jboss-service.xml
Installation der in der jboss-service.xml aufgeführten Basisdienste:
[Log4jService] Creating
[Log4jService$URLWatchTask] Configuring from URL: resource:log4j.xml
[Log4jService] Created
[NamingService] Creating
[NamingService] Created
[JNDIView] Creating
[JNDIView] Created
[URLDeploymentScanner] Creating
[URLDeploymentScanner] Created
[Log4jService] Starting
[Log4jService] Started
[NamingService] Starting
[AbstractDeploymentScanner$ScannerThread] Running
[NamingService] Starting jnp server
[NamingService] Started jnpPort=1099, rmiPort=0, backlog=50, bindAddress=null, Client SocketFactory=null, Server SocketFactory=null
[NamingService] Listening on port 1099
[NamingService] Started
[JNDIView] Starting
[JNDIView] Started
Installation des in →Kapitel 7.2.3 JBoss – Installation und Konfiguration – Einrichten der Umgebung – MySQL beschriebenen DataSource Objektes:
[URLDeploymentScanner] Starting
[MainDeployer] Starting deployment of package:
file:/D:/JBOSS3.2.2/server/minimal/deploy/mysql-ds.xml
[MySQLDS] Bound connection factory for resource adapter for
ConnectionManager 'jboss.jca:service=LocalTxCM,name=MySQLDS
to JNDI name 'java:/db/MySqlDS'
[TxConnectionManager] Started
[TxConnectionManager] Starting
[MainDeployer] Deployed package:
file:/D:/JBOSS3.2.2/server/minimal/deploy/mysql-ds.xml
Der in →Kapitel 7.4.2 JBoss – Installation und Konfiguration – Konfigurationsdateien - *-service.xml besprochene Maildienst:
[MainDeployer] Starting deployment of package:
file:/D:/JBOSS3.2.2/server/minimal/deploy/mail-service.xml
[MailService] Creating
[MailService] Created
[MailService] Starting
[MailService] Mail Service bound to java:/Mail
[MailService] Started
[MainDeployer] Deployed package:
file:/D:/JBOSS3.2.2/server/default/deploy/mail-service.xml
[MainDeployer] Starting deployment of package:
Der Startvorgang ist nach einer Bearbeitung eventueller benutzerdefinierter Dienste abgeschlossen.
file:/D:/JBOSS3.2.2/server/minimal/deploy/user-service.xml
[MainDeployer] Deployed package:
file:/D:/JBOSS3.2.2/server/minimal/deploy/user-service.xml
[URLDeploymentScanner] Started
[MainDeployer] Deployed package:
file:/D:/JBOSS3.2.2/server/minimal/conf/jboss-service.xml
[Server] JBoss (MX MicroKernel) [3.2.2 (build: CVSTag=JBoss_3_2_2 date=200311041533)] Started in 23s:439ms
8 JBoss – Administration und Deployment
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 – Managementdienste). Durch die 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 in dieser Leseprobe nicht enthalten
Abbildung 8.1: JBoss Management Console - JMX Agent View
Die Ansicht dieses JMX-Adapters liefert natürlich einen weitaus komplexeren 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 in dieser Leseprobe nicht enthalten
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 in dieser Leseprobe nicht enthalten
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 Standardarchitektur - EJB-Komponentenmodell als 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:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
"-//JBoss//DTD JBOSS 2.4//EN"
"http://www.jboss.org/j2ee/dtd/jboss_2_4.dtd">
<jboss>
<enterprise-beans>
<entity>
<!—- JNDI Namen der EJB umbiegen -->
<ejb-name> MeinObjekt </ejb-name>
<jndi-name> ejb/MeinObjekt </jndi-name>
<!—- Referenz zu anderen EJBs umbiegen -->
<ejb-ref>
<ejb-ref-name> AnderesObjekt </ejb-ref-name>
<jndi-name> ejb/AnderesObjekt </jndi-name>
</ejb-ref>
<!—- JNDI Namen der Ressourcen verzweigen-->
<resource-ref>
<res-ref-name> jdbc/DefaultDS </res-ref-name>
<resource-name> db/MySqlDS </jndi-name> </resource-ref></entity></enterprise-beans>
</jboss>
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 JBoss-spezifische 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:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jaws PUBLIC
"-//JBoss//DTD JAWS 2.4//EN"
"http://www.jboss.org/j2ee/dtd/jaws_2_4.dtd">
<jaws>
<!-- Angabe des Persistenzmediums -->
<datasource> java:db/MySqlDS </datasource>
<type-mapping> MySql </type-mapping>
<enterprise-beans>
<entity>
<!-- Zuordnung der Spalten in der Datenbank -->
<ejb-name> MeinObjekt </ejb-name>
<cmp-field>
<field-name> PK </field-name>
<column-name> PK </column-name>
</cmp-field>
<cmp-field>
<field-name> eigenschaft </field-name>
<column-name> EIGENSCHAFT </column-name>
</cmp-field>
<!-- Beschreibung der finder-Methoden -->
<finder>
<name> findByPK </name>
<query ><![CDATA[where PK = {0}]]> </query>
</finder>
<finder>
<name> findByEigenschaft </name>
<query ><![CDATA[where EIGENSCHAFT = {0}]]> </query>
</finder>
<finder>
<name> findByAll </name><query >< query>
</finder>
<!-- Angabe des Tabellennamens -->
<table-name> MEINEOBJEKTE </table-name>
<time-out> 10 </time-out>
</entity>
</enterprise-beans>
</jaws>
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:
jar -cvf meinobjekt.jar *.*
Manifest wurde hinzugefügt.
Hinzufügen von: MeinObjektBean.class
(ein = 1380)(aus= 588)(komprimiert 57%)
Hinzufügen von: MeinObjektHome.class
(ein = 492)(aus= 273)(komprimiert 44%)
Hinzufügen von: MeinObjektRemote.class
(ein = 352)(aus= 215)(komprimiert 3%)
Hinzufügen von: WEB-INF/
(ein = 0)(aus= 0)(gespeichert 0 %)
Hinzufügen von: WEB-INF/ejb-jar.xml
(ein = 2045) (aus= 831)(komprimiert 59%)
Hinzufügen von: WEB-INF/jaws.xml
(ein = 1348) (aus= 521)(komprimiert 61%)
Hinzufügen von: WEB-INF/jboss.xml
(ein = 778)(aus= 359)(komprimiert 53%)
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:
[MainDeployer] Starting deployment of package:
file:/D:/jboss-3.2.2/server/default/deploy/meinobjekt.jar
[EjbModule] Creating
[EjbModule] Deploying MeinObjekt
[EntityContainer] Creating
[EntityInstancePool] Creating
[EntityInstancePool] Created
[JDBCInitCommand] Table 'MEINEOBJEKTE' already exists
[EjbModule] Creating
[EjbModule] Created
[EntityContainer] Starting
[EntityInstancePool] Starting
[EntityInstancePool] Started
[EjbModule] Started
[EJBDeployer] Deployed:
file:/D:/jboss-3.2.2/server/default/deploy/meinobjekt.jar
[MainDeployer] Deployed package:
file:/D:/jboss-3.2.2/server/default/deploy/meinobjekt.jar
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:
<%@ page import ="java.util.*" %>
<%@ page import ="javax.ejb.*" %>
<%! InitialContext jndiContext; %>
<%! Object ref; %>
<%! MeinObjektHome home; %>
<%! MeinObjektRemote remote; %>
<%! Collection coll; %>
<html>
<head>MeinObjekt EJB Test</head>
<body>
<%
try
{
// JNDI Verzeichnisdienst initialisieren
jndiContext = new InitialContext();
// EJB mittels JNDI referenzieren
ref = jndiContext.lookup("ejb/MeinObjekt");
// Home-Interface
home =(MeinObjektHome)PortableRemoteObject.narrow
(ref, MeinObjektHome.class);
// EJBs erzeugen
home.create("1", "eins");
home.create("2", "zwei");
// EJBs über das Remote-Interface auslesen
coll = home.findbyAll();
out.println("Inhalt der ausgelesenen EJBs:<br>");
for (Iterator it=coll.iterator(); it.hasNext();)
{
remote = (MeinObjektRemote)it.next();
out.println(remote.getPK() + " - " + remote.getEigenschaft());
out.println("<br>");
}
}
catch (Exception e)
{
e.printStackTrace();
}
%>
</body>
</html>
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 in dieser Leseprobe nicht enthalten
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[100].
9 Freie Software
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[101]. Durch das Verfassen des GNU[102] -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 in dieser Leseprobe nicht enthalten
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[103]. Richard Stallman fasst die Motivation, aus der das GNU-Projekt heraus entstanden ist, folgendermaßen zusammen:
"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[104], 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.
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[106] 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[107].
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[108].
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[109]. 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 innerhalb 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[110]. 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 Konfigurierbarkeit proprietärer Software. Die offenen Datenaustauschformate erlauben es, ohne Restriktionen, ein jedes System an ein anderes zu koppeln und auf unternehmensspezifische Feinheiten abzustimmen[111]. 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 Berufsleben 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[112]. 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[113], 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 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[114].
Abbildung in dieser Leseprobe nicht enthalten
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[115].
9.4.2 Finanzierung
Die Geschäftsmodelle der Freien Software sind neben dem Distributionsgeschäft vor allem im Bereich der Dienstleistungen angesiedelt[116]. 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[117]. 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.
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[118]. 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.
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[119] 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[120] 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.[121] 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.
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[122]. 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.
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[123] oder das Struts Framework[124] 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[125] und OpenEJB[126] drei konkurrenzfähige Produkte, die jetzt schon am Marktanteil-Kuchen der proprietären Mitstreiter knabbern.
10 Anhang
10.1 Literatur- und Webverzeichnis
10.1.1 Softwarearchitektur (Kapitel 2)
[SunJ2SE03] Sun Microsystems, Inc.: „Java 2 Platform, Standard Edition (J2SE)“ - http://java.sun.com/j2se/ (Okt. 2003)
[SunJ2EE03] Sun Microsystems, Inc.: „Java 2 Platform, Enterprise Edition (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 Applications with the J2EE Platform, Second Edition – 4.4. Web-Tier Application Framework Design” http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html (Okt. 2003)
[DunkelHolitschke03] Dunkel, Jürgen und Holitschke, Andreas: „Softwarearchitektur in der Praxis“ - Berlin / Springer Verlag 2003
10.1.2 Verteilte Systeme (Kapitel 3)
[TanenbaumSteen03] Tanenbaum, Andrew S. van Steen, Maarten: „Verteilte Systeme – Grundlagen und Paradigmen“ – München / 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_frame.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, Enterprise Edition (J2EE) – Download & Specifications“ - http://java.sun.com/j2ee/download.html (Okt. 2003)
[SunJ2EESpec03] Sun Microsystems, Inc.: “Java 2 Platform Enterprise Edition 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 Servlet 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 Technology 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%3D139940%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/agents.html (Dez. 2003)
[Green03] Green, Dale: “Trail: The Reflection API” – The Java Tutorial - 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/download.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 politische 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/free-software-for-freedom.html (Dez. 2003)
[Gehring96] Gehring, Robert: “Freeware, Shareware und Public Domain” – Studienarbeit bei der TU Berlin - http://ig.cs.tu-berlin.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 1999 - http://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)
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 (RPC)
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
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
10.3 Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
10.4 Glossar
Abbildung in dieser Leseprobe nicht enthalten
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 public-standard 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.
[...]
[1] [SunJ2SE03]
[2] [SunJ2EE03]
[3] [JBoss03]
[4] [Jakarta03]
[5] [MySQL03]
[6] Vgl. [Bredemeyer03]
[7] Stichworte: Synchronisation und Transaktionsmanagement
[8] lat. Zusammenhang
[9] MVC = Model View Controller
[10] Vgl. [SUNWebTier03]
[11] Vgl. [DunkelHulitschke03] S.4
[12] Vgl. [DunkelHolitschke03] S.15
[13] auch: GUI – Graphical User Interface
[14] Vgl. [TanenbaumSteen03]
[15] Vgl. [Bapat94]
[16] Klassifikation der Rechnerarchitekturen nach Michael J. Flynn.
[17] In Anlehnung an [Weber98] S.5
[18] Vgl. [Dohmann02]
[19] Vgl. [BornPartner03]
[20] Vgl. [PuderRömer01] S.11-13
[21] Weiterführende Literatur: [Kubitzky95]
[22] SQL = Structured Query Language
[23] Vgl. [PuderRömer01] S.23
[24] Extensible Markup Language
[25] Offizielle Website: [W3CWebservices03]
[26] HTTP = HyperText Transfer Protocol
[27] Stichwort: EAI – Enterprise Application Integration
[28] OMG – Object Management Group
[29] MDA – Model Driven Architecture
[30] Vgl. [Frankel03] Preface xvi
[31] Middleware: Software zwischen Betriebssystem und Anwendung
[32] Vgl. [PuderRömer01] S.23
[33] Stichwort: Synchronisation und Transaktionsmanagement
[34] Vgl. [PuderRömer01] S.10
[35] Programmierschnittstelle: API - Application Programming Interface
[36] RMI - Remote Method Invocation
[37] Vgl. [W3CSOAP03] (SOAP - Simple Object Access Protocol)
[38] Debuging: Finden und Eliminieren von Fehlern in Hardware und Software (Wikipedia.org)
[39] Deploying: Installation einer verteilten Anwendung auf eine Verteilungsplattform
[40] Stichwort: Objekt-Relationales Mapping
[41] [DennigerPeters02] S.246-248
[42] Tranaktion: eine logisch zusammengefasste Menge datenändernder Operationen
[43] Vgl. [VossenGross93] S.28-30
[44] Download unter [SunJ2EEDownload03]
[45] EJB – Enterprise Java Beans
[46] Vgl. [SUNJ2EESpec03] S.16
[47] In Anlehnung an [SUNJ2EESpec03] Figure J2EE.2-1
[48] Der Klassiker für eine umfangreiche Einführung: [EcksteinLoyWood98]
[49] Java „Sandbox“ Prinzip
[50] Häufig in diesem Kontext als „Thin Clients“ bezeichnet
[51] JSP – Java Server Pages
[52] Vgl. [HunterCrawford98] S.11
[53] RMI-IIOP - Remote Method Invocation over the Internet InterOrb Protocol
[54] CORBA - Common Object Request Broker Architecture, Standardarchitektur der OMG für verteilte Objektsysteme
[55] ORB - Object Request Broker, Container für verteilte Objekte in CORBA
[56] JDBC - Java Database Connectivity
[57] JNDI - Java Naming and Directory Interface
[58] LDAP - Lightweight Directory Access Protocol
[59] DNS - Domain Name System
[60] Bei der Erweiterung des Namensraums in einem Verzeichnisdienst spricht man von „Binding“
[61] JTS - Java Transaction Service
[62] JTA - Java Transaction API
[63] OTS - Object Transaction Service – Standard der OMG
[64] JMS = Java Messaging System
[65] Vgl. [SunJMS03]
[66] Siehe: http://java.sun.com/products/ejb
[67] Vgl. [SunEJBSpec01] S.47 - 49
[68] Bei ausschließlich lokalen Inter-Bean Aufrufen besteht zusätzlich die Option eines
LocalHomeInterface.
[69] Vgl. [SunEJBSpec01] S.487
[70] Download der Spezifikation und der Klassen: [SunEJBDownload]
[71] DTD = Data Type Definition
[72] Vgl. [LaMonica03]
[73] Vgl. [Kunert03]
[74] Vgl. [JMXWhiteP99] S. 1
[75] Vgl. [JMXFAQ03]
[76] Vgl. [SUNJavaBeans03]
[77] Vgl. [SunJMXSpec02] S.20 - 24
[78] Instanzen von sogenannten „Wrapper-Klassen“
[79] Vgl. [Hendler99]
[80] Vgl. [Green03]
[81] Vgl. [SunJMXSpec02] S.40
[82] Vgl. [SunJ2EEAPIDoc03] Interface javax.management.DynamicMBean
[83] [StarkJBoss03] S.73
[84] SNMP = Simple Network Management Protocol
[85] Siehe Kapitel 8 Freie Software
[86] [JBossGroup03]
[87] Vgl. [StarkJBoss03] S.18
[88] In Anlehnung an [StarkJBoss03] S.19
[89] [JakartaTomcat03]
[90] [Jetty03]
[91] [MySQL03]
[92] [ApacheGroup03]
[93] [SunJ2SEDownload03]
[94] Siehe [jCVS03]
[95] [HyperSonic03]
[96] [MySQL03]
[97] [MySQLFront03]
[98] Vgl. [JakartaTomcat03]
[99] [Log4jProject03]
[100] Siehe: http://www.hochges.de
[101] Vgl. [Grassmuck01] S. 217 - 219
[102] selbstbezügliche Abkürzung: GNU – GNU is not Unix!
[103] Vgl. [SnoopyMüller99] S.12 - 15
[104] Vgl. [Grassmuck01] S. 246
[105] Vgl. [GNUOpenSource03]
[106] engl. donations
[107] Siehe: http://www.adobe.de
[108] Siehe: http://www.winzip.de
[109] Vgl. [Gehring96]
[110] Vgl. [HeiseNews00]
[111] Vgl. [Grassmuck01] S.359
[112] Vgl. [Grassmuck01] S.235-236
[113] CVS - Concurrent Versions System
[114] Siehe: http://www.sourceforge.net
[115] Am Beispiel von JBoss: [SourceforgeMem03]
[116] Vgl. [Hetze99]
[117] Prominentes Beispiel: http://www.suse.de
[118] Vgl. [Urhg03]
[119] Vgl. [GNULic91]
[120] BSD - Berkeley Software Distribution
[121] Vgl. [BSDLic99]
[122] Siehe: http://www.edv-buchversand.de/borlandshop/
[123] Siehe: http://ant.apache.org/
[124] Siehe: http://jakarta.apache.org/struts/
[125] Siehe: http://jonas.objectweb.org/
Häufig gestellte Fragen
Was ist das Inhaltsverzeichnis dieses Dokuments?
Das Inhaltsverzeichnis umfasst die folgenden Themen: Aufbau und Ziele, Softwarearchitektur, Verteilte Systeme, Verteilungsplattformen, J2EE als Standardarchitektur, JMX Architektur, JBoss – Installation und Konfiguration, JBoss – Administration und Deployment, Freie Software und Anhang.
Was sind die Hauptziele von Kapitel 1, "Aufbau und Ziele"?
Kapitel 1 zielt darauf ab, den J2EE-konformen JBoss Application Server als Freie Software und Verteilungsplattform zu untersuchen. Es behandelt die theoretischen Grundlagen verteilter Systeme und bietet eine Einführung in die J2EE-Standardarchitektur und den JMX-Management-Ansatz.
Was sind die Hauptmerkmale von Kapitel 2, "Softwarearchitektur"?
Kapitel 2 behandelt die Anforderungen an moderne Softwarearchitekturen, grundlegende Konzepte wie Kohärenz und lose Kopplung, verschiedene Architekturebenen (Makro, Mikro, technisch) und das Schichtenmodell (Präsentations-, Anwendungs-, Persistenzschicht).
Was sind die Schlüsselmerkmale verteilter Systeme, die in Kapitel 3 behandelt werden?
Kapitel 3 definiert verteilte Systeme, beschreibt ihre Merkmale (Autonomie, Dezentralisierung, Redundanz, Skalierbarkeit) und erläutert Kommunikations- und Koordinationsmechanismen (Nachrichtenaustausch, RPC, Netzbetriebssysteme, Datenbankzugriffe, verteilte Objektsysteme, Web Services) sowie Nachteile.
Was sind die grundlegenden Merkmale von Verteilungsplattformen (Middleware) gemäß Kapitel 4?
Kapitel 4 definiert Verteilungsplattformen, beschreibt ihre grundlegenden Merkmale (operationale Interaktion, entfernte Interaktion, Transparenz, Portabilität, Interoperabilität) und erläutert Basisdienste (Verzeichnis-, Management-, Persistenz-, Messaging-, Transaktionsdienste).
Was ist J2EE als Standardarchitektur (Kapitel 5)?
Kapitel 5 stellt J2EE als Standardarchitektur für verteilte Java-Anwendungen vor, beschreibt die Architektur (Applet-, Application Client-, Web-, EJB-Container), die Laufzeitumgebung (Kommunikationsprotokolle, Datenbankzugriff, Namensdienste, Transaktionsmonitore, Messaging-Systeme) und das EJB-Komponentenmodell.
Was ist die JMX Architektur (Kapitel 6)?
Kapitel 6 gibt einen Überblick über die JMX-Architektur (Java Management Extensions) zur Steuerung und Überwachung verteilter Systeme, einschließlich Instrumentation Level, Agent Level, Distributed Services Level und Architekturelemente wie MBean Server, MBeans, JBoss XMBeans und Protokolladapter/Connectors.
Wie installiert und konfiguriert man JBoss gemäß Kapitel 7?
Kapitel 7 führt durch die Installation und Konfiguration von JBoss, einschließlich der Einrichtung der Umgebung (JDK, JBoss, MySQL, Tomcat), der Verzeichnisstruktur und der Konfigurationsdateien (jboss-service.xml, *-service.xml, standardjaws.xml, standardjboss.xml) sowie des Startvorgangs.
Wie administriert und deployt man Anwendungen in JBoss (Kapitel 8)?
Kapitel 8 behandelt die Administration und das Deployment in JBoss, einschließlich Managementdienste (JBoss Management Console, Administration Console) und ein Beispiel-Deployment (jboss.xml, jaws.xml, Kompilieren/Packen/Deployen, Testlauf).
Was ist Freie Software (Kapitel 9)?
Kapitel 9 definiert Freie Software, grenzt sie von Open Source, Freeware, Shareware und Public Domain ab, beschreibt die Vorzüge Freier Software (Qualität, Zukunftssicherheit, kollektiver Lernprozess), die Organisation und Finanzierung von Open Source-Projekten und Lizenzen (GNU GPL, BSD License) sowie den Einsatz von Open Source in Enterprise-Umgebungen.
Welche Literatur und Webverzeichnisse werden im Anhang (Kapitel 10) genannt?
Kapitel 10 enthält ein Literatur- und Webverzeichnis, ein Abbildungsverzeichnis, ein Abkürzungsverzeichnis, ein Glossar und eine Eidesstattliche Erklärung. Die Literatur bezieht sich auf die einzelnen Kapitel des Dokuments.
- Quote paper
- Masroor Ahmad (Author), 2004, Der freie J2EE Application Server JBoss, Munich, GRIN Verlag, https://www.grin.com/document/108677
