Eine XML-basierte Integration von Unternehmensanwendungen am Beispiel der Qualitätssicherung in der Automobilindustrie

Inhaltsverzeichnis

1 Einleitung

2 Enterprise Application Integration
2.1 Definition und Motivation von EAI
2.2 Aufbau von EAI-Anwendungen
2.3 EAI auf Basis von XML

3 Komponentenbasierte Softwareentwicklung
3.1 Notwendigkeit für komponentenbasierte Software
3.2 Strukturierung von Systemen

4 Technologien zur komponentenbasierten Softwareentwicklung
4.1 Enterprise JavaBeans
4.1.1 Einführung in Enterprise JavaBeans
4.1.2 Architektur und Funktionsweise von Enterprise JavaBeans
4.1.3 Bestandteile einer Enterprise-Bean
4.1.4 Arten von Enterprise JavaBeans
4.1.4.1 Session Beans
4.1.4.1.1 Grundlagen von Session Beans
4.1.4.1.2 Aufbau einer Stateful Session Bean am Bei- spiel eines Währungsumrechnungstools
4.1.4.2 Entity Beans
4.1.4.2.1 Grundlagen von Entity Beans
4.1.4.2.2 Aufbau einer Entity-Bean
4.1.4.2.3 Steuerung des Lebenszyklus
4.1.4.2.4 Container-Managed-Persistence (CMP)
4.1.4.2.5 CMP am Bespiel eines Counters
4.1.4.2.6 Bean-Managed-Persistence (BMP)
4.1.4.3 Message Driven Beans
4.1.4.3.1 Grundlagen von Message Driven Beans
4.1.4.3.2 Aufbau von Message-Driven-Beans
4.2 CORBA
4.2.1 Einführung in CORBA
4.2.2 Funktionsweise von CORBA
4.2.3 OMG-Interface Definition Language
4.2.4 CORBA Beispielanwendung
4.3 WebServices
4.3.1 Einführung in Web Services
4.3.2 Architektur und Funktionsweise von Web Services
4.4 (Distributed)COM
4.5 Bewertung und Auswahl einer Technologie für die Serverkomponenten

5 Anforderungen an einen Prototypen für XML-basiertes EAI
5.1 Beschreibung des Vorgehensmodells
5.2 Zielstellung und Rahmenbedingungen
5.2.1 Ausgangsituation
5.2.2 Verwendete Tools und Programme
5.2.3 Zielstellung der Implementierung

6 Entwurf des Prototypen
6.1 Grundlegende Architektur der Anwendung
6.2 Übersicht der Funktionalitäten
6.3 Entwurf der Klassenhierarchie
6.4 Modellierung der Datenbankstruktur

7 Darstellung ausgewählter Implementierungsaspekte
7.1 Komponentenübergreifende Realisierungsaspekte
7.1.1 Das Connection-Object als Bindeglied zwischen Datenbank und Komponenten
7.1.2 Verwaltung fortlaufender Primärschlüsselwerte
7.1.3 Kommunikation zwischen JSP und Servlets
7.2 Implementierung der User-, Anwendungs- und Rechteverwaltung
7.3 Die Anwendung zum Erstellen von Stylesheets
7.4 Die Durchführung von Transformationen
7.5 Einführung und Test sowie Ergebnisse

8 Zusammenfassung und Ausblick

Anhang

Abkürzungsverzeichnis

Selbstständigkeiterklärung

Literaturverzeichnis

Danksagung

Ich möchte mich an dieser Stelle bei allen bedanken, die mir bei der Entstehung der vorliegenden Diplomarbeit hilfreich zur Seite gestanden haben.

Ich danke Herrn Prof. Dr. Holger Hinrichs für die fachliche Unterstützung sowie die Möglichkeit diese Arbeit unter seiner Betreuung anzufertigen.

Besonderer Dank geht an die Kollegen der gedas Deutschland GmbH in Berlin. Herrn Henry Sirotenko möchte ich für die vielen guten Anregungen sowie die Betreuung dieser Arbeit als Zweitbetreuer danken. Herrn Andreas Lahrius und Herrn Jens Kersten gilt mein Dank für die zahlreichen Tipps und Hinweise die massgeblich zum Erfolg dieser Arbeit beigetragen haben.

Darüber hinaus möchte ich mich bei meinen Eltern für die Unterstützung während des gesamten Studiums ganz herzlich bedanken.

Abbildungsverzeichnis

2.1 Integration von Unternehmensanwendungen mittels Point-to-Point Schnittstellen

2.2 Integration von Unternehmensanwendungen mittels Middleware

2.3 Zusammenhang zwischen Nutzen und Änderungsaufwand in Abhängig- keit der verschiedenen Integrationsebenen [RWD99]

3.1 Abhängigkeit zwischen der Granularität von Komponenten und deren Nutzen sowie Wiederverwendbarkeit

3.2 Unterschiedliche Ausprägungen von Mehrebenenarchitekturen

4.1 Verwendung der Three-Tier-Architektur mit EJB [DP02]

4.2 Übersicht über die EJB-Architektur [GT00]

4.3 Übersicht über die Hierarchie der Enterpirse JavaBeans

4.4 Vergleich Stateless- und Stateful Session Beans

4.5 Architektur einer Session Bean [DP02]

4.6 Architektur einer Entity-Bean [DP02]

4.7 Architektur einer Message-Driven-Bean [DP02]

4.8 Object Management Architecture der OMG [GT00]

4.9 Verwendung der entstandenen Java-Klassen

4.10 Architektur von Web Services [Win01]

4.11 Funktionsweise des UDDI Dienstes

4.12 Beispielhafter Ablauf eines SOAP-Aufrufs

4.13 Kriterien zur Bewertung der vorgestellten Technologien

4.14 Bewertung der Technologien

5.1 Angestrebter Transformationsprozess

6.1 Prozess der Userinteraktion

6.2 Übersicht über die Architektur der zu entwickelnden Anwendung

6.3 Übersicht der Use-Cases des Admintools

6.4 Übersicht der Use-Cases zum Erstellen und Verwalten von Stylesheets

6.5 Übersicht der Use-Cases zum Durchführen von Transformationen

6.6 Klassendiagramm der Administrationsanwendung

6.7 Benötigte Klassen zur Durchführung sämtlicher Transformationen

6.8 Beschreibung der wichtigsten Methoden

6.9 Klassendiagramm der zu erstellenden Anwendung

7.1 Startseite im Portal nach User-Anmeldung

7.2 Ausgangspunkt für alle administrativen Tätigkeiten

7.3 Fieldmapping zum Erzeugen von XSLT-Dokumenten

7.4 Eingelesenes XML-Dokument dient als Ausgangspunkt zur Erstellung von Stylesheets

Kapitel 1 Einleitung

Seit einigen Jahren gewinnt der Begriff der komponentenbasierten Softwareentwicklung in der IT-Branche¹ mehr und mehr an Bedeutung. Der Ansatz, Software in Form einzel-ner, wiederverwendbarer Komponenten zu entwickeln, verspricht gegenüber traditioneller prozeduraler Softwareentwicklung zahlreiche Vorteile. Der wichtigste ist wohl die Mög-lichkeit, einmal entwickelte Softwarebausteine in verschiedenen Projekten verwenden zu können. Damit verbunden ist das Streben nach einer Reduzierung des gesamten Entwick-lungsaufwandes sowie der Kosten.

Eines der vielversprechensten Anwendungsgebiete für komponentenbasierte Software ist die Entwicklung von Anwendungen zur Integration von Unternehmensanwendungen (engl. Enterprise Application Integration, EAI² ). Die Zusammenarbeit zwischen den ver-schiedenen Unternehmensanwendungen wird für Unternehmen, die auf einem zentrali-sierten und globalisierten Markt erfolgreich tätig sein wollen, von unschätzbarem Wert. Nur so wird es möglich, auf sich rasch ändernde Marktsituationen angemessen und zeit-nah reagieren zu können. Dies geschieht durch die Beschleunigung und Rationalisierung der Informationsflüsse durch das Unternehmen. Aber auch die Zusammenarbeit zwischen Unternehmen kann durch EAI-Anwendungen erleichtert werden und so einen Mehrwert für alle beteiligten Partner schaffen.

Die hier vorliegende Arbeit beschäftigt sich mit der Entwicklung von wiederverwendba-rer, auf Komponenten basierter Software. Zur praktischen Umsetzung wird ein Beispiels-zenario aus der Qualitätssicherung eines deutschen Automobilherstellers verwendet. Da-bei soll ein Prototyp entwickelt werden, mit dem es möglich ist, Grafikdaten zwischen zwei Anwendungen auszutauschen. Da zum Einen die verwendeten Grafikformate auf der XML³ Syntax basieren, zum anderen XML eine wesentliche Grundlage für moderne EAI-Anwendungen bildet, soll der Focus der Arbeit darauf gelegt sein, wie XML den

2 Kapitel 1. Einleitung

Austausch von Daten zwischen Anwendungen unterstützt. Somit soll der zu entwickelnde Prototyp in der Lage sein, XML-Daten zu verarbeiten. Besonderer Wert soll dabei auf die Erstellung von Stylesheets gelegt werden, mit denen es möglich ist, die Struktur von XML-Dokumenten zu ändern.

Um eine strukturierte Einführung in den zuvor kurz beschriebenen Sachverhalt zu geben, wird im Kapitel 2 zunächst eine Einführung in das Thema EAI gegeben. Neben einer Definition wird versucht, die Gründe für die Entwicklung von EAI-Anwendungen näher zu beleuchten. Ausserdem wird sich dem allgemeinen Aufbau solcher Anwendungen ge-widmet. Abschliessend folgt ein kurzer Einblick, wie XML die Integration unterstützen kann.

Die Kapitel 3 und 4 befassen sich mit der Entwicklung komponentenbasierter Softwa-reanwendungen. Während in Kaptel 3 die Grundlagen erläutert werden, gibt das Kapitel 4 einen umfassenden Einblick in verschiedenen Möglichkeiten zur Umsetzung dieses Ansatzes. Dazu werden die Technologien Enterprise JavaBeans (EJB⁴ ), Common Object Request Broker Architecture (CORBA⁵ ), WebServices sowie das (Distributed) Component Object Model ((D)COM⁶ ) vorgestellt. Alle Technologien bieten Ansätze zur Entwicklung von Software in Komponenten. Denn Abschluss bildet ein Vergleich der vorgestellten Technologien anhand selbst gewählter Kriterien. Als Ergebnis steht die Auswahl einer Technologie, welche als besonders geeignet erscheint.

Die Abschnitte 5 bis 7 beschäftigen sich mit der prototypischen Umsetzung einer EAIAnwendung. Dazu erfolgt zunächst eine detaillierte Beschreibung der Anwendung. Ausgehend von der bisherigen Situation wird ein Überblick über die Zielstellung der Implementierung gegeben. Darauf folgend werden die Modellierung der grundlegenden Architektur sowie einige wesentliche Implementierungsaspekte näher erläutert.

Den Abschluss dieser, im Rahmen einer Diplomarbeit entstandenen Ausarbeitung bildet eine Zusammenfassung der wichtigsten Ergebnisse, sowie ein Ausblick auf mögliche Einsatzgebiete sowie Erweiterungen des entwickelten Systems.

Kapitel 2 Enterprise Application Integration

2.1 Definition und Motivation von EAI

Heutige Unternehmenslandschaften sind geprägt von einer Vielzahl an IT-Systemen. Um den unterschiedlichen Aufgaben eines modernen Unternehmens gerecht zu werden, be-darf es im allgemeinen mehrerer spezieller Softwaresysteme [Sai01]. Bisher war eine In-tegration diverser inselartiger Anwendungen sowie ein Datenaustausch untereinander nur beschränkt möglich. Dies betrifft die Kommunikation innerhalb eines Unternehmens aber auch über Unternehmensgrenzen hinweg [Nus01]. Ein bisher häufig praktizierter Ansatz zur Integration diverser Anwendungen ist die Point-to-Point Kopplung von Systemen. Dabei wird jeweils zwischen zwei beteiligten Anwendungen ein direkter Datenaustausch vorgenommen. (siehe Abb. 2.1)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Integration von Unternehmensanwendungen mittels Point-to-Point Schnittstellen

Die Nachteile einer solchen Vorgehensweise liegen auf der Hand:

- Mit Anstieg der Anwendungen steigt die Anzahl der Schnittstellen exponentiell an (Anzahl Schnittstellen = n*(n-1)/2 wobei n=Anzahl der Anwendungen)
- Wird sehr schnell unübersichtlich
- Erhöhter Aufwand bei Updates und Neueinführungen von Systemen
- Wartung ist zeitaufwendig und kostenintensiv

Ein anderer Ansatz, die Kommunikation zwischen Anwendungen zu ermöglichen, ist die Integration einer sogenannten Middleware. Dabei wird die Middleware zwischen die beteiligten Anwendungen geschaltet. (siehe Abb 2.2)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Integration von Unternehmensanwendungen mittels Middleware

Middleware-Produkte ermöglichen den Datenaustausch zwischen Anwendungen verschiedener Hersteller auch über Plattform- und Unternehmensgrenzen hinweg [WR00]. Dieser Ansatz ist einer der Kernpunkte des Vorgehens, welches heute weitläufig unter dem Begriff Enterprise Application Integration (EAI, dt. Integration von Unternehmensanwendungen) bekannt ist.

Da der Begriff des EAI etwas schwammig ist und unterschiedliche Ausprägungen und Definitionen existieren, soll im Folgenden der Versuch einer Kurzdefinition unternom-men werden. Hauptanwendungsziel einer jeden EAI-Lösung ist das Bemühen, Anwen-dungen, die nicht für eine Zusammenarbeit entworfen worden sind, dazu zu bringen, in Geschäftsprozessen zu interagieren. Eine sehr treffende Definition ist die folgende:

2.2. Aufbau von EAI-Anwendungen 5

„Unter Enterprise Application Integration (EAI) versteht man die Schaffung von betrieblichen Anwendungssystemen durch die Kombination einzelner Anwendungen unter Verwendung einer gemeinsamen Middleware. [Ruh00]“

Die wichtigsten Ziele, die mit EAI verfolgt werden, seien im Folgenden kurz aufgeführt:

- Integration von Daten, Anwendungen und Prozessen
- Kostengünstiger, sicherer und aktueller Datenaustausch zwischen Anwendungen und Unternehmen
- Steigerung von Effektivität und Effizienz durch Automatisierung von Geschäftspro-zessen
- Steigerung der Flexibilität der gesamten IT-Landschaft durch Verwendung einer Middleware und Vermeidung von Point-to-Point Verbindungen

Im Weiteren stellt sich die Frage, was die ausschlaggebenden Punkte für die Entwicklung von EAI-Lösungen waren. Die IT ist seit vielen Jahre ein immer wichtiger werdenden Faktor für die Wettbewerbsfähigkeit eines Unternehmens. Um am Markt Bestand zu ha-ben, müssen Unternehmen Produktneuerungen, -verbesserungen und -innovationen vor-stellen, ihre Time-to-Market reduzieren, Verwaltungskosten einsparen etc. Diese Punkte erfordern die Einführung neuer Geschäftsprozesse sowie eine extrem anpassungsfähige IT-Unterstützung. Verstärkt wird dieser Druck durch die zunehmende Globalisierung so-wie die verstärkte Ausrichtung auf E-Business. Dabei werden verstärkt Geschäfte über di-gitale Medien abgewickelt. Die dazu benötigten Daten müssen mit hoher Geschwindigkeit (am besten in Real-Time) bereitgestellt werden. Das EAI bietet die dafür nötigen Grund-lagen. Es fungiert dabei als eine Art Drehscheibe für Kommunikation, über die sämtliche interne und externe Kernanwendungen eines Unternehmens miteinander verbunden wer-den können [Nus01]. Im folgenden Abschnitt wird der Aufbau einer EAI-Anwendung eingehend beleuchtet.

2.2 Aufbau von EAI-Anwendungen

Nachdem die Ziele von EAI-Anwendungen beschrieben wurden, widmet sich dieser Ab-schnitt dem Aufbau und der Funktionsweise. EAI-Anwendungen bieten Integrationsmög-lichkeiten auf drei verschiedenen Ebenen: der Datenebene, der Objektebene und der Pro-zessebene. Die drei Schichten bauen aufeinander auf und ergänzen sich gegenseitig. Wie weit die Integration gehen soll, muss für jedes Unternehmen selbst entschieden werden,

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Zusammenhang zwischen Nutzen und Änderungsaufwand in Abhängigkeit der verschiedenen Integrationsebenen [RWD99] da sowohl Nutzen als auch Änderungsaufwand mit jeder Ebene steigen. Dieser Zusammenhang wird in Abbildung 2.3 verdeutlicht.

Datenebene

Die einfachste und unterste Integrationsebene ist die Datenebene. Die Aufgabe auf dieser Stufe ist die Bereitstellung von Daten in dem jeweils von einer Anwendung benötigten Datenformat. Ein aktuell viel diskutierter und verwendeter Ansatz ist der Datenaustausch mit Hilfe von XML-Dateien. Dabei werden mit Hilfe von XSL¹ -Transformationen die XML-Eingabedateien in das zuvor spezifizierte Ausgabeformat umgewandelt. Da diese Art der Integration eng mit der Datenstruktur der beteiligten Systeme verbunden ist, muss mit jeder Änderung an den Systemen auch eine Änderung an den Stylesheets erfolgen. Gerade bei Systemen die noch einer Weiterentwicklung unterliegen, kann dadurch der Aufwand ganz erheblich ansteigen. Die Integration auf Datenebene kann mit der oben bereits beschriebenen Middleware recht einfach erfolgen.

Objektebene

Auf der nächsthöheren Integrationsebene findet eine Integration in Objekten statt. Alle Daten werden als entsprechende Businessobjekte modelliert, auf denen Aktionen ausge-führt werden können. Damit sind, wie aus der objektorientierten Programmierung be-kannt, alle Daten und auf ihnen auszuführenden Methoden in Objekten gebündelt. Z.B. werden in einem Objekt „Kunde“ Datenfelder wie Kundennummer, Name, Anschrift etc. aber auch Methoden wie Kunde anlegen, löschen ändern gemeinsam erstellt.

2.3. EAI auf Basis von XML 7

Die Realisierung erfolgt über die sog. Hub-and-Spoke Architektur. Dabei dient der Hub als zentraler und intelligenter Integrationsserver, über den sämtliche Datentransporte ab-gewickelt werden. Jede Anwendung muss somit genau eine Schnittstelle zum Hub unter-stützen. Dieser wiederum ist dafür verantwortlich, die Daten in einem für die jeweilige Zielanwendung verständlichen Format bereitzustellen. Nachdem er die Daten vollständig empfangen und transformiert hat, „spricht“ (spoke) der Hub die Empfänger an und leitet ihnen die Daten weiter. Eine solche zentralisierte Lösung bringt klare Vorteile durch Ver-ringerung der administrativen Tätigkeiten und das leichte Hinzufügen und Herauslösen von Anwendungen mit sich.

Prozessebene

Um Geschäftsprozesse in einer heterogenen Landschaft systemübergreifend abzubilden, reicht eine Integration auf Daten- und Objektebene nicht aus. Vielmehr muss eine Inte-gration auf Ebene der Prozesse erfolgen. Dieser Vorgang ist bekannt als Business Process Automatisation (BPA² ) bzw. Business Process Integration (BPI³ ). Dieser Vorgang spielt eine besondere Rolle bei der Entwicklung komplexer Supply Chains, bei der Prozesse über mehrere Unternehmen hinweg aneinander angepasst und aufeinander abgestimmt werden müssen. Ziel ist eine Modellierung aus Geschäftsprozessen, Geschäftsprozess-schritten und Objekten. Dabei sollten die Geschäftsprozesse von den Anwendungen los-gelöst werden, sodass ein Wechsel der Anwendung keine Änderungen in den Prozessen nach sich zieht.

Auf der obersten Ebene der Integration ist die Realisierung am schwierigsten. Dennoch ist sie in der Lage, den gesamten Geschäftsprozess über verschiedene Anwendungen hinweg abzubilden und bietet somit den fortschrittlichsten Ansatz.

2.3 EAI auf Basis von XML

Wie in den vorherigen Abschnitten bereits erwähnt, ist ein Grundbaustein eines EAI-Systems die Integration auf Datenebene. Damit eine Kommunikation zwischen Anwen-dungen erfolgen kann, bedarf es einer plattformunabhängigen Sprache zum Datenaus-tausch. Die Lösung für diese Herausforderung war die Entwicklung der Metasprache XML durch das World Wide Web Consortium (W3C⁴ ). Dabei bietet XML die Mög-lichkeiten, Daten und Dokumente so zu beschreiben, dass ein Austausch zwischen ver-schiedenen Systemen ermöglicht wird. Dabei ist es uninteressant, ob sich die Systeme in einem Unternehmen befinden oder z.B. über das Internet aus verschiedenen Unternehmen verbunden werden [Gro03a].

Beim XML-basierten Datenaustausch zwischen Anwendungen kommt meist die o.g. Middleware zum Einsatz. Das sendende Unternehmen nutzt diese, um Daten in eine vordefinierte XML-Struktur umzuwandeln. Dies erfolgt auf einem Middleware-Layer mit Hilfe zuvor erstellter Stylesheets. Die erstellten Dokumente werden z.B. über das Internet an das empfangene Unternehmen übertragen, welches seinerseits wiederum eine Umwandlung in das von ihm benötigte Format vornimmt [Lin03].

XML erleichtert ausserdem die Integration auf Objektebene. Da jedes Dokument neben den Daten auch die Beschreibung der Daten enthält, kann eine Modellierung von Objekten automatisch erfolgen. Daneben kann durch die Erstellung von Document Type Definitions (DTD⁵ ) sichergestellt werden, dass nur gültige Dokumente generiert werden. Somit wird während des Transformationsprozesses die Identifikation und Prüfung auf Gültigkeit der Daten erleichtert [RWD99].

Zusammenfassend lässt sich sagen, dass der Einsatz von XML in EAI-Anwendungen vie-le Vorteile beim unternehmensweiten und unternehmensübergreifenden Datenaustausch mit sich bringt. Die Pflege von Geschäftsbeziehungen zu Partnerfirmen über das Inter-net kann automatisiert und somit schnell und fehlerfrei erfolgen. Zwei Beispiele aus der Praxis untermauern diese These: Intel konnte durch die Einführung von RosettaNet (ein auf XML basierendes Datenaustauschformat) seine Bearbeitungszeiten für die Annah-me eines Kundenauftrages von 12 Stunden auf wenige Minuten reduzieren [Int03]. Der Flugzeughersteller Boeing konnte mit Hilfe von XML seine vorhandenen 18 Beschaf-fungssysteme auf 4 reduzieren [Fox03].

Kapitel 3 Komponentenbasierte Softwareentwicklung

3.1 Notwendigkeit für komponentenbasierte Software

Ein in der Informatik lange verfolgtes, dennoch bis heute nicht erreichtes Ziel ist die Entwicklung von Softwaresystemen ohne dabei immer wiederkehrende Probleme neu lö-sen zu müssen. Dieser Ansatz gewinnt gerade bei den EAI-Anwendungen immer mehr an Bedeutung. Ein weiterer Schritt in die richtige Richtung ist die Softwareentwicklung auf Basis einzelner Komponenten, die zu einem Gesamtsystem zusammengesetzt wer-den. Komponenten können als Bausteine zur Lösung einer speziellen Aufgabe angesehen werden.

„A component is a piece of software small enough to create and maintain, big enough to deploy and support, and with standard interfaces for interoperability.“

Jed Harris, Präsident der CI Labs

Nach aussen sollen von einer Komponente lediglich die Signaturen, d.h. Parameter und Rückgabewerte, nicht aber realisierungstechnische Aspekte sichtbar sein. Diese Herangehensweise ist unter dem Begriff der Kapselung bereits aus der objektorientierten Programmierung bekannt.

Die komponentenbasierte Softwareentwicklung bringt eine Reihe von Vorteilen mit sich:

- Komponenten können so entwickelt werden, dass eine Wiederverwendung ermög-licht wird
- Die Entwicklung eines komplexen Systems kann einfacher auf mehrere kleine Teams mit konkret abgegrenzten Zuständigkeitsbereichen aufgeteilt werden
- Entwickelte Systeme bleiben offen, sodass sie mit relativ geringem Aufwand um weitere Funktionalitäten (Komponenten) erweitert werden können
- Durch die Kombination von Komponenten verschiedener Hersteller sinkt die Abhängigkeit von jedem einzelnen Hersteller
- Durch die Wiederverwendung von Komponenten wird die Softwareentwicklung insgesamt kostengünstiger
- Die Verteilung auf mehrere Systeme wird erleichtert. (siehe nachfolgender Ab-schnitt)

Neben den Vorteilen sollen auch die auffälligsten Nachteile kurz Erwähnung finden:

- Wenn die Aufteilung der Komponenten zu fein gewählt wird, steigt die Kommu-nikation zwischen ihnen, womit zwangsläufig die Performance des Gesamtsystems sinkt
- Eine schrittweise Umstellung von Altsystemen ist nur schwer möglich, da bei diesen entsprechende Schnittstellen meist fehlen und somit eine Integration neuer Systeme in eine bestehende Systemarchitektur erschwert wird

Eine wesentliche Frage, die bei der Entwicklung von Komponenten zu klären ist, ist die nach der Granularität der Komponente. Davon direkt abhängig sind der Nutzen und die Wiederverwendbarkeit. Diesen Sachverhalt spiegelt Abbildung 3.1 wieder.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Abhängigkeit zwischen der Granularität von Komponenten und deren Nutzen sowie Wiederverwendbarkeit

Wie aus der Abbildung zu erkennen ist, können grössere und komplexere Komponenten (mit geringer Granularität) nur selten verwendet werden. Wenn es aber ein Einsatzge-biet gibt, dann ist der Nutzen um so grösser. Im jeweils aktuellen Anwendungskontext bleibt zu klären, in welcher Form eine Aufteilung in Komponenten als sinnvoll erscheint. Dennoch sollte jede Komponente die folgenden Eigenschaften besitzen [GT00]:

- Eine Komponente soll ganze Geschäftsobjekte kapseln und die Geschäftslogik auf diesen Objekten realisieren
- Eine Komponente soll möglichst komplette Transaktionen eines Geschäftsobjektes implementieren
- Eine Komponente ist anwendungsunabhängig und einzeln lauffähig

3.2 Strukturierung von Systemen

Mit der Einwicklung auf Basis von Komponenten, wie sie im vorherigen Abschnitt be-schrieben wurde, entsteht eine Architektur, die ein System aus einer Menge von Baustei-nen zusammensetzt. Obwohl diese Einteilung hauptsächlich den Prozess der Software-entwicklung erleichtern soll, ergibt sich ein weiteres Einsatzgebiet. Durch Komponenten, welche die gesamte Funktionalität in sich kapseln, entsteht die Möglichkeit Systeme über mehrere Rechner zu verteilen. Dies wird durch die Entwicklungen und Fortschritte der letzten Jahrzehnte im Bereich der Rechenleistung und Netzwerktechnik unterstützt.

In diesem Zusammenhang erfolgt eine Verteilung der Komponenten über eine sog. Multi-Ebenen-Architektur. Von jeder Ebene (auch: Schicht engl.: Tier) sollen nur die Menge aller öffentlichen Schnittstellen, nicht aber implementierungstechnische Aspekte sicht-bar sein. Eine Änderung in einer Schicht sollte möglichst keine Änderungen in darüber oder darunter liegenden Schichten nach sich ziehen. Anders als bei der Kommunikation zwischen Rechnern, die über das ISO/OSI¹ - Referenzmodell definiert wird, hat sich im Bereich der Strukturierung von Systemen über Schichten bisher kein Modell durchsetzen können. Vielmehr existieren diverse Ansätze, von denen die 4 wichtigsten im Folgenden kurz erläutert werden sollen.

Wie in Abbildung 3.2 zu sehen ist, liegen die Hauptunterschiede in der Anzahl der Schichten im Referenzmodell.

One-Tier-Architektur

Das klassische Einzelplatzsystem basiert zumeist auf einer Architektur mit nur einer Schicht. Der Zugriff auf die Datenbank ist direkt in die Präsentationsschicht integriert. Diese Architektur ist hauptsächlich in kleineren Anwendungen zu finden, kann aber durch eine gemeinsame Datenbank mehrplatzfähig gemacht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Unterschiedliche Ausprägungen von Mehrebenenarchitekturen

Two-Tier-Architektur

Ein erster Ansatz zur Multi-Tier-Architektur ist die Ausgliederung der Anfragen an die Datenbank. Dadurch kann bei komplexen Vorgängen der Netzwerkverkehr stark eingeschränkt werden. Das eigentliche Erstellen der Datenbankabfrage ist mit der Geschäftslogik weiterhin gemeinsam in der Präsentationsschicht integriert. Lediglich der Anfragestring wird an einen Datenbankserver weitergeleitet, welcher nach der Bearbeitung die Ergebnisse zurückliefert. Somit ist es möglich, einen separaten Datenbankserver aufzusetzen, um Performancevorteile zu erzielen.

Three-Tier-Architektur

In der Drei-Schichten-Architektur erfolgt eine strikte Trennung zwischen Datenbank, Ge-schäftslogik und Präsentationsebene. Dabei kann jede dieser Schichten auf einem anderen Rechner angesiedelt sein. Somit ist es möglich, für jede Schicht die am besten geeigne-te Hardware zu wählen. Die Geschäftslogik läuft auf dem Applicationsserver. Als Da-tenbankserver kann ein Mainframe Computer zum Einsatz kommen. Die Präsentations-schicht liegt auf einem Web-Server. Dies ist das zur Zeit am meisten verbreitete Modell.

Four-Tier-Architektur

In der Vier-Ebenen-Architektur erfolgt aus Sicherheits- und Skalierbarkeitsgründen eine Verteilung der Business-Logic über zwei Ebenen. Dabei wird unter die Präsentations-schicht ein Webserver geschaltet. Dieser nimmt die Anfragen vom Benutzer entgegen und leitet sie an die Applikationsschicht weiter. In dieser wird wiederum die eigentliche Business-Logic ausgeführt. Auch dieser Ansatz wird in der Praxis häufig verwendet.

Obwohl zwischen der komponentenbasierten Softwareentwicklung und der Strukturierung von Software über Schichten enge Zusammenhänge bestehen, lassen sich einige klare Unterschiede herausstellen:

- Komponenten können horizontal und vertikal (über Schichten und verteilt über Rechnergrenzen hinweg), Schichten nur horizontal gegliedert werden

3.2. Strukturierung von Systemen 13

- Komponenten realisieren eine in sich abgeschlossene Funktionalität auf Ebene der Businessobjekte, eine vollständige Schicht aus der Architektur zu implementieren macht dagegen wenig Sinn
- Komponenten sind flexibler

Kapitel 4 Technologien zur komponentenbasierten Softwareentwicklung

Nachdem im vorherigen Abschnitt bereits von komponentenbasierter Software und MultiTier-Architekturen die Rede war, soll sich der folgende Abschnitt mit den konkreten Technologien zur Umsetzung dieser Ansätze beschäftigen. Zunächst wird das Thema Enterprise JavaBeans behandelt. Im Abschnitt 4.2 geht es dann um denn Standard CORBA von der Object Management Group (OMG¹ ). Abschnitt 4.3 ist den Web Services gewidmet, Abschnitt 4.4 dem von Microsoft entwickelten (D)COM.

4.1 Enterprise JavaBeans

4.1.1 Einführung in Enterprise JavaBeans

Enterprise JavaBeans (EJB) sind eine Spezifikation von Sun Microsystems. Sie ordnen sich in das Enterprise Konzept von Sun ein und werden als ein Komponentenmodell für die Entwicklung und Distribution von serverseitigen Java-Komponenten bezeichnet. Sie sollen die Entwicklung von verteilten, komponentenbasierten Java-Anwendungen erleich-tern.

Wird versucht, die EJB’s in die im Abschnitt 3.2 vorgestellten Schichtenarchitekturen ein-zuordnen, würde man sie der Drei- bzw. Vier-Schichten-Architektur zuordnen. Abbildung 4.1 zeigt den möglichen Aufbau einer Bean.

Client Schicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1: Verwendung der Three-Tier-Architektur mit EJB [DP02]

Die Client-Schicht übernimmt die Präsentation und Darstellung der Daten. In dieser Ebe-ne kommen hauptsächlich HTML², JavaScript und JSP³ zum Einsatz. Innerhalb einer Four-Tier-Architecture kann die Client-Schicht in zwei Schichten unterteilt werden, dann laufen HTML und JavaScript im Browser des Users, JSP’s auf einem Webserver. Seitens des Clients können die Beans über das Java Naming and Directory Interface (JNDI⁴ ) auf-gefunden werden. Die Erzeugung neuer Bean-Instanzen erfolgt über RMI⁵ oder CORBA.

Anwendungsschicht

Die Anwendungsschicht hält die eigentliche Business-Logic einer Anwendung vor. In dieser Schicht arbeiten die Beans, welche wiederum über z.B. JDBC⁶ auf die Datenebene zugreifen können.

Datenebene

Auf der Datenebene arbeiten meist relationale Datenbankmanagementsysteme (DBMS⁷ ). In ihnen werden alle zu einer Anwendung gehörenden Daten gehalten.

4.1.2 Architektur und Funktionsweise von Enterprise JavaBeans

In diesem Abschnitt soll die Architektur der Enterprise JavaBeans sowie die Einordnung in das Enterprise Konzept von Sun näher beleuchtet werden. Wie Abbildung 4.2 zeigt, exi-

4.1. Enterprise JavaBeans 17

stieren drei grundlegend unterschiedliche Typen von Beans: Entity Beans, Session Beans sowie Message Driven Beans. Client Programme sind in der Lage, über das Home- bzw. Remote-Interface auf die Beans zuzugreifen und die in ihnen implementierte Geschäftslogik zu nutzen. Jede Bean läuft in einem EJB-Container, welcher seinerseits Dienste für die Bean bereitstellt (z.B. Datenbankzugriff über JDBC, Zugriff auf Transaktionsdienst über JTA⁸, Zugriff auf Messaging-Service über JMS⁹ etc.). Die beteiligten Komponenten sollen im Anschluss kurz erläutert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.2: Übersicht über die EJB-Architektur [GT00]

EJB-Container

Der EJB-Container ist ein Herzstück der EJB-Architektur. Er bildet die Laufzeitumge-bung für Enterprise Bean Komponenten und stellt ihr die wichtigsten Dienste zur Verfü-gung. In Anlehnung an die EJB-Spezifikation in der Version 2.0 muss jeder Container den Beans min. folgende Dienste über Programmierschnittstellen (eng. Application Programming Interface API¹⁰ ) zur Verfügung stellen [DM01]:

- API der Java 2 Plattform, Standard Edition (J2SE¹¹ )
- API der Enterprise JavaBeans Spezifikation 2.0
- API des JNDI 1.2
- API des UserTransaction Interfaces 1.0.1 aus Java Transaction Interface
- API der JDBC 2.0 Erweiterung
- API von JavaMail 1.1 (nur für das Versenden von Mails)
- API von Java XML Parser (JAXP)

Das Bereitstellen dieser Interfaces ermöglicht dem Bean-Entwickler, sich auf seinen eigentlichen Geschäftsablauf zu konzentrieren, den er zu implementieren hat. Ausserdem ist sichergestellt, dass eine Bean auf jedem Server funktionsfähig ist und auf Anfragen des Clients immer mit dem gleichen Verhalten reagiert.

Zur Laufzeit ist der Container ausserdem für die Verwaltung des Lebenszyklus einer Bean verantwortlich. Nach Aufforderung eines Clients erzeugt der Container die entsprechen-de Bean. Da der Container aus Performancegründen die Bean nicht bereit halten kann bis sie wieder benötigt wird, gibt es das sog. Instanzenpooling. Gerade im Bereich der Businessanwendungen, in denen viele Clients gleichzeitig auf eine Anwendung zugreifen ist dies unumgänglich. Wird eine Bean längere Zeit nicht benötigt, kann sie deaktiviert (Zustand ist dann pooled) und in einen Pool gesetzt werden. Verlangt ein Client wieder einen Zugriff auf diese Bean wird sie wieder aus dem Pool geholt (Zustand ist nun wieder ready) und dem Client zur Verfügung gestellt. Ist der Pool voll bzw. bei einer Bean ein be-stimmter Zeitzähler abgelaufen (das Handling ist abhängig vom Applicationserver), kann eine Bean serialisiert werden. Da dieses Vorgehen jedoch abhängig vom Typ der Bean ist, soll darauf in den entsprechenden Abschnitten näher eingegangen werden.

J2EE-Server

Der Server bietet seinerseits wiederum die Laufzeitumgebung für die Container an. Er stellt allerdings nicht nur die Umgebung für JavaBean-Komponenten sondern auch für andere Komponenten aus dem J2EE¹² Umfeld bereit. Dabei hat der Server grundlegende Funktionalitäten anzubieten [DP02]:

- Thread- und Prozessmanagement (zur Unterstützung mehrerer gleichzeitig laufender Container)
- Clustering und Lastverteilung bei Anwendungen, die über mehrere Systeme verteilt sind
- Namens- und Verzeichnisdienst zum Auffinden von Komponenten

Wie diese Dienste angeboten werden, bleibt den Herstellern der Server überlassen. Eine Reglementierung innerhalb der EJB-Spezifikation erfolgt nicht.

Namens- und Verzeichnisdienst

Damit die Clients in der Lage sind, die Beans innerhalb ihrer Umgebung zu finden, sind sie auf einen Namensdienst angewiesen. Während des Bindings wird ein Name einer Re-ferenz auf ein entferntes Objekt zugewiesen. Der Client kann nun im Prozess des Lookup das Objekt wiederfinden, ohne dass er tatsächlich weiss, auf welchem Rechner es sich befindet. Der Namens- und Verzeichnisdienst wird im J2EE Kontext über das JNDI ange-sprochen.

Neben den Clients sind auch die Beans in der Lage, mit Hilfe von JNDI auf Ressourcen zuzugreifen. Damit ist eine Bean z.B. in der Lage, auf Ressourcen wie Datenbankver-bindungen zuzugreifen. Somit ist es beispielsweise möglich, eine Anwendung auf ein anderes DBMS umzustellen, ohne auch nur ein Stück Quellcode der Beans zu ändern.

Messagingdienst

Die letzte wichtige Komponente die hier kurz angesprochen werden soll, ist der Java Mes-saging Service (JMS). Er kommt vorwiegend bei den Message Driven Beans zum Einsatz, die später noch eingehender behandelt werden. Clients können dabei Nachrichten asyn-chron versenden, wobei Empfänger und Absender einer Nachricht jeweils anonym blei-ben. Allerdings können nicht nur Clients im herkömmlichen Sinne Nachrichten versen-den. Auch eine Kommunikation zwischen verschiedenen JavaBeans ist möglich. Damit lassen sich Prozesse voneinander entkoppeln und „echte“ verteilte Systeme erstellen.

4.1.3 Bestandteile einer Enterprise-Bean

Eine Bean setzt sich aus folgenden 5 Komponenten zusammen. Wobei zu beachten ist, dass nicht jede Bean jede dieser Komponenten besitzt/besitzen muss. Auf die Besonder-heiten der einzelnen Beanarten wird in den nächsten Abschnitten noch näher eingegangen.

Bean-Klasse

Die eigentliche Implementierung der Funktionalität einer Bean erfolgt in der BeanKlasse selber. Jede Enterprise Bean muss, abhängig von ihrem Typ, ein bestimmtes Interface implementieren (javax.ejb.EntityBean, javax.ejb.SessionBean, javax.ejb.MessageDrivenBean).

In Anlehnung an die EJB-Spezifikation sind während der Implementierung der Beanklasse gewisse Restriktionen einzuhalten. Die wichtigsten sind [DM01]:

- Eine Enterprise-Bean darf keine Klassen aus java.io benutzen, um auf das Dateisystem zuzugreifen
- Eine Enterprise-Bean darf keine Funktionalitäten des Abstract Windowing Toolkit (AWT¹³ ) benutzen
- Eine Enterprise-Bean darf keine Threads starten oder stoppen

Home-Interface

Das Home-Interface wird von der Klasse javax.ejb.EJBHome abgeleitet. Es steuert den Lebenszyklus einer Bean. Benötigt werden dafür u.a. die Methoden zum Erstellen (create()) und Löschen (remove() - muss nicht separat deklariert werden) sowie zum Auffinden (findByPrimaryKey(), findByName()) einer Bean.

Remote-Interface

Im Remote-Interface werden alle Methoden definiert, die die Bean nach aussen zur Verfügung stellt. Die Summe der Geschäftsmethoden stellt damit die Funktionalität der Bean dar. Es muss von javax.ejb.EJBObject abgeleitet werden, welches seinerseits wieder von java.rmi.Remote abgeleitet ist.

Primärschlüsselklasse

Der Primärschlüssel ist nur bei Entity-Beans von Bedeutung und dient dazu, eine Enti-tät von einem bestimmten Typ eindeutig zu identifizieren. Ähnlich dem Primärschlüs-sel einer Datenbanktabelle kann darüber eine Entity-Bean im Container des Servers gefunden werden. Ist gibt zwei Arten von Primärschlüsseln. Zum einen Schlüsselwer-te, die durch eine Java-Standard-Klasse definiert werden (java.lang.String oder java.lang.Integer) und solche, die einen zusammengesetzten Wert aus mehreren Daten haben. Dieser wird i.a. über eine eigens dafür entwickelte Klasse repräsentiert.

Deployment-Deskriptor

Der Deployment Deskriptor ist eine XML-Datei der eine oder mehrere Beans beschreibt. Er enthält Daten, die nicht im Code der Bean abgelegt sind. Dazu gehören Informationen

4.1. Enterprise JavaBeans 21

zu JNDI Namen und Referenzen, Informationen zur Persistenz (bei Container Managed Persistence (CMP¹⁴ ) bei Entity Beans) sowie Informationen über das Laufzeitverhalten der Komponente.

4.1.4 Arten von Enterprise JavaBeans

In diesem Abschnitt soll sich den einzelnen Arten von Enterprise JavaBeans gewidmet werden. Die folgende Grafik zeigt die Hierarchie der Beantypen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.3: Übersicht über die Hierarchie der Enterpirse JavaBeans

4.1.4.1 Session Beans

4.1.4.1.1 Grundlagen von Session Beans

Der erste Typ von EJB, der hier näher untersucht werden soll, sind die Session Beans. Sie implementieren im Allgemeinen die Logik eines Geschäftsprozesses. Dabei erfüllen sie die Aufgabe der Interaktion zwischen anderen Beans. Sie repräsentieren keine Daten in der Datenbank, sind aber in der Lage, auf diese zuzugreifen. In der Praxis werden Session Beans häufig für Aktionen verwendet, die sich auf mehrere Entity-Beans auswirken, z.B. die Buchung einer Reise. Die Session-Bean stellt dabei die Kommunikation zwischen den möglichen Entity Beans Hotel, Flug, Kunde etc. sicher.

In Bezug auf die Eigenschaft, sich den momentanen Zustand zu merken, werden bei Session Beans grundsätzlich zwei Arten unterschieden:

Stateless Session Bean

Zustandlose Session Beans sind leichtgewichtige und effiziente Beans, da sie weder einem bestimmten Client zugeordnet sind, noch grosse Mengen an Server-Ressourcen verbrau-chen. Da sie keinen Zustand (Conversational-State) verwalten, kann eine einzelne Instanz von mehreren Clients verwendet werden. Demnach existiert immer eine create()-Methode ohne Parameter. Somit müssen alle variablen Werte, die die Bean zum Ausfüh-ren einer Aktion benötigt, über die Parameter der jeweiligen Methode übergeben werden. Methodenübergreifend können Ergebnisse nicht verwendet werden, womit eine komplette Aufgabe immer innerhalb eines einzelnen Methodenaufrufs abgeschlossen werden muss.

Stateful Session Bean

Eine weitere Art der Session Beans sind die zustandbehafteten Session Beans. Diese werden über ihre gesamte Lebensdauer hinweg einem bestimmten Client zugeordnet. Im Gegensatz zu den zustandlosen besitzen die zustandbehafteten Session Beans einen Conversational-State. Sie sind damit in der Lage, sich Ergebnisse aus Berechnungen zu merken und sie in weiteren Methoden wieder zu verwenden. Eine Möglichkeit, der Bean konkrete Eigenschaften zu geben, ist die Parametrisierung der create()-Methode.

Zusammenfassend folgt eine Gegenüberstellung der beiden Arten von Session Beans:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.4: Vergleich Stateless- und Stateful Session Beans

4.1.4.1.2 Aufbau einer Stateful Session Bean am Beispiel eines Währungsumrechnungstools

Die einzelnen Interfaces und Methoden, die ein Entwickler implementieren muss, be-vor ein Client auf eine Bean zugreifen kann, sollen im Folgenden am Beispiel eines Währungsumrechnungstools beschrieben werden. Ein Überblick über die Funktionsweise und den Aufbau einer Session Bean gibt Abbildung 4.5. Es zeigt, wie Clients die Bean über das Home- bzw. Remote-Interface ansprechen, in welchem Zusammenhang EJBContainer und Server stehen und welche Rolle das JNDI spielt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.5: Architektur einer Session Bean [DP02]

Das Home-Interface

Mit der Implementierung des Home-Interfaces muss der Lebenszyklus der Session-Bean definiert werden. Es werden also Methoden zum Erzeugen und Zerstören der Bean benötigt. Das Interface erweitert javax.ejb.EJBHome, in welchem die Me-thode zum Zerstören (remove()) bereits definiert wird. Da die Kommunikation zwi-schen dem Client und dem Server über ein Netzwerk erfolgt, muss jede definierte Me-thode eine RemoteException werfen, falls es während der Kommunikation zu ei-nem Netzwerkproblem kommt. Die create()-Methode muss zusätzlich noch eine CreateException auslösen, für den Fall, dass beim Erstellen der Bean ein Fehler auftritt.

Abbildung in dieser Leseprobe nicht enthalten

Das Remote-Interface

Das Remote-Interface definiert den eigentlichen Zweck der Bean. Die Methoden dieses Interfaces stellen die Schnittstellen nach aussen dar, die von der Bean-Klasse implemen-tiert werden müssen. Das Remote-Interface erweitert javax.ejb.EJBObject. Jede Methode muss so definiert werden, dass sie eine RemoteException werfen kann.

Abbildung in dieser Leseprobe nicht enthalten

Die Bean-Klasse

Aufgabe der Bean-Klasse ist es, alle im Remote-Interface definierten Methoden zu implementieren. Dies ist in einem Anwendungssystem die Geschäftslogik. Daneben müssen die aus dem Home-Interface bekannten Methoden ejbCreate() und ejbRemove() sowie die Methoden ejbActivate(), ejbPassivate() und setSessionContext() implementiert werden.

setSessionContext()

Direkt nach dem Erzeugen der Session Bean wird die Methode setSessionContext() aufgerufen. Dabei bekommt sie vom Container, in

4.1. Enterprise JavaBeans 25

dem sie läuft, dessen SessionContext übergeben, der in der Implementierung der Methode abgespeichert werden muss.

ejbCreate()

Die Initialisierung der Session Bean erfolgt über die ejbCreate()-Methode. Zustandlose-Beans besitzen davon lediglich eine ohne Parameter, zustandbehaftete Beans können mehrere create()-Methoden haben, die sich dann aber in ihren Signaturen unterscheiden müssen.

ejbPassivate()

Da der EJB-Container Beans, die lange nicht in Verwendung sind, passiviert, um Ressourcen freizugeben, wird dafür in der Bean-Klasse eine entsprechende Methode benötigt. Dabei werden z.B. Netzwerk- und Datenbankverbindungen getrennt. Da eine zustandlose Bean nicht passiviert wird, kann die Methode bei ihnen leer bleiben.

ejbActivate()

Eine vom Container passivierte Bean wird über die Methode ejbActivate() wieder aktiviert, nachdem ein Client eine Anforderung an diese Bean gestellt hat. Von der Bean benötigte Ressourcen (z.B. Netzwerk- oder Datenbankverbindungen) werden der Bean dabei wieder zugeordnet.

ejbRemove()

Das Löschen einer Session Bean wird vom Client durch Aufruf der Methode ejbRemove() initiiert. Nach dem Aufruf der Methode werden der Bean zugewiesene Ressourcen wieder freigegeben und die Bean-Instanz aus dem Container gelöscht.

Im Anhang A ist ein Listing mit dem vollständigen Sourcecode der Session Bean zu finden. Erwähnt werden sollte noch eine Konvention zur Benennung der Interfaces und Klassen. Das Remote-Interface bekommt i.a. einen aussagekräftigen Namen, unter dem die Bean entwickelt werden soll. Das Home-Interface bekommt den Suffix „Home“, die Bean-Klasse den Suffix „Bean“. Des weiteren sollten alle Instanzvariablen als private deklariert werden. Daher muss für jedes Attribut eine get()-Methode implementiert werden, die den entsprechenden Wert zurückgibt.

Die Clientanwendung

Um die erstellte Bean zu testen wird eine Clientanwendung benötigt. Die Anwendung sucht über den JNDI-Namen die Bean und erstellt eine neue Instanz. Danach kann auf alle im Remote-Interface definierten Methoden zugegriffen werden. Der Sourcecode ist ebenfalls im Anhang A zu finden.

Wie die Bean im EJB-Container bereitgestellt wird ist abhängig vom jeweiligen Produkt. An dieser Stelle sei auf die Handbücher der Hersteller verwiesen.

4.1.4.2 Entity Beans

4.1.4.2.1 Grundlagen von Entity Beans

Im Gegensatz zu den Session Beans repräsentieren Entity Beans persistente Daten meist in einer Datenbank. Sie dienen als Abbild von Objekten der realen Welt, in denen neben dem Zustand auch das Verhalten abgebildet wird. Einen Überblick über die Architektur zeigt die folgende Abbildung 4.6. Es ist zu sehen, dass Entity Beans ebenfalls ein Home-und ein Remote-Interface besitzen. Die Umgebung im Server und die Rolle des JNDI sind identisch zu den Session Beans. Hinzugekommen ist JDBC, womit die Persistenz, die Speicherung der von einer Bean dargestellten Daten in einer Datenbank realisiert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.6: Architektur einer Entity-Bean [DP02]

Einer der wesentlichen Unterschiede zu den Session Beans besteht in der Verwendung ei-nes Primärschlüssels. Als Primärschlüssel dienen ein oder mehr Attribute der Bean, die es dann ermöglichen, alle Instanzen der Klasse eindeutig zu identifizieren. Ein weiterer Un-terschied liegt in der Funktionsweise des parallelen Zugriffs durch Clients. Während bei zustandbehafteten Session Beans jeder Client auf seine eigene Instanz zugreift, können bei Entity Beans mehrere Clients auf eine Instanz zugreifen. Der konkurrierende Zugriff wird durch den EJB-Container verwaltet.

4.1.4.2.2 Aufbau einer Entity-Bean

Home-Interface

Ähnlich wie bei den Session Beans muss auch das Home-Interface bei den Enti-ty Beans Methoden zum Erstellen und Löschen der Bean definieren. Hinzu kom-men Methoden zum Auffinden einer Bean. Dazu gehört im Allgemeinen die Methode findByPrimaryKey(), mit der eine Bean anhand ihres Primärschlüssels aufgefunden wird. Hinzu kommen Methoden, die eine Menge von Beans zurückliefern. Dazu später mehr.

Remote-Interface

Das Remote-Interface definiert alle Methoden, die gegenüber dem Client angeboten werden. Auch hier erweitert es EJBObject. Ausserdem muss jede Methode eine RemoteException auslösen. Da auch bei den Entity Beans alle Attribute mit dem Modifier private versehen seien sollten, muss für jedes Attribut, welches gelesen oder geschrieben werden soll, die entsprechende get()- bzw. set()-Methode definiert wer-den.

4.1.4.2.3 Steuerung des Lebenszyklus

setEntityContext()/unsetEntityContext()

Auch Entity Bean Instanzen werden vom EJB-Container in einem Pool gehalten. Eine Instanz aus dem Pool kann dabei immer nur einer Bean-Identität zugeordnet sein. Um neue Instanzen in den Pool aufzunehmen, wird vom Container die setEntityContext()Methode aufgerufen. Dabei übergibt der Container der Bean seinen Context, der der Bean dann in der Implementierung der Methode zugewiesen werden muss.

Will der Container die Menge der Beans im Pool verringern, ruft er die unsetEntityContext()-Methode auf. Dabei wird lediglich die Bean-Instanz aus dem Pool gelöscht, ihr zu diesem Zeitpunkt zugeordnete Bean-Identitäten gehen dadurch jedoch nicht verloren. Sie bleiben in der zugrundeliegenden Datenbank gespeichert.

[...]

---

¹ IT - Informationstechnologie

² EAI - Enterprise Application Integration

⁵ CORBA - Common Object Request Broker Architekture

³ XML - eXtensible Markup Language

⁴ EJB - Enterprise JavaBeans

⁵ CORBA - Common Object Request Broker Architekture

⁶ (D)COM - (Distributed) Component Object Model

¹ XSLT - XML Stylesheet Language Transformations

² BPA - Business Process Automatisation

⁵ CORBA - Common Object Request Broker Architekture

³ BPI - Business Process Integration

⁵ CORBA - Common Object Request Broker Architekture

⁴ W3C - World Wide Web Consortium

⁵ DTD - Document Type Definition

¹ ISO/OSI - International Standardization Organization/Open Systems Interconnect

¹ OMG - Object Management Group

² HTML - Hypertext Markup Language

³ JSP - Java Server Pages

⁴ JNDI - Java Naming and Directory Interface

⁵ CORBA - Common Object Request Broker Architekture

⁵ RMI - Remote Method Invokation

⁵ CORBA - Common Object Request Broker Architekture

⁶ JDBC - Java Database Connectivity

⁵ CORBA - Common Object Request Broker Architekture

⁷ DBMS - Datenbankmanagementsystem

⁸ JTA - Java Transaction API

⁹ JMS - Java Message Service

¹⁰ API - Application Programming Interface

⁵ CORBA - Common Object Request Broker Architekture

¹¹ J2SE - Java2 Standard Edition

¹² J2EE - Java2 Enterprise Edition

¹³ AWT - Abstract Windowing Toolkit

¹⁴ CMP - Container Managed Persistence