Inhaltsverzeichnis
Werbung
Leistungsanalyse_JBOSS Name der Autoren: Lars Brügger, Christian Klein, Alexander Wieland Titel der Arbeit: ?Leistungsanalyse JBoss? Hochschule und Studienort: FOM Essen Inhaltsverzeichnis • 1 Abkürzungsverzeichnis • 2 Abbildungsverzeichnis • 3 Tabellenverzeichnis • 4 Einleitung • 5 Grundlagen ♦ 5.1 Application Server ♦ 5.2 Java Enterprise Edition ♦ 5.3 JBoss Application Server ◊ 5.3.1 Geschichte ◊ 5.3.2 Zielgruppen ⋅ 5.3.2.1 JBoss Community Version ⋅ 5.3.2.2 JBoss Enterprise Version ◊ 5.3.3 Marktanteile ◊ 5.3.4 Lizenzierung • 6 Leistungsanalyse ♦ 6.1 Systemanforderungen ♦ 6.2 Java EE Konformität ◊ 6.2.1 Einleitung ◊ 6.2.2 Applikationskomponenten ◊ 6.2.3 APIs ◊ 6.2.4 Web-Container ◊ 6.2.5 EJB-Container ♦ 6.3 Konfiguration und Administration ◊ 6.3.1 Einleitung ◊ 6.3.2 Dateibasiert ◊ 6.3.3 Programmbasiert ♦ 6.4 Entwicklung und Deployment ◊ 6.4.1 Einleitung ◊ 6.4.2 Architektur ◊ 6.4.3 Prozess ♦ 6.5 Performance, Skalierbarkeit und Verfügbarkeit ◊ 6.5.1 Einleitung ◊ 6.5.2 Clustering ⋅ 6.5.2.1 Session-Replikation ⋅ 6.5.2.2 JNDI Inhaltsverzeichnis 1 Leistungsanalyse_JBOSS ⋅ 6.5.2.3 Konfiguration ◊ 6.5.3 Verfügbarkeit ⋅ 6.5.3.1 Smart Stubs ⋅ 6.5.3.2 Load Balancer ♦ 6.6 Interoperabilität ◊ 6.6.1 Einleitung ◊ 6.6.2 Serviceorientierte Architekturen ◊ 6.6.3 Technologien ⋅ 6.6.3.1 Web Services ⋅ 6.6.3.2 CORBA und RMI ♦ 6.7 Sicherheit ◊ 6.7.1 Einleitung ◊ 6.7.2 JBossSX ⋅ 6.7.2.1 Authentifizierung und Autorisierung ⋅ 6.7.2.2 Verbindung / Kommunikation ♦ 6.8 Zusammenfassender Überblick • 7 Fazit • 8 Fußnoten • 9 Literatur- und Quellenverzeichnis 1 Abkürzungsverzeichnis Abkürzung AOP API AS AXIS BSH CA CORBA CPU CRM CSR DBMS DSA Bedeutung Aspect-oriented Programming Application Programming Interface Application Server Apache Extensible Interaction System Bean Shell Script Certificate Authority Common Object Request Broker Architecture Central Processing Unit Customer Relationship Management Certificate Signing Request Database Management System Digital Signature Algorithm 1 Abkürzungsverzeichnis 2 Leistungsanalyse_JBOSS EAR EIS EJB EJBoss GB GPL GUI HA-JNDI HAR HSQLDB HTML HTTP IDE IDL IIOP IP IT J2EE J2SE JAAS JACC JAF JAR JAXP JAXR JAX-RPC JAX-WS JBossSX jBPM JCP JDBC JDK JEE JEMS JMS JMX JNDI JRMP JSP JSSE JTA Enterprise Archive Enterprise Information System Enterprise Java Bean Enterprise Java Beans Open Source Software Gigabyte GNU General Public License Graphical User Interface High Availability - Java Naming And Directory Interface Hibernate Archive Hypersonic SQL Database Hypertext Markup Language Hypertext Transfer Protocol Integrated Development Environment Interface Definition Language Internet Inter-ORB Protocol Internet Protocol Information Technology Java 2 Enterprise Edition Java 2 Standard Edition Java Authentication And Authorization Service Java Authorization Contract For Containers Java Beans Activation Framework Java Archive Java API For XML Processing Java API For XML Registries Java API For XML Remote Procedure Calls Java API For XML Web Services JBoss Security Extension Java Business Process Management Java Community Process Java Database Connectivity Java Development Kit Java Enterprise Edition JBoss Enterprise Middleware Suite Java Message Service Java Management Extensions Java Naming And Directory Interface Java Remote Method Protocol Java Server Page Java Secure Socket Extension Java Transaction API 1 Abkürzungsverzeichnis 3 Leistungsanalyse_JBOSS JTS JVM LDAP LGPL MB MBean MHz MIME OMG POJO RAID RAM RAR REST RMI RMI-IIOP RPC RSA SAAJ SAN SAR SLA SOA SOAP SSL TLS UDDI UNIX URL WAR WS4EE WSDL XHTML XML XML-DTD XSD XTP Java Transaction Service Java Virtual Machine Lightweight Directory Access Protocol GNU Lesser General Public License Megabyte Managed Bean Megahertz Multipurpose Internet Mail Extensions Object Management Group Plain Old Java Object Redundant Array Of Independant Disks Random Access Memory Resource Adapter Archive Representational State Transfer Remote Method Invocation Remote Method Invocation - Internet Inter-ORB Protocol Remote Procedure Calls Verschlüsselungsverfahren benannt nach den Erfindern Rivest, Shamir and Adleman SOAP With Attachments API For Java Storage Area Network Service Archive Service Level Agreement Service-oriented Architecture Simple Object Access Protocol Secure Socket Layer Transport Layer Security Universal Description, Discovery And Integration Uniplexed Information And Computing System Uniform Resource Locator Web Application Archive Web Service 4 Enterprise Edition Web Services Description Language Extensible Hypertext Markup Language Extensible Markup Language Extensible Markup Language - Document Type Definition XML Schema Definition Extreme Transaction Processing 2 Abbildungsverzeichnis Abb.-Nr. 2 Abbildungsverzeichnis Abbildung 4 Leistungsanalyse_JBOSS 1 2 3 4 5 6 7 8 J2EE-Tiers für verschiedene Applikationen Gartner: magischer Quadrant J2EE Application Model JBoss Architektur J2EE-Interoperabilität JBossSX Sicherheit anhand des Beispiels einer Web-Anwendung Zusammenspiel zwischen JaasSecurityDomain, Truststore, Security Domain und Security Datastore 3 Tabellenverzeichnis Tabelle Nr. 1 2 3 4 5 6 7 8 9 10 11 12 13 Bezeichnung Rechte und Pflichten der JBoss-Nutzer supportete Betriebssysteme, Chipsätze und Java Virtual Machines - JBoss Certified Configurations - v4.2 zertifizierte Datenbanken und Datenbanktreiber - JBoss Certified Configurations - v4.2 benötigte J2SE 1.4 Optional Packages Ordnerstruktur ausgehend vom Basisverzeichnis Ordnerstruktur ausgehend vom Verzeichnis einer Konfiguration Auswahl an Konfigurationsdateien MBeans von zentraler Bedeutung JBoss Deployer Attribute der ClusterPartition MBean Attribute der HANamingService MBean Attribute der HASessionStateService MBean Zusammenfassender Überblick 4 Einleitung Die Spezifikation der Java Enterprise Edition (bis Version 1.4 J2EE, ab Version 1.5 JEE) und der Application Server JBoss sind zwei wichtige Themen im Bereich der Java-Enterprise-Anwendungen. So ist die Java Enterprise Edition faktisch der Standard in vielen Unternehmen, wenn es um die Entwicklung von Java Applikationen geht, die zunehmend herstellerunabhängig und damit interoperabel sein sollen. Mit der Entscheidung diese Spezifikation einzusetzen wird gleichzeitig ein Server benötigt, auf dem diese Anwendungen bereitgestellt werden können und der zudem mit der Java Enterprise Edition konform ist. Ziel der Arbeit ist es, grundlegende Informationen zum JBoss Application Server zu geben und die wesentlichen von ihm unterstützten Technologien zu erläutern. Der Kern der Arbeit ist die Durchführung einer Leistungsanalyse, in der die wichtigsten Features des Application Servers ermittelt und anschließend näher betrachten werden. Dabei werden lediglich qualitative Kriterien berücksichtigt, da die Analyse von quantitativen Kriterien zu keinem aussagekräftigen Ergebnis führte. Die erlangten Erkenntnisse werden abschließend in einem Fazit durch eine subjektive Beurteilung aufgegriffen. Der Fokus dieser Arbeit liegt auf dem vierten Release des JBoss Application Servers. Dieser basiert auf der Java Enterprise Edition Version 1.4 (J2EE). Für die Sammlung von Informationen gibt es hierzu die meiste und nach wie vor aktuelle Fachliteratur, welche zusätzlich durch die Nutzung von Internetquellen unterstützt wird. Die fünfte Version wurde erst während der Leistungsanalyse als ?stabiles? Release deklariert und folglich bei Red Hat 3 Tabellenverzeichnis 5 Leistungsanalyse_JBOSS als kommerzielle Version in die JBoss Enterprise Middleware Suite (JEMS) integriert und angeboten. Zudem war die Auswahl von geeigneter Literatur bereits abgeschlossen. Die Arbeit ist in zwei Hauptthemen eingeteilt. Zum einen sind im Kapitel Grundlagen die wichtigsten Aspekte zu den Themen Application Server, J2EE und JBoss selbst abgedeckt. Dazu gehören die allgemeine Begriffsdefinition eines Application Servers, wichtige Informationen, die zum Verständnis der J2EE-Spezifikation beitragen, ein kurzer Einblick in die Geschichte des JBoss Application Servers sowie Aussagen bezüglich der Zielgruppen, Marktanteile und Lizenzierung. Zum anderen stellt die Ausarbeitung der Leistungsanalyse den Hauptteil dar. Dabei werden keine Vergleiche zu anderen Application Servern und deren Technologien gezogen. Die Analyse beginnt mit den hardware- und softwaretechnischen Systemanforderungen, welche die Voraussetzung für den Betrieb des Application Servers bilden. Die darauf folgenden Kapitel beginnen mit einer kurzen Einführung zum jeweiligen Thema, um sich besser mit den genannten Informationen auseinandersetzen zu können. Im Kapitel Java EE Konformität sind Bezüge zu den enthaltenen Applikationskomponenten, den Application Programming Interfaces (APIs) und dem Web- bzw. EJB-Container des JBoss Application Servers hergestellt. Konfiguration und Administration sind die Stichworte zur Verwaltung des Servers, bei welcher verschiedene Möglichkeiten in dem gleichnamigen Kapitel betrachtet werden. Das darauf folgende Kapitel gibt einen Einblick in die Architektur und in den Prozess der Entwicklung und des Deployments von JBoss-spezifischen Anwendungen. Der Punkt Performance, Skalierbarkeit und Verfügbarkeit klärt Fragen zur Antwortzeit und dem Datendurchsatz eines Servers. Zusätzlich wird das Thema Clustering aufgegriffen. Das Kapitel Interoperabilität nimmt Bezug auf die benötigte Unabhängigkeit verschiedener Systeme. So wird auf eine serviceorientierte Architektur eingegangen und damit einhergehende, mit dem JBoss umsetzbare Technologien wie Web Services, CORBA und RMI erläutert. Der letzte Punkt der Analyse umfasst das Thema Sicherheit, welches den Fokus auf die im JBoss integrierte JBoss Security Extension (JBossSX) legt. Der zusammenfassende Überblick zeigt in komprimierter Form die wichtigsten Aspekte der aus der Analyse gewonnenen Informationen. Das Fazit schließt mit den Erkenntnissen aus den gewonnenen Informationen und der eigenen Bewertung zu dem JBoss Application Server und den Spezifikationen ab. 5 Grundlagen 5.1 Application Server Eine eindeutige Definition eines Application Server (deutsch: Applikationsserver, Anwendungsserver) existiert nicht. Der Begriff ist in der Geschäftspraxis stark verwässert und unterliegt einem inflationären Gebrauch.[1] Die Entstehung des Begriffs geht auf die Einführung der 3-Tier-Architektur zurück. Der Unterschied zur klassischen Client-Server-Architektur (2-Tier) besteht darin, dass eine separate Ebene für die Geschäftslogik in Form eines eigenständigen Servers eingesetzt wird. Das Ziel soll die Verwendung der Geschäftslogik unabhängig vom jeweiligen Clienttypen sein.[2] Diese separate Ebene wird auch als Business Tier, Middle Tier, Application Tier oder Server Tier bezeichnet.[3] Ein wichtiger Aspekt bei der Betrachtung eines Application Server ist die J2EE-Spezifikation der Firma Sun Microsystems. Sie ist dafür verantwortlich, dass unter einem Application Server im Allgemeinen ein Java-J2EE-Application Server verstanden wird.[4] Diese Spezifikation fordert, dass ein J2EE-konformer Application Server einen Servlet-Container, einen EJB-Container und eine Reihe unterstützender APIs besitzt. Damit scheiden reine Webserver wie Apache Tomcat oder Jetty aus, da sie lediglich einen Servlet-Container implementieren.[5] Beispiele für vollwertige Application Server sind z.B. JBoss von Redhat, Websphere von IBM, BEA Weblogic (jetzt Oracle) und Glassfish von Sun. Nähere Informationen zu dieser Thematik finden sich hier [[1] Java Enterprise Edition] und hier [[2] Java EE Konformität]. 4 Einleitung 6 Leistungsanalyse_JBOSS Die Anbieter von Application Servern bezeichnen ihre Produkte als Web Application Server, Legacy Application Server oder Enterprise Application Server. Ein Web Application Server ist auf Web-basierte Anwendungen wie z.B. Online-Shops spezialisiert und betreibt den dafür notwendigen Web-Server neben dem Application Server. Ein Legacy Application Server unterstützt keine Web-basierten Anwendungen. Stattdessen ist diese Variante für herkömmliche, transaktionsbasierte Desktop-Anwendungen konzipiert. Ein Enterprise Application Server ist eine Kombination aus Web Application Server und Legacy Application Server.[6] 5.2 Java Enterprise Edition Die Java Enterprise Edition ist ein von Sun Microsystems entwickeltes Rahmenwerk für Design, Entwicklung, Zusammenbau und Verteilung von Unternehmens-Anwendungen auf Basis von Komponenten. J2EE wurde Ende 1999 offiziell veröffentlicht.[7] Die Java Enterprise Edition ist also im Wesentlichen kein Produkt, sondern ein Satz von Spezifikationen und Technologien, die vor allem die Entwicklung von sicheren, stabilen und portablen Unternehmens-Anwendungen ermöglichen sollen. Ausgefüllt werden diese Spezifikationen durch Implementierungen verschiedener Anbieter, zwischen denen der Programmierer wählen kann. Den Kern der Spezifikation bildet dabei ein modulares, komponentenbasiertes Modell, dessen Bestandteile über standardisierte Schnittstellen (APIs) miteinander kommunizieren und zusammenarbeiten.[8] Der große Vorteil des Java Enterprise Edition Anwendungsmodells ist, dass bereits viele komplexe Themen, die mit der Entwicklung von Unternehmens-Anwendungen einhergehen - wie z.B. Transaction Management, Life-Cycle Management oder Resource Pooling ? ein fester Bestandteil der Plattform sind und automatisch den unterstützten Komponenten zur Verfügung stehen. So wird es den Entwicklern von Komponenten und Anwendungen ermöglicht, sich auf die Kernthemen wie die Entwicklung von Business Logik oder Benutzeroberflächen zu konzentrieren.[9] Die Java Enterprise Edition basiert auf einem Komponenten-Container-Modell. Vier Kern-Container liefern mit Hilfe ihrer jeweiligen APIs die spezifischen Laufzeitumgebungen, die für die verschiedenen Komponenten erforderlich sind: • Java Applications sind eigenständige Programme, die innerhalb des Application Client Containers ablaufen. • Applets sind Java Applets, die innerhalb eines Applet-Containers ablaufen. • Servlets und Java Server Pages laufen innerhalb eines Web-Containers eines Web-Servers. • Enterprise Java Beans laufen innerhalb eines EJB-Containers und stellen die Kern-Komponenten der J2EE-Spezifikation dar.[10] Die J2EE-Plattform bietet eine spezielle Unterstützung für die Applikationsentwicklung auf Basis einer 4-Tier-Architektur an. Die Komponentenmodelle orientieren sich am Vorbild dieser Architektur.[11] Die 4-Tier Architektur besteht aus den vier Schichten Client-Tier, Web-Tier, Business-Tier und EIS (Enterprise Information System)-Tier. Je nachdem ob eine Web-basierende oder eine nicht-Web-basierende Anwendung entwickelt wird, kommen alle vier bzw. nur drei der vier Schichten zum Einsatz.[12] Dies ist auch in der folgenden Abbildung zu sehen, in der die Applikation 2 eine Web-basierende und die Applikation 1 eine nicht-Web-basierende Anwendung darstellt. 5.1 Application Server 7 Leistungsanalyse_JBOSS Abbildung 1: J2EE-Tiers für verschiedene Applikationen[13] 5.3 JBoss Application Server 5.3.1 Geschichte Im März 1999 entwickelt Marc Fleury den Open-Source Application Server EJBoss (Enterprise Java Beans Open Source Software) und stellt das erste Release bereits im November zur freien Verfügung. Der Application Server unterliegt dabei nicht der GNU General Public License (GPL), sondern der Lesser GPL (LGPL) (siehe [[3] Lizenzierung]). Aufgrund eines Hinweises von Sun Microsystems, dass das Wort EJB (Enterprise Java Bean) geschützt ist, wird der Application Server in JBoss umbenannt. Die Weiterentwicklung des JBoss Application Servers wird nun in Form einer Community übernommen, an der sich auch Fleury beteiligt. Um Expertenwissen in Form von Dokumentationen, Beratungen und Schulungen anbieten zu können, wird 2001 die JBoss Group LCC gegründet. 2002 wird das Angebot erweitert und seitdem auch Unterstützung für Entwickler angeboten. Fast gleichzeitig wird der JBoss Application Server in seinem 3. Release als Hauptbestandteil in der JBoss Enterprise Middleware Suite (JEMS) angeboten.[14] Aus der JBoss Group LCC wird 2004 das Unternehmen JBoss Inc., deren Inhaber die Entwickler des Application Servers selbst sind und die durch die Venture Capital-Geber Matrix Partners, Accel Partners und Intel unterstützt werden.[15] Mit dem vierten Release des JBoss Application Servers werden nun auch gezielt Firmen angesprochen, indem Dienstleistungen zur Unterstützung bei der Produktion durch die JBoss Inc. angeboten werden.[14] In den kommenden Jahren wird die Produktpalette weiter ausgebaut, sodass die im JBoss Application Server integrierten Anwendungen, wie JBoss Cache, Hibernate, jBPM und JBoss Rules, auch außerhalb des Application Servers lauffähig sind.[14] Im Jahr 2006 wird die JBoss Inc. von Red Hat für 350 Millionen US-Dollar gekauft. Weitere 70 Millionen US-Dollar folgen, als vorher vereinbarte Ziele von JBoss erreicht werden.[16] Beide Firmen setzen dabei auf Open-Source als Softwaremodell und erwirtschaften Geld, indem sie Support- und Service-Abonnements vertreiben. Red Hat bietet die supportete und ebenso weiter gewachsene Version 5 als JBoss Enterprise 5.2 Java Enterprise Edition 8 Leistungsanalyse_JBOSS Application Platform an. Das Community Projekt des JBoss Application Servers ist seit dem 02.12.2009 in der sechsten Version (6.0.0 M1) erhältlich. Seit dieser Zeit werden die verschiedenen Releases nicht mehr als alphaoder beta-Versionen angeboten, sondern es werden bestimmte Projekte zu einem Meilenstein zusammengefasst. Erst wenn dieser Meilenstein in seiner finalen Version vorliegt und getestet wurde, wird das Release zum Download freigegeben. 5.3.2 Zielgruppen Die Entscheidung, welche Version des JBoss Application Servers die Nutzer bzw. Unternehmen bevorzugen, liegt in deren Bedürfnissen und den Vorgaben, die sie zu erfüllen haben. 5.3.2.1 JBoss Community Version Die JBoss Community Version ist unter www.jboss.org herunterladbar. Benutzer sind demnach Personen, die einfache Anforderungen haben oder neue Technologien testen wollen. Sie müssen demnach die Projekte selbst integrieren, absichern, pflegen und supporten. Weiterhin werden während der Entwicklung von Applikationen auftretende Fehler und Bugs selbständig gelöst bzw. durch den Bezug von Lösungsvorschlägen aus der Community eigenständig behandelt. Diese Version enthält zusätzlich unausgereifte bzw. noch zu testende Features, für die es weder Patches noch Hot Fixes gibt. Auch nicht möglich sind Zertifizierungen auf Basis der Community Version. Ein wichtiger Vorteil dieser Version ist der breite Entwicklerkreis, der mit neuen Features und Innovationen die Weiterentwicklung des JBoss Application Servers vorantreibt.[17] 5.3.2.2 JBoss Enterprise Version Bei der Enterprise Version handelt es sich um eine von Red Hat offerierte Variante, die für Unternehmen und Entwickler geeignet ist, die geschäftskritische Anwendungen in einer Produktionsumgebung bereitstellen wollen. Der Erhalt der Software ist über ein entgeltliches Abonnement geregelt und beinhaltet eine bereits vorgefertigte Plattform, in der keine weiteren Integrationen von benötigten Projekten notwendig sind. Zusätzlich wird ein 24x7 Support angeboten, sowie Updates bzw. Patches ausgeliefert, um zum Beispiel Sicherheits-, Performance- und Stabilitätsprobleme zu beheben. Das Thema Sicherheit ist zusätzlich über den ?security response process? von Red Hat gewährleistet, in dem Ratschläge zu Sicherheitsfragen gegeben werden. Weiterhin bietet Red Hat seinen Kunden Schulungen, Zertifizierungen und Beratungen für Betriebssysteme, Hardware und Datenbanken.[17] Die Enterprise Version baut dabei auf der Community Version des JBoss Application Servers auf. Sobald die aktuelle Community Version durch Tests auf nahezu vollständige Fehlerfreiheit und Stabilität geprüft wurde, wird diese als Enterprise Version von Red Hat vertrieben. Daher wird diese Variante meist mit einer niedrigeren Versionsnummer als die aktuellste Version aus der Community angeboten. 5.3.3 Marktanteile Im November 2004 führte BZ Research, ein Tochterunternehmen der SD Times, eine Java Studie durch, bei der 757 Abonnenten der Zeitschrift teilnahmen[18]. Den Ergebnissen zufolge werden immer mehr Java-Applikationen in Produktivumgebungen genutzt. Im Gegensatz zum Vorjahr, in dem 26,9 % den JBoss als Application Server verwendeten, hat sich der Anteil in 2004 auf 34,8 % erhöht, und sich die Marktstellung zu kommerziellen Application Servern, wie zum Beispiel dem IBM Websphere, dem BEA WebLogic oder ORACLE Application Servern weiter verbessert.[19] 5.3.1 Geschichte 9 Leistungsanalyse_JBOSS Laut einer Umfrage der Webseite Javamagazin.de setzen 41 % der Teilnehmer den JBoss Application Server als Test- und Produktivplattform ein. Sieben Prozent nutzen diesen ebenfalls nur als Testplattform, weitere 39 % geben an, den JBoss Application Server überhaupt nicht zu verwenden.[20] Mit der Zeit haben sich auch weitere bekannte Größen wie Novell und Hewlett-Packard dazu entschieden, sich von ihren eigenen J2EE-Technologien zu trennen und liefern den JBoss-Code nun mit ihren Produkten aus.[21] In einer Marktuntersuchung des Unternehmens Gartner, welche im September 2009 veröffentlicht wurde, hat sich Red Hat mit dem JBoss Application Server als einzige Open-Source-Plattform neben den kommerziellen Angeboten von Microsoft, Oracle und IBM in dem Quadranten der Marktführer platziert. Marktführer sind nach Gartner diejenigen, die Verständnis von dem Markt haben und dessen Richtung beeinflussen. Weiterhin sind es jene, die einen gewissen Ruf bzw. eine gewisse Verbreitung haben und dadurch lang auf dem Markt aktiv sind.[22] Gartner ist ein Anbieter von Marktforschung und Analyse der Technologie-Industrie und teilt seinen ?magischen Quadranten? in vier Kategorien ein: • Marktführer • Herausforderer • Visionäre • Nischenbesetzer[22] Zusätzlich ist der Quadrant in die zwei Dimensionen ?Vollständigkeit der Vision?, mit den hoch gewichteten Kriterien Angebots- bzw. Produktstrategie, Innovation und Marktkenntnis, und ?Fähigkeit zur Umsetzung?, mit den hochgewichteten Kriterien Produkt/Dienstleistung und Verkaufsabwicklung/Preise, gegliedert[22]. 5.3.3 Marktanteile 10 Leistungsanalyse_JBOSS Abbildung 2: Gartner: magischer Quadrant.[23] Nach Gartner ist Red Hat mit dem JBoss Application Server der Marktführer im Open-Source-Bereich. Die Stärken seien dabei die größte installierte Basis und die größte Anzahl an Partnern, die Red Hat begleiten. Außerdem habe die JBoss-Technologie einen exzellenten Ruf und ist zusammen mit dem breiten Portfolio an Open-Source-Angeboten bestens positioniert, um mit führenden kommerziellen Anbietern mitzuhalten. Probleme sieht Gartner bei den geschäftlichen Anforderungen von Red Hat, die der JBoss-Abteilung höhere Margen und Erträge auferlegt. Dies führe teilweise zu einer Verlangsamung der Entwicklung von technischen Innovationen oder anderen Tätigkeiten. Weiterhin sieht Gartner Probleme bei dem Übergang vom etablierten, aber schmalen Application-Server-Markt zum breiter angelegten und unverzichtbaren Applikation-Infrastruktur-Markt und der damit einhergehenden Neustrukturierung der Marketing-, Vertriebs- und Geschäftsperspektive. Ebenso machen die begrenzten Investitionen in XTP, Event-Verarbeitung und Cloud-Technologien das Unternehmen möglicherweise anfälliger für die nächste Welle von Wettbewerbern.[22] 5.3.4 Lizenzierung Der Source Code des JBoss Application Servers ist unter der LGPL (der GNU Lesser General Public License) lizenziert, welche unter http://www.gnu.org/copyleft/lesser.txt eingesehen werden kann.[24] Die LGPL gehört zu den Open-Source Lizenzen und hat das Ziel, den Quelltext der Anwendung frei zugänglich zu lassen.[25] Dadurch ergeben sich die folgenden Rechte und Pflichten für Nutzer und Weiterentwickler des JBoss Application Servers: Der JBoss AS kann als Teil einer spezifischen Geschäfts-Anwendung ohne Einschränkungen verwendet werden, Querverweise zwischen JBoss und proprietären Softwareprodukten sind erlaubt.[25] JBoss Kunden, Partnern und der JBoss Gemeinde steht es frei, Kopien des JBoss AS Keine Lizenzgebühren herunterzuladen, ohne dass dadurch Lizenzgebühren entstehen.[25] Sowohl JBoss Kunden, Partner als auch End-Nutzer dürfen Kopien des JBoss AS an Weitergabe an Dritte Dritte weitergeben.[25] Für den internen Gebrauch ist es gestattet, Änderungen am JBoss AS vorzunehmen. Es Modifikation für internen entsteht keine Verpflichtung, diese Änderungen in irgendeiner Weise zu Gebrauch veröffentlichen.[25] Weitergabe von Nutzern des JBoss AS ist es gestattet, geänderte Versionen an Dritte weiterzugeben. modifizierter Software an Dieser geänderte Quelltext muss aber unter der LGPL lizenziert und für alle frei Dritte zugänglich gemacht sein.[25] Der Unterschied zwischen der herkömmlichen GPL (der GNU General Public License) Einbettung in und der LGPL, liegt darin, dass eine durch LGPL geschützte Programmbibliothek kommerzielle Produkte nicht nur von freier Software verwendet werden darf, sondern auch von kommerziellen Programmen.[26] Tabelle 1: Rechte und Pflichten der JBoss-Nutzer Nutzungsfreiheit 6 Leistungsanalyse 6.1 Systemanforderungen Die Aussagen, welche minimalen Hardwarevoraussetzungen für die Benutzung des JBoss Applikation Servers 4.2 benötigt werden, differieren sehr stark. So gelten teilweise Anforderungen von 512 MB Arbeitsspeicher, 400 MHz CPU-Taktrate und 100 MB Festplattenspeicherplatz für ein Rechnersystem als ausreichend.[27] Andere 5.3.4 Lizenzierung 11 Leistungsanalyse_JBOSS wiederum sprechen von einem Rechner mit einem 2,6 MHz Dual-Core-System und ca. 4 GB Arbeitsspeicher[28]. Dies ist auf die individuellen Anforderungen der Nutzer zurückzuführen. So sind die Bedürfnisse durch Performance- und Balancing-Tests zu überprüfen und entsprechend der eigenen Vorgaben, wie zum Beispiel der Anzahl der gleichzeitigen Benutzerzugriffe, der Anzahl der Applikationen oder deren Arbeitsspeicherbedarf, anzupassen. Reicht die Rechnerleistung eines Systems nicht aus, kann mit Hilfe eines Cluster-Betriebs Abhilfe geschaffen werden, bei dem die auf dem Application Server liegende Last durch Hinzunahme eines weiteren Application Servers geteilt werden kann (siehe [[4] Performance, Skalierbarkeit und Verfügbarkeit]).[29] Da der JBoss Application Server auf einem 32-Bit-System höchstens ca. 2 GB Hauptspeicher zuordnen kann[29], wird in den beiden o.g. Fällen die Installation auf einem 64-Bit-System bevorzugt, da damit eine bessere Speicherverwaltung genutzt werden kann. Als softwaretechnische Voraussetzung für die Benutzung des JBoss Application Servers ist eine vorhandene Installation des Java Development Kit 1.4[30]. Doch um auch die EJB3-Technologien benutzen zu können, sollte Java in der Version 1.5 installiert sein[31]. Red Hat teilt die Enterprise Version des JBoss Application Servers in eine kompatible und in eine zertifizierte Variante bzw. Konfiguration ein, für die Support angeboten wird. Diese unterscheiden sich generell in der Kombination von Betriebssystem und der Chipsatzarchitektur, sowie der verwendeten Java Virtual Machine (JVM). Bei der kompatiblen Version des JBoss 4.2 ist nur die Version der JVM vorgegeben, die einem Release 1.5.x entsprechen muss. Das Betriebssystem und der benutze Chipsatz sind nicht weiter spezifiziert.[32] Die zertifizierten Konfigurationen bestehen aus speziell geprüften und getesteten Kombinationen aus Betriebssystemen, Chipsatzarchitekturen, Java Virtual Machines und Datenbanken, die bei den meisten Kunden von Red Hat zum Einsatz kommen[32]: Betriebssystem Chipsatz Architektur Java Virtual Machine(s) Sun JDK 1.5.0_15 Red Hat Enterprise Linux v5 x86, x86_64 BEA JRockit JDK 1.5.0_08 IBM JDK 1.5.0 SR6 IBM System z IBM JDK 1.5.0 SR5 Red Hat Enterprise Linux v5 s390x (64-bit) Sun JDK 1.5.0_15 BEA JRockit JDK 1.5.0_08 Red Hat Enterprise Linux v4 x86, x86_64 IBM JDK 1.5.0 SR6 Azul JDK 1.5.0_11 IBM System z Red Hat Enterprise Linux v4 s390x (64-bit) IBM JDK 1.5.0 SR5 s390 (31-bit) Sun JDK 1.5.0_15 Microsoft Windows 2003 x86 BEA JRockit JDK 1.5.0_10 Sun JDK 1.5.0_15 Microsoft Windows 2003 x86_64 BEA JRockit JDK 1.5.0_08 Solaris 10 x86, SPARC Sun JDK 1.5.0_15 Solaris 9 SPARC Sun JDK 1.5.0_15 HP-UX i2 RISC, ia64 HP-UX JDK 1.5.0.06 Tabelle 2: supportete Betriebssysteme, Chipsätze und Java Virtual Machines - JBoss Certified Configurations v4.2[32] 6.1 Systemanforderungen 12 Leistungsanalyse_JBOSS Während des Release-Prozesses der JBoss Enterprise Application Plattform 4.2 wurden die folgenden Datenbanken und Datenbanktreiber geprüft und zertifiziert[32]: Datenbank IBM DB2 v9.1 Fixpack 3 IBM DB2 v8.2.7 Datenbanktreiber IBM DB2 Universal JDBC Driver v3.1.57 IBM DB2 Universal JDBC Driver v2.10.52 Oracle JDBC driver v10.2.0.1 Oracle 10g R2 Oracle JDBC driver v10.2.0.2 Oracle JDBC driver v10.2.0.1 Oracle 9i Oracle JDBC driver v10.2.0.2 Sybase ASE15 Sybase jConnect JDBC driver v6.0 (Build 26023) Microsoft SQL Server 2005 Microsoft SQL Server 2005 driver v1.1.1501.101 MySQL v5.0 mysql-connector-java v5.0.7 PostgreSQL v8.1 PostgreSQL v8.2 JDBC3 with SSL (build 504) Tabelle 3: zertifizierte Datenbanken und Datenbanktreiber - JBoss Certified Configurations - v4.2[32] Neben diesen Anforderungen bringt der JBoss von Haus aus bereits einen WebServer und eine Servlet-Engine (JBossWeb oder Tomcat), eine relationale Datenbank (HSQLDB - Hypersonic SQL DB) und den eigentlichen Application-Server für die EJBs mit[33]. 6.2 Java EE Konformität 6.2.1 Einleitung Wie bereits in Kapitel 5.2 beschrieben, stellt J2EE ein Rahmenwerk für die Entwicklung von Unternehmens-Anwendungen dar. Anwendungsentwickler sowie Hersteller von Java Application Servern werden dazu aufgefordert, sich an diese Standards zu halten, um die Portabilität von Anwendungen herstellerübergreifend zu gewährleisten. Das von Sun Microsystems geleitete Konsortium des Java Community Process (JCP) entwickelt zu jeder veröffentlichten Java Enterprise Edition Spezifikation auch eine aktualisierte Compatibility Test Suite. Anhand dieser Testumgebung kann ein Application Server hinsichtlich seiner J2EE Kompatibilität überprüft werden.[34] Die Compatibility Test Suite für J2EE 1.4 beinhaltete bereits über 5000 Testfälle und es werden von Spezifikation zu Spezifikation mehr. Die Testumgebung überprüft die Kompatibilität, indem sie spezielle Funktionen der Anwendung aufruft und die zurückgelieferten Ergebnisse überprüft.[35] Um sich J2EE-kompatibel nennen zu dürfen, muss ein Application Server die Kompatibilitätstests bestehen, die durch die Compatibility Test Suite ausgeführt werden. Die Test-Suites werden den Herstellern der Application Server allerdings nicht unentgeltlich überlassen, so dass Open-Source-Projekte wie JBoss offenbar lange Zeit Schwierigkeiten hatten, die nötige Summe aufzubringen.[36] Mit der J2EE 1.4 Version gewährte Sun Microsystems erstmalig auch JBoss den Zugang zu den Kompatibilitäts-Tests und bot somit den JBoss-Entwicklern die Möglichkeit ihren Application Server offiziell als J2EE-konform zertifizieren zu lassen. Dies geschah zwar nicht unentgeltlich, aber offensichtlich für JBoss zu 6.2 Java EE Konformität 13 Leistungsanalyse_JBOSS annehmbaren Konditionen.[37] In der von Sun veröffentlichten J2EE 1.4 Spezifikation werden umfangreiche Anforderungen an J2EE konforme Application Server gestellt, die in den folgenden Kapiteln bezüglich ihrer Umsetzung im JBoss 4 Server genannt werden sollen. 6.2.2 Applikationskomponenten Jeder J2EE Server muss Methoden zur Ausbringung, zur Verwaltung und zur Ausführung von J2EE konformen Applikationskomponenten zur Verfügung stellen. Diese Applikationskomponenten können bezüglich ihrer Abhängigkeit vom J2EE Server in drei Kategorien eingeteilt werden: • Komponenten, die auf dem J2EE Server ausgebracht, verwaltet und ausgeführt werden, z.B. Web-Komponenten und Enterprise Java Beans (EJBs) • Komponenten, die auf dem J2EE Server ausgebracht und verwaltet werden, jedoch auf einem Client ausgeführt werden, z.B. HTML-Seiten oder in HTML-Seiten eingebettete Applets • Komponenten, deren Ausbringung und Verwaltung nicht vollständig in der J2EE Spezifikation enthalten sind, wie z.B. eigenständige Application Clients[38] Abbildung 3: J2EE Application Model.[39] Um Web-Komponenten und EJBs zur Verfügung stellen zu können, muss jeder J2EE Server einen Web-Container (auch Servlet-Container) und einen EJB-Container zur Verfügung stellen.[40] 6.2.3 APIs Alle vier in der J2EE 1.4 Spezifikation genannten Container, also auch der Web- und der EJB-Container müssen die folgenden, zum Umfang der Java 2 Platform, Standard 6.2.1 Einleitung 14 Leistungsanalyse_JBOSS Edition, v1.4 (J2SE) gehörenden APIs implementieren[41]: • Java IDL / Interface Definition Language - ermöglicht den Aufruf von CORBA Objekten[42] • JDBC / Java Database Connectivity - zum Zugriff auf relationale Datenbanken[43] • RMI-IIOP / Remote Method Invocation - Internet Inter-ORB Protocol - ermöglicht den Zugriff auf CORBA Dienste[42] • JNDI / Java Naming and Directory Interface - für den Zugriff auf und die Bereitstellung von Namensund Verzeichnisdiensten[43] • JAXP / Java API For XML Processing - zur Bearbeitung und Transformation von XML Dokumenten[43] • JAAS / Java Authentication and Authorization Service - stellt Dienste zur Authentifizierung von Benutzern und zur Zuweisung von Rechten an diese zur Verfügung[44] Web-Container und EJB-Container müssen zusätzlich zu den bereits genannten J2SE 1.4 APIs noch die in der folgenden Tabelle ersichtlichen Java Optional Packages implementieren: Java Optional Package EJB 2.1 / Enterprise Java Beans Servlet 2.4 JSP 2.0 / Java Server Pages JMS 1.1 / Java Message Service JTA 1.0 / Java Transaction API Web-Container EJB-Container Aufgabe Abbildung von Geschäftslogik und Ja (Client API) Ja Persistenzierung der Geschäftsdaten Ja Nein Packen und Ausbringen von Web-Applikationen[45] JavaMail 1.3 JAF 1.0 / Java Beans Activation Framework Connector 1.5 / J2EE Connector Architecture Web Services Ja Nein Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja JAX-RPC 1.1 / Java API For XML Remote Ja Procedure Calls SAAJ 1.2 / SOAP with Ja Attachments API for Java JAXR 1.0 / Java API for Ja XML Registries J2EE Management 1.0 / Java 2 Platform, Enterprise Edition Management API JMX 1.2 / Java 6.2.3 APIs Erstellung dynamischer Websites[46] Austausch von asynchronen Nachrichten zwischen Anwendungen[47] Transaktionverarbeitung zwischen AS und anderen Systemen (z.B. Datenbanken)[48] Erzeugung, Versand und Empfang von E-Mails aus einer Anwendung[49] Framework zur Behandlung von Daten in verschiedenen MIME-Typen[43] Anbindung von Enterprise Informationssystemen[50] Zusammenführung mehrerer Java Technologien zur Bereitstellung von Web Services[44] Ja Bereitstellung von Client APIs zum Zugriff auf Web Services[51] Ja Manipulation von SOAP Nachrichten[51] Ja Ja Ja Ja Ja Bereitstellung von Client APIs zum Zugriff auf XML basierende Verzeichnisdienste wie z.B. UDDI[51] Bereitstellung von Schnittstellen für Management Tools z.B. zur Abfrage des Status und der ausgebrachten Anwendungen eines J2EE Servers[52] Management von J2EE Komponenten innerhalb 15 Leistungsanalyse_JBOSS Management Extensions JACC 1.0 / Java Authorization Contract Ja Ja For Containers Tabelle 4: benötigte J2SE 1.4 Optional Packages[55] des J2EE Servers[53] Auslagerung von Autorisierungsentscheidungen beim Zugriff auf EJB-Methoden und Webressourcen[54] Als J2EE 1.4 zertifizierter Applikationserver implementiert der JBoss 4 alle geforderten APIs der J2SE 1.4, sowie alle geforderten Java Optional Packages. Dadurch stehen dem Entwickler bereits umfangreiche Funktionalitäten zur Verfügung, welche nicht mehr eigens implementiert werden müssen. 6.2.4 Web-Container Der Web-Container stellt die Laufzeitumgebung für die J2EE Web-Komponenten, den Java-Servlets und den Java Server Pages zur Verfügung. Seine Infrastruktur ermöglicht das Kompilieren und Ausführen von JSPs. Eigene Web-Komponenten können implementiert werden, wenn sie mit der Java-Servlet-API ausgestattet sind. Alle Web-Komponenten werden in Paketen gebunden und eingesetzt. Neben Java-Servlets und JSPs können auch andere Klassen und Klassenbibliotheken oder statische Dokumente, wie HTML, XHTML, XML oder Grafiken repräsentiert werden.[40] Ein J2EE konformer Web-Container muss den Servlet 2.4 sowie den JavaServer Pages (JSP) 2.0 Spezifikationen entsprechen. Die Servlet 2.4 Spezifikationen betreffen das Packen und Ausbringen von Web-Applikationen sowohl als eigenständige Anwendung, als auch als Teil einer J2EE Anwendung. Des Weiteren muss der Web-Container, um verteilte Anwendungen zu ermöglichen, das Ablegen von Objekten in der javax.servlet.http.HttpSession zulassen. Dadurch ist der Austausch von Objekten mit anderen Teilnehmern gewährleistet.[45] Die Java Server Pages Technologie ermöglicht es Webentwicklern und -designern, einfach zu wartende, informationsreiche und dynamische Webseiten in bestehende Business-Anwendungen zu integrieren. Dabei werden Benutzeroberfläche und Inhaltsgenerierung voneinander getrennt.[56] Der JBoss Application Server in der Version 4 beinhaltet keine Eigenimplementierung eines Web-Containers seitens des Herstellers, sondern integriert eine bereits vorhandene Web-Containerlösung, den Tomcat 5. Dieser unterstützt die geforderten Servlet 2.4 und JSP 2.0 Spezifikationen bereits vollständig. Er wird über einen ?Deployable Service? durch das jboss-tomcat-5.0.sar-Paket im deploy Verzeichnis des JBoss zur Verfügung gestellt. Der Dienst ist einfach über die META-INF\jboss-service.xml Datei konfigurierbar[57] und wird beim Start des JBoss Server vom JMX Mikrokernel (siehe Kapitel 6.3) als MBean nachgeladen.[58] Durch den modularen Aufbau des JBoss Servers lässt sich der integrierte Tomcat Web Container mit überschaubarem Aufwand durch jeden anderen J2EE konformen Web-Container ersetzen. Es wurde die org.jboss.web.AbstractWebContainer Klasse entwickelt, um eine möglichst einfache Implementierung dieser Web-Container zu ermöglichen.[57] 6.2.5 EJB-Container Enterprise Java Bean ist die Bezeichnung für die Spezifikation der serverseitigen Komponenten-Architektur der J2EE-Plattform. Das Ziel dieser Komponenten-Architektur ist die Schaffung einer geschäftslogik-orientierten Mittelschicht.[59] Laut der EJB 2.1 Spezifikation, welche zwar nicht direkt zum Umfang der J2EE Spezifikation 6.2.4 Web-Container 16 Leistungsanalyse_JBOSS gehört, deren Erfüllung aber die Grundvoraussetzung für die Erfüllung der J2EE 1.4 Spezifikation ist[60], unterscheidet man zwischen den folgenden drei EJB-Typen, die sich im Wesentlichen durch ihre Einsatzmöglichkeiten unterscheiden[61]: • Session Beans bilden typische Abläufe oder Vorgänge der Geschäftslogik ab und führen konkrete Operationen auf den Datenbeständen aus. • Entity Beans repräsentieren eine konkrete Entität innerhalb der Geschäftslogik, wie zum Beispiel ein Kunde oder eine Rechnung, die dauerhaft z.B. in einer Datenbank gespeichert werden. Ihre Aufgabe ist es die dem Modell zugrunde liegenden Daten zu kapseln und über einfache Schnittstellen zugänglich zu machen. • Message Driven Beans dienen als Empfänger von asynchronen Nachrichten und reagieren demnach auf Ereignisse, die von Clients oder Beans ausgelöst werden. Sie modellieren ebenfalls konkrete Abläufe und Aktionen innerhalb der Geschäftslogik. Der EJB-Container stellt die Laufzeitumgebung dar, die für die Ausführung der EJB-Komponenten benötigt wird. Er implementiert alle für die Ausführung von EJB-Komponenten benötigten Funktionalitäten. Die Kommunikation zwischen dem EJB-Container und der EJB-Komponente selbst erfolgt über die in der EJB-Spezifikation definierten Schnittstellen.[62] Durch die geprüfte J2EE 1.4 Konformität des JBoss Application Servers 4 und somit auch seines EJB-Containers, ist sichergestellt, dass Applikationskomponenten, zu denen auch die Enterprise Java Beans gehören, auf allen J2EE konformen J2EE Servern lauffähig sind, so dass der Wechsel von anderen Application Servern wie WebLogic oder Websphere zum JBoss aber auch umgekehrt kein Problem darstellt. Die EJBs können einfach von einem J2EE Server zum anderen migriert werden.[63] Als ein Nachteil der EJB 2.1 Spezifikation wird häufig die für Entity Beans verfügbare Container Managed Persistence (CMP) genannt. Diese stellt Funktionalitäten zur Abspeicherung und zum Zugriff auf Entity Beans in einer Datenbank zur Verfügung, die aber häufig nicht den Ansprüchen der Entwickler gerecht werden kann. So ist es z.B. nicht möglich in Java definierte Vererbungshierarchien auf eine relationale Datenbank abzubilden. Um dennoch eine Abbildung der objektorientierten Vererbungshierarchien zu ermöglichen wird deshalb häufig auf nicht zum J2EE Standard gehörige Persistenz-Schnittstellen verwendet, wie z.B. Hibernate [64], welches im Auslieferungsumfang des JBoss Application Servers enthalten ist. Durch die Verwendung solcher J2EE fremder Schnittstellen wird allerdings die Portabilität der Anwendung beeinträchtigt. Für die Ausbringung der EJBs auf dem JBoss Server ist die EJBDeployer-MBean zuständig. Um die EJB 2.1 Konformität der bereitgestellten EJB-Komponenten zu gewährleisten, bietet diese MBean über das VerifyDeployment-Attribut die Möglichkeit die auszubringende EJB auf Validität zu überprüfen. Es wird überprüft, ob alle benötigten Schnittstellen implementiert wurden und die richtigen Typen für Übergabeparameter der Schnittstellen verwendet wurden. Tauchen Fehler bei der Ausbringung auf, so werden aussagekräftige Fehlermeldungen generiert, die es dem Programmierer oder Deployer erleichtern den Mangel zu beheben.[65] 6.3 Konfiguration und Administration 6.3.1 Einleitung Die Konfiguration und Administration hängt von der speziellen Architektur des JBoss Application Servers ab. Denn dieser basiert nicht auf einem monolithischen Kern, sondern auf einem Mikrokernel. Grundlage für diesen Mikrokernel ist die JMX (Java Management eXtensions) von Sun, weshalb dieser auch JMX-Mikrokernel genannt wird. Andere Bezeichnungen für den Kern sind z.B. WebOS oder JBoss server spine. Die Funktionalitäten der J2EE-Plattform wie persistence, transactions, security, naming, messaging, logging usw. setzen als Dienste auf diesem Mikrokernel auf. Im Kontext von JMX heißen diese Dienste MBeans. Durch die 6.2.5 EJB-Container 17 Leistungsanalyse_JBOSS Modularität besteht die Möglichkeit, nicht benötigte MBeans wegzulassen oder eigene MBeans zu integrieren.[66] Abbildung 4: JBoss Architektur[67] Für die Konfiguration und Administration sind drei Verfahren von Bedeutung. Erstens das Editieren von verschiedenen XML-Dateien, den so genannten Deskriptoren. Zweitens die Arbeit mit der JMX-Console, sowie der JBoss Web-Console, die beide per Web-Oberfläche erreichbar sind. Drittens die Arbeit mit dem Programm Twiddle per Kommandozeile. Dabei gilt zu beachten, dass alle Änderungen über die Variante zwei und drei bei einem Neustart des Servers verloren gehen und somit nicht persistent sind.[68] 6.3.2 Dateibasiert Die zur Konfiguration relevanten XML-Dateien sind zahlreich und hängen stark davon ab, welche Dienste konfiguriert werden sollen. Zum näheren Verständnis und zur besseren Orientierung ist an dieser Stelle die Ordnerstruktur ausgehend vom JBoss Basisverzeichnis erläutert. Diese bezieht sich auf die Version 4.0.2, gilt aber prinzipiell für alle Veröffentlichungen der Version 4. Ordner bin client docs lib server server/all Inhalt Start- und Stoppskript für den JBoss Server, Skript zum Start des Programms Twiddle sowie diverse JAR-Dateien, die von den Skripten benötigt werden.[69] Java-Biblitheken (JAR-Dateien) die clientseitig für die Kommunikation mit dem JBoss Application Server notwendig sind.[70] Hier befindet sich nicht wie vermutet die JBoss Dokumentation, sondern diverse Unterordner mit Lizenzen für alle Dienste, XML-DTDs für JBoss spezifische Deskriptoren, XSDs für die J2EE Standard Deskriptoren.[71] Java-Bibliotheken (JAR-Dateien), die der JBoss Application Server zum Start verwendet. Dieser Ordner darf keine eigenen Bibliotheken enthalten.[69] Verschiedene JBoss Konfigurationen, von denen jede in einem eigenen Unterordner abgelegt ist. Der Name des Unterordners repräsentiert dabei den Namen der Konfiguration.[70] Diese Konfiguration enthält alle Funktionalitäten von JBoss. Es ist oftmals einfacher mit dieser Konfiguration zu starten und alle nicht benötigten Dienste zu entfernen, als die Default-Konfiguration um die zusätzlich benötigten Dienste zu erweitern.[72] 6.3.1 Einleitung 18 Leistungsanalyse_JBOSS Dies ist die Standardkonfiguration und gleichzeitig die am meisten verwendete. Dienste wie IIOP, JAXR oder clustering fehlen.[72] Diese Konfiguration enthält nur rudimentäre Dienste wie logging, JNDI naming services und URL deployment scanning. Sie bietet keine Unterstützung für EJBs, Web-Anwendungen, JMS server/minimal oder andere höherwertige Dienste. Sie wird verwendet, wenn wenig Speicher zur Verfügung steht oder genau kontrolliert werden soll, welche Dienste geladen werden.[72] Tabelle 5: Ordnerstruktur ausgehend vom Basisverzeichnis server/default Des Weiteren enthält jede Konfiguration identische Unterordner. Die Ordner in Klammern legt der JBoss Application Server erst dann an, wenn dieser mit entsprechender Konfiguration erstmalig gestartet wird.[73] Ordner Inhalt Dieser Ordner enthält verschiedene Konfigurationsdateien. Hier liegt z.B. die jboss-service.xml, die alle conf fixen Kerndienste für die gesamte Laufzeit des JBoss Application Servers definiert.[69] (data) Dieser Ordner steht für Dienste zur Verfügung, die ins Dateisystem schreiben.[69] Dieser Ordner wird vom Hot-Deployment Dienst überwacht.[69] Dateien oder Ordner, die in dieses deploy Verzeichnis gelegt werden, werden automatisch deployed. Das gilt z.B. für EJB-Anwendungen, WARund EAR-Dateien sowie Dienste.[74] Java-Bibliotheken, die beim Start der Konfiguration geladen werden.[74] Diese können von allen lib Diensten verwendet werden.[75] Dies ist der Standardordner, in den die log-Dateien mittels des frei verfügbaren Frameworks log4j (log) geschrieben werden.[75] (tmp) Diesen temporären Ordner verwendet JBoss, um deployte Anwendungen zu entpacken.[75] (work) Dieser Ordner beinhaltet von JBoss kompilierte JSPs, falls diese zum Einsatz kommen.[75] Tabelle 6: Ordnerstruktur ausgehend vom Verzeichnis einer Konfiguration Um den JBoss Application Server beispielsweise mit der Konfiguration minimal zu starten, ist das Startskript mit dem Attribut -c aufzurufen: run -c minimal. Ohne die Angabe eines Zusatzes startet JBoss mit der Konfiguration default. Eine eigene Konfiguration kann erstellt werden, indem z.B. eine Kopie des Ordners default auf gleicher Hierarchieebene angelegt wird. Der Name des neuen Ordners stellt den Namen der Konfiguration dar, die an das Startskript mittels run -c zu übergeben ist.[76] Das Stoppen des Servers kann auf drei unterschiedliche Arten erfolgen. Dieser Vorgang kann simultan zum run-Skript per shutdown eingeleitet werden. Weiterhin kann innerhalb des durch das run-Skript hervorgerufenen Fensters die Tastenkombination STRG+C gedrückt werden. Für die dritte Variante ist die JMX-Console zu verwenden.[77] Da die Konfiguration jedes einzelnen Dienstes umfangreich sein kann und dies zudem nicht Kern dieser Arbeit ist, sind an dieser Stelle nicht alle XML-Dateien aufgeführt. Ziel ist vielmehr die Identifikation einiger wichtiger Dateien, um sich somit einen Überblick verschaffen zu können. Die Pfade in der folgenden Tabelle beziehen sich auf das Wurzelverzeichnis einer Konfiguration. Datei(en) conf/jboss-service.xml conf/jboss-minimal.xml Funktion Legt die Kerndienste der Konfiguration fest. Stellt ein Beispiel für die Mindestimplementierung der Datei jboss-service.xml dar. Die Datei wird in dieser Form für die Konfiguration minimal verwendet. conf/jndi.properties 6.3.2 Dateibasiert 19 Leistungsanalyse_JBOSS conf/login-config.xml conf/log4j.xml conf/props/jmx-console-roles.properties, Legt die Eigenschaften für den JNDI-Dienst des JBoss Application Servers fest. Die Einstellungen greifen, wenn der InitialContext mit dem Standardkonstruktor aufgerufen wird. Dient zur Konfiguration der Sicherheit. Nähere Details finden sich hier [[5] Sicherheit]. Dient zur Konfiguration des logging Frameworks log4j von Apache. Dienen zur Konfiguration von Benutzern und Rollen, die beim Zugriff auf die JMX-Console greifen. conf/props/jmx-console-users.properties Tabelle 7: Auswahl an Konfigurationsdateien[78] 6.3.3 Programmbasiert Neben der Konfiguration auf Dateiebene stellt der JBoss Application Server die JMX-Console bzw. agent view bereit, mit der der Benutzer alle Dienste direkt zur Laufzeit konfigurieren kann. Damit lassen sich die MBeans auslesen, anzeigen und aktualisieren. Die JMX-Console ist eine Web-Oberfläche und nach dem Start des Servers unter http://localhost:8080/jmx-console/ erreichbar.[79] Voraussetzung dafür ist, dass der dafür notwendige Dienst in der Konfiguration enthalten ist. Bei der Konfiguration default ist dieser unter deploy/jmx-console.war installiert.[80] Die JMX-Console eignet sich z.B. für Entwickler, zur Steuerung des Servers ist dieses Werkzeug jedoch unzureichend. Eine Datasource (Java-Objekt für eine Datenquelle z.B. Datenbank) ist beispielsweise über vier MBeans verteilt und bietet somit keine zentrale Konfigurationsmöglichkeit. Außerdem besteht bei einigen MBeans nur lesender Zugriff. Hinzu kommt, wie bereits erwähnt, dass alle Änderungen nicht in den entsprechenden XML-Dateien nachgezogen werden und somit beim Neustart des Servers verloren gehen.[81] Für die Web-Console gilt das gleiche wie für die JMX-Console. Ist diese installiert, kann sie unter http://localhost:8080/web-console/ aufgerufen werden. Bei der Konfiguration default befindet sich die Anwendung unter management/console-mgr.sar. Die Web-Console ist eine Kombination aus Applet und HTML-Seite. Sie umfasst die gleichen Zugriffsmöglichkeiten wie die JMX-Console.[82] Sie bietet im Vergleich lediglich eine reichhaltigere Darstellungsweise.[80] Neben der oberflächengestützten Bearbeitung der Dienste via JMX-Console bzw. Web-Console, steht zusätzlich das Kommandozeilenwerkzeug Twiddle zur Verfügung. Die Bezeichnung ist in Anlehnung an das englische Wort Twiddle gewählt und steht im Kontext von JBoss für das Herumdrehen von Bits über JMX. Twiddle kommuniziert über Remote Method Invocation (RMI, Port 1099) mit dem JMX-Server. Das Skript zum Start von Twiddle liegt im Ordner bin. Unter der Angabe des Argumentes -h bzw. --help-commands zeigt das Werkzeug eine Hilfestellung an.[83] Gegenüber der JMX-Console bietet Twiddle den Vorteil, dass dessen Aufruf über ein Skript erfolgen kann. Somit lassen sich Aufgaben automatisieren. Trotzdem eignet es sich genau wie die JMX-Console nicht zur täglichen Verwaltung des Servers, da alle durchgeführten Änderungen den Neustart des Servers nicht überdauern.[84] Auch ohne komfortables Management-Werkzeug sollte das Bewusstsein dafür sensibilisiert sein, dass MBeans ein mächtiges Konzept darstellen. Die Änderung einer MBean sollte nur erfolgen, wenn die genauen Konsequenzen bekannt sind. Unachtsamkeit oder Unwissenheit können die Lauffähigkeit des Servers beeinträchtigen.[81] Die folgende Tabelle zeigt eine Aufstellung über MBeans, die von zentraler Bedeutung sind. MBean jboss:name=SystemProperties,type=Service jboss:service=JNDIView jboss.system:service=Logging,type=Log4jService 6.3.3 Programmbasiert Funktion Anzeige von System Properties. Zeigt den Inhalt des JNDI an. Konfiguration der Logging Intensität. 20 Leistungsanalyse_JBOSS jboss.system:service=ThreadPool jboss.system:type=Server jboss.system:type=ServerConfig jboss.system:type=ServerInfo Konfiguration der Thread Pool Size. Informationen zum Server, z.B. Startzeit oder Version. Informationen zum Server, z.B. Name der gestarteten Konfiguration, diverse Pfade wie Basis-, Log-, Deployverzeichnis usw. Informationen zum Server, z.B. Java-Version, Hostname, IP-Adresse des Hosts, Name und Version des Betriebssystems. Tabelle 8: MBeans von zentraler Bedeutung[85] Die Macht, die hinter dem Konzept der MBeans steht, bietet zugleich auch Angriffsmöglichkeiten. Deshalb ist eine Absicherung der gesamten JMX-Architektur zwingend erforderlich. Im Auslieferungszustand des JBoss Application Servers sind die JMX-Console, die JBoss Web-Console sowie die HTTP- und JMX-Invoker nicht abgesichert.[86] Konkret bedeutet dies z.B., dass ein Angreifer mittels modifizierter Google- oder Yahoo-Suche[87] eine nicht abgesicherte JMX-Console auffinden und im Anschluss vollen Zugriff darauf haben kann. Beispielsweise könnte er den Server herunterfahren oder schadhafte Programme über das MBean jboss.system:service=MainDeployer einschleusen.[88] 6.4 Entwicklung und Deployment 6.4.1 Einleitung Der JBoss Application Server basiert auf J2EE. Folglich kommen bezogen auf Entwicklung und Deployment grundsätzlich sämtliche in diesem Standard definierte Java-Technologien zum Einsatz. Für die Entwicklung einer Anwendung kann auf eine beliebige IDE (integrated development environment) mit Java-Unterstützung zurückgegriffen werden, wie z.B. Eclipse.[89] Weiterhin existiert das JBoss Developer Studio von RedHat, welches im Kern auch auf Eclipse basiert und zudem weitere Komponenten integriert.[90] Eine Analyse und Bewertung der Entwicklung hängt neben der verwendeten IDE auch von den zusätzlich verwendeten Hilfsprogrammen und Plugins wie z.B. Ant, JBossTools (früher JBossIDE)[91] ab, weshalb dieser Schritt entfällt. 6.4.2 Architektur Das Deployment bzw. die Bereitstellung ist ein vorgelagerter Schritt zu der Ausführung und Verwendung einer Anwendung. Zunächst muss der Application Server über eine deployte Anwendung informiert werden. Anschließend kann dieser die nötigen Änderungen veranlassen, damit diese verwendet werden kann.[92] Seit der Version 2.0 unterstützt der JBoss Application Server das so genannte Hot-Deployment sowie das Redeployment ohne Neustart des Servers für Anwendungen vom Typ EJB-JAR, WAR, und EAR. Ab Version 3.0 gilt das Hotund Redeployment für alle Dienste des Mikrokernels, sogar wenn Abhängigkeiten zwischen diesen bestehen.[93] Jede Deployment-Anfrage wird an den MainDeployer geschickt. Dieser entscheidet, ob die Anfrage an einen der registrierten SubDeployer weitergeleitet wird. Dabei kümmert sich der erste passende SubDeployer um die Abarbeitung der Anfrage. Der MainDeployer, JAR-Deployer und SAR-Deployer sind fester Bestandteil des JBoss-Kerns, alle anderen Sub-Deployer sind MBeans und melden sich beim MainDeployer an.[94] Dadurch bleibt die Deployment-Architektur modular.[95] Die folgende Tabelle zeigt einige der zur Verfügung stehenden Deployer. 6.4 Entwicklung und Deployment 21 Leistungsanalyse_JBOSS Name Dateiendung Dateityp AbstractWebDeployer *.war EARDeployer *.ear EJBDeployer *.jar JARDeployer *.jar RARDeployer *.rar SARDeployer *.sar XSLSubDeployer / HARDeployer *.har AspectDeployer *.aop ClientDeployer *.jar BeanShellSubDeployer *.bsh Tabelle 9: JBoss Deployer[96] Dateiinhalt (obligatorisch) Anmerkung Kann zusätzlich Web Application WEB-INF/web.xml WEB-INF/jboss-web.xml Archive enthalten. Kann zusätzlich Enterprise META-INF/application.xml META-INF/jboss-app.xml Archive enthalten. Kann zusätzlich Java Archive META-INF/ejb-jar.xml META-INF/jboss.xml (EJB) enthalten. Darf keinen Ordner Java Archive / namens WEB-INF (Bibliothek) enthalten. Resource META-INF/ra.xml / Adapter Archive Kann auch eine Datei mit der Endung *-service.xml META-INF/jbosssein. Dabei wird Service Archive service.xml META-INF/jbossservice.xml nicht benötigt. Kann generell für XML-Dateien verwendet XML-Datei / werden. JBoss verwendet diesen Deployer z.B. für ds.xml. Hibernate META-INF/hibernate/ Archive service.xml Kann auch eine Datei mit der Endung *-aop.xml Aspektorientierte META-INF/jboss-aop.xml sein. Dabei wird Programmierung META-INF/jbossaop.xml nicht benötigt. Java Archive Kann zusätzlich (J2EE META-INF/applicationMETA-INF/jbossclient.xml Application client.xml enthalten. Clients) Bean Shell Script / / Die Tabelle unterstreicht die Tatsache, dass JAR-Dateien rein technisch gesehen identisch zu EAR-, WAR- und SAR-Dateien sind. Lediglich die Ordner-Struktur und die vorhandenen Konfigurationsdateien unterscheiden sich.[97] JBoss unterstützt das Arbitrary Nesting bzw. Russian Doll Packaging. Das heißt, dass jeder beliebige Archivtyp in einem anderen Archivtyp geschachtelt sein kann, also z.B. eine EAR-Datei in einer EAR-Datei oder eine WAR-Datei in einer EAR-Datei.[98] 6.4.2 Architektur 22 Leistungsanalyse_JBOSS 6.4.3 Prozess Genau wie bei er Konfiguration und Administration [siehe [6]] kann das Deployment auf Dateiebene oder per Aufruf des MBean jboss.system:service=MainDeployer mittels Twiddle oder JMX-Console erfolgen. Auch hier besteht die Problematik, dass das Deployment per MBean nicht persistent ist. Das heißt, dass keinerlei Dateien oder Ordner im JBoss-Verzeichnis verändert werden und nach einem Neustart des Servers die Anwendung nicht mehr deployed ist.[95] Stattdessen empfiehlt es sich, die Anwendung manuell im Deploy-Verzeichnis der jeweiligen Konfiguration zu platzieren. Zur Laufzeit überwacht der Deployment-Scanner das Verzeichnis in periodischen Abständen und merkt, wenn eine Anwendung in dieses gelegt, eine Anwendung aus diesem gelöscht oder eine Anwendung durch eine neue Version ersetzt wird.[95] Dafür ist das MBean jboss.deployment:flavor=URL,type=DeploymentScanner verantwortlich.[99] Es besteht die Möglichkeit, entweder die Archivdatei in das Deploy-Verzeichnis zu legen oder den gesamten Inhalt des Archives im Deploy-Verzeichnis zu entpacken. Das Entpacken des Archives funktioniert mit jeder Java-Archivdatei.[98] Die erste Variante bietet den Vorteil, dass lediglich eine Datei verwendet wird. Ersetzt man jedoch eine Archivdatei durch eine neue Version, wird die alte zuerst undeployed bzw. gelöscht und die neue danach wieder deployed. In einer Produktivumgebung verlieren dadurch alle verbundenen Benutzer die Verbindung zur Anwendung, weshalb äußerste Vorsicht geboten ist.[95] Beim Deployment einer Archivdatei entpackt JBoss den Inhalt in das Verzeichnis tmp/deploy der jeweiligen Konfiguration. In diesem Verzeichnis können zwar Änderungen durchgeführt werden, die dann nicht zu einem neuen Deployment führen, allerdings werden die Änderungen auch nur für statische Web-Inhalte und JSP-Dateien übernommen und für Deployment-Deskriptoren beispielsweise nicht.[100] Das Extrahieren des kompletten Archives in das Deploy-Verzeichnis der jeweiligen Konfiguration stellt die zweite Variante dar und bietet den Vorteil, dass JBoss diesen Schritt nicht selbst mit Hilfe des Verzeichnisses tmp/deploy durchführen muss. Außerdem werden auch die Änderungen an Deployment-Deskriptoren übernommen, allerdings wird dabei die Anwendung automatisch neu deployed. Dadurch werden alle mit der Anwendung verbundenen Benutzer auch hier getrennt. Bei Änderungen an statischen Web-Inhalten und JSP-Dateien entfällt wie bei der ersten Variante das neue Deployen. Ein wesentlicher Nachteil gegenüber der ersten Variante liegt darin, dass mit einer ganzen Ordnerstruktur anstatt mit einer einzigen Archivdatei gearbeitet wird.[98] 6.5 Performance, Skalierbarkeit und Verfügbarkeit 6.5.1 Einleitung Die am häufigsten genannten Kennzahlen für Performance sind die Antwortzeit und der Durchsatz. Die Antwortzeit beschreibt, wie schnell das System auf die Anforderungen eines Benutzers reagiert. Dabei kann sie von einer Anforderung zur nächsten sehr unterschiedlich ausfallen, selbst wenn es sich um dieselbe Anforderung handelt. Daher wird meistens die durchschnittliche Antwortzeit für eine konkrete Anforderung ausgewertet und nicht die Einzelzeiten. Man unterscheidet nochmals zwischen Verarbeitungszeit und Roundtrip-Antwortzeit. Die Verarbeitungszeit ist die Zeitdauer von dem Moment, in dem das System die Anforderung erstmals empfängt, bis zu dem Moment, in dem es die Antwort zurückgibt. Die Roundtrip-Antwortzeit umfasst die Latenz, also die Zeit, die es braucht, um die Anforderung des Benutzers von dessen Eingabegerät zum System und wieder zurück zu transportieren. Daher ist die Antwortzeit immer länger als die Verarbeitungszeit und hängt in der Regel von dem Kommunikationsnetzwerk zwischen Benutzer und System ab. Der Durchsatz gibt an, wie viele Anforderungen 6.4.3 Prozess 23 Leistungsanalyse_JBOSS das System pro Zeiteinheit bewältigen kann.[101] Im Folgenden sind die Komponenten genannt, die einen Einfluss auf die Antwortzeit und den Durchsatz des Systems haben: • Hardware und Netzwerk • Betriebssystem • Java Virtual Machine • JBoss Application Server • die eigene Anwendung[102] Entsprechen Antwortzeit und Durchsatz nicht oder nicht mehr den geforderten Werten, welche meistens zu Beginn eines Projektes in so genannten Service Level Agreements (SLAs) definiert werden, so kann die Leistung eines Systems durch Skalierung verbessert werden. Dabei unterscheidet man zwischen vertikaler und horizontaler Skalierung.[101] Unter vertikaler Skalierung versteht man das Hinzufügen von Ressourcen innerhalb einer logischen Einheit, um die Kapazität zu erhöhen. Ein Beispiel könnte das Hinzufügen von CPUs zu einem existierenden Server sein oder die Erweiterung des Speicherplatzes durch das Hinzufügen von Festplatten zu einer existierenden RAID/SAN-Installation. Die horizontale Skalierung beschreibt das Hinzufügen mehrerer logischer Ressourcen-Einheiten, die dazu gebracht werden, wie eine einzige Einheit zu arbeiten. Die meisten Cluster-Lösungen, verteilten Dateisysteme und Lastverteiler dienen der horizontalen Skalierung.[103] 6.5.2 Clustering Bereits kleine bis mittlere Applikationen können einen einzelnen Application Server komplett auslasten. So kann es zu Antwortzeiten kommen, die für den Benutzer als störend wahrgenommen werden. In diesem Fall werden die Application Server meist redundant ausgelegt. Das heißt, dass nicht mehr ein einzelner Rechner die Clientanfragen bedient, sondern dass sich eine Gruppe von Application Servern die Clientanfragen teilen. Dieses Verfahren wird auch als Clustering bezeichnet. JBoss bietet diesbezüglich eine Menge an Funktionalitäten.[104] Die J2EE Spezifikation beinhaltet dabei selbst keine Standards, die das Clustern von Anwendungen betreffen. Jeder Application Server implementiert das Clustern auf seine eigene Art und Weise, und bietet dazu unterschiedliche Dienste an.[105] 6.5.2.1 Session-Replikation Der JBoss Application Server kann sowohl HTTP-Sessions als auch EJB Sessions replizieren.[106] HTTP-Sessions können repliziert werden, um den Status eines Web-Clients, der mit dem Web-Container verbunden ist, bzw. der eine aktive Session besitzt, auch an die anderen Web-Container im Cluster weiterzugeben. Bei Ausfall eines Web-Containers kann die Session auf einem anderen Web-Container fortgesetzt werden. Wird der JBoss Application Server im Clusterbetrieb verwendet, so findet automatisch die Replikation der HTTP-Sessions unter den Web-Containern statt.[107] Allerdings muss die Web-Anwendung die Session-Replikation explizit unterstützen. Dazu muss das <distributable/> Element in die WEB-INF/web.xml Datei eingetragen sein.[108] Auch alle EJB Typen, Stateless Session Beans, Stateful Session Beans sowie Entity Beans können im Clusterbetrieb des JBoss repliziert werden. Sie müssen jedoch ebenfalls explizit als replizierbar gekennzeichnet sein. Dies geschieht durch das Tag <clustered>true</clustered> im Deployment-Deskriptor jboss.xml.[109] Es ist von Projekt zu Projekt zu entscheiden, welche Sessions wirklich repliziert werden sollen und welche nicht. Natürlich könnte man 6.5.1 Einleitung 24 Leistungsanalyse_JBOSS einfach ohne Rücksicht auf Verluste alle HTTP-Sessions und alle EJB-Sessions auf allen Servern replizieren lassen. Es gilt jedoch, je mehr Sessions innerhalb eines Clusters repliziert werden müssen, desto mehr hat JBoss mit administrativen Dingen zu tun. Praxisberichte zeigen, dass die einzelnen JBoss innerhalb eines Clusters ab einer gewissen Applikationsgröße sehr intensiv miteinander kommunizieren, so dass die Performance der Gesamtapplikation drastisch sinkt.[106] 6.5.2.2 JNDI JNDI steht für Java Naming and Directory Interface. Analog zu einem Telefonbuch können beim JNDI-Dienst für jedes Objekt eine Anschrift, d.h. die Referenz des Objektes, welches sich auf einem beliebigen Rechner und in einem beliebigen Prozess befinden kann, sowie sein symbolischer Name hinterlegt sein. Die Anmeldung eines Objektes beim JNDI-Dienst wird automatisch durch den EJB-Container vorgenommen.[110] Jeder JBoss Server stellt einen eigenen lokalen JNDI-Dienst zur Verfügung, in der die lokalen EJBs registriert sind. Wird nun JBoss als Cluster eingesetzt, so ist es von Vorteil, wenn die Applikationen, die die EJBs kontaktieren, diese nicht erst auf den einzelnen Rechnern des Clusterverbunds suchen müssen.[111] Dazu wurde der HA-JNDI (High Availability JNDI) Dienst entwickelt, welcher auf jedem Cluster Knoten ausgeführt wird und diesen ermöglicht, sich mit Hilfe von JGroups gegenseitig zu erkennen und miteinander zu kommunizieren. Dieser Dienst bietet Ausfallsicherheit für an den Client gebundene Objekte, welche durch einen replizierten Cache, der innerhalb des JBoss Cache implementiert ist, ermöglicht wird. Die Ausfallsicherheit beschränkt sich allerdings lediglich auf das JNDI Lookup, die Ausfallsicherheit einer EJB selbst muss anderweitig garantiert werden. Objekte, die an den lokalen JNDI Dienst gebunden sind, werden nicht repliziert.[112] Bei einem Lookup seitens des Clients wird die Anfrage immer an einen Rechner innerhalb des Clusterverbunds gerichtet. Dort delegiert HA-JNDI die Anfrage an das normale JNDI des jeweiligen Rechners weiter. Befindet sich das gesuchte Objekt nicht auf diesem Rechner, so delegiert HA-JNDI die Anfrage an die übrigen Rechner im Clusterverbund. Auf jedem einzelnen Rechner wiederholt sich die Suche nach dem Objekt.[113] 6.5.2.3 Konfiguration Um einen JBoss Cluster zu erstellen, sollten mehrere JBoss Instanzen innerhalb eines Netzwerkes existieren. Diese werden durch die Zuweisung zu einer so genannten ?Partition? gruppiert. Innerhalb eines Netzwerkes können mehrere Cluster definiert werden, die durch einen eindeutigen Partitionsnamen identifizierbar sein müssen. Generell ist es möglich, dass ein JBoss Server Mitglied mehrerer Cluster sein kann, jedoch ist dies aufgrund der erschwerten Administration nicht empfehlenswert. Leider lässt die Version 4 des JBoss keine Unterpartitionen zu. Dies bedeutet, dass z.B. bei Einsatz von 10 JBoss Servern, jeder Server eine Replikation aller 9 weiteren Server beinhaltet. Der Abgleich untereinander führt zu enormem Performanceverlust. Es würde Sinn machen kleinere Untergruppen zu bilden, so dass nur die Mitglieder der Untergruppen sich untereinander replizieren. Alle Untergruppen zusammen würden jedoch weiterhin als eine Einheit nach außen erscheinen. Diese Funktionalität ist erst für die folgenden Versionen des JBoss vorgesehen.[107] Die Ausgangsbasis für einen JBoss Cluster ist der ?all?-Modus, in dem der JBoss Application Server gestartet werden kann. Es wird empfohlen, dass eine JBoss Instanz, die innerhalb eines Clusters agieren soll, unter Angabe des Rechnernamens bzw. der IP-Adresse gestartet wird. Der Aufruf könnte dann wie folgt aussehen: c:\j2ee\jboss\bin\run -c all --host=myhost. Werden beispielsweise zwei JBoss Instanzen im Netzwerk im ?all?-Modus gestartet, so finden diese sich automatisch, ohne dass eine weitere Konfiguration nötig ist.[114] Dies liegt an den vorhandenen Default-Werten in der Datei cluster-config.xml im Verzeichnis \server\all\deploy. In dieser Datei werden verschiedene MBeans konfiguriert, welche administrative Funktionalitäten bezüglich des Clusterns vornehmen.[115] 6.5.2.1 Session-Replikation 25 Leistungsanalyse_JBOSS Die ClusterPartition MBean spezifiziert, welchem Cluster bzw. welcher Partition eine JBoss Server Instanz beitritt. Alle Instanzen, die die gleiche ClusterPartition MBean Konfiguration haben, gehören zum selben Cluster..[107] Die folgende Tabelle zeigt die Attribute der ClusterPartition MBean:[115] Attribut PartitionName NodeAddress Funktion Gibt den eindeutigen Namen der Partition an. Dient der Bindung des Cluster-Knotens an eine IP-Adresse. Fällt ein JBoss im Clusterverbund aus, so kann dies in Erfahrung gebracht werden, indem DeadlockDetection der Wert auf True gesetzt wird. Wird der Zustand einer EJB auf einen anderen Server repliziert, so benötigt dies eine StateTransferTimeout gewisse Zeit. Dieser Parameter legt die maximale Zeit fest, die dieser Vorgang dauern darf. JBoss verwendet das Komponentenmodell JGroups, um innerhalb des Clusters zu kommunizieren. JGroups benötigt diverse Initialisierungsparameter, die innerhalb dieses PartitionConfig Attributes vorgegeben werden. So wird z.B. die Multicast-Adresse oder die Dauer eines Pings, der zum Auffinden neuer Mitglieder gesendet wird, festgelegt. Tabelle 10: Attribute der ClusterPartition MBean Die HANamingService MBean legt die Einstellungen für den HA-JNDI Dienst fest. Dieser ist immer eng mit einer Partition verbunden. Auch diese MBean wird über Attribute konfiguriert[116], von denen die wichtigsten in der folgenden Tabelle aufgelistet werden: Attribut PartitionName Funktion Gibt den eindeutigen Namen der Partition an, für die der Dienst zuständig ist.[116] Dient der Bindung des Dienstes an eine IP-Adresse, an der er auf Client-Anfragen BindAddress wartet.[116] Port Port, den ein Client verwendet, um einen JNDI-Server zu finden.[101] Nachdem der Server ermittelt wurde, verwendet der Client diesen Port, um mit dem RmiPort JNDI-Dienst zu kommunizieren und Namensauflösungen zu tätigen.[101] Legt fest, wie viele unbehandelte Namensauflösungen in der Warteschlange stehen backlog dürfen, bevor Clients die Nachricht ?connection refused? erhalten.[101] Multicast Adresse zum Versand von Namensauflösungsanfragen an andere autoDiscoveryAddress HA-JNDI-Instanzen.[116] Tabelle 11: Attribute der HANamingService MBean Mit Hilfe der HASessionStateService MBean wird der Zustandsreplikationsmechanismus spezifiziert, der die Zustände von Stateful Session Beans innerhalb des Clusters repliziert.[116] Dieser Dienst wird durch die folgenden Attribute konfiguriert.[107]: Attribut PartitionName JndiName BeanCleaningDelay Funktion Gibt den eindeutigen Namen der Partition an, für die der Dienst zuständig ist. Gibt den JNDI Namen vor, unter dem der HASessionState Dienst gebunden wird. Gibt die Zeit in Millisekunden an, nach der der HASessionState Dienst einen Status löschen kann, welcher nicht modifiziert wurde. Dies ist nötig, damit bei Ausfall eines für eine Stateful Session Bean zuständigen Servers die Bean wieder von anderen Servern verwendet 6.5.2.3 Konfiguration 26 Leistungsanalyse_JBOSS werden kann. Tabelle 12: Attribute der HASessionStateService MBean 6.5.3 Verfügbarkeit Um die Hochverfügbarkeit einer Anwendung sicherzustellen, ist zunächst einmal wichtig, über welchen Weg und auf welche Art und Weise die einzelnen Clients letztlich auf den Cluster bzw. die einzelnen Knoten zugreifen. Abhängig davon muss eine Strategie angewandt werden, die darauf reagiert, wenn ein Knoten des Clusters nicht mehr erreichbar ist.[117] 6.5.3.1 Smart Stubs Smart Stubs werden häufig auch als Proxy oder Interceptor bezeichnet. Die meisten Remote Services, die vom JBoss Application Server zur Verfügung gestellt werden, dazu gehören JNDI, EJB, RMI und JBoss Remoting, stellen dem Client ein Smart Stub Objekt zur Verfügung, welches auf den Client geladen wird.[107] Erfragt ein Client beispielsweise das Home-Interface einer EJB innerhalb eines Clusters, so sorgt das dynamische ClassLoading von RMI dafür, dass der zugehörige Smart Stub der EJB an den Client übertragen wird, sobald dieser die create-Methode des Home-Interfaces aufruft. Innerhalb dieses von JBoss generierten Smart Stubs befindet sich der notwendige Code, um die EJB innerhalb des Clusters zu finden.[114] Der Smart Stub enthält auch Informationen über das Cluster, welche bei jeder Verbindung mit einem aktiven Knoten aktualisiert werden. Dieser kennt die IP Adressen aller verfügbaren Server Knoten, den Algorithmus zur Lastenverteilung zwischen den Knoten, und er weiß, wie er bei Ausfall eines Servers zu reagieren hat.[107] 6.5.3.2 Load Balancer Wird eine Web-Applikation auf einem JBoss Cluster bereitgestellt, so können keine Smart Stubs für das Load Balancing und die Ausfallsicherheit sorgen. In diesem Fall wird ein Load Balancer benötigt, der alle Requests verarbeitet und an die entsprechenden Clusterknoten weiterleitet. Der Load Balancer ist in der Regel selbst ein Mitglied des Clusters und kennt dessen Konfiguration und Ausfallregeln. Der Client selbst kennt nur den Load Balancer und wendet sich ausschließlich an diesen.[107] Es gibt sowohl hardware- als auch softwarebasierte Load Balancer. Ein typisches Exemplar für eine softwarebasierte Lösung ist das mod_jk Modul von Apache für Tomcat, ein typisches hardwarebasiertes Pendant ist Ciscos CSS 11150.[118] 6.6 Interoperabilität 6.6.1 Einleitung In Unternehmen zielen bestimmte Systemintegrationsstrategien in Bezug auf Anwendungssysteme darauf ab, dass alte, neue und auch dazu gekaufte Anwendungen integriert werden können[119]. Dadurch erfährt die Interoperabilität heutzutage immer mehr an Bedeutung. Durch sie soll gewährleistet werden, dass in einer heterogenen Systemlandschaft Informationen herstellerübergreifend zwischen zwei oder mehreren Komponenten ausgetauscht und auch weiter verarbeitet werden können[120]. Der Austausch von Informationen muss sich dabei aber nicht nur auf firmeninterne Systeme beschränken, sondern kann auch mit entfernten Partnern über das Internet stattfinden. In Verbindung mit Softwaresystemen wird die Interoperabilität durch folgende 5 Faktoren bestimmt[121]: • Datenkompatibilität 6.5.3 Verfügbarkeit 27 Leistungsanalyse_JBOSS • Anpassungsfähigkeit der Geschäftsprozesse • Anbindung an bestehende (Legacy)-Systeme • Steuerbarkeit der Transaktionen • Sicherheit des Netzes Wie bereits in Kapitel 6.2 erwähnt, ist der JBoss Application Server 4.x mit der J2EE Version 1.4 konform und entspricht durch die Verwendung von Standards der in der Spezifikation geforderten Interoperabilität von Anwendungssystemen. Aber auch Frameworks und genormte Schnittstellen, wie zum Beispiel der Interface Definition Language (IDL) und der Extensible Markup Language (XML)[122] tragen dazu bei, dass unter J2EE entwickelte Anwendungen zueinander kompatibel sind und eine entsprechende Portabilität gegenüber anderen Betriebssystemen aufweisen. 6.6.2 Serviceorientierte Architekturen Werden Anwendungssysteme in der eigenen Firmenumgebung oder auch über diese hinweg zu einer zusammenhängenden Architektur integriert, so kommt man zu dem Ansatz einer serviceorientierten Architektur (SOA). Eine SOA ist aber nicht nur eine reine technische Architektur, sondern ist ebenfalls ein Geschäftsmodell-Konzept, ein Teil der IT-Infrastruktur und ein Programmierschema[123]. Die miteinander agierenden Systeme verwenden bestimmte Dienste (Services), um miteinander zu kommunizieren und um benötigte Daten auszutauschen. Diese Services beruhen auf vorher gekapselte Funktionen der einzelnen Systeme, die wiederum zu einem übergeordneten Service zusammengefügt werden können. 6.6.3 Technologien 6.6.1 Einleitung 28 Leistungsanalyse_JBOSS Abbildung 5: J2EE-Interoperabilität[124] In den folgenden Abschnitten werden Technologien und Standards innerhalb des JBoss Application Servers genannt, mit denen eine Unabhängigkeit zu den verwendeten Programmiersprachen und Betriebssystemen umgesetzt werden kann. 6.6.3.1 Web Services Mit Hilfe von Web Services kann eine SOA umgesetzt werden, da diese nicht an eine bestimmte Technologie gebunden und auch mit den unterschiedlichsten Entwicklungsumgebungen realisierbar ist. Aber ebenso werden Web Services in Form von Remote Procedure Calls (RPC) oder einem Representational State Transfer (REST) verwendet[125]. Ein Client bekommt so den Zugriff auf bereitgestellte Funktionen bzw. Methoden, die der Server implementieren muss. Ein Web Service ist dabei nichts anderes, als eine Sammlung von bereits schon länger existierender Standards, die miteinander genutzt werden. Dies sind in der Regel: • HTTP (Hypertext Transfer Protocol - als Übertragungsprotokoll im Internet / Intranet) • SOAP (Simple Object Access Protocol - als Kommunikationsprotokoll) • XML (Extensible Markup Language - als Dateiformat in der die übertragenen Nachrichten vorliegen) • WSDL (Web Services Description Language - als Web Service Beschreibungssprache) • UDDI (Universal Description, Discovery and Integration - als Verzeichnisdienst) 6.6.3 Technologien 29 Leistungsanalyse_JBOSS Auf eine genauere Erläuterung zu diesen Standards soll in diesem Kontext verzichtet werden. Mit Hilfe dieser Standards ist es möglich, einen Web Service, der in einer Sprache geschrieben wurde, in einer anderen zu benutzen und somit die Interoperabilität zu gewährleisten. Die Datenkompatibilität der verwendeten Sprachen wird mittels eines Wrappers erzeugt, der die erhaltenen Daten bzw. Informationen aus der XML-Datei auflöst und in die benötigte Programmiersprache ?übersetzt?. Für die Kontrolle, ob eine Web Service von einem bestimmten Client aufgerufen werden darf, können so genannte Handler eingesetzt werden, die die Zugriffsberechtigungen des Client prüfen. Die in den JBoss Application Server 4 integrierte Web Service Engine ist die Web Service Enterprise Edition (WS4EE), oder auch JBossWS genannt. Diese ist zu ca. 75 Prozent an das Open-Source-Framework AXIS angelehnt und wurde durch die Integration des in der J2EE-Spezifikation 1.4 vorgegebenen Komponentenmodells Java API for XML Remote Procedure Calls (JAX-RPC) erweitert.[126] Die Spezifikation JAX-RPC ist dabei die Schnittstelle aus der J2EE-Spezifikation, die benötigt wird, um Web Services zu erstellen. Um Web Services für den JBoss Application Server zu implementieren, werden zum Beispiel Enterprise Java Beans (EJBs) nach entsprechenden Vorgaben dazu befähigt, als Web Service zu agieren und ermöglichen dadurch die Interoperabilität zu anderen Herstellern.[126] Neben der Überführung einer EJB in einen Web Service kann auch ein Servlet zur Entwicklung eines Web Services benutzt werden. Die Programmlogik ist dann aber nicht mehr im Application Container des JBoss realisiert, sondern ist im Web Container des in den JBoss Application Server integrierten Tomcats zu finden. Auf diese Art und Weise können zum Beispiel Applikationen erstellt werden, die keine EJB-Administration implementiert haben müssen.[126] Mit der Java Enterprise Edition 5 und der Einführung des EJB-3.0-Standards ist die Entwicklung eines Web Services weiter vereinfacht worden. So sind zum Beispiel die Konfigurationsdatei webservice.xml und externe Tools, wie zum Beispiel das Java Webservice Deployment Pack, nicht mehr unbedingt nötig. Vielmehr kann man nun entsprechende Stateless Session Beans bzw. normale Java Objekte (POJOs - Plain Old Java Objects) mit Annotations wie zum Beispiel @WebService oder @WebMethod ? entsprechend der JAX-WS 2.0-Spezifikation versehen, um diese als Web Service zu deklarieren. Diese werden dann vom Application Server erkannt, der weitere Schritte übernimmt. Dies ist zum Beispiel die automatische Generierung der WSDL-Datei während des Deployens des Web Services.[127] Wie bereits erwähnt, beschränken sich die Zugriffe von ?außen? nicht nur auf die Verwendung von Web Services. Neben diesen ist es ebenso möglich, EJBs über die Common Object Request Broker Architecture (CORBA) der Object Management Group (OMG) oder über die Remote Method Invocation (RMI) von Sun Microsystems anzusprechen.[128] 6.6.3.2 CORBA und RMI Die Middleware-Technologie CORBA ist ebenso wie Web Services darauf ausgelegt, interoperabel mit einem Partner zu kommunizieren, der nicht in Java geschrieben wurde. Die Sprache, in der CORBA seine Interfaces beschreibt, ist die Interface Definition Language (IDL). Mit dieser wird ebenfalls wie bei der WSDL-Datei bei Web Services beschrieben, wie Objekte und Methoden angesprochen werden können bzw. welche Parameter oder Datentypen erwartet werden.[129] Bei der Benutzung von RMI ist eine weitere Beschreibungssprache nicht notwendig, da dieses hauptsächlich für die Kommunikation von einem Java-Programm zu einem anderen Java-Programm gedacht ist. Für den Transport werden, anders als bei Web Services per SOAP, die Daten bei CORBA mittels IIOP (Internet Inter-ORB Protocol) und bei RMI über das JRMP (Java Remote Method Protocol) bzw. auch das IIOP übertragen.[129] Sun Mircosystems hat im Jahr 2001 IIOP in RMI integriert, um kompatibel zu CORBA zu sein und ebenfalls mit diesem Protokoll mit CORBA-Anwendungen kommunizieren zu können.[130] 6.6.3.1 Web Services 30 Leistungsanalyse_JBOSS Bei der Verwendung der unterschiedlichen Technologien sollte man in Erwägung ziehen, ob eine Interoperabilität zwischen den verschiedenen Applikationen gebraucht wird. Sollte man diese nicht benötigen, zum Beispiel in dem Fall, dass das Client- und Serverprogramm beide in Java geschrieben sind, dann sollte man das in der Regel performantere Duo RMI / JRMP benutzen.[131] In Sachen Performance verhält sich der JBoss Application Server bei der Nutzung von RMI / JRMP aber anders, als man erwartet. Die beim JBoss verwendeten EJBs arbeiten im Standard über RMI / JRMP. Kommunizieren diese aber wiederum über RMI / IIOP, so ergibt sich ein Geschwindigkeitszuwachs von ca. 30 Prozent. Dies steht in einem erheblichen Widerspruch zu den allgemeinen Erfahrungen, dass Kommunikation per IIOP langsamer ist, als die über JRMP.[132] Wegen der besseren Eigenschaften der Protokollierung des Datenstroms wird aber meist die Verwendung von IIOP bevorzugt.[131] Ob nun eine Kommunikation über einen Web Service oder über RMI / IIOP bzw. RMI / JRMP zwecks Interoperabilität implementiert werden soll, hängt von weiteren Fragen ab, wie zum Beispiel: • Ist es sicher, den Application Server direkt an das Internet anzubinden? • Arbeitet der Kommunikationspartner ebenso mit Java? • Ist mit allen Partnern eine Kommunikation per IIOP möglich?[133] Sollte eine dieser drei Fragen mit ?Nein? beantwortet werden, so sollte in Erwägung gezogen werden, die gewünschte Applikation als einen Web Service zu implementieren und zur Verfügung zu stellen.[133] 6.7 Sicherheit 6.7.1 Einleitung Das Thema Sicherheit spielt bei der Entwicklung von Anwendungen grundsätzlich eine wichtige Rolle. Vor allem im Bereich von Unternehmensanwendungen können Sicherheitslücken sowie der Verlust von sensiblen Daten kostspielig sein. Der Schutz vor unbefugtem Zugriff muss zum einen für die Informationen innerhalb der Anwendung und zum anderen für die Umgebung, in der diese läuft, sichergestellt sein.[134] Da die Sicherheit sich durch die gesamte Anwendung oder das gesamte System durchzieht und somit ein globaler Aspekt ist, spricht man auch von einem Cross-Cutting Concern.[135] Die drei wesentlichen Aspekte bzgl. der Sicherheit sind Authentifizierung, Autorisierung (Zugriffskontrolle) und Verbindung bzw. Kommunikation. Die Authentifizierung ist die Validierung der Benutzeridentität meist in Form von Benutzername und Passwort. Nach erfolgreicher Authentifizierung wird bei der Autorisierung überprüft, welche Aktionen der Benutzer im System durchführen darf. Eine sichere Kommunikation bzw. Verbindung ist z.B. mit Hilfe von Verschlüsselungsverfahren und Sicherheitszertifikaten zu erreichen.[136] Der letzte Aspekt ist besonders bei der Nutzung eines offenen Mediums wie dem Internet wichtig. Im Rahmen der Kommunikation sind die drei Kriterien Vertraulichkeit, Integrität der Daten und Integrität des Absenders/Empfängers relevant. Vertraulichkeit heißt, dass die Daten durch Dritte nicht mitgelesen werden. Unter Integrität der Daten versteht man, dass diese nicht durch Dritte manipuliert werden. Die Integrität des Absenders/Empfängers bedeutet, dass die Person wirklich die ist, für die sie sich ausgibt.[137] Es gilt zu überprüfen, wie die oben genannten Kriterien beim JBoss Application Server umgesetzt sind und welche Standards z.B. bezogen auf Protokolle und Verschlüsselungsverfahren dieser unterstützt. Weiterhin von Interesse ist, wie die Konfiguration der Sicherheit erfolgt und welche Bestandteile eines Application Servers abgesichert werden können, also z.B. Web-Anwendungen, EJBs, Webservices usw. 6.6.3.2 CORBA und RMI 31 Leistungsanalyse_JBOSS 6.7.2 JBossSX Der JBoss Application Server beinhaltet ein eigenständiges Modul für die Sicherheit aller J2EE-Technologien, die innerhalb des Application Servers laufen. Dieses Modul heißt JBoss Security Extension (JBossSX) und basiert auf der JAAS-API (Java Authentication and Authorization Service).[138] Die JAAS-API wurde zuerst als Erweiterung für JDK 1.3 veröffentlicht. Ab JDK 1.4 gehörte diese zum Basisumfang dazu. Sie deckt sowohl Authentifizierung als auch Autorisierung ab. JBossSX baut jedoch lediglich auf den Funktionalitäten im Bereich der Authentifizierung auf. Im Wesentlichen sind dies die folgenden Elemente: • Subject (javax.security.auth.Subject) • Principal (java.security.Principal) • Callback (javax.security.auth.callback.Callback) • CallbackHandler (javax.security.auth.callback.CallbackHandler) • Configuration (javax.security.auth.login.Configuration) • LoginContext (javax.security.auth.login.LoginContext) • LoginModule (javax.security.auth.spi.LoginModule)[139] Ein näherer Blick in die Dokumentation des JDK 1.4 zeigt, dass die meisten der genannten Elemente keine vollimplementierten Java-Klassen sind.[140] Principal, Callback, CallbackHandler, LoginModule sind Interfaces und Configuration ist eine abstrakte Klasse. Dies unterstreicht die Tatsache, dass JAAS eine Abstraktionsschicht zwischen die Anwendung und den darunterliegenden Sicherheitsmechanismus legt und somit eine Austauschbarkeit herstellt, ohne dabei das gesamte System zu beeinflussen.[141] Lediglich LoginContext und Subject sind ausprogrammierte Java-Klassen, wobei von der Klasse Subject keine weiteren Klassen abgeleitet werden können, da diese um das Schlüsselwort final erweitert ist. Dies deutet darauf hin, dass die beiden Elemente fundamental sind und von jedem Application Server in dieser Form genutzt werden. Dies gilt vor allem für die Klasse Subject, die die zentrale Klasse von JAAS darstellt.[142] Ein Subject ist eine Person oder ein System, die bzw. das sich authentifizieren möchte. Einem Subject können ein oder mehrere Principals zugeordnet sein. Ein Principal ist eine eindeutige Identität z.B. in Form einer ID, digitalen Signatur oder Kreditkartennummer.[143] 6.7.2.1 Authentifizierung und Autorisierung 6.7.2 JBossSX 32 Leistungsanalyse_JBOSS Abbildung 6: JBossSX[144] Die J2EE-Spezifikation schreibt nicht vor, wo die Daten zur Authentifizierung abgelegt, auf welche Art diese herangezogen und wie diese validiert werden müssen. Darüber entscheiden die Anbieter der einzelnen Application Server selbst und stellen dementsprechend eine eigene Implementierung bereit. Im Fall von JBossSX werden alle Anfragen innerhalb des Application Servers an eine Security Domain bzw. Security Realm weitergegeben. Dies ist für alle Komponenten des Application Servers wie z.B. Web-Anwendungen, EJB-Anwendungen, JMS queues/topics einheitlich geregelt.[138] Jede dieser Komponenten kann dabei einer unterschiedlichen Security Domain, jedoch zu einem Zeitpunkt immer nur einer einzigen, zugeordnet sein. Eine Security Domain ist die zentrale Quelle für Benutzer, Passwörter sowie die den Benutzern zugeordneten Rollen.[145] Beim JBoss Application Server sind Security Domains über die Datei login-config.xml zu konfigurieren.[146] In dieser Datei stehen in der Regel keine direkten Informationen für die Authentifizierung und Autorisierung, sondern darin sind lediglich die Orte aufgeführt, wo diese Informationen abgefragt werden können. JAAS unterstützt Security Domains, die auf folgenden Techniken beruhen: • DBMS (Datenbankmanagementsystem) • Application Server • LDAP (Lightweight Directory Access Protocol) • Betriebssystem (UNIX oder Windows NT/2000) • Dateisystem • JNDI (Java Naming and Directory Interface) • Biometrie[147] JBossSX unterstützt standardmäßig Security Domains auf der Basis von DBMS, LDAP und Dateisystem.[148] Innerhalb einer Security Domain muss je nach gewünschter Technik ein entsprechendes LoginModule verwendet werden. Die gebräuchlichsten dieser Module befinden sich in den Java-Paketen org.jboss.security.auth.spi, org.jboss.security.src.jaas und org.jboss.security. Für eine Authentifizierung und Autorisierung mittels DBMS, LDAP oder Dateisystem eignen sich unter anderem die Klassen DatabaseServerLoginModule, LdapLoginModule und UsersRolesLoginModule in der genannten Reihenfolge.[149] Innerhalb einer Security Domain können auch mehrere LoginModules verwendet werden, z.B. bei einer Authentifizierung anhand mehrerer Quellen oder wenn die Authentifizierung und Autorisierung anhand verschiedener Quellen durchgeführt wird. Dies wird auch als Stapeln (Stacking) von LoginModulen bezeichnet.[150] Sollten die standardmäßig mitgelieferten LoginModule 6.7.2.1 Authentifizierung und Autorisierung 33 Leistungsanalyse_JBOSS nicht ausreichen, können benutzerdefinierte programmiert werden.[151] Um eine Security Domain einer bestimmten Komponente des Application Servers zuzuordnen, steht ein deklaratives Modell in Form von XML-Deskriptoren zur Verfügung. Bei EJB-Anwendungen kann zusätzlich auf Annotations zurückgegriffen werden. Der Nachteil der Annotations liegt darin, dass diese im Programmcode fest verdrahtet sind, während die XML-Deskriptoren von diesem losgelöst sind. Mit der Einführung von EJB3 gilt die Regel, dass die XML-Deskriptoren dazu benutzt werden, die Standard-Konfiguration teilweise zu überschreiben (partial deployment descriptor) oder die Konfiguration in den Annotations bei Bedarf zu überschreiben (convention over configuration).[152] Somit ist der parallele Einsatz von XML-Deskriptoren und Annotations ebenfalls denkbar. Grundsätzlich erfüllt der JBoss Application Server durch die XML-Deskriptoren die Anforderung, das Thema Sicherheit als einen anwendungsübergreifenden Aspekt bzw. Cross-Cutting Concern zu behandeln. Neben den Standard-Deskriptoren sind für die Sicherheitskonfiguration die JBoss-spezifischen Deskriptoren obligatorisch. Die JBoss-spezifischen Deskriptoren dienen dazu, die zuvor in der login-config.xml erstellten Security Domains den jeweiligen Komponenten zuzuordnen. Für Web-Anwendungen kommt neben dem Standard-Deskriptor web.xml der JBoss-spezifische Deskriptor jboss-web.xml hinzu. Bei EJB-Anwendungen lautet der Standard-Deskriptor ejb-jar.xml und der JBoss-spezifische jboss.xml. Diese Vorgehensweise kann auf alle Komponenten des JBoss Application Servers übertragen werden. Es müssen lediglich die richtigen XML-Dateien verwendet werden.[153] Abbildung 7: Sicherheit anhand des Beispiels einer Web-Anwendung[154] Die login-config.xml ist statisch. Das heißt, dass eventuelle Änderungen an der Datei zur Laufzeit nicht übernommen werden. Eine darin konfigurierte SecurityDomain wird erst beim Start bzw. Neustart des Servers unter JNDI gebunden und auch nur dann, wenn eine Anwendung existiert, die diese verwendet.[155] Weiterhin besteht beim JBoss Application Server die Möglichkeit, Security Domains dynamisch zu adressieren. Dafür muss im ersten Schritt ein MBean vom Typ org.jboss.security.auth.login.DynamicLoginConfig im Deploy-Verzeichnis des Servers erstellt werden. Diese Datei muss die Endung *-service.xml besitzen. Darin ist der Dateiname für die dynamische LoginConfiguration hinterlegt. Im zweiten Schritt muss eine Datei mit genau diesem Namen, die 6.7.2.1 Authentifizierung und Autorisierung 34 Leistungsanalyse_JBOSS vom Format identisch mit der login-config.xml ist, in der Archivdatei der jeweiligen Anwendung hinterlegt werden.[156] Es gibt Anwendungsfälle, bei denen das rollenbasierte Sicherheitskonzept unzureichend ist. Dieser Fall tritt ein, wenn sich die Sicherheitsüberprüfung direkt auf die Informationen einer Benutzeranfrage bezieht. Beispielsweise kann ein Bankmitarbeiter Buchungen bis 10.000 Euro eigenständig bearbeiten, darüber hinaus muss er eine Freigabe seines Vorgesetzten erhalten. In diesem Fall ist eine von Hand programmierte Lösung nicht zu vermeiden, weshalb man auch von programmatic security bzw. context-based security spricht.[157] Innerhalb des Web-Containers eignen sich dazu die Methoden getUserPrincipal und isUserInRole. Die beiden Pendants dazu innerhalb des EJB-Containers heißen getCallerPrincipal und isCallerInRole. getUserPrincipal bzw. getCallerPrincipal liefert die Benutzerkennung zurück und mit isUserInRole bzw. isCallerInRole kann abgefragt werden, ob dem Benutzer eine entsprechende Rolle zugeordnet ist. Grundsätzlich ist bei der programmatic Security zu beachten, dass dieser Ansatz ein hohes Maß an Flexibilität bietet, jedoch die Portabilität des Quellcodes verloren gehen kann.[158] 6.7.2.2 Verbindung / Kommunikation Die Sicherung der Verbindung bzw. der Kommunikation erfolgt beim JBoss Application Server über das Protokoll SSL (Secure Socket Layer) bzw. TLS (Transport Layer Security). Dazu verwendet dieser JSSE (Java Secure Socket Extension), welches seit JDK 1.4 zum Basisumfang gehört.[159] JSSE unterstützt SSL in den Versionen 2.0, 3.0 und TLS in der Version 1.0 sowie zahlreiche Verschlüsselungsverfahren, von denen RSA und DSA in diesem Kontext relevant sind.[160] Zwingende Voraussetzung für die Nutzung von SSL sind beglaubigte Zertifikate. Dabei hängt es von der Authentifizierungsmethode ab, ob nur der Server oder sogar Client und Server ein gültiges Zertifikat bereitstellen müssen. Meldet sich ein Benutzer z.B. beim Online-Banking bei seiner Bank an, muss lediglich die Bank ein Zertifikat bereitstellen. In diesem Fall spricht man von protocol-level server authentication. Tauschen beispielsweise zwei Banken untereinander Daten aus oder nutzt ein Mitarbeiter firmeninterne Dienste über das Internet, müssen beide Parteien, Client und Server, gültige Zertifikate aufweisen. In der Regel liegt dabei die protocol-level mutual authentication vor.[161] Das JDK stellt das Programm keytool bereit, mit dem sich eine Datenbank (Keystore bzw. Truststore), bestehend aus private und public keys, sowie Zertifikaten verwalten lässt. Es ermöglicht unter anderem die Generierung, Speicherung sowie den Import und Export von Zertifikaten. Ein Zertifikat ist eine Art digitale Unterschrift von einer Instanz (Person, Unternehmen usw.), die beglaubigt, dass ein public key von einer anderen, genau benannten Instanz (Person, Unternehmen usw.) stammt.[162] Wird ein Paar, bestehend aus private und public key mittels keytool generiert, wird auch ein Zertifikat erstellt. Dieses Zertifikat sagt jedoch nur aus, dass man selbst den public key beglaubigt hat. Der Vorteil liegt darin, dass diese Variante kostenlos ist. Das heißt, die Vorgehensweise eignet sich gut zu Testzwecken oder für die Kommunikation über geschlossene Netze (z.B. Intranet). Für die Kommunikation über offene Netze (z.B. Internet) sollte die kostenpflichtige Variante bevorzugt werden. Zunächst muss mittels keytool anhand eines selbst beglaubigten Zertifikats ein CSR (Certificate Signing Request) aus dem Keystore exportiert werden. Dieser muss an eine CA (Certificate Authority) wie z.B. VeriSign, Thawte oder Entrust gesendet werden. Die CA schickt dann das beglaubigte Zertifikat an den Antragsteller zurück, der dieses zurück in seinen Keystore importieren muss.[163] Die Nutzung des Keystores in einer Security Domain ist direkt nicht möglich. Das heißt, dass sich in der Datei login-config.xml keine SSL-fähigen Security Domains definieren lassen. Die Integration in JBossSX erfolgt über den Umweg eines MBean vom Typ org.jboss.security.plugins.JaasSecurityDomain. Die Vorgehensweise ist 6.7.2.2 Verbindung / Kommunikation 35 Leistungsanalyse_JBOSS ähnlich wie bei dynamischen Security Domains. Zunächst muss ein MBean-Service im Deploy-Verzeichnis des Servers erstellt werden. Diese Datei muss die Endung *-service.xml besitzen. Darin ist der Pfad zum Keystore sowie der Name der Security Domain hinterlegt, die um die SSL-Funktionalität erweitert werden soll. Dieser Name muss mit dem Namen in der login-config.xml definierten Security Domain übereinstimmen.[164] Abbildung 8: Zusammenspiel zwischen JaasSecurityDomain, Truststore, Security Domain und Security Datastore[165] Je nach verwendeter Komponente variiert die Aktivierung der SSL-Unterstützung. Sowohl die Methode an sich als auch die verwendeten Konfigurationsdateien weichen voneinander ab. Der Zugriff auf Web-Anwendungen ist durch den in JBoss integrierten Webserver (Apache Tomcat) vergleichsweise einfach umzusetzen. Denn dieser unterstützt SSL standardmäßig. Dazu muss lediglich ein HTTP Connector in der Datei server.xml eingetragen sein, der auf einen Keystore verweist.[166] Erfolgt ein direkter Zugriff auf EJBs von außen z.B. über eine GUI-Anwendung, so kann auch diese Verbindung per SSL gesichert werden. Die Konfiguration kann entweder über ein MBean vom Typ org.jboss.remoting.transport.Connector vorgenommen werden oder direkt über Annotations in den EJBs selbst.[167] Bei Web-Services kann die Verschlüsselung der SOAP Nachricht zum einen ähnlich wie bei Web-Anwendungen über SSL und zum anderen mit Hilfe von JAX-WS (Java API for XML Web Services) geschehen. Die Variante per JAX-WS ist aufwändiger. Dabei kommen die Konfigurationsdateien jboss-wsse-server.xml und jboss-wsse-client.xml zum Einsatz. Zu beachten ist, dass diese Dateien bei POJO-Webservices im WEB-INF Ordner und bei EJB-Webservices im META-INF Ordner liegen müssen. Weiterhin ist die Annotation @EndpointConfig nötig, um auf eine JAX-WS Konfiguration in der Datei standard-jaxws-endpoint-config.xml zuzugreifen, sowie die Datei standard-jaxws-client-config.xml, um die Nutzung von JAX-WS clientseitig zu veranlassen.[168] 6.8 Zusammenfassender Überblick Im Folgenden steht eine kurze, tabellarische Zusammenfassung über die Ergebnisse der Leistungsanalyse. Kriterium Systemanforderungen Ergebnis(se) Hardwarevoraussetzungen: + geringer Bedarf an CPU, RAM und Festplattenspeicherplatz für die reine Grundinstallation + bei fehlender Rechnerleistung Einrichtung eines Clustersystems möglich Softwarevoraussetzungen: 6.8 Zusammenfassender Überblick 36 Leistungsanalyse_JBOSS ° mindestens JDK Version 1.4, für EJB3-Technologie JDK Version 1.5 notwendig + integrierter Webserver (Tomcat) + integrierte relationale Datenbank (HSQLDB) und weitere per Anbindung möglich + JBoss 4 ist vollständig J2EE 1.4 konform + herstellerunabhängiger Standard sorgt für Portabilität + J2EE Standard APIs stellen zahlreiche Funktionalitäten zur Verfügung, auf die Entwickler zurückgreifen können + J2EE konformer Web-Container Tomcat 5 kann mit wenig Aufwand durch Java EE Konformität jeden anderen J2EE konformen Web-Container ersetzt werden + J2EE konformer EJB-Container implementiert EJB 2.1 Spezifikation und bietet Hilfestellung zu Einhaltung des Standards (EJBDeployer-MBean) - nicht alle benötigten Grundfunktionalitäten ausreichend durch Standard APIs abgedeckt, so dass der Einsatz proprietärer APIs manchmal unumgänglich ist - Einsatz von proprietären APIs setzt Portabilität aufs Spiel + Flexibilität und Modularität durch Mikrokernel-Architektur + verschiedene Start-Konfigurationen möglich - persistente Konfiguration nur auf Dateiebene möglich Konfiguration und - Konfiguration der Dienste kann sehr komplex und zeitaufwändig sein Administration - Konfiguration über JMX-Console und Twiddle zu technisch - JMX-Console, JBoss Web-Console sowie HTTP- und JMX-Invoker im Auslieferungszustand nicht abgesichert + Auswahl der Entwicklungsumgebung bleibt dem Anwender überlassen + Hot-Deployment und Redeployment ohne erforderlichen Neustart des Servers + flexible und modulare Deployment-Architektur + unterstützt die Schachtelung von Archivtypen (Arbitrary Nesting bzw. Russian Entwicklung und Deployment Doll Packaging) - Deployment per JMX-Console und Twiddle nicht persistent - Änderungen innerhalb des Deploy-Verzeichnisses können dazu führen, dass alle Verbindungen zu einer Anwendung getrennt werden, da diese automatisch neu deployt wird + Erhöhung der Performance durch horizontale Skalierung + Verteilung von rechenintensiven Komponenten auf mehrere Server möglich + Duplizierung von Sessions durch Clustering sorgt für Hochverfügbarkeit + automatische Lastenverteilung innerhalb des Clusters Performance, Skalierbarkeit + JBoss Cluster ist einfach zu konfigurieren + automatische Verteilung der redundanten Komponenten innerhalb des Clusters und Verfügbarkeit - Clustering über viele Server hinweg sorgt für Performanceverlust, da großer Overhead für Ausbringung von Änderungen - keine Untergruppierungen innerhalb eines Clusters möglich, redundante Komponenten werden stets auf alle Server verteilt Interoperabilität + Portabilität von erstellten Anwendungen durch Konformität zu J2EE Version 1.4 gegeben + Nutzung eingebetteter Frameworks, vieler Standards und genormter Schnittstellen (IDL, XML) + Integration in eine serviceorientierte Architektur möglich + herstellerübergreifende Funktionsaufrufe bzw. Kommunikation per Web Services (SOAP, REST), CORBA (IIOP) und RMI (IIOP, JRMP) möglich 6.8 Zusammenfassender Überblick 37 Leistungsanalyse_JBOSS + Datenkompatibilität mittels Wrapper + als Web Service können genutzt werden: EJBs, POJOs, Servlets + unterstützt die Authentifizierung und Autorisierung per DBMS, LDAP und Dateisystem + Authentifizierung und Autorisierung anhand mehrerer bzw. unterschiedlicher Quellen möglich + benutzerdefinierte Module für Authentifizierung und Autorisierung möglich + Programmatic Security bzw. Context-Based Security grundsätzlich möglich + Unterstützung von SSL 2.0, SSL 3.0 und TLS 1.0 + Unterstützung von zahlreichen Verschlüsselungsverfahren (z.B. RSA, DSA Sicherheit usw.) - grundsätzliche Problematik: XML-Deskriptoren vs. Annotations - Einsatz der zusätzlich benötigten Deskriptoren etwas undurchsichtig - Konfiguration von Security Domains erfordern Neustart des Servers - SSL-Funktionalität nur über den Umweg einer ManagedBean möglich - keine einheitliche Aktivierung der SSL-Unterstützung bei unterschiedlichen Komponenten - hohe Komplexität und viele Abhängigkeiten erschweren den Überblick Tabelle 13: Zusammenfassender Überblick 7 Fazit Seit der Veröffentlichung des JBoss Application Servers im November 1999 hat sich dieser der Konkurrenz kontinuierlich angenähert. Nach einer Untersuchung von Gartner im September 2009 schafft es JBoss als einziger Open-Source Application Server in den Quadranten der Marktführer. Der Vorsprung der kommerziellen Application Server von Oracle (Weblogic), IBM (WebSphere) und Microsoft (diverse Angebote) ist deutlich geschrumpft. Durch die Akzeptanz der Fachwelt sowie der großen Anzahl an aktiven Entwicklern, die Teil der JBoss Community sind bzw. durch Red Hat zur Verfügung gestellt werden, besitzt JBoss mittlerweile einen hohen Verbreitungsgrad. Die Leistungsanalyse als Kern dieser Arbeit bezieht sich dabei auf die Version 4 des Application Servers. Weiterhin erfolgt keine Differenzierung auf JBoss Enterprise Version und JBoss Community Version. Beide Varianten werden grundsätzlich als identisch angesehen, was die Analyse von technischen Feinheiten erleichtert. Die Hardwareanforderungen, die den Einsatz des JBoss Application Server ermöglichen, variieren und sind stark von den Bedürfnissen des Anwenders und der eingesetzten Anwendungen abhängig. Im Gegensatz dazu sind bei den Softwareanforderungen klare Vorgaben gesetzt. Grundsätzlich ist eine Installation des JDK 1.4 Pflicht, unter Verwendung von EJB3 sogar das JDK 1.5. Dadurch, dass der JBoss Application Server selbst in Java entwickelt ist, kann dieser auf jedem Betriebssystem installiert werden, für das eine JVM in der benötigten Version zur Verfügung steht. Mit der J2EE-Zertifizierung seitens Sun Microsystems ist ebenso der Wechsel zwischen verschiedenen Application Servern möglich. Der Einsatz von proprietären APIs, JBoss spezifischen Deskriptoren oder Context-Based Security kann derartige Portierungen erschweren. Der Basisumfang des JBoss Application Server umfasst die Hypersonic SQL Datenbank und als Webcontainer den Apache Tomcat 5.x. Beides kann durch individuelle Komponenten ausgetauscht werden. Diese Modularität und Flexibilität gilt für die gesamte Architektur des Servers. Dieser basiert auf einem JMX-Mikrokernel. Alle Dienste wie z.B. Persistenz, Trankaktionen oder Sicherheit setzen als so genannte MBeans auf diesen auf. So lassen sich verschiedene Startkonfigurationen aus individuell ausgewählten MBeans verwenden. Eine persistente Konfiguration dieser Startkonfigurationen ist jedoch nur auf Dateiebene möglich. Die mitgelieferten Programme JMX-Console, JBoss Web-Console und Twiddle eignen sich dazu nicht, da zum einen alle Änderungen einen Neustart des Servers nicht überdauern und zum anderen die Bedienung zu technisch bzw. unkomfortabel ist. Zudem bietet die JMX-Console und die JBoss Web-Console im Auslieferungszustand ein Sicherheitsrisiko, weshalb diese neben der HTTP- und JMX-Invoker zunächst abgesichert werden sollten. 7 Fazit 38 Leistungsanalyse_JBOSS Die Bereitstellung (Deployment) von Anwendungen auf dem JBoss Application Server ist ebenfalls durch eine MBean geregelt. So können Anwendungen durch simples Einfügen, Ändern oder Löschen im Deploy-Verzeichnis zur Laufzeit manipuliert werden. In diesem Zusammenhang spricht man auch von Hot-Deployment bzw. Redeployment ohne erforderlichen Neustart des Servers. Dabei sollte stets berücksichtigt werden, dass Änderungen im Deploy-Verzeichnis dazu führen können, dass alle Verbindungen zu einer Anwendung getrennt werden, da diese automatisch neu deployt wird. Ähnlich wie bei der Konfiguration unterliegt das Deployment per JMX-Console oder JBoss Web-Console den gleichen Defiziten, weshalb die zuvor genannte Variante gewählt werden sollte. Zur Gewährleistung der Sicherheit kann der Zugriff auf die erstellten Anwendungen gesteuert werden. JBoss unterstützt die Authentifizierung und Autorisierung per DBMS, LDAP und Dateisystem und lässt sowohl mehrere als auch unterschiedliche Quellen dafür zu. Sollten die mitgelieferten Funktionalitäten nicht ausreichen, können eigens erstellte Varianten verwendet werden. Für die Absicherung der Kommunikation bzw. Verbindung unterstützt JBoss SSL 2.0, SSL 3.0 und TLS 1.0 sowie zahlreichen Verschlüsselungsverfahren (z.B. RSA, DSA usw.). Allerdings ist dies nur über den Umweg einer MBean möglich. An dieser Stelle wird deutlich, wie die hohe Modularität zum Nachteil werden kann. Die Konfiguration der SSL-Unterstützung ist bei den unterschiedlichen Komponenten (Web-Anwendungen, EJB-Anwendungen, Webservices usw.) nicht einheitlich. Weiterhin erfordert die Veränderung an grundlegenden Sicherheitsmerkmalen einen Neustart des Servers. Um die Performance des JBoss Application Server zu steigern bietet dieser das Clustering als Mittel der horizontalen Skalierung an. So können rechenintensive Anwendungskomponenten auf mehrere Server verteilt, und die Anfragen an den Cluster durch Smart-Stubs oder Load-Balancer automatisch auf die Teilnehmer des Clusters verteilt werden. Bei Ausfall eines Clusterteilnehmers erfolgt dann automatisch eine Weiterleitung aller Anfragen auf die anderen Clusterteilnehmer, welche ebenfalls die geforderte Anwendungskomponente bereitstellen. Der JBoss Cluster ist zunächst sehr einfach zu konfigurieren, da es bereits ausreicht alle teilnehmenden Server im "all"-Modus zu starten und diese sich dann selbstständig gegenseitig im Netzwerk aufspüren und untereinander abgleichen. Die zu replizierenden Sessions können mit geringem Aufwand durch entsprechende Deployment-Deskriptoren gekennzeichnet werden und werden dann automatisch innerhalb des Clusters verteilt. Leider kann die Bildung eines Clusters über eine hohe Anzahl von Servern hinweg zu Performanceverlust führen, da ein großer Overhead für die Ausbringung der Änderungen innerhalb des Clusters entsteht. Dem könnte durch die Möglichkeit der Bildung von Untergruppen innerhalb eines Clusters entgegengewirkt werden. So müssten sich nicht mehr alle Teilnehmer des Clusters untereinander abgleichen, sondern nur die Teilnehmer der jeweiligen Untergruppen. Die Hochverfügbarkeit wäre solange nicht beeinträchtigt, bis die gesamte Untergruppe ausfällt. Leider bietet der JBoss Application Server in der Version 4 nicht die Möglichkeit der Untergruppierung. Mit dem JBoss Application Server wird die Interoperabilität zwischen zwei oder mehreren Unternehmen gewährleistet und ebenso die Möglichkeit geschaffen, heterogene Anwendungssysteme mit diesem in einer Systemlandschaft zu integrieren. Hierfür werden für die Arbeit mit dem JBoss verschiedene Frameworks, Standards und genormte Schnittstellen bereitgestellt. So können die weit verbreiteten Technologien Web Services, CORBA und RMI für die Implementierung von entfernten Funktionsaufrufen zum Einsatz kommen. Wrapper bieten hierzu Übersetzungsdienste zu denen als Web Service genutzten EJBs, POJOs oder Servlets an und gewähren dadurch die Datenkompatibilität zu den genutzten Programmiersprachen. Als anormales Verhalten des JBoss ist hier jedoch die Performancesteigerung bei der Kommunikation zu erwähnen. Entgegen einer standardisierten und im Normalfall performanteren Nutzung des JRMP-Protokolls in Zusammenarbeit mit RMI, erfährt die Kommunikation bei Verwendung des Protokolls IIOP einen Geschwindigkeitszuwachs um ca. 30 Prozent. Dies steht in einem enormen Widerspruch zu den Erkenntnissen, die bis dato aus der Praxis erlangt wurden. Zusammenfassend gilt zu sagen, dass der JBoss Application Server aufgrund der vielen Funktionalitäten und enthaltenen Standards, sowie seiner raschen Weiterentwicklung eine ernst zu nehmende Alternative zu kommerziellen Produkten darstellt. Trotzdem muss an dieser Stelle auf die Gefahr hingewiesen werden, den JBoss Application Server ohne entsprechendes Wissen einzusetzen. Dadurch, dass sich der Server so leicht herunterladen und durch einfaches Entpacken installieren lässt, ist die Verlockung groß, in diesem Zustand damit 7 Fazit 39 Leistungsanalyse_JBOSS in den Produktivbetrieb zu wechseln. Der Server sollte nur von Spezialisten bzw. vorher geschulten Anwendern eingesetzt werden, auch wenn die hohen Schulungsgebühren der kostenlosen Verfügbarkeit des eigentlichen Servers gegenüberstehen. Gerade die Konfiguration ist komplex, zeitaufwändig, undurchsichtig und fehleranfällig. Zudem erschweren die vielen Abhängigkeiten durch die an vielen Stellen vorkommende Modularität den Überblick zu behalten. Eine schwerwiegende Sicherheitslücke im Auslieferungszustand kann dazu führen, dass eine fremde Person den JBoss Application Server fernsteuern kann. Letztendlich sind dies Faktoren, die den Erfolg eines Projektes beeinträchtigen können. Falls die Wahl auf den JBoss Application Server fällt, sind zusätzliche, externe Tools z.B. zur Administration oder zur Entwicklung unumgänglich, weil diese entweder gänzlich fehlen oder schlichtweg ungeeignet sind. Diese Tools sollten sorgfältig ausgewählt sein, da sie z.B. den Grad der Arbeitserleichterung sowie die Geschwindigkeit und den Komfort der Anwendungsentwicklung beeinträchtigen. Nichtsdestotrotz können bestimmte Schwierigkeiten z.B. hinsichtlich der Thematik XML-Deskriptoren vs. Annotations dadurch nicht behoben werden. Durch die unterschiedliche Versionierung des JBoss kommt hinzu, dass es Updates bzw. Patches nur für die von Red Hat angebotene Enterprise Version des JBoss Application Servers gibt. Die Anwender der Community-Version sind dadurch mehr oder weniger auf sich allein gestellt und können ggf. Lösungsvorschläge von den Community-Mitgliedern erhalten. 8 Fußnoten 1. ? Vgl. Stoyan (2004), S. 325. 2. ? Vgl. Langner (2006), S. 5. 3. ? Vgl. Sam-Bodden (2004), S. 149. 4. ? Vgl. Gentsch (2004), S. 30. 5. ? Vgl. Stark (2004), S. 201f. 6. ? Vgl. Gulp.de (Mai 2002) 7. ? Vgl. Andresen (2004), S. 263. 8. ? Vgl. Stark (2004), S. 15. 9. ? Vgl. Sun.com (o.J.b) 10. ? Vgl. Andresen (2004), S. 264. 11. ? Vgl. Langner (2006), S. 7. 12. ? Vgl. Andresen (2004), S. 263ff. 13. ? in Anlehnung an: Andresen (2004), S. 265. 14. ? 14,0 14,1 14,2 Vgl. Jamae (2009), S. 4. 15. ? Vgl. Fleury (2005), S. 15. 16. ? Vgl. Redhat.com (April 2006) 17. ? 17,0 17,1 Vgl. JBoss.com (o.J.a) 18. ? Vgl. JBoss.com (November 2004), S. 2. 19. ? Vgl. JBoss.com (November 2004), S. 14. 20. ? Vgl. Javamagazin.de (o.J.) 21. ? Vgl. It-republik.de (Januar 2005) 22. ? 22,0 22,1 22,2 22,3 Vgl. Gartner.com (September 2009) 23. ? in Anlehnung an: Gartner.com (September 2009) 24. ? Vgl. Fleury (2005), S. 571. 25. ? 25,0 25,1 25,2 25,3 25,4 25,5 Vgl. JBoss.de (2008) 26. ? Vgl. Gnu.org (Dezember 2008) 27. ? Vgl. Novell.com (o.J.) 28. ? Vgl. Cursor.de (August 2009), S. 1. 29. ? 29,0 29,1 Vgl. Cursor.de (August 2009), S. 8. 30. ? Vgl. Richards (2005), S. 1. 31. ? Vgl. JBoss.org (Mai 2006), S. 1. 8 Fußnoten 40 Leistungsanalyse_JBOSS 32. ? 32,0 32,1 32,2 32,3 32,4 Vgl. JBoss.com (o.J.c) 33. ? Vgl. Cachaca.de (o.J.) 34. ? Vgl. Heise.de (November 2003) 35. ? Vgl. Sun.com (o.J.a) 36. ? Vgl. Heise.de (November 2003) 37. ? Vgl. Heise.de (März 2003) 38. ? Vgl. Sun.com (November 2003), S. 7. 39. ? in Anlehnung an: Sun.com (November 2003), S. 6. 40. ? 40,0 40,1 Vgl. Strobel (2004), S. 245. 41. ? Vgl. Sun.com (November 2003), S. 85f. 42. ? 42,0 42,1 Vgl. Sun.com (November 2003), S. 10. 43. ? 43,0 43,1 43,2 43,3 Vgl. Sun.com (November 2003), S. 11. 44. ? 44,0 44,1 Vgl. Sun.com (November 2003), S. 13. 45. ? 45,0 45,1 Vgl. Sun.com (November 2003), S. 102. 46. ? Vgl. Sun.com (o.J.c) 47. ? Vgl. Fleury (2006), S. 277. 48. ? Vgl. Langner (2006), S. 337. 49. ? Vgl. Ihns (2004), S. 69. 50. ? Vgl. Sun.com (November 2003), S. 12. 51. ? 51,0 51,1 51,2 Vgl. Sun.com (November 2003), S. 107. 52. ? Vgl. Sun.com (November 2003), S. 108. 53. ? Vgl. Sun.com (November 2003), S. 109. 54. ? Vgl. Fleury (2006), S. 19. 55. ? in Anlehnung an: Sun.com (November 2003), S. 86f. 56. ? Vgl. Sun.com (o.J.c) 57. ? 57,0 57,1 Vgl. Fleury (2005), S. 409. 58. ? Vgl. Fleury (2005), S. 79. 59. ? Vgl. Ihns (2004), S. 46. 60. ? Vgl. Sun.com (November 2003), S. 86f. 61. ? Vgl. Ahmad (2004), S. 42f. 62. ? Vgl. Ihns (2004), S. 52. 63. ? Vgl. Fleury (2005), S. 4. 64. ? Vgl. Dirk-Maschner.de (2006), S. 39. 65. ? Vgl. Fleury (2005), S. 216. 66. ? Vgl. Burke (2006), S. 532. 67. ? in Anlehnung an: Sam-Bodden (2004), S. 164. 68. ? Vgl. Jamae (2009), S. 41ff. 69. ? 69,0 69,1 69,2 69,3 69,4 Vgl. Fleury (2006), S. 26. 70. ? 70,0 70,1 Vgl. Burke (2006), S. 530. 71. ? Vgl. Marrs (2006), S. 7. 72. ? 72,0 72,1 72,2 Vgl. Richards (2005), S. 9. 73. ? Vgl. Marrs (2006), S. 11. 74. ? 74,0 74,1 Vgl. Burke (2006), S. 530. 75. ? 75,0 75,1 75,2 75,3 Vgl. Langner (2006), S. 13. 76. ? Vgl. Marrs (2006), S. 9. 77. ? Vgl. Richards (2005), S. 7. 78. ? Vgl. JBoss.org (Mai 2006), S. 8f. 79. ? Vgl. Jamae (2009), S. 40. 80. ? 80,0 80,1 Vgl. JBoss.org (Mai 2006), S. 11. 81. ? 81,0 81,1 Vgl. Jamae (2009), S. 41. 82. ? Vgl. JBoss.org (Mai 2006), S. 319. 8 Fußnoten 41 Leistungsanalyse_JBOSS 83. ? Vgl. Fleury (2006), S. 91. 84. ? Vgl. Jamae (2009), S. 48. 85. ? in Anlehnung an: Jamae (2009), S. 43ff. 86. ? Vgl. JBoss.org (Mai 2006), S. 319f. 87. ? Vgl. Hof (2009), S. 21f. 88. ? Vgl. Hof (2009), S. 11f. 89. ? Vgl. Langner (2006), S. 17. 90. ? Vgl. JBoss.com (o.J.b) 91. ? Vgl. JBoss.org (o.J.) 92. ? Vgl. Jamae (2009), S. 47. 93. ? Vgl. Burke (2006), S. 533. 94. ? Vgl. Fleury (2006), S. 143f. 95. ? 95,0 95,1 95,2 95,3 Vgl. Jamae (2009), S. 48. 96. ? in Anlehnung an: Fleury (2006), S. 143f. 97. ? Vgl. Marrs (2006), S. 11. 98. ? 98,0 98,1 98,2 Vgl. Richards (2005), S. 26. 99. ? Vgl. JBoss.org (Mai 2006), S. 68. 100. ? Vgl. Richards (2005), S. 25. 101. ? 101,0 101,1 101,2 101,3 101,4 Vgl. Jamae (2009), S. 414. 102. ? Vgl. Jamae (2009), S. 416. 103. ? Vgl. Royans.net (September 2007) 104. ? Vgl. Langner (2006), S. 431. 105. ? Vgl. Jamae (2009), S. 321. 106. ? 106,0 106,1 Vgl. Langner (2006), S. 432. 107. ? 107,0 107,1 107,2 107,3 107,4 107,5 107,6 Vgl. JBoss.org (2006) 108. ? Vgl. Jamae (2009), S. 356. 109. ? Vgl. Langner (2006), S. 442ff. 110. ? Vgl. Ihns (2004), S. 199. 111. ? Vgl. Langner (2006), S. 434. 112. ? Vgl. Jamae (2006), S. 367f. 113. ? Vgl. Langner (2006), S. 435. 114. ? 114,0 114,1 Vgl. Langner (2006), S. 437. 115. ? 115,0 115,1 Vgl. Langner (2006), S. 439. 116. ? 116,0 116,1 116,2 116,3 116,4 Vgl. Langner (2006), S. 441. 117. ? Vgl. Ordix.de (März 2007) 118. ? Vgl. Langner (2006), S. 433. 119. ? Vgl. Sneed (2003), S. 31. 120. ? Vgl. Mertins (2008), S. 160. 121. ? Vgl. Allmendinger (2002), S. 72. 122. ? Vgl. Sneed (2003), S. 31. 123. ? Vgl. Erl (2004), S. 476. 124. ? in Anlehnung an: Sun.com (November 2003), S. 14. 125. ? Vgl. Roseindia.net (o.J.) 126. ? 126,0 126,1 126,2 Vgl. Langner (2006), S. 393. 127. ? Vgl. Rupp (2007), S. 165. 128. ? Vgl. Langner (2006), S. 395. 129. ? 129,0 129,1 Vgl. Langner (2006), S. 78. 130. ? Vgl. Langner (2006), S. 99. 131. ? 131,0 131,1 Vgl. Langner (2006), S. 79. 132. ? Vgl. Langner (2006), S. 98. 133. ? 133,0 133,1 Vgl. Langner (2006), S. 112. 8 Fußnoten 42 Leistungsanalyse_JBOSS 134. ? Vgl. Jamae (2009), S. 73. 135. ? Vgl. Miles (2005), S. 2. 136. ? Vgl. Hunt (2003), S. 518. 137. ? Vgl. Jamae (2009), S. 82. 138. ? 138,0 138,1 Vgl. Jamae (2009), S. 79. 139. ? Vgl. Fleury (2006), S. 366. 140. ? Vgl. Sun.com (o.J.d) 141. ? Vgl. Marrs (2006), S. 192. 142. ? Vgl. Fleury (2006), S. 366. 143. ? Vgl. Hunt (2003), S. 527. 144. ? in Anlehnung an: Jamae (2009), S. 79. 145. ? Vgl. Burke (2006), S. 674. 146. ? Vgl. Langner (2006), S. 16. 147. ? Vgl. Marrs (2006), S. 193. 148. ? Vgl. Burke (2006), S. 674. 149. ? Vgl. Jamae (2009), S. 92ff. 150. ? Vgl. Jamae (2009), S. 102. 151. ? Vgl. Fleury (2006), S. 406. 152. ? Vgl. Jamae (2009), S. 173. 153. ? Vgl. Fleury (2006), S. 378f. 154. ? Vgl. Jamae (2009), S. 136. 155. ? Vgl. Jamae (2009), S. 79f. 156. ? Vgl. Jamae (2009), S. 81. 157. ? Vgl. Jamae (2009), S. 78. 158. ? Vgl. Hunt (2003), S. 525. 159. ? Vgl. Fleury (2006), S. 434. 160. ? Vgl. Sun.com (o.J.e) 161. ? Vgl. Jamae (2009), S. 87ff. 162. ? Vgl. Sun.com (o.J.f) 163. ? Vgl. Jamae (2009), S. 85. 164. ? Vgl. Jamae (2009), S. 90f. 165. ? Vgl. Jamae (2009), S. 90. 166. ? Vgl. Jamae (2009), S. 149. 167. ? Vgl. Jamae (2009), S. 197ff. 168. ? Vgl. Jamae (2009), S. 252ff. 9 Literatur- und Quellenverzeichnis Ahmad (2004) Allmendinger (2002) Andresen (2004) Browne (2009) Ahmad, Masroor: Der freie J2EE Application Server JBoss - Diplomarbeit zur Erlangung des akademischen Grades Diplominiformatiker (FH), Grin Verlag für akademische Texte, Fulda 2004. (ISBN-13: 978-3640068722) Allmendinger, Jutta (Hrsg.) / Hinz, Thomas (Hrsg.): Organisationssoziologie, Westdeutscher Verlag, o.O. 2002. (ISBN-13: 978-3531139999) Andresen, Andreas: Komponentenbasierte Softwareentwicklung mit MDA, UML 2 und XML, 2., neu bearbeitete Auflage, Hanser Verlag, München 2004. (ISBN-13: 978-3446229150) Browne, Paul: JBoss Drools Business Rules. Capture, automate, and reuse your business processes in a clear English language that your computer can understand, Packt Publishing Ltd., Birmingham 2009. (ISBN-13: 978-1847196064) 9 Literatur- und Quellenverzeichnis 43 Leistungsanalyse_JBOSS Burke (2006) Cachaca.de (o.J.) Cursor.de (August 2009) Dirk-Maschner.de (2006) Erl (2004) Fleury (2005) Fleury (2006) Gartner.com (September 2009) Gentsch (2004) Gnu.org (Dezember 2008) Gulp.de (Mai 2002) Heise.de (November 2003) Heise.de (März 2003) Hof (2009) Hunt (2003) Ihns (2004) It-republik.de (Januar 2005) Jamae (2009) Javamagazin.de (o.J.) Burke, Bill / Monson-Haefel, Richard: Enterprise JavaBeans 3.0, 5. Aufl., O'Reilly Media, Sebastopol 2006. (ISBN-13: 978-0596009786) o.V.: JBoss Application Server, Überblick, http://www.cachaca.de/index.php?section=130. (06.01.2010 13:55) o.V.: Systemvoraussetzungen. Cursor CRM. Perfekte Kundenorientierung, http://www.cursor.de/infomaterial/doc_download/8-systemvoraussetzungen/systemvoraussetzungen.pd (28.12.2009, 14:51) Maschner, Dirk: Persistenz und Vererbung in Hibernate Teil 1: Prinzipien,http://www.dirk-mascher.de/publikationen/mascher_hibernate_0306.pdf. (11.01.2009, 20:15 Erl, Thomas: Service-Oriented Architecture: A Filed Guide to Integrating XML and Web Services, Prentice Hall International, New Jersey 2004. (ISBN-13: 978-0131428980) Fleury, Marc / Stark, Scott / Richars, Norman: JBoss 4.0 - The Official Guide, Sams, o.O. 2005. (ISBN-13: 978-0672326486) Fleury, Marc / Stark, Scott / Richars, Norman: JBoss 4.0 - JBoss 4.0 - Das offizielle Handbuch, Addison-Wesley-Verlag, München 2006. (ISBN-13: 978-3827323194) Natis, Yefim V. / Pezzini, Massimo / Iijima, Kimihiko: Magic Quadrant for Enterprise Application Servers, http://www.gartner.com/technology/media-products/reprints/oracle/article96/article96.html. (25.11.2009, 20:17) Gentsch, Peter / Lee, Sue (Hrsg.): Praxishandbuch Portalmanagement. Profitable Strategien für Internetportale, 1. Aufl., Gabler Verlag, Wiesbaden 2004. (ISBN-13: 978-3409124546) o.V.: Why you shouldn't use the Lesser GPL for your next library, http://www.gnu.org/licenses/why-not-lgpl.html. (10.01.2010, 13:37) o.V.: Unter der Lupe: Application Server. Die Marktführer werden sich behaupten, http://www.gulp.de/kb/mk/chanpos/appserver.html. (08.01.2010, 13:46) o.V.: Java Community Process verabschiedet J2EE 1.4, http://www.heise.de/newsticker/meldung/Java-Community-Process-verabschiedet-J2EE-1-4-88867.htm (10.01.2010, 13:42) o.V.: Sun bietet JBoss J2EE-Zertifizierung an, http://www.heise.de/newsticker/meldung/Sun-bietet-JBoss-J2EE-Zertifizierung-an-76651.html. (10.01.2010, 14:01) Hof, Patrick / Liebchen, Jens: Bridging the Gap between the Enterprise and You -or- Who's the Jboss now?, in: Sicherheit in vernetzten Systemen. 16. DFN Workshop am 17. und 18. März 2009, hg. von Christian Paulsen, Hamburg 2009. (ISBN-13: 978-3837033526) Hunt, John / Loftus, Chris: Guide to J2EE: Enterprise Java, Springer Verlag, London 2003. (ISBN-13: 978-1852337049) Ihns, Oliver (Hrsg.) / Heldt, Stefan / Wirdemann, Ralf / Zuzmann, Henning: Enterprise JavaBeans komplett: Grundlagen, Überblick und Einsatz von EJB 2.1, Oldenbourg Wissenschaftsverlag GmbH, München 2004. (ISBN-13: 978-3486273793) o.V.: Umfragen: Starke Marktanteile für JBoss und Eclipse, http://it-republik.de/jaxenter/news/Umfragen-Starke-Marktanteile-fuer-JBoss-und-Eclipse-019434.htm (04.01.2010, 09:40) Jamae, Javid / Johnson, Peter: JBoss in Action. Configuring The JBoss Application Server, Manning, Greenwich 2009. (ISBN-13: 978-1933988023) o.V.: Quick Vote: Verwenden Sie JBoss?, http://javamagazin.de/itr/service/show.php3?id=189&nodeid=36&func=results&poll_id=22. (21.12.2009, 14:22) 9 Literatur- und Quellenverzeichnis 44 Leistungsanalyse_JBOSS JBoss.de (2008) JBoss.com (November 2004) JBoss.com (o.J.a) JBoss.com (o.J.b) JBoss.com (o.J.c) JBoss.org (o.J.) JBoss.org (Mai 2006) JBoss.org (2006) Langner (2006) Leonard (2009) Marrs (2006) Mertins (2008) Miles (2005) Novell.com (o.J.) Ordix.de (März 2007) Redhat.com (April 2006) Richards (2005) Roseindia.net (o.J.) Royans.net (September 2007) Rupp (2007) Sam-Bodden (2004) o.V.: Lizenzierung Info-Center - JBoss Deutschland, http://www.jboss.de/resources/licensing. (10.01.2010, 13:26) o.V.: BZ Media: Fourth Annual Java Use and Awareness Study. A BZ Research Report, http://www.jboss.com/pdf/bzresearch_study.pdf. (25.12.2009, 20:37) o.V.: JBoss Community and JBoss Enterprise, http://www.jboss.com/products/community-enterprise. (23.12.2009, 22:50) o.V.: JBoss Developer Studio 2.1 Portfolio Edition, http://www.jboss.com/products/devstudio/. (08.01.2010, 13:47) o.V.: JBoss Enterprise Application Platform Supported Configurations: JBoss Enterprise Application Platform v4.2, http://www.jboss.com/products/platforms/application/supportedconfigurations/#JEAP4.2. (25.12.2009, 20:40) o.V.: JBoss IDE, http://www.jboss.org/jbosside/. (08.01.2010, 13:48) o.V.: The JBoss 4 Application Server Guide. JBoss AS 4.0.4. Release 5, http://docs.jboss.org/jbossas/jboss4guide/r5/adminguide.pdf. (17.11.2009, 22:28) o.V.: The JBoss 4 Application Server Clustering Guide, http://docs.jboss.org/jbossas/guides/clusteringguide/r2/en/html_single. (10.01.2010, 14:27) Langner, Thorsten / Reiberg Daniel: J2EE und JBoss. Grundlagen und Profiwissen. Verteilte Enterpris Applikationen auf Basis von J2EE, JBoss & Eclipse, Hanser Verlag, München 2006. (ISBN-13: 978-3446405080) Leonard, Anghel: JBoss Tools 3 Developer's Guide. Build functional applications from scratch to serve deployment using JBoss Tools, Birmingham 2009. (ISBN-13: 978-1847196149) Marrs, Tom / Davis, Scott: JBoss at Work. A Practical Guide, O'Reilly Media, Sebastopol 2006. (ISBN-13: 978-0596007348) Mertins, Kai (Hrsg.) / Ruggaber, Rainer (Hrsg.) et al.: Enterprise Interoperability III: New Challenges and Industrial Approaches, 1. Auflage, Springer Verlag London, o.O. 2008. (ISBN-13: 978-1848002203) Miles, Russ: AspectJ Cookbook. Real-World Aspect-Oriented Programming with Java, O'Reilly Media Sebastopol 2005. (ISBN-13: 978-0596006549) o.V.: JBoss Enterprise Middleware. System Requirements, http://www.novell.com/products/jboss/sysreqs.html. (28.12.2009, 13:50) Zeller, Alexander: JBoss Clustering - Einer für alle, alle für einen, http://www.ordix.de/ORDIXNews/3_2007/Java_J2EE_JEE/clustering_jboss.html. (10.01.2010, 14:31) o.V.: Red Hat Signs Definitive Agreement to Acquire JBoss. Open source leaders agree to join to drive down the cost of developing and deploying web-enabled applications, http://www.redhat.com/about/news/prarchive/2006/jboss.html. (28.11.2009, 18:51) Richards, Norman / Griffith Jr., Sam: JBoss. A Developer's Notebook, 1. Aufl., O'Reilly Media,Sebastopol 2005.(ISBN-13: 978-0596100070) o.V.: Introduction to Web services technologies, Uses of Web Services, http://www.roseindia.net/webservices/Web-Services-technology.shtml]. (04.01.2010, 14:49) o.V.: What is scalability, http://www.royans.net/arch/2007/09/22/what-is-scalability/]. (10.01.2010, 14:14) Rupp, Heiko W.: EJB 3 für Umsteiger: Neuerungen und Änderungen gegenüber dem EJB-2.x-Standard 1. Auflage, dpunkt-Verlag, Heidelberg 2007. (ISBN-13: 978-3898644297) Sam-Bodden, Brian / Judd, Christopher: Enterprise Java Development on a Budget. Leveraging Open Source Java Technologies, Apress, New York 2004. (ISBN-13: 978-1590591253) 9 Literatur- und Quellenverzeichnis 45 Leistungsanalyse_JBOSS Sneed, Harry M. / Sneed, Stephan H.: Web-basierte Systemintegration: so überführen Sie bestehende Anwendungssysteme in eine moderne Webarchitektur, mit Online-Service zum Buch, 1. Auflage, Vieweg+Teubner Verlag, Braunschweig 2003. (ISBN-13: 978-3528058371) Stark, Thomas: J2EE. Einstieg für Anspruchsvolle, 1. Aufl., Pearson Studium, München 2004. Stark (2004) (ISBN-13: 978-3827321848) Stoyan, Robert (Hrsg.): Management von Webprojekten. Führung, Projektplan, Vertrag. Mit Beiträgen Stoyan (2004) zu IT, Branding, Webdesign und Recht, Springer Verlag, Berlin 2004. (ISBN-13: 978-3540005827) Strobel, Claus: Web-Technologien in E-Commerce Systemen, Oldenbourg Wissenschaftsverlag GmbH Strobel (2004) München 2004. (ISBN-13: 978-3486274349) o.V.: Java 2 Platform, Enterprise Edition (J2EE) FAQ, Sun.com (o.J.a) http://java.sun.com/javaee/reference/faq/j2ee.jsp#compatibility. (10.01.2010, 13:56) o.V.: Java 2 Platform, Enterprise Edition (J2EE) Overview, http://java.sun.com/j2ee/appmodel.html#2. Sun.com (o.J.b) (10.01.2010, 13:18) Sun.com (o.J.c) o.V.: JavaServer Pages Overview, http://java.sun.com/products/jsp/overview.html. (10.01.2010, 14:06) o.V.: JavaTM 2 Platform, Standard Edition, v 1.4.2 API Specification, Sun.com (o.J.d) http://java.sun.com/j2se/1.4.2/docs/api/index.html. (08.01.2010, 13:51) o.V.: JavaTM Secure Socket Extension (JSSE). Reference Guide for the JavaTM 2 SDK, Standard Sun.com (o.J.e) Edition, v 1.4.2, http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html#Features. (08.01.2010, 13:52) o.V.: keytool - Key and Certificate Management Tool, Sun.com (o.J.f) http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html. (08.01.2010, 13:52) Sun.com o.V.: Java? 2 Platform Enterprise Edition Specification, v1.4, (November 2003) http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf. (30.12.2009, 01:31) Sneed (2003) 9 Literatur- und Quellenverzeichnis 46
