Implementierung einer Referenzanwendung für den JBoss Application Server unter Verwendung der Java 2 Enterprise Edition

Inhaltsverzeichnis

1. Einleitung
1.1. Thematik und Aufbau der Arbeit
1.2. Motivation
1.3. Aufgabenstellung

2. Theoretische Grundlagen
2.1. Einführung in plattformunabhängige Programmierung
2.1.1. Die Java-Plattform
2.1.2. XML als plattformunabhängiges Datenformat
2.1.3. SQL, die Standard-Datenbank-Anfragesprache
2.2. Verteilte Anwendungen
2.2.1. Komponenten
2.2.2. Komponentenmodelle in Java
2.2.3. Alternative Komponentenmodelle
2.2.4. Vergleich der Komponentenmodelle
2.3. Softwareentwicklung für komponentenbasierte Systeme
2.3.1. Komponenten-Engineering
2.3.2. UML als Standard zur Modellierung des Entwicklungsprozesses

3. Enterprise JavaBeans
3.1. Rollenmodell bei J2EE
3.1.1. Enterprise Bean-Provider
3.1.2. Application Assembler
3.1.3. Deployer
3.1.4. EJB-Server-Provider
3.1.5. EJB-Container-Provider
3.1.6. System-Administrator
3.2. Architektur der Enterprise JavaBeans
3.2.1. J2EE-Server
3.2.2. EJB-Container
3.2.3. Programmierrestriktionen bei EJB .
3.3. Enity Beans
3.3.1. Aufbau einer Entity Bean
3.3.2. Bean Managed Persistence
3.3.3. Container Managed Persistence . .
3.3.4. Container Managed Relations
3.3.5. Client-Sicht
3.3.6. Alternativen für persistente Objekte
3.4. Session Beans
3.4.1. Stateless Session Beans
3.4.2. Stateful Session Beans
3.4.3. Client-Sicht
3.5. Message-Driven Beans
3.6. Transaktionen

4. JBoss Application Server
4.1. Architektur des JBoss
4.1.1. Java Management Extension
4.1.2. Aufbau des JBoss-Kerns
4.1.3. JBoss Interceptor-Architektur
4.2. Deployment
4.2.1. JBoss Classloading
4.2.2. JBoss Deployment-Komponenten .
4.2.3. Hot-Deployment
4.2.4. Vorgang des Deployments
4.2.5. Clustering
4.2.6. Cluster-Architektur des JBoss
4.3. EJB-Container
4.4. Webserver
4.5. JBoss-Konfiguration
4.5.1. JBoss-Standard-Konfigurationen
4.5.2. JBoss-spezifische Deployment-Deskriptoren .
4.5.3. Konfiguration für HTTPS-Verbindungen
4.6. JBoss Version 4.0
4.6.1. AOP
4.7. Werkzeuge für den JBoss Application Server
4.7.1. Ant
4.7.2. XDoclet
4.7.3. Entwickler-Werkzeuge für die JBoss-Plattform
4.7.4. Integrierte Entwicklungsumgebungen
4.8. Vergleich zwischen J2EE-Application-Servern
4.8.1. JOnAS
4.8.2. Oracle 10g und Orion Application Server .
4.8.3. BEA WebLogic 8.1
4.8.4. IBM WebSphere
4.9. Fazit

5. Referenz-Anwendung
5.1. Zielsetzung
5.2. Anwendungsfälle - UML
5.3. Aufbau, Architektur und Entwurfsmuster
5.3.1. Multitier-Anwendung
5.3.2. Entwurfsmuster: MVC 2 - Web
5.3.3. Entwurfsmuster: Session-Fassade
5.3.4. Entwurfsmuster: DTO Data Transfer Object .
5.3.5. Entwurfsmuster: UUID
5.4. Backend der Anwendung
5.4.1. Datenmodell
5.5. Web-Anwendung
5.5.1. Aufbau und Architektur der Anwendung .
5.5.2. Web-Benutzer-Interface
5.5.3. Konfiguration der Anwendung
5.6. Administrator-Anwendung
5.6.1. Architektur der Administrator-Anwendung
5.6.2. Verbindung mit JBoss
5.7. WAP-Frontend

6. Zusammenfassung und Ausblick
6.1. Zukunftsprognose
6.2. Einsatzmöglichkeiten der entwickelten Anwendung
6.2.1. Notwendige Erweiterungen für einen produktiven Einsatz
6.2.2. Die Anwendung als Beispiel zur Erstellung von J2EE Applikationen
6.3. Fazit

A. Anhang

A.1. Servlet und JavaServer Pages
A.1.1. Servlets
A.1.2. JavaServer Pages

A.2. Deployment

A.3. JBoss Management Konsole

A.4. Datenmodell der Referenzanwendung .

A.5. Konfiguration der Web-Anwendung . .

A.6. Inhalt der CD

Abbildungsverzeichnis

Tabellenverzeichnis

Quelltextverzeichnis

Listings

Literaturverzeichnis

Selbstständigkeitserklärung

Danksagung

Durch die Auswahl des Themas und die gemeinsame Bestimmung der Schwerpunkte mit meinem betreuenden Prof. Dr. Stefan Edlich, ist die vorliegende Diplomarbeit zum interessantesten Teil meines Studiums geworden.

Für die Unterstützung bei der Umsetzung möchte ich mich hiermit bei meinen Betreuern Prof. Dr. Stefan Edlich und Prof. Dr. Thomas Preuß bedanken.

Ebenfalls möchte ich mich an dieser Stelle bei meinen Kommilitonen Christian Koth, Jens Ziegler, Oliver Kalz, Andreas Graff und Mathias Meyer bedanken. Durch ihre konstruktive Kritik und ihr fachliches Wissen konnten einige Fragen, die im Verlauf der Arbeit auftraten, geklärt werden.

Meinen Eltern möchte ich für die großzügige Unterstützung während des gesamten Studiums danken.

Mark Rambow

1. Einleitung

Durch zunehmende Globalisierung und gemeinschaftliches Arbeiten bei räumlicher Tren- nung gewinnt die Vernetzung von Unternehmensanwendungen immer mehr an Bedeutung. Das World Wide Web ermöglicht den Zugriff auf die Daten von Unternehmen. Um dieser Entwicklung gerecht werden zu können ist es notwendig, Konzepte für eine Infrastruktur zu schaffen, welche die dabei auftretenden Probleme beherrschbar macht. Dieser Heraus- forderung stellen sich Unternehmen wie Sun Microsystems oder Microsoft.

In dieser Arbeit soll auf die von Sun eingeführte, Java 2 Platform, Enterprise Edition (J2EE) eingegangen werden. Um deren Vorteile nutzen zu können, wird ein Application-Server verwendet, welcher die benötigten Dienste bereitstellt. In der vorliegenden Diplomarbeit soll eine Evaluation des Open-Source-Projekt JBoss Application Server durchgeführt werden, dabei wird JBoss auch kommerziellen Produkten gegenübergestellt.

Ziel ist es, dem Leser sowohl ein Verständnis für das Erstellen von Anwendungssoftware auf Basis von J2EE zu vermitteln, als auch den JBoss Application Server detailliert und kritisch zu untersuchen.

1.1. Thematik und Aufbau der Arbeit

Diese Arbeit beschäftigt sich mit der Erstellung einer Referenzimplementierung für den JBoss Application-Server. In diesem Zusammenhang wird in die Grundlagen für die Erstel- lung von komponentenbasierten Systemen auf J2EE-Basis eingeführt, einige „best practi- ses“ in Form von Entwurfsmustern (Pattern) vorgestellt und Quellcodebeispiele zur Veran- schaulichung angeführt.

Der zweite Schwerpunkt dieser Arbeit befasst sich mit Application-Servern, speziell mit dem JBoss. Dabei wird der JBoss genau untersucht und seine Konfiguration erläutert. Um den JBoss Application Server im Markt einordnen zu können, wird ein kurzer Vergleich mit den Konkurenzprodukten durchgeführt. Es soll gezeigt werden, welche Kriterien für den Einsatz eines Application-Server sprechen und was beim Einsatz zu beachten ist.

1.2. Motivation

JBoss ist ein Open-Source Application-Servern für J2EE Anwendungen. Dadurch ist er sowohl für kosteneffizient arbeitende kleinere Unternehmen interessant, die ihn kostenlos einsetzen können als auch für große Unternehmen, die in der Verfügbarkeit des Quellcodes mehr Sicherheit für ihr Unternehmen erkennen. Durch seine große Entwicklergemeinde, die als JBoss Group gemeinsam das Projekt vorantreiben, gehört er zu den sich am schnellsten weiterentwickelnden Application-Servern.

Durch den Einsatz neuester Technologien gehen vom JBoss immer wieder Impulse aus, die ihn besonders interessant für die Untersuchung machen.

1.3. Aufgabenstellung

Die Aufgabenstellung umfasst sowohl die Erstellung einer Referenzimplementierung auf Basis des JBoss als auch die genaue Untersuchung des JBoss Application Servers. Das zu entwickelnde Programm stellt ein Beispiel für J2EE-Anwendungen dar. Sie soll nicht den Anforderungen eines Produktivsystems gerecht werden, sondern vielmehr als Studienobjekt Entwickler bei der Erstellung von J2EE-Anwendungen und dem Betrieb des JBoss Appli- cation Server unterstützen.

2. Theoretische Grundlagen

Die Basis für komplexe Anwendungen im J2EE¹ -Bereich bildet die Programmiersprache Java², auf der die Enterprise Edition aufbaut. Im Rahmen dieser Diplomarbeit kann keine vollständige Einführung in die Softwareentwicklung mit Java gegeben werden. Vielmehr geht es um die Vermittlung von Konzepten, die bei der Entwicklung von J2EE-Applikatio- nen Verwendung finden.

Weitere wichtige Grundlagen stellen die Auszeichnungssprache XML³ und die Datenbank- Anfragesprache SQL⁴ dar. In welchem Zusammenhang sie mit der Entwicklung von Enter- prise Systemen stehen, wird im ersten Abschnitt dieses Kapitels veranschaulicht. Der daran anschließende Abschnitt „Verteilte Anwendungen“ geht tiefer auf die Program- mierung mit der Java 2 Enterprise Edition ein. Es soll ein Überblick über die verfügbaren Komponenten der J2EE gegeben und diese mit anderen Modellen verglichen werden. Den Abschluss des Kapitels bildet der Abschnitt „Softwareentwicklung für komponentenbasier- te Systeme“. Hier wird auf das Softwareengineering bei J2EE Anwendungen eingegangen und es werden Standards vorgestellt, die diesen Prozess unterstützen.

2.1. Einführung in plattformunabhängige Programmierung

Unter Plattformunabhängigkeit versteht man die Unabhängigkeit einer entwickelten Soft- ware von einer spezifischen Zielplattform. In die Betrachtung müssen dabei sowohl die Hardware als auch die verwendeten Betriebssysteme einbezogen werden. Unter anderem ist dabei sicherzustellen, dass alle Datentypen den gleichen Wertebereich ausschöpfen z. B. ist der Integer-Wertebereich maschinenabhängig. Eine weitere Anpassung bezieht sich auf die Haltung von Daten im Hauptspeicher. Dieser kann als „Big-Endian“ oder „Little-En- dian“ organisiert sein. Dabei bedeutet Big-Endian, dass die Bytes in einer Speicherzelle vom höchstwertigen Byte links zum niederwertigsten Byte rechts angeordnet werden. Beim „Little-Endian“-Format, welches hauptsächlich von Intel bevorzugt wird, steht das niederwertigste Byte links, das höchstwertige Byte rechts [Cur94].

Auch der Zugriff und Austausch von Daten muss geregelt werden. Immer häufiger kommt daher eine Datenaustauschsprache zum Einsatz, die öffentlich spezifiziert wurde - XML. Auch offen gelegte Standards bei Netzwerkprotokollen helfen hier Plattformunabhängig- keit zu erreichen. Um dieses Konzept zu verwirklichen ist es erforderlich, eine Vermittler- instanz (Middleware) zwischen den Programmcode und die Zielplattform zu schalten. Mit einer solchen Middleware kann z. B. ein Java-Programm mit einem in COBOL⁵ implemen- tierten Programm auf einem Mainframe kommunizieren. Hierbei könnte z. B. CORBA⁶ als Middleware eingesetzt werden. Ein gutes Beispiel für offene Protokolle zur Kommunika- tion findet man u. a. bei den WebServices. Hier wird mittels SOAP⁷ und einer Servicebe- schreibung in XML der Zugang zu Programmen unterschiedlicher Programmiersprachen und Systeme hergestellt. Ein weiterer Ansatz, der bei portablen Programmen unterschiedli- cher Sprachen zum Einsatz kommt, ist eine Laufzeitumgebung, wie sie bei der Sprache Java oder der .NET-Sprachfamilie zu finden sind. Diese Sprachen nennt man interpretierte Pro- grammiersprachen. Im Fall von Java wird kein nativer Code erzeugt, sondern Bytecode, der von der JVM⁸ interpretiert wird. Das hat den Vorteil, dass man Programmcode auf jedem Rechner, für den eine JVM verfügbar ist, ohne Änderungen ausführen kann. Dieses Prinzip nennt Sun „Write Once, Run Anywhere“.

2.1.1. Die Java-Plattform

Als Sun 1995 die Programmiersprache Java veröffentlichte, wuchs deren Verbreitung mit der gleichzeitig wachsenden Popularität des Internets. Java setzte sich zum Ziel, die unterschiedlichsten Hard- und Softwareplattformen in der Art zu vereinen, dass Java-Programme ohne Codeanpassungen überall dort lauffähig sind, wo eine JVM installiert ist.

Die ersten Java-Programme waren Applets, die in Browsern ausgeführt und von einem Ser- ver bei Bedarf geladen wurden. Der Vorteil dieser Programme war, dass eine Oberfläche für dynamische Interaktion von Webseiten mit deren Benutzern geschaffen wurde. Oftmals wurden mit Applets jedoch auch einfach nur Webseiten, z. B. durch animierte Logos, auf- gewertet.

Die Benutzer dieser Programme können sicher sein, dass diese keinen Schaden verursachen. Java-Applets laufen in der sogenannten Sandbox ab. Das heißt, dass sie nicht auf Systemressourcen zugreifen können. Aufgrund der Applet-Technologie wird Java oft als die Sprache des Internets bezeichnet.

Doch die Java-Plattform kann weitaus mehr und entwickelt sich in rasantem Tempo wei- ter. Durch die Auslegung Javas als objektorientierte Programmiersprache mit einer Vielzahl von APIs⁹, z. B. für Netzwerkprogrammierung und Sicherheit, wurde Java unter anderem auch für Serverprogrammierung interessant. Der eigentliche Durchbruch auf diesem Ge- biet gelang Sun mit der Spezifikation von J2EE mit den Teilspezifikationen der Servlets und JavaServer Pages (vgl. A.1) sowie der Enterprise JavaBeans (EJB), die in Kapitel 3 beschrieben werden. Die Plattformunabhängigkeit half dabei der Marktdurchdringung, so dass Java eine der am häufigsten verwendeten Programmiersprachen ist.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Java und J2EE Quelle: [SM97]

Plattformunabhängigkeit - Portabilität

Erreicht wurde die Plattformunabhängigkeit Javas durch einen Zwischenschritt bei der Übersetzung des Quelltextes in einen lauffähigen Code. Statt eines Compilers, der Program- me in Maschinensprache übersetzt und so lauffähig macht, übersetzt der Java Compiler das Programm in einen maschinenunabhängigen Bytecode. Dieser kann dann in einer virtuellen Maschine ausgeführt werden. Sun bzw. deren Tochterunternehmen JavaSoft sorgen dafür, dass für die meisten Hard- und Softwareplattformen eine solche JVM verfügbar ist.

Dieses Konzept orientierte sich am aktuellen Bedarf. In einer heterogenen Landschaft wie dem Internet gab es nun die Möglichkeit, Software nicht mehr für eine bestimmte Plattform zu entwickeln, sondern für einen definierten Benutzerkreis.

Doch nicht nur reine Java-Programme und Applets sind portabel, auch andere Komponenten die in Java entwickelt wurden, so z. B. die Enterprise JavaBeans der J2EE-Spezifikation. Diese sind ohne Javacode-Anpassungen zwischen den Application-Servern unterschiedlicher Hersteller austauschbar. Geringfügige Anpassungen, die bei solch komplexen Softwaresystemen notwendig sind, werden mittels XML-Dateien konfiguriert. Diese sind ebenfalls durch ihre Repräsentation als reiner Text auf jeder Plattform bearbeitbar. Solche Anpassungen sind einfach und weniger fehlerträchtig, als die Portierung eines in C++ geschriebenen Softwaresystems von Windows auf z. B. Linux.

Die Portabilität aller Bestandteile der Java-Plattform lässt Entwickler aus einer Vielzahl möglicher Implementierungsvarianten auswählen, wodurch besser skalierbare und individueller zugeschnittene Softwaresysteme entstehen können.

Die Entwicklung der Plattformunabhängigkeit geht jedoch weiter und betrifft nicht nur die Java Softwareentwicklung. Durch die Einführung von WebServices ist mittlerweile die Inte- roperabilität zwischen sehr unterschiedlichen Rechner-Architekturen möglich, selbst wenn der WebService von einem Programm einer anderen Programmiersprache zur Verfügung gestellt wird.

Konzepte der Sprache

Die Eigenschaften Javas, wie Dynamik, Robustheit und Sicherheit, ließen aus der vermeint- lichen Internetsprache schnell eine universell einsetzbare Programmiersprache werden.

Die Objektorientierung veränderte die Art der Softwareentwicklung. Das Modellieren von komplexen Objekten entspricht viel eher der Art, wie Menschen ihre Umgebung wahrneh- men. Dieses Programmierparadigma kann als Grundlage für das neue Konzept der kom- ponentenorientierten Softwareentwicklung angesehen werden. Hierbei wird noch weiter generalisiert ohne die Möglichkeit zu verlieren, detailgenaue Abbildungen der Wirklichkeit zu schaffen.

Als völlig neu entwickelte Sprache konnte sich Java auch von einigen in anderen Sprachen existierenden Konzepten lösen, die sowohl in der Entwicklung als auch im Betrieb eines Programms zu Fehlern führen können.

Konzepte, die nicht in Java aufgenommen wurden, sind unter anderen die aus der Sprache C und C++ bekannte Zeigerarithmetik, die Mehrfachvererbung oder auch die goto-Anwei- sung, um nur einige wichtige zu nennen [Krü02].

Das Weglassen dieser Eigenschaften hatte jedoch außer einer Umgewöhnung für Umsteiger aus anderen Sprachen mehr Vor- als Nachteile. Java ist um einige Syntaxelemente ärmer als z. B. C++ und deshalb leichter zu erlernen, zum anderen ist die Sprache dadurch stabiler. Alle Speicherzugriffe werden von der JVM durchgeführt. Hierbei tritt auch der Garbage Collector als eine wichtige Eigenschaft von Java auf. Wo C-Programmierer noch selbst dafür sorgen mussten Speicher freizugeben, läuft in Java in gewissen Zeitabständen der Garbage Collector als Prozess. Dieser sucht nach nicht referenzierten Java-Objekten. Wenn ein solches Objekt gefunden wurde, wird der belegte Speicherplatz wieder freigegeben bzw. die finalize-Methode aufgerufen.

Ein Absturz eines Javaprogramms, das Auftreten eines Nullpointers oder eine andere Ausnahme wird durch die Ausnahmebehandlung¹⁰ der JVM verarbeitet und, wenn nötig, die fehlerhafte Anwendung kontrolliert beendet.

Die Ausnahmebehandlung trägt jedoch nicht nur durch das Abfangen von Fehlern zur Stabilität bei. Durch diesen Mechanismus ist es auch leichter, Fehler im Programmcode während der Entwicklung zu finden und so entsprechend auszuschließen. Dies führt dazu, dass die Programme fehlerfreier und fehlertoleranter sind.

Das Sicherheitskonzept von Java ist dafür zuständig, dass Programme und Daten nicht kom- promittiert oder von Unbefugten gelesen werden können. Zugriffe auf Daten und Ressourcen werden nur autorisierten Personen gestattet. Dieses Sicherheitskonzept wird zusätzlich durch die Java Cryptographic API unterstützt, die die Verschlüsselung jeglicher Daten er- möglicht.

Der Java Security Manager sorgt für die Verwaltung von Zugriffsrechten. Dabei kann er eingesetzt werden, um z. B. den Zugriff auf das Netzwerk oder auf bestimmte Dateien zu verhindern. Der Security Manager arbeitet mit einer Positivliste: alles was nicht erlaubt ist, ist verboten. Um den Security Manager einzusetzen, muss das Programm jedoch mit der entsprechenden Option gestartet werden [Ull03].

Applets benutzen grundsätzlich den Security Manager, der vom Browser beim Start der JVM aktiviert wird.

Da Java durch die Möglichkeit, Programmteile bei Bedarf nachzuladen, sehr oft in ver- teilten Systemen eingesetzt wird, gibt es auch einen Mechanismus, um Programm-Pakete zu signieren. Die Dateien, die dabei meist übertragen werden, sind JARs¹¹. Dies hilft dem Empfänger zu überprüfen, wessen Programmteil er empfängt, und gibt ihm die Sicherheit, dass auf dem Weg durch das Netzwerk der Bytecode nicht manipuliert wurde.

2.1.2. XML als plattformunabhängiges Datenformat

Die Extensible Markup Language (XML) entstand aus der Standard Generalized Markup Language (SGML), einem ISO-Standard¹². Nachdem SGML nicht die gewünschte Akzep- tanz fand, begann das W3C (World Wide Web Consortium) unter Mitwirkung der Industrie einen neuen Standard zu entwickeln. XML wurde sehr schnell in der Industrie angenom- men und fand eine enorm schnelle Verbreitung. Zum Ziel gesetzt hatte sich das W3C, einen Sprach-Standard zu etablieren, der es ermöglicht, Daten zu strukturieren und über das In- ternet auszutauschen. Ursprünglich war XML dazu gedacht, elektronische Publikationen zu unterstützen und so das Design von der Darstellung zu lösen (nach [Qui04]). Durch den all- gemeinen Charakter von XML lassen sich fast beliebige Daten darstellen und auch andere Auszeichnungssprachen wie HTML¹³ oder auch SVG¹⁴ damit beschreiben. Es wird jedoch noch lange dauern bis sich reine oder generierte HTML-Seiten vollständig durch XML-Seiten ersetzen lassen, die mit Hilfe von XSLT¹⁵ zum gewünschten Dokument umgeformt werden.

In XML verfasste Dokumente unterliegen den Richtlinien der XML-Spezifikation [Qui04]. Zum einen müssen XML-Dokumente wohlgeformt sein, das heißt, dass jedes geöffnete Tag¹⁶ auch durch einen „ / “ oder ein schließendes Tag terminiert werden. Tags können in- einander verschachtelt werden, wenn deren Reihenfolge dabei konsistent bleibt. Eine restriktivere Einschränkung stellt die Gültigkeit eines XML-Dokuments dar. Ein XML-Dokument ist genau dann gültig, wenn es eine DTD¹⁷ referenziert und der darin beschriebenen Grammatik entspricht.

Der folgende XML Codeabschnitt zeigt ein Beispiel der Datei jboss-web.xml eines speziellen Deployment-Deskriptors des JBoss Servers (vgl. Kapitel 3). Dieses Dokument ist wohlgeformt, da öffnende Tags in korrekter Weise geschlossen wer- den.In der ersten Zeile wird für das Dokument der Zeichensatz angegeben, hier UTF-8¹⁸. Danach wurde, mit der Angabe der DTD, der Document-Type festgelegt, der unter der angegebenen URL¹⁹ zu finden ist.

Listing 2.1: jboss-web.xml

Abbildung in dieser Leseprobe nicht enthalten

Bei J2EE-Anwendungen werden seit EJB 2.0 XML-Dateien zur Konfiguration eingesetzt. In früheren EJB-Versionen wurden zu diesem Zweck noch serialisierte Java-Objekte be- nutzt. Durch die einfachere Verarbeitung von XML lassen sich so leichter Anpassungen an den EJBs vornehmen. Auch der JBoss-Server wird mit XML-Dateien konfiguriert. Alle Einstellungen, die die angebotenen Dienste betreffen, werden in einer der Konfigurationsdateien vorgeschrieben. Auf diese Dateien wird in Kapitel 4.5 genauer eingegangen.

2.1.3. SQL, die Standard-Datenbank-Anfragesprache

Die Structured Query Language (SQL) ist die Standard-Anfragesprache für relationale Datenbanksysteme. Sie vereinigt in sich die verschiedenen Sprachen, die bei einem RDBMS²⁰ benötigt werden [HS00]:

- Data Definition Language (DDL)
- Data Manipulation Language (DML)
- View Definition Language (VDL)
- Storage Definition Language (SDL)

Die Grundlagen der Sprache wurden bereits 1974 und 1976 von IBM durch die Entwick- lung der Sprachen SEQUEL²¹ und SEQUEL2 gelegt. SQL entstand in den folgenden Jahren durch Datenbankhersteller wie Oracle. Im Jahr 1986 wurde SQL dann zum ANSI²² -Stan- dard. Durch die International Standard Organisation (ISO) wurde 1989 SQL-89 und 1992 SQL-92 standardisiert. Mit SQL-99 wurde SQL dann zu einer objektrelationalen Daten- banksprache.

Relationale Datenbanksysteme beherrschen zur Zeit den Markt, obwohl objektrelationa- le und objektorientierte Datenbanksysteme eine Zeit lang immer mehr Marktanteile bean- spruchten. Der Trend zur objektorientierten Datenbank wurde durch den Einsatz der soge- nannten Objektrelationalen Mapper gebremst (vgl. Kapitel 3.3.3). Durch die lange Tradition des Relationen-Modells ist die damit verbundene SQL jedoch nicht aus der Datenbankwelt wegzudenken. Die Verwendung von SQL in objektorientierten Systemen führt jedoch zum Impedance Mismatch, dem Bruch zwischen der Programmier- und Datenzugriffssprache. In den heutigen Zugriffsschichten für Datenbanksysteme aus objektorientierten Welten werden meist SQL-Statements generiert, um den Impedance Mismatch vor dem Nutzer zu verber- gen. Um den Übergang zu objektorientierten Datenbanken zu erleichtern bietet z.B. die postrelationale Datenbank Caché die Möglichkeit, auch mit SQL Daten zu manipulieren, zu definieren oder Anfragen zu stellen.

Im J2EE-Umfeld wird häufig eine relationale Datenbank für die Persistenz der Daten eingesetzt. Auch hier werden SQL-Statements erzeugt. Bei der Container Managed Persistence (CMP) wird dem Programmierer mit EJB-QL (vgl. Kapitel 3.3.2) eine auf der SQL-Syn- tax basierende Anfragesprache zur Verfügung gestellt, mit der Objekte aus Datensätzen des RDBMS erzeugt werden können.

Die Bedeutung von SQL lässt sich an diesen Beispielen gut erkennen. Selbst völlig neue Ansätze zur Speicherung von Daten greifen auf SQL zu oder bieten eine Anfragesprache, die sich an SQL orientiert.

2.2. Verteilte Anwendungen

In einem heterogenen Umfeld mit ständig wachsendem Bedarf an Rechenleistung, Spei- chergrösse und immer kürzeren Antwortzeiten wird das Konzept des Grossrechners zuneh- mend durch verteilte Systeme ersetzt. Diese Systeme haben einige entscheidende Vorteile [TS03]:

- Benutzertransparenz: Ein verteiltes System fühlt sich für den Benutzer an, wie ein einzelner leistungsfähiger Computer.
- Kosten: Rechenleistung im PC-Bereich wird immer günstiger. Durch den Zusammenschluss vieler günstiger Systeme ist die Rechenleistung eines Grossrechners zu einem wesentlich geringeren Preis zu verwirklichen.
- Erweiterbarkeit: Bei Leistungsengpässen und schwindenden Reserven von Speicherplatz oder anderen Betriebsmitteln können neue Systeme an das verteilte System angeschlossen werden, um die Leistung weiter zu steigern.
- Spezialisierung: Komponenten einer Software können so verteilt werden, das sie auf dem Rechner im verteilten System ablaufen, der ihnen die bestmögliche Leistung gewährleistet.
- Ausfallsicherheit: Bei einem verteilten System soll der Ausfall einer Komponente nicht das gesamte System beeinträchtigen.

Die im folgenden aufgeführten Nachteile hingegen lassen sich durch sorgfältige Planung relativieren.

Verteilte Systeme sind abhängig vom Verbindungsnetzwerk. Wenn die Netzwerkkompo- nenten unzuverlässig arbeiten, wird das Gesamtsystem beeinträchtigt. Die fortschreitende Entwicklung in der Netzwerktechnik verringert jedoch dieses Problem immer weiter. Eine weitere Aufgabe ist es, ein solches System gegen Angriffe von außen zu schützen. Es werden mehr Punkte zur Kompromittierung angeboten; die Chance, ein Sicherheitsloch zu finden, steigt. Bei verteilten Systemen, die in einem Intranet genutzt werden, um eine hohe Rechenleistung zu erbringen ist dieses Problem geringer, als beim verteilten Rechnen z. B. im Internet. Hier lassen sich aber durch virtuelle private Netzwerke (VPN) die Risiken von ungewolltem Mitlesen und Verändern des Datenverkehrs minimieren. Der Einsatz von Fire- walls und Intrusion Detection Systemen (IDS) schützt vor Einbrüchen in die Systeme und gehört mittlerweile zum Standard in Firmen- und oft auch in Heimnetzwerken. Ein weiteres Problem liegt in der Komplexität der Verwaltung eines solchen Systems. Die Software, die die Vorteile von verteilten Systemen nutzen soll, ist wesentlich komplizierter zu entwickeln, als die für monolithische Systeme. Es gibt jedoch Rahmenwerke (Frame- works), die den Entwickler hierbei unterstützen.

Im Bereich der Application-Server bieten die Serverhersteller oftmals schon die Möglich- keit zur Verteilung der Last auf mehrere Application-Server. Das so genannte Clustering bietet hierbei die Vorteile von verteilten Systemen ohne grösseren Aufwand. Software die für J2EE entwickelt wird, ist ohne große Änderungen auch in einem Cluster einsetzbar. Auf das Verteilen von Komponenten und Last wird im folgenden Abschnitt eingegangen. In Kapitel 4.2.5 wird am Beispiel des JBoss die Konfiguration eines Clusters erläutert.

2.2.1. Komponenten

„Jeder Teil einer Software wurde schon einmal implementiert, aber noch nicht von jedem.“ [Quelle: unbekannt]

Die objektorientierte Software-Entwicklung ist erprobt und hat ihre Stärken und Schwä- chen offenbart. Es wurde nach Lösungsansätzen gesucht, um die Wiederverwendbarkeit von Programmteilen zu erhöhen. Dabei hat sich auch gezeigt, dass Klassen und Objekte zu feingranular sind, um den Softwareentwicklungszyklus weiter zu beschleunigen. Oftmals werden in unterschiedlichen Softwaresystemen ähnliche Programmteile benötigt, wie z. B.

ein Datenbankzugang oder eine Benutzerverwaltung. Solch ein Programmteil besteht in der Regel jedoch aus mehreren Klassen. In Java werden solche Teilsysteme zu Paketen, den so genannten „Packages“ zusammengefasst. Um diese Programmteile einfach wiederverwenden zu können, ist es notwendig, aus solchen Paketen Komponenten zu erzeugen. Der Begriff Komponente kann wie folgt definiert werden:

„Ein Halbfabrikat bzw. eine Komponente (componentware) ist also ein abge- schlossener, binärer Software-Baustein, der eine anwendungsorientierte, se- mantisch zusammengehörende Funktionalität besitzt, die nach außen über Schnittstellen zur Verfügung gestellt wird.“ [Bal00] Eine Komponente kann also aus einer Vielzahl von Klassen bestehen, deren Funktionalität über eine Schnittstelle bereitgestellt wird. Dadurch ist es auch möglich, dass viele Komponenten miteinander interagieren können. Da Komponenten mit dem Ziel der Wiederverwendung entwickelt werden, ist es notwendig, dass alle Funktionen und Schnittstellen der Komponente ausreichend beschrieben und getestet werden.

Eine Komponente sollte klein genug sein, um sie leicht warten und herstellen und in einer Vielzahl von Systemen integrieren zu können. Sie soll aber einen Funktionsumfang bieten, der gross genug ist, um einen Vorteil durch ihre Integration zu erhalten. (vgl. [SDD02] und [DP02]).

Der Einsatz einer fertigen Komponente orientiert sich am so genannten „Blackbox Prinzip“. Das bedeutet, dass für den Einsatz und die Integration der Komponente nicht der Quelltext bzw. die Implementierungsdetails offen liegen müssen, sondern dass anhand der Schnittstellen und Funktionsbeschreibung eine Integration erfolgt. Durch das Komponenten-Paradigma lassen sich grössere Softwaresysteme effizienter zusammenstellen und entwickeln. Bei Software-Entwicklern, welche an verschiedenen Standorten arbeiten, ist eine solche Architektur notwendig. So kann jeder einen Teil der Software entwickeln, welcher der Schnittstellen- und Funktionsbeschreibung entspricht.

Komponenten steigern die Qualität einer Software. Durch gut getestete Komponenten tre- ten weniger Fehler auf und die Komplexität bei der Fehlersuche wird verringert. Wenn eine Komponente fehlerhaft ist, kann diese überprüft und berichtigt werden. Auch ist es wesentlich einfacher, neue Technologien in Komponenten-Software zu integrieren. Wenneine Komponente ein Refactoring²³ durchläuft, kann festgestellt werden, ob sie die neuesten Entwurfsmuster verwendet. Ist dies nicht der Fall, kann sie aufgrund ihrer geringeren Größe leichter auf den aktuellsten Stand der Softwaretechnik gebracht werden.

Komponenten in Geschäftsanwendungen

In verteilten Softwaresystemen gibt es eine Reihe von immer wieder auftretenden Anforde- rungen, die durch den Einsatz von Komponentenmodellen erfüllt werden können. In heuti- gen Unternehmensanwendungen steht meist eine Datenbank zur Verfügung, die Geschäfts- daten (Entitäten) enthält. Programme oder Programmteile arbeiten auf der Basis dieser Da- ten. Oftmals sind sowohl die Daten, als auch die Geschäftsprozesse über ein Netzwerk mit- einander verbunden. Die Änderungen an den Geschäftsdaten werden mit Hilfe von Transak- tionen (vgl. 3.6) gesichert und die Daten der Anwendung werden dem Nutzer ansprechend visualisiert.

Man spricht hierbei von mehrschichtigen Systemen. Moderne Anwendungen werden immer vielschichtiger. Die ehemaligen 2-Schichtsysteme (Client-Server-Systeme) werden durch 3- bis n-Schichtsysteme ersetzt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Beispiel einer Mehrschicht-Architektur

Dabei gibt es meistens eine Präsentations-, eine so genannte Geschäftslogik- und eine Da- tenhaltungs-Schicht. Die drei Hauptschichten sind oft auch physikalisch voneinander ab- gegrenzt. Das Schichtenmodell durchzieht jedoch auch die Anwendungen innerhalb der physikalischen Schichten. Bei speziellen Anforderungen kann die Anzahl der Schichten um weitere ergänzt werden. Intern sind sie oft stark gekoppelt; zu ihren korrespondierenden Schichten besteht eine schwächere Bindung. So ist der Austausch einer Schicht durch eine andere mit entsprechenden Schnittstellen möglich.

Das Komponenten-Paradigma entfaltet hier sein Potential. So ist es durch eine Analyse möglich, Komponenten in bestehenden oder neu zu entwickelnden Anwendungen zu fin- den. Komponenten können sowohl die einzelnen Schichten der Anwendung darstellen als auch bestimmte funktionale Aspekte, wie z. B. Logging, Netzwerkverbindungen oder Si- cherheit. Bei diesen funktionalen Anforderungen ist eine weitere Abstraktion, durch die aspektorientierte Programmierung möglich, die in Kapitel 4.6.1 vorgestellt wird.

Die heutigen Geschäftsanwendungen verwenden zumeist einen Application-Server, der die technischen Anforderungen eines Softwaresystems umsetzt, während die funktionalen Teile des Systems von Entwicklern individuell erstellt werden. Man spricht dabei von einer Trennung der Zuständigkeiten („separation of concerns“). Die Application-Server bieten eine Ablaufumgebung (auch Container genannt) für die funktionalen Bestandteile des Softwaresystems. Sie bieten Dienste an, die in allen Geschäftsanwendungen gleichermaßen auftreten. So z. B. Transaktionen, Sicherheitsrichtlinien, Zugriff auf Datenquellen (EIS²⁴ ) und Laufzeitverwaltung der installierten Anwendungen.

2.2.2. Komponentenmodelle in Java

Da Komponenten und Objekte viele Gemeinsamkeiten haben, definiert Java mehrere Kom- ponentenmodelle. Der erste Ansatz zu Komponenten ist bei den Applets zu finden. Diese kann man als GUI²⁵ -Komponenten in Webseiten betrachten. Applets sind keine Programme und sind nicht eigenständig ausführbar. Ein Applet wird immer in einer Ablaufumgebung, also einem Container, ausgeführt. Dieser Container kann sowohl ein Webbrowser als auch ein Applet-Viewer sein. Der Container überwacht unter anderem die Rechte des Applets (Sandbox-Prinzip) und dessen Lebenszyklus. Die Darstellung eines Applets ist immer eine vom Applet implementierte GUI. Applets werden von java.applet.Applet abgelei- tet.

Komponenten sind wiederverwendbare Softwarebausteine (vgl. 2.2.1), die über Schnittstellen Funktionen bereitstellen. Applets können aus einer Reihe von Klassen bestehen, die selbst Funktionseinheiten innerhalb des Applet-Programms darstellen. Applets können also selbst ebenfalls aus Komponenten bestehen. Dabei kann man die visuelle Komponente des Applets von seinen funktionalen Komponenten trennen.

Applets können also aus Komponenten zusammengesetzt sein und Teil anderer komponen- tenbasierter Systeme werden. Die Portabilität ist durch die Sprache Java gewährleistet. Es ist leicht, Komponenten eines Applets in anderen Programmen wiederzuverwenden. Ein ganzes Applet ist jedoch nur komplett als Komponente einer anderen Webseite wiederver- wendbar.

Ebenso ist die Anzahl der Schnittstellen die ein Applet hat sehr begrenzt. Es kann mit JavaScript²⁶ und dem Benutzer interagieren sowie auf Programm-Ereignisse und Lebenszyklusmethoden reagieren.

JavaBeans

Das erste echte Komponentenmodell, das auch als solches entwickelt wurde, ist die JavaBe- ans-Spezifikation. Sun hat sich damit zum Ziel gesetzt, das Erstellen von Softwarebaustei- nen (Komponenten) für Firmen zu ermöglichen, die diese Komponenten vertreiben können, (vgl. [SM97]).

Bei der Entwicklung des GUI-Frameworks Swing und AWT²⁷ wurden von Sun selbst JavaBeans eingesetzt. Eine kurze Definition von Sun für JavaBeans lautet: „A Java Bean is a reusable software component that can be manipulated visually in a builder tool.“ [SM97] Dies zeigt nur ein kleines Spektrum der Möglichkeiten, die man mit JavaBeans hat.

Um diese Definition zu erfüllen ist es notwendig, dass andere Programme JavaBeans un- tersuchen können. Zu diesem Zweck dient die Java Reflection-API²⁸. Mit den Reflection- Methoden ist es möglich, Objekte und Klassen zur Laufzeit zu untersuchen. Da alle Objekte von Object abgeleitet sind, steht ihnen die Methode getClass() zur Verfügung. Das Class-Objekt liefert Informationen zum Typ, den Konstruktoren, Methoden und Feldern einer Klasse. Die Attribute einer JavaBean unterliegen wohl definierten Namens-Konventio- nen. So müssen die Attribute die Sichtbarkeit private definieren. Damit sind sie nicht direkt von einer anderen Klasse zugänglich. Um die Attribute einer JavaBean dennoch ändern zu können, bekommen alle Attribute, die änderbar sein sollen, ein get/set-Methoden-Paar, das als public definiert ist. Auf diese öffentlich zugänglichen Methoden können andere Klas- sen und Programme über die Reflection-API zugreifen. Dieser Vorgang wird Introspection genannt. Die grafischen Programme zum Editieren einer JavaBean benutzen genau diese Möglichkeit. Attribute die diese Anforderungen erfüllen, werden bei den JavaBeans „pro- perties“ genannt.

Um sicherzustellen, dass alle JavaBean-Instanzen bei ihrer Erzeugung die gleichen Eigen- schaften haben, besitzen sie nur einen parameterlosen Konstruktor²⁹. Um die Beans anzu- passen werden die Properties bearbeitet. Dieser Vorgang wird als „Customizing“ bezeich- net.

JavaBeans erzeugen z. B. für jede Property ein PropertyChangeEvent bei Änderungen dieser Attribute. JavaBeans können auch eigene Events definieren, bei GUI-Komponenten sind das die AWT- oder Swing-Events.

Wie in Kapitel 2.2.1 bereits beschrieben, müssen Komponenten Interfaces besitzen, die nach außen deren Fähigkeiten anzeigen. Bei den JavaBeans sind das BeanInfo und PropertyEditor. Diese Interfaces werden explizit von grafischen Editoren genutzt (z. B. Bean Development Kit von Sun), um die Beans zu bearbeiten.

Die Spezifikation der JavaBeans verlangt auch, dass sie dauerhaft abgespeichert werden können. Dazu wird wie bei anderen Java-Klassen das Interface Serializable implementiert, wodurch die JavaBean in binärer Form dauerhaft speicherbar ist. Es besteht ebenso die Möglichkeit Beans über XML-Encoder/Decoder persistent zu machen. Wie bereits erwähnt, werden JavaBeans als GUI-Komponenten eingesetzt, z. B. als JButton oder auch als Menu- Item. Doch außer diesen „sichtbaren“ Komponenten werden auch „unsichtbare“ JavaBeans benutzt. Letztere werden z. B. in Webanwendungen verwendet um die Programmlogik zu halten oder das Datenmodell einer Seite zu kapseln. In der Beschreibung der in dieser Di- plomarbeit erstellten Anwendung im Kapitel 5.5 wird genauer auf die Verwendung von JavaBeans eingegangen.

Enterprise JavaBeans

An dieser Stelle wird nur kurz auf die Enterprise JavaBeans-Technologie eingegangen. Ein umfassender Überblick wird in Kapitel 3 gegeben.

Die Enterprise JavaBeans sind eine serverseitige Komponententechnologie der J2EE. Um EJB nutzen zu können, ist ein Application-Server notwendig, der die Ablaufumgebung bereitstellt und den Lebenszyklus der EJB überwacht. Dieser stellt eine Vielzahl von Diensten bereit, die bei Geschäftsanwendungen notwendig sind. Diese Dienste können implizit genutzt werden und müssen nicht vom Programmierer der Komponente entwickelt werden. Zu diesen Diensten zählen z. B. die Persistenz von Entity Beans. Dieser Dienst ermöglicht die Speicherung von Geschäfts-Entitäten in einem Enterprise Information System, z. B. einer relationalen Datenbank. Dies entlastet den Entwickler und sorgt für fehlertolerantere Anwendungen, da weniger funktionaler Quelltext benötigt wird.

Die Enterprise JavaBeans sind konsequent auf verteilte Systeme ausgerichtet. Sie ermöglichen über Namensdienste das Auffinden von Komponenten und Datenquellen. Dadurch ist der Einsatz von EJBs in Clustern möglich. Ein Cluster bietet verschiedene Vorteile, die in Kapitel 4.2.5 aufgezeigt werden.

2.2.3. Alternative Komponentenmodelle

Die alternativen Komponentenmodelle die hier beschrieben werden sollen, sind als Konkurrenz zu den in dieser Arbeit verwendeten Java-Komponentenmodellen zu sehen. Es soll nur ein kurzer Überblick gegeben werden, um die Java-Komponentenmodelle besser einordnen zu können und vergleichbar zu machen. Der anschließende Vergleich der Komponentenmodelle ergänzt diesen Abschnitt.

COM, COM+ und DCOM

Das von Microsoft entwickelte Component Object Model (COM) ist bereits im Jahr 1993 entstanden. Als eines der ersten Modelle für komponentenbasierte Software und durch den Marketingdruck von Microsoft wurde es zu einer führenden Komponententechnologie. COM basiert auf „Object Linking and Embedding“ (OLE) von Microsoft, das eine Kom- ponentenumgebung bietet, die jedoch noch nicht auf verteilte Komponenten eingeht. In den folgenden Jahren und Betriebssystem-Versionen von Windows wurde COM vollständig in- tegriert und bietet die Dienste, die Applikationsentwickler in Windows benötigen. Bereits damals wurden Konzepte wie Objektorientierung und Unabhängigkeit von Program- miersprachen umgesetzt. COM definiert einen Binärstandard für die erzeugten DLL-Datei- en, die mit Programmiersprachen wie C++, Delphi und sogar Java erzeugt und benutzt wer- den können (vgl. [Sch01]) .

Jedoch gab es mit COM und dem später folgenden COM+, das seit Windows 2000 eine Reihe weiterer Dienste bereitstellt, auch zahlreiche Probleme. COM fehlte die Möglichkeit Komponenten über ein Netzwerk zu verteilen. Diese Aufgabe übernahm das „Distributed Component Object Model“ (DCOM), welches die entsprechenden Dienste zur Verfügung stellte.

Eine fehlende Versionskontrolle und das systemweite Registrieren der Komponenten führ- ten zum Begriff der DLL-Hölle. Damit meint man, dass durch die Verwendung von DLLs über deren Namen geschieht, wodurch es möglich ist, dass mehrere Hersteller von Kom- ponenten eine DLL mit gleichem Namen zur Verfügung stellten. Ebenso war es für Appli- kationen schwer herauszufinden, ob die Komponente die geforderte ist und in der richtigen Version vorliegt.

Einer der größten Nachteile, der sich nach der Einführung und dem Erfolg von Java noch weiter verstärkte, war die Bindung an die Windows-Plattform. Das Portieren von WindowsAnwendungen, die als COM implementiert wurden, war gar nicht oder nur mit enormen Aufwand auf andere Systeme möglich.

.NET

Microsoft nahm sich der Problematik an und schuf .NET³⁰. Es wurde, basierend auf der COM und COM+ Architektur, eine Neuimplementierung vorgenommen und deren beste Eigenschaften übernommen. Auch die Konzepte, die Java so erfolgreich machen, wurden herangezogen. Als Konkurrenz zu Java und J2EE hat Microsoft mit .NET ein Framework entwickelt, das nicht wie Java/J2EE plattformunabhängig, sondern programmiersprachenu- nabhängig ist. Dadurch kann die Windowsplattform weiteren Ansprüchen gerecht werden. Microsoft entwickelte eine „Common Language Runtime“ (CLR) und die „Microsoft Inter- mediate Language“ (MSIL). Die CLR ist die Ablaufumgebung für alle .NET-fähigen Sprachen und verwaltet deren Speicherzugriffe, Threads, Laufzeitausnahmen, Sicherheit bzw. Rechte und das Typsystem. Die CLR vereinheitlicht für alle Sprachen die Datentypen. Mit der Entwicklung der Sprache C#³¹ erreichte Microsoft eine große Kompatibilität zu C- Code, der teilweise direkt in C# verwendet werden kann. Ebenfalls gibt es die Möglichkeit der Wiederverwendung von COM und COM+ Komponenten. Bei C++ ist es sogar möglich, „unmanaged code“ im .NET Framework ablaufen zu lassen, also Code, der weiterhin selbst das Speichermanagement und Zeigerarithmetik verwenden darf.

Doch Microsoft wollte es auch Umsteigern anderer Sprachen leicht machen, ihre Program- me für die .NET Plattform zu entwickeln. Dazu wurden Sprachen wie J#, VisualBasic.NET und sogar COBOL.NET und Haskell.NET entwickelt. Auch die Kombination verschiede- ner Sprachen innerhalb eines Assembly ist möglich. Ein Assembly ist eine Komponente in dem Sinn, dass es Schnittstellen und Metainformationen besitzt und ist eher mit JavaBeans als mit Enterprise JavaBeans zu vergleichen. Sie können zwar auch serverseitig eingesetzt werden (ASP.NET Assembly), sind jedoch kein serverseitiges Komponentenmodell.

Die MSIL ist der „kleinste gemeinsame Nenner“ aller .NET-Sprachen. Da .NET program- miersprachenunabhängig ist (die Sprachen müssen der „Common Language Specification“ CLS entsprechen), müssen alle Sprachen erst in MSIL übersetzt werden. Danach werden sie vom .NET Just in Time Compiler in Maschinencode oder Assembler übersetzt. Das heißt, dass die Programme direkt auf dem Prozessor ausgeführt und nicht interpretiert werden. Microsoft hat .NET von Anfang an auf WebServices und XML ausgerichtet. So ist XML ein integraler Bestandteil des .NET Frameworks und wird in jeder Sprache unterstützt. WebSer- vices sind für Microsoft ein wichtiger Bestandteil in .NET und dafür gedacht, mit unter- schiedlichen Komponenten, verteilt im Netz, von jedem Endgerät aus, zu kommunizieren. Als Transportprotokoll wird der Standard SOAP genutzt. Damit hat Microsoft die Möglich- keit geschaffen DCOM abzulösen. DCOM kommuniziert nicht via HTTP (Port 80) und ist daher unflexibel in komplexeren Netzwerktopologien (scheitert z. B. an den meisten Fire- walls).

Um Marktanteile, die Java in den letzten Jahren im Bereich der Enterprise Systeme gewon- nen hat, zurückzugewinnen, wurde ASP.NET entwickelt. ASP.NET ist eine Weiterentwick- lung der „Active Server Pages“, die vom „Internet Information Server“ IIS bekannt sind. Hier werden die Assemblies genau wie andere Programme in MSIL übersetzt und in eine DLL überführt, die mit Hilfe der CLR ausgeführt werden kann. Die ASP Assemblies er- zeugen als Ausgabe HTML, können aber durch ihre Zugehörigkeit zur .NET Familie auch Komponenten anderer .NET-Sprachen direkt benutzen (nach [Poh03]). Microsoft liefert für die Entwicklung mit .NET die Entwicklungsumgebung Visual Studio .NET. Prinzipiell ist das .NET Framework plattformunabhängig angelegt, jedoch liefert Mi- crosoft nur Implementierungen für die eigene Windows Produktfamilie. Mit dem MONO Projekt³² gibt es lauffähige Ansätze für die Portierung auf andere Plattformen wie Linux und Mac-OS. Jedoch sind diese bei weitem noch nicht so leistungsfähig wie .NET für Win- dows. Das liegt unter anderem daran, dass .NET keine klare Trennung zwischen dem .NET Framework und dem Betriebssystem geschaffen hat. Einige Dienste wie Transaktionsüber- wachung werden vom Betriebssystem zur Verfügung gestellt. Auch ist .NET bisher nur in Teilen bei der ISO und ECMA³³ standardisiert (nach [Gra03]).

2.2.4. Vergleich der Komponentenmodelle

Der Vergleich der Komponentenmodelle von Java/J2EE und Microsoft.NET erfolgt auf der Ebene der Geschäftsanwendungen.

Bei unternehmensweiten Anwendungen hat J2EE derzeit einen großen Vorsprung vor Mi- crosoft .NET. Dieser Vorsprung ist zum einen dadurch zu erklären, dass J2EE früher entwi- ckelt wurde, zum anderen schafft es eine andere technologische Basis. Die Plattformunab- hängigkeit bietet vielen Unternehmen größeren Entscheidungsspielraum bei der Auswahl von Betriebssystemen und Hardwareplattformen. Dies kann die .NET Plattform nicht bie- ten.

Microsoft .NET ist zugeschnitten auf die Microsoft Produktpalette, deren Betriebssysteme und die dazu passende Hardware. Ein verteiltes Komponentenmodell wurde mit .NET nicht neu eingeführt, sondern es wurde auf das COM+/DCOM Modell zurückgegriffen. Microsoft bedient eine andere Zielgruppe mit ihrer Plattform: Entwickler die seit jeher Mi- crosoft-Produkte einsetzen und die eine Bindung an den Konzern nicht scheuen. Meist ha- ben diese Firmen eine Vielzahl von Entwicklungen in COM und Webanwendungen mit ASP. Diese sind leicht in das neue .NET zu integrieren. Angesprochen werden sollen au- ßerdem Programmierer der unterschiedlichsten Sprachen, die in .NET eine gemeinsame Plattform finden können, ohne sich auf eine Sprache zu einigen.

J2EE ist bei den Komponenten für verteilte Anwendungen ein wesentliches Stück weiter. Die Enterprise JavaBeans Technologie ist speziell auf große verteilte Systeme zugeschnitten und bietet eine Vielzahl von Diensten. Eine besonders interessante Technik ist bei den En- tity Beans die Container Managed Persistenz (CMP) vgl. Kapitel 3.3. CMP ist ein Modell zum transparenten Laden, Speichern und Verändern von Daten in Informationssystemen, wie z. B. relationalen Datenbanken. Auf die weiteren Eigenschaften der EJB wird im Kapi- tel 3 eingegangen.

Doch auch Microsoft hat Eigenschaften in die .NET-Plattform integriert, die bei J2EE noch nicht genausoweit ausgereift sind. Hier ist vor allem die Unterstützung für WebServices zu nennen. Darin liegen eindeutig die Stärken der .NET-Plattform. Die konsequente Ausrich- tung auf XML und WebServices liegt zum einen daran, dass .NET noch ebenso jung ist wie die WebServices, als auch daran, dass das DCOM-Modell ersetzt werden sollte. Microsoft unterstützt nicht nur die Entwicklung von WebServices, sondern bietet z. B. mit Microsoft- Passport selbst WebServices an.

WebServices sind ein offener Standard, basierend auf dem SOAP-Protokoll, das auch mit J2EE verwendet werden kann. So gibt es z. B. mit JAXP einen XML Parser, JAXM³⁴ und SAAJ³⁵ ermöglichen die Nutzung von SOAP als Protokoll zum Nachrichtenaustausch. JAX-RPC ermöglicht, „Remote Procedure Calls“ an den WebService-Schnittstellen, die mit der WebService Definition Language (WSDL) beschrieben sind. Mit JAXR besteht Zugang zu Informationen über registrierte Webservices (UDDI³⁶ ). In der kürzlich vorgestellten Version 1.4 der J2EE sind die WebServices vollständig integriert worden.

Insgesamt kann man sagen, dass Microsoft.NET einige interessante Fähigkeiten vor allem im Desktop-Applikations-Bereich, mitbringt. Integration von XML und WebServices sind als Stärken zu nennen. Im Bereich der verteilten Anwendungen gibt es jedoch noch einigen Nachholbedarf, um die Leistungsfähigkeit von J2EE zu erreichen. Als Nachteil ist die Bindung an Microsoft zu nennen, strategische Entscheidungen bezüglich Softwarearchitekturen sind so von diesem Konzern abhängig.

Die Offenheit von Java und J2EE als unabhängige Standards bieten großen Spielraum für Weiterentwicklungen. Der Java Community Process, der für Vorschläge und Erweiterungen der Java-Standards zuständig ist, bietet die Möglichkeit, Entwicklungen mitzuverfolgen und frühzeitig Designentscheidungen treffen zu können. Ein weiterer wichtiger Faktor ist der, dass es bereits eine große Zahl an Java/J2EE Projekten gibt und viele Erfahrungen gesammelt und veröffentlicht sind. Man kann in Foren und in Büchern wesentlich mehr Informationen und Problemlösungen finden, als im Microsoft.NET Bereich.

Als Übersicht über bestimmte Eigenschaften der Plattformen soll folgende Tabelle dienen.

Tabelle 2.1.: Vergleich J2EE und .NET-Plattform

Abbildung in dieser Leseprobe nicht enthalten

2.3. Softwareentwicklung für komponentenbasierte Systeme

Die Softwareentwicklung von komponentenbasierten Systemen unterscheidet sich von der Softwareentwicklung für objektorientierte Systeme in ihrer Granularität und der Sichtweise. Da Komponenten als fertige Softwarebausteine betrachtet werden können, geht es beim Komponentenengineering vielmehr um das Zusammenspiel der Komponenten untereinander und in ihrem Systemumfeld.

Wenn Komponenten eines Systems neu geschaffen werden, muss jede dieser Komponenten den Softwareentwicklungszyklus durchlaufen. Da Komponenten nicht allzu komplex gehalten werden sollten, gestaltet sich deren Entwicklung einfacher, als die Entwicklung eines monolithischen Programms. Nach der Entwicklung müssen die Komponenten jedoch zusammengesetzt und in eine Systemumgebung integriert werden.

Notwendig ist bei Komponenten, dass eine Dokumentation und Schnittstellenbeschreibung vorliegt. Diese kann schon während der Entwurfsphase erstellt werden. Es wird angestrebt, die Schnittstellenbeschreibungen einem Standard anzupassen, um höhere Wiederverwendbarkeit zu ermöglichen.

Der nächsten Abschnitt thematisiert das Softwareengineering für komponentenbasierte Systeme. Danach erfolgt eine kurze Darstellung der Unified Modeling Language (UML), die die Modellierung von Komponenten unterstützt.

2.3.1. Komponenten-Engineering

Nach [SDD02] kann die Entwicklung von komponentenbasierter Software in verschiedene Teilbereiche untergliedert werden :

- Application Family Engineering: Dieser Prozess widmet sich der Entwicklung von Softwaresystemen für eine Gruppe von Anwendungen. Hierbei wird auf bereits vorhandene Komponenten zurückgegriffen, die an das System angepasst und integriert werden können. Am Ende des Prozesses soll ein Komponenten-Framework für die gewählte Anwendungsgruppe entstehen.
- Domain Engineering: Ziel ist es, ein Komponentensystem zu entwickeln, das explizit für eine Wiederverwendung vorgesehen ist. Es entsteht ein Architekturmodell, das für die gewählte und verwandte Anwendungsdomänen genutzt werden kann.
- Component System Engineering: In dieser Phase werden die Komponenten erstellt, deren Funktionen und Schnittstellen den gestellten Anforderungen entsprechen. Ihr Verhalten wird in der Komponenten-Spezifikation dokumentiert.
- Application Engineering: In diesem Prozess wird der größte Nutzen aus komponen- tenbasierter Software gezogen. Hier werden die entsprechenden Komponenten kon- figuriert und zusammengesetzt, um ein Softwaresystem zu erstellen. Dieser Vorgang ähnelt dem Assemblieren von Computerhardware, wo Wiederverwendung effektiv einsetzt wird.

Eine der Hauptaufgaben bei der Entwicklung von komponentenbasierten Systemen ist die Identifizierung von möglichen Komponenten. Dabei können sowohl fachliche als auch funk- tionale Komponenten gefunden und gekapselt werden. Da in heutigen Komponentenarchi- tekturen, wie sie die EJB-Technologie bereitstellt, bereits eine Vielzahl von funktionalen Komponenten integriert sind, bieten hauptsächlich die Fachkomponenten ein hohes Poten- tial für die Wiederverwendung.

Die Identifizierung der Komponenten geschieht entweder während der Entwurfsphase des Softwareengineering-Prozesses oder bei bestehenden nicht komponentenbasierten Systemen durch gezielte Analyse.

Die Erstellung eines Komponentensystems verlangt einen umfangreicheren Softwareeng- ineering-Zyklus. Die Phasen des Softwareengineering untergliedern sich laut [Bal00] in:

- Planungsphase
- Definitionsphase
- Entwurfsphase
- Implementierungsphase
- Einführungsphase
- Wartungsphase

Durch das Komponentenparadigma erweitern sich vor allem die Entwurfs-, Implementierungs- und Einführungsphase.

In der Entwurfsphase muss zusätzlich zur Architekturentscheidung (z. B. 3- oder Mehr- schicht-Modell) die Identifizierung der Fachkomponenten erfolgen. Weiterhin ist während dieser Phase die Entscheidung für oder gegen spezielle Entwurfsmuster zu treffen. Für die Entwicklung mit der J2EE werden diesbezüglich einige Vorschläge von Sun Microsystems in den „J2EE Blueprints“ [SM04a] veröffentlicht, die sich als effektiv bewährt haben. Die in dieser Arbeit verwandten Entwurfsmuster werden im Abschnitt 5.3 beschrieben. Die Implementierungsphase gestaltet sich bei Komponentensystemen ebenfalls anders als bei monolithischen Softwaresystemen. Die einzelnen Komponenten lassen sich unabhängig voneinander implementieren (unter Beachtung der Schnittstellen). Um jedoch ein lauffä- higes System zu schaffen, müssen die Applikation zusammengesetzt und entsprechende Umgebungsvariablen angepasst werden. Die J2EE-Spezifikation hat die Implementierung auf verschiedene Rollen aufgeteilt, die im Abschnitt 3.1 genauer beschrieben werden. Die Einführungsphase soll sich bei der EJB-Technologie auf das Installieren der Anwen- dung auf dem Application-Server beschränken. Dabei müssen Anpassungen in speziel- len Dateien, den „Deployment-Deskriptoren“ (siehe Abschnitt 3.2), vorgenommen werden. Durch die Standardisierung der J2EE Plattform sind Anwendungen so mit geringem Auf- wand auf unterschiedlichen Application-Servern verschiedener Hersteller lauffähig.

2.3.2. UML als Standard zur Modellierung des Entwicklungsprozesses

Die „Unified Modeling Language“ (UML) wurde von der Object Management Group (OMG)³⁷ entwickelt, die unter anderem auch CORBA eingeführt hat. UML hat sich als Standard insbesondere für die Modellierung objektorientierter Softwaresysteme durchge- setzt.

Da Komponenten in Java objektorientiert entwickelt werden (laut Definition ist eine Kom- ponente nicht zwingend objektorientiert), ist die Entwicklung mit der UML gut abgedeckt. UML bietet verschiedene Diagrammtypen an, um Klassen, Beziehungen und Abläufe dar- zustellen. Dabei wird von der Implementierung abstrahiert. Ein UML-Diagramm muss nicht jedes Implementierungsdetail darstellen aber einen guten Überblick über das System ver- mitteln.

Durch die unterschiedlichen Diagrammtypen können Klassen und Objekte aus verschiedenen Blickwinkeln betrachtet werden. So wird von einer groben Struktur bis hin zu Methoden, Attributen und Referenzen einer Klasse, alles darstellbar. Es lassen sich auch Abläufe innerhalb einer Programmsequenz (Sequenzdiagramm) modellieren.

Um die Anforderungen an eine Software zu modellieren, werden Anwendungsfall-Dia- gramme (Geschäftsprozessdiagramme) verwandt. Diese Diagramme abstrahieren so stark von der Implementierung, dass sie sich gut dazu eignen, sie mit dem Auftraggeber zu ent- wickeln. Anwendungsfall-Diagramme sind in der ersten Stufe des Entwicklungsprozesses anzusiedeln. Die folgende Abbildung zeigt ein Anwendungsfall-Diagramm eines Nutzers.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Ausschnitt der Anwendungsfälle der Referenz Anwendung

Mit der Weiterentwicklung der UML wird angestrebt, durch exakte Modellierung von Softwaresystemen aus UML Diagrammen lauffähige Programme zu erzeugen. Der Begriff „Model Driven Architecture“ bezeichnet diese Vorgehensweise. MDA ist ebenfalls ein Standard der OMG und stützt sich auf UML und andere Techniken (Meta-Object Facility MOF, Common Warehouse Meta-Model CWM).

Mit der Einführung von UML 2.0 (eine Veröffentlichung wird 2004 erwartet) sind neue Diagrammtypen und Erweiterungen für MDA und komponentenbasierte Softwareentwicklung eingeführt worden. In UML 2.0 lassen sich nun nicht nur Schnittstellen von Softwarekomponenten beschreiben, die von anderen Komponenten aus erreicht werden können, sondern ebenfalls Schnittstellen, die von einer Komponente benötigt werden und z. B. von einem Application-Server bereitgestellt werden.

Es mit UML 2.0 auch möglich, Parameter für die Deploymentdeskriptoren (siehe Kapitel 3) innerhalb eines Diagramms anzugeben und so die Installation von J2EE-Komponenten zu steuern.

UML hat sich zum Ziel gesetzt in der Version 2.0 wieder stärker von Programmiersprachen zu abstrahieren. Um spezielle Anforderungen dennoch erfüllen zu können, werden die so genannten „Profile“ benutzt. Diese UML-Profile erlauben es „Stereotypen“ zu definieren, also Klassen mit einer selbst definierten Charakteristik. Diese können sowohl Methoden als 28 2. Theoretische Grundlagen auch Attribute enthalten, wodurch z. B. die Definition von Session Beans oder Entity Beans möglich ist. Mit diesen Stereotypen lassen sich dann alle Komponenten des J2EE-Systems ausstatten und die entsprechenden Schnittstellen können in der UML dargestellt werden. Diese Aufgabe fällt dem Modellierungswerkzeug zu. Danach lassen sich die Komponenten über deren Schnittstellen verbinden.

In der folgenden Abbildung sind eine Session- und eine Entity Bean-Komponente darge- stellt, die eine Schnittstelle bereitstellen (Entity Bean) bzw. benötigen (Session Bean). Sie befinden sich in einem Artefakt, einer JAR-Datei. Zu diesem Artefakt können Eigenschaften angegeben werden, die bei J2EE in den Deployment-Deskriptoren konfiguriert werden. Im Beispiel ist das Attribut Transaction auf den Wert required zu setzen (vgl. Ka- pitel 3.6).

Das Artefakt wird auf dem JBoss Application Server Version 3.2 installiert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4: UML 2 - Diagramm (Komponenten und Deployment)

3. Enterprise JavaBeans

In diesem Kapitel wird das Enterprise JavaBeans-Komponentenmodell detailliert beschrieben. Dabei wird auf die Rollen eingegangen, die für J2EE-Entwickler bei der Erstellung von Softwaresystemen spezifiziert sind. Anschließend werden die verschiedenen EJB-Ty- pen, deren Implementierung und ihre Konfiguration in den entsprechenden DeploymentDeskriptoren beschrieben. Den Abschluss des Kapitels bildet ein Abschnitt über Alternativen für die Persistenz von EJBs und ihre Transaktionsverwaltung.

3.1. Rollenmodell bei J2EE

In der Spezifikation der Enterprise JavaBeans 2.0 [SM01a], auf die sich diese Arbeit bezieht, sind nicht nur die Implementierungsdetails der einzelnen Beantypen und Vorschriften für die EJB-Container festgelegt, sondern auch die Rollen, die bei der Erstellung von Enterprise-Anwendungen eingenommen werden.

Dabei sind die einzelnen Rollen voneinander abgegrenzt, um sie von verschiedenen Personen oder Unternehmen ausfüllen lassen zu können. Die Spezifikation der Rollen bestimmt die Eigenschaften der Endprodukte jeder einzelnen Rolle, um so die aufeinander aufbauenden Stufen bei der Enwicklung durchlaufen zu können.

Währen der Entwicklung der in dieser Arbeit in Kapitel 5 beschriebenen J2EE-Anwendung werden vom Autor alle hier beschriebenen Rollen eingenommen.

3.1.1. Enterprise Bean-Provider

Der Bean-Provider (Anbieter einer Enterprise-JavaBean-Komponente) ist für die Entwick- lung der Enterprise JavaBeans zuständig. Er entwickelt die Geschäftslogik, indem er die für einen Anwendungsteil nötigen Entitäten und Geschäftsabläufe abbildet. Dazu bedient er sich bei den dazu passenden Bean-Typen, die in Kapitel 3.2 beschrieben werden.

Da der Enterprise Bean-Provider alle Implementierungsdetails seiner Klassen und der be- reitgestellten Schnittstellen kennt, beschreibt er diese im Deployment-Deskriptor seiner Bean. Dabei werden Abhängigkeiten zu anderen Teilen der Gesamtanwendung definiert. Durch die Trennung der Zuständigkeiten ist der Enterprise Bean-Provider von technischen Aspekten der Anwendung, wie z.B. der Implementierung von Sicherheitsrichtlinien und Transaktionsverwaltung, befreit. Als Endprodukt seiner Arbeit liefert der Bean-Provider ein Java Archiv (JAR-Datei) aus, das die implementierten Klassen, Schnittstellen und den Deployment-Deskriptor seiner EJBs enthält. Bei einer Trennung der Rollen auf verschiede- ne Personen oder sogar Unternehmen, muss die JAR-Datei vom Enterprise Bean-Provider ausreichend dokumentiert werden, um die nachfolgende Arbeit des Zusammenstellens der Anwendung zu ermöglichen.

Die nachfolgenden Rollen im Entwicklungsprozess stützen sich auf die Arbeit des BeanProviders und ergänzen die notwendigen Anforderungen im Deployment-Deskriptor sowie in der Container- und Serverkonfiguration.

3.1.2. Application Assembler

Der Application Assembler benötigt für seine Arbeit ein umfassendes Wissen über die Gesamtanwendung. Er stellt aus den, von den Enterprise Bean-Providern bereitgestellten, JavaArchiven eine Anwendung zusammen. Dazu ergänzt er die mitgelieferten Deployment-De- skriptoren der einzelnen Komponenten.

Viele J2EE-Anwendungen besitzen ein Web-Interface für den Benutzer. Diese Schnittstel- len werden bei J2EE-Anwendungen überwiegend durch den Einsatz der JSP- und Serv- let-Technologie erstellt (vgl. A.1). Der Application-Assembler kann eine solche Benutzer- schnittstelle selbst erstellt haben oder eine vorhandene in die Gesamtanwendung integrie- ren.

Das Ergebnis seiner Arbeit ist ein weiteres Archiv, das die einzelnen Komponenten, das op- tionale Web-Interface und einen weiteren Deployment-Deskriptor (application.xml) enthält. Das Archiv ist eine EAR-Datei, wobei „EAR“ für Enterprise Archive steht.

3.1.3. Deployer

Der Deployer ist nun für die Installation und Inbetriebnahme der Anwendung zuständig. Dabei wird er von serverseitigen Tools des Container-Providers (siehe 3.1.5) unterstützt.

Seine Aufgabe ist es unter anderem sicherzustellen, dass alle angeforderten Datenquellen (Datenbanken, Dateien etc.) verfügbar sind. Hierbei muss er z. B. das Mapping der Entity Beans auf bereits vorhandene Datenbanken vornehmen und die in den einzelnen Kompo- nenten definierten Sicherheitsrollen konkreten Benutzern und Benutzergruppen aus der Be- nutzerverwaltung zuordnen.

Der Deploymentvorgang wird beim JBoss Application Server nicht, wie bei anderen Anbie- tern, über ein grafisches Programm unterstützt. Der JBoss benutzt einen Hot-Deployment- Mechanismus, der das Installieren der Anwendung automatisiert, wenn entsprechende Kon- figurations-Informationen vorliegen. Detailliert beschrieben wird der Hot-Deployment-Me- chanismus im Kapitel 4.2.3.

3.1.4. EJB-Server-Provider

Der Serveranbieter ist in den meisten Fällen mit dem EJB Container-Provider gleichzuset- zen. Der Server bietet die Grundlage des EJB-Containers und bietet diesem Systemdienste an. Er kümmert sich z. B. um Netzwerkverbindungen, Thread und Prozessmanagement. Der Server ist auch für das Clustering zuständig, das in Kapitel 4.2.5 am Beispiel des JBoss ver- anschaulicht wird.

3.1.5. EJB-Container-Provider

Der Container-Provider ist dafür zuständig, eine Laufzeitumgebung für Enterprise JavaBeans bereitzustellen. Der EJB-Container ist im EJB-Server installiert und nutzt dessen grundlegenden Dienste.

Die Aufgaben des Containers werden in der EJB-Spezifikation genau beschrieben. Unter anderem werden vom Container der Persistenzmechanismus angeboten, die Transaktionen bei Datenbankzugriffen überwacht und die Instanzen der EJBs verwaltet. Den installierten EJBs werden Schnittstellen zu den Containerdiensten bereitgestellt. Der Container über- wacht auch den Zugriff auf die EJBs, denn alle Aufrufe werden vom Container abgefangen und weitergeleitet. Dadurch ist es auch möglich, Sicherheitsrichtlinien auf der Server/Con- tainer-Seite durchzusetzen.

Der Container-Provider bietet die Werkzeuge an, die vom Deployer benötigt werden, um Anwendungen zu installieren und zu überwachen.

[...]

---

¹ Java 2 Platform, Enterprise Edition

² Java ist eingetragenes Markenzeichen der Sun Microsystems Cooperation

³ Extensible Markup Language

⁴ Structured Query Language

⁵ Common Business Oriented Language

⁶ Common Object Request Broker Architecture

⁷ Simple Object Access Protocol

⁸ Java Virtual Maschine

⁹ Application Programming Interface

¹⁰ Exceptionhandling

¹¹ Java Archives

¹² International Organisation for Standardization

¹³ Hypertext Markup Language

¹⁴ Scalable Vector Graphics

¹⁵ eXtensible Stylesheet Language Transformation, Eine Sprache zur Formatierung von XML Dokumenten

¹⁶ engl. Markierung

¹⁷ Document Type Definition

¹⁸ Unicode Transformation Format, 8-bit kodierte Form

¹⁹ Uniform Resource Locator

²⁰ Relational Database Management System

²¹ Structured English Query Language

²² American National Standard Institute

²³ Das Untersuchen, Verbessern und ggf. Neuimplementieren von Quelltexten, ohne dessenderen Semantik zuverändern.

²⁴ Enterprise Information System

²⁵ Graphical User Interface

²⁶ in Webseiten eingebettete, von Netscape entwickelte Skript-Sprache um dynamische Inhalte zu erzeugenoder zu modifizieren

²⁷ Abstract Windowing Toolkit, API zur Erstellung grafischer Benutzeroberflächen

²⁸ java.lang.reflect

²⁹ Durch den Aufruf des Konstruktors wird bei eine Instanz einer Klasse erzeugt

³⁰ gesprochen: DOT NET

³¹ C Sharp

³² http://www.go-mono.com

³³ European Computer Manufacturers Association

³⁴ Java API for XML Messaging

³⁵ SOAP with Attachments API for Java

³⁶ Universal Description, Discovery and Integration www.uddi.org

³⁷ http://www.omg.org