Konzept (PDF)

Konzept AquaWeb
aqua plan GmbH
Aachen, Februar 2003
aqua plan
Ingenieurgesellschaft für Problemlösungen in Hydrologie und Umweltschutz mbH
Goethestr. 5, 52064 Aachen - Tel.: 0241/400 70-0, Fax: 0241/400 70-99
Geschäftsführer: Dipl.-Ing. Gerhard Langstädtler, Markus von Brevern
Amtsgericht Aachen HRB 5290
Bankverbindungen: Postbank Dortmund, Kto. Nr. 814608-469, BLZ 44010046
Sparkasse Aachen, Kto. Nr. 15009905, BLZ 39050000
email: post@aquaplan.de · http://www.aquaplan.de

Inhaltsverzeichnis
1 Motivation 2
2 Aufgaben der Clients und des Servers 2
2.1 Begriffsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 AquaWeb-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Datentransfer, Caching, Dateneinheiten 4
3.1 Dateneinheiten editieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Aktualisieren der Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Sicherheit, Abrechnungsmechanismen 5
4.1 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Behinderung des Erspähens . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Transaktionssteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Überwachung der Zugriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Möglichkeiten der Vernetzung 6
5.1 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1 Anforderungen an Hard- und Software . . . . . . . . . . . . . . . . 6
5.1.2 Datendurchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 Erweiterungsmöglichkeiten 7
6.1 Multiserver-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.1 Heimat von Dateneinheiten . . . . . . . . . . . . . . . . . . . . . . 7
6.1.2 Lokaler Zugriff, globaler Zugriff . . . . . . . . . . . . . . . . . . . . 8
6.1.3 Kommunikation zwischen den Servern . . . . . . . . . . . . . . . . . 8
6.1.4 Anforderungen an die Hardware . . . . . . . . . . . . . . . . . . . . 8
7 Fragen und Antworten 10
1

1 Motivation
Vielfach werden beim Einsatz von Informationssystemen Strukturen aufgebaut, die für den
Einzelplatz-Einsatz geeignet sind, im Mehrfach-Nutzer-Betrieb aber zu Behinderungen
führen.
So wird bei existierenden Applikationen oft die gesamte Intelligenz des Datenmanagements
allein auf der Clientseite implementiert und die Server fungieren lediglich als Fileserver.
Um echte Multi-User-Fähigkeit zu gewährleisten, müssen jedoch gewisse Funktionalitäten
in einer zentralen Instanz integriert werden.
Bei reinen Fileservern muss die Synchronisation von Mehrfachzugriffen der Clients von
diesen selbst erfolgen. Die einzige Möglichkeit der Kommunikation untereinander bzw.
den Bedarf einer Änderung von Daten anzumelden besteht allein über das Setzen von
” Marken“ auf dem Fileserver.
Fileserver können die Clients nicht direkt über Datenänderungen informieren. Dies ist
jedoch wünschenswert. Die Möglichkeit einer Kommunikation eröffnet sich durch ein Protokoll,
das Botschaften zwischen Server und Client in beide Richtungen erlaubt. AQTP
ist ein solches Protokoll.
Mit einem Fileserver werden alle Daten, die für die Berechnung notwendig sind, an den
Client übertragen, welcher daraufhin auf diesen Daten arbeitet und die Ergebnisse zurückschickt.
So wird unnötig Bandbreite und Rechenzeit verschwendet.
Erst durch die aktive Kommunikation zwischen Server und Client, wird es möglich, Berechnungen
auf dem Server zu initiieren. Dieser arbeitet dann auf den lokalen Daten und
überträgt lediglich die Ergebnisse oder nur deren graphische Repräsentation.
Die Synchronisation der Daten ist allein Aufgabe des Servers und kann ohne Kommunikation
mit den Clients erfolgen. Der Server koordiniert als zentrale Instanz alle Zugriffe
im Hinblick auf Integrität, Sicherheit und Konsistenz.
Diese Lösung wird im folgenden vorgestellt.
2 Aufgaben der Clients und des Servers
2.1 Begriffsbestimmung
Ein Server ist dadurch definiert, dass er einen gewissen Dienst (Service) bereitstellt. Ein
Rechner kann dabei mehrere Server in sich vereinigen. Diesen Dienst in Anspruch nehmen
die Clients. Grundsätzlich handelt es sich um Programme und nicht um Maschinen.
2

Server und Client können also durchaus auf einem Rechner laufen (z.B. X-Client und
X-Server).
Dienste, die zur Verfügung gestellt werden können, sind unter anderem Filesystemzugriffe,
Datenbankzugriffe, Druckerbereitstellung, email-relays oder http-Zugriffe.
Server des AquaWebstellen mittels des AQTP-Protokolls Zeitreihen, Stammdaten, Geo-
Daten und Funktionen für deren Bearbeitung zur Verfügung. Alle Rechner, auf denen ein
AquaWeb-Client läuft, und die mit dem Rechner, auf dem ein Server läuft, verbunden
sind, können diesen Dienst nutzen.
Der Server-Rechner muss ein Multi-Threading-fähiges Betriebssystem haben und in das
Netz (Intra- oder Inter-) über TCP/IP eingebunden sein. Er muss ausreichend Rechenleistung,
RAM und Festplattenplatz besitzen, um alle Clients gleichzeitig bedienen zu
können. Hierfür kommt vorzugsweise ein schneller Unix-Rechner in Frage (z.B. Solarisoder
HP-UX-Systeme).
Die Clients werden von aqua plan derzeit für Microsoft-Windows und Windows-NT zur
Verfügung gestellt.
Ein Zeitreihensystem lässt sich nur schwer im Kontext einer relationalen Datenbank abbilden.
Deshalb wäre ein Datenbankserver nicht hinreichend für das befriedigende Arbeiten
mit dem System. Das AQTP-Protokoll stellt vielmehr eine völlig neue, auf das Problem
perfekt zugeschnittene Lösung dar.
2.2 AquaWeb-Ansatz
Die Clients des AquaWebbrauchen nur mit geringer Funktionalität ausgerüstet zu sein,
die gesamte Intelligenz ist im Server integriert.
Alle Berechnungen laufen auf dem Server ab, wobei die Daten nur lokal angesprochen
werden. Im Regelfall werden weder Zeitreihen noch Relationen oder Geo-Daten zwischen
Server und Client ausgetauscht.
Der Client übernimmt lediglich die Darstellung der vom Server übermittelten Daten.
Beispielsweise bereitet der Server Zeitreihen-Graphiken auf und überträgt nur die Vektordaten
an den Client. Falls die Übertragung der Zeitreihendaten jedoch schneller ist, oder
diese explizit angefordert werden (z.B. im Wertepaareditor), werden diese an den Client
geschickt.
Ohne den Einsatz einer Client-Server-Architektur ist die Netzverbindung zwischen Client
und Server immer der Flaschenhals der Anwendung.
Mit dem Einsatz des AQTP-Protokolls dagegen wird die Minimierung der zu übertragenden
Daten und damit eine erhebliche Entlastung erreicht.
3

Die verwendete Technik sei hier kurz skizziert:
– Ein Button wird gedrückt
– Die Inhalte aller geänderten Felder der aktuellen Maske werden ausgelesen und über
AQTP an den Server übertragen. Dieser bringt damit seine lokale Repräsentation
der Maske auf den neusten Stand.
– Die mit dem Button verknüpfte Azur-Funktion wird über AQTP an den Server
gesendet.
– Ohne weitere Kommunikation mit den Client führt der Server nun die Azur-Funktion
aus.
– Am Ende werden alle durch die Berechnung veränderten Felder über AQTP auf
dem Client auf den neusten Stand gebracht.
– Sollten neue Graphiken entstehen, so werden diese jetzt an den Client übermittelt.
– Alle Daten, die mit AQTP verschickt werden, sind vorher komprimiert worden.
3 Datentransfer, Caching, Dateneinheiten
Um den Netzzugriff auf ein Minimum zu beschränken, werden auf allen Clients und Servern
Daten zwischengespeichert (gecached). Zur Arbeitsweise eines Multiserver-AquaWebsiehe
Abschnitt 6.1.
Gecached werden Dateneinheiten, die jeweils mit read-only- und uptodate-Flags versehen
sind. Dateneinheiten (DE) sind Zeitreihenausschnitt, Stammdatentupel, Coderelation,
GeoLayer und Vektorgraphiken.
3.1 Dateneinheiten editieren
Möchte ein Client eine DE editieren, so muss er das beim Server anmelden. Der Server
prüft, ob die DE zur Zeit read-only ist und meldet es dem Client. Daraufhin wird die DE
auf read-write gesetzt (gelocked), sodass kein anderer Client sie editieren kann. Befindet
sich die DE nicht im Cache des Clients, überträgt der Server sie an diesen. Hat der Client
die DE editiert, schreibt er sie zurück auf den Server. Dieser setzt wieder das read-only-
Flag der DE.
4

3.2 Aktualisieren der Clients
Der Server verwaltet für jeden Client eine Liste mit DE, die übertragen wurden und
sich also im Cache des jeweiligen Clients befinden können. Ändert ein Client eine DE,
so wird an alle Clients, deren Liste auf dem Server diese DE enthält, eine Botschaft
verschickt. Ist zur Zeit keine Session für einen Client angemeldet, so wird die Botschaft in
eine Warteschlange (message queue) gestellt. Bei Eröffnung der nächsten Session für den
Client wird diese Warteschlange abgearbeitet.
DE im Cache eines Clients, die vom Server die Botschaft erhalten haben, dass diese
DE sich geändert hat, laden die DE nicht sofort nach, sondern löschen lediglich deren
uptodate-Flag. Beim nächsten Zugriff auf die DE wird diese dann nachgeladen.
4 Sicherheit, Abrechnungsmechanismen
4.1 Authentifizierung
Ein Client kann nur mit einem Server Verbindung aufnehmen. Der Client ist dazu auf
dem Server registriert. Clients untereinander können nicht kommunizieren. Server untereinander
übetragen keine Benutzerdaten.
Clients besitzen Seriennummern, Benutzer haben Benutzerkennungen und Passwörter.
Die Clients sind nicht dafür zuständig, die Benutzer zu identifizieren. Daher ist es für
jeden Benutzer möglich, jeden Client zu benutzen. Jeder Client kann jedoch nur maximal
einen Benutzer bedienen.
Zu Beginn einer Sitzung muss sich der Benutzer mit Kennung und Passwort identifizieren.
Bei erfolgreicher Authentifizierung wird eine Server-Session eröffnet, die beim Verlassen
der Sitzung wieder geschlossen wird. Jede Session hat einen konfigurierbaren Time-Out.
Passwörter werden verschlüsselt übertragen.
4.2 Behinderung des Erspähens
Bei der Kommunikation über ein ISDN-Intranet oder über eine geschlossene Benutzergruppe
im Frame Relay (VPN), sind Versuche, die Daten zu erspähen von vornherein so
gut wie ausgeschlossen.
Erfolgt die Verbindung über das Internet, profitieren die AquaWeb-Nutzer von der standardmäßigen
Kompression aller Pakete mit einem nicht frei zugänglichen Algorithmus.
5

4.3 Transaktionssteuerung
Wie aus Abschnitt 2.2 hervorgeht, werden Transaktionen immer vollständig auf dem Server
ausgeführt, ohne Kommunikation mit dem Client.
Transaktionssteuerung ist demnach nicht Aufgabe des AQTP-Protokolls, sondern der
Server-Software. Da die Bearbeitung nur auf lokalen Daten stattfindet, sind keine Probleme
zu erwarten.
4.4 Überwachung der Zugriffe
Die Sessions werden geloggt. Die Anzahl der Pakete, die verbrauchte Server-Zeit und die
Gesamtzeit werden abgelegt. Mittels Skripts können aus den Log-Dateien wichtige Daten
extrahiert werden.
So ist es möglich, den Server hinsichtlich Netzanbindung, Plattenplatz, Rechenleistung
und RAM-Ausbau den Bedürfnissen anzupassen.
Die wichtigsten Skripts stellt die Firma aqua plan zur Verfügung. Ein mit dem UNIX-
System vertrauter Programmierer kann diese jederzeit erweitern.
5 Möglichkeiten der Vernetzung
Die Arbeitsplätze müssen mit dem zuständigen AquaWeb-Server verbunden sein. Das
AQTP-Protokoll benutzt diese Verbindung zum Datenaustausch. Wenn der Server über
das Internet erreichbar ist, genügt es, die Arbeitsplätze ebenfalls an das Internet anzubinden.
Dies ist jedoch nicht die schnellste Alternative, sie erlaubt aber dennoch ein
kontinuierliches Arbeiten.
Server und Arbeitsplätze können auch über ISDN-Router mit 64 oder 128 kBit/s direkt
vernetzt werden. Dies erlaubt viel bessere Übetragungsraten und Antwortzeiten. Die Firma
aqua plan setzt diese Technik seit über vier Jahren ein, um die Filiale in Wien mit der
Zentrale in Aachen zu verbinden, bzw. diese mit diversen Kunden in ganz Deutschland.
5.1 Internet
5.1.1 Anforderungen an Hard- und Software
Jeder PC mit Windows-NT/2000, ist in der Lage, den AquaWeb-Client ablaufen zu
lassen.
6

Notwendig für eine Einzelplatz-Verbindung ist ein PC und eine ISDN-Karte (oder ein
Modem). Soll ein ganzes LAN in das Internet eingebunden werden, so muss ein Router
für den Zugang benutzt werden.
Da die Telefonkosten zum Provider in jedem Fall entstehen, sollte u.U. eine Standleitung
in Erwägung gezogen werden.
Jeder Arbeitsplatz, der an AquaWebteilnehmen will, muss eine eigene IP-Adresse haben,
ein email-Anschluss reicht nicht aus.
5.1.2 Datendurchsatz
Der Datendurchsatz ist nicht durch die Verbindung zwischen Arbeitsplatz und Provider
bestimmt, sondern durch die Netzlast des Internets. In der Praxis hat sicg gezeigt, dass
eine Bandbreite von ca. 5 kB/s für ein relativ flüssiges Arbeiten ausreichend ist. In einem
LAN ist keine Verzögerung zu bemerken, die Anwendung läuft mindestens so schnell wie
lokal.
6 Erweiterungsmöglichkeiten
6.1 Multiserver-Version
In einem Multiserver-AquaWebwerden Dateneinheiten nicht nur zwischen Server und
Client, sondern auch zwischen Servern ausgetauscht. Um die Datenkonsistenz zu gewährleisten,
muss die Struktur der Dateneinheiten erweitert werden.
6.1.1 Heimat von Dateneinheiten
Jede DE ist auf genau einem Server ” beheimatet“. Alle anderen Server können die DE
zwar speichern, sie sind jedoch nicht für deren Verwaltung zuständig. Der Heimatserver
einer DE ist so zu wählen, dass alle Clients der für diese DE zuständigen Dienststelle
möglichst in der Nähe sind (z.B. im gleichen LAN).
Anfragen nach Änderung der DE können nur vom Heimatserver stattgegeben werden.
Dieser schickt bei Änderung einer DE allen Servern eine entsprechende Botschaft (siehe
auch Abschnitt 3.2).
7

6.1.2 Lokaler Zugriff, globaler Zugriff
Jedem Client ist genau ein Server zugeordnet. Ein Zugriff auf andere Server ist nicht
möglich. Möchte der Client auf DE zugreifen, die weder auf seinem Server beheimatet
noch in dessem Cache vorhanden sind, muss dieser eine Anfrage an andere Server stellen.
Diese Anfragen und der damit verbundene Datentransfer ist mit Kosten und Wartezeit
verbunden.
Als Voreinstellung ist es daher sinnvoll, Benutzern den Zugriff auf entfernte DE zu verwehren.
Dieses Recht kann im Benutzerprofil individuell eingestellt werden. Standardmäßig
greifen alle Masken nur auf lokale DE zu. Werden von einem Client nur DE seines Heimatservers
angefordert, so werden unnötige Kosten und Wartezeiten vermieden.
Die logische Vernetzung der Server untereinander muss keinen vollständig verbundenen
Graphen darstellen. Jeder Server ist nur über die Existenz der direkten Nachbar-Server
informiert (siehe Abb. ??, Server 1 ist nicht mit Server 3 verbunden). Eine Anfrage kann
daher über mehrere Zwischenstufen erfolgen.
6.1.3 Kommunikation zwischen den Servern
Wenn ein Client eine DE anfordert, die nicht auf dessen Server (S1) vorhanden ist, stellt
dieser fest, welcher andere Server (S2) die Anfrage befriedigen kann. Daraufhin überträgt
er die DE in seinen Cache und merkt sich deren Ursprung. Dann überträgt er die DE
an den Client. Bei der nächsten Anfrage des Client kann S1 die DE aus seinem Cache
übertragen, ohne auf S2 zuzugreifen. Erst wenn er eine update-Botschaft von S2 bekommt,
muss er die DE neu laden.
Solange eine DE aktuell ist, kann ein Server Anfragen nach ihr aus seinem Cache befriedigen,
auch wenn er nicht deren Heimatserver ist. Das Server-Server-Botschaftensystem
stellt sicher, dass Änderungen an DE sofort mitgeteilt werden. So ist die Kommunikation
zwischen den Servern auf ein absolutes Minimum reduziert.
6.1.4 Anforderungen an die Hardware
Da ein Server eines Multiserver-Verbundes viel weniger Clients und Dateneinheiten verwalten
muss als ein Einzelserver, sind die Anforderungen an die Hardware wesentlich
geringer.
Jeder Server muss Multi-Threading-fähig sein. Ein Windows-Betriebssystem scheidet daher
aus. Unix ist hier das Betriebssystem der Wahl. Die Erfahrungen der letzten Jahre
haben gezeigt, dass ein PC mit Linux einer Unix-Workstation, von der Performance abgesehen,
ebenbürtig ist. Falls der Linux-Rechner über mindestens 256 MB RAM und eine
aktuelle CPU verügt, ist er geeignet einen AquaWeb-Server aufzunehmen.
8

Alle Server sollten jederzeit von den benachbarten Servern aus erreichbar sein. Sind sie es
nicht, so wird das Server-Server-Botschaftensystem blockiert, mit der Folge, dass ganze
Teilsysteme des AquaWebnicht erreichbar sind oder die Aktualität von Daten nicht mehr
gewährleistet ist.
9

7 Fragen und Antworten
Liegen die Programme lokal auf jedem Arbeitsplatz oder werden sie jeweils über das Internet
übertragen?
Auf dem Arbeitsplatz liegt lediglich der AquaWeb-Client. Dieser übernimmt die Eingabe
der Daten und die Darstellung von Ergebnissen auf dem Bildschirm und dem Drucker.
Die Daten liegen auf dem Server auf dem auch alle Auswertungen/Berechnungen laufen.
Wie werden Zugriffsberechtigungen ermöglicht und geprüft?
Jeder Benutzer muss sich zu Beginn einer Sitzung mit seiner Kennung und seinem Passwort
identifizieren. Die dazu nötigen Daten werden auf dem Server vorgehalten. Jedes übermittelte
Paket kann eindeutig einem Benutzer und einem Server zugeordnet werden.
Ist das Arbeiten auch ohne Internet möglich?
Auf das Internet kann verzichet werden. Das Vorhandensein eines Servers ist jedoch Voraussetzung.
Dieser kann auch lokal betrieben werden.
Wie funktioniert der Import/Export von Daten?
Der Import und der Export von Daten ist direkt am Client möglich. Exportdaten werden
vom Server zum Client übermittelt, Importdaten über den Client eingelesen. Die
Daten werden an den Server weitergeleitet und stehen von dort den anderen Clients zur
Verfügung.
Ist die Multi-User-Fähigkeit gewährleistet?
Da der Server alle Zugriffe zentral verwaltet und koordiniert, ist erst mit der AquaWeb-
Lösung eine echte Multi-User-Fähigkeit gegeben.
10

Benötigt jeder Arbeitsplatz eine eigene IP-Adresse?
Ja. Zum Datenaustausch über ein Datennetz muss jeder Platz eine eindeutige Kennung
haben. Da AquaWebTCP/IP-Netze voraussetzt, muss jeder Platz also eine eigene IP-
Adresse haben. Erfolgt die Anbindung an den Server nicht über das Internet, so ist jedoch
keine offizielle IP-Adresse notwendig.
Wieviel Plattenplatz muss auf einem Arbeitsplatz vorgesehen werden?
Die AquaWeb-Software benötigt etwa 8 MByte Plattenplatz auf dem Rechner des Clients.
Darüberhinaus benötigt der Cache Platz. Dieser ist an jedem Arbeitsplatz frei konfigurierbar.
Der Cache sollte, wenn möglich, auf einer lokalen Festplatte eingerichtet werden.
Kann nur über den Server gedruckt werden?
Nein. Die Ausgabe am Client erfolgt wie bei den übrigen Anwendungen über die von dort
aus erreichbaren Drucker.
11