-
Die Erfindung betrifft ein Verfahren
zum Verarbeiten von Daten eines Online-Systems mittels eines Offline-Systems,
wobei
- – das
Online-System einen Server aufweist, auf dem eine Server-Datenbank
installiert ist,
- – das
Offline-System einen Client-Rechner aufweist, auf dem eine lokale
Datenbank installiert ist und
- – die
lokale Datenbank einen ersten Datensatz enthält,
mit den Schritten - – Auswählen von
mindestens einem zweiten Datensatz des Online-Systems, der auf der
Server-Datenbank gespeichert ist,
- – Lesen
des mindestens einen zweiten Datensatzes des Online-Systems und
Schreiben des mindestens einen zweiten Datensatzes in die lokale Datenbank.
-
Die Erfindung betrifft weiterhin
eine Systemkonfiguration zum Verarbeiten von Daten seines Online-Systems
mittels eines Offline-Systems, wobei
- – das Online-System
einen Server aufweist, auf dem eine Server-Datenbank installiert
ist,
- – Mitteln
zum Auswählen
von mindestens einem zweiten Datensatz des Online-Systems, der auf der
Server-Datenbank gespeichert ist,
- – Mitteln
zum Lesen des mindestens einen zweiten Datensatzes des Online-Systems und
- – Mitteln
zum Schreiben des mindestens einen zweiten Datensatzes in die lokale
Datenbank.
-
Derartige Verfahren und Systemkonfigurationen
können
im Rahmen beliebiger Netzwerke zum Einsatz kommen. Beispielsweise
haben sich firmeneigene Intranets mittlerweile zu einem Medium entwickelt,
das eine komplexe Verteilung von Softwarekomponenten ermöglicht.
Dynamische Intranetseiten, die in sogenannten Browsern dargestellt
werden, bilden dabei die Benutzerschnittstellen dieser Systeme.
Die Intranetseiten können
von beliebigen Rechnern aufgerufen werden, die einen Intranetzugang haben.
Die Benutzeraktionen und die von den Benutzern zur Verfügung gestellten
Eingabedaten können unter
Vermittlung der Schnittstellen an den serverseitigen Teil des Softwaresystems
geliefert werden. Dieser stellt die gewünschten Verarbeitungsroutinen
und erforderliche Datenspeichermedien zur Verfügung.
-
Derartige Netzwerke bieten somit
ein dynamisches und zuverlässiges
System für
eine Vielzahl von Benutzern. Problematisch ist allerdings, wenn auf
an sich im Intranet zur Verfügung
gestellte Softwaresysteme auch ohne Zugang zum Intranet zugegriffen
werden soll. Dies kann beispielsweise dann gewünscht sein, wenn ein Mitarbeiter
eines Unternehmens auf einer Dienstreise keine Möglichkeit hat, sich in das
firmeneigene Intranet einzuwählen.
-
Um bei solchen Situationen Abhilfe
zu schaffen, wurde bereits vorgeschlagen, Teile des Servers auf
einen Client-Rechner zu kopieren, das heißt insbesondere die Applikationen
inklusive HTML-Seiten, Programmen und die Datenbank. Auf dem Client-Rechner
können
dann die an sich für
den Server vorgesehenen Applikationen zum Einsatz kommen. Auf diese
Weise entstehen unterschiedliche Datenzustände auf dem Server beziehungsweise
dem Client-Rechner. Bei fortschrittlichen Systemen ist es bereits
möglich,
diese unterschiedlichen Datenbestände von Online-Systemen und
Offline-Systemen zu synchronisieren.
-
Dennoch existiert auch bei den fortgeschrittenen
Systemen das Problem, dass es aufgrund der auf dem Client-Rechner
bearbeiteten Daten zu inkonsistenten Datenbeständen kommen kann, insbesondere
da ein gleichzeitiger Zugriff von mehreren Benutzern stattfinden
kann. Derartige inkonsistente Datenbestände, die sich im schlimmsten
Fall in Datenverlusten äußern können, sind
nicht akzeptabel.
-
Der Erfindung liegt die Aufgabe zugrunde, ein
Verfahren und eine Systemkonfiguration zur Verfügung zu stellen, so dass die
Nachteile und Probleme des Standes der Technik ausgeräumt beziehungsweise überwunden
werden, wobei insbesondere Datenverluste und inkonsistente Datenbestände vermieden
werden sollen.
-
Diese Aufgabe wird mit den Merkmalen
der unabhängigen
Ansprüche
gelöst.
-
Vorteilhafte Ausführungsformen und Weiterbildungen
der Erfindung sind in den abhängigen
Ansprüchen
angegeben.
-
Die Erfindung baut auf dem gattungsgemäßen Verfahren
dadurch auf, dass der mindestens eine zweite Datensatz in der Server-Datenbank
in markierter Form gespeichert wird, so dass der Zugriff auf den
mindestens einen zweiten Datensatz in der Server-Datenbank gesperrt ist. Es ist mit anderen Worten
möglich,
Datenbestände
zu reservieren und offline zu bearbeiten. Auf diese Weise wird bei
einem gewünschten
gleichzeitigen Zugriff mehrerer Benutzer auf die gleichen Daten
ein Datenverlust oder eine Inkonsistenz der Datenbestände vermieden.
-
Das erfindungsgemäße Verfahren ist in besonders
vorteilhafter Weise dadurch weitergebildet, dass zum Freigeben des
Zugriffs auf den mindestens einen zweiten Datensatz in der Server-Datenbank dieser
in nicht markierter Form in der Server-Datenbank gespeichert wird.
Sobald ein Benutzer mit der Verarbeitung der Daten im Offline-System
zu einem Ende gekommen ist, können
die betreffenden Sätze wieder
für andere
Benutzer zugänglich
gemacht werden. Es ist also nicht mehr erforderlich, die Daten in markierter
Form in der Server-Datenbank zu speichern. Vielmehr sollten die
Daten wieder in Abwesenheit jeglicher Markierung für alle Benutzer
zugänglich sein.
Dies gilt sowohl für
Nutzer, die die Daten online bearbeiten wollen als auch für Benutzer,
die eine Übertragung
der Daten zur Weiterverarbeitung in einem Offline-System wünschen.
-
Ebenfalls kann in besonders vorteilhafter Weise
vorgesehen sein, dass auf dem Server mindestens zwei Datenbank-Manager
vorgesehen sind, wobei ein erster Datenbank-Manager mit der Server-Datenbank verbunden
ist und ein zweiter Datenbank-Manager mit der lokalen Datenbank
verbunden ist, und dass auf dem Client-Rechner den Datenbank-Managern
entsprechende Mittel vorgesehen sind, welche Anfragen des Client-Rechners an die Datenbank-Manager
weiterleiten. Eine solche Weiterbildung des erfindungsgemäßen Verfahrens
ist zum Beispiel dann sinnvoll, wenn es in der Programmiersprache
Java implementiert ist. Da aus einem Java-Applet nicht auf eine
lokale Datenbank zugegriffen werden darf, werden sowohl die Datenbankverbindung
zur lokalen Datenbank als auch die Datenbankverbindung zur Server-Datenbank
vom Server aus aufgebaut. Die Programmkomponenten, die die Datenbankzugriffe
durchführen,
das heißt
die Datenbank-Manager, befinden sich ebenfalls auf dem Server. Die
den Datenbank-Managern
entsprechenden Mittel sind als "Platzhalter" auf dem Client-Rechner
angeordnet. Sie bieten die gleiche Schnittstelle an und delegieren
alle Anfragen an den Server, wo sie von Servlets angenommen werden
und an die Datenbank-Manager weitergeleitet werden. Hierbei wird
die Technik des HTTP-Tunnelings eingesetzt. Da jeder Datenbank-Manager genau auf
eine Datenbank zugreifen kann, werden bei der diskutierten Weiterbildung
der vorliegenden Erfindung zwei Datenbank-Manager, zwei Platzhalter
im Client-Rechner
und zwei Servlets benötigt.
Ein Applet auf der Seite des Client-Rechners ist in der Lage, eine
Hilfsfunktion aufzurufen, die dem Stellvertreterobjekt (Platzhalter),
welches für
die serverseitige Datenbank zuständig
ist, den Auftrag gibt, alle zum Datensatz gehörenden Daten zu lesen. Diese
Daten werden dann an das andere Stellvertreterobjekt weitergeleitet,
welches sie in die lokale Datenbank schreibt.
-
Das erfindungsgemäße Verfahren ist in besonders
vorteilhafter Weise dadurch weitergebildet, dass der erste Datensatz
Standardkomponenten umfasst und dass der mindestens eine zweite
Datensatz projektbezogene Daten umfasst, d.h. in beiden Datenbanken
sind sogenannte Basisdaten vorhanden, die von den Projektdatensätzen benutzt
(referenziert) werden.
-
Die auf dem Client-Rechner installierte
Datenbank enthält
nach der Installation vorzugsweise nur Stammdaten, wie zum Beispiel
Standardkomponenten, die in den Projekten verwendet werden dürfen, oder
Benutzerdaten. Projektspezifische Daten müssen explizit aus dem Online-System "ausgecheckt" werden, d.h. bevor
der geänderte
Datensatz wieder freigegeben wird, werden die Änderungen in die Online-Datenbank
kopiert und somit alle Daten, die zu einem bestimmten Projekt gehören, in
die lokale Datenbank des Offline-Systems kopiert. Im Online-System
wird das entsprechende Projekt als "ausgecheckt" markiert.
-
Besonders nützlich ist es, dass das Auswählen des
mindestens einen zweiten Datensatzes anhand eines Namens des mindestens
einen zweiten Datensatzes erfolgt, dass vor dem Schreiben des mindestens
einen zweiten Datensatzes in die lokale Datenbank geprüft wird,
ob in der lokalen Datenbank bereits ein Datensatz mit dem selben
Namen vorliegt, und dass in dem Fall, dass bereits ein Datensatz
mit dem selben Namen in der lokalen Datenbank vorliegt, dieser vor
dem Schreiben des mindestens einen zweiten Datensatzes in die lokale
Datenbank gelöscht
wird. Zu diesem Zweck kann ein eindeutiger Datensatzbezeichner verwendet
werden, der den Datensatz identifiziert. Weiterhin sorgt der Datensatzbezeichner
dafür,
dass eine eventuell vorhandene ältere
Version gelöscht
wird, bevor eine neue Version angelegt werden kann. Ein solcher
Datensatz kann sich über
beliebig viele Datenbanktabellen verteilen. Für den Fall, dass im Rahmen
des erfindungsgemäßen Verfahrens
Standardkomponeneten von dem Datensatz referenziert werden, die
in allen Datenbanken gleichermaßen
vorhanden sind, so müssen
diese Standardkomponenten nicht vom Server auf den Client-Rechner
kopiert werden. Will man so verfahren, so bedeutet dies allerdings,
dass Änderungen,
die an Standardkomponenten durchgeführt werden, in allen lokalen
Datenbanken nachvollzogen werden müssen. Dies muss erfolgen, bevor
Datensätze,
die diese veränderten
oder neu hinzugefügten Komponenten
benutzen, "ein-
oder ausgecheckt" werden
können.
-
Ein Beispiel für eine Anwendung ist der Einsatz
der Erfindung für
die Entwicklung eines "WindCenter's". Dabei werden komplette Windparkdaten zwischen
der Online-Datenbank und den einzelnen Oftline-Datenbanken hin und
her bewegt. Das im WindCenter Projekt entwickelte, webbasierte System ermöglicht die
Konfiguration von Windparkanlagen und die Berechnung aller relevanter
technischer und finanzieller Daten.
-
Dazu werden zuerst alle Daten, die
zu einem Projekt gehören
nacheinander aus der Serverdatenbank ausgewählt, gelesen, in die lokale
Datenbank geschrieben und in der Server-Datenbank in markierter
Form gespeichert. Da die zu einem Projekt gehörenden Daten aus vielen verschiedenen
Teildaten bestehen, gibt es für
alle diese Teildaten eigene Zugriffs- und Speichermethoden, die
nacheinander aufgerufen werden bis alle Daten in der Oftline-Datenbanken
enthalten sind.
-
Während
des Kopiervorganges werden dabei mehrere Unterfunktionen aufgerufen,
welche die Teildatensätze
kopieren. Beispielsweise kann ein Benutzer Windparkdaten kopieren.
Das System ruft dann u.a. Funktionen auf, die Finanzdaten und technische
Daten kopieren. Der komplette Windpark-Datensatz wird dann reserviert
und alle Daten sind in der auf dem Client-Rechner gespeicherten
Oftline-Datenbank enthalten. Natürlich
kann der Benutzer dabei auch die Daten mehrerer Windparks kopieren.
-
Das erfindungsgemäße Verfahren wird dadurch in
besonders vorteilhafter Weise gestaltet, dass nach dem Verarbeiten
der Daten in dem Offline-System verarbeitete Daten in das Online-System übertragen
werden. Nach diesem Übertragen
der Daten des Offline-Systems
zum Online-System können
die Daten wieder für
alle Benutzer freigegeben werden, um weiterverarbeitet zu werden.
Neben dem Übertragen
der geänderten
Projektdaten vom Offline-System ins Online-System ist es ebenfalls
möglich,
Daten von neu angelegten Projekten in das Online-System zu übertragen
und somit allen Benutzern zur Verfügung zu stellen.
-
Die Erfindung baut auf der gattungsgemäßen Systemkonfiguration
dadurch auf, dass der mindestens eine zweite Datensatz in der Server-Datenbank
in markierter Form speicherbar ist, so dass der Zugriff auf den
mindestens einen zweiten Datensatz in der Server-Datenbank gesperrt werden kann. Auf diese
Weise werden die Vorteile und Eigenschaften des erfindungsgemäßen Verfahrens
auch im Rahmen einer Systemkonfiguration umgesetzt. Dies gilt ebenfalls
für die
nachfolgend angegebenen besonders bevorzugten Ausführungsformen
der erfindungsgemäßen Systemkonfiguration.
-
Diese baut in besonders nützlicher
Weise dadurch auf der Erfindung auf, dass Mittel zum Freigeben des
Zugriffs auf den mindestens einen zweiten Datensatz in der Serverdatenbank
vorgesehen sind, die den mindestens einen Datensatz in nicht markierter
Form in der Server-Datenbank speichern.
-
Die erfindungsgemäße Systemkonfiguration ist
weiterhin in besonders vorteilhafter Wiese so fortgebildet, dass
auf dem Server mindestens zwei Datenbank-Manager vorgesehen sind,
wobei ein erster Datenbank-Manager mit der Server-Datenbank verbunden
ist und ein zweiter Datenbank-Manager mit der lokalen Datenbank
verbunden ist, und dass auf dem Client-Rechner den Datenbank-Managern
entsprechende Mittel vorgesehen sind, welche Anfragen des Client-Rechners
an die Datenbank-Manager weiterleiten.
-
Weiterhin kann bei der erfindungsgemäßen Systemkonfiguration
in nützlicher
Weise vorgesehen sein, dass der erste Datensatz Standardkomponenten
umfasst und dass der mindestens eine zweite Datensatz projektbezogene
Daten umfasst. Besonders bevorzugt kann bei einer erfindungsgemäßen Systemkonfiguration
vorgesehen sein, dass die Mittel zum Auswählen des mindestens einen zweiten
Datensatzes einen Namen des mindestens einen zweiten Datensatzes
verwenden, dass vor dem Schreiben des mindestens einen zweiten Datensatzes
in die lokale Datenbank geprüft
werden kann, ob in der lokalen Datenbank bereits ein Datensatz mit
demselben Namen vorliegt, und dass in dem Fall, dass bereits ein
Datensatz mit demselben Namen in der lokalen Datenbank vorliegt,
dieser vor dem Schreiben des mindestens einen zweiten Datensatzes
in die lokale Datenbank gelöscht
werden kann.
-
Ebenfalls kann die Systemkonfiguration
so ausgelegt sein, dass mehrere zweite Datensätze nacheinander aus der Serverdatenbank
ausgewählt, gelesen,
in die lokale Datenbank geschrieben und in der Server-Datenbank
in markierter Form gespeichert werden können.
-
Nützlicherweise
ist die Systemkonfiguration so gestaltet, dass nach dem Verarbeiten
der Daten in dem Offline-System verarbeitete Daten in das Online-System übertragen
werden können.
-
Der Erfindung liegt die Erkenntnis
zugrunde, dass es möglich
ist, ein verbindungsorientiertes Informationssystem auch offline
zur Verfügung
zu stellen, ohne dass die Gefahr von Datenverlusten oder inkonsistenten
Datenbeständen
auftreten könnte.
Projektabhängige
Datenbestände
können
reserviert und offline bearbeitet werden. Im Anschluss hieran können sie
wieder in das Online-System rückgeführt werden.
-
Die Erfindung wird nun mit Bezug
auf die begleitenden Zeichnungen anhand bevorzugter Ausführungsformen
beispielhaft erläutert.
-
Dabei zeigt:
-
1 ein
Blockdiagramm einer erfindungsgemäßen Systemkonfiguration;
-
2 ein
erstes Flussdiagramm zur Erläuterung
eines erfindungsgemäßen Verfahrens;
-
3 ein
zweites Flussdiagramm zur Erläuterung
eines erfindungsgemäßen Verfahrens;
-
4 ein
drittes Flussdiagramm zur Erläuterung
eines erfindungsgemäßen Verfahrens
und
-
5 eine
schematische Darstellung einer Benutzeroberfläche.
-
1 zeigt
ein Blockdiagramm einer erfindungsgemäßen Systemkonfiguration. Das
gesamte System ist in einen Server 10, der das Online-System bildet,
und einen Client-Rechner 14,
der das Offline-System bildet, unterteilt. Auf dem Server 10 sind eine
Server-Datenbank 12 sowie ein Datenbank-Manager 18 (DBManager)
für die
Server-Datenbank 12 vorgesehen.
Auf dem Client-Rechner 14 ist eine lokale Datenbank 16 vorgesehen.
Zum Zugriff auf diese lokale Datenbank 16 auf dem Client-Rechner 14 ist auf
dem Server 10 ein weiterer Datenbank-Manager 20 vorgesehen.
Beide Datenbank-Manager 18, 20 auf
dem Server 10 stehen mit den Servlets 28, 30 in Verbindung,
wobei das Datenbankservlet 28 dem Datenbank-Manager 18 für die Serverdatenbank 12 zugeordnet
ist und das Remote-Datenbankservlet 30 dem Datenbank-Manager 20 für die lokale
Datenbank 16 zugeordnet ist. Das Datenbankservlet 28 kommuniziert
mit einem Platzhalter 22, der auch als "ClientProxy" bezeichnet werden kann. Das Remote-Datenbankservlet 30 kommuniziert
mit einem weiteren Platzhalter 24, der ebenfalls als ClientProxy
bezeichnet werden kann. Auf dem Client-Rechner 14 wird
im Rahmen eines Web-Browsers 26 ein Applet zur Verfügung gestellt,
der über
die Platzhalter 22, 24 einen "check in/check out-Dialog" mit den Datenbank-Managern 18, 20 führen kann.
-
Im Einzelnen erfolgt die Kommunikation
des Client-Rechners mit dem Server wie folgt. Das Applet im Web-Browser 26 auf
dem Client-Rechner 14 ruft eine Hilfsfunktion auf ("moveObject"), die dem Stellvertreterobjekt 22,
welches für
die Server-Datenbank 12 zuständig ist, in Auftrag gibt,
alle zu einem bestimmten Datensatz gehörenden Daten zu lesen. Weiterhin
lautet der Auftrag, diese Daten dann an das andere Stellvertreterobjekt 24 weiterzugeben. Dieses
schreibt dann die Daten unter Vermittlung des Remote-Datenbankservlet 30 und
des Datenbank-Managers 20 in die lokale Datenbank 16 des Client-Rechners 14.
Zu diesem Zweck identifiziert ein eindeutiger Datensatzbezeichner
den Datensatz. Auf dieser Grundlage kann dafür gesorgt werden, dass eine
eventuell vorhandenen ältere
Version des Datensatzes in der lokalen Datenbank 16 gelöscht werden
kann, bevor ein neuer Datensatz angelegt wird. Die nun "ausgecheckten" Projektdaten werden
in markierter Form auf der serverseitigen Datenbank 12 gespeichert,
um sie im Hinblick auf einen weiteren Zugriff zu schützen. Das "auschecken" der Projektdaten
besteht also in einem Lesen der Projektdaten von der Server-Datenbank 12,
einem Schreiben der Projektdaten in die lokale Datenbank 16 sowie
einem Speichern markierter Projektdaten in die Server-Datenbank 12.
-
In einem System für viele Benutzer bedienen die
in 1 dargestellten Datenbank-Manager 18, 20 genau
einen Client. Die Datenbank-Manager werden als Softwarekomponenten
daher für
jeden Client neu erzeugt.
-
2 zeigt
ein Flussdiagramm zur Erläuterung
eines erfindungsgemäßen Verfahrens.
In Schritt 210 werden Projektdaten aus der serverseitigen
Datenbank 12 gelesen. Diese Projektdaten 212 werden dann
in Schritt 214 daraufhin geprüft, ob bereits ein Projekt
mit dem gleichen Namen in der clientseitigen Datenbank 16 existiert.
Ist dies der Fall, so werden in Schritt 216 die Projektdaten
in der clientseitigen Datenbank 16 gelöscht. Danach wird zu Schritt 218 übergegangen.
Ergibt sich in Schritt 214, dass noch kein Projekt mit
dem gleichen Namen existiert, so kann sogleich zu Schritt 218 übergegangen
werden, in dem die Projektdaten in die clientseitige Datenbank 16 geschrieben
werden. In Schritt 220 werden nachfolgend die serverseitigen
Projektdaten als "ausgecheckt" markiert. Die markierten
Projektdaten 222 werden in Schritt 224 in der
serverseitigen Datenbank 12 gespeichert.
-
Bei dem Flussdiagramm gemäß 2 wurde zur Vereinfachung
der Darstellung davon ausgegangen, dass nur ein zusammenhängender
Datensatz in den Client-Rechner übertragen
werden soll.
-
3 zeigt
ein Flussdiagramm zur Erläuterung
eines erfindungsgemäßen Verfahrens.
-
Das Flussdiagramm berücksichtigt,
dass die zu einem Projekt gehörenden
Daten aus vielen verschiedenen Teildaten bestehen. Daher gibt es
für alle diese
Teildaten eigene Zugriffsverfahren und Speicherverfahren, die nacheinander
aufgerufen werden, bis alle Daten in der lokalen Datenbank enthalten sind.
-
In Schritt 310 wird ein
erster Teil von Projektdaten aus der serverseitigen Datenbank 12 gelesen. Diese
Projektdaten (Teil 1) 312 werden zunächst in Schritt 314 daraufhin überprüft, ob ein
Projekt mit gleichem Namen in der clientseitigen Datenbank 16 existiert.
Ist dies der Fall, so werden die kompletten Projektdaten in der
clientseitigen Datenbank 16 gelöscht. Danach kann zu Schritt 318 übergegangen werden.
Wird in Schritt 314 festgestellt, dass kein Projekt mit
dem gleichen Namen existiert, so kann sogleich zu Schritt 318 übergegangen
werden, in dem der erste Teil der Projektdaten in die clientseitige Datenbank 16 geschrieben
werden kann. Nachfolgend wird im Schritt 322 überprüft, ob bereits
alle Projektdaten vom Server zum Client transferiert wurden. Ist
dies nicht der Fall, so wird in Schritt 324 ein weiterer
Teil der Projektdaten aus der serverseitigen Datenbank gelesen.
Diese Projektdaten (weiterer Teil) 326 werden dann in Schritt 320 in
die clientseitige Datenbank 16 geschrieben. Wird in Schritt 322 ermittelt,
dass bereits alle Projektdaten vom Server zum Client transferiert
wurden, so können
diese Projektdaten in Schritt 328 als "ausgecheckt" markiert werden. Die markierten Projektdaten
(Teil 1) 330 können
dann in der serverseitigen Datenbank 12 als markierte Projektdaten
in Schritt 332 gespeichert werden.
-
4 zeigt
ein Flussdiagramm zur Erläuterung
eines erfindungsgemäßen Verfahrens.
-
In diesem Flussdiagramm ist die Kommunikation
zwischen dem Client-Rechner und Server im Detail dargestellt.
-
In Schritt 410 wird vom
Client zunächst
die Methode des sogenannten "ClientProxy" aufgerufen, welches
mit der serverseitigen Datenbank verbunden ist. In Schritt 412 wird
ein Request-Objekt erzeugt und an das Datenbank-Servlet gesendet.
Das Request-Objekt 414 wird vom Server in Schritt 416 gelesen,
wobei die entsprechende Methode des Datenbank-Managers ausgeführt wird,
der mit der serverseitigen Datenbank verbunden ist. Diese Methode liest
einen Teil der Projektdatenbank aus der Server-Datenbank 12.
Der Teil der Projektdaten (auf dem Server) 418 wird in
Schritt 420 in ein Response-Objekt geschrieben und an den
Client zurückgeschickt. Das
Response-Objekt mit den Projektdaten 422 wird vom Client
in Schritt 424 gelesen. Nunmehr liegt ein Teil der Projektdaten 426 auf
dem Client vor. In Schritt 428 wird auf der Seite des Clients
in Schritt 428 die Methode des ClientProxy aufgerufen,
welches mit der clientseitigen Datenbank verbunden ist. In Schritt 430 wird
ein Request-Objekt erzeugt und an das Datenbank-Remoteservlet gesendet. Auf diese Weise
wird ein Request-Object 432 zur Verfügung gestellt, welches in Schritt 434 vom
Server gelesen werden kann. Weiterhin wird in diesem Schritt 434 die
entsprechende Methode des Datenbank-Managers ausgeführt, der
mit der clientseitigen Datenbank verbunden ist. Diese Methode schreibt
dann einen Teil der Projektdaten in die Client-Datenbank 16.
In Schritt 436 wird nachfolgend eine Antwort 438 in
ein Response-Objekt geschrieben und an den Client zurückgeschickt.
-
5 zeigt
eine schematische Darstellung einer Benutzeroberfläche. Auf
der rechten Seite der Benutzeroberfläche werden die auf der Server-Datenbank
gespeicherten Daten angezeigt. Diese werden unterteilt in editierbare
(editable) Datensätze,
die im oberen Bereich gezeigt sind, und Datensätze, die nur gelesen werden
können
(read only), welche im unteren Bereich dargestellt werden. Die Datensätze, die
auf der rechten Seite im unteren Bereich dargestellt werden, sind
als "ausgecheckt" markiert. Sie sind
auf dem Client-Rechner im oberen Bereich dargestellt und insofern
editierbar (editable). Es sind weiterhin mehrere für Benutzeroberflächen typische Funktionselemente
dargestellt, mit denen Datensätze
ausgewählt
beziehungsweise zwischen den einzelnen Feldern überführt werden können. Als
weitere Funktion kann das Benutzerschnittstellenfenster mittels
des Funktionselementes "close" geschlossen werden.
-
Die in der vorstehenden Beschreibung,
in den Zeichnungen sowie in den Ansprüchen offenbarten Merkmale der
Erfindung können
sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung
der Erfindung wesentlich sein.