Referenzarchitekturen für Web-Applikationen Finale Version

Referenzarchitekturen für Web-Applikationen
Finale Version
Autoren:
Michalis Anastopoulos
Tim Romberg
Kennung
refarch_final
Klassifikation
Version
1.0
20. Dezember 2001
Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministerium für Wirtschaft und Technologie
unter den Förderkennzeichen 16IN0047
und 16IN0048 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung
liegt bei den Autoren.
Inhalt
1 Einführung ....................................................................................................................7
2 Analyse von Architekturanforderungen .......................................................................9
2.1 Einteilung der Anwendung nach den Hauptkritieren..........................................9
2.2 Quantitative Analyse.........................................................................................11
3 Architektur-Überlegungen..........................................................................................15
3.1 Überlegungen zur physikalischen und Prozeß-Sicht der Architektur ...............15
3.2 Überlegungen zur logischen Sicht und Entwicklungssicht der Architektur .....27
4 Notationsformen für den Architekturentwurf.............................................................33
4.1 UML Implementierungsdiagramme..................................................................33
4.2 Modellierung von Web-Architekturen..............................................................35
5 Referenzarchitekturen.................................................................................................39
5.1 2-Tier.................................................................................................................39
5.2 Enterprise (N-Tier)............................................................................................40
5.3 XML-Pipe .........................................................................................................46
5.4 Content Management ........................................................................................48
6 Literatur ......................................................................................................................50
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Einführung
1
Einführung
Neben der Wahl von leistungsfähigen Standardprodukten wie Entwicklungs- und
Laufzeitumgebung ist in der Anfangsphase eines Entwicklungsprojekts die Wahl
einer leistungsfähigen Software-Architektur entscheidend.
Software-Architektur enthält nach [Boehm et al. 1995]:
• „a collection of software and system components, connections and constraints
• a collection of system stakeholder’s need statements
• a rationale, which demonstrates that the components, connections and contraints
define a system that, if implemented, would satisfy the collection of system stakeholder’s need statements”
Software-Referenzarchitekturen haben das Ziel, die Entwicklung von Softwarefamilien zu unterstützen.
Wie in [Kru95] ausgeführt, kann sich Architektur auf verschiedene Systemaspekte
beziehen. Zu unterscheiden sind die vier Sichten
• Logische Sicht
• Entwicklungssicht
• Prozeßsicht und
• Physikalische Sicht
Die logische Sicht macht Aussagen über die logische Entitäten der Anwendungsdomäne und ihre Beziehungen. Die Entwicklungssicht macht Aussagen über die in der
Entwicklung entstandenen Software-Artefakte. Diese beiden Sichten können zusammen als statische Sicht bezeichnet werden. Zur Laufzeit sind dagegen die laufenden
Prozesse interessant (Prozeßsicht) und die physischen Einheiten wie Server und
LAN-Verbindungen, auf denen die Software eingesetzt wird (Physikalische Sicht).
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
7
Einführung
Abbildung 1:4+1
Sichten auf SoftwareArchitekturen
Bei unserer Untersuchung wurde uns schnell klar, daß es die Referenzarchitektur für
Web-Anwendungen schlechthin nicht geben kann. Zu unterschiedlich sind die Anforderungen von Shops, Auktionshäusern oder Diskussionsforen. Zu unterschiedlich
sind auch die uns bekannten und empfehlenswerten Realisierungsformen. Die Variabilität der Referenzarchitekturen ist dabei eine Antwort auf die Variabilitäten der großen Domäne Web-Anwendungen, wie sie unsere Kollegen [John, Andriessens 2001]
untersucht haben.
Im folgenden Teil Analyse von Architekturanforderungen zeigen, wir, dass drei,
maximal vier dieser Variabilitäten ausreichen, um die wesentlichen Anforderungen
an die Referenzarchitektur zu erfassen und das Skalierungsverhalten zu charakterisieren. Danach zeigen wir, wie sich durch eine quantitative Analyse die kritischen Komponenten ermitteln lassen.
8
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Analyse von
Architekturanforderungen
2
Analyse von Architekturanforderungen
2.1
Einteilung der Anwendung nach den Hauptkritieren
Auf die zu wählende Referenzarchitektur wirken sich vor allem die Variabilitäten in
den von [John, Andriessens 2001] so genannten „horizontalen Domänen“ aus. So
z.B.
• in der Teildomäne Informationsaufbereitung: Sind die angezeigten Informationen statisch oder dynamisch? Bei einer dynamischen Informationsaufbereitung
ist die darzustellende Information von Eingaben des Benutzers abhängig.
• in der Teildomäne Session Management : Gibt es Sitzungszustand (Session
State) und ist dieser so umfangreich, dass er nicht allein in der URL oder in
einem Cookie gespeichert werden kann?
• in der Teildomäne Benutzerinformationen : „Kennt“ die Anwendung ihre
Benutzer, z.B. in Form eines Benutzerprofils, oder nicht?
• in der Teildomäne Transaktionsmanagement : Findet konkurrierender Schreibzugriff auf Daten von mehreren gleichzeitigen Sessions statt?
Nach unseren Beobachtungen sind diese vier Punkte die wesentlichen Variabilitäten,
die zur Wahl einer bestimmten Referenzarchitektur zur Realisierung der WebAnwendung führen. Dies ist besonders in frühen Phasen eines Projekts sehr interessant, denn die Referenzarchitektur beantwortet gleichzeitig die Frage nach den notwendigen Infrastrukturkomponenten und nach dem Skalierungsverhalten.
Abbildung 2:Features von BeispielAnwendungen
Dynamische Inhalte Sitzungszustand
Benutzerinformation Transaktionen
Spiegel Online (Nachrichten) -
-
-
-
Yellow Map (Branchen-verze-+
ichnis)
-
-
-
Bahnauskunft (Komplexere
Abfragen über mehrere
Seiten)
+
+
-
-
Amazon (Buchhandel)
+
+
+
+ (nur Bestellvorgang)
Online-Banking
+
+
+
+
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
9
Analyse von
Architekturanforderungen
Die vier Variabilitäten sind dabei nicht unabhängig. So haben Anwendungen mit
umfangreichem Sitzungszustand notwendigerweise dynamische Inhalte. Theoretisch
sind zwar viele Kombinationen denkbar. Sowohl von der praktischen Realisierung
(siehe obere Tabelle) als auch von den typischen Features der Standardumgebungen
her ergibt sich aber eine Ordnung gemäß der ansteigenden technischen Komplexität,
wie sie das folgende Feature-Diagramm zeigt.
Abbildung 3:Alternative Features der
Webdomäne
Webanwendung
Statische Inhalte
Dynamische Inhalte
Ohne Sitzungszustand
Mit Sitzungszustand
Ohne Benutzerinformation
Ohne Transaktionen auf
gemeinsamen Daten
Mit Benutzerinformation
Mit Transaktionen auf
gemeinsamen Daten
Die erste Variabilität mag trivial erscheinen. Verschiedentlich wurde aber über Firmen berichtet, die sich für ihre Webpräsenz Java-Applikationsserver mit DreiSchichten-Architektur im Wert von mehreren 10 000 Euro angeschafft haben,
obwohl ein Content Managment System die Anforderungen viel besser erfüllt hätte.
(Ein Content Management System kann nur in sehr einfacher Form Seiten dynamisch
generieren - z.B. durch das Zusammensetzen aus mehreren Komponenten oder als
Ergebnisliste von Suchen.) Auch bei vielen anderen Anwendungen gibt es weite
Bereiche, in denen die angezeigten Informationen im wesentlichen statisch sind. Hier
macht es Sinn, den statischen Teil soweit möglich vom dynamischen zu trennen und
den statischen Teil in einer einfacheren Architektur zu realisieren.
Von einer „Anwendung“ sprechen wir natürlich eigentlich nur, wenn es auch einen
dynamischen Teil gibt. Von der Infrastruktur her ergibt sich daraus fast immer die
Notwendigkeit, eine Datenbank einzusetzen, um die Informationen schnell und flexibel zusammenstellen zu können. Alle Referenzarchitekturen, für die dies zutrifft,
haben daher gemeinsam eine Präsentationsschicht (oben dargestellt), die die generierten Inhalte optisch aufbereitet und eine Form der persistenten Ablage der zugrundeliegenden Daten in einer Datenbank (unten dargestellt).
Die zweite Variabilität, umfangreiche Session-Daten oder nicht, hat große Auswirkungen auf die zu wählende Referenzarchitektur. Die verschiedenen Standardumgebungen unterscheiden sich wesentlich darin, wie sie die Session-Daten halten, gegen
Ausfälle sichern, und nach Ablauf einer Timeout-Periode gezielt „vergessen“.
10
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Analyse von
Architekturanforderungen
Die dritte Variabilität, Benutzerdaten oder nicht, beeinflußt die Architektur von den
notwendigen Komponenten her nur wenig. Die Architektur muß lediglich vorsehen,
wo die benutzerbezogenen Daten persistent abgelegt werden. Diese Daten lassen sich
gut partitionieren, da für eine laufende Session im Regelfall nur die Daten des entsprechenden Benutzers benötigt werden. In einer Bankanwendung mit 2000 Konten
können z.B. Kontenbewegungen der ersten 1000 Konten auf dem einen Server, die
der letzten 1000 Konten auf dem anderen Server gehalten werden. Dies wäre z.B.
nicht sinnvoll bei den 2000 Artikeln eines Katalogs. Die Größe der Datenbank wird
bei solchen Anwendungen stark von der Anzahl der Benutzer getrieben. Für die
Anzahl der Zugriffe ist dagegen eher die Anzahl der gleichzeitigen Sessions bestimmend. Wie man dies genau abschätzen kann, wird im nächsten Kapitel beispielhaft
gezeigt.
Die vierte Variabilität betrifft gerade die Daten, die mehrere Sessions potentiell
gemeinsam benutzen. Es kann sich dabei um Katalog- oder Preisdaten handeln, die
lediglich lesend verwendet werden. Oder es finden eben tatsächliche Transaktionen
auf den Daten statt, wie z.B. Gebote bei einer Auktion. Diese Transaktionen stellen
insbesondere dann eine Herausforderung dar, wenn die vielen Sessions auf vielen
Servern verteilt laufen. Es muß eine Synchronisation stattfinden, deren Aufwand mit
der Anzahl der Server steigt und so zu einem unterproportionalen Skalierungsverhalten des Gesamtsystems führt. Um diesen Effekt möglichst gering zu halten, bieten die
unterschiedlichen Standardumgebungen unterschiedliche intelligente Mechanismen
an.
2.2
Quantitative Analyse
Oft werden die Laufzeiteigenschaften eines Systems von der Last auf einige wenige
Komponenten bestimmt. [Menascé, Almeida 2000] zeigen einige quantitative
Modelle, die es erlauben, das Benutzerverhalten, die daraus resultierende Last
und den Ressourcenverbrauch bei Webanwendungen zu ermitteln. Im folgenden zeigen wir ein typisches Vorgehen für eine Anwendung zur Reservierung von Flugtickets.
Die minimale Anwendung besteht aus den drei Use Cases Profil anlegen, Flug
suchen & buchen und Flug stornieren. Nehmen wir an, sie bestehen jeweils aus den
folgenden Schritten:
Profil anlegen
1. Name & Rechnungsadresse
2. Bankverbindung
Flug suchen und buchen
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
11
Analyse von
Architekturanforderungen
1. Anmeldung
2. Angabe Start, Ziel, Datum
3. Auswahl Flug
4. Reservierung von Plätzen (Transaktion!)
5. Reservierung bestätigen
Flug stornieren
1. Anmelden
2. Anzeige gebuchter Flüge
3. Auswahl Flug
4. Stornieren
Um die beschriebene Analyse durchführen zu können, ist zunächst eine Modellierung
der Web-Seiten erforderlich, über die die Use-Cases abgewickelt werden können. Die
Unified Modeling Language stellt nur eine Möglichkeit dar, dies zu tun. Wir wollen
im Folgenden nur den zweiten Use-Case betrachten, da er die wichtige Transaktion
der Reservierung eines Platzes enthält. Das Ergebnis der Modellierung könnte wie
folgt aussehen:
Abbildung 4:Modell
der Webseiten für den
Use Case „Flug
suchen & buchen“
Anmeldung
Angabe Start,
Ziel, Datum
Verfügbare
Flüge
Angaben zur
Reservierung
Flug
Detailinfo
Reservierung
eingebucht
Reservierung
möglich. Bitte
bestätigen
Dies stellt natürlich nur einen sehr vereinfachten Ablauf dar, da in der Praxis noch
wesentlich mehr Zweige existieren dürften. Auch sind in manchen Fällen mehrere
Browserfenster zu berücksichtigen.
Im zweiten Schritt überlegt man sich, welche Komponenten notwendig sind, um die
erforderlichen Informationen zu generieren oder die Entscheidungen (durch Rauten
symbolisiert) zu treffen.
Abbildung 5:Verwendete Komponenten
12
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Analyse von
Architekturanforderungen
Verfügbare
Flüge
Anmeldung
Angabe Start,
Ziel, Datum
Angaben zur
Reservierung
Flug
Detailinfo
Reservierung
eingebucht
Reservierung
möglich. Bitte
bestätigen
Flüge &
Tarife
Benutzerprofile
Flughäfen
Plätze &
Reservierungen
Im vorliegenden Beispiel wird bei der Anmeldung eine Komponente Benutzerprofile
benötigt, um zu entscheiden, ob die Anmeldung gültig war oder nicht. Bei der
Angabe des Starts und Ziels werden Auswahllisten mit Hilfe der Komponente Flughäfen gefüllt. Die Komponente Plätze & Reservierungen stellt über eine Leseschnittstellen verfügbare Plätze zur Verfügung und erlaubt über eine Schreibschnittstelle das
Buchen eines Platzes.
Die Last auf jede dieser Komponenten kann nun abhängig von der Anzahl der begonnenen Sitzungen pro Zeiteinheit ermittelt werden, wenn man die Übergangswahrscheinlichkeiten zwischen den Webseiten kennt, d.h. die Wahrscheinlichkeit, dass ein
Benutzer einen bestimmten Link wählt oder eine bestimmte Entscheidung vom
System getroffen wird.
Man erhält dann nämlich eine Markov-Kette des Benutzerverhaltens, oder, wie
[MeA00] es nennen, einen Customer Behavior Model Graph. Über die Überlegung,
dass jeder Benutzer, der eine Webseite aufruft, sie in irgendeiner Form wieder verlassen muss (und sei es durch Schließen des Browsers), kann man dann die Häufigkeit
der Seitenaufrufe und damit die Last auf die Komponenten leicht bestimmen. In diesem Beispiel gehen wir davon aus, daß die Wahrscheinlichkeiten nur vom aktuellen
Zustand abhängen, und nicht von dem Pfad, auf dem er erreicht wurde, was in der
Praxis natürlich komplexer sein kann.
Im vorliegenden Beispiel schätzt man, dass in 80% der Fälle die Anmeldeinformationen korrekt sind. 90% aller Benutzer entscheiden sich nach der Anmeldung, einen
Flug nachzufragen (10% brechen ab). In der Liste der verfügbaren Flüge ist zu 60%
ein Flug dabei, den der Benutzer sich im Detail ansieht. Und so weiter.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
13
Analyse von
Architekturanforderungen
Wenn man nun davon ausgeht, dass pro Stunde 10 000 Benutzer frisch auf die Seite
Anmeldung kommen, so folgt daraus, dass im Gleichgewicht pro Stunde 10 000
Benutzer diese Seite verlassen müssen. Das bedeutet, dass die Seite Anmeldung
12 500 Mal pro Stunde aufgerufen wird (10 000 geteilt durch 0,8).
Wenn man wissen möchte, wie oft die Seite Angabe Start, Ziel, Datum aufgerufen
wird, so kann man diese Häufigkeit zunächst mit h bezeichnen und sich klarmachen,
dass im Gleichgewicht h = 10 000 + 0,9 * 0,4 * h gilt. Die Seite wird nämlich von den
10 000 Benutzern pro Stunde aufgerufen, die gerade frisch von der Anmeldung kommen sowie 0,9 * 0,4 * h mal von den Benutzern, die von der Seite Verfügbare Flüge
enttäuscht zurückkehren. Daraus folgt h = 10 000 / 0,64 = 15 625. Die anderen Häufigkeiten können ähnlich berechnet werden.
Abbildung 6:Berechnung der Last
10 000 / h
Verfügbare
Flüge
Anmeldung
0,4
Angaben zur
Reservierung
Reservierung
eingebucht
0,7
0,6
0,9
0,2
Angabe Start,
0,8 Ziel, Datum
12 500 / h
Flug
Detailinfo
0,3
Reservierung
möglich. Bitte
0,7 bestätigen
0,5
14 062 / h
8 437 / h
2 953 / h
15 625 / h
8 437 / h
Flüge &
Tarife
Benutzerprofile
Flughäfen
Plätze &
Reservierungen
Man erkennt nun leicht, dass die eigentlichen Transaktionen nur mit einer gemäßigten Rate von 2 953 pro Stunde getätigt werden, also weniger als eine pro Sekunde, so
dass dies vermutlich ein Server gut bewältigt. Angaben über Flughäfen und Flüge
werden dagegen sehr oft abgefragt, so daß es sich evtl. lohnt, diese Daten zu replizieren, zumal sie nur gelesen werden.
14
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
3
Architektur-Überlegungen
Von den Herstellern von Standardumgebugen werden eine ganze Reihe von Referenzarchitekturen vorgestellt, die jeweils auf deren Standardumgebung abgestimmt
sind (siehe [MIC-5], [MIC-6], [SUN-1]). Verschiedentlich wird aber über große
Schwierigkeiten berichtet, größere Anwendungen nach diesen Vorgaben zu realisieren. Auch sind die Empfehlungen auch nur eines Herstellers oft nicht einheitlich und
ändern sich häufig. Man findet andererseits bei verschiedenen Herstellern ähnliche
Überlegungen mit jeweils unterschiedlicher Terminologie.
Als ersten Schritt auf dem Weg zu Referenzarchitekturen haben wir immer wiederkehrende Überlegungen bzw. Entwurfsmuster gesammelt, die sich z.T. in den Frameworks der Hersteller wiederfinden oder in Praxisprojekten erfolgreich verwendet
wurden. Diese Muster können auch unabhängig von den in Kapitel 4 vorgestellten
Referenzarchitekturen benutzt werden.
3.1
Überlegungen zur physikalischen und Prozeß-Sicht der Architektur
In diesen Sichten stehen die Anforderungen Performance, effizienter Einsatz von
knappen Ressourcen und Ausfallsicherheit im Vordergrund.
3.1.1
Zwischenspeicherung (allgemein)
Bevor Clients Serverressourcen nutzen können, müssen sie sie zuerst aktivieren bzw.
initialisieren. Das heißt im Falle von Serverkomponenten, daß eine Instanziierung
nötig ist, die der Komponente ihren Laufzeitcharakter vergibt. Im Falle von Datenbanken ist ein Verbindungsaufbau nötig.
Bei den im Web üblichen hunderten oder tausenden von gleichzeitigen Verbindungen
ist es unmöglich, pro Client-Verbindung beispielsweise eine Datenbankverbindung
aufrecht zu erhalten. Andererseits ist es bei vielen Ressourcen zu zeitaufwändig, sie
bei jedem Request wieder neu zu initialisieren
Um eine akzeptable Systemperformanz zu erreichen, kommen sogenannte Ressource
Pools zum Einsatz. In diesen Pools werden aktive Ressourcen zwischengespeichert
und wiederverwendbar gemacht. Die Ressourcen im Pool benötigen auch eine Initialisierung, bevor sie genutzt werden, allerdings erfolgt sie sehr schnell.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
15
Architektur-Überlegungen
Wenn ein Client eine Ressource aktivieren will, wird zuerst der Zwischenspeicher
nach einer passenden, bereits aktivierten Ressource durchsucht und wenn sie vorhanden ist, wird sie angesprochen. Zudem kann eine Pool-Ressource gleichzeitig mehrere Clients bedienen. Wenn Ressourcen im Pool nicht mehr gebraucht werden, sind
sie Kandidaten für die Entfernung aus dem Pool.
Meistens werden derartige Mechanismen von Standardumgebungen angeboten. Das
heißt, daß die Ressourcen und darüber hinaus die betroffenen Entwickler sich nicht
um die Details der Zwischenspeicherung (z.B. Datenintegrität, Persistenz) und der
Nebenläufigkeit kümmern müssen. Dadurch ist der Prozeß transparent. Das heißt,
daß die Clients nicht wissen müssen, ob sie bereits aktivierte Ressourcen wiederverwenden oder ob sie diese Ressourcen selbst aktiviert haben.
Folgende Abbildungen1 illustrieren das Verhalten von Ressourcen, die an einem Pooling-Szenario teilnehmen.
Abbildung 7:Ressource Pooling:
Zustandsdiagram
Ressource ist
passiv
<< von Infrastruktur angestoßen >>
Ressource vom Zwischenspeicher
entfernen
<<vom Client angestoßen>>
Ressource aktivieren
Ressource im Zwischenspeicher
<<vom Client angestoßen>>
Ressource ansprechen
Ressource ist
aktiv
Ressource
bedient Client
Ressource nicht mehr vom Client gebraucht
1
16
Diese Abbildungen sind nicht UML-konform.
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Abbildung 8:Ressource Pooling: Interaktionsdiagram
Client A
Client B
Infrastruktur
1: Aktiviere
Ressource
<<aktiviere>>
Aktive Ressource
2: Ressource
ansprechen
3:
aktiviere
Ressource
4: Ressource
ansprechen
Zu diesem Zeitpunkt wird
keine Ressource
aktiviert
3.1.1.1 Zwischenspeicherung von Datenbankverbindungen
Der vollständige Aufbau einer Datenbankverdindung ist eine zeitaufwändige Aufgabe. Eine Verbindung muß erstellt und initiliisiert werden. Dazu gehört beispielsweise das Auffinden der Datenbank und das Laden eines Treibers für den DBZugriff. Dann müssen Nutzer durch die Autorisierungs- und Authentifizierungsmechanismen gehen, bevor sie eine Abfrage starten können. Connection Pools kommen
zum Einsatz um die ständige Wiederholung dieser Tätigkeiten zu vermeiden.
Verbindungen mit Connection Pooling werden nach ihrem Aufbau, das heißt für
ODBC nach Vergabe eines eindeutigen Identifizierers für die Verbindung oder für
JDBC nach Instanziierung eines Verbindungdsobjektes, in einem Pool aufbewahrt.
Die Verbindung ist dann für mehrere Clients wiederverwendbar. Wenn ein Client eine
ähnliche Verbindung aufzubauen versucht, nutzt das System die bereits existierende
Verbindung im Pool. Wenn die Pool-Verbindung nicht mehr von Clients gebraucht
wird, wird sie nach einer bestimmten Zeit geschlossen und vom Pool entfernt.
Die Pooling-Technologie wird auch für Verbindungen im allgemeinen eingesetzt, das
heißt nicht nur für Datenbanken. So nutzt der Weblogic Applikationsserver von BEA
ein Pool für Verbindungen zwischen dem Microsoft Information Server, der in diesem Szenario statische HTML-Seiten liefert, und dem Weblogic Applikationsserver,
der hier die dynamischen Inhalte liefert.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
17
Architektur-Überlegungen
3.1.2
Zwischenspeicherung von HTML-Seiten
Ein dynamische HTML-Seite enthält Anweisungen innerhalb des HTML-Quellcodes, die dynamisch kompiliert und ausgeführt werden, wenn ein Client die Seite
erfordert. Nach Ausführung aller Anweisungen entstehen die endgültigen Inhalte, die
dem Client zugeschickt werden.
Die Kompilierung und Ausführung dynamischer Seiten ist zeitaufwändig und das
führt oft zu inakzeptabler Performanz. Aus diesem Grund kommen Caches für
HTML-Seiten zum Einsatz.
Der Entwickler definiert für jede dynamische Seite, die Komponenten der Seite, die
zwischenzuspeichern sind. Diese Komponenten können entweder HTML-Layout
oder ein berechneter Wert sein.
Bei dynamischen HTML-Seiten kommen demnach zwei Arten von Caches zum Einsatz. Der Output- und der der Input-Cache. Im ersten Fall wird der endgültige
HTML-Inhalt, nämlich die Präsentation, zwischengespeichert . Im zweiten Fall werden Daten zwischengespeichert, die unterschiedlich darzustellen sind.
3.1.3
Replikation von Ressourcen
Die Replikation von Ressourcen wird zugunsten der Ausfallsicherheit und der Performanz angewendet. An der Stelle eines einzigen Server, der die verfügbaren Ressourcen verwaltet, werden zusätzliche Server eingesetzt, die Kopien von den Originalressourcen verwalten.
Es existieren zwei Arten von Replikation [Fel98]:
1. Aktive Replikation
Der Client sendet seine Anfrage sowohl an den Server mit der Originalressource als
auch an die Server mit den Repliken. Anschließend werden das Original und die
Repliken aktualisiert und die jeweligen Server senden eine Antwort zurück. Da alle
Repliken die Anfrage bekommen und da der Client üblicherweise auf die erste Antwort wartet, ist ein Ausfall transparent.
Voraussetzung für die aktive Replikation ist, daß die Client-Nachrichiten in der gleichen Reihenfolge bei den Servern ankommen. Dies erledigt meistens die Infrastruktur. Zugunsten der Konsistenz muß die Ressource entweder keinen Zustand zwischen
Operationen verwalten oder der eingenommene Zustand muß nur vom Initialzustand
und der Reihenfolge der bereits verlaufenen Zustände abhängen. Wenn beispielsweise der Zustand der replizierten Ressource auch vom Zustand des Servers abhängt,
auf dem sie läuft, ist keine Konsistenz zu erwarten.
18
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Folgende Abbildung illustriert die aktive Replikation.
Abbildung 9:Aktive
Replikation
Client
Server 1
Server 2
Server 3
1: Anfrage
2: Anfrage
3: Anfrage
4: Antwort
5: Antwort
6: Antwort
2. Passive Replikation
Bei der passiven Replikation, die heutzutage üblicher ist, wird ein Server als Primärserver gekennzeichnet und die restlichen Server als Backup-Server. Clients senden
Anfragen nur an den Primärserver, der anschließend entsprechend die Backup-Server
aktualisiert. Falls der Primärserver ausfällt, ist das System weiter funktionsfähig,
indem ein Backup-Server übernimmt.
In diesem Fall implementiert der Primärserver, nämlich die Infrastruktur, die Logik
für die Konsistenzhaltung der Backup-Server. Der Primärserver wartet auf eine
Bestätigung nach jeder Aktualisierung, die er auf einem Backup-Server versucht.
Nachdem die Backup-Server bestätigt haben, schickt der Primärserver die Antwort
an den Client.
Das ist die einfachste Möglichkeit, um Atomizität und Konsistenz zu gewährleisten.
Mit dieser Möglichkeit ist allerdings keine Erhöhung der Systemperformanz zu
erwarten. Im Hinblick darauf kommen Mechanismen für den Lastausgleich zum Einsatz, den wir nachfolgend behandeln.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
19
Architektur-Überlegungen
Abbildung 10:Passive Replikation
Client
Primärserver
Backup 1
Backup 2
1: Anfrage
2: Aktualisiere
3: Aktualisiere
4: Bestätigung
5: Bestätigung
6: Antwort
3.1.4
Lastausgleich
Lastausgleichsmechanismen erweitern das Konzept der passiven Replikation, um
Skalierbarkeit und bessere Performanz, vor allem bei schreibenden Zugriffen, zu
erreichen.
In einem Lastausgleichsszenario existiert kein Primärserver sondern gleichberechtigte Server, die Bestandteil eines Serverblocks (oder -Cluster) sind. Die Rolle des
Primärservers spielen Stubs1 oder spezielle Lastausgleichskomponenten (Load
Balancers) [BEA-D].
Eine Client-Anfrage landet zuerst bei dem Load Balancer, der die Entscheidungslogik zur Auswahl eines Servers implementiert. Die Entscheidung ist mit der Last
sowohl auf der Komponenten- als auch auf der Netzwerkebene verbunden [Mic-E].
Der Load Balancer sorgt auch für die Haltung der Konsistenz zwischen den Repliken
im Cluster, wenn bei schreibendem Zugriff ein replizierter Zustand zu verändern ist.
Schließlich wird Ausfallsicherheit gewährleistet, indem der Load Balancer einen ausgefallenen Server nicht mehr berücksichtigt.
1
20
Ein Stub ist typischerweise einer Komponente zugeteilt und übernimmt die Ver- und Entpackung der transprortierten Daten.
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
3.1.5
Trennung von Lese und Schreib-Schnittstelle (Bulk Read)
Eines der Grundprinzipien der Objektorientierung ist die Kapselung von Daten. Klassen implementieren dabei wohldefinierte Schnittstellen, über die die Daten eines
Objekts gelesen oder geschrieben werden können.
Für persistente Daten verwenden Frameworks wie z.B. Enterprise JavaBeans das
Konzept der Business Objects, wie sie u.a. [Sut 1997] und [Eel 1998] vorgeschlagen
haben. Der Zugriff auf die persistenten Daten erfolgt dabei nicht über die DatenbankAPI, sondern über die Schicht der Business Objects, also Objekte einer objektorientierten Sprache. Der Verwender hat somit eine im Vergleich zum relationalen Modell
reichhaltigere, objektorientierte Sicht auf die Daten. Das Framework bzw. die Business Objects selbst sind dann dafür verantwortlich, die entsprechenden Transaktionen
auf der Datenbank durchzuführen.
In einer Umgebung, in der die Anwendung über mehrere Server physikalisch verteilt
werden soll, kann es aus mehreren Gründen ineffizient sein, Lese- und Schreibzugriffe über die gleiche Objektinstanz durchzuführen:
Als „Bulk Read“ Zugriffe werden Lesezugriffe bezeichnet, bei denen eine Menge
von Datensätzen der gleichen Tabelle ausgelesen werden muss. Diese Zugriffe sind
sehr typisch, wenn der Benutzer z.B. einen Artikel aus einer Liste aller Artikel auswählen soll. Bei einem klassischen Business Object-Ansatz müssten zunächst für
jeden Artikel der Liste eine Objektinstanz der Klasse Artikel instanziert werden, um
dann z.B. der Präsentationsschicht zu erlauben, die darin enthaltenen Daten auszulesen. Diese Instanzierungen können je nach Plattform sehr viel Zeit in Anspruch nehmen.
Das Problem verschärft sich, wenn in der Abfrage Daten aus verknüpften Objekten
gebraucht werden. Dies ist sehr ärgerlich, weil die relationale Datenbanktechnologie
hierfür schon lange sehr performante JOIN-Mechanismen bereitstellt.
Zweitens kommen die Überlegungen zur physikalischen Verteilung der kapselnden
Funktionalität zu sehr unterschiedlichen Ergebnissen je nachdem, ob es sich um
lesenden oder schreibenden Zugriff handelt.
Wie oben schon erwähnt, müssen transaktionale Schreiboperationen immer zwischen
den verschiedenen phyiskalischen Instanzen einer logischen Entität synchronisiert
werden, was die Verteilung nicht sehr effizient macht. Bei Lesezugriffen hingegen
läßt sich der Durchsatz durch Verteilung erheblich steigern.
Aufgrund dieser und anderer Schwierigkeiten wird von verschiedenen Autoren ([Hun
1998], [Hal 1997]) gefordert, den Business Object-Ansatz zugunsten anderer Ansätze
aufzugeben. Wo man sich aber aus anderen Gründen für ein Framework wie Enterprise JavaBeans entschieden hat, bietet sich eine getrennte Implementierung der
Lese-Schnittstelle an:
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
21
Architektur-Überlegungen
Man definiert also eine Klasse, die das eigentliche Business Object mitsamt seiner
transaktionalen (d.h. schreibenden) Business Methoden und der Gültigkeitsprüfungen darstellt. Daneben implementiert man eine Klasse, mit der die dahinterliegenden
Daten schnell in tabellarischer Form ausgelesen werden können. Falls das Framework keine inhärente Möglichkeit bietet, die Konsistenz zwischen diesen beiden
Klassen sowie dem Datenbankschema zu gewährleisten, kann man Codegenerierung
einsetzen (siehe unten).
3.1.6
Asynchroner Nachrichtenaustausch (Messaging)
Alle Serveroperationen, die Client-Komponenten aufrufen, sind in zwei Gruppen einzuordnen. In die synchronen und in die asynchronen Operationen. Im ersten Fall muß
ein Client gesperrt bleiben, bis die Antwort auf seine Anfrage von der Serverkomponente ankommt. Im zweiten Fall steht die Client-Komponente nach Abschicken einer
Nachricht weiter zu Verfügung. Diese Möglichkeit wird in erster Linie von den Messaging-Technologien unterstützt.
Zur Realisierung von asynchronen Operationen gibt es folgende Möglichkeiten:
– Einwegoperationen
– Callback
– Polling
– Asynchrones, ereignisgesteuertes Messaging
1. Einwegoperationen
Mit dem Standard-Nachrichtenaustausch (z.B. durch die Nutzung von StandardCORBA oder -Java) sind asynchrone Aufrufe durchaus möglich. Einweg-Operationen können beispielsweise asynchron sein. Diese Operationen werden dadurch
gekennzeichnet, daß die Client-Komponente eine Nachricht verschickt und auf keine
Antwort wartet. Eine typische Einweg-Operation ist eine Bestätigung.
2. Callback
Hier wird einer Einweg-Operation eine Referenz auf dem Client übergeben, so daß
der Server zu einem späteren Zeitpunkt den Client ansprechen kann (Callback).
Alternativ kann ein Client parallellaufende Threads nutzen, um blockierende Aufrufe
zu vermeiden. Das heißt, ein Thread verschickt die Nachricht und bleibt gesperrt, bis
eine Antwort da ist, während ein anderer, parallellaufender Thread sich um die restliche Funktionalität der Client-Komponente kümmert.
3. Polling
22
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Bei diesem Ansatz verschickt die Client-Komponente eine Nachricht und blockiert
nicht. Stattdessen übeprüft sie regelmäßig, ob der Server eine Antwort fertiggestellt
hat und wenn ja, nimmt sie diese Antwort auf. Die Überprüfung erfolgt eigentlich
auch als eine Nachricht, die diesmal synchron verschickt wird. Auch hier kann der
Einsatz von Threads sinnvoll sein.
Die bisher beschriebeneni Möglichkeiten sind allerdings mit Nachteilen behaftet. So
ist bei Einwegoperationen keine Zuverlässigkeit der Zustellung gewährleistet. Im
Falle von Callback & Threads muss komplizierter Code geschrieben werden. Polling
produziert viele Nachrichten, was die Netzwerkverbindungen und die Systemperformaz negativ beeinflußt.
4. Asynchrones, ereignisgesteuertes Messaging
Das asynchrone, ereignisgesteuerte Messaging kommt zum Einsatz, um genau diese
Probleme zu lösen. Mit dem ereignisgesteuerten Messaging ist also ein Nachrichtenaustausch mit folgenden Charakteristiken möglich:
• Asynchron: Sender müssen nicht blockieren
• Bidirektional: Sender und Empfänger tauschen Nachrichten basierend auf Ereignissen aus.
• Quality of Service: Der Messaging-Dienst schützt Nachrichten vor Ausfällen und
sorgt für den sicheren Nachrichtentransport. Zudem hat jeder Beteiligte grob- bis
feingranulare Kontrolle über die Qualität des Messaging. Er kann beispielsweise
auf verschiedenen Ebenen Prioritäten oder Timeouts sowie transaktionale oder
Persistenzattribute setzen.
Nachfolgend beschreiben wir Muster für das asynchrone Messaging. Die Ereignisverwaltung bezieht sich mehr auf funktionale Eigenschaften und deswegen behandeln wir sie im Abschnitt 3.2.
• Asynchronous Client Connector
Folgende Abbildung illustriert den Asynchronous Client Connector [Gom01]. Das
Muster nutzt eine Connector-Komponente, die zwei parallellaufende Stubs für die
aus- und eingehende Nachrichten enthält. Antworten aus dem Server werden erst in
einem Puffer gespeichert, von dem der Client sie empfangen kann.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
23
Architektur-Überlegungen
Abbildung 11:Asynchronous Client Connector
<<Connector>>: Asynchronous Client Connector
<<Ressource>>
: Network
:Client Message
Input Buffer
4:send_reply
(Response)
:Client Return
Stub
:Client Call Stub
3:forward_reply
(PackedResponse)
2:forward_msg
(PackedMessage)
5:receive_response
(Response)
1:send_msg(Message)
<<Component>>
: Asynchronous Client
• Shared Queue
Warteschlangen (Queues) sind ein Standard-Feature von Messaging-Umgebungen.
Sender legen asynchron ihre Nachrichten in die Warteschlange und Empfänger nehmen Nachrichten von der Warteschlange heraus. Letzteres kann so bald wie möglich,
in Gruppen oder periodisch passieren.
Die Warteschlange wird gemeinsam und parallel von mehreren Sendern und Empfängern verwendet. Die Messaging-Infrastruktur (Queue Manager) sorgt für diese
Nebenläufigkeit jeder Warteschlange, die sie verwaltet, sowie für andere Dienste wie
Routing, Priorisierung und anderes. BEA Tuxedo (vgl. [BEA-A],[BEA-B]) und
Microsoft Message Queuing ( vgl. [Mic-A],[Mic-B]) sind Beispiele von MessagingUmgebungen, die Queues einsetzen.
Nachdem eine Nachricht empfangen und verarbeitet wurde, ist es üblich, daß Sender
und Empfänger Rollen tauschen, damit der Sender die Antwort auf seine Nachricht
empfangen kann. Diese Art der Kommunikation ist auch unter dem Begriff “Asynchrone Peer-To-Peer-Kommunikation” bekannt, da die Beteiligte selbständige gleichrangige Maschinen (Peers) sein können und nicht unbedingt Clients und Server.
24
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Abbildung 12:Message Queues
Sender
Empfänger
enqueue(message)
dequeue(message)
Queue
Manager
Queue
Manager
routing
authentication
prioritization
...
send
3.1.7
<<shared>>
Empfänger
Queue
dispatch
Verbindungslose Schnittstelle
Manche Komponenten haben Schnittstellen, in denen Methodenaufrufe im Kontext
der aktuellen Verbindung zum Client interpretiert werden müssen. Beispiel wäre ein
Warenkorb:
Warenkorb
+ArtikelHinzufügen(in ArtikelNr, in Anzahl)
+BestellungAbschliessen()
Die Methode BestellungAbschliessen ist nur im Kontext der Verbindung zu interpretieren. Wird sie von Client A aufgerufen, so werden genau die Artikel bestellt, die
Client A während seiner Verbindung mit der Methode ArtikelHinzufügen gewählt
hat. Ruft sie Client B auf, werden u.U. ganz andere Artikel bestellt.
Pro Verbindung muss die Komponente also entsprechende Serverressourcen belegen.
Falls die Komponente auf mehreren Servern läuft, müssen alle Anfragen eines
bestimmten Clients immer an die gleiche Instanz geleitet werden.
Bei einer, wie im Web typischen, sehr hohen Anzahl von Verbindungen skalieren solche Komponenten entsprechend schlecht. Besonders dann, wenn sie außerdem persistenten Zustand verwalten, und die in Abschnitt 3.1.3 Replikation von Ressourcen
beschriebenen Konsistenzprobleme auftreten. Komponenten, die eine hohe Anzahl
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
25
Architektur-Überlegungen
von Clients parallel bedienen müssen, sollten daher nach Möglichkeit mit verbindungslosen Schnittstellen konzipiert werden.
Die Forderung nach einer verbindungslosen Schnittstelle ist nicht gleichzusetzen mit
der Forderung nach einer zustandslosen Komponente, d.h. einer zustandslosen Implementierung.
Grundsätzlich läßt sich eine bestehende, verbindungsorientierte Schnittstelle auf drei
Arten in eine verbindungslose Schnittstelle umwandeln. Zur Illustration verwenden
wir die verbindungsorientierte Schnittstelle einer Leinwand, auf der verschiedene
Clients Linien und Kreise zeichnen können:
Leinwand
+SetzePinselFarbe(in Farbe)
+SetzePinselDicke(in Dicke)
+ZeichneRechteck(in Links, in Oben, in Rechts, in Unten)
+ZeichneKreis(in MitteX, in MitteY, in Radius)
(Dies eignet sich hier besser als der Warenkorb. Mit „in“ kennzeichnen wir Eingangsparameter.)
Die Methoden zum Zeichnen von Rechtecken und Kreisen verwenden hierbei einen
Pinsel, dessen Farbe und Dicke im Verbindungskontext festgelegt sind.
1. Methoden erweitern
Die Methoden werden so um Parameter erweitert, dass ihre Interpretation auch ohne
den Verbindungskontext möglich ist. Wie man sieht, können dadurch manche Methoden überflüssig werden:
Leinwand
+ZeichneRechteck(in Farbe, in Dicke, in Links, in Oben, in Rechts, in Unten)
+ZeichneKreis(in Farbe, in Dicke, in MitteX, in MitteY, in Radius)
2. Grobgranularere Methoden verwenden
Die Schnittstelle wird so umgebaut, dass dort, wo bisher mehrere zusammenhängende Aufrufe nötig gewesen wären, nun ein einzelner Methodenaufruf ausreicht:
26
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Figur
<<serialisierbar>>
+Farbe
+Dicke
+HinzufügenRechteck(in Links, in Oben, in Rechts, in Unten)
+HinzufügenKreis(in MitteX, in MitteY, in Radius)
Leinwand
+ZeichneFigur(in FigurByValue : Figur)
Grobgranulare Methoden haben dabei typischerweise komplexe Parameter, die wie
dargestellt mittels ByValue-Objekten oder XML-Dokumenten übertragen werden
können.
3. Verbindungszustand durch persistenten Zustand ersetzen
D.h. wir verwenden statt einem „Session“-Pinsel beliebig viele globale Pinsel:
Leinwand
+DefiniereGlobalenPinsel(in Farbe, in Dicke, aus PinselNr)
+ZeichneRechteck(in PinselNr, in Links, in Oben, in Rechts, in Unten)
+ZeichneKreis(in PinselNr, in MitteX, in MitteY, in Radius)
Während die ersten beiden Wege mehr Arbeit auf den Client verlagern, bringt der
dritte Weg oft nicht den gewünschten Effekt bezüglich Skalierbarkeit, da jetzt der
persistente Zustand - sprich, eine u.U. große Anzahl von globalen Pinseln - mit dem
entsprechenden Aufwand verwaltet werden muss.
3.2
Überlegungen zur logischen Sicht und Entwicklungssicht der Architektur
Hier stehen die Effizienz der Entwicklung und die Investitionssicherheit im Vordergrund
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
27
Architektur-Überlegungen
3.2.1
Trennung von Präsentations- und Geschäftslogik
Moderne Webapplikationen werden entwickelt, um eine Vielzahl unterschiedlicher
Benutzer zu unterstützen. Das heißt, daß die Benutzerschnittstelle stark variieren
kann, während die Geschäftslogik für die Erstellung der zu präsentierenden Informationen unverändert bleibt. Der Bedarf an einer Trennung zwischen Präsentations- und
Geschäftslogik wird dadurch deutlich.
Durch eine derartige Trennung ist die gleiche Geschäftlogik für viele Benutzerschnittstellen wiederverwendbar. Das fördert die Skalierbarkeit, da neue GUIs ohne
Aufwand unterstützt werden können. Die Duplizierung der selben Geschäftslogik für
jede Benutzerschnittstelle und der somit enstehende große Aufwand für Entwicklung,
Testen und Wartung werden vermieden. Durch die Trennung wird auch das Personal
besser ausgenutzt, da die GUI-Designer und die Entwickler der Geschäftslogik sich
getrennt auf ihre Arbeit konzentrieren können.
Das wohl bekannteste Entwurfsmuster, das die Trennung von Präsentation und
Geschäftslogik fördert, ist das Model View Controller [Gam95] oder MVC Muster.
Abbildung 13 illustriert dies [Sun-C].
• Das Modell repräsentiert Geschäftsdaten und -regeln. Falls sich eine Datenanderung ereignet, sorgt das Modell dafür, daß alle interessierten Views über diese
Änderung notifiziert werden. Dieser Notifizierungsansatz ist auch als PushModell bekannt. Alternativ wird das Pull-Modell eingesetzt, bei dem die View die
aktuellsten Daten durch einen Modellaufruf bekommt.
• Die View stellt die Modellinhalte dar und kann auf sie zugreifen. Sie ist verantwortlich für die Konsistenz zwischen den präsentierten Inhalten und den Modellinhalten. Deswegen muß sie entsprechend auf Modelländerungen reagieren. Die
View registriert auch Aktionen seitens des Nutzers und leitet sie an den Controller
weiter.
• Der Controller interpretiert Nutzerinteraktionen als Änderungen, die an dem
Modell vorgenommen werden müssen. Für die Ergebnisse dieser Änderungen
wählt der Controller eine geegnete View aus.
28
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Abbildung 13:MVC
Pattern
Model
Anfrage
-kapselt Applikationszustand
-reagiert auf Anfragen
-stellt Funktionalität der Applikation bereit
-informiert die Präsentation über Änderungen
Notifizierung
Zustandsänderung
View
-stellt die Modelle dar
-aktualisiert die Modelle
-leitet Nutzeraktionen an den Controller weiter
-erlaubt dem Controller eine View auszuwählen
Auswahl einer View
Nutzeraktionen
Controller
Aufruf
Ereignis
-definiert das Applikationsverhalten
-bildet Nuzeraktionen afdguf Modellaktualisierungen dar
-wählt eine View für Ergebnisse au
-je Funktionalität gibt es einen Controller
Im Web-Kontext erfährt MVC eine etwas andere Interpretation. Es ist auch hier sinnvoll, die fachliche Funktionalität (Modell), Präsentation (View) und Steuerung (Controller) in getrennten Klassen zu implementieren. Die Frameworks bieten dafür entsprechende Unterstützung - in Java lassen sich z.B. Präsentationskomponenten
relativ leicht mit Java Server Pages, Steuerungskomponenten mit Servlets und
Modelle mit Java Beans implementieren. Die Ereignisweitergabe funktioniert aber
etwas anders als oben dargestellt. Bei der Kommunikation über HTTP kann der Server keine Ereignisse an den Client schicken. Dies wäre bei u.U. Tausenden von Clients, die z.B. alle eine Sicht auf das gleiche Modell haben, auch kaum praktikabel.
Außerdem eignet sich HTML als Präsentationsformat nicht für Änderungen. Stattdessen geht die Kommunikation immer vom Client aus und bewirkt im Normalfall
einen Neuaufbau der Präsentation.
3.2.2
Codegenerierung und Aktive Repositories
Eines der wichtisten Ziele bei der Definition einer Architektur ist die leichte Erweiterbarkeit. Ein wichtiges Prinzip ist dabei die Lokalität von Änderungen. Damit ist
gemeint, dass typische Änderungsanforderungen Änderungen an möglichst wenig
Quellen erforderlich machen. Aktuelle Standardumgebungen erfüllen diese Anforderung im wesentlichen nicht.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
29
Architektur-Überlegungen
Nehmen wir als Beispiel Enterprise JavaBeans und Feldlängen. Nehmen wir an, wir
hätten eine Entität „Kunde“ mit einem Feld „Nachname“. Die Länge dieses Feldes
wird einmal im Datenbankschema definiert. Die zugehörige Entity Bean sollte beim
Ändern des Nachnamens von vorneherein prüfen, ob die Länge zulässig ist, und entsprechend darauf reagieren. Drittens sollte auf der Webseite, in der sich der Kunde
eintragen kann, von vorneherein das Feld Name entsprechend begrenzt sein, um dem
Anwender eine nachträgliche, mühsame Korrektur zu ersparen. Die Information über
die Länge des Feldes „Nachname“ ist also an mindestens drei verschiedenen Stellen
vorhanden. Entsprechend fehlerträchtig kann das Ändern einer Feldlänge sein.
Ähnliche Probleme gibt es beim Ändern eines Feldnamens, von Fremdschlüsselbeziehungen zwischen Tabellen oder von „höherwertigen“ Gültigkeitsprüfungen.Verschärft wird das Problem durch die oben erwähnte Trennung von Lese- und Schreibschnittstelle aus Performanceüberlegungen.
Wir sehen grundsätzlich zwei Möglichkeiten, diesem Problem zu begegnen: Codegenerierung und Aktive Repositories.
Bei beiden Verfahren definiert der Entwickler die entsprechende Information nur an
einer Stelle. Bei der Codegenerierung erzeugt ein Werkzeug die notwendigen statischen Informationen wie Datenbankschema, Quellcode oder HTML-Code. Dieses
Verfahren wird von Enterprise JavaBeans mit der Container Managed Persistence auf
teilweise schon eingesetzt -- dort bleibt das Problem aber grundsätzlich bestehen. Bei
aktiven Repositories steht die Information auch zur Laufzeit an einer zentralen Stelle,
dem Repository zur Verfügung. Dieses Repository kann z.B. die zur Laufzeit zugängliche Schemainformation der Datenbank sein. Inzwischen bieten Datenbankschnittstellen wie JDBC und ODBC hierzu entsprechende Schnittstellen an. Nachteil: Man
ist bezüglich der Art der Information sehr eingeschränkt. Flexibler ist es, die Information in einer eigenen Repository-Komponente, z.B. in eigenen Datenbanktabellen
zu halten. Da die Informationen sich zur Laufzeit nicht oder nur sehr selten ändern,
kann man sie auch hier replizieren bzw. zwischenspeichern, um die Performance
nicht zu gefährden. Ein weiterer Vorteil: Die Schemainformationen werden in weitgehend datenbankneutraler Form definiert und danach auf spezifische Datenbanken
abgebildet.
3.2.3
Interceptors
Die Idee hinter dem Interceptor-Muster ist die transparente Erweiterbarkeit einer
Umgebung. Applikationen sind dabei in der Lage, die Umgebung transparent um
neue Dienste zu ergänzen, ohne den Kern (ORB, Applikationsserver) der Umgebung
und die eigenen Applikationen verändern zu müssen. Die neuen Dienste sind als
separate Interceptors implementiert und werden dem Kern der Umgebung bekanntgemacht (registriert). Diese Dienste interagieren durch festgelegte Schnittstellen
sowohl mit dem Kern als auch mit den Client- oder Serverkomponenten.
30
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Architektur-Überlegungen
Bei komponentenbasierten (COM+, EJB, CORBA Component Model) Applikationsservern müssen Serverkomponenten Services wie Persistenz, Sicherheit, Transaktionen usw. nicht selbst implementieren. Stattdessen brauchen sie nur zu deklarieren
(d.h. entsprechende Attribute setzen), daß sie diese Dienste benötigen, und der Applikationsserver übernimmt den Rest. Wenn eine Komponente beispielsweise die Transaktionsattribute gesetzt hat, fängt (intercept) praktisch die Umgebung alle Nachrichten an die Komponente ab und vergibt ihnen den gewünschten transaktionellen
Charakter.
In diesem Ansatz, der auch als die Interceptor Proxy Variante des Interceptor-Musters
bekannt ist, sind Interceptors Teil des Kerns, nämlich des Applikationsservers. Der
Kern bietet die Interceptor-Services den Applikationen an. Clients sowie Serverkomponenten können keine eigenen Interceptors realisieren, mindestens nicht ohne großen Aufwand. Sie können, wenn gewünscht, die Implementierung der betroffenen
Dienste komplett übernehmen.
Im Gegesatz dazu erweitern die Interceptors bei CORBA (Standardspezifikation) und
(Standard-)COM die Applikationen und nicht den Kern, nämlich den ORB. Sowohl
Clients als auch Server können eigene und separate Interceptors realisieren, die dann
mit dem ORB interagieren.
Abbildung 14:Interceptors
Client
Serverkomponente
Interceptor
Interceptor
Interceptor
Interceptor
Interceptor
Interceptor
ORB
3.2.4
Event Handling
In ereignisgesteuerten Architekturen werden Zustandsänderungen als ausgelöste
Ereignisse wahrgenommen. Dies entkoppelt die Kommunikation zwischen den Komponenten, die Änderungen vornehmen und den Komponenten, die an Änderungen
interessiert sind. Die daduch erreichte Flexibilität hat dazu geführt, daß ereignisgesteuerte Architekturen aktuell häufig zum Einsatz kommen.
Der asynchronen Kommunikation, die früher vorgestellt wurde, liegt oft eine Ereignissverwaltung (Event Handling) zugrunde. Bei ereignisgesteuerten Systemen wird
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
31
Architektur-Überlegungen
der Empfang einer Nachricht als ein Ereignis gesehen, worauf Empfänger entsprechend reagieren.
Die meist bekannten Muster zur Ereignisverwaltung sind: Event Notification
[Rie96], Observer [Gam95] und Publish-Subscribe, das wir nachfolgend beschreiben.
• Publish-Subscribe
In diesem Muster [Kle99] gibt es drei Arten von Komponenten: Die Publishers, die
Subscribers und den Subrscription Manager. Publishers registrieren beim Subscription Manager die Dienste, die sie anbieten. Diese Dienste sind praktisch Daten, die
sich oft ändern und beim Subscription Manager abgelegt werden. Über diese Änderungen der Daten möchten Subscribers informiert werden.
Ein Subscriber meldet bein Subscription Manager sein Interesse an diesen Daten an.
Sobald sich Publisher neue Daten in das Repository legen, werden Ereignisse vom
Manager ausgelöst. Der Manager verschickt anschließend Notifikationen über diese
Ereignisse an alle Interessenten. Folgende Abbildung illustriert eine mögliche Konfiguration für dieses Muster.
Abbildung 15:Das
Publish-Subscribe
Muster
Publisher
......
Publisher
32
Subscriber
Subscription
Manager
......
Subscriber
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Notationsformen für den
Architekturentwurf
4
Notationsformen für den Architekturentwurf
Im vorangegangenen Kapitel wurden einige, im Kontext von Webanwendungen
wichtige Eigenschaften von Komponenten und ihrer Verbindungen identifiziert. Dies
wirft die Frage nach einer entsprechenden Visualisierung auf.
Für den logischen objektorientierten Entwurf hat sich die UML industrieweit durchgesetzt. Für den Entwurf von Software-Architektur, speziell der physikalischen und
Prozeßsicht, werden in der Praxis häufig nichtformale „Box & Line“-Diagramme
verwendet. [Kru95] verwendet Notationen, die nicht vollständig UML-konform sind
und die Darstellung einiger für Webanwendungen wichtiger Aspekte umständlich
machen. Angeregt durch [IBM2001] wollen wir in diesem Kapitel ein UML-Profil
vorstellen, das wichtige Aspekte für Webanwendungen abbildet. Dabei verwenden
wir die von der UML vorgesehenen allgemeinen Erweiterungsmechansimen Contraint, Property und Stereotype und stellen, wo es sinnvoll ist, eine verkürzte grafische Notation vor.
Wir stellen zunächst die Standard-UML-Notation vor und definieren darauf aufbauend Erweiterungen.
4.1
UML Implementierungsdiagramme
[UML99] definiert zwei Arten von Implementierungsdiagrammen: Komponentendiagramme und Deploymentdiagramme.
Komponentendiagramme zeigen die Abhängigkeiten zwischen Softwarekomponenten wie Quellcode-Kompoenten, Objektcode-Komponenten und ausführbaren Komponenten. Eine typische Beziehung ist die Beziehung „verwendet“ (eine sog. Dependency), die durch einen gestrichelten Pfeil von einer Komponente auf eine andere
Komponente oder eines ihrer Interfaces notiert wird:
Abbildung 16:UML
Komponentendiagramm
GUI
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
Update
Planner
33
Notationsformen für den
Architekturentwurf
Dies entspricht einer Abhängigkeit zur Build-Zeit. Die dargestellten Komponenten
sind als Typen zu verstehen. Die Bedeutung des obigen Diagramms ist: Die Komponente GUI verwendet die Schnittstelle Update der Komponente Planner. Man
beachte, dass Methodenaufrufe auch in der Gegenrichtung stattfinden können, wenn
z.B. die Schnittstelle Update einen Abstract Listener enthält.
Deployment-Diagramme zeigen die Konfiguration der Ausführumgebung und der
Softwarekomponenten, der Prozesse und der Objekte, die in ihr ausgeführt werden.
Eine Laufzeitkomponente, die auf einem ausführenden Knoten installiert wurde, wird
innerhalb des als Quader symbolisierten Knotens dargestellt:
Abbildung 17:UML
Deployment-Diagramm
Die dargestellten Komponenten sind dabei als laufende Instanzen zu verstehen. Auch
hier stellt ein gestrichelter Pfeil eine Verwendungsbeziehung dar, allerdings eben im
Sinne von „Die auf Joe’s Machine laufende Instanz der Komponente Planner verwendet die auf dem AdminServer laufende Instanz von Scheduler über die Schnittstelle reservations.“
Die UML erfüllt damit das von [Kru95] vorgegebene Programm zu drei Vierteln. Statische Klassendiagramme in Verbindung mit Packages eignen sich für die logische
Sicht. Statische Klassendiagramme und Komponentendiagramme zeigen die Entwicklungssicht. Die letztgenannten Deployment-Diagramme zeigen die physikalische Sicht. Lediglich die Prozeßsicht findet keine wirkliche Entsprechung.
Prozesse werden in [Kru95] als Einheiten dargestellt, die auf einem ausführenden
Knoten laufen, denen Systemressourcen wie Adressraum und Prozessorzeit zugeordnet werden und die Nachrichten und Ereignisse an andere Prozesse verschicken. Bei
den von uns anvisierten Anwendungen spielen die Laufzeitkomponenten genau diese
Rolle. Insofern wird auch die Prozeßsicht durch Deployment-Diagramme abgedeckt.
34
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Notationsformen für den
Architekturentwurf
4.2
Modellierung von Web-Architekturen
Für die Modellierung von Web-Architekturen bieten diese Elemente eine gute Grundlage, sind aber noch nicht ausreichend. So schlägt [IBM2001] eine Notation vor, in
der explizit zwischen Schreib-Lese-Daten, Nur-Lese-Daten und Cache-Daten unterschieden wird:
Abbildung 18:Komponenten von WebArchitekturen.
Quelle: [IBM ..]
Schreib-Lese-Daten werden als blauer Zylinder, Nur-Lese-Daten als gelber Zylinder
und Cachedaten, Zwischenergebnisse oder replizierte Daten als grüner Zylinder dargestellt (siehe auch Abschnitt Replikation).
Eine weitere Unterscheidung betrifft den Spielraum der Entwicklung: Anwendungen
(lies: grobkörnige Komponenten), die im Zuge des Projekts neu oder weiterzuentwikkeln sind werden von Anwendungen der Partner, zu denen lediglich die Schnittstelle
bekannt ist, und Legacy-Anwendungen unterschieden.
Auf das UML-Modell übertragen, sind sowohl die Daten als auch die Anwendungen
in dieser Notation als Komponenten zu betrachten. Bei beiden existieren sowohl ein
Typaspekt als auch ein Instanzaspekt.
4.2.1
Datencluster
Daten sind dabei als „datenlastige Komponenten“ zu verstehen, mit ggf. mehreren
Schnittstellen, von denen manche nur Lesezugriffe zulassen können. Den Daten oder
der Komponente an sich kann man die Eigenschaft „Nur-Lesen“ schlecht zuordnen.
Alle Daten, die in der Anwendung existieren, müssen irgendwann irgendwie dorthin
gelangen, also geschrieben werden. Da die Komponente diese Daten kapseln sollte,
muss sie dafür eine Schnittstelle anbieten. Diese muss aber nicht für den Webzugriff
zur Verfügung stehen. Andererseits kann man auch einer isolierten Schnittstelle
schlecht formal die Eigenschaft „Nur-Lesen“ zuordnen, auch wenn dies fachliche
sinnvoll erscheint. Den Implementierer einer Schnittstelle hindert ja nichts daran,
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
35
Notationsformen für den
Architekturentwurf
eine globale Statistik der „fachlichen Lesezugriffe“ zu führen, und damit führen dann
Aufrufe der Schnittstelle zu Zustandsänderungen in der Komponente. Die „NurLese“-Eigenschaft ist also sinnvollerweise eine Eigenschaft der Beziehung zwischen
Schnittstellenimplementierung, d.h. der Beziehung zwischen Schnittstelle und Komponente.
Eine datenlastige Komponente wird üblicherweise durch eine Menge von relationalen Tabellen und Beziehungen realisiert. Wir schlagen für eine solche Komponente
den Stereotypen data cluster vor.
Die Zugriffsart der Schnittstelle sollte durch Verwendung der Eigenschaft StateAccess gekennzeichnet werden. Als alternative Notation schlagen wir offene Pfeile vor:
Abbildung 19:Datencluster - UML Standardnotation
{HasEnterpriseState = true}
{StateAccess = readonly}
Lesen
{StateAccess = readonly}
Ändern
{StateAccess = readwrite}
Suchen
{StateAccess = readwrite}
Flüge
<<data cluster>>
Buchen
Flugdaten
Hinzufügen {StateAccess = readwrite}
Abbildung 20:Datencluster - Verkürzte
Notation
Lesen
Suchen
Flüge
Buchen
4.2.2
Ändern
Hinzufügen
<<data cluster>>
Flugdaten
SE
Sichtbarkeit von Daten
Aus den obigen Überlegungen ergibt sich, daß es sinnvoll ist, die Daten hinsichtlich
ihrer Gültigkeit bzw. Sichtbarkeit (Scope) zu unterscheiden. Bei typischen Webanwendungen sind diese Sichtbarkeitsbereiche die Session, der Benutzer (Kunde) und
das gesamte Unternehmen. Dies kann im UML-Modell durch die Eigenschaften
HasEnterpriseState, HasUserState und HasSessionState ausgedrückt werden. Es
werden drei Eigenschaften benötigt, da eine Komponente gleichzeitig session-,
benutzer und unternehmensbezogene Daten verwalten kann. In der verkürzten Notation verwenden wir in der unteren rechten Ecke platzierte SE, SU und SS. Die Unterscheidung zwischen Benutzer- und Unternehmensbereich ist nicht immer leicht zu
treffen und daher optional.
36
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Notationsformen für den
Architekturentwurf
4.2.3
Datenbankschnittstellen
Ein Datencluster wird im Normalfall über generische (d.h. nicht fachliche) relationale Schnittstellen wie ODBC oder JDBC angesprochen. Nur in manchen Fällen werden fachliche Schnittstellen mittels Stored-Procedure-Mechanismen realisiert. Es ist
daher sinnvoll, die Standardschnittstellen durch vereinfachte Pfeile wie in der folgenden Abbildung darzustellen.
Der Stereotyp data cluster wird zusätzlich durch den altbekannten, in [IBM..] verwendeten Zylinder visualisiert.
Abbildung 21:Datencluster mit Standardschnittstelle
Suchen
Flugdaten
Flüge
Buchen
SE
Wenn das Deployment, z.B. im Komponentendiagramm, nicht im Vordergrund steht,
ist es u.U. sinnvoll, funktionale Komponente und Datencluster zu einer Komponente
zusammenzufassen:
Abbildung 22:Komponente mit persistentem Zustand
Suchen
Flüge
Buchen
SE
4.2.4
Weitere Eigenschaften von Schnittstellen
Wie schon erläutert, haben Komponenten mit verbindungslosen Schnittstellen ein
wesentlich besseres Skalierungsverhalten als verbindungsbehaftete. Wie gezeigt,
kann dies mittels der Eigenschaft HasSessionState unterschieden werden, ob eine
Komponente Session State hält oder nicht. Die Eigenschaft HasSessionState läßt sich
aber auch der Schnittstelle zuordnen, z.B. weil man über die anderen Schnittstellen,
die die Komponente implementiert, nichts weiß. In einem solchen Fall notieren wir
verbindungslose Schnittstellen mit einer Null, verbindungsbehaftete Schnittstellen
mit einem S:
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
37
Notationsformen für den
Architekturentwurf
Abbildung 23:SessionState-Eigenschaft
von Schnittstellen
SQL Insert
0
Resultset Cursor
s
<<data cluster>>
Flugdaten
SE
In dem dargestellten Beispiel handelt es sich um einen Datencluster, auf den mit Hilfe
von zwei Schnittstellen zugegriffen werden kann - auch wenn man diese Einteilung
in einer praktischen Anwendung vielleicht nicht treffen würde. Über die Schnittstelle
SQL Insert können Datensätze hinzugefügt werden. Da z.B. bei jedem Aufruf ein
kompletter Datensatz übergeben wird, ist diese Schnittstelle verbindungslos. Bei
Resultset Cursor handelt es sich dagegen um den bekannten Cursor-Mechanismus für
das Lesen von Datensätzen mit solchen Methoden wie GetResultset (z.B. über SQL
Select), NextRecord und PreviousRecord. In diesem Fall muß sich die Komponente
für jede Verbindung die aktuelle Ergebnismenge und die aktuelle Cursorposition
merken.
Eine weitere wichtige Eigenschaft von Schnittstellen ist die Art, in der Aufrufe erfolgen. Wie im letzten Kapitel gezeigt, haben asynchrone Schnittstellen z.T. Vorteile
gegenüber synchronen Schnittstellen. Außerdem sind unidirektionale von bidirektionalen Schnittstellen zu unterscheiden. Bei bidirektionale Schnittstellen können Aufrufe auch in der Gegenrichtung erfolgen, das heißt die Komponente ruft ihren Client
auf - z.B. über einen Abstract Listener. Wir verwenden die in der UML schon für
Nachrichten definierte Eigenschaft asynchronous, und die neue Eigenschaft bidirectional. Die Notation lehnt sich an die in der UML verwendete Notation für Nachrichten an:
Abbildung 24:Art der
Schnittstellenaufrufe
Unidirektional, synchron
Bidirektional, synchron
Unidirektional, asynchron
Bidirektional, asynchron
Wir arbeiten an Notationen für Lastverteilung und Caching. Außerdem verfolgen wir
die Vision, durch eine recht formale Modellierung von Architektureigenschaften Probleme automatisch zu erkennen.
38
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Referenzarchitekturen
5
Referenzarchitekturen
Im folgenden stellen wir einige Referenzarchitekturen vor, die für eine oder mehrere
Kategorien von Webanwendungen eine gute Kombination der vorgestellten Muster
darstellen.
Zur Auswahl einer passenden Architektur sind die vier im ersten Teil vorgestelltenHauptkriterien entscheidend.
Anwendungen mit statischem Inhalt sollte man mit Content-Management-Architekturen realisieren. Eine Spielart für Inhalte, die in verschiedenen Formaten dargestellt
werden müssen, sind XML-Pipe-Architekturen.
Anwendungen ohne Sitzungszustand lassen sich gut in 2-Schichten-Architekturen
realisieren. Auch einfachere Applikationen mit Sitzungszustand lassen sich darin realisieren, wenn sich die Nutzerlast in Grenzen hält. Benutzerinformationen bestimmen
dabei mit das Skalierungsverhalten.
Komplexere Anwendungen erfordern in jedem Fall eine Trennung von Präsenationslogik und Fachlogik. Hohe Lasten bei Anwendungen mit Sitzungszustand erfordern
eine leistungsfähige Infrastruktur. Noch viel stärker gilt dies für Anwendungen mit
komplexen Transaktionen. Die vorgestellte Enterprise-Architektur erfüllt alle diese
Anforderungen.
5.1
2-Tier
Der Begriff der zweischichtigen Architektur stammt aus der Zeit, als Clients direkt
mit Datenbankserver kommuniziert haben. Clients waren schwergewichtig, weil sie
die gesamte Logik für die Kommunikation mit dem Server implementiert haben. Im
Hinblick auf die heutigen Webanwendungen haben 2-Tier-Architekturen eine andere
Form eingenommen, die in Abbildung 25 dargestellt wird.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
39
Referenzarchitekturen
Abbildung 25:2-TierArchitektur
Client
Server Tier
ServerLogik
Dynamische
HTML-Seiten
Statische
HTML-Seiten
Datenbank
Services
Die Abbildung 25 illustriert eine Referenzarchitektur mit optionalen Teilen und Verbindungen. Von dieser Referenz können verschiedene konkrete Architekturen abgeleitet werden.
Die einfachste Arhitektur die von der Abbildung 25 abzuleiten ist, ist die Architektur
eines Web-Client, der vom Webserver lediglich statische HTML-Seiten erfordert.
Das heißt, in Abbildung 25 fallen die Komponenten “dynamische HTML-Seiten”,
“Datenbank” und “Serverlogik” sowie die entsprechenden Verbindungen weg.
Statische Seiten enthalten feste Inhalte. Dazu kann Logik in der Form von Skripten,
Applets oder Steuerelemente gehören, die auf der Client-Seite ausgeführt werden.
Die letztere Möglichkeit errinert an die erwähnten schwergewichtigen Clients.
Dieses Szenario wird erweitert, wenn die statischen Seiten serverseitige Applikationslogik (z.B. CGI-Applikationen, Servlets und anderes) oder eine Datenbank
ansprechen. Die Datenbank kann mit dem Webserver integriert sein (z.B. Zope) oder
sie kann auf einem separaten Server laufen.
Das 2-Tier-Szenario läßt sich mit dynamischen HTML-Seiten weiter ausbauen. In
diesem Fall sind alle Komponenten in Abbildung 25 präsent. Dabei erzeugen Serverlogik oder Anweisungen innerhalb des HTML-Quellcodes die dynamischen Inhalte.
Möglich ist auch, daß die Anweisungen oder die separate Serverlogik auf Datenbanken zugreifen. Der Webserver kann abschließend auch Services wie Sicherheit oder
Pooling anbieten.
40
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Referenzarchitekturen
Der Hauptvorteil von 2-Tier-Architekturen liegt an der kostengünstigen Implementierung. Apache ist die populärste Open-Source-Lösung in dieser Hinsicht [Ser-A].
Es wird geschätzt, daß der Apache-Server für mindestens 58% aller Web-Domänen
eingesetzt wird. Es muß allerdings erwähnt werden, daß der Apache-Server sehr oft
bei 3-Tier-Architekturen zum Einsatz kommt. Umgebungen, die den zweischichtigen
Ansatz unterstützen sind auch unter dem Begriff “Server Side Scripting Tools”
bekannt.
Der zweischichtige Ansatz führt jedoch schnell zu Engpässen, wenn anspruchsvolle
Szenarien wie personalisierte Dienste, verteilte Transaktionen, Integration von
Legacy-Applikationen oder Enterprise Information Systems [Sun-A] gewünscht sind.
5.2
Enterprise (N-Tier)
Der Hauptunterschied zwischen 2-Tier- und Enteprise-Architekturen liegt an der
Komponentenorientierung, die der Enterprise-Ansatz weitgehend unterstützt. Dies
fördert die Modularität sowie die Wiederverwendung und darüber hinaus die Flexibilität und Skalierbarkeit anspruchsvoller Webapplikationen.
Zudem unterstützten Enterprise-Architekturen die Verteilung von Komponenten oder
Systemen. Deswegen sind sie auch als mehrschichtige oder N-Tier-Architekturen
bekannt.
Zusammenfassend sind Enteprise-Architekturen für geschäftskritische Webapplikationen gedacht, die folgende Eigenschaften besitzen [BEA-E]:
• Sicherheit: Applikationen müssen bis zu Tausenden von Nutzern skalieren können
und trotzdem sicher sein
• Zuverlässigkeit: Applikationen müssen trotz Client-, Prozeß-, Server- und Netzwerkausfälle zur Verfügung stehen.
• Interoperabilität: Applikationen müssen mit Legacy-Systemen interoperieren.
• Management: Die Verwaltung von Client/Server-Applikationen, die über zahlreiche Maschinen weltweit laufen, muß möglich sein.
5.2.1
Infrastruktur-Komponenten
Abbildung 26 stellt die Enteprise-Architektur dar (vgl. [Sta96], [Cut01], [Mei01],
[Fit01]). Die Webserver-Komponente ist auch hier präsent und kann dieselbe Funktionalität wie bei der 2-Tier-Architektur anbieten. Bei der Enteprise-Architektur ist
auch eine Schnittstelle zwischen dem Webserver und dem Application Server implementiert.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
41
Referenzarchitekturen
Abbildung 26:Layers
einer EnterpriseAchitektur
Web Client
HTTP
Web Server
Firewall
Application Server
Data Services
Backend
Collaboration
Legacy
Applications
Enterprise Components
EAI
Workflow
Personalization
Common Services
Connectors
Enteprise
Information
Systems
XML
Databases
B2B Partners
Nachfolgend beschreiben wir die im Vergleich zu Abbildung 25 zusätzlichen Komponenten der Enteprise-Architektur:
• Firewall
Die Firewall schirmt das interne Netz gegen das Internet ab.
• Application Server
Die Logik-Komponenten der 2-Tier-Architektur (z.B. ein Servlet) kommuniziert mit
dem Application Server, um Funktionalitäten der Enterprise-Komponenten zu nutzen. Der Application Server enthält also Informationen über alle verfügbaren Komponenten und ist für ihre Lokalisierung, Instanziierung, Zwischenspeicherung und
Unterstützung durch Services zuständig.
42
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Referenzarchitekturen
• Common Services
Unter Common Services sind Dienste wie Sicherheit, Transaktionen und Konkurrenzfähigkeit gemeint. Diese Services werden vom Application Server implementiert. Dadurch brauchen Enteprise-Komponenten sich nicht um derartige Services zu
kümmern. Der Application Server erweitert, wenn gewünscht, jede Enteprise-Komponente transparent um Funktionalität der Common Services.
• Connectors
Konnektoren implementieren EAI-Schnittstellen (Enteprise Application Integration)
für die Integration externer Backend-Applikationen.
• Workflow (Engine)
Entwickler modellieren Geschäftsvorgänge als Workflows und verbinden sie mit
Funktionalität der Enterprise-Komponenten. Die Workflow Engine erlaubt die Ausführung von Workflows zur Laufzeit.
• Personalization
Die Personalization-Komponente nimmt eine Anpassung der HTML-Seiten an
bestimmte Clients vor. Die Art der Anpassung wird durch Regeln definiert. Eine Rule
Engine sorgt für die Haltung der Regeln zur Laufzeit.. Zudem wird es den Clients
möglich, sich zu registrieren und über Notifikationen informiert zu werden.
• Enterprise Components
Die Enterprise-Komponenten implementieren die Geschäftslogik in der Form von
Funktionen, die den Clients letztendlich zur Verfügung stehen.
• Data Services
Es handelt sich um Dienste wie Data Warehouses, Medaten-Repository und ähnliches. Die Ziele dieser Dienste sind vor allem die Integration, Vereinheitlichung und
Analyse verschiedener Datenquellen. Content Management Funktionalität kann auch
angeboten werden. Die Content Management Architektur behandeln wir separat im
Abschnitt 5.4.
• Collaboration
Collaboration kommt in Business to Business Szenarien zum Einsatz. Es werden
XML- (z.B. XML-Parser, -Übersetzer) sowie Registrierungs-Services angeboten. Mit
den letzteren können sich Partner anmelden und Rollen (z.B. Lieferant) in einem
B2B-Szenario einnehmen. Die Collaboration-Komponente sorgt zur Laufzeit für das
Senden und Empfangen von Geschäftsnachrichten für registrierte Partner. Diese
Komponente kann die Workflow-Komponente beinhalten, um Geschäftsvorgänge die
sich über verschiedene Geschäftspartner ausstrecken, zu unterstützen.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
43
Referenzarchitekturen
• Enteprise Information Systems
Sun fasst unter dem Begriff Enterprise Information Systems große kommerzielle
Systeme zusammen wie: PeopleSoft. SAP R/3, IBM’s CICS, RPG sowie nicht-relationale Datenbanken.
5.2.2
Realisierung einer 4-Schichten-Architektur
Eine Aufteilung der Anwendungskomponenten in vier Schichten, wie in Abbildung
27 gezeigt, führt zu hoher Skalierbarkeit in dieser Umgebung und bietet einige Flexibilität und damit Zukunftssicherheit. Die Bennenung der Schichten und grundlegende
Konzepte wurden [HeS00] entnommen.
Abbildung 27:VierSchichten-Architektur
HTTP
HTTP
HTTP
Presentation
s
Workspace
1
0
0
Enterprise
0
2
Resource
(Schema)
Hervorstechendstes Merkmal ist dabei die Trennung von Enterprise und WorkspaceSchicht. Diese Trennung sorgt dafür, dass die „schweren“, transaktionsgesicherten
Operationen von Komponenten gemäß Abschnitt 3.1.7 mit verbindungslosen, grobgranularen Schnittstellen ausgeführt werden, die somit von der Verwaltung der u.U.
vielen tausend Verbindungen entlastet sind (Enterprise Tier). Wo die Verwaltung von
Session State über mehrere zusammenhängende Requests notwendig ist, führt man
eine entsprechende Komponente auf der Workspace Tier ein. In jedem Fall ist die
Präsentationslogik gemäß Abschnitt 3.2.1von der fachlichen Logik getrennt.
44
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Referenzarchitekturen
Mit dieser Trennung läßt sich eine effiziente Lastverteilung sowohl „von Hand“ als
auch durch die von vielen Applikationsservern mitgelieferten, und damit „unsichtbaren“ Lastverteilungsmechanismen erreichen.
Die Schnittstellen der Enterprise-Komponenten sind zu den oberen Schichten hin
synchrone Schnittstellen, da letztendlich das synchrone HTTP-Protokoll bedient werden muss. Zwischen den Enterprise-Komponenten können synchrone oder asynchrone Schnittstellen zum Einsatz kommen, wobei asynchrone Schnittstellen insbesondere zwischen großen Subsystemen in Abschnitt 3.1.6 erwähnten Vorteile (z.B.
größerer Durchsatz und Verläßlichkeit) haben. Zur logischen Entkopplung können
die in Abschnitt 3.2.4 erwähnten Publish-Subscribe-Mechanismen eingesetzt werden.
Synchrone Schnittstellen können auch zwischen den Enterprise-Komponenten notwendig sein, wenn es sich um „Ereignisse mit Vetorecht“ handelt.
Dazu ein Beispiel aus einem ERP-System: Ein ERP-System enthält unter anderem
eine Buchhaltungskomponente und eine Komponente für die Materialwirtschaft. Die
Buchhaltungskomponente könnte vor dem Löschen einer Kostenstelle ein entsprechendes Ereignis aussenden. Wenn die KOstenstelle, beispielsweise in der Materialwirtschaft, schon bebucht wurde, würde die Materialwirtschaftskomponente entsprechend ein Veto gegen das Löschen der Kostenstelle einlegen.
In beiden Fällen bieten sich XML-Schnittstellen an, da bei den grobgranularen
Methoden häufig komplexe Daten übergeben werden müssen und sich die Schnittstellenevolution so leichter bewältigen läßt. Logs und Auswertungen werden durch
das Textformat auch erleichert.
Mit den Schnittstellen der Enterprise-Schicht steht die ideale Plattform für B2B-Integrationsprojekte bereit. Die Schnittstellen lassen sich z.B. als SOAP-basierter Webservice veröffentlichen und in die Wertschöpfungskette anderer Unternehmen integrieren. Mehr dokumentenorientierte Standards wie Biztalk oder ebXML
entsprechen den erwähnten asynchronen XML-Schnittstellen der Systeme.
Auch der für manche Anwendungsgebiete immer noch sinnvolle Rich Client für den
Backoffice-Bereich läßt sich über die Enterprise-Schicht anbinden.
Durch die Trennung Workspace / Presentation können Mehrsprachigkeit und die
Anbindung z.B. von WAP-Clients realisiert werden.
Für die Durchsetzung einer solchen Architektur im Entwicklungsprozeß bieten sich
bei größeren Projekten automatisierte Verfahren an, wie z.B. in [Ciu99] beschrieben.
Für die Realisierung dieser 4-Schichten-Architektur bieten sich vor allem die im
App2Web-Dokument Richtlinien vorgestellten Umgebungen J2EE und .NET an.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
45
Referenzarchitekturen
Zu den einzusetzenden Infrastruktur-Elementen gibt die folgende Tabelle einige Hinweise:
5.3
Implementierung in Schicht
Java 2 Enterprise Edition
Microsoft .NET
Presentation
Java Server Pages und Servlets
ASP.NET-Seiten mit entsprechenden CodeBehind-Klassen
Workspace
Servlets mit Verwendung von Sessions, einfache Java-Objekte, EJB:
Session Beans
Keine besondere Unterstützung:
Einfache Klassen
Enterprise
Zur Implementierung von synchronen Schnittstellen: Statefree Session
Beans
Zur Implementierung von asynchronen Schnittstellen: Message driven
Beans
Zur Implementierung des Datenzugriffs: Entity Beans
Zur Implementierung von
Schnittstellen bieten sich Webservice-Klassen an. Jede Komponente auf Enterprise-Ebene kann
in einen Webservice gekapselt
werden.
Für den Datenzugriff erlaubt
ADO.NET einen hohen Komfort.
XML-Pipe
Die XML-Pipe Architektur unterstützt das Senden und Empfangen von Nachrichten
im XML-Format. Wie bereits erwähnt, kommt diese Architektur in Business To Business Szenarien sehr oft zum Einsatz, weil die XML-Nachrichten zwischen Partnern
mit heterogenen Systemen gut austauschbar sind.
XML-Nachrichten können strukturierte Daten, Anforderungen oder auch binäre
Daten als Attachments enthalten. Abbildung 28 stellt die XML-Pipe Architektur dar
(vgl. [Mic-F], [BEA-F]).
46
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Referenzarchitekturen
Abbildung 28:XMLPipe Architektur
Empfänger
XML Server
Sender
XML
XML
Reader
XML
Parser
XML
Serializer
Dispatcher
Listener
• Listener
Der Listener empfängt und erkennt die XML-Nachricht. Anschließend initialisiert er
den XML-Server und leitet die Nachricht an ihn weiter.
• XML Reader
Um die XML-Nachricht bearbeiten zu können, muß der XML-Server sie in eine für
ihn geeignete Form übersetzen (z.B. DOM-Baum). Die Reader-Komponente liest die
Nachricht und führt diese Übersetzung durch.
• XML Parser
Nachdem die XML-Nachricht für den Server “verständlich” gemacht wurde, muß der
Server die Nachricht analysieren, um von der XML-Struktur die Information herauszubekommen. Dafür ist der Parser verantwortlich
• Dispatcher
Der Dispatcher sorgt praktisch für die Interpretation der Ergebnisse aus der Analyse
der Nachricht. Möglicherweise wird eine Geschäftsfuktionalität basierend auf diesen
Ergebnissen angestoßen.
• Serializer
Wenn eine Antwort gewünscht ist, muß sie auch in XML formatiert werden. Der
Serializer ist dafür zuständig.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
47
Referenzarchitekturen
5.4
Content Management
Content Management Systeme vereinheitlichen Daten aus verschiedenen Quellen
und unterstützen vor allem die Datensuche und -publikation. Dies erfolgt durch die
Nutzung von Metainformationen, die auf die Semantik der Daten hinweisen.
Abbildung 29 illustriert eine Content Management Referenzarchitektur (vgl. [Vig-A],
[Con-A], [Dig-A]), die aus zwei Hauptkomponenten besteht: aus dem Content Delivery System, das die Daten für den Web Client aufbereitet und liefert, und dem Content Management Server, der für die Datenspeicherung, -zugriff sowie -integration
zuständig ist.
• Content Delivery Server
Der Content Delivery Server ist der Kern des Content Delivery Systems. Er realisiert
den Zugriff auf den Content Management Server und bereitet Daten auf. Externe
Webserver können mit Hilfe von Plugins an den Content Delivery Server angeschlossen werden. Der Content Delivery Server ist auch für die Autorisierung der Benutzer
zuständig.
• Publisher
Der Publisher erledigt schwergewichtige Aufgaben wie die Neuanlage eines Dokumentes. Er startet Transaktionen in der Content-Datenbank und kann auf statische
Dateien zugreifen.
• Dispatch Service
Es handelt sich um einen Broker, der die Kommunikation mit der Content-Datenbank
realisiert. Der Dispatcher führt leichtgewichtige Operationen wie das Löschen eines
Dokumentes oder die Neueanlage eines Benutzers aus.
• Content Database
Die Content-Datenbank bietet eine einheitliche, strukturierte (möglicherweise objektorientierte) Sicht auf eigene und integrierte Daten und Metainformationen. Enthalten
sind auch die Informationen über Benutzer, Benutzergruppen und die zugewiesenen
Rechte. Transaktionen werden für jedes Objekt der Datenbank unterstützt.
48
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Referenzarchitekturen
Abbildung 29:Content Management
Architektur
Web
Client
Content Delivery System
Webserver
Content
Delivery
Server
Content Management Server
Publisher
Static
Static
Files
Static
Files
Files
Dispatch
Service
Partners
Content
Database
Syndication
Service
External
Databases
Aggregation
Service
• Aggregation Service
Der Aggregation Service, in seiner einfachsten Form, enthält Adapter für die Integration externer Datenbanken. Eine erweiterte Variante stellt Crawlers [Fit01] oder
Agenten zur Verfügung, die externe Systeme besuchen und nach relevanten Daten
suchen.
• Syndication Service
Der Syndication Server unterstützt die Verteilung der Daten an Geschäftspartner. Der
Service unterstützt unterschiedliche Daten, die verpackt und an registrierte Partner
übersendet werden. Dabei sind verschiedene Übergabemöglichkeiten erlaubt (z.B.
ereignisgesteuert, im voraus geplant usw.). Die Verwaltung und Zurückverfolgung
verteilter Daten wird ebenso unterstützt. Agenten sind auch hier möglich und helfen
bei der Integration der gelieferten Daten.
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
49
Literatur
6
50
Literatur
[BEA-A]
Enterprise Middleware Series, Reliable Queuing Using BEA Tuxedo,
BEA Systems 2001, http://www.bea.com/products/tuxedo
paper_queuing.shtml
[BEA-B]
Online Dokumentation zu BEA Tuxedo Release 7.1, BEA Systems
2001, http://e-docs.bea.com/tuxedo/tux71/index.htm
[BEA-C]
WebLogic Server Programming, BEA WebLogic JSP, BEA WebLogic
Server 6.1 Beta, BEA Systems, June, 2001, http://e-docs.bea.com/
wls/docs61///////pdf/jsp.pdf
[BEA-D]
WebLogic Server Using WebLogic BEA Server Clusters, BEA
WebLogic Server 6.0, BEA Systems, March 2001, http://edocs.bea.com/wls/docs61///////pdf/cluster.pdf
[BEA-E]
BEA WebLogic Enterprise Introduction, BEA WebLogic Enterprise
4.1, BEA Systems Mai 2001, http://www.bea.com/products/weblogic/
enterprise/enterprise_intro.pdf
[BEA-F]
Überblick über BEA WebLogic Collaborate, BEA Systems 2001,
http://e-docs.bea.com/wlcollab/v1_0/getstart/over.htm
[Bec94]
Kent Beck, Patterns Generate Architectures, Proceedings of the European Conference on Object-Oriented Programming, 1994, Bologna,
Italien
[Con-A]
Contentmanager.de, Marktübersicht: Produktindex, http://www.contentmanager.de/itguide/markt_produktidx.php
[Cut01]
Component Development Strategies, The Monthly Newsletter from
Cutter Information Corp. on Managing and Developing ComponentBased Systems, VOL. X, Special Excerpt, Cutter Information Corp.
ISSN 1552-7391, 2001
[Dig-A]
Zope Content Manager’s Guide, Digital Creations, 2000, http://
www.zope.org/Documentation
[Fel98]
Pascal FELBER, The CORBA Object Group Service, Doktorarbeit,
École Polytechnique Fédérale de Lausanne, 1998, http://
lsewww.epfl.ch/OGS/thesis/
[Fit01]
Patrick Fitzgerald, Tie it together and open it up with Enterprise Information Portals, Trendmarkers e-newslettter, Techmetrix Research,
April 2001, vefügbar unter http://www.techmetrix.com/trendmarkers/
tmk0401/tmk0401-3.php3
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Literatur
[Gam95]
E. Gamma et al., Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995
[Gom01]
Hassan Gomaa et al., Reusable Component Interconnection Patterns
for Distributed Software Architectures, Proceedings of the Symposium on Software Reusability, 2001, Toronto
[Hal97]
Daniel S. Halbach, Eric C. Newton: A Practical Alternative to Business Objects. An Experience Report. http://www.pareto.com/
exprep97.html.
[Has01]
Willi Hasselbring: Reference Architecture Modeling with the UML
and Vital: A Comparative Study, Proceedings of 1st ICSE Workshop
on Describing Software Architecture with UML, http://www.rational.com/events/ICSE2001/index.jsp
[HeS00]
Peter Herzum, Oliver Sims: Business Component Factory. OMG
Press, 2000.
[Hun98]
Kitty Hung, Tony Simons, Tony Rose: „The Truth Is Out There?“: A
Survey of Business Objects. 5th International Conference on ObjectOriented Information systems (OOIS'98), 9-11 September 1998, Paris
[IBM-A]
IBM Patterns for E-Business, http://www-106.ibm.com/developerworks/patterns/b2bi/select-application-topology.html
[JoA01]
Isabel John, Christoph Andriessens: Domänenmodellierung für Webanwendungen. Bericht aus dem Projekt Application2Web, FZI 2001
[Kle99]
Mark Klein Rick Kazman, Attribute-Based Architectural Styles, Software Engineering Institute Carnegie Mellon University Pittsburgh, PA
15213 REPORT NUMBER CMU/SEI-99-TR-022
[Kru95]
Philippe Kruchten: The 4+1 View Model of Architecture. IEEE Software, November 1995. http://www.rational.com/products/whitepapers/350.jsp
[Mei01]
Jürg Meier, Tanja Scharf, Regeln für die Anwendungsarchitektur verteilter Systeme, Objektspektrum März/April 2001, pp 77-81
[MeA00]
Menascé, Almeida: Scaling for E-Business. Technologies, Models,
Performance and Capacity Planning, Prentice Hall 2000.
[Mic-A]
Online Dokumentation zu Microsoft Queuing Services, Microsoft
Corporation 2001, http://msdn.microsoft.com/library/psdk/msmq/
msmq_overview_4ilh.htm
[Mic-B]
Microsoft Message Queuing Services, A Guide to Reviewing Microsoft Message Queue Server, Release 1.0-The Message Queuing Service of Windows NT, 1997, Microsoft Corporation 2001
[Mic-C]
The ODBC Programmer’s Reference, Microsoft Development Network, 2001, Microsoft Corporation 2001, http://msdn.microsoft.com/
library/default.asp?URL=/library/psdk/iisref/eadg6cbl.htm
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
51
Literatur
52
[Mic-D]
Active Server Pages Guide, Microsoft Development Network, Microsoft Corporation 2001, http://msdn.microsoft.com/library/
default.asp?URL=/library/psdk/iisref/eadg6cbl.htm
[Mic-E]
Gregory Leake, Architecture Decisions for Dynamic Web Applications: Performance, Scalability, and Reliability, November 2000, Microsoft Corporation 2001, http://msdn.microsoft.com/library/techart/
docu2kbench.htm
[Mic-F]
Soap Toolkit 2.0 Gold Release, Microsoft Development Network,
2001, http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsoap/html/soap1and2.asp
[Mic-G]
Reference Architecture for Commerce: Business to Consumer
(B2C),Microsoft Corporation 2001, http://msdn.microsoft.com/
library/default.asp?url=/library/en-us/dnrac/html/
mracv1_overview.asp
[Raj99]
Gopalan Suresh Raj, A detailed comparison of EJB and the MTS
Models, http://members.tripod.com/gsraj/misc/ejbmts/ejbmtscomp.html
[Rie96]
D. Riehle: The Event Notification Pattern - Integrating Implicit Invocation with Object-Orientation, Theory and Practice of Object
Systems vol. 2 no. 1, pp. 43-52, John Wiley & Sons, 1996
[Sch98]
Douglas C. Schmidt, Steve Vinoski, Object Interconnections, An
Introduction to CORBA Messaging, SIGS C++ Report magazine,
Dezember 1998, (http://www.iona.com/hyplan/vinoski/col15.pdf)
[Ser-A]
ServerWatch Web Servers, http://serverwatch.internet.com/webserverapache.html
[Sta96]
Enterprise Architecture Project, Final Report Juni, 1996, Stanford
University Information Technology Systems & Services, Architecture
Planning & Standards Redwood Hall, Ext 32696
[Sun-A]
J2EE Connector Architecture brings business systems to the Web,
http://java.sun.com/features/2000/08/connect.html
[Sun-B]
Sun Microsystems: Java 2 Platform Enterprise Edition Blueprints.
http://java.sun.com/j2ee/blueprints/
[Sun-C]
J2EE Blueprints, J2EE Design Patterns, Model-View-Controller
Architecture, http://java.sun.com/j2ee/blueprints/design_patterns/
model_view_controller/index.html
[Sun-D]
Sun Microsystems: J2EE Patterns Catalog. http://developer.java.sun.com/developer/restricted/patterns/
J2EEPatternsAtAGlance.html
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001
Literatur
[Sut97]
Jeff Sutherland: The Object Technology Architecture: Business
Objects for Corporate Information Systems. In: Sutherland et al.:
Business Object Design and Implementation. Springer, 1997. http://
www.jeffsutherland.org/papers/boa_pap.html
[UML99]
OMG Unified Modeling Language Specification, June 1999. http://
www.rational.com/uml
[Vig-A]
Vignette Content Management Server, Vignette Corporation, 2001,
http://www.vignette.com
Copyright  Fraunhofer IESE / FZI Karlsruhe2001
53
Literatur
54
Copyright  Fraunhofer IESE / FZI Karlsruhe 2001