ID 8119
Osterrieder, Christian: Komponentenmodelle für Web-Anwendungen
Hamburg: Diplomica GmbH, 2004
Zugl.: Paris-Lodron-Universität Salzburg, Diplomarbeit, 2004
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2004
Printed in Germany
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die den
benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich
gemacht habe.
Salzburg, 8. Juli 2004
Danksagung
Ich möchte mich bei Herrn Univ. Prof. Dr. Wolfgang Pree für die Betreuung der
Diplomarbeit bedanken.
Besonderer Dank gilt Herrn Univ.-Doz. Dr. Siegfried Reich von der Salzburg
Research Forschungsgesellschaft. Er hat mir maßgeblich bei der Suche nach einem ge-
eigneten Thema geholfen und mir mit zahlreichen fruchtbaren Gesprächen, die einen
wesentlichen Beitrag zum Gelingen dieser Arbeit darstellten, die nötige Motivation
gegeben.
Herzlich bedanken möchte ich mich auch bei meiner Lebensgefährtin Antonia, oh-
ne die ich nicht das Potenzial in mir entdeckt hätte, dieses Studium zu ergreifen und
zum Erfolg zu führen.
Inhaltsverzeichnis
1
Einleitung
1
1.1
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Gliederung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
Beschreibung von Komponentenmodellen
4
2.1
Grundlagen der komponentenbasierten Softwareentwicklung . . . . .
4
2.1.1
Begriffe und Definitionen
. . . . . . . . . . . . . . . . . . .
4
2.1.2
Grundidee der komponentenbasierten Softwareentwicklung
.
6
2.2
Die de-facto-Standards der komponentenbasierten Softwareentwicklung
9
2.2.1
Die Common Object Request Broker Architecture
. . . . . .
10
2.2.2
Die Enterprise JavaBeans der Java 2 Enterprise Edition . . . .
17
2.2.3
Die Assemblies des .NET Frameworks
. . . . . . . . . . . .
24
2.2.4
Web-Services . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.2.5
Vergleich der Komponentenmodelle . . . . . . . . . . . . . .
34
3
Beschreibung von Web-Anwendungen
42
3.1
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.1.1
Begriffe und Definitionen
. . . . . . . . . . . . . . . . . . .
42
3.1.2
Anforderungen an Web-Anwendungen als Kriterienkatalog . .
45
3.2
Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.2.1
Mehrschichtige-Architekturen . . . . . . . . . . . . . . . . .
50
3.2.2
Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.2.3
Model-View-Controller-Muster . . . . . . . . . . . . . . . .
54
4
Architekturen und Lösungsstrategien für Web-Anwendungen
56
4.1
Common Object Request Broker Architecture (CORBA) . . . . . . .
56
4.1.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.1.2
Lösungsstrategien zu den Anforderungen an Web-Anwendungen 57
4.2
Java 2 Enterprise Edition (J2EE) . . . . . . . . . . . . . . . . . . . .
63
4.2.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.2.2
J2EE-Anwendungen nach dem Model-View-Controller-Muster
66
4.2.3
Lösungsstrategien zu den Anforderungen an Web-Anwendungen 66
4.3
.NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.3.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.3.2
Lösungsstrategien zu den Anforderungen an Web-Anwendungen 74
4.4
Web-Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.4.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.4.2
Lösungsstrategien zu den Anforderungen an Web-Anwendungen 80
5
Terminkalender als komponentenbasierte Web-Anwendung
87
5.1
Anforderungen an das Produkt . . . . . . . . . . . . . . . . . . . . .
87
5.1.1
Begriffe für K
ALENDARO
. . . . . . . . . . . . . . . . . . .
87
5.1.2
Die Akteure von K
ALENDARO
. . . . . . . . . . . . . . . . .
88
5.1.3
Funktionale Anforderungen . . . . . . . . . . . . . . . . . .
91
5.1.4
Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . .
97
5.2
Auswahl des Komponentenmodells . . . . . . . . . . . . . . . . . . .
97
5.2.1
Common Object Request Broker Architecture . . . . . . . . .
98
5.2.2
.NET Framework . . . . . . . . . . . . . . . . . . . . . . . .
99
5.2.3
Java 2 Enterprise Edition . . . . . . . . . . . . . . . . . . . . 100
5.2.4
Web-Services . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.5
Ausgewähltes Komponentenmodell . . . . . . . . . . . . . . 101
5.3
Architekturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.1
Architektur der Web-Anwendung . . . . . . . . . . . . . . . 102
5.3.2
Architektur der Synchronisationsanwendung . . . . . . . . . 104
5.4
Entwicklung der Web-Anwendung . . . . . . . . . . . . . . . . . . . 105
5.4.1
Verwendete Entwicklungswerkzeuge und Plattformen
. . . . 105
5.4.2
Der Persistenzmechanismus von K
ALENDARO
. . . . . . . . 108
5.4.3
Entwicklung der Synchronisationsanwendung . . . . . . . . . 110
5.5
Bewertung der Web-Anwendung und Schlussfolgerungen . . . . . . . 114
5.5.1
Bewertung der Anforderungen aus dem Kriterienkatalog . . . 114
5.5.2
Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . 118
6
Ausblick
119
7
Zusammenfassung
121
Anhänge
123
Anhang A: Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . 123
Anhang A.1: Paket Terminkalender . . . . . . . . . . . . . . . . . . . 123
Anhang A.2: Paket Terminteilnahme . . . . . . . . . . . . . . . . . . 126
Anhang A.3: Paket Suche . . . . . . . . . . . . . . . . . . . . . . . . 128
Anhang A.4: Paket Verwaltung . . . . . . . . . . . . . . . . . . . . . 129
Anhang A.5: Paket Administration . . . . . . . . . . . . . . . . . . . 133
Anhang A.6: Paket Conduit . . . . . . . . . . . . . . . . . . . . . . . 135
Anhang B: Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . 138
Anhang C: Document Type Definition der Synchronisationsdateien . . . . . 139
Anhang D: WSDL Beschreibung der Web-Services zur Kalendersynchroni-
sation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Glossar
143
Abkürzungsverzeichnis
147
Literatur
151
Bilderverzeichnis
1
Object Management Architecture (OMA) . . . . . . . . . . . . . . .
11
2
Clientsicht auf Komponenten in CORBA . . . . . . . . . . . . . . . .
13
3
Entwicklersicht auf Komponenten in CORBA . . . . . . . . . . . . .
15
4
CORBA Container-Programming-Modell . . . . . . . . . . . . . . .
16
5
Typen von Enterprise JavaBeans . . . . . . . . . . . . . . . . . . . .
19
6
Clientsicht auf Komponenten in EJB für Session Beans und Entity Beans 20
7
Beziehungen zwischen den Klassen eines EJB Containers . . . . . . .
22
8
Die .NET Framework Architektur . . . . . . . . . . . . . . . . . . .
26
9
Bestandteile von .NET Assemblies . . . . . . . . . . . . . . . . . . .
27
10
Web-Service als virtuelle Komponente . . . . . . . . . . . . . . . . .
30
11
Beziehung zwischen UDDI, SOAP und WSDL. . . . . . . . . . . . .
34
12
2-Schichten-Architektur
. . . . . . . . . . . . . . . . . . . . . . . .
51
13
Mehrschichtige Architektur . . . . . . . . . . . . . . . . . . . . . . .
51
14
Verteilungsplattform als Infrastruktur für verteilte Systeme . . . . . .
53
15
Kommunikation und Datenaustausch zwischen den einzelnen Teilen
des Model-View-Controller-Musters . . . . . . . . . . . . . . . . . .
54
16
Mehrschichtige Architektur einer Web-Anwendung mit CORBA . . .
56
17
Beispiel für den Einsatz einer half bridge . . . . . . . . . . . . . . . .
63
18
Mehrschichtige Architektur einer .J2EE Web-Anwendung
. . . . . .
64
19
Beispiel eines Model-View-Controller-Muster in J2EE. . . . . . . . .
66
20
Mehrschichtige Architektur einer .NET Web-Anwendung . . . . . . .
73
21
Service-orientierte Architektur (SOA) . . . . . . . . . . . . . . . . .
80
22
Aufteilung der Anwendungsfalldiagramme in Pakete . . . . . . . . .
91
23
Anwendungsfalldiagramm des Paketes Terminkalender . . . . . . . .
92
24
Anwendungsfalldiagramm des Paketes Terminteilnahme
. . . . . . .
93
25
Anwendungsfalldiagramm des Paketes Suche . . . . . . . . . . . . .
94
26
Anwendungsfalldiagramm des Paketes Verwaltung - Teilnehmer . . .
94
27
Anwendungsfalldiagramm des Paketes Verwaltung - Terminkalender .
95
28
Anwendungsfalldiagramm des Paketes Verwaltung - Veranstalter . . .
95
29
Anwendungsfalldiagramm des Paketes Administration
. . . . . . . .
96
30
Anwendungsfalldiagramm des Paketes Conduit . . . . . . . . . . . .
97
31
Architektur der Web-Anwendung . . . . . . . . . . . . . . . . . . . . 102
32
Architektur der Synchronisationsanwendung . . . . . . . . . . . . . . 104
33
Klassen des Sequence Blocks Entwurfsmusters . . . . . . . . . . . . 110
34
Sequenzdiagramm der Synchronisation
. . . . . . . . . . . . . . . . 111
35
Filter-Servlet zur Prüfung der Autorisation in K
ALENDARO
. . . . . . 115
36
Erwartete Entwicklungsstufen des Web. . . . . . . . . . . . . . . . . 119
37
Relationales Datenbankschema von K
ALENDARO
. . . . . . . . . . . 138
Tabellenverzeichnis
1
CORBA Komponentenkategorien
. . . . . . . . . . . . . . . . . . .
16
2
Vergleich der Komponentenmodelle . . . . . . . . . . . . . . . . . .
41
3
Synchronisation der K
ALENDARO
Kalendereinträge mit der empfan-
genen Synchronisationsdatei . . . . . . . . . . . . . . . . . . . . . . 112
4
Synchronisation des Palm Datebooks mit der Synchronisationsdatei,
Kalendereinträge hinzufügen oder löschen . . . . . . . . . . . . . . . 113
5
Synchronisation des Palm Datebooks mit der Synchronisationsdatei,
Kalendereinträge ändern . . . . . . . . . . . . . . . . . . . . . . . . 114
6
Anwendungsfälle des Paketes Terminkalender . . . . . . . . . . . . . 126
7
Anwendungsfälle des Paketes Terminteilnahme . . . . . . . . . . . . 128
8
Anwendungsfälle des Paketes Suche . . . . . . . . . . . . . . . . . . 129
9
Anwendungsfälle des Paketes Verwaltung - Teilnehmer . . . . . . . . 130
10
Anwendungsfälle des Paketes Verwaltung - Terminkalender . . . . . . 132
11
Anwendungsfälle des Paketes Verwaltung - Veranstalter
. . . . . . . 133
12
Anwendungsfälle des Paketes Administration . . . . . . . . . . . . . 134
13
Anwendungsfälle des Paketes Conduit . . . . . . . . . . . . . . . . . 137
Zielsetzung
1
1
Einleitung
Das World-Wide-Web (kurz Web) konnte sich innerhalb kürzester Zeit als Plattform
für verteilte Anwendungen etablieren. Immer häufiger wird dieses Medium von Be-
trieben und Organisationen benutzt, um Produkte und Dienstleistungen mit Hilfe von
Web-Anwendungen anzubieten. Web-Anwendungen sind nicht nur durch eine Anbin-
dung an betriebliche Anwendungen geprägt, sondern erfordern auch eine entsprechen-
de Umsetzung von betrieblichen Abläufen im Web [Gaedke 99].
Web-Anwendungen sind Softwaresysteme die Inhalte und Dienste über eine Be-
nutzerschnittstelle zur Verfügung stellen. Sie beruhen auf Spezifikationen des World
Wide Web Consortiums [Kappel 04]. Das einfache, dokumentenbasierte Modell, das
dem Web zugrunde liegt, behindert jedoch den Entwurf, die Wartbarkeit und Evolution
von Web-Anwendungen. Die Softwaretechnik hat viele Verfahren, Modelle und Me-
thoden zur Lösung dieser Probleme hervorgebracht, sie werden für Web-Anwendungen
aber nur selten verwendet [Gaedke 99].
Allgemein anerkannt in der Softwaretechnik ist die komponentenbasierte Softwa-
reentwicklung. Sie soll Zeit- und Kostenersparnisse und eine Qualitätssteigerung von
Software bringen indem sie die Wiederverwendung durch Komposition von Software-
Bausteinen ermöglicht.
In der komponentenbasierten Softwareentwicklung haben sich verschiedene Kom-
ponentenmodelle und Spezifikationen als de-facto-Standards durchgesetzt. Zu diesen
Standards zählen:
£ Die Common Object Request Broker Architecture (kurz CORBA),
£ die Enterprise JavaBeans (kurz EJB) der Java 2 Enterprise Edition (kurz J2EE),
£ die Assemblies des .NET Frameworks und
£ die Web-Services.
Um eine industrielle Konstruktion und Produktion von Web-Anwendungen mittels
dieser de-facto-Standards zu erreichen, ist es Voraussetzung, dass das Zusammenspiel
der Software-Komponenten durch ein Framework definiert wird. Das Framework kann
als Halbfertigfabrikat ein vordefiniertes Architekturrahmengerüst anbieten und spielt
eine wichtige Rolle für die Entwicklung von Web-Anwendungen [Pree 99].
Gliederung
2
1.1
Zielsetzung
In dieser Arbeit werden Frameworks und Spezifikationen im Zusammenhang mit
Komponentenmodellen untersucht, welche zur Entwicklung von Web-Anwendungen
dienen. Dazu wird ein Überblick über die de-facto-Standards der komponentenbasier-
ten Softwareentwicklung gegeben.
Die Theorie der komponentenbasierten Softwareentwicklung bestimmt verschiede-
ne Erwartungen und Anforderungen an Softwarekomponenten. Durch einen Vergleich
der Komponentenmodelle werden die jeweiligen Vor- und Nachteile untersucht und
gegenübergestellt. Somit soll festgestellt werden, ob die vorgestellten Komponenten-
modelle den Erwartungen und Anforderungen entsprechen.
Betriebe und Organisationen haben gewisse Anforderungen an Web-Anwendungen
und deren Architekturen. Ziel ist es, die wichtigsten dieser Anforderungen festzustel-
len und in einem Kriterienkatalog zusammenzufassen. Mittels dieses Kriterienkatalogs
werden die de-facto-Standards der komponentenbasierten Softwareentwicklung in ei-
ner Literaturstudie verglichen.
Praktisches Ziel der Diplomarbeit ist die Entwicklung eines Softwareprototypen in
Form eines Terminkalenders. Für diese Aufgabe soll ein geeignetes Komponentenmo-
dell evaluiert werden. Anhand dieses praktischen Beispiels wird geprüft, ob die für
dieses Komponentenmodell zur Verfügung stehenden Frameworks und Spezifikatio-
nen, den Anforderungen aus dem Kriterienkatalog gerecht werden.
1.2
Gliederung
Die vorliegende Diplomarbeit gliedert sich in vier Hauptteile:
£ Das Kapitel 2 der Diplomarbeit beschäftigt sich mit der komponentenbasier-
ten Softwareentwicklung. Dabei werden die Komponentenmodelle von CORBA,
der EJB Spezifikation, des .NET Frameworks und die Web-Services vorgestellt.
Durch einen Vergleich der Komponentenmodelle werden deren Vor- und Nach-
teile bestimmt.
£ Das Kapitel 3 dient der Beschreibung von gängigen Softwarearchitekturen für
Web-Anwendungen. Anschließend werden die wichtigsten Anforderungen an
Web-Anwendungen evaluiert und in einem Kriterienkatalog zusammengefasst.
£ Im Kapitel 4 werden die Frameworks und Spezifikationen von CORBA, der J2EE
Spezifikation, dem .NET Framework und der Web-Services überprüft, ob sie den
evaluierten Anforderungen aus dem Kriterienkatalog gerecht werden.
Gliederung
3
£ Das Kapitel 5 zeigt schließlich die Entwicklung des Prototypen des Terminkalen-
ders und einer Synchronisationsanwendung zum Datenabgleich des Terminkalen-
ders mit einem handelsüblichen Handheld-Computer. Dazu werden Komponen-
tenmodelle, Frameworks und Spezifikationen aus den vorangegangenen Kapiteln
ausgewählt und untersucht, ob sie den evaluierten Anforderungen des Kriterien-
katalogs entsprechen.
Kapitel 6 enthält einen Ausblick auf zukünftige Entwicklungen der komponenten-
basierten Softwareentwicklung für Web-Anwendungen.
Begriffe und Definitionen
4
2
Beschreibung von Komponentenmodellen
In diesem Kapitel werden im Abschnitt 2.1 die Grundlagen der komponentenbasierten
Softwareentwicklung beschrieben, auf denen diese Arbeit aufbaut. Danach wird im
Abschnitt 2.2 eine Einführung in die wichtigsten Komponentenmodelle und Spezifika-
tionen gegeben und deren Vor- und Nachteile bestimmt.
2.1
Grundlagen der komponentenbasierten Softwareentwicklung
Im Unterabschnitt 2.1.1 werden die wichtigsten Begriffe der komponentenbasierten
Softwareentwicklung definiert. Danach wird im Unterabschnitt 2.1.2 die Grundidee
der komponentenbasierten Softwareentwicklung erklärt, um die Verwendung von vor-
gefertigten Software-Komponenten für Web-Anwendungen verstehen zu können.
2.1.1
Begriffe und Definitionen
Wiederverwendung von Software
Softwareprodukte werden immer komplexer, ihre Entwicklungszeiten immer kürzer.
Um diese und viele andere Probleme der Softwaretechnik in den Griff zu bekommen,
ist es notwendig, bereits vorhandene Software anpassen und wieder verwenden zu kön-
nen. Es stellt sich daher zuerst die Frage was unter Wiederverwendung von Software
verstanden wird.
Unter [Biggerstaff 89] findet sich folgende Definition für diesen Begriff:
,,Wiederverwendung von Software ist das erneute Anwenden von bei der
Entwicklung eines Softwaresystems entstandenen Artefakten und angesam-
meltem Wissen bei der Entwicklung eines neuen Softwaresystems, um den
Aufwand zur Erstellung und Pflege dieses neuen Systems zu reduzieren."
Eine weitere Definition für die Software-Wiederverwendung wird in [Ezran 89] ver-
wendet:
,,Software reuse is the systematic practice of developing software from a
stock of building blocks, so that similarities in requirements and/or architec-
ture between applications can be exploited to achieve substantial benefits in
productivity, quality and business performance."
Aus diesen Definitionen kann der Schluss gezogen werden, dass Software-Wieder-
verwendung immer hinsichtlich des Prozesses der Softwareentwicklung zu sehen ist.
Sie stellt eine systematische Verwendung von bereits gegebenen Software-Komponen-
ten (Software-Bausteinen) dar, das einen wohldefinierten Prozess der komponentenba-
sierten Softwareentwicklung erfordert [Schmietendorf 02].
Begriffe und Definitionen
5
Software-Komponente
Dies führt unmittelbar zu einer Definition des Begriffes Software-Komponente. Der
Begriff Software-Komponente und Komponente wird im weiteren Verlauf der Diplom-
arbeit analog behandelt. In [Balzert 96] findet sich folgende allgemeine Definition:
,,Ein Halbfabrikat bzw. eine Komponente (componentware) ist also ein ab-
geschlossener, binärer Software-Baustein, der eine anwendungsorientierte,
semantisch zusammengehörende Funktionalität besitzt, die nach außen über
Schnittstellen zur Verfügung gestellt wird. Beim Entwurf des Halbfabrikats
wurde auf hohe Wiederverwendbarkeit großer Wert gelegt."
Eine der bekanntesten und allgemein anerkannten Definitionen ist die von
[Szyperski 02]:
,,A software component is a unit of composition with contractually specified
interfaces and explicit context dependencies only. A software component can
be deployed independently and is subject to composition by third parties."
Der Begriff Komponente ist in der Literatur nicht eindeutig definiert. Es existieren
viele unterschiedliche Ansichten. Allgemein trifft es die Aussage, dass eine Kompo-
nente eine eigenständige Software ist, mit wohldefinierten Interaktionspunkten und -
modi. Sie kann mit anderen Komponenten zu größeren Software-Gebilden verbunden
werden und somit als Software-Baustein angesehen werden [Atkinson 03].
Komponentenmodell
Eine weitere Definition, die sich bereits aus dem Titel dieser Arbeit ergibt, ist die der
Komponentenmodelle. In [Szyperski 02] wird beschrieben, dass ein Komponentenmo-
dell festlegt, welche Anforderungen eine Komponente erfüllen muss, und zwar sowohl
in syntaktischer, als auch in semantischer Hinsicht.
Eine ausführliche Definition findet sich in [Thomas 98]:
,,A component model defines the basic architecture of a component, specify-
ing the structure of its interfaces and the mechanisms by which it interacts
with its container and with other components. The component model provi-
des guidelines to create and implement components that can work together
to form a larger application. Application builders can combine components
from different developers or different vendors to construct an application."
Das Komponentenmodell ist demnach der ,,Bauplan" der komponentenbasierten
Softwareentwicklung, welcher dem Entwickler und Benutzer von Software-Kompo-
nenten Standards und Vorgehensweisen zur Softwareentwicklung vorgibt.
Grundidee der komponentenbasierten Softwareentwicklung
6
Framework
In der Einleitung wurde der Begriff des Frameworks verwendet. In den meisten kom-
ponentenbasierten Softwareprojekten kommen nicht einzelne Software-Komponenten
zum Einsatz, es werden vielmehr Sammlungen von Komponenten in so genannten
Rahmenwerken (engl. frameworks) verwendet. Software die aufgrund eines Frame-
works entwickelt wurde, verwendet nicht nur bereits existierenden Quellcode, sondern
ermöglicht auch die Wiederverwendung von Softwarearchitekturen [Pree 97]. Frame-
works werden von [Pree 97] folgendermaßen definiert:
,,A framework is simply a collection of several single components with pre-
defined cooperations between them, for the purpose of accomplishing a cer-
tain task."
Ein Framework stellt somit eine Sammlung von Komponenten dar, wobei die ver-
wendete Programmiersprache nebensächlich ist. Die Komponenten interagieren nach
einem vordefinierten Schema und bieten eine Schnittstelle zur Erweiterung nach au-
ßen (so genannte hot spots oder variation points) [Pree 02]. Frameworks ergänzen die
Komponentenstandards und erleichtern die industrielle Konstruktion und Produktion
von Software [Pree 99].
Die bereits angesprochene ,,Wiederverwendung von Software durch Komponenten"
gilt allgemein als ein Schlüssel für die Etablierung einer ingenieurmäßigen Vorgehens-
weise bei der Entwicklung von Software [Schmietendorf 02]. Im Folgenden Unter-
abschnitt wird daher die Grundidee der komponentenbasierten Softwareentwicklung
erläutert.
2.1.2
Grundidee der komponentenbasierten Softwareentwicklung
Seit langem beschäftigt sich die Softwareindustrie mit den Problemen der Wieder-
verwendung von Software. Diese Probleme gründen darin, dass mit zunehmender
Leistungsfähigkeit der Computer die Computerprogramme immer komplexer werden.
Gleichzeitig werden die Zeiträume für die Entwicklung von Software immer kürzer
und die Entwicklungsteams immer größer. Mit den traditionellen funktionalen und pro-
zeduralen Programmiermethoden kann dies zu schwer wartbaren Programmen führen.
Daher kann sich ein Großteil des Gesamtaufwandes der Softwareentwicklung auf die
Wartung und Korrektur von Programmen verlagern.
Objektorientierte Softwareentwicklung
Als eine der Antworten auf die Probleme der Softwarewiederverwendung galt die ob-
jektorientierte Softwareentwicklung. Damit sollte erreicht werden, dass eine komplexe
Grundidee der komponentenbasierten Softwareentwicklung
7
Anwendung in kleine Einheiten (in so genannte Objekte), zerlegt werden kann. Diese
Einheiten sollten möglichst unabhängig voneinander entwickelt und getestet werden
können. Ein wichtiger Aspekt der objektorientierten Softwareentwicklung ist die Mög-
lichkeit, neue Klassen
1
zu definieren, indem diese von vorhandenen Klassen erben.
Dadurch kann der vorhandene und schon getestete Funktionsumfang wieder verwen-
det und gleichzeitig angepasst und spezialisiert werden.
Besonders die frühen Vertreter der objektorientierten Softwareentwicklung vertra-
ten den Standpunkt, dass Objekte die am besten geeignete Abstraktion für die Wieder-
verwendung von Software darstellen [Sommerville 01]. Die objektorientierte Softwa-
reentwicklung konnte die Probleme allerdings nicht vollständig lösen und weist unter
anderem folgende Grenzen und Schwächen auf:
£ Klassen und Objekte verschiedener Programmiersprachen können oft nicht zu-
sammen in einem Softwareprodukt verwendet werden.
£ Eine einzelne Klasse für sich ist häufig nicht nützlich.
£ Wiederverwendung durch Vererbung kann starke Abhängigkeiten schaffen, so-
dass kein Austausch der ursprünglichen Klasse (zum Beispiel durch eine neuere
Version) möglich ist.
£ Vielfältige Beziehungen zwischen einzelnen Klassen können ein komplexes Ge-
flecht an Abhängigkeiten erzeugen.
£ Die Verteilung von Klassen und Objekten über ein Netzwerk ist oft nicht möglich.
Komponentenbasierte Softwareentwicklung
Abhilfe soll hier die Idee der komponentenbasierten Softwareentwicklung bringen.
Dieses Konzept ist nicht neu und wurde bereits 1968 auf einer NATO-Konferenz
in Garmisch-Patenkirchen von Mc Ilroy formuliert [McIlroy 68]. Als Beispiele sol-
cher frühzeitigen Komponentenansätze seien das Funktionsprinzip der Programmier-
sprache C oder auch das UNIT-Konzept der Programmiersprache PASCAL genannt
[Schmietendorf 02].
Das Ziel der komponentenbasierten Softwareentwicklung ist die Zusammensetzung
von Software durch Wiederverwendung von Komponenten. Dies soll Zeit- und Kosten-
ersparnisse bei der Entwicklung und eine zusätzliche Qualitätssteigerung der Software
bringen. Der Anwendungsentwickler hat dabei normalerweise keinerlei Zugriff auf
den Quellcode einer Software-Komponente, da Software-Komponenten häufig nur in
1
Menge von Objekten, die eine gemeinsame Struktur haben und ein gemeinsames Verhalten zeigen.
Grundidee der komponentenbasierten Softwareentwicklung
8
binärer Form zur Verfügung stehen. Er kann ihr Verhalten aber über die Konfiguration
ihrer Eigenschaften anpassen.
Im Folgenden seien noch die Erwartungen an Software-Komponenten und die An-
forderungen an deren Architektur aufgelistet:
Erwartungen an Software-Komponenten.
In [Schmietendorf 02] werden folgende Er-
wartungen an Software-Komponenten gestellt:
£ Höhere Qualität und Verfügbarkeit von Softwareprodukten: Durch umfangrei-
chen Einsatz und Test der Software-Komponenten wird angenommen, dass diese
weniger Fehler aufweisen.
£ Arbeitsteilige Softwareentwicklung: Durch den Einsatz von wohldefinierten Soft-
ware-Komponenten besteht die Möglichkeit, die Softwareentwicklung auf meh-
rere Personen oder örtlich aufzuteilen.
£ Verteilung wirtschaftlicher Risiken: Durch die Verteilung von fachlichen Anfor-
derungen in der Softwareentwicklung entstehen hohe Risiken, die durch kompo-
nentenbasierte Softwareentwicklung gemindert werden können.
£ Spezialisierung: Es können Techniken zum Einsatz kommen, die durch das spe-
zielle Wissen des Entwicklers entstanden sind, dem Benutzer der Software-Kom-
ponenten wird kein entsprechendes Wissen abverlangt.
£ Verbesserte Erweiterbarkeit: Durch klar voneinander abgegrenzte Software-Kom-
ponenten wird die Wartung, Pflege und Erweiterung vorhandener Software-Kom-
ponenten vereinfacht. Eine fehlerhafte Software-Komponente kann durch eine
Neuentwicklung einfach ausgetauscht werden.
£ Verkürzung der Entwicklungszeiten: Die Wiederverwendung von bereits gefer-
tigten Software-Komponenten verkürzt die Entwicklungszeit von Softwarepro-
dukten.
Anforderungen an die Architektur von Software-Komponenten.
Aus obigen Erwartun-
gen ergeben sich folgende Anforderungen an die Architektur von Software-Kompo-
nenten welche unter [Griffel 98] folgendermaßen zusammengefasst und beschrieben
sind:
£ Unabhängigkeit von der technischen Umgebung: Das Zusammenarbeiten von
Komponenten sollte möglichst unabhängig von Programmiersprachen, Betriebs-
systemen, Netztechniken und Entwicklungsumgebungen sein.
Die Common Object Request Broker Architecture
9
£ Ortsunabhängigkeit: Eine Komponente sollte nutzbar sein, unabhängig davon, ob
sie sich auf einem lokalen Rechner, in einer anderen Prozessumgebung oder im
Netzwerk auf einem entfernten Rechner befindet. Die dazu notwendigen Mecha-
nismen sollten für den Benutzer nicht sichtbar sein.
£ Trennung von Schnittstelle und Komponentenquellcode: Die Spezifikation einer
Komponente sollte vollständig unabhängig von deren Entwicklung erfolgen kön-
nen.
£ Selbstbeschreibende Schnittstellen: Zur Laufzeitkopplung und besseren Wieder-
verwendbarkeit von Komponenten sollte sie Auskunft über ihre eigenen Möglich-
keiten und Zugriffspunkte geben können.
£ Sofortige Nutzbarkeit: Eine Komponente sollte auf jeder Plattform installier- und
nutzbar sein. Dies impliziert insbesondere eine binäre Unabhängigkeit des Kom-
ponentencodes.
£ Integrations- und Kompositionsfähigkeit: Eine Komponente sollte zusammen mit
anderen Komponenten zu einer neuen funktionsfähigen Komponente integriert
werden können.
2.2
Die de-facto-Standards der komponentenbasierten Softwareentwicklung
Im Alltag der Entwicklung von Web-Anwendungen existieren vier Modelle, die die
Erstellung von Komponenten zu standardisieren versuchen:
£ Das Komponentenmodell der Object Management Group (OMG): CORBA Com-
ponent Model (CCM) [CORBA 02],
£ die Komponentenmodelle von Sun mit der Enterprise JavaBeans (EJB) Spezifi-
kation [EJB 02],
£ die Komponentenmodelle des .NET Frameworks von Microsoft [Microsoft(2) 04]
und
£ die Web-Services.
Die fundamentalen Eigenschaften in Form des Objektmodells, der Object Manage-
ment Group, von Sun und von Microsoft, sind vergleichbar. Ein etwas anderer Weg
wird mit Web-Services beschritten. Gemeinsam ist ihnen, dass sie das Konzept der
Trennung von Schnittstelle und Komponentenquellcode benutzen.
Diese Komponentenmodelle, die de-facto-Standards darstellen, werden in den fol-
genden Unterabschnitten 2.2.1, 2.2.2, 2.2.3 und 2.2.4 genauer beschrieben. Ein ab-
Die Common Object Request Broker Architecture
10
schließender Vergleich der Komponentenmodelle in Unterabschnitt 2.2.5, wird deren
Vor- und Nachteile bestimmen.
2.2.1
Die Common Object Request Broker Architecture
,,CORBA - the Common Object Request Broker Architecture is OMG's
showcase specification for application interoperability independent of plat-
form, operating system, programming language - even of network and pro-
tocol."
Object Management Group
Dieser Unterabschnitt gibt eine Einführung in das Komponentenmodell von
CORBA. Zuerst wird auf die Object Management Architecture eingegangen. Da-
nach wird das Komponentenmodell von CORBA genauer beschrieben, welches in der
CORBA-Components Spezifikation dargestellt wird (siehe [CORBA 02]). Wegen des
enormen Umfangs der Spezifikation kann hier natürlich nur ein Überblick gegeben
werden. CORBA wird getrennt aus Clientsicht und aus Entwicklersicht betrachtet. es
werden die so genannten Container, die Schnittstellen-Beschreibungen und die XML-
Beschreibungen der Archive erläutert.
Object Management Group (OMG)
Die Common Object Request Broker Architecture (CORBA) ist eine Spezifikation der
Object Management Group (OMG). Die Object Management Group ist eine interna-
tionale Organisation, die 1989 gegründet wurde, und mittlerweile über 600 Mitglieder
zählt. Die primären Ziele der Organisation sind die Förderung der Wiederverwend-
barkeit, der Portierbarkeit und der Interoperabilität von objektorientierter Software in
verteilten, heterogenen Umgebungen [CORBA 02]. Die aktuelle Version des CORBA
Standards ist die Version 3.0, welche in dieser Beschreibung Verwendung findet.
Object Management Architecture
Die Grundlage für die CORBA-Spezifikation bildet die Object Management Archi-
tecture (OMA). Die Object Management Group hat erkannt, dass viele verschiedene
Anwendungen die gleichen Dienste benötigen. Mit der Object Management Architec-
ture wird versucht, diese Dienste zu extrahieren und als eine Menge standardisierter
Objekte zur Verfügung zu stellen [CORBA 02(2)]. Die Architektur besteht aus 5 Tei-
len, deren Beziehungen zueinander in Bild 1 dargestellt sind und im Folgenden kurz
beschrieben werden:
Die Common Object Request Broker Architecture
11
Bild 1: Object Management Architecture (OMA)
£ Der Object Request Broker: Der Object Request Broker (ORB) ist der Mittel-
punkt der Object Management Architecture. Er ermöglicht die Kommunikation
in heterogenen, verteilten Umgebungen.
£ Die Common Object Services: Die Common Object Services (COS) bieten
Dienste, die über den reinen Transport der Methodenaufrufe hinausgehen und
die generell genug sind, um von vielen Anwendungen verwendet werden zu kön-
nen. Zu diesen Diensten gehören beispielsweise der Naming Service, der Trading
Service und der Event Service.
£ Die Common Facilities: Die Common Facilities bieten Dienste, die auf die Com-
mon Object Services aufgebaut sind. Die Dienste der Common Facilities sind
spezieller als die Common Object Services und erledigen komplexere Aufgaben.
Diese sind in folgende Bereiche gegliedert:
Informationsmanagement
Benutzerschnittstellen
Systemmanagement
Taskmanagement
£ Die Domain Objects: Die Domain Objects stellen die nächst höhere Abstraktions-
stufe dar. Diese stellen Dienste für Benutzer in einem speziellen Anwendungsbe-
reich zur Verfügung.
£ Die Application Objects: Die Application Objects sind nun die eigentlichen ver-
teilten Anwendungen und unterliegen daher nicht der Standardisierung durch die
Object Management Group.
Das CORBA Komponentenmodell
Das CORBA Komponentenmodell (CCM) ist ein serverseitiges Komponentenmodell,
das in erster Linie für Business-Komponenten
2
gedacht ist. In einer aus CORBA-Kom-
2
Konfigurierbare Softwaremodule mit eigener Verarbeitungslogik und Datenhaltung, die selbständig lauffähig sind.
Die Common Object Request Broker Architecture
12
ponenten zusammengesetzten Anwendung laufen die Komponenten in einem oder
mehreren verteilten Servern. Clients greifen über CORBA auf diese Komponenten zu,
um deren Dienste zu benutzen [CORBA 02].
Eine Komponente in CORBA ist ein einfacher Typ, welcher eine Erweiterung und
Spezialisierung des Object-Metatypen von CORBA darstellt. Die interne Repräsenta-
tion der Komponente wird dabei gekapselt [CORBA 02]. Eine wichtige Eigenschaft
besteht auch darin, dass Komponenten mehrere Schnittstellen exportieren und impor-
tieren können [Stal 00].
Clientsicht auf Komponenten
Clients stellen Anfragen (engl.: requests) an CORBA-Objekte, deren Implementie-
rungsdetails und Ort verborgen bleiben. Client und ausführbares CORBA-Objekt kön-
nen in verschiedenen Programmiersprachen entwickelt worden sein und auf verschie-
denen Plattformen laufen [CORBA 02]. Als Client wird in diesem Zusammenhang je-
de Entität bezeichnet, die eine Anfrage an ein CORBA-Objekt richtet, also auch andere
CORBA-Objekte.
Eine Referenz auf eine Komponente ist ähnlich der Referenz auf ein CORBA-Ob-
jekt. Clients die noch keine Komponenten kennen, können diese wie eine gewöhnliche
Referenz auf ein Objekt benutzen. Diese Referenz auf eine Instanz einer Komponen-
te verweist immer auf eine ausgezeichnete Schnittstelle der Komponente, der so ge-
nannten Äquivalenzschnittstelle. Eine Komponente kann auch weitere Schnittstellen
besitzen, die Facetten genannt werden. Der Client kann über die Äquivalenzschnitt-
stelle diese Facetten ansteuern. Durch die Möglichkeit der zusätzlichen Schnittstellen,
wird die Wiederverwendbarkeit und Erweiterbarkeit beträchtlich gesteigert, da einer
Komponente weitere Funktionen hinzugefügt werden können, ohne dass bestehende
Schnittstellen oder Clients davon betroffen sind [Stal 00][CORBA 02].
Eine Komponente obliegt der Zuständigkeit einer Home-Schnittstelle (kurz Home
genannt). Jedes Home administriert Komponenten genau eines bestimmten Typs. Je-
de Komponente ist also stets eindeutig einem Home zugeordnet. Clients können die
Home-Schnittstelle benutzen, um auf eine standardisierte Weise den gesamten Lebens-
zyklus der Komponente zu kontrollieren. Ein Home kann optional einen Primärschlüs-
sel benutzen, um eine Zuordnung von Schlüsselwerten zu Komponenteninstanzen her-
zustellen. Der Weg zur Komponente erfolgt also stets über das Home. Clientanwen-
dungen lokalisieren das Home über einen Home-Finder, bei dem sie sich zur Initiali-
sierungszeit registrieren [CORBA 02]. Die ,,Clientsicht auf Komponenten" ist in Bild
2 dargestellt.
Die Common Object Request Broker Architecture
13
Bild 2: Clientsicht auf Komponenten in CORBA
Entwicklersicht auf Komponenten
Das Komponentenmodell bietet verschiedene Arten von Schnittstellen die in der Spe-
zifikation [CORBA 02] folgendermaßen beschrieben sind (siehe Bild 3):
£ Facetten (engl.: facets): Facetten sind benannte Schnittstellen eines bestimmten
Typs. Über sie kann der Client auf die Dienste der Komponente zugreifen. Dazu
werden die Schnittstellen als gewöhnliche CORBA-Objektreferenzen zur Verfü-
gung gestellt (siehe auch Abschnitt ,,Clientsicht auf Komponenten").
Die einzelnen Facetten einer Komponente sind soweit voneinander unabhängig,
dass mehrere Facetten des gleichen Typs definiert werden können, ohne dass sich
deren Verwendung gegenseitig, zum Beispiel durch einen gemeinsamen Zustand,
beeinflussen. Damit können Facetten verschiedene Sichten einer Komponente
darstellen und verschiedene Rollen eines Clients gegenüber der Komponente de-
finieren. Die Lebenszeit einer Facette ist durch die Lebenszeit der Komponente,
zu der sie gehört, begrenzt.
£ Receptacles: Ein Receptacle bezeichnet die Fähigkeit einer Komponente, eine
Schnittstelle eines bestimmten Typs zu verwenden. Ist die Komponente mit einer
solchen Schnittstelle verbunden, ist von einer Connection die Rede. Die Etablie-
rung der Verbindungen erfolgt über so genannte Monteure [Stal 00].
Receptacles ermöglichen die für Komponenten wichtige Wiederverwendung
durch Komposition. Eine Komponente kann so die Dienste einer anderen Kompo-
nente oder eines Objektes in Anspruch nehmen und wieder zur Verfügung stellen.
Es besteht allerdings keine implizite Beziehung oder Abhängigkeit zwischen der
Komponente und der verbundenen Objektreferenz. Es kann also nicht automa-
tisch von einer Delegation oder Weiterleitung von Operationsaufrufen ausgegan-
Die Common Object Request Broker Architecture
14
gen werden. Allein der Komponentenentwickler definiert die Bedeutung eines
Receptacles.
£ Ereignisse (engl.: events): Das Ereignis-Modell des CORBA Komponentenmo-
dells ist ein push-Modell, das heißt die Komponenten übergeben die Ereignisse
einem Ereigniskanal. Der einfache Mechanismus dieses push-Modells ist durch
so genannte Consumer-Schnittstellen verwirklicht worden. Entwickler spezifizie-
ren das Interesse einer Komponente, Ereignisse zu senden oder zu empfangen,
indem sie Ereignisauslöser beziehungsweise Ereignisempfänger der Komponen-
tendefinition hinzufügen:
Ereignisauslöser (engl.: event sources): Ereignisauslöser in Komponenten
haben Referenzen zu Consumer-Schnittstellen und geben Ereignisse eines
speziellen Typs zu einem oder mehreren Ereignisempfänger, oder an einen
Ereigniskanal weiter.
Ereignisempfänger (engl.: event sinks): Ereignisempfänger liefern Consu-
mer-Schnittstellen, an die andere Entitäten (Clients, Komponenten, usw.), die
Ereignisse eines bestimmten Typs senden.
Optional können Entwickler auch angeben, ob mehrere Empfänger ein Ereignis
empfangen sollen, oder ob dies explizit nur einem Empfänger ermöglicht wird.
Konfiguration von CORBA-Komponenten.
Eine CORBA-Komponente besitzt Attri-
bute, welche eine Konfiguration der Komponente ermöglichen. Im Sinne der Wieder-
verwendbarkeit dienen sie dabei in erster Linie zur Bestimmung des Verhaltens, aus
einer Menge möglicher Verhaltensmuster. Dadurch soll die Komponente die Möglich-
keit haben, an spezielle Verwendungssituationen angepasst werden zu können. Der
Quellcode der Komponente muss dabei nicht geändert werden [CORBA 02].
Zugriff auf die Attribute wird über Accessor-Methoden und Mutator-Methoden er-
möglicht. Accessor-Methoden liefern nur die Werte von Attributen, verändern aber
nicht den Zustand der Komponente. Das heißt die Attribute können nur gelesen wer-
den. Mutator-Methoden können den Zustand der Komponente verändern, sie können
auf die Attribute lesend und schreibend zugreifen [CORBA 02].
Container für Komponenten.
Ein Container bildet eine Schale um die Komponente
und stellt ihr verschiedene Programmierschnittstellen zur Verfügung. Die Grundüber-
legung hierfür ist, dass eine Komponente kein Wissen über die Interaktion mit dem
darunter liegenden System benötigt, dies bewirkt Plattformunabhängigkeit [Stal 00].
Die Common Object Request Broker Architecture
15
Bild 3: Entwicklersicht auf Komponenten in CORBA
Ein Container weist zwei unterschiedliche Arten von Programmierschnittstellen
auf:
1. External API
3
: Definiert die Schnittstellen, die einem Client verfügbar gemacht
werden. Hierzu zählen die Äquivalenzschnittstelle, die Facetten und das Home.
2. Container API: Definiert ein Framework, das dem Komponenten-Entwickler ver-
fügbar ist. Hierbei wird zwischen internen Schnittstellen (engl.: internal interfa-
ces) und Rückruf-Schnittstellen (engl.: callback interfaces) unterschieden. Über
interne Schnittstellen ist es der Komponente möglich, die vom Container ange-
botenen Dienste zu benutzen. Die Rückruf-Schnittstellen sind innerhalb der Kom-
ponente zu entwickeln. Sie stehen dem Container zur Verfügung.
In diesem Kontext existieren zwei unterschiedliche Ausprägungen, um Komponen-
tenreferenzen mit oder ohne einen Persistenzstatus zu verwalten: Entity Container für
persistente Container und Session Container für eine transiente Verwaltung von Kom-
ponenten [CORBA 02][Stal 00].
Zwischen dem Container, der zu Grunde liegenden CORBA-Implementierung (dem
Portable Object Adapter (POA)) und den CORBA-Diensten existieren wiederum drei
unterschiedliche Interaktionsmöglichkeiten - die Container Implementation Types:
Wenn ein Servant
4
sämtliche Instanzen eines Komponententyps repräsentiert, dann
spricht man von einer Interaktion des Typs stateless, wobei beim Typ conversional
zu jeder Instanz ein eigener Servant zugeordnet wird. Bei persistenten Containern
3
Application Programming Interface (API)
4
Eine Instanz der Objektimplementierung wird in der CORBA-Spezifikation als Servant bezeichnet.
Servants werden von einer Server-Anwendung erzeugt.
Die Common Object Request Broker Architecture
16
gibt es nur einen Implementierungstyp, der durable genannt wird. Auch bei diesem
wird jede Komponente mit einer eindeutigen Referenz auf einen Servant verbunden
[CORBA 02].
Daraus ergeben sich vier Komponentenkategorien als Kombination von Con-
tainertyp, Container Implementierungstyp sowie Primärschlüsseln (siehe Tabelle 1)
[CORBA 02]:
Kategorie
Containertyp
Implementierungstyp
Primärschlüssel
Service
Transient
Stateless
Nein
Session
Transient
Conversational
Nein
Process
Transient
Durable
Nein
Entity
Persistent
Durable
Ja
Tab. 1: CORBA Komponentenkategorien
Die Architektur des Container-Programming-Modells ist in Bild 4 zusammenge-
fasst.
Bild 4: CORBA Container-Programming-Modell
Schnittstellenbeschreibungen von CORBA-Komponenten.
Die Schnittstellen der CORBA-
Komponenten wurden bis zur CORBA-Version 2.3 mit Hilfe der Interface Definition
Language (IDL) beschrieben. Mit der Version 3.0 erfolgt die Beschreibung in einer
Erweiterung der Interface Definition Language, der Component Interface Definition
Language (CIDL). Damit wurde eine deklarative Sprache definiert, um die Entwick-
lung und den Einsatz von Persistenzmechanismen einer Komponente zu beschreiben.
Die Component Interface Definition Language stellt dem Entwickler abstrakte
Die Enterprise JavaBeans der Java 2 Enterprise Edition
17
sprachliche Mittel zur Verfügung, um eine Komponente sowie deren Zusammenwir-
ken mit Persistenzmechanismen zu beschreiben. Ein Übersetzer erzeugt daraus pro-
grammiersprachliche Lese- und Schreiboperationen zum Zugriff auf das zu Grunde
liegende persistente Speichermedium [Stal 00].
Zur Speicherung von persistenten Zuständen sieht das Komponentenmodell zwei
Möglichkeiten für die Zuständigkeiten vor [Stal 00]:
1. Ist der Container für die Durchführung der Persistenzmechanismen zuständig,
spricht man von Container managed Persistence. Der Container erzeugt dann
automatisch die benötigten Speicher- und Ladeoperationen und führt diese aus.
2. Wenn der Entwickler diese Aufgabe nicht dem Containern übertragen, sondern
stattdessen selbst für die entsprechende Aktion zuständig sein will, dann spricht
man von Component managed Persistence. Er kann sich dabei des Persistenz-
dienstes bedienen oder stattdessen proprietäre Mechanismen einsetzen.
Komponentenbeschreibung mittels Descriptoren.
Zur ,,Verpackung" von einer oder
mehreren Komponenten dienen Archive, die so genannten Component Archive (CAR)
Dateien. Neben den Implementierungs- und Ressourcendateien sind XML
5
-basierte
Beschreibungen, die Descriptoren genannt werden, Teil dieser Auslieferung. Die Kom-
ponenten erhalten einen Softwarepaket-Descriptor, der Informationen zu den ausführ-
baren Dateien im Archiv enthält. Für jeden Komponententyp gibt es einen Descriptor,
der den Typ, die Schnittstellen und weitere Informationen enthält [Stal 00].
2.2.2
Die Enterprise JavaBeans der Java 2 Enterprise Edition
,,The Enterprise JavaBeans architecture is a component architecture for the
development and deployment of component-based distributed business app-
lications. Applications written using the Enterprise JavaBeans architecture
are scalable, transactional, and multi-user secure. These applications may
be written once, and then deployed on any server platform that supports the
Enterprise JavaBeans specification."
Linda G. DeMichiel, Sun Microsystems
In diesem Unterabschnitt wird eine Einführung in Enterprise JavaBeans (kurz
EJB) gegeben. Die aktuelle Version, die hierbei Verwendung findet, ist die Enterprise
JavaBeans 2.1 Specification. Zu Beginn werden die Ziele dieser Spezifikation vorge-
stellt, danach werden die verschiedenen Typen von Enterprise JavaBeans beschrieben
5
Extensible Markup Language (XML)
Die Enterprise JavaBeans der Java 2 Enterprise Edition
18
und schließlich wird das Komponentenmodell aus Clientsicht und Entwicklersicht be-
trachtet.
Enterprise JavaBeans Spezifikation
Enterprise JavaBeans sind eine vollständige Spezifikation für Server-Komponenten.
Sie wurde von Sun Microsystems, zusammen mit anderen Herstellern von Middle-
ware- und Datenbank-Produkten entwickelt. Es wurde ein Standard entwickelt, wel-
cher komponentenbasierte, transaktionsorientierte und mehrschichtige Anwendungen
in Java realisiert. Die EJB Spezifikation wird durch große Teile der Industrie gefördert
(unter anderem IBM, Oracle, Bea Systems, Borland) [Backschat 02].
Ziele der EJB Spezifikation
Die Ziele der EJB Architektur lassen sich wie folgt zusammenfassen [EJB 02]:
£ Die EJB Spezifikation soll die Standard-Komponentenarchitektur für verteilte ob-
jektorientierte Geschäftsanwendungen in der Programmiersprache Java werden.
£ Die EJB Spezifikation soll das Entwickeln von Anwendungen erleichtern, indem
sich der Entwickler nicht mehr um die technischen Details, wie Transaktions- und
Zustandsverwaltung, Persistenz, Sicherheit, Nebenläufigkeiten und Ressourcen-
verwaltung kümmern muss.
£ Die EJB Spezifikation folgt der ,,Write Once, Run Anywhere"
6
Philosophie.
£ Kompatibilität soll sowohl im Rahmen der bestehenden Java-APIs, als auch mit
Server-Systemen von Drittanbietern und CORBA-Protokollen gewährleistet sein.
£ Die EJB Spezifikation soll die Verwendung und die Entwicklung von Web-
Services ermöglichen.
Entsprechend den vorgestellten allgemeinen Zielen, kann die EJB Spezifikation
sowohl als herstellerunabhängiger Vorschlag für die Entwicklung mehrschichtiger
Client/Server-Anwendungen als auch als Integrationsplattform in heterogenen Syste-
mumgebungen verstanden werden [Schmietendorf 02].
Typen von Enterprise JavaBeans
Es gibt verschiedene Typen von Enterprise JavaBeans (siehe Bild 5), die jeweils für
bestimmte Einsatzbereiche vorgesehen sind [Backschat 02]:
6
Ohne Neukompilierung oder Änderung des Quelltextes lauffähige Softwareeinheit oder Anwendung, auf jeder beliebigen
Plattform.
Die Enterprise JavaBeans der Java 2 Enterprise Edition
19
Bild 5: Typen von Enterprise JavaBeans
£ Entity Beans: Entity Beans modellieren Daten-Entitäten, mit dauerhaft gespei-
cherten Daten (persistente Daten). Bei diesen Enterprise JavaBeans besteht nicht
für jeden Client eine eigene Instanz, sondern für alle Clients eine gemeinsame,
auf die jedoch ein gleichzeitiger Datenzugriff möglich ist. Entity Beans werden
meist durch eine Datenbank verwaltet und können somit auch vor Serverabstür-
zen gesichert werden.
Man unterscheidet wiederum zwei Typen von Entity Beans:
Die Bean Managed Persistence Beans (BMP-Beans) überlassen es dem
Komponentenentwickler, sich um die Persistenz der Daten zu kümmern. Er
ist selbst dafür verantwortlich eine Verbindung zu einem Datenbank-Mana-
gement-System (DBMS) aufzubauen und die nötigen Daten darin zu spei-
chern oder von dort zu laden.
Einfacher wird es dem Entwickler bei Container Managed Persistence Beans
(CMP-Beans) gemacht. Er muss lediglich beschreiben welche Daten er ge-
speichert haben möchte. Der Container baut die Verbindung zum Datenbank-
Management-System auf, um Daten zu speichern oder zu laden. Ein weiterer
Vorteil kann die Unabhängigkeit vom Datenbank-Management-System sein.
£ Session Beans: Session Beans werden dazu verwendet, Anwendungslogik auf
dem Server auszuführen. Eine Session Bean ist nicht persistent. Sobald die Kom-
munikation zwischen dem Client und dem Server beendet ist, kann auch die In-
stanz durch den Container zerstört werden.
Man kann Session Beans in Stateless Session Beans und Stateful Session Beans
unterteilen:
Stateless Session Beans (SLS) besitzen keinen spezifischen Zustand und ste-
hen einem Client nur für die Zeit eines Methodenaufrufes zur Verfügung.
Der Vorteil besteht darin, dass wesentlich weniger Instanzen vorhanden sein
müssen, als Clients vorhanden sind.
Die Enterprise JavaBeans der Java 2 Enterprise Edition
20
Bei Stateful Session Beans (SFS) handelt es sich um kompliziertere Kon-
struktionen. Sie besitzen einen so genannten Conversational State, einen zu-
standsbehafteten Status. Dadurch wird die Stateful Session Bean über ihren
gesamten Lebenszyklus hinweg einem Client zur Verfügung gestellt.
£ Message-Driven Beans: Message-Driven Beans ermöglichen eine Bearbeitung
von Nachrichten die über einen Nachrichtendienst, dem Java Message Service
(JMS), eingehen können. Sie können keinen spezifischen Zustand halten und ha-
ben keine individuelle Identität. Alle eingehenden Nachrichten werden vom Con-
tainer entgegengenommen, der sie dann zur Verarbeitung an eine zuständige In-
stanz weiterleitet.
Session Beans und Entity Beans werden direkt über Schnittstellen angesprochen.
Diese Aufrufe sind synchronisiert, das heißt Session Beans bleiben solange blockiert,
bis die Dienste der Entity Beans abgearbeitet sind. Für Message-Driven Beans wird
hingegen eine asynchrone Kommunikationsform verwendet. Der Client kann unmit-
telbar nach dem Absenden einer Nachricht fortfahren und wird nicht blockiert.
Clientsicht auf Komponenten
Der Zugriff eines Clients auf die Dienste einer Session Bean oder auf eine Entity Bean
erfolgt über folgende Schnittstellen (siehe Bild 6):
£ Home-Interface: Das Home-Interface steuert den Lebenszyklus der Komponente.
Dazu zählen die Erzeugung, die Beseitigung und die Lokalisierung einer EJB-
Komponente.
£ Component-Interface: Das Component-Interface spezifiziert die nach Außen
sichtbaren Dienste der EJB-Komponente.
Bild 6: Clientsicht auf Komponenten in EJB für Session Beans und Entity Beans
Damit ein Client auf eine konkrete EJB-Instanz zugreifen kann, benötigt er eine
Referenz auf das entsprechende Home-Interface. Diese erhält der Client zum Zeitpunkt
der Ausführung über den Namens- und Verzeichnis-Dienst JNDI (Java Naming and
Directory Interface).
Die Enterprise JavaBeans der Java 2 Enterprise Edition
21
Message-Driven Beans reagieren nur auf Nachrichten und haben somit keinen un-
mittelbaren Client. Daher exportieren sie auch keine Schnittstellen für einen Aufruf,
sondern verarbeiten eingehende Nachrichten über den Java Message Service (JMS).
Lokale (engl. local) und entfernte (engl. remote) Clients.
EJB unterscheidet zwei Ar-
ten von Clients, die die Sichtweise des Clients auf die Enterprise JavaBean verändert
[Backschat 02]:
£ Local Clients: Local Clients liegen im gleichen Adressraum des Containers und
werden von derselben Java Virtual Machine (JVM) ausgeführt.
£ Remote Clients: Remote Clients können in einem anderen Adressraum als der
Container liegen, sie laufen beispielsweise in einer anderen Java Virtual Machine
(JVM) ab, oder können sich auf einem anderen Rechner befinden.
Entwicklersicht auf Komponenten
Für den Entwickler einer Enterprise JavaBean besteht diese aus verschiedenen Schnitt-
stellen und Hilfsklassen, der Bean-Klasse selbst, sowie dem Deployment Descriktor.
Diese Bestandteile seien im Folgenden beschrieben [Backschat 02]:
£ Remote Home-Interface: Das Remote Home-Interface wird von Remote Clients
aufgerufen und übernimmt die Steuerung des Lebenszyklus der Enterprise Java-
Bean.
£ Local Home-Interface: Das Local Home-Interface übernimmt dieselben Aufga-
ben wie das Remote Home-Interface, ist jedoch nur für Local Clients zugänglich.
£ Remote Component-Interface: Das Remote Component-Interface deklariert alle
Methoden die eine Bean-Klasse zur Verfügung stellt. Diese Methoden werden
Geschäftsmethoden genannt.
£ Local Component-Interface: Das Local Component-Interface erfüllt denselben
Zweck wie das Remote Component-Interface. Es ist jedoch nur für Local Clients
zugänglich.
£ Bean-Klasse: In der Bean-Klasse werden alle Geschäftsmethoden des Home-In-
terface und des Component-Interface implementiert. Weiterhin enthält sie noch
zusätzliche Methoden, die direkt vom Container aufgerufen werden und zur Ver-
waltung der Bean-Instanzen dienen.
Die Zuordnung der Schnittstellen-Methoden auf die Bean-Klassen wird vom
Container übernommen. Der Container generiert die Klassen für die Kompo-
nenten-Schnittstellen, in denen dann die Methodenaufrufe an die Methoden der
Die Enterprise JavaBeans der Java 2 Enterprise Edition
22
Bean-Klasse delegiert werden. Container werden auf Seite 22 genauer beschrie-
ben.
Für die Methoden aus den Home-Interfaces gibt es keine gleichnamigen Imple-
mentierungen in der Bean-Klasse. Da diese aber dennoch vorhanden sein müssen,
gibt es Konventionen denen diese Methoden entsprechen müssen.
£ Primärschlüssel-Klasse: Sie ist nur für Entity Beans nötig und muss nur als eigene
Klasse zu einem Entity Bean definiert werden, wenn sich der Primärschlüssel
nicht auf eine Standard-Klasse von Java abbilden lässt.
£ Deployment Descriptor: Der Deployment Descriptor enthält Metadaten der Kom-
ponente. In dieser XML
7
-Datei werden die Anforderungen einer Enterprise Ja-
vaBean an seine Laufzeitumgebung beschrieben. Die Elemente der XML-Datei
sind von der EJB-Spezifikation vorgegeben. Die Informationen aus dem Deploy-
ment Descriptor werden vom Container ausgewertet, um der Komponente die
gewünschte Laufzeitumgebung zu bieten.
Der Container der Enterprise JavaBeans.
Der Container verwaltet den Lebenszyklus
einer Enterprise JavaBean. Er verwaltet EJB-Objekte für den Zugriff durch Clients,
bearbeitet Transaktionen zwischen Clients und EJB-Objekten, ermöglicht Zugriffskon-
trollen für einzelne Methoden einer EJB und ist für die Erzeugung, das Ressourcen-
Pooling
8
und die Vernichtung von Enterprise JavaBeans zuständig [Backschat 02]. Die
folgenden Zusammenhänge sind in Bild 7 dargestellt.
Bild 7: Beziehungen zwischen den Klassen eines EJB Containers
Nachdem dem Container das Home-Interface, das Component-Interface, die Bean-
Klasse sowie der Deployment-Descriptor zur Verfügung gestellt wurde, erzeugt der
7
Extensible Markup Language (XML)
8
Ressourcen-Pooling ist eine Methode der Leistungsoptimierung.
Die Enterprise JavaBeans der Java 2 Enterprise Edition
23
Container die verschiedenen Klassen, durch die diese Komponenten zusammengehal-
ten werden.
Alle Anfragen von Clients zum Erzeugen, Suchen und Löschen von Enterprise
JavaBeans oder zum Aufruf von EJB-Methoden werden durch den Container vermit-
telt. Entweder verarbeitet er sie selbst, oder er gibt die Anfragen an die entsprechen-
den Methoden des EJB-Objekts weiter. Nachdem ein Client eine Referenz auf eine
Schnittstelle für ein EJB-Objekt erhalten hat schaltet sich der Container in alle Me-
thodenaufrufe bei der Enterprise JavaBean ein, um sie mit erforderlichen Maßnahmen
wie beispielsweise zur Transaktionsverwaltung und Sicherheit zu versorgen. Außer-
dem bietet der Container Unterstützung bei der Persistenz von Enterprise JavaBeans,
indem er entweder den Zustand selbst verwaltet, oder indem er die Enterprise JavaBean
informiert, wenn sie ihren Zustand persistent speichern oder laden muss.
Ein Container kann während seiner Lebenszeit mehrere EJB-Objekte und Objektar-
ten verwalten. Dabei hat er gewisse Freiheiten bei der Verwaltung von Ressourcen.
Beispielsweise kann ein Container entscheiden, ob er eine Enterprise JavaBean vor-
übergehend serialisiert und auf dem Dateisystem des Servers, oder auf einem anderen
persistenten Speicher ablegt. Dieser Vorgang wird als Passivieren einer Enterprise Ja-
vaBean bezeichnet.
Bei der Inbetriebnahme eines EJB-Objekts in einem Server kann angegeben wer-
den, wie der Container die Enterprise JavaBean zur Laufzeit, bezüglich der Transak-
tionsverwaltung, des Ressourcen-Pooling, der Zugriffskontrollen und der Datenpersis-
tenz behandeln soll. Für diesen Zweck sind die Deployment-Descriptoren zuständig.
Diese Einstellungen können für jede Inbetriebnahme eines EJB-Objekts entsprechend
angepasst werden.
Das Deployment der Enterprise JavaBeans.
Die Inbetriebnahme einer EJB innerhalb
eines Containers wird als Deployment bezeichnet. Dazu gehören die folgenden Schrit-
te:
1. Die Deployment-Informationen und die Optionen für die Enterprise JavaBean
werden in Form des Deployment-Descriptors angegeben. Die Informationen in
diesem Deployment-Descriptor umfassen die Namen der Klassen, die als Compo-
nent-Interfaces, Home-Interfaces und Bean-Klassen der EJB dienen, sowie Op-
tionen für die Transaktionsunterstützung und Einstellungen für die Zugriffskon-
trolle. Zusätzlich zu der grundlegenden Deployment-Information erfordern die
verschiedenen Typen von Enterprise JavaBeans (siehe Seite 18) jeweils eine Rei-
he zusätzlicher Metadaten [Backschat 02].
Die Assemblies des .NET Frameworks
24
2. Generierung der vom Container zur Verfügung gestellten Klassen.
3. Verpackung der Enterprise JavaBeans in einem EJB-Jar-Archiv. Darin werden
alle für die Komponente relevanten Dateien zusammengefasst. Viele Entwick-
lungsumgebungen für Enterprise JavaBeans, können dieses Archiv automatisch
erzeugen. Der Komponentenentwickler kann es aber auch durch einen einfachen
Befehl selbst erzeugen [Backschat 02].
2.2.3
Die Assemblies des .NET Frameworks
,,The Microsoft
R
.NET Framework is an important new component of the
Microsoft Windows
R
family of operating systems. It is the foundation of the
next generation of Windows-based applications that are easier to build, de-
ploy, and integrate with other networked systems. [...] The .NET Framework
helps software developers and systems administrators more easily build and
maintain systems with improvements toward performance, security, and re-
liability."
Microsoft Corporation
Dieser Unterabschnitt gibt eine Einführung in die neueste Komponententechnik von
Microsoft, die Bestandteil des .NET Frameworks (.NET wird als ,,dot-net" gesprochen)
ist. Zu Beginn wird auf die Entwicklungsgeschichte der Komponententechniken von
Microsoft eingegangen, danach werden das .NET Framework und dessen Software-
Komponenten beschrieben.
Entwicklungsgeschichte der Komponententechniken von Microsoft
Die Komponententechniken von Microsoft wurden im Gegensatz zu CORBA oder
EJB, nicht am ,,Reißbrett" geplant. Vielmehr stellen diese gewachsene Standards dar,
dessen Entwicklung im Wesentlichen durch die Produktpflege und durch Marketing-
maßnahmen beeinflusst wurden [Gruhn 00]. Im Folgenden werden die einzelnen Ent-
wicklungen kurz beschrieben.
Das Component Object Model (COM).
Microsofts Component Object Model (COM)
wurde erstmals 1993 veröffentlicht und ist auf Windows-Betriebssystemen allgegen-
wärtig. Es stellt den Standard dar, auf den alle anderen Komponentenmodelle von Mi-
crosoft aufgebaut wurden.
COM ist ein binärer Standard, der die Kommunikation von Objekten regelt, die
sich auf einem Rechner mit einem Windows-Betriebssystem befinden. Es wird nicht
Die Assemblies des .NET Frameworks
25
vorgeschrieben, in welcher Programmiersprache die Komponenten entwickelt werden
müssen. Es werden lediglich Schnittstellen definiert, sie stellen die einzige fundamen-
tale Entität von COM dar [Szyperski 02].
Distributed COM (DCOM).
Um COM das Verteilen der Komponenten über ein
Netzwerk zu ermöglichen, wurde es 1996 um ein Netzwerkprotokoll erweitert und
Distributed COM (DCOM) genannt.
Ermöglicht wird die Kommunikation über Rechnergrenzen hinweg, durch Nutzung
von Remote Procedure Calls (RPC). Dadurch ist es möglich, zahlreiche verbindungs-
orientierte und verbindungslose Netzwerkprotokolle (zum Beispiel TCP, UDP, IPX,
usw.) zu verwenden.
OLE und ActiveX.
Um den Begriff OLE, das für Object Linking and Embedding
steht und den Begriff ActiveX, besteht einige Verwirrung. OLE in der ursprünglichen
Bedeutung bezog sich nur auf die von Microsoft benutzten Verbunddokumente. Die
OLE Version 2 bezog dann zusätzlich COM mit ein, Microsoft nannte dies aber nach
wie vor OLE. Anfang 1996 änderte Microsoft seine Meinung und wählte als neuen
Markennamen für OLE, nun den Ausdruck ActiveX. Damit bezog sich nun OLE er-
neut nur auf die Verbunddokumenttechnik. Daher lässt sich ActiveX als Sammlung von
Techniken, die auf Basis von COM und DCOM definiert sind, bezeichnen. Dies unter-
streicht die fundamentale strategische Bedeutung von COM und DCOM für Microsoft
[Brosius 98].
COM+.
Eine weitere Version von Microsofts COM, ist die Version COM+, sie
wurde 1997 veröffentlicht. COM+ stellt die Vereinigung von COM, des Microsoft
Transaction Server (MTS) und des Microsoft Message Queue Server (MSMQ) dar und
war erstmals in Windows 2000 enthalten [Szyperski 02].
Das .NET Framework.
Die Entwicklung des .NET Framework begann mit der Ent-
wicklung einer neuen Version von COM+. Sehr schnell stellte sich allerdings für Mi-
crosoft heraus, dass .NET sich so weit von COM entfernen würde, dass ein neuer Na-
me gerechtfertigt ist. Zunächst wurde das Konzept Next Generation Windows Service
(NGWS) genannt, seit Juli 2000 verwendet Microsoft den Begriff .NET Framework.
Das .NET Framework bildet den Kern von Microsofts .NET (.NET ist ein Begriff
welcher für eine ganze Reihe von Techniken von Microsoft steht). Die Architektur des
.NET Framework, wird in Bild 8 dargestellt [Reilly 02].
Die Assemblies des .NET Frameworks
26
Bild 8: Die .NET Framework Architektur
Common Language Runtime (CLR)
Die Common Language Runtime (CLR) ist die Laufzeitumgebung von .NET-Program-
men. Sie basiert auf einer virtuellen Maschine mit einem eigenen Befehlssatz, der
Common Intermedia Language (CIL). In diese Sprache wird der Quellcode aller .NET-
Programme übersetzt.
Die Common Language Runtime (CLR) stellt also eine gemeinsame Plattform al-
ler .NET-Programme dar, egal in welcher Sprache sie geschrieben wurden oder auf
welcher Maschine sie laufen [Beer 03].
Assemblies
Die Software-Komponenten des .NET Frameworks werden Assemblies genannt. Sie
sind die Nachfolger der COM-Komponenten [Beer 03]. Um die Akzeptanz des .NET
Frameworks zu fördern, wurde von Microsoft eine Interoperabilität mit COM-Kompo-
nenten sichergestellt.
Assemblies bilden eine Sammlung von Klassen und anderen Ressourcen (zum Bei-
spiel Bilder). Sie werden entweder als EXE-Datei oder als DLL-Datei gespeichert und
ausgeliefert. Als EXE-Datei wird ein ausführbares Programm (von execute), welches
durch einen Übersetzer (engl. compiler) erzeugt wurde, bezeichnet. Eine DLL-Datei
(Dynamic Link Library (DLL)) bezeichnet einen Bibliotheksbaustein.
In Bild 9 werden die einzelnen Bestandteile eines Assemblies verdeutlicht. Die
nachfolgenden Erläuterungen klären die dabei verwendeten Begriffe:
Ende der Leseprobe aus 166 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2004, Komponentenmodelle für Web-Anwendungen, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/223344
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare