Zusammenfassung. Werkzeugorientierte Verarbeitung

in datenbankbasierten Ingenieursystemen geschieht ty-

pischerweise in einer Workstation/Server-Umgebung.

Dabei sind die werkzeugrelevanten Entwurfsdaten fuÈ r

die Dauer der Verarbeitung aus EffizienzgruÈnden (Re-

ferenzlokalitaÈ t) im Hauptspeicher der Workstation zu

puffern. Die Rolle der langfristigen Datenspeicherung

sowie der Datenversorgung der beteiligten Workstati-

ons uÈbernimmt der Datenbank-Server.

In diesem Artikel werden verschiedene Workstation/

Server-Architekturen vorgestellt und hinsichtlich ihrer

Tauglichkeit fuÈ r datenbankbasierte Ingenieuranwen-

dungen bewertet. Im Brennpunkt dieser Betrachtun-

gen stehen Datenextraktion, Datenbereitstellung und

-verarbeitung sowie Integration der geaÈnderten Daten,

Datensicherung und Synchronisation. Das Verarbei-

tungsmodell haben wir detailliert und dabei wichtige

Merkmale herausgearbeitet sowie die Grundformen be-

kannter Architekturen verfeinert. Zudem wird eine

Entscheidungshilfe zur Auswahl der geeigneten System-

architektur fuÈ r eine gegebene Anwendung erarbeitet.

Unsere Untersuchungen zeigen, daû keine global opti-

male Architektur existiert und daû fuÈ r die Bewertung

eines Ansatzes die spezifischen Charakteristika der

Zielanwendung entscheidend sind. Hier ist insbesonde-

re ausschlaggebend, ob deskriptiv formulierte Datenan-

forderungen und vorab bekannte Verarbeitungskontex-

te der Anwendung effizient und auf ihre BeduÈ rfnisse zu-

geschnitten verfuÈ gbar gemacht werden koÈnnen.

SchluÈ sselwoÈ rter: Workstation/Server, Datenbanken,

Objektorientierung, Ingenieuranwendungen, Verarbei-

tungskonzept

Abstract. Engineering and design systems typically em-

ploy their engineering and design tools in a worksta-

tion/server environment. Usually it is the task of the

database server to manage the persistent design data,

whereas the tools run at the workstation site. Due to ef-

ficiency considerations it is overly important that the ap-

plication's current design data are cached in the main

memory at the workstation, thereby exploiting near-by-

application locality.

In this paper, we introduce some important worksta-

tion/server architectures and we discuss their suitability

for engineering applications that build upon database

system. The discussion is focussed on data extraction

from the server, data representation and processing at

the workstation, integration of committed design data

into the global database as well as on synchronization

and recovery issues. Furthermore, the processing mod-

el is being detailled whilst refining the basic architec-

tures. Our investigations reveal that there is no single

optimal architecture; in contrast, the specific character-

istics of the application at hand determine the suitabili-

ty of the various architectures. Therefore, we give some

decision guidelines on how to choose the best system ar-

chitecture for a given application scenario.

Key words:Workstation/server, databases, object orien-

tation, engineering applications, processing model

CR Subject Classification:D.4.4, E.m., H.2.4, H.2.8, J. 6

1. Einleitung

Der Einsatz integrierter rechnergestuÈ tzter Entwurfs-

umgebungen (engl. ¹integrated computer-aided design

environmentsª) stellt einen wesentlichen Schritt zur Be-

herrschung der KomplexitaÈt des Entwurfs (etwa VLSI-

Entwurf oder CAD in den Bereichen Maschinenbau,

Architektur und Bau- und Raumwesen) dar. Diese Ent-

wurfsumgebungen bieten fuÈ r einen konkreten Anwen-

dungsbereich eine zugeschnittene Infrastruktur fuÈ r die

Anwendung entsprechender CAD-Werkzeuge und un-

terstuÈ tzen alle Phasen des Entwurfsprozesses in luÈ cken-

loser und kontinuierlicher Weise. Eine Basis zur Erstel-

lung solch angepaûter Umgebungen bilden die sog.

Informatik Forsch. Entw. (1995) 10: 55±72

Workstation/Server-Architekturen fuÈ r datenbankbasierte

Ingenieuranwendungen

T.HaÈrder, B.Mitschang, U.Nink und N.Ritter

Fachbereich Informatik, UniversitaÈ t Kaiserlautern, Postfach 3049, D-67653 Kaiserslautern

Eingegangen am 5.Oktober 1993/Angenommen am 19.Oktober 1994

Springer-Verlag 1995

e-mail: {haerder/mitsch/nink/ritter} @ informatik.uni-kl.de

CAD-Frameworks [14, 32], die eine moÈglichst allgemei-

ne und damit wiederverwendbare Betriebsumgebung

fuÈ r CAD-Werkzeuge bereitstellen. In diesem Sinne ist

es eine zentrale Aufgabe eines CAD-Frameworks, die

folgenden Basisdienste anzubieten:

± Langfristige Verwaltung aller entwurfs- und werk-

zeugrelevanten Daten, sowie Maûnahmen zur Erhal-

tung der semantischen IntegritaÈ t dieser Daten.

± Integration von Werkzeugen in die Entwurfsumge-

bung unter besonderer BeruÈ cksichtigung der vorherr-

schenden Objekt- und Entwurfsstrukturen.

± Datenversorgung der Werkzeuge und Bereitstellung

von operationalen Schnittstellen fuÈ r die werkzeugorien-

tierte Verarbeitung.

± Kontrolle von Ablauffolgen (Transaktionsdienste

[13], workflow management [18]) bei der werkzeugori-

entierten Verarbeitung undMechanismen zur Fehlerbe-

handlung.

Als wesentliche Systemarchitektur hat sich hier die

Workstation/Server-Architektur herausgebildet. Hier-

bei finden die einzelnen Werkzeuganwendungen auf

den Workstations statt, und die zentrale Datenverwal-

tung geschieht auf dem Server. Zur Optimierung der

Workstation/Server-Kommunikation sowie zur Ausnut-

zung der VerarbeitungslokalitaÈ t der Werkzeuge ist der

Einsatz eines Hauptspeicherpuffers auf der Worksta-

tion-Seite (¹Objektpufferª) notwendig [17]. Diese

SchluÈ sseleigenschaft soll durch die explizite Verwen-

dung des Begriffs Workstation hervorgehoben werden;

dadurch unterscheiden sich diese Architekturen erheb-

lich von solchen, die sich durch die bloûe Funktionali-

taÈ t des Client/Server-Ansatzes charakterisieren lassen.

Ausgehend von dieser U

È

berlegung kristallisiert sich

ein Zyklus der Werkzeugverarbeitung (Abb.1) heraus,

fuÈ r den folgende Aspekte von besonderer Relevanz

sind:

(1) Extraktion der werkzeugrelevanten Daten (Check-

out)

Die fuÈ r den Verarbeitungsschritt notwendigen Daten

sind aus den auf dem Server verwalteten Entwurfsda-

ten zu selektieren und mit minimalem Kommunika-

tionsaufwand zur Workstation (WS) zu transportieren.

Wir bezeichnen diese Menge der fuÈ r die Werkzeugan-

wendung relevanten Daten als Verarbeitungskontext.

(2) Bereitstellung/RepraÈsentation der Daten im Objekt-

puffer

Die gelieferten Daten sind demWerkzeug in geeigneten

Datenstrukturen zur RepraÈsentation der komplexen

Entwurfsobjekte und ihrer verschiedenartigen inter-

und intrastrukturellen Beziehungen zur VerfuÈ gung zu

stellen, die idealerweise dem Zugriffsverhalten und

den Verarbeitungscharakteristika des Werkzeuges flexi-

bel angepaût werden koÈnnen.

(3) UnterstuÈ tzung der Werkzeug-Verarbeitung

Bei den Operationsfolgen (Suche, A

È

nderung) der

Werkzeuganwendungen dominiert eine navigierende

Verarbeitungsweise, die durch ein flexibles Cursorkon-

zept gesteuert wird. ZusaÈtzlich kann es sinnvoll sein, in-

haltsorientierte SuchvorgaÈnge zu unterstuÈ tzen. Bei-

spielsweise kann dies durch eine deskriptive Anfrage-

moÈglichkeit und mengenorientierte Verarbeitungswei-

se effektiv unterstuÈ tzt werden. Bereits waÈhrend dieser

Objektpuffer-Verarbeitung ist es sinnvoll, die Einhal-

tung bestimmter IntegritaÈ tsbedingungen zu uÈberwa-

chen.

(4) Integration der geaÈnderten Daten (Check-in)

Am Ende eines Verarbeitungsschrittes ist das Ergebnis

der Werkzeuganwendung in die zentrale Datenbank zu-

ruÈ ckzuschreiben, was wiederum mit minimalem Kom-

munikationsaufwand geschehen sollte. Nach erfolgrei-

cher Integration der geaÈnderten Daten muû Schema-

konsistenz gewaÈhrleistet sein. Dies bedeutet insbeson-

dere, daû am Ende des Verarbeitungsschrittes weitere

IntegritaÈ tsbedingungen zu uÈberpruÈ fen sind.

Mit dieser Skizze des Verarbeitungszyklus einer Werk-

zeuganwendung sind bereits wesentliche Anforderun-

gen an ein unterstuÈ tzendes Architekturkonzept ange-

sprochen. Aus Sicht des Werkzeugs hat das Leistungs-

verhalten oberste PrioritaÈt, da es oft entscheidend fuÈ r

die Akzeptanz des gesamten Verarbeitungskonzepts

ist. Typischerweise sind die innerhalb eines Verarbei-

tungskontextes zu bearbeitenden Datenmengen sehr

groû und hochgradig vernetzt. Bei komplexen Berech-

nungen des Werkzeuges, die viele Datenelemente mit-

einander in Beziehung setzen, fallen deshalb enorm vie-

le Datenzugriffe (navigierender Art) an. Aus diesem

Grund ist es eine oft genannte Forderung, bei solchen

Operationsfolgen etwa in der GroÈûenordnung von

Hauptspeicher-Zugriffsoperationen zu liegen (was der

MoÈglichkeit, etwa 10

5

Objektreferenzen pro Sekunde

auswerten zu koÈnnen, entspricht). Um diese Zielvorga-

be erreichen zu koÈnnen, erscheint es notwendig, die Da-

tenrepraÈsentation und auch die Datenstrukturen imOb-

jektpuffer an das Zugriffsverhalten des Werkzeuges an-

zupassen und zudem effiziente Zugriffsfunktionen mit

variablen Verarbeitungsgranulaten (Attribut, Objekt,

Menge von Objekten) und einer einheitlichen Schnitt-

stelle (DatenunabhaÈngigkeit) bereitzustellen.

Neben der Vorstellung der Grundformen von Work-

station/Server-Architekturen liegt die Hauptintention

dieses Artikels in der Diskussion moÈglicher Optimie-

rungen und in der Bewertung der Eignung dieser AnsaÈt-

56

Abb.1. Werkzeugbasiertes Verarbeitungsmodell

ze fuÈ r bestimmte AnwendungsfaÈ lle. Daher wendet sich

dieser Artikel sowohl an den DBMS-Implementierer

als auch an den Anwendungsentwickler. WaÈhrend sich

die Diskussion der vorgeschlagenen Architekturerwei-

terungen eher an den Implementierer richtet, wird den

Interessen des Anwendungsentwicklers insbesondere

durch bestimmte Abstraktionen und die getrennte Dis-

kussion der Architekturgrundformen und der zugehoÈ ri-

gen Optimierungen Rechnung getragen. FuÈ r den an

weiteren Details interessierten Leser werden weiterfuÈ h-

rende Spezialliteraturreferenzen gegeben. Damit soll

insbesondere eine leicht zugaÈngliche EinfuÈhrung in die

Problematik unseres Themas gegeben werden, die die

sehr umfangreiche und z.T. sehr undurchsichtige Spezi-

al- und Originalliteratur verstaÈndlich aufbereitet.

ZunaÈchst betrachten wir in Kapitel 2 ein typisches

Verarbeitungsszenario. Dort wird am Beispiel des

VLSI-Entwurfs ein MengengeruÈ st fuÈ r einen typischen

Verarbeitungskontext im Chip-Planning vorgestellt.

Die Kapitel 3 und 4 bilden den Hauptteil dieser Arbeit.

WaÈhrend hier aus Anwendersicht eher die Beschrei-

bung der einzelnen Architekturen (Abschn.3.2) und de-

ren anwendungsbezogene Bewertung (Abschn.4.2) von

Interesse sind, richten sich die Diskussion der vorge-

stellten Erweiterungen (Abschn.3.3) und die aufgestell-

ten Grundprinzipien fuÈ r den Systementwurf (Ab-

schn.4.1) in erster Linie an den Implementierer. Ein

kurzes ResuÈmee und ein Ausblick auf weitere Arbeiten

schlieûen die Betrachtungen ab.

2. Charakteristika von Verarbeitungskontexten

Ziel dieses Kapitels ist es, genauere Informationen uÈber

den Aufbau und die GroÈûe von Verarbeitungskontexten

bereitzustellen. Beispielhaft werden fuÈ r den VLSI-Ent-

wurf die dort vorherrschenden/typischen Verarbei-

tungskontexte bestimmt. Die in diesem Kapitel erarbei-

teten MengengeruÈ ste und allgemeinen Charakteristika

von Verarbeitungskontexten werden in den nachfolgen-

den Kapiteln zur System- bzw. Architekturbewertung

herangezogen.

2.1 Anwendungsszenario

Chip-Planning. Der VLSI-Entwurf ist ein komplexer

Anwendungsbereich, in dem eine Vielzahl von Ent-

wurfswerkzeugen zum Einsatz kommen. Wir wollen an

dieser Stelle jedoch nicht auf die Methodik des Gesamt-

entwurfs eingehen [37], vielmehr sollen anhand eines

Entwurfswerkzeugs die Charakteristika von Werkzeug-

anwendungen illustriert und die typischen Objektstruk-

turen aufgezeigt werden. Durch das in [1] beschriebene

Werkzeug Chip-Planner wird die Topographie einer

Zelle bestimmt. Da typischerweise die Anzahl der Stan-

dardzellen fuÈ r eine zu entwerfende Zelle sehr groû ist

(~ 10

6

Standardzellen), entwirft man hierarchisch aufge-

baute Zellen, die jeweils aus einer begrenzten Anzahl

von Subzellen bestehen. Der Chip-Planner betrachtet

in einer konkreten Anwendung eine Zelle dieser Hier-

archie zusammenmit ihren direkten Subzellen. Die Ein-

gabe besteht aus der Schnittstellenbeschreibung der zu

planenden Zelle (Rahmen und Anschluûbereiche/Pin-

Intervalle) sowie Informationen uÈber die Subzellen

(moÈgliche Formen und Vernetzungen). Davon ausge-

hend werden Floorplan-Informationen berechnet, d.h.

insbesondere die Anordnung der Subzellen innerhalb

der Zelle und die Schnittstellen-Beschreibungen der

Subzellen. Letztere dienen als Eingabe fuÈ r nachfolgen-

de Chip-Planner-Anwendungen zur Berechnung der

Subzellen-Topographien. In diesem Sinne wird die Ge-

samt-Topographie des zu entwerfenden Chips durch

sukzessive Chip-Planner-Anwendungen in einer Top-

Down-Vorgehensweise ermittelt.

Abbildung 2 visualisiert die Zellhierarchie eines 2-

Bit-Addierers. Im unteren Teil des Bildes ist ausschlieû-

lich die Zellschnittstelle dargestellt, waÈhrend im oberen

Teil auch der Zellaufbau zu sehen ist. Die Hierarchisie-

rung ist dabei gut zu erkennen: Die Beschreibung der

Zelle des 2-Bit-Addierers setzt sich direkt in der Be-

schreibung der Subzellen (drei 1-Bit-Addierern und ei-

nem Halbaddierer) fort. Weiter wird dort auch die An-

ordnung der Subzellen und der Verbindungsleitungen

angedeutet.

Datenmodellierung. Eine ausfuÈhrliche Bertrachtung der

Informations- und Datenmodellierung fuÈ r das ange-

sprochene Anwendungsbeispiel ist im Rahmen dieses

Artikels nicht angebracht [22]. Trotzdem sei an dieser

Stelle darauf hingewiesen, das bspw. Zellschnittstellen,

Zellen und Zellinhalte sinnvollerweise als komplexe

Objekte zu modellieren sind, die sich aus elementaren

Objekten, wie z.B. Verdrahtungen, Anschluû-Pins etc.,

zusammensetzen. Um die fortschreitende Entwicklung

und VervollstaÈndigung der Entwurfsobjekte zu reflek-

tieren, wird eine Versionierung der komplexen Objekte

durchgefuÈhrt. Da jetzt fuÈ r komplexe Objekte mehrere

Versionen auftreten koÈnnen, muû festgelegt werden,

welche Versionen zu einer groÈûeren Verarbeitungsein-

heit zusammenzufassen sind. Dieser Auswahlvorgang

heiût Konfigurierung

1

. Damit wird ein Verarbeitungs-

kontext aus Versionen von zueinander in Beziehungen

stehenden komplexen Objekten durch Konfigurierung

gewonnen. Das Konfigurationsobjekt dient dabei als

57

Abb.2. Zellhierarchie eines 2-Bit-Addierers

eine Art Anker fuÈ r den gesamten Verarbeitungskon-

text. Von diesem Anker aus koÈnnen alle werkzeugrele-

vanten Daten durch Traversieren von Objektbeziehun-

gen erreicht werden.

2.2 Eigenschaften von Verarbeitungskontexten

Allgemeine Eigenschaften. Die Verarbeitungskontexte

verschiedener Werkzeuganwendungen koÈnnen natuÈ r-

lich uÈberlappen; man spricht dann von gemeinsamen

Teilobjekten (¹object sharingª). Weiterhin koÈnnen

auch rekursive Objektstrukturen auftreten (vgl. rekursi-

ve Zellhierarchie des Beispiels). Der Chip-Planner be-

noÈ tigt als Eingabe nicht die vollstaÈndigen Objekte, son-

dern es genuÈgt eine Sicht auf diese. Dabei ist sowohl ein-

fache Projektion einzelner Attribute als auch das Ver-

dichten von Information (Aggregation) sowie eine

Komponentenprojektion innerhalb der Komplexobjek-

te vorzusehen.

Quantitative Aspekte von Verarbeitungskontexten. Im

folgenden wird eine grobe, quantitative AbschaÈtzung

typischer Verarbeitungskontexte unserer Beispielwelt

gegeben. In einer typischen Zell-Hierarchie nach [37]

besteht der zu entwerfende Chip aus ca. 50±100 Modu-

len, die sich selbst jeweils aus ebenfalls ca. 50±

100 BloÈ cken zusammensetzen, die wiederum jeweils in

ca. 1000 Standardzellen zerlegt werden koÈnnen. Tabel-

le 1 beinhaltet charakteristische SchaÈtzgroÈûen fuÈ r die

Eingabedaten einer Chip-Planner-Anwendung. Dabei

unterscheiden wir einen HierarchieuÈbergang mit ca.

60 Subzellen (Verarbeitungskontext VK 1) und einen

mit ca. 1000 Standardzellen (Verarbeitungskontext

VK 2). FuÈ r diese beiden Situationen wurden die folgen-

den GroÈûen berechnet:

± FCO: Anzahl der zu lesenden Komplexobjekte.

± FEO: Anzahl zugehoÈ riger Elementar-Objekte.

± DVol: Datenvolumen bei ausschlieûlicher Betrach-

tung relevanter Daten.

± FP(a): Anzahl belegter DB-Seiten bei maximaler

Clusterbildung, d.h. bei Ablage des gesamten Datenvo-

lumens DVol in aufeinanderfolgende Seiten.

± FP(b): Anzahl belegter DB-Seiten bei fehlender Clu-

sterbildung; in diesem Fall liegt jedes Elementarobjekt

auf einer eigenen Seite.

± FP(c): Anzahl belegter DB-Seiten bei 25% Nutzda-

ten pro Seite.

Die Anzahl der Komplexobjekte (FCO in Tabelle 1)

setzt sich im wesentlichen zusammen aus den 60 (1000)

Komplexobjekten vom Typ Zelle, den zugehoÈ rigen

Schnittstellen-Objekten (im Schnitt besitzen je vier Zel-

len die gleiche Schnittstelle) und den Objekten zur Be-

schreibung der Superzelle und der Konfiguration. Die

jeweiligen Anzahlen von Elementarobjekten (FEO) in-

nerhalb eines Komplexobjektes wurden aufgrund von

Erfahrungswerten und abhaÈngig vom Typ des Verarbei-

tungskontextes abgeschaÈtzt. Unsere Verarbeitungskon-

texte bestehen aus 20 Elementarobjekttypen, die im

Mittel 10 Attribute von durchschnittlich 10 Byte aufwei-

sen. Daraus ergeben sich eine ElementarobjektgroÈûe

von 100 Byte und die in Tabelle 1 enthaltenen Datenvo-

lumina (DVol). FuÈ r die Ermittlung der Seitenbelegun-

gen wurde eine SeitengroÈûe von 4 KB angenommen.

Man erkennt aus Tabelle 1 sehr deutlich, daû fuÈ r die

Ein-/Ausgabe auf dem Server und die U

È

bertragung ei-

nes Verarbeitungskontextes zwischen Server und Work-

station die Clusterbildung ein sehr entscheidender

Leistungsfaktor ist. So sind in jedem Fall wesentliche

Effizienzeinbuûen zu erwarten, wenn fuÈ r die Planung

einer Zelle mit 60 Subzellen eine Datenmenge von

20 MB zwischen Server und Workstation transferiert

werden muû und die reinen Nutzdaten nur 1/40 davon

(500 KB) betragen.

In der RealitaÈt wird die Clusterbildung von Verar-

beitungskontexten durch die zeitliche Trennung von Er-

zeugung der Objektversionen und Konfigurierung der

Verarbeitungskontexte erschwert. Wird erst unmittel-

bar vor der Werkzeuganwendung konfiguriert (dies ist

die Regel), so wird ein kostspieliges Umspeichern der

Objekte zur Erreichung optimaler Clusterbildung not-

wendig. In aÈhnlicher Weise steht ¹object sharingª der

Clusterbildung entgegen. U

È

berlappende Verarbeitungs-

kontexte koÈnnen nur unter EinfuÈhrung von Redundanz

vollstaÈndig zusammenhaÈngend gespeichert werden.

ZusaÈtzlich zum Datenvolumen macht Tabelle 1 auch

deutlich, daû typische Verarbeitungskontexte aus sehr

vielen einzelnen Objektinstanzen (und auch Objektre-

ferenzen bzw. Objektbeziehungen) aufgebaut sind. Da-

mit werden auch Anforderungen an die RepraÈsentati-

on eines Verarbeitungskontextes im Objektpuffer der

Workstation gestellt. Diese GroÈûenordnungen legen

nahe, daû im Objektpuffer entsprechende Maûnahmen

fuÈ r die effiziente Navigation und auch zugeschnittene

Zugriffspfade fuÈ r wertabhaÈngige Suche vorzusehen

sind.

Abgeschlossener vs. offener Verarbeitungskontext. Ent-

wurfsdaten von CA*-Anwendungen werden in der Re-

gel in versionierter Form verwaltet. Es gibt jedoch auch

komplexe Anwendungen (z.B. wissensbasierte Syste-

me), die auf eine Versionierung verzichten und ihre Da-

tenaÈnderungen direkt einbringen. Der Begriff des Ver-

arbeitungskontextes wird deshalb dahingehend erwei-

tert, daû seine Komponenten entweder uÈber eine Konfi-

gurierung oder direkt bestimmt werden koÈnnen.

58

1

Im mechanischen CAD entspricht der Konfigurierung die Bau-

gruppenerstellung, wobei Versionen von Bauteilen ausgewaÈhlt

werden. Verschiedene Konfigurationen fuÈhren hier zu verschie-

denen Baugruppen-Varianten.

Tabelle1. Quantitative Beschreibung der Verarbeitungskontexte

Viele Anwendungen aus Entwurfsbereichen zeich-

nen sich dadurch aus, daû ein Verarbeitungskontext be-

reits vor der Werkzeuganwendung inhaltlich fixiert

(bzw. entsprechend zusammengestellt und konfigu-

riert) werden kann. Damit kann der Verarbeitungskon-

text zu Beginn des Verarbeitungsschrittes angefordert

und im Objektpuffer installiert werden, und ein Nach-

fordern bzw. Nachladen von zusaÈtzlich benoÈ tigten Da-

ten ist unnoÈ tig. Wir bezeichnen solche Verarbeitungs-

kontexte als abgeschlossen.

Die Abgeschlossenheit der Verarbeitungskontexte

ist jedoch keine generelle Eigenschaft aller hier disku-

tierter Anwendungsbereiche. Daher ist es wichtig, auch

offene Verarbeitungskontexte zu beruÈ cksichtigen. Die-

se sind dadurch gekennzeichnet, daû sie nicht vollstaÈn-

dig zu Beginn der Werkzeuganwendung spezifiziert

werden koÈnnen und ein Nachladen von Daten waÈhrend

des Werkzeuglaufs (oder der Entwurfsarbeit) notwen-

dig werden kann.

3. Workstation/Server-Architekturen

Werkzeugorientierte Verarbeitung in Ingenieursyste-

men geschieht typischerweise in einer Workstation, wo-

bei die Entwurfsdaten wegen der Nutzung der Refe-

renzlokalitaÈ t und der graphischen Ein-/Ausgabe in der

¹NaÈhe der Anwendungª gehalten werden. Ein Server

uÈbernimmt dabei die Rolle der langfristigen Datenspei-

cherung und der Datenversorgung fuÈ r die beteiligten

Workstations. Je mehr Aufgaben bei dieser Rollenver-

teilung in die Workstation verlagert werden koÈnnen,

umso mehr Workstations lassen sich von einem Server

effizient unterstuÈ tzen. Da groûe Mengen an Daten zu

uÈbertragen sind, ist auch die Organisation der Kommu-

nikation von groûer Wichtigkeit. Einerseits gilt es hier,

das Verbindungsnetz zu entlasten, und andererseits soll

durch gebuÈndelte DatenuÈbertragung und zusaÈtzliche

Sicherungsmaûnahmen (siehe transaktionsgestuÈ tzter

RPC in Encina [13]) ein moÈglichst groûes Maû an Feh-

lerisolation erzielt werden. Diese Isolation, die durch

eine (weitgehende) gegenseitige Maskierung der Feh-

ler in Workstation und Server erreicht werden kann, ist

vor allem deshalb wichtig, weil Entwurfstransaktionen

sehr lange dauern und interaktive Entwurfsarbeit nach

MoÈglichkeit nicht unterbrochen bzw. zuruÈ ckgesetzt

werden sollte.

3.1 Charakteristika der verschiedenen Architekturtypen

Workstation/Server-Architekturen lassen sich danach

unterscheiden, wie die Datenversorgung und damit

maûgeblich die Aufgabenverteilung organisiert ist. Die

drei wichtigsten Grundformen (Page-Server, Object-

Server und Query-Server) sind in Abb.3 veranschau-

licht. Oft wird zusaÈtzlich der File-Server-Ansatz (z.B.

mit NFS) als eigenstaÈndiger Architekturtyp diskutiert.

Dieser laÈût sich als spezieller Page-Server auffassen,

der NFS als Transportmechanismus fuÈ r die zu uÈbertra-

genden Seiten benutzt. Er weist allerdings ein schlech-

teres Leistungsverhalten auf [11]. Referenzsysteme

sind die File-Server von Objectivity [28] und Gemstone

[3].

Wie Abb.3 zeigt, stellt jeder Architekturansatz durch

den Objekt-Manager den verschiedenen Anwendungen

die gleiche navigierende und objektorientierte Schnitt-

stelle zur VerfuÈ gung, und auch jeder Server besitzt als

minimale FunktionalitaÈ t (siehe grau unterlegte Kompo-

nenten) ein Speichersystem zur Verwaltung von Datei-

en auf Externspeicher (DB) und einen Seitenpuffer zur

Minimierung der physischen Ein/Ausgabe auf die DB.

Weiterhin muû der Server als zentrale Komponente die

Synchronisation der Workstation-Anforderungen uÈber-

nehmen, was wegen der langen Entwurfstransaktionen

mit Hilfe von persistenten Datenstrukturen (persisten-

te Sperren) zu geschehen hat. Vorsorgemaûnahmen fuÈ r

DB-Fehler und Server-Crash (Logging) und die Be-

handlung dieser Situationen (Recovery) gehoÈ ren eben-

falls zu den zentralen Aufgaben. In Anlehnung an die

Originalliteratur [11] erhalten die einzelnen Architek-

turtypen ihren Namen vom Granulat der Datenanfor-

derung durch die Workstation.

Beim Page-Server wird jede Seitenanforderung

workstation-seitig durch eine Fehlseitenbedingung

(Page-Fault) ausgeloÈ st; daraufhin wird die betreffende

Seite vom Server zur VerfuÈ gung gestellt. Der Server

hat dabei keine Kenntnis des Objektbegriffs: er verwal-

tet nur Seiten, die (normalerweise) auch das Granulat

der Synchronisation und des Logging darstellen. Die

Pufferung der Objekte in der Workstation kann nur

uÈber die Pufferung der zugehoÈ rigen Seiten geschehen,

in denen auch die DB-bezogene Verarbeitung (Objekt-

Manager) stattfindet. Alle objektbezogenen Zugriffe

und Auswertungen erfolgen demnach in der Worksta-

tion. Der Anwendung wird im wesentlichen eine navi-

gierende, objektorientierte Schnittstelle durch den Ob-

jekt-Manager geboten.

Ein Object-Server liefert in der Grundform auf An-

forderung (uÈber eine OID) ein einzelnes Objekt. Erwei-

terungen dieses Ansatzes erlauben eingeschraÈnkte An-

fragemoÈglichkeiten uÈber inhaltsorientierte Suche mit

Hilfe einfacher SuchausdruÈ cke (SSA: simple search ar-

guments). Auch bei diesen erweiterten Anforderungs-

59

Abb.3. Workstation/Server-Architekturen

moÈglichkeiten wird ein objektweiser Transport zur

Workstation unterstellt. Die uÈbertragenen Objekte koÈn-

nen in den Objektpuffer so eingelagert werden, daû ihre

Speicherungs- und Zugriffsstrukturen an die BeduÈ rfnis-

se der navigierenden Anwendung angepaût sind. Work-

station wie auch Server kennen ¹Objekteª, besitzen die

entsprechende VerarbeitungsfunktionalitaÈ t und sind in

der Lage, objektbezogene Manipulationen und Aus-

wertungen (Selektion, Projektion, Methoden) durchzu-

fuÈhren. Im Gegensatz zum Page-Server kann hier (wie

auch beim nachfolgend beschriebenen Query-Server)

das Objekt sowohl als Synchronisations- als auch als

Logginggranulat herangezogen werden.

Query-Server beliefern die Anwendung auf eine Anfra-

ge hin mit einer Menge von (komplexen) Objekten, die

auf einmal uÈbertragen und auf die Verarbeitungsanfor-

derungen zugeschnitten im Objektpuffer gespeichert

wird. Voraussetzung ist eine maÈchtige Anfrageschnitt-

stelle, die der Objekt-Manager der Anwendung ver-

fuÈ gbar macht. Die Verarbeitung im Objektpuffer ge-

schieht dann uÈber eine navigierende Schnittstelle.

Im folgenden werden einige wichtige Merkmale und

grundlegende Prinzipien hinsichtlich DatenrepraÈsen-

tation und Verarbeitungskonzept angesprochen, die we-

sentlich zum allgemeinen VerstaÈndnis von Workstation/

Server-Architekturen beitragen.

Speicherungsmodelle.Hinsichtlich DatenrepraÈsentation

laÈût sich das Server-Speicherungsmodell von dem WS-

Speicherungsmodell unterscheiden. Wird das Speiche-

rungsmodell des Servers auch als Speicherungsmodell

workstation-seitig uÈbernommen, so spricht man von ei-

nem Server-Speicherungsmodell (homogenes Speiche-

rungsmodell). Dies bedeutet, daû die Objektstrukturen

und Zugriffspfade im wesentlichen unveraÈndert blei-

ben, d.h. weder Konversion der Datentypen noch Attri-

butprojektion moÈglich sind. Lediglich eine Anpassung

der Objektreferenzen kann aus EffizienzgruÈnden

durchgefuÈhrt werden. Im Gegensatz dazu geht der An-

satz des WS-Speicherungsmodells von zwei unterschie-

dlichen DatenrepraÈsentationen aus. Dies aÈuûert sich

auch dadurch, daû nun zu dem Seitenpuffer im Server

noch ein Objektpuffer in der Workstation hinzukommt.

Die DatenrepraÈsentation im Objektpuffer ermoÈglicht

dabei eine Konversion der Datentypen zusammen mit

Attributprojektion und Anpassung der Objektreferen-

zen. Zur besseren UnterstuÈ tzung der Verarbeitung ist

es oft erforderlich, temporaÈre Zugriffspfade, die auch

Collections genannt werden, fuÈ r homogene Objektmen-

gen anzulegen. Diese Collections koÈnnen als Listen,

BaÈume, Hash-Strukturen u.a. ausgepraÈgt sein und da-

durch an das Zugriffsverhalten der Anwendung ange-

paût werden. Solche Collections werden vor allem dazu

eingesetzt, spezielle Referenzbeziehungen zwischen

Objekten zu verkoÈ rpern und effizient auszuwerten. Ins-

gesamt laÈût sich mit diesem Konzept eine Anpassung

von Speicherungs- und Zugriffspfadstrukturen an die

Erfordernisse der Anwendungsschnittstelle durchfuÈh-

ren.

Swizzling. In DBS ist es erforderlich, die SchluÈ ssel der

Objekte (OID) indirekt durch Verweisstrukturen (z.B.

Datenbanknr., Segmentnr., Offset) zu implementieren,

die ein Aufsuchen und Verschieben der Objekte auf Ex-

ternspeicher gestatten. FuÈ r die hauptspeicherbasierte

Verarbeitung in derWorkstation ist diese durch Indirek-

tion gewonnene FlexibilitaÈ t jedoch weniger dringlich.

Vielmehr belastet jede Indirektion das Leistungsverhal-

ten und das macht sich bei der vorherrschenden navigie-

renden Verarbeitung besonders negativ bemerkbar, da

die Auswertung einer OID-Referenz selbst bei einer ef-

fizienten Hash-Implementierung mindestens 50 In-

struktionen kostet. Eine wesentliche Verbesserung er-

zielt man durch eine Klasse von Techniken ± Pointer-

Swizzling [27] genannt ±, die externspeicherbasierte

OID-Referenzen waÈhrend der Verarbeitung auf haupt-

speicherbasierte Verweise umstellen. Ihr LoÈ sungsspek-

trum baut auf drei orthogonalen Kriterien auf: Ort,

Zeitpunkt und Art des Swizzling [20].

Wenn die Objektformate und Seitenstrukturen bei-

behalten werden muÈ ssen (z.B. beim Server-Speiche-

rungsmodell), kann In-Place-Swizzling gewaÈhlt wer-

den. Copy-Swizzling arbeitet auf Kopien der Objekte

und stellt die OID-Referenzen in der Kopie auf Verwei-

se im Hauptspeicher (oder im virtuellen Speicher) um;

dies wuÈ rde beim WS-Speicherungsmodell angewendet

werden. Beim ersten Verfahren erfolgt ein Unswizzling

der Verweise (auf die OID-Referenzen) beim ZuruÈ ck-

schreiben der geaÈnderten Seiten, waÈhrend beim zwei-

ten die RuÈ ckstellung der Verweise nur fuÈ r geaÈnderte

oder neue Objekte erforderlich ist. Das zweite Klassifi-

kationskriterium charakterisiert den Zeitpunkt der Um-

stellung, wobei sofortiges Swizzling (eager swizzling)

eine Umstellung der OID-Referenzen bei allen Objek-

ten vornimmt, sobald sie in den Hauptspeicher ge-

bracht werden. Hierbei ist die Auswertung der Verwei-

se besonders schnell, da keine LaufzeitpruÈ fung mehr er-

forderlich ist. Beim Swizzling auf Anforderung (lazy

swizzling) werden die OID-Referenzen bei Erstrefe-

renz oder spaÈter (d.h. nach anwendungsspezifischen

Kriterien) umgestellt, was bei jeder Referenzauswer-

tung eine zusaÈtzliche PruÈ fung impliziert. Weiterhin laÈût

sich als Art direktes und indirektes Swizzling unterschei-

den, d.h., jeder Verweis zeigt direkt auf das Objekt oder

nur auf einen Deskriptor des Objektes. Indirektes

Swizzling kostet wiederum mehr, da ein zweiter Ver-

weis zu verfolgen ist, jedoch gestattet es auch groÈûere

FlexibilitaÈ t, da es das spaÈtere Einladen oder die Erset-

zung von Objekten waÈhrend der Verarbeitung ermoÈg-

licht.

Hier koÈnnen wir nicht alle moÈglichen 2

3

Swizzling-

Kombinationen diskutieren und bewerten. Wegen der

Vielzahl der Verfahrensvarianten mit unterschiedlichen

Kosten duÈ rfte es schwierig sein, allgemeinguÈ ltige Re-

geln aufzustellen, bei welcher ReferenzhaÈufigkeit sich

Swizzling zu lohnen beginnt. Jedenfalls sind Faustre-

geln, die ein Swizzling empfehlen, wenn die mittlere Re-

ferenzhaÈufigkeit eines Objektes bei drei liegt, kritisch

zu hinterfragen. Hervorheben wollen wir nur das sofor-

tige, direkte Swizzling, das offensichtlich die schnellste

Referenzauswertung gestattet. Es bietet sich insbeson-

60

dere bei geschlossenen Kontexten an. In seiner Variante

auf Objektkopien koÈnnen zusaÈtzlich noch spezielle Ver-

arbeitungsanforderungen (durch das WS-Speicherungs-

modell) beruÈ cksichtigt werden.

Versionsspeicherung. Verarbeitungskontexte werden

durch Konfigurierung von Versionen von komplexen

Objekten gebildet; sie dienen als Eingabe fuÈ r die An-

wendung (WerkzeuglaÈufe). Ihr Ergebnis sind neue Ver-

sionen, die persistent zu speichern sind. Bei dieser Ver-

sionserzeugung werden in der Regel nur ein Teil der

eingegebenen (Elementar-) Objekte aktualisiert und

nur einige Objekte eingefuÈ gt bzw. geloÈ scht. Als Spei-

cherrepraÈsentationsformen lassen sich dabei die redun-

dante und die inkrementelle Versionsspeicherung unter-

scheiden. Die redundante Speicherungsform weist al-

len Objekten einer neuen Version neue SpeicherplaÈ tze

zu, die inkrementelle nur den geaÈnderten und neu hin-

zugekommenen Objekten.

In allen Architekturen ermoÈglicht die redundante

Versionsspeicherung eine optimale Clusterbildung, da

bei der DB-Integration fuÈ r alle an der neuen Version

beteiligten Objekte gezielt ein Cluster aufgebaut wer-

den kann (Seiten oder Objekte im Objektpuffer wer-

den in ein entsprechendes Speichersegment kopiert).

Im Vergleich zur versionsfreien RepraÈsentation der ge-

aÈnderten Objekte (update-in-place) verringert sich hier-

bei eher der Schreibaufwand. Es sind aber enorme Spei-

cherungskosten in Kauf zu nehmen. Inkrementelle Ver-

sionsspeicherung dagegen gewaÈhrleistet SpeicheroÈko-

nomie, verschlechtert jedoch schrittweise eine evtl. vor-

handene Clusterbildung.

Auch Synchronisationsaspekte werden wesentlich

durch das FuÈhren von Versionen beeinfluût. Bei einer

versionsfreien RepraÈsentation fuÈhren uÈberlappende

A

È

nderungsanforderungen von Transaktionen zu Zu-

griffskonflikten oder Blockierungen, waÈhrend eine Ver-

sionsbildung die konfliktfreie Zuordnung einer Version

zu einer Transaktion erlaubt. Selbst die nebenlaÈufige

Ableitung von neuen Versionen aus einer gemeinsa-

men Objektversion ist aus Sicht der Synchronisation

problemlos moÈglich. Die Synchronisation wird beson-

ders effektiv und effizient, wenn sie Versionen von

Komplexobjekten als Einheiten (z.B. fuÈ r das Sperren)

nutzen kann.

Verarbeitungsformen. Verschiedene Formen der Verar-

beitung von Anwendungsoperationen sind in Worksta-

tion/Server-Architekturen moÈglich. Einstufige Verarbei-

tung bedeutet, daû es nur einen Ort fuÈ r die (DB-bezoge-

ne) Verarbeitung der Anwendungsoperationen gibt.

Das impliziert, daû dort der aktuelle DB-Zustand vor-

liegen muû. In unserem Fall ist dieser Verarbeitungsort

die Workstation. Bei kurzen Transaktionen wuÈ rde sich

hierfuÈ r auch der Server anbieten, der mit Hilfe von

¹function request shippingª oder ¹programmierter Ver-

teilungª an die Workstation angebunden werden kann

[16]. Demnach bedeutet zweistufige Verarbeitung, daû

die Abwicklung der Anwendungsoperationen auf zwei

verschiedene Orte aufgeteilt sein kann. Dazu ist wech-

selweise der aktuelle DB-Zustand (soweit er benoÈ tigt

wird) herzustellen. In unserem Fall erstreckt sich die

Verarbeitung auf Workstation und Server.

Verarbeitungsschnittstelle. In allen Architekturen ist die

Anwendung von den Einzelheiten der Objektdarstel-

lung und des Objektzugriffs isoliert. Wegen der Kom-

plexitaÈ t der Objekte und ihrer VerknuÈpfungen wuÈ rde ei-

nerseits die Anwendungsentwicklung erschwert und an-

dererseits waÈre bei direkter Objektmanipulation durch

die Anwendung ihre IntegritaÈ t gefaÈhrdet. Deshalb fin-

det die gesamte DB-bezogene Verarbeitung unter Kon-

trolle des Objekt-Managers (siehe Abb.3) statt; er bie-

tet der Anwendung eine objektorientierte Schnittstelle

mit objektweiser Verarbeitung, wobei die Objektmani-

pulation durch Methodeneinsatz erfolgt. Optional kann

mit einer Query-Schnittstelle zusaÈtzlich eine mengen-

orientierte Verarbeitungsweise eingefuÈhrt werden.

Die Art der IntegritaÈ tssicherung ist weitgehend

durch die objektorientierte Schnittstelle vorgegeben.

Einfache IntegritaÈ tsbedingungen wie die Typkorrekt-

heit oder Einhaltung von Wertebereichen koÈnnen

durch Nutzung abstrakter Datentypen fuÈ r Objektattri-

bute gewaÈhrleistet werden. Komplexere Bedingungen

wie attributuÈbergreifende Zusicherungen innerhalb ei-

nes Objekts lassen sich innerhalb der Objekt-Kapsel-

ung, z.B. durch entsprechende Methoden, realisieren.

FuÈ r objektuÈbergreifende Bedingungen (z.B. symmetri-

sche Referenzbeziehungen) stellt die Objekt-Manager

klassenspezifische oder gar globale Methoden zur Ver-

fuÈ gung. Bei der U

È

berpruÈ fung kann es erforderlich sein,

Objekte (Seiten) aus der DB nachzuladen.

Persistenz. Aus Sicht der Anwendung ist es wuÈnschens-

wert, transiente und persistente Daten nebeneinander

und gleichfoÈ rmig benutzen zu koÈnnen. Wenn Anwen-

dung und DBS dasselbe Datenmodell verwenden

(seamless interface), ist dies auf einfache Weise moÈg-

lich. Dazu ist es sinnvoll, die Persistenz von Objekten

typunabhaÈngig zu realisieren. Erreichen laÈût sich dies

z.B. durch einen speziellen Allokieroperator (wie bei

ObjectStore [24]), durch den die ¹Lebensdauerª eines

Objektes zum Zeitpunkt seiner Erzeugung festgelegt

wird. Eine andere MoÈglichkeit ist, Persistenz uÈber die

Erreichbarkeit (wie bei O

2

[10]) zu definieren, d.h., ein

Objekt wird persistent, sobald es von einem bereits

persistenten Objekt referenziert wird.

3.2 Grundformen der Workstation/Server-Architekturen

Nach diesem kurzen U

È

berblick uÈber die Workstation/

Server-Architekturen soll ihre Eignung fuÈ r die werk-

zeugorientierte Verarbeitung im Detail diskutiert wer-

den. Dabei beziehen wir uns auf die AusfuÈhrungen in

Abschn.3.1, insbesondere Abb.3, und die Aufgaben,

die bereits in Kapitel 1 identifiziert worden sind. WaÈh-

rend in diesem Abschnitt zunaÈchst die Grundformen

der Architekturen diskutiert werden, gehen wir im an-

schlieûenden Abschn.3.3 auf Verbesserungen und Er-

weiterungen ein.

61

3.2.1 Page-Server

Bei der Grundform des Page-Servers bleibt die Ein-

richtung eines Objektpuffers in der Workstation auûer

Acht. Die DB-bezogenen Operationen erfolgen direkt

auf den im Seitenpuffer eingelagerten Seiten. Wegen

ihrer Einfachheit wurde die Page-Server-Architektur

bisher in vielen Systemimplementierungen bevorzugt.

Bekannte Vertreter sind ObjectStore [24] und O

2

[10].

Datenversorgung. Wie bereits eingefuÈhrt, erfolgt die

Datenversorgung uÈber den Austausch einzelner Seiten,

gesteuert uÈber Fehlseitenbedingungen, die beim Ob-

jektzugriff entstehen. Bei der Anforderung wird die

voraussichtliche Verwendung der Seite (Lesen, Schrei-

ben) spezifiziert, so daû der Lock-Server die entspre-

chenden Sperren anlegen kann. Eine NutzungsaÈnde-

rung (Schreiben) verlangt deshalb eine explizite Sperr-

konversion.

Der Kommunikationsaufwand zwischen Server und

Workstation ist bestimmt durch die Anzahl und GroÈûe

der zu uÈbertragenden Seiten (z.B. 4 KByte). Die U

È

ber-

tragung einer ganzen Seite benoÈ tigt nur etwa doppelt so-

viel Zeit wie die eines einzelnenObjektes, dessen GroÈûe

vielleicht 100 Byte betraÈgt, ist also pro Speichereinheit

guÈnstiger. Um diesen Effekt gewinnbringend einsetzen

zu koÈnnen, sollten im Schnitt mindestens zwei Objekte

in jeder Seite von der Anwendung benoÈ tigt werden. Im

Sinne der Optimierung ist es also zwingend geboten,

moÈglichst viele von der Anwendung benoÈ tigten Objek-

te in moÈglichst wenigen Seiten unterzubringen. Diese

Clusterbildung geschieht aber in der Regel zum Zeit-

punkt der Objekterzeugung, so daû sie aus der Sicht

nachfolgender Anwendungen unveraÈnderbar ist und

auch sehr unguÈnstig sein kann. Mangelnde Clusterbil-

dung (entsteht z.B. bei Anwendungen mit uÈberlappen-

den Objektmengen) zeigt eine Reihe von schwerwie-

genden negativen Auswirkungen. Je weniger angefor-

derte Objekte in einer Seite sind, umso mehr ¹andereª

Objekte sind normalerweise in ihr gespeichert. Da-

durch ist die referenzierte Seitenmenge groÈûer, was fuÈ r

die gleiche Objektmenge einen hoÈheren U

È

bertragungs-

aufwand und groÈûere Pufferbereiche impliziert. Das be-

deutet weiterhin, je geringer die Clusterbildung ist,

umso stoÈ render wird die Wirkung der Seitensperren auf

parallele Transaktionen. Die Spannweite der dabei ent-

stehenden Kosten lassen sich bei unserer Referenzan-

wendung leicht aus Tabelle 1 in Abschn.2.2 ableiten.

Der staÈndige Austausch von Seiten wirkt einer star-

ken Fehlerisolation zwischen Workstation und Server

entgegen. Wegen der haÈufigen Eintragungen ist es zu

teuer, die aktuelle Sperrtabelle persistent zu halten.

Ein Server-Crash impliziert aber dann den Abbruch

der Verarbeitung in allen Workstations, da nach Wie-

deranlauf keine konsistente Fortsetzung der Datenver-

sorgung garantiert werden kann. Seitenanforderungen

waÈhrend des Ausfalls wuÈ rden ohnehin zu VerzoÈ gerun-

gen oder zum Abbruch der Verarbeitung fuÈhren.

DatenrepraÈsentation in der Workstation.Da die Konver-

tierung der Seiten vom Externspeicherformat des Ser-

vers in das Hauptspeicherformat der Workstation moÈg-

lichst geringen Aufwand verursachen soll, werden so-

wohl im Server als auch in der Workstation in der Re-

gel gleiche Seitenformate benutzt (homogenes Speiche-

rungsmodell). Durch die Wahl der zu unterstuÈ tzenden

Programmiersprache sind so Modell und Formate auf

dem Server festgelegt. Damit ist der Ansatz (eher) mo-

nolingual, und fuÈ r die Integration in weitere Sprachen

sind umfangreiche VeraÈnderungen (auch im DBS) er-

forderlich.

Da die Seiteninhalte ungeschuÈ tzt in den Seitenpuffer

der Workstation eingelagert werden, ergibt sich prinzi-

piell ein Problem bei der objektbezogenen Zugriffskon-

trolle, d.h., es gibt keine besonderen Schutzmaûnahmen

fuÈ r die mitgelieferten, aber nicht benoÈ tigten Objekte,

fuÈ r die moÈglicherweise gar keine Zugriffsrechte vorlie-

gen. Es ist deshalb zu fordern, daû Seitenpuffer und Sy-

stemsoftware (Objekt-Manager u.a.) durch spezielle

Maûnahmen (getrennte AdreûraÈume) hinreichend

stark von der Anwendung isoliert werden.

Wegen der sprachbezogenen RepraÈsentation der Ob-

jekte in den Seiten findet auch keine besondere Anpas-

sung an die BeduÈ rfnisse der Anwendung statt. Insbeson-

dere fehlt die MoÈglichkeit der Attributprojektion, da

die Seiteninhalte vom Server uÈbernommen und in der

Workstation unveraÈndert bleiben; es sind also immer

alle Attribute eines Objektes sichtbar, obwohl in der

Regel nur eine Teilmenge davon benoÈ tigt wird.

Sind zur inhaltsorientierten Suche spezielle Zugriffs-

pfade des DBS erforderlich, so werden diese seitenwei-

se zur Workstation uÈbertragen und dort im Seitenpuf-

fer verarbeitet. Auf diese Weise muÈ ssen alle Suchvor-

gaÈnge und Datenmanipulationen in derWorkstation ab-

gewickelt werden, was einer einstufigen Verarbeitung

entspricht. Dies bedeutet aber auch, daû bei einem Ob-

jekttyp-Scan alle Seiten des betroffenen Speicherseg-

ments zur Workstation zu transportieren sind, und zwar

unabhaÈngig von der SelektivitaÈ t des Sucharguments.

Verarbeitung der Anwendungsobjekte. Wie bereits er-

waÈhnt bietet der Objekt-Manager der Anwendung eine

objektorientierte Schnittstelle, durch die die Objektma-

nipulation und die Art der IntegritaÈ tssicherung weitge-

hend vorgegeben sind.

Integration. Am Ende der Transaktion sind verzoÈ gerte

IntegritaÈ tsbedingungen zu uÈberpruÈ fen, was ebenfalls

moÈglicherweise unter Nachladen von Seiten in der

Workstation zu geschehen hat. Alle zum Schreiben an-

geforderten Seiten muÈ ssen zum Commit an den Server

zuruÈ ckgeschickt werden (erzwungenes ZuruÈ ckschrei-

ben, engl. FORCE). Da der Server nur Seiten und kei-

ne Objekte kennt, muû er als Log-Information zwangs-

laÈufig jeweils ganze Seiten schreiben.

3.2.2 Object-Server

In der Grundform dieses Ansatzes werden die Objekte

durch die Anwendung ausschlieûlich uÈber Navigation

referenziert. Der Zugriff auf ein im Objektpuffer feh-

62

lendes Objekt produziert dabei genau eine Objektfehl-

bedingung, die zur Anforderung genau dieses Objektes

an den Server fuÈhrt. Dieser laÈdt die zugehoÈ rige Seite

oder Seitenmenge in seinen Seitenpuffer, kopiert aus

ihr das gewuÈnschte Objekt in seinen Objektpuffer,

sperrt es und liefert es der Workstation. Im Vergleich

zum Page-Server weist der Object-Server eine deutlich

hoÈhere SystemkomplexitaÈt auf. Als Workstation/Ser-

ver-Systeme, die diesen Ansatz verfolgen, sind zu nen-

nen: Ontos [29], Versant [36] und Itasca (Orion) [21].

Wir betrachten hier nur kleine Objekte, die in einer

Seite oder in wenigen Seiten gespeichert werden koÈn-

nen. Wirklich groûe Objekte, etwa Multimedia-Objek-

te, erfordern spezielle LoÈ sungsverfahren. Es liegt nahe,

die Objekte selbst als Einheit von Synchronisation und

Recovery auf dem Server zu verwenden, zumal man da-

mit eine sehr gute UnterstuÈ tzung der ParallelitaÈ t zwi-

schen Anwendungen und ein effektives Logging er-

zielt. Die beim Page-Server geschilderten Probleme

hinsichtlich der Fehlerisolation gelten wegen der HaÈu-

figkeit der Objektanforderungen auch hier.

Datenversorgung. Die Objekte selbst bilden das Aus-

tauschgranulat zwischen Server und Workstation. Der

Kommunikationsaufwand ist bestimmt durch die An-

zahl und GroÈûe der zu uÈbertragenden Objekte (vgl. Ta-

belle1) und ist insensitiv gegenuÈber Clusterbildung zu-

sammengehoÈ riger Objekte in gemeinsamen Seiten. Die

Clusterbildung wirkt sich hierbei nur kostensparend

bei der Ein-/Ausgabe von der DB zum Seitenpuffer des

Servers aus. Betrifft die sukzessive Objektanforderung

mehrere Objekte aus einer Seite, so werden unabhaÈngi-

ge U

È

bertragungsvorgaÈnge initiiert; dabei summieren

sich die Kosten fuÈ r alle erforderlichen Aktionen (RPC,

Kopieren, Konvertieren, . . .).

Bei diesem Ansatz erhaÈ lt die Workstation alle Ob-

jekte, die sie referenziert, und zwar mit saÈmtlichen At-

tributen, obwohl in der Regel nur ein Teil der Attribute

fuÈ r die Verarbeitung notwendig ist (keine Projektions-

moÈglichkeit). Zudem wird jedes Attribut, wie groû

auch immer, vollstaÈndig im Objektpuffer abgelegt. Wei-

terhin kann bei wertabhaÈngiger Objektverarbeitung

erst im Objektpuffer uÈberpruÈ ft werden, ob ein Objekt

die Suchbedingung erfuÈ llt. Beispielsweise erfordert ein

Objekttyp-Scan das aufeinanderfolgende Holen aller

betroffenen Objekte in die Workstation und ihre U

È

ber-

pruÈ fung im Objektpuffer. Besonders bei hoher Scan-Se-

lektivitaÈ t impliziert diese Verarbeitungsweise ein hohes

Maû an nutzlosen DatenuÈbertragungen.

DatenrepraÈsentation in der Workstation.Auf Server und

Workstation koÈnnen unterschiedliche Satzformate in-

nerhalb der Objektpuffer existieren. Die Formate im

DBS und in der Anwendungssprache sind zwar nicht

zwingend abhaÈngig voneinander, jedoch ist bei Spra-

chen mit aÈhnlicheren Formaten eine effizientere und

einfachere UnterstuÈ tzung moÈglich, da hier der Konver-

tierungsaufwand geringer ist.

Verarbeitung der Anwendungsobjekte. Genau wie beim

Page-Server sind Objektmanipulation und auch die Art

der IntegritaÈ tssicherung durch die objektorientierte

Schnittstelle weitgehend vorgegeben.

Integration. Nach der Verarbeitung durch die Anwen-

dung erfolgt das Unswizzling aller geaÈnderten Objekte,

die dann zum Server zuruÈ ckgeschickt werden (FORCE

bei Check-in). Dort muÈ ssen alle ObjektaÈnderungen in

die betreffenden Seiten eingebracht werden. FuÈ r die

Log-Funktion bietet sich in diesem Fall Eintrags-Log-

ging (Objekt-Logging) an.

3.2.3 Query-Server

Die wichtigste Erweiterung im Vergleich zum Object-

Server ist an der Schnittstelle zur Anwendung zu fin-

den. Diese Schnittstelle mit ihrer objektorientierten, na-

vigierenden VerarbeitungsmoÈglichkeit wird durch eine

allgemeine Anfragesprache ergaÈnzt, mit der die An-

wendung ihre Datenanforderungen formulieren kann.

Die Datenbereitstellung kann dabei vom Query-Server

mengenorientiert erfolgen, die Datenverarbeitung ge-

schieht wiederum navigierend.

Query-Server-Architekturen wurden bisher nur als

Prototyp-Systeme erprobt. Das Spektrum ihrer Reali-

sierungsvarianten wird durch folgende Implementierun-

gen illustriert: PRIMA [15], AIM-P [23], XNF [26],

Starburst's Coexistence Approach [2], KRISYS [35],

Persistence [19], PENGUIN [25], andADMS-EWS [31].

Bei der Diskussion des Verarbeitungszyklus gehen

wir zunaÈchst in der Diskussion der Grundform des

Query-Servers von einem abgeschlossenen Kontext aus,

bei dem alle Operationen (auûer der Extraktion und In-

tegration der Daten) einstufig, d.h. nur in der Worksta-

tion, abgewickelt werden koÈnnen. Dabei wird durch

eine oder mehrere aufeinanderfolgende Anfragen der

benoÈ tigte Kontext geholt (Check-out); nach ausschlieû-

lich lokalen Manipulationen und IntegritaÈ tspruÈ fungen

werden die geaÈnderten Daten bei Commit zuruÈ ck zum

Server propagiert und in die DB integriert (Check-in).

Datenversorgung. Vor Beginn der Verarbeitung wird

der gesamte Kontext durch eine oder mehrere Anfra-

gen spezifiziert. Typischerweise wird dieser eine Menge

von komplexen Objekten (netzwerkartig verknuÈpfte

Objektmengen heterogener Art) umfassen, die man

beispielsweise mithilfe von MQL- oder SQL/XNF-An-

weisungen [26] beschreiben kann. Bei SQL muÈûte man

zur Ableitung einer Menge von komplexen Objekten

Anfragen zulassen, die sich aus mehreren Anweisun-

gen zusammensetzen.

Die Auswertung der Anfrage findet im Server statt,

wobei die komplexen Objekte (je nach Datenmodell

unterschiedlich) abgeleitet und in Transferpuffern ge-

sammelt werden. Durch Operationen wie Projektion,

Selektion oder Verbund koÈnnen die Objekte genau an

die Sicht der Anwendung angepaût werden. Bei der

Wahl des Sperrkonzeptes und -granulats bleiben alle

Freiheitsgrade erhalten. Idealerweise sollten die kom-

plexen Objekte als Ableitungseinheit direkt gesperrt

werden. Dies ist jedoch dann nicht moÈglich, wenn sie

63

als dynamisch definierte und netzwerkartig verknuÈpfte

Strukturen keinen RepraÈsentanten besitzen, der als

Sperrhalter benutzt werden kann. Deshalb sind in ei-

nem solchen Fall alle Objekte der Menge einzeln zu

sperren. Liegt ein geeignetes Versionskonzept fuÈ r den

Kontext vor [22], so laÈût sich der VersionsrepraÈsentant

als Sperrhalter heranziehen.

Als Abschluû der Check-out-Operation wird die ge-

samte Ergebnismenge auf einmal zur Workstation

transferiert und im Objektpuffer allokiert. Ausgehend

von der Annahme, daû im Schnitt nur etwa 50% der

Daten eines fuÈ r die Werkzeugverarbeitung relevanten

Objektes projiziert werden, entspricht hier das tatsaÈchli-

che Volumen der zu transportierenden und in der

Workstation einzulagernden Daten der HaÈlfte des in

Tabelle 1 aufgefuÈhrten Gesamtdatenvolumens (DVol).

Da bis zum Check-in keine weiteren Kontakte mit dem

Server erforderlich sind, resultiert aus dieser Art der

Datenversorgung eine maximale Isolation im Fehlerfall

(z.B. Crash von Server oder Workstation).

DatenrepraÈsentation in der Workstation. Es wurde be-

reits unterstrichen, daû die Anwendung ihre Sicht auf

die Objekte spezifizieren kann. Zur effizienteren Refe-

renzierung lassen sich alle Beziehungen zwischen Ob-

jekten als Hauptspeicheradressen auspraÈgen. Da die

Speicherungsstrukturen der komplexen Objekte expli-

zit angelegt werden, koÈnnen sie (bereits im Transferpuf-

fer) optimal auf das Zugriffsverhalten der Anwendung

zugeschnitten werden. Falls spezielle Scans oder inhalt-

liche SuchvorgaÈnge im Objektpuffer zu unterstuÈ tzen

sind, ist es in einfacher Weise moÈglich, passende Haupt-

speicher-Zugriffspfade zu erzeugen. Der Query-Server-

Ansatz bietet also maximale FlexibilitaÈ t fuÈ r Objekt-

repraÈsentation und ZugriffsunterstuÈ tzung, welche we-

gen der objektweisen Anforderung bei den anderenAn-

saÈtzen nicht gegeben ist.

Verarbeitung der Anwendungsobjekte. Die dominieren-

de Verarbeitungsart ist navigierend, wobei die Wahl

der Speicherungsstrukturen ihre Leistung verbessern

sollte. Als bewaÈhrtes Cursor-Konzept fuÈ r komplexe Ob-

jekte lassen sich hierarchische Cursor [17] einfuÈhren,

deren strukturelle AbhaÈngigkeiten der Objekt-Mana-

ger kontrollieren kann.

Integration. Bei der A

È

nderung von Objekten sind diese

zu markieren, so daû bei Commit das Check-in selektiv

erfolgen kann. So ist es moÈglich, daû nur die geaÈnder-

ten Attribute der Objekte (Netto-A

È

nderungen) auf ein-

mal zum Server zuruÈ cktransferiert werden. Als Zusatz-

aufwand faÈ llt jetzt die Wiederholung der A

È

nderungen

auf Serverseite an. Dazu sind alle betroffenen Objekte

mit ihren Seiten aufzusuchen und, falls noch nicht vor-

handen, in den Serverpuffer zu laden. Die Integration

der A

È

nderungen betrifft die Objekte und ihre abhaÈngi-

gen Strukturen wie Zugriffspfade usw. Auch hier bietet

sich das Eintrags-Logging fuÈ r die Log-Funktion an.

3.3 Weiterentwicklungen der Architektur-Grundformen

In den vorangegangenen Abschnitten sind einige

Schwachstellen der Architekturen angesprochen wor-

den. Im folgenden werden Weiterentwicklungen vorge-

stellt, die diese Schwachstellen vermeiden sollen.

3.3.1 Erweiterungen des Page-Servers

Workstation-seitige Optimierung. Wichtig fuÈ r eine Stei-

gerung der Effizienz ist die BeruÈ cksichtigung der Verar-

beitungslokalitaÈ t und des Zugriffsverhaltens der An-

wendung. Dazu ist es sinnvoll, die Speicherungsstruk-

tur der Objektmengen beeinflussen zu koÈnnen. Wie be-

reits in Abb.3 angedeutet, laÈût sich die Page-Server-Ar-

chitektur durch EinfuÈhrung eines Objektpuffers ent-

sprechend erweitern. Damit wird gleichzeitig die Inte-

gration anderer Sprachen in das System sehr viel einfa-

cher. Die Objekte werden dabei aus den uÈbertragenen

Seiten extrahiert und in einer der Anwendungsverarbei-

tung angepaûten Form in einem Objektpuffer eingela-

gert. Falls diese Anpassung Projektion von Attributen,

Typkonversion und Pointer-Swizzling erlaubt, koÈnnen

viele Nachteile der direkten U

È

bernahme des Server-

Speicherungsmodells vermieden werden.

In der Workstation kann man nun entweder den Sei-

tenpuffer durch einen Objektpuffer ersetzen oder aber

zusaÈtzlich zu dem Seitenpuffer einen Objektpuffer hal-

ten. In jedem Fall ergeben sich zusaÈtzliche Kosten, da ei-

nerseits die Objekte aus den Seiten in die entsprechen-

den Speicherungsstrukturen des Objektpuffers kopiert,

und andererseits alle ObjektaÈnderungen in den betref-

fenden Seiten nachgefuÈhrt werden muÈ ssen. Werden Sei-

ten redundant zu Objekten gehalten, wird im Vergleich

zur anderen Variante (ausschlieûliche Verwendung ei-

nes Objektpuffers) das Nachladen von Seiten zum

Zwecke der Einlagerung der zum Server zu propagie-

renden, geaÈnderten Objekte vermieden; jedoch ver-

schlechtert sich die Speicherplatzausnutzung in der

Workstation.

Server-seitige Optimierung. Bisher wurde unterstellt,

daû der Server nur Seiten kennt, also nur diese als Ein-

heiten des Sperrens und des Logging waÈhlen kann. Da-

durch wird das Logging enorm speicherintensiv, und

(schreibgeschuÈ tzte) Seiten koÈnnen nicht vor Commit

der Transaktion, der sie zugeteilt wurden, einer ande-

ren Transaktion in einer anderen Workstation verfuÈ g-

bar gemacht werden.

Sobald der Server Objekte kennt, kann er die globale

Synchronisation auf der Basis von Objektsperren be-

werkstelligen. Die Objektanforderung der Anwendung

(uÈber OIDs) wird, falls das Objekt nicht in der Worksta-

tion gefunden wird, an den Server weitergereicht. Bei

SperrgewaÈhrung wird das Objekt O

i

zusammen mit sei-

ner Hausseite zur Workstation uÈbertragen, wobei die

Objektsperre als ¹langª (bis Commit) und die Seiten-

sperre als ¹kurzª eingetragen wird, d.h., eine Seite

kann waÈhrend einer Transaktion vom Server zuruÈ ckge-

fordert und einer anderen Workstation zugeordnet wer-

64

den, wenn dort ein Objekt O

k

bearbeitet werden soll

oder wenn die neue Sperranforderung vertraÈglich zur

Sperre von O

i

ist. Dieser Ansatz, der viele Aspekte von

DB-Sharing [30] aufweist und eine gemeinsame Nut-

zung von Seiten in parallelen Transaktionen gestattet,

besitzt folgende Verarbeitungseigenschaften:

± Jede Objektsperre wird einzeln beantragt. Bei Clu-

sterbildung werden zwar viele zusammengehoÈ rige Ob-

jekte auf einmal uÈbertragen, bei Erstreferenz muÈ ssen

die Sperren jedoch objektweise vom Server angefor-

dert werden.

± Falls in den Seiten direkt gearbeitet wird (Server-

Speicherungsmodell), verursacht die ZuruÈ ckforderung

oder der Austausch von Seiten zusaÈtzliche Kosten,

wenn Swizzling angewendet wird. Auûerdem koÈnnen

Objektverschiebungen und Split-VorgaÈnge auftreten.

± Ist ein Objektpuffer vorhanden (WS-Speicherungs-

modell), so sind ObjektaÈnderungen verschiedener

Transaktionen bei deren Commit in eine Seite einzu-

bringen, was sehr aufwendig sein kann (z.B. bei B*-

Baumseiten).

± Es ist ein Caching von Seiten uÈber Commit-Grenzen

hinaus moÈglich. Damit kann ein Verarbeitungskontext

(inklusive der Sperren) direkt an den nachfolgenden

Verarbeitungsschritt weitergegeben und so eine erneute

Ladephase eingespart werden. Eine SeitenuÈbertragung

erfolgt dann beispielsweise erst auf Veranlassung einer

anderen Workstation. Diese Vorgehensweise erfordert

die BeruÈ cksichtigung von sog. KohaÈrenz-Protokollen

[4], die die AkutalitaÈ t der lokalen Daten garantieren.

± Die Workstation kann Log-Aufgaben uÈbernehmen

und eintragsbezogenes oder logisches Logging durch-

fuÈhren und die Log-Information dem Server geblockt

zur VerfuÈ gung stellen. Auf diese Weise kann der globa-

le Log wesentlich platz- und E-/A-sparender organi-

siert werden.

In [5] werden weitere MoÈglichkeiten der Erweiterung

des Page-Server-Ansatzes hinsichtlich feinerer Synchro-

nisationsgranulate im Detail diskutiert.

3.3.2 Erweiterungen des Object-Servers

Die bisher skizzierte Grundform des Object-Servers

kann in mehreren Aspekten verbessert werden, um vor

allem Kommunikationskosten und Speicherplatzbedarf

zu reduzieren. Besonders wichtig erscheint eine Erwei-

terung bei der Objektanforderung, die neben der An-

forderung uÈber OIDs zumindest eine inhaltsorientierte

Suche mit einfachen SuchausdruÈ cken erlauben sollte.

Voraussetzung ist jedoch eine entsprechend groûe Aus-

drucksmoÈglichkeit der Anwendungsschnittstelle.

Einfache Suchbedingungen. Durch diese scheinbar

¹geringfuÈ gigeª Erweiterung erzwingt man jedoch einen

U

È

bergang zur zweistufigen Verarbeitung. Dies fuÈ hrt im

allgemeinen eine hohe ZusatzkomplexitaÈt ein, da von

einer potentiell replizierten DB ausgegangen werden

muû. Durch die ObjektaÈnderungen im WS-Objektpuf-

fer sind manche Objekte in zwei Versionen im System

(veraltete Version im Server) vorhanden. In Ab-

schn.3.3.3 wird gezeigt, daû bei allgemeinen Anfragen

der aktuelle DB-Zustand erst auf Server- oder Worksta-

tionseite hergestellt sein muû, bevor die Anfrage in

konsistenter Weise evaluiert werden kann. Das erfor-

dert aber beispielsweise eine Propagierung von A

È

nde-

rungen zum Server oder ein Nachladen des Auswer-

tungskontextes zur Workstation.

Die BeschraÈnkung auf einfache SuchausdruÈ cke ge-

waÈhrleistet die U

È

berpruÈ fbarkeit des SuchpraÈdikats auf

jeweils einem Objekt, was hier zur Vereinfachung des

Suchvorgangs ausgenutzt werden kann. Wegen des spe-

ziellen SuchpraÈdikates kann mit Hilfe der folgenden

Vorgehensweise auf den im allgemeinen erforderlichen

Auswertungs-Overhead verzichtet werden. Ein Objekt-

typ-Scan mit dem SuchpraÈdikat SP liefert auf dem Ser-

ver im allgemeinen eineMenge potentiell veralteterOb-

jekte. Diese Treffermenge kann auûerdem zu groû oder

unvollstaÈndig sein, da in der Workstation entsprechen-

de Objekte geloÈ scht, geaÈndert oder neu erzeugt worden

sein koÈnnen. Eine Suche mit dem gleichen SuchpraÈdi-

kat SP in der Workstation stellt eine Menge aktueller

Objekte bereit. Diese Treffermenge kann ebenfalls un-

vollstaÈndig sein, da nicht alle Objekte, die sich fuÈ r SP

qualifizieren, in der Workstation gepuffert sein muÈ ssen.

Zur Konstruktion der aktuellen Treffermenge kommt

erschwerend hinzu, daû auch geloÈ schte oder geaÈnderte

Objekte im WS-Objektpuffer, die SP erfuÈ llt haben, zu

beruÈ cksichtigen sind. Diese Objekte sind nur als ge-

loÈ scht oder geaÈndert markiert, da die betreffenden A

È

n-

derungen noch zum Server propagiert werden muÈ ssen.

Die aktuelle Objektmenge, die sich fuÈ r SP qualifi-

ziert, muû durch Vergleich der OIDs imWS-Objektpuf-

fer konstruiert werden. Dazu fuÈhren wir folgende Be-

zeichnungen ein:

± OID

Server

: Menge der OIDs der Objekte, die vom

Server angeliefert werden

± OID

qual

: Menge der OIDs der Objekte, die im WS-

Objektpuffer SP erfuÈ llen (unveraÈnderte

Objekte, neu eingefuÈ gte Objekte und ge-

aÈnderte Objekte, so daû SP nach A

È

nde-

rung erfuÈ llt)

± OID

mod

: Menge der OIDs der Objekte, die im WS-

Objektpuffer SP nicht mehr erfuÈ llen (ge-

loÈ schte Objekte, geaÈnderte Objekte, so

daû SP nach A

È

nderung nicht mehr erfuÈ llt)

OID

qual

und OID

mod

sind disjunkt; OID

qual

∪ OID

mod

ergibt OID

WS

als Menge der OIDS aller betroffenen

Objekte in der Workstation. Somit laÈût sich die aktuel-

le Ergebnismenge OID

Erg

fuÈ r SP wie folgt ableiten:

OID

Erg

= OID

qual

∪ (OID

Server

-OID

WS

)

Besonders einfach wird diese Ergebnisbereitstellung,

wenn keine betroffenen Objekte im WS-Objektpuffer

gespeichert sind:

OID

Erg

= OID

Server

65

Projektion. Es bleibt aber auch bei dieser Erweiterung

das Problem, daû alle Attribute eines Objektes, die

sehr groû sein koÈnnen (Text oder Grafik), vollstaÈndig

in der Workstation abgelegt werden. Wenn im voraus

bekannt ist, welche Attribute (oder Attributwertinter-

valle) bearbeitet werden, ist eine ProjektionsmoÈglich-

keit auf Typ- oder Wertebene vorteilhaft. Das fuÈhrt al-

lerdings zu neuen Problemen, da durch das Wegfallen

eines Attributes evtl. einige Methoden nicht mehr an-

wendbar sein koÈnnen.

Delegation von IntegritaÈtspruÈ fungen. Um den U

È

ber-

tragungsaufwand bei einmaligen Objektreferenzen zu

begrenzen, koÈnnen in einer Anwendung AuftraÈge zur

IntegritaÈ tsuÈberpruÈ fung an den Server delegiert werden.

Dabei sind Vorkehrungen erforderlich, um fuÈ r die Inte-

gritaÈ tspruÈ fung im Server den aktuellen DB-Zustand zu

gewaÈhrleisten.

Komplexe Objekte. Eine Erweiterung dieses Ansatzes,

bei der dem Object-Server die Strukturbeziehungen

zwischen den Elementarobjekten bekannt gemacht

werden, zielt auf eine betraÈchtliche Verminderung der

Kommunikation zwischen Server und Workstation ab.

Dabei kann der Object-Server bei Anforderung eines

Wurzelobjektes abhaÈngige Objekte bestimmen und als

komplexes Objekt in einem Vorgang zur Workstation

uÈbertragen. Dadurch laÈût sich auûer dem Kommu-

nikationsaufwand auch die Last auf dem Server, der fuÈ r

jedes Objekt mehrmals die zwischendurch vielleicht so-

gar verdraÈngte Seite abarbeiten muû, reduzieren. Bei

dieser Vorgehensweise haÈngt jetzt die Anzahl der Da-

tentransfer-VorgaÈnge von der Anzahl der benoÈ tigten

komplexen Objekte ab (siehe Tabelle 1). Jedoch blei-

ben bei diesem Ansatz die komplexen Objekte fuÈ r die

Anwendungen statisch, d.h. fest vorgegeben, und es ist

nicht moÈglich, dynamisch beliebige komplexe Objekte

zusammenzustellen.

Diese Erweiterung zum Complex-Object-Server und

die inhaltsorientierte Suche sind erste Schritte in Rich-

tung Query-Server, der auf eine Anforderung hin eine

Menge von komplexen Objekten auf einmal zuruÈ cklie-

fert. Die dabei auftretende VerarbeitungskomplexitaÈ t

wird im nachfolgenden Kapitel diskutiert.

3.3.3 Erweiterungen des Query-Servers

Der allgemeine Fall bezieht sich auf einen offenen Kon-

text und wird benoÈ tigt, wenn der Verarbeitungskontext

nicht vollstaÈndig im voraus bekannt ist; er schlieût meh-

rere Check-out sowie die Delegation von PruÈ fauftraÈgen

an den Server oder das Nachladen von Daten zum

Zwecke der IntegritaÈ tspruÈ fung ein. Diese Verarbei-

tungsform wurde als zweistufig bezeichnet.

Da Anfragen verschickt werden, besitzt die Grund-

form schon die volle funktionale MaÈchtigkeit. Die Er-

weiterungen beziehen sich deshalb hier auf die Unter-

stuÈ tzung flexiblerer Anwendungsanforderungen (offe-

ner Kontext) und die Optimierung der Anfrageverar-

beitung (Delegation von Teilanfragen).

Offener Kontext. Im Verlauf des Verarbeitungszyklus

wird der Kontext in der Workstation staÈndig aktuali-

siert. Dabei koÈnnen die A

È

nderungen (nicht-freigegebe-

ne Daten) beim abgeschlossenen Kontext bis zum

Check-in im Objektpuffer gehalten werden, bis sie

dann auf einmal zum Server propagiert werden. In die-

sem Fall ist der Teil der aktuellen DB, der von der An-

wendung referenziert wird, ausschlieûlich im Objekt-

puffer. Beim offenen Kontext dagegen wird vom Prin-

zip her eine zweistufige Verarbeitung erzwungen, fuÈ r

die jeweils der aktuelle DB-Zustand, der aus der Sicht

der Anwendung alle ihre bisherigen A

È

nderungen einzu-

schlieûen hat, verfuÈ gbar sein muû. Die wesentliche

Schwierigkeit besteht dabei darin, daû es sich bei der

Workstation/Server-Datenverteilung um eine teilweise

replizierte DB handelt, da A

È

nderungen in Datenkopi-

en im Objektpuffer erfolgen und diese nicht sofort in

die (globale) Server-DB propagiert werden. Das unmit-

telbare NachfuÈhren jeder A

È

nderung auf der Serverseite

wuÈ rde jedoch die NuÈ tzlichkeit des gesamten Ansatzes

in Frage stellen.

Um uÈberhaupt nach tragfaÈhigen LoÈ sungskonzepten

suchen zu koÈnnen, treffen wir die Annahme, daû es

sich bei den Check-out- oder anderen Nachladeforde-

rungen um relativ seltene Ereignisse handelt, weil sonst

das Gesamtsystem fast nur noch mit der Herstellung

des aktuellen DB-Zustandes beschaÈftigt sein duÈ rfte.

Folgende Vorgehensweisen sind moÈglich:

• Nicht-uÈberlappende Nachforderung. Die Anwendung

garantiert, daû die nachzuladenden Objekte disjunkt

zu den Objekten, die sich momentan im Objektpuffer

befinden, sind. Die Objekte koÈnnen ohne Zusatzmaû-

nahme in der Server-DB bestimmt und in den Objekt-

puffer integriert werden.

• Propagierung des relevanten Objektpufferinhalts. Die

Anwendung stellt eine deskriptive Anfrage als Nachfor-

derung. Der Objektmanager stellt fest, welche geaÈnder-

ten Teile des Objektpuffers von dem AnfragepraÈdikat

oder der Ausgabemenge betroffen sind, und propagiert

diese in die Server-DB. Falls die betroffene Objektmen-

ge nicht eingeschraÈnkt werden kann, sind alle geaÈnder-

ten Objekte zu propagieren. Dabei muÈ ssen die Objekte

erst in die Seiten, Zugriffspfade usw. integriert werden,

bevor sie sich in die Anfrageevaluation einbeziehen las-

sen. Weiterhin impliziert dieseWiederholung der A

È

nde-

rung auf Serverseite das Schreiben der erforderlichen

Log-Information. Die Ergebnisobjekte werden dann

zur Workstation transferiert und redundanzfrei in den

Objektpuffer eingelagert, was uÈber die OIDs kontrol-

liert werden kann.

• Evaluierung der Nachforderung im Objektpuffer. Die

Idee dieser Vorgehensweise ist es, den aktuellen DB-

Zustand, soweit er fuÈ r die Auswertung der Nachforde-

rung gebraucht wird, im Objektpuffer aufzubauen.

Dazu ist es erforderlich, AuswertungsmoÈglichkeiten

fuÈ r die volle AnfragemaÈchtigkeit im Objektpuffer be-

reitzustellen. Dieser Ansatz impliziert, daû in der Re-

gel sehr viele Daten zu uÈbertragen (z.B. Objekttyp-

Scan) und geeignete Zugriffspfade im Objektpuffer an-

zulegen sind. Die Hilfsdaten, die nur der Auswertung

66

der Nachforderung dienen, muÈ ssen dann wieder ent-

fernt werden.

Die zuletzt angesprochene Vorgehensweise wird i. a.

viel zu komplex und teuer sein, weil zunaÈchst die Aus-

wertungsumgebung in die Workstation zu uÈbertragen

ist. So bleibt ± von SonderfaÈ llen abgesehen ± die ¹Pro-

pagierung des relevanten Objektpufferinhaltsª als einzi-

ge gangbare LoÈ sung. Da die A

È

nderungen ohnehin pro-

pagiert werden muÈ ssen, wird lediglich ein Vorziehen

dieser Arbeit erzwungen; nur bei MehrfachaÈnderungen

eines Objekts kann so Mehrarbeit entstehen.

Bei offenen Kontexten ist die Datenversorgung we-

sentlich komplexer geworden. Bei der Verarbeitung da-

gegen ergeben sich keine Unterschiede. Lediglich bei

der IntegritaÈ tspruÈ fung ist eine differenziertere Vorge-

hensweise moÈglich. Ist eine U

È

berpruÈ fung erforderlich,

die Daten/Referenzen auûerhalb des verfuÈ gbaren Kon-

textes benoÈ tigt, so kann entweder eine Nachforderung

veranlaût oder ein PruÈ fauftrag (z.B. fuÈ r die Einhaltung

der referentiellen IntegritaÈ t) an den Server gestellt wer-

den. NatuÈ rlich muû auch hier vor AusfuÈhrung der Ope-

rationen die Konsistenz des aktuellen DB-Zustandes

gewaÈhrleistet sein.

Check-in liefert keine neuen Aspekte. Es ist die Inte-

gration aller A

È

nderungen zu bewerkstelligen, wobei vie-

le A

È

nderungen schon waÈhrend der Verarbeitung bei

Nachforderungen propagiert worden sein koÈnnen.

Delegation von Teilanfragen. Die Diskussion der Nach-

forderungen bei offenen Kontexten, die mit einer de-

skriptiven Anfragesprache spezifiziert werden koÈnnen,

hat im wesentlichen zwei Optionen erbracht: die voll-

staÈndige AusfuÈhrung der Anfrage auf dem Server(-puf-

fer) oder ihre vollstaÈndige AusfuÈhrung im Objektpuf-

fer. Dabei wird der Aufwand, die gesamte Auswertungs-

umgebung im Objektpuffer einrichten zu muÈ ssen, diese

zweite MoÈglichkeit im allgemeinen disqualifizieren.

Wenn aber andererseits Objektpuffer sehr groû werden

(> 100 MBytes), dann kann das Propagieren der A

È

nde-

rungen (deren Anzahl proportional zur PuffergroÈûe an-

genommen wird) auch sehr teuer werden. Deshalb kann

es sinnvoll sein, fuÈ r die Query-Server-Architektur nach

OptimierungsmoÈglichkeiten fuÈ r die Aufgabe, wo und

wie Anfragen ausgewertet werden, zu suchen.

Die Delegation von Teilanfragen an den Server, die

Auswertung der komplementaÈren Teilanfragen im Ob-

jektpuffer sowie das Mischen/VervollstaÈndigen des Ge-

samtergebnisses auf der Workstationseite ist ein sol-

cher Ansatz. Er impliziert, daû sowohl in der Worksta-

tion als auch im Server alle Funktionen der Anfragever-

arbeitung ausgefuÈhrt werden koÈnnen.

Die wichtigste und am schwierigsten zu realisierende

Voraussetzung auf der Workstationseite ist das genaue

Wissen, was alles (welche Objekte und ob vollzaÈhlig)

im Objektpuffer ist, um entscheiden zu koÈnnen, ob sich

eine Teilanfrage konsistent und vollstaÈndig auswerten

laÈût. In KRISYS [12] uÈbernimmt diese Aufgabe der

Kontext-Manager, der mit Hilfe von PraÈdikaten die

gepufferten Objektmengen charakterisiert und Infor-

mationen uÈber ihre Anwesenheit/VollzaÈhligkeit verwal-

tet. Im Verlauf von A

È

nderungen der Objekte koÈnnen

sich erhebliche KomplexitaÈ ten bei der BuchfuÈhrung er-

geben, da Objekte von m Kontextmengen (PraÈdikate)

in n andere Kontextmengen migrieren koÈnnen.

Abbildung 4 zeigt auf der linken Seite ein Beispiel ei-

ner Anfrage in SQL-Notation mit dem zugehoÈ rigen

Operatorbaum. Sie dient dazu, zu einer im Objektpuf-

fer vorhandenen Menge von Zellen (<oid-set>) mittels

eines Joins die zugehoÈ rigen Schnittstellen nachzufor-

dern. Bei der U

È

bersetzung/Optimierung einer Anfrage

erkennt der Kontext-Manager, welche Teilanfragen

sich im Objektpuffer beantworten lassen. Die restli-

chen Teilanfragen werden zur Abwicklung an den Ser-

ver geschickt. Der optimierte Operatorbaum beinhaltet

als BlaÈtter zwei Teilanfragen, von denen die rechte an

den Server zu delegieren ist und die linke direkt auf

dem Objektpuffer ausgefuÈhrt wird. Die Qualifikation

der Schnittstellen geschieht mittels der Menge <ref-set>, die der Kontext-Manager aus den im Objektpuf-

fer vorhandenen Zellen ermittelt. Bei dieser Auswer-

tung muû ggf. durch Propagation von A

È

nderungen ga-

rantiert werden, daû jede Teilanfrage als konsistente

Sicht auf demselben DB-Zustand evaluiert wird. Die

server-seitigen Ergebnisobjekte werden an den Objekt-

puffer geliefert, wo die Frageauswertung dann komplet-

tiert wird. Dieses Verarbeitungskonzept wurde in ganz

aÈhnlicher Weise im Projekt ADMS [31] aufgegriffen.

Dort werden Anfrageergebnisse in einem Anfrage-

Cache, der auf der Workstation liegt, zwischengespei-

chert und, soweit moÈglich, zur Beantwortung von nach-

folgenden Anfragen verwendet [7]. Allerdings liegen

dazu bisher nur vereinfachende Simulationsstudien vor.

Mit dem Ansatz der Delegation von Teilanfragen

werden der Anwendung deskriptive Anfragen hoher

AuswahlmaÈchtigkeit ermoÈglicht, die, falls der Kontext

ausreicht, ausschlieûlich im Objektpuffer bewaÈ ltigt wer-

den. Bei Referenzen auf den Server strebt die Auswer-

tung eine Aufteilung der Teilanfragen an, so daû die

Verarbeitungskosten minimal werden. Das Ergebnis er-

gaÈnzt dann den offenen Kontext im Objektpuffer.

4. Bewertung der ArchitekturansaÈtze

Nachdem die verschiedenen Workstation/Server-Archi-

tekturen diskutiert worden sind, sollen diese nun an-

hand der sie charakterisierenden Kriterien bewertet

werden. Darauf aufbauend und ausgehend von den spe-

zifischen Eigenschaften eines Anwendungsbereiches

67

Abb.4. Beispiel fuÈ r die Delegation von Teilanfragen

wird eine Entscheidungshilfe zur Auswahl einer geeig-

neten Zielarchitektur skizziert.

4.1 Bewertungskriterien fuÈ r die Workstation-Server-

Kooperation

Im folgenden werden allgemeine ¹Faustregelnª aufge-

stellt, die LeistungsfaÈhigkeit und FlexibilitaÈ t einer

Workstation/Server-Verarbeitung in hohem Maûe be-

stimmen. FuÈ r unsere Fragestellung werden diese als Be-

wertungskriterien fuÈ r die verschiedenen AnsaÈtze be-

nutzt.

(1)Minimierung der Kommunikation zwischen Server

und Workstation. Die Anzahl der DatenuÈbertragungen

und die GroÈûe des Kommunikationsvolumens haben of-

fensichtlich wesentlichen Einfluû auf die Systemeffizi-

enz. Beim Page-Server haÈngt der Kommunikationsauf-

wand stark vom Grad der Clusterbildung ab. Der Ob-

jekt-Server genuÈgt dieser Regel aufgrund der Einzelan-

forderung und -uÈbertragung von Objekten weniger,

waÈhrend der Query-Server diese Forderung am ehe-

sten erfuÈ llt, da mengenorientierte Anforderungen mit

der Bereitstellung der Ergebnismenge beantwortet wer-

den. DaruÈber hinaus foÈ rdert das Konzept der Delegati-

on von TeilauftraÈgen eine weitere Reduktion der Kom-

munikation. Allerdings wird an der Query-Server-Ar-

chitektur deutlich, daû die Verringerung des Kommuni-

kationsvolumens durch eine hoÈhere SystemkomplexitaÈ t

erkauft wird.

(2)Minimierung der Anzahl der KopiervorgaÈnge. Die

EinfuÈhrung eines eigenen WS-Speicherungsmodells im-

pliziert Extra-KopiervorgaÈnge durch die Extraktion der

Objekte und das Wiedereinbringen der A

È

nderungen.

Deshalb genuÈ gt die U

È

bernahme des Server-Speiche-

rungsmodells dieser Regel am besten; der Page-Server

bietet also in dieser Hinsicht die optimale LoÈ sung.

(3) UnterstuÈ tzung groÈûtmoÈglicher Transaktionsparalleli-

taÈt. Gegenseitige Behinderung oder gar Blockierung

von Transaktionen (WerkzeuglaÈufen) werden dann mi-

nimal, wenn die Objekte als Einheiten der Verarbei-

tung auch als Einheiten des Sperrens verwendet und

mit angemessenen Sperrmodi belegt werden koÈnnen.

Wenn der Page-Server als Sperrgranulat Seiten verwen-

det, kann er dieser Regel nur nachkommen, falls alle ge-

lieferten Seiten ausschlieûlich fuÈ r die jeweilige Anwen-

dung relevante Daten enthalten. Ist dies nicht der Fall,

so werden implizit mit der Seitensperre auch andere

Objekte isoliert, was dann zur Blockierung parallel lau-

fender Anwendungen fuÈhren kann. Object- und Query-

Server besitzen hier groÈûere Freiheitsgrade zur Opti-

mierung, wobei bei letzterem durch die Verwendung

komplexer Objekte oder eines geeigneten Versionskon-

zeptes der Synchronisationsaufwand drastisch reduziert

werden kann.

(4) Reduktion der E/A durch platzsparendes Logging.

Logisches Logging oder Eintragslogging laÈût sich bei al-

len Architekturen anwenden, bei denen der Server Ob-

jekte kennt. Nur der Page-Server in seiner Grundform

verstoÈût gegen diese Regel.

(5) Effizienter Objektzugriff waÈhrend der Verarbeitung.

Eine Zugriffsoptimierung kann nicht nur uÈber Pointer-

Swizzling, sondern auch uÈber zusaÈtzliche Zugriffspfade

erfolgen, wenn spezielle Zugriffsfolgen haÈufig auftre-

ten. Dies ist in allen AnsaÈtzen moÈglich, aber von der

Anwendung abhaÈngig: Pointer-Swizzling lohnt sich im-

mer dann, wenn Objekte mehrmals referenziert wer-

den, und Zugriffspfade koÈnnen nur gewinnbringend

eingesetzt werden, wenn das Zugriffsverhalten der An-

wendung bekannt ist.

(6)Maximierung der Fehlerisolation. Mit der Minimie-

rung der Anzahl der Datenanforderungen an den Ser-

ver wird eine hoÈhere Fehlerisolation dadurch erreicht,

daû nunmehr laÈngere Verarbeitungsphasen in der

Workstation bei Ausfall des Servers ohne VerzoÈ gerung

abgearbeitet werden koÈnnen. Im Falle nicht persi-

stenter Sperren wird jedoch die Fehlerisolation einge-

schraÈnkt, da ein Ausfall des Servers dann das RuÈ ckset-

zen aller laufenden Transaktionen impliziert.

Die Diskussion verdeutlicht bereits, daû keine global

optimale Architektur existiert. Dies wird noch deutli-

cher angesichts der Existenz gegenlaÈufiger AbhaÈngig-

keiten zwischen den Regeln sowie der Notwendigkeit

der Einbeziehung von Anwendungskriterien in die Be-

urteilung. So ist die FlexibilitaÈ t der Anwendungsanbin-

dung und die AuswahlmaÈchtigkeit bei der Datenanfor-

derung durch die Gesichtspunkte Sprachintegration,

DatenrepraÈsentation und Datenversorgung bestimmt.

Hierbei ist zu beachten, daû multi-linguale Sprachinte-

gration [8], [34] dem Konzept der nahtlosen Schnittstel-

le (seamless interface) widerspricht und zugeschnittene

DatenrepraÈsentation ein unabhaÈngiges WS-Speiche-

rungsmodell fordert. Damit zeigt sich ein Konflikt zu

Regel 2. Weiterhin besteht zwischen Verarbeitungsart

und der geforderten FlexibilitaÈ t bzgl. der Datenversor-

gung folgende AbhaÈngigkeit: Einstufige Verarbeitung

erzwingt die BeschraÈnkung auf genau eine deskriptive,

mengenorientierte Anforderung (Check-out) oder ver-

schiedene Einzelanforderungen (uÈber OID), waÈhrend

Zweistufigkeit beliebige deskriptive, mengenorientier-

te Nachforderungen erlaubt. Der Einfluû anwendungs-

spezifischer Gesichtspunkte wird im folgenden Ab-

schnitt weiter ausgefuÈhrt.

4.2 Kriterien zur Architekturauswahl

In Kapitel 2 wurde zwischen abgeschlossenen und offe-

nen Kontexten unterschieden. Allgemein kann eine Ar-

chitektur, die sich zur Verarbeitung offener Kontexte

eignet (dies gilt fuÈ r die Grundform aller angesproche-

nen AnsaÈtze), auch bei abgeschlossenen Kontexten ein-

gesetzt werden. WaÈhrend bei abgeschlossenem Kontext

einstufige Verarbeitung genuÈgt, ist bei offenen Kontex-

ten und deskriptiven Nachforderungen Zweistufigkeit

erforderlich. Um nun fuÈ r eine gegebene Anwendung

eine Wahl zwischen den Architekturen zu treffen, ist es

jedoch sinnvoll, eine moÈgliche Ausnutzung von Kon-

textwissen zu beruÈ cksichtigen. Diese kann auf zwei Ar-

ten geschehen. Explizite Nutzung bedeutet, daû der

68

Kontext in einer oder mehreren Anfragen an- bzw.

nachgefordert wird. Werden die Objekte dagegen uÈber

Objekt/Seiten-Fehlbedingungen angefordert, konnte

aber bereits vorher eine Clusterbildung als Kontext er-

zielt werden (insbesondere fuÈ r Page-Server wichtig), so

liegt eine implizite Nutzung vor. Die explizite Nutzung

durch den Query-Server ist flexibler, da der Kontext

zum Zeipunkt der Anforderung beschrieben werden

kann und nicht im voraus durch eher starre Anordnung

der Objekte in entsprechenden Speicherungsstrukturen

manifestiert sein muû. Weitere Vorteile der expliziten

Nutzung sind weniger Kommunikation, MoÈglichkeit

der Query-Optimierung und weniger Wartungsauf-

wand (Reorganisation) fuÈ r Pufferstrukturen.

Der in Abb.5 dargestellte Baum gibt eine Hilfestel-

lung fuÈ r die Auswahl eines Architekturansatzes ausge-

hend von folgenden anwendungsspezifischen Fragestel-

lungen:

± Liegt Kontextwissen vor? (Kontextkriterium)

± Ist die Clusterbildung von Verarbeitungskontexten

moÈglich? (Clusterbildungskriterium)

± Ist FlexibilitaÈ t bzgl. der DatenrepraÈsentation erfor-

derlich? (FlexibilitaÈ tskriterium)

± Sind deskriptive AnfragemoÈglichkeiten gefordert

oder soll implizit beim Navigieren angefordert wer-

den? (Datenanforderungskriterium)

Ist kein Kontextwissen vorhanden (rechter Teilbaum),

so kann auch davon ausgegangen werden, daû keine

sinnvolle Clusterbildung von Verarbeitungskontexten

existiert. Unter BeruÈ cksichtigung des FlexibilitaÈtskrite-

riums koÈnnen hier Page- und Object-Server empfohlen

werden, wobei EffizienzgruÈnde insbesondere fuÈ r den

Page-Server sprechen (weniger Kommunikation, gerin-

gere Anzahl von KopiervorgaÈngen). Sind flexible Da-

tenrepraÈsentation und/oder mehrsprachige Anwen-

dungsanbindung erforderlich, so koÈnnen die Page-Ser-

ver-Erweiterung oder der Object-Server herangezogen

werden. Die Erweiterung des Object-Servers um einge-

schraÈnkte, mengenorientierte Verarbeitung (SSA) laÈût

sich in beschraÈnktem Maûe effizienzsteigernd einset-

zen, bedient aber die gleiche Anwendungsklasse wie

die Grundform. Der Query-Server erscheint in einem

solchen Szenario (kein Kontextwissen) ungeeignet, da

eine seiner wesentlichen FaÈhigkeiten, die deskriptive

Anforderung ganzer Kontexte/Kontextteile via Server-

Anfrage, nicht sinnvoll ausgenutzt werden kann.

Ist andererseits Kontextnutzung ± eine Unterschei-

dung zwischen abgeschlossenem und offenem Kontext

ist hier unerheblich ± moÈglich (linker Teilbaum), stellt

sich zunaÈchst die Frage, ob Clusterbildung auf die Kon-

texte anwendbar ist. Ist dies nicht der Fall, so ist der

Query-Server zu empfehlen, da die Auswertung einer

deskriptiven Anfrage serverseitig optimiert werden

kann. Hierbei ist zu beachten, daû bei abgeschlossenem

Kontext nicht die volle SystemkomplexitaÈ t zum Tragen

kommt, da zwischenzeitig kein aktueller DB-Zustand

auf dem Server zu erzeugen ist und keine nachgeforder-

ten Daten in den Objektpuffer integriert werden muÈ s-

sen. Ist Clusterbildung moÈglich, sollte weiter beachtet

werden, inwieweit eine flexible DatenrepraÈsentation

notwendig ist. Besteht hierzu keine Notwendigkeit,

dann ist dem Page-Server aus Effizienzgesichtspunkten

der Vorzug zu geben. Andernfalls (flexible RepraÈsenta-

tion) sollten die Page-Server-Erweiterung oder der

Query-Server abhaÈngig von der gewuÈnschten Art der

Datenanforderung eingesetzt werden. In dieser Situati-

on scheint der Object-Server seinen Konkurrenten zu

unterliegen: deskriptive Anforderung votiert eindeutig

fuÈ r den Query-Server, und aufgrund der Clusterbildung

ist das Anforderungsgranulat Seite beim Page-Server

effektiver als die objektweise Anforderung beim Ob-

ject-Server. Insgesamt ist bei Ausnutzbarkeit von Kon-

textwissen insbesondere der Query-Server zu empfeh-

len. Sollen deskriptive Anfragen gestellt werden koÈn-

nen, so kommt nur er in Frage. Ein Ansatz mit geringe-

rer SystemkomplexitaÈ t (Page-Server-Varianten) ist nur

dann sinnvoll, wenn eine geeignete Clusterbildung die-

ser Kontexte garantiert werden kann.

Diese anwendungsbezogene Architekturauswahl

greift im wesentlichen auf die Grundformen (Ab-

schn.3.2) zuruÈ ck, gilt aber auch fuÈ r die daraus abgeleite-

ten Optimierungen, die in Abschn.3.3 vorgestellt wur-

den. Um zwischen den verschiedenen Optimierungen

auswaÈhlen zu koÈnnen, sind detailliertere Anwendungs-

kenntnisse hinsichtlich Mehrbenutzerbetrieb, Kontext

und Clusterbildung sowie quantitative Analysen erfor-

derlich.

4.3 Konsequenzen fuÈ r Entwurfsanwendungen

In der in Kapitel 2 angesprochenen VLSI-Entwurfsan-

wendung liegen abgeschlossene Kontexte vor, da die

Eingangsdaten fuÈ r einen Werkzeuglauf ausschlieûlich

durch in vorangegangenen Verarbeitungsschritten er-

zeugte Versionen bestimmt sind. Durch die Versionie-

rung der komplexen Entwurfsobjekte aufgrund der

schrittweisen Verarbeitung wird eine Konfigurierung

der Eingabedaten notwendig. Da diese von der Erzeu-

gung der einzelnen Objektversionen zeitlich getrennt

ist, kann im allgemeinen keine Clusterbildung erzielt

werden. Deshalb ist das Kontextwissen nur uÈber de-

skriptive Anfragen nutzbar. Weiter erfordern die ver-

schiedenen Werkzeug-Anwendungen aufgrund unter-

schiedlichen Zugriffsverhaltens eine moÈglichst flexible

69

Abb.5. Architekturauswahl nach Anforderungen der Anwendung

Anpassung der DatenrepraÈsentation. Letzteres ist moÈg-

lich, weil das Zugriffsverhalten eines Werkzeugs vorab

bekannt ist. A

È

hnliche Kontexteigenschaften liegen un-

serer Meinung nach in vielen Entwurfsanwendungen

(z.B. Software-Entwurf, CAD im Maschinenbau) vor.

Bei solchen Anwendungen kann nach unserem Aus-

wahlbaum der Query-Server in seiner einstufigen und

deshalb einfacheren Version herangezogen werden.

Der abgeschlossene Kontext laÈût sich zu Beginn der

Verarbeitung mit einer entsprechend maÈchtigen Anfra-

gesprache (Mengenorientierung, Projektion) spezifizie-

ren und laden (Check-out). Dadurch liegt beim Aufbau

der Speicherungsstrukturen in der Workstation bereits

der gesamte Kontext vor, so daû kein Nachfordern not-

wendig wird und die Reorganisation der Pufferstruktu-

ren auf ein Minimum beschraÈnkt wird. Zur Begrenzung

des Synchronisationsaufwandes sind Sperren auf RepraÈ-

sentanten (Komplexobjekt oder Version) zu empfehlen.

Eine Begrenzung des Logging-Aufwands erreicht man

mit Eintrags-Logging bzgl. der Versionsobjekte.

Page- oder Object-Server sind in diesem Anwen-

dungsbereich weniger geeignet, da der Verarbeitungs-

kontext in der Regel sehr groû (GroÈûenordnung MB)

ist und sehr viele Elementarobjekte enthaÈ lt, was zu ei-

ner hohen Zahl von Anforderungen fuÈhren wuÈ rde.

Durch die beschriebene fehlende MoÈglichkeit zur Clu-

sterbildung bedeutet dies nicht nur fuÈ r den Object-, son-

dern auch fuÈ r den Page-Server einen unverhaÈ ltnismaÈûig

hohen Kommunikationsaufwand.

Bei interaktiven CAD-Anwendungen, bei denen der

Entwerfer ad-hoc DB-Anfragen stellt, ergibt sich ein

Zugriffsverhalten, das sich als offener Kontext beschrei-

ben laÈût. In aÈhnlicher Weise koÈnnen wissensbasierte

Anwendungen [12] charakterisiert werden. Dabei ent-

stehen vorzugsweise durch sukzessive Konsultationen

offene Kontexte, deren Bereitstellung insbesondere

durch ¹Delegation von Teilfragenª effektiv erfolgen

kann [35], so daû auch hier der Query-Server empfoh-

len werden kann.

ResuÈmee und Ausblick

In dieser Arbeit wurden verschiedene AnsaÈtze zur Rea-

lisierung von datenbankbasierten Ingenieuranwendun-

gen in Workstation/Server-Umgebungen beschrieben

und bewertet. Dabei bezog sich der Fokus unserer Be-

trachtungen auf die Problematik der Datenversorgung

einer workstation-basierten Anwendung durch einen

Datenbank-Server. Im einzelnen wurden folgende

Schwerpunkte gesetzt:

± Extraktion der benoÈ tigten Daten vom Datenbank-

Server.

± Datensicherung und Synchronisation.

± Datenbereitstellung und -verarbeitung im worksta-

tion-seitigen Objektpuffer.

± Integration der geaÈnderten Daten.

Unsere Untersuchungen der verschiedenen Worksta-

tion/Server-Architekturen haben gezeigt, daû keine glo-

bal optimale Architektur existiert und daû fuÈ r die Be-

wertung eines Ansatzes die spezifischen Charakteristi-

ka der Zielanwendung entscheidend sind. Hier wurden

speziell die Auswirkungen eines Verarbeitungskontex-

tes (offen oder geschlossen), der Einfluû von Clusterbil-

dung sowie die Rolle eines WS-Speicherungsmodells

untersucht und deren Konsequenzen fuÈ r die Datenver-

sorgung in Workstation/Server-Umgebungen analy-

siert. Im Gegensatz zu bisherigen Untersuchungen [11,

9] haben wir das Verarbeitungsmodell detailliert und

dabei wichtige Merkmale herausgearbeitet, die sich in

den betrachteten Architekturtypen und deren Verfeine-

rungen widerspiegeln. Insgesamt kristallisierten sich

folgende generellen Bewertungen heraus:

± Der Page-Server vereinigt eine recht einfache System-

konzeption (einstufige Verarbeitung, direkte U

È

bernah-

me des Server-Speicherungsmodells fuÈ r die Objektver-

arbeitung in der Workstation) mit einem, abhaÈngig vom

Grad der Clusterbildung, guten Leistungsverhalten.

± Der Object-Server scheint seinen Konkurrenten zu

unterliegen: Verarbeitungskontexte votieren fuÈ r den

Query-Server, und bei Clusterbildung ist das Anforde-

rungsgranulat Seite beim Page-Server effektiver als die

objektweise Anforderung beim Object-Server.

± Der Query-Server zeigt eine hohe SystemkomplexitaÈt

aufgrund des sehr flexiblen und maÈchtigen Verarbei-

tungsmodells (zweistufige Verarbeitung (falls notwen-

dig), flexibles WS-Speicherungsmodell, Nutzung defi-

nierter Verarbeitungskontexte).

Diese qualitativen Untersuchungen zur prinzipiellen

Eignung von Workstation/Server-Architekturen fuÈ r ein

gegebenes Anwendungsszenario sollten mit quantitati-

ven Analysen kombiniert werden, um eine endguÈ ltige

Architekturauswahl zu ermoÈglichen. Hierbei kann auf

die existierenden Benchmarks, die in [6] charakterisiert

und klassifiziert sind, nur bedingt verwiesen werden. Es

fehlen naÈmlich sowohl der direkte Vergleich von

Query-Server-Architekturen zu den anderen beiden

ArchitekturansaÈtzen als auch allgemeinguÈ ltige Aussa-

gen uÈber die Auswirkungen eines Mehrbenutzerbe-

triebs (bei gleichartigen und gemischten Anwendun-

gen). Erste vergleichende Untersuchungen zu Page-Ser-

ver- und Objekt-Server-Ansatz unter Mehrbenutzerbe-

trieb finden sich in [5].

Durch eine Pufferung der Verarbeitungskontexte

uÈber Commit-Grenzen hinaus kann der aktuelle Verar-

beitungskontext (inklusive der zugehoÈ rigen Sperren) di-

rekt und ohne extra Ladephase an den nachfolgenden

Verarbeitungsschritt weitergegeben werden. Dies

scheint insbesondere fuÈ r den Bereich der Ingenieuran-

wendungen eine sehr lohnende Sache, da dort oftmals

das Ergebnis einer Werkzeuganwendung den Verarbei-

tungskontext fuÈ r die darauffolgende Werkzeuganwen-

dung darstellt. Erste Leistungsmessungen [4] hinsicht-

lich der dann notwendigen KohaÈrenz-Protokolle sind

auf alle ArchitekturansaÈtze zu erweitern, um verglei-

chende Bewertungen durchfuÈhren zu koÈnnen.

Kommunikation bleibt bei den hier diskutierten Ar-

chitekturen ein wichtiges Thema, auch wenn FDDI

70

(100Mb/s) bzw. kuÈnftig ATM (Asynchronous Transfer

Mode) als Standard-Technologien bei LANs eingesetzt

werden. ATM erlaubt die Integration von Multimedia-

Daten und soll als TraÈgersystem fuÈ r Breitbandnetze in

einigen Jahren noch hoÈhere TransferkapazitaÈ ten bereit-

stellen (ATM 1 mit 155Mb/s und ATM 2 mit 622Mb/

s). Diese lassen sich jedoch zunehmend schwieriger aus-

schoÈpfen, da die beteiligten CPUs die Kommunika-

tionsdatenraten begrenzen. Bei jeweils 20000 Instr./

Transfer verkoÈ rpert bei hohen Raten nicht das U

È

bertra-

gungsmedium den begrenzenden Faktor, sondern die

CPU-Leistung des Servers. Dieser Sachverhalt macht

sich beim Page-Server und besonders beim Object-Ser-

ver wegen der groûen Anzahl der Kommunikationsvor-

gaÈnge nachteilig bemerkbar. Er duÈ rfte die Skalierbar-

keit dieser Architekturen beschraÈnken, da je neben der

Unterbrechungs- und Kommunikationsabwicklung zu-

saÈtzlich immer noch die eigentliche AusfuÈhrung des

DBS-Codes anfallen.

Aktuelle Forschungsarbeiten im Bereich integrierter

rechnergestuÈ tzter (Ingenieur-)Anwendungen (insbe-

sondere im Bereich CAD-Frameworks [32, 14]) erwei-

tern das Einsatzgebiet eines DB-Servers auf eine Welt

heterogener Datenhaltungssysteme (Dateisysteme und

verschiedenartige DBS), welche die bekannten Standar-

disierungs- und Austauschformate unterstuÈ tzen muÈ ssen

und auch eine Erweiterbarkeit hinsichtlich weiterer

Datenhaltungssysteme zeigen. Im Lichte dieser zukuÈnf-

tigen Anforderungen erscheint ein Architekturansatz

auf der Abstraktionsebene und mit der FlexibilitaÈ t des

Query-Servers angebracht. Aus diesem Grund zielen

unsere weiteren Arbeiten auf einen modularen und auf

einen Anwendungsfall konfigurierbaren Query-Server.

Einen ersten Schritt in diese Richtung stellen unsere

praktischen Arbeiten zur Query-Komponente dar: in

[35] untersuchen wir die Optimierung von Objekt-

pufferanfragen sowie die Delegation von Teilanfragen

an den DB-Server. Entwicklungsziel ist die Integration

eines Query-Servers in unser Framework-System [33].

Danksagung. Wir danken unseren Kollegen S.Deûloch, M. Ges-

mann, J.Thomas und E.Rahm fuÈ r die kritische Durchsicht einer

ersten Fassung. Weiterhin bedanken wir uns bei den Gutachtern

fuÈ r die wertvollen Hinweise zur Verbesserung der Darstellung.

Literatur

1. Altmeyer, J., SchuÈ rmann, B., Zimmermann, G.: Three-phase

chip planning. Proc. Int. Conf. on Computer Aided Design,

Santa Clara, CA, 1992

2. Ananthanarayanan, R., Gottemukkala, V., KaÈfer, W., Lehman,

T.J., Pirahesh, H.: Using the coexistence approach to achieve

combined functionality of object-oriented and relational sys-

tems. Proc ACM SIGMOD'93, Washington, DC, May 1993,

pp 109±118

3. Butterworth, P., Otis, A., Stein, J.: The Gemstone object dat-

abase management system. Commun. ACM 34, 64±77 (1991)

4. Carey, M., Franklin, M., Livny, M., Shekita, E.: Data caching

tradeoffs in client-server DBMS architectures. Proc. ACM

SIGMOD'91, Denver, June 1991, pp. 12±21

5. Carey, M., Franklin, M., Zaharioudakis, M.: Fine-grained shar-

ing in a page server OODBMS. Proc. ACM SIGMOD'94, Min-

neapolis, June 1994, pp. 359±370

6. Chaudhri, A., Revell, N.: Benchmarking object databases: past,

present & future. UNI-COM-Seminar on Object-Oriented

Databases: Realising their Potential and Interoperability with

RDBMS, London, May, 1994

7. Chen, C., Roussopoulos, N.: The implementation and perfor-

mance evaluation of the ADMS query optimizer: integrating

query result caching and matching. Advances in Database

Technology ± EDBT'94 (Lect. Notes Comput. Sci., Vol. 777,

pp. 322±336) Berlin, Heidelberg, New York: Springer 1994

8. DeMichiel, L., Chamberlin, D., Lindsay, B., Agrawal, R., Arya,

M.: Polyglot: extensions to relational databases for sharable

types and functions in a multi-language environment. Proc. of

9 th Int. Conf. on Data Engineering, Vienna, April 1993, pp.

651±660

9. Deppisch, U., Obermeit, V.: Tight database cooperation in a

server-workstation environment. Proc. 7 th Int. Conf. on Dist-

rib. Computer Systems, Berlin, 1987

10. Deux,O., et al.: TheO

2

system.Commun.ACM34, 34±49 (1991)

11. DeWitt, D.J., Futtersack, P., Maier, D., Velez, F.: A study of

three alternative workstation-server architectures for object-

oriented database systems. Proc. VLDB'90, Brisbane, Austra-

lia, pp. 107±121

12. Deûloch, S., Leick, F. J., Mattos, N.M., Thomas, J.: The KRISYS

project: a summary of what we have learned so far. Tagungs-

band der GI-Fachtagung ¸Datenbanksysteme fuÈ r BuÈ ro, Tech-

nik und Wissenschaft`, Informatik aktuell, S.124±143. Berlin,

Heidelberg: Springer 1993

13. Gray, J., Reuter, A.: Transaction processing ± concepts and

techniques. San Mateo, CA: Morgan Kaufmann 1993

14. Harrison, D.S., Newton, A.R., Spickelmier, R.L., Barnes, T.J.:

Electronic CAD-Frame works. Proc. of the IEEE 78: 2, 1990,

pp.393±417.

15. HaÈrder, T., HuÈbel, C., Meyer-Wegener, K., Mitschang, B.: Pro-

cessing and transaction concepts for cooperation of engineer-

ing workstations and a database server. Data Knowl. Eng. 3,

87±107 (1988)

16. HaÈrder, T., Meyer-Wegener, K.: Transaktionssysteme in Work-

station/Server-Umgebungen. Informatik Forsch. Entw. 5, 127±

143 (1990)

17. HuÈbel, C., Sutter, B.: DB-Integration von Ingenieuranwendun-

gen ± Modelle, Werkzeuge, Kontrolle. Reihe Datenbanksyste-

me. Wiesbaden: Vieweg 1993

18. Jablonski, S.: Transaction support for activity management.

Proc. Workshop on High Performance Transaction Processing

Systems, Asilomar, CA, 1993

19. Keller, A., Jensen, R., Agrawal, S.: Persistence software: bridg-

ing object-oriented programming and relational database.

Proc. ACM Sigmod'93, Washington, DC, May 1993, pp. 523±

528

20. Kemper, A., Kossmann, D.: Adaptable pointer swizzling strate-

gies in object bases. Proc. 9 th Int. Conf. on Data Engineering,

Vienna, April 1993, pp. 155±162

21. Kim, W.: Introduction to object-oriented databases. Computer

System Series. Cambridge, MA: MIT Press 1991

22. KaÈfer, W., Mitschang, B.: Flexible Entwurfsdatenverwaltung

fuÈ r CAD-Frameworks: Konzept, Realisierung und Bewertung.

Tagungsband der GI-Fachtagung ¸Datenbanksysteme fuÈ r

BuÈ ro, Technik und Wissenschaft`, Informatik aktuell, S.144±

163. Berlin, Heidelberg Springer 1993

23. KuÈ spert, K., Dadam, P., GuÈnauer, J.: Cooperative object buffer

management in the advanced information management proto-

type. Proc. 13 th VLDB Conf., Brighton, 1987, pp.483±492

24. Lamb, C., Landis, G., Orenstein, J., Weinreb, D.: The Object-

Store database system. Commun. ACM 34, 50±63 (1991)

25. Lee, B., Wiederhold, G.: Outer joins and filters for instantiating

objects from relational databases through views. IEEE Knowl.

Data Eng. 6, 108±119 (1994)

26. Mitschang, B., Pirahesh, H., Pistor, P., Lindsay, B., SuÈdkamp, S.:

SQL/XNF ± processing composite objects as abstractions over

relational data. Proc. 9 th Int. Conf. on Data Engineering, Vien-

na, 1993, pp. 272±282

71

27. Moss, B., Eliot, J.: Working with persistent objects: to swizzle or

not to swizzle. IEEE Trans. Software Eng. 18, 657±673 (1992)

28. Objectivity Inc.: Objectivity database system overview. Menlo

Park, CA, 1990

29. Ontologic Inc.: ONTOS developer's guide. Billerica, MA, 1991

30. Rahm, E.: Der Database-Sharing-Ansatz zur Realisierung von

Hochleistungs-Transaktionssystemen. Inf. Spektrum 12, 65±81

(1989)

31. Roussopoulos, N. Delis, A.: Modern client-server DBMS archi-

tectures. ACM SIGMOD RECORD 20, 52±61 (1991)

32. Rammig, F.J., SteinmuÈ ller, B.: Frameworks und Entwurfs-

umgebungen. Inf.-Spektrum 15, 33±43 (1992)

33. Ritter, N., Mitschang, B., HaÈrder, T., Gesmann, M., SchoÈning,

H.: Capturing design dynamics ± the CONCORD approach.

Proc. 10 th Int. Conf. on Data Engineering, Houston, Texas,

1994, pp. 440±451

34. Stonebraker, M.: Architektures of future data base systems.

IEEE Data Eng. 13, (1990)

35. Thomas, J., Mitschang, B., Mattos, N.M., Deûloch, S.: Enhanc-

ing knowledge processing in client/server environments. Proc.

2nd Int. Conf. on Information and Knowledge Management,

Washington, 1993, pp. 324±334

36. Versant Object Technologies Inc: VERSANT technical over-

view. Menlo Park, CA, 1990

37. Zimmermann, G.: PLAYOUT ± a hierarchical layout system.

Tagungsband 18. GI Fachtagung, Hamburg, Informatik-Fach-

berichte 188, S.31±51. Berlin, Heidelberg: Springer 1988

72

Theo HaÈrder (Jg.1945). Studium der Elektrotechnik an der TH Darmstadt (1966±1971), seit 1972 Mitarbeit im

Fachbereich Informatik (Datenverwaltungssysteme) der TH Darmstadt, 1975 Promotion, 1976 Postdoctoral

Fellow in IBMResearch, San Jose (Mitarbeit im Projekt ¹System Rª), 1977 Dozent, 1978 Professor fuÈ r Informa-

tik an der THDarmstadt, seit 1980 Professor fuÈ r Praktische Informatik (Datenverwaltungssysteme) an der Uni-

versitaÈ t Kaiserslautern. Besondere Forschungsinteressen: Leistungsanalyse von Datenbank- und Transaktions-

Systemen, Mehrrechner-Datenbanksysteme, Non-Standard-Anwendungen fuÈ r DBS (CAD/CAM), Datenban-

ken in Netzen, Wissenbankverwaltungssysteme.

Bernhard Mitschang (Jg.1959). Seit 1994 Professor fuÈ r Datenbanksysteme und Wissensbasierte Systeme an der

TU MuÈnchen, davor Studium der Informatik an der UniversitaÈ t Kaiserlautern (1977±1982), von 1983 bis 1994

wissenschaftlicherMitarbeiter im Sonderforschungsbereich 124 am Fachbereich Informatik der UniversitaÈ t Kai-

serslautern, 1988 Promotion, 1994 Habilitation; von Okt. 1989 bis Dez. 1990 Post-doctoral Fellow in IBM Re-

search, San Jose, Kalifornien und von 1988 bis 1994 in der Projektleitung des Teilprojekts D2 im Sonderfor-

schungsbereich 124 am Fachbereich Informatik der UniversitaÈ t Kaiserslautern. Hauptarbeitsgebiete: Ingenieur-

anwendungen fuÈ r Datenbanksysteme (DBS), Anfrageverarbeitung in DBS, Parallelisierung in DBS, Wissens-

bankverwaltungssysteme (WBVS), Modellierung von Anwendungen in DBS und WBVS. Mitgliedschaften in

der Gesellschaft fuÈ r Informatik (GI), Association for Computing Machinery (ACM) und IEEE Computer So-

ciety (IEEE).

Udo Nink (Jg.1966). Studium der Informatik an der UniversitaÈ t Kaiserslautern (1986±1992), seit 1992 wissen-

schaftlicher Mitarbeiter im Sonderforschungsbereich 124 am Fachbereich Informatik der UniversitaÈ t Kaisers-

lautern. Hauptarbeitsgebiete: Verarbeitungsmodelle fuÈ r technische DB-Anwendungen, Anwenderprogramm-

ierschnittstellen, Objektorientierte Datenbanksysteme, Austausch von Produktmodelldaten mit STEP. Mit-

gliedschaft in der Gesellschaft fuÈ r Informatik (GI).

Norbert Ritter (Jg.1962). Studium der Informatik an der UniversitaÈ t Kaiserslautern (1984±1991), seit 1992 wis-

senschaftlicher Mitarbeiter am Fachbereich Informatik der UniversitaÈ t Kaiserslautern. Hauptarbeitsgebiete:

Anwendungsmodellierung, Ablaufmodelle fuÈ r kooperative Entwurfsarbeit, Anbindung von Datenbanksyste-

men an Entwurfsumgebungen, kooperative Transaktionen, Versionsmodellierung. Mitgliedschaft in der Gesell-

schaft fuÈ r Informatik (GI).