Diese Seite wird nicht mehr gepflegt. Bitte besuchen Sie www.PROJECT-CONSULT.de
This website is no longer updated. Please visit www.PROJECT-CONSULT.de
VERADOK
Das Projekt VERADOK
Designkriterien für VERADOK
Abbildung des VERADOK-Designs auf eine C/S-Architektur
Ausblick
Ist eine Client/Server-Architektur für Dokumentenmanagement-Systeme mit großen Dokumentmengen geeignet ?

Von Dr. Ulrich Kampffmeyer
Profil_Kampffmeyer

In Veröffentlichungen der letzten Zeit werden Stimmen laut, die die Eignung von Client/Server-Architekturen (C/S) für Dokumentenmanagementsysteme unter Nutzen/Kosten- und auch Performance-Aspekten in Frage stellen. Es werden Alternativ-Konzepte vorgeschlagen, die grafische Arbeitsplätze für die Präsentation und spezielle Erfassungsplätze für die Dokumenteneingangsverarbeitung direkt mit dem zentralen Host kombinieren. Für das Management und die Ablage großer Daten- und Dokumentmengen sei der Host besser als andere Systeme geeignet, im übrigen handele es sich hier ebenfalls um eine C/S-Architektur mit dem Host als Server. Der Artikel will diese Aussagen relativieren und die Vorteile von konsequenten C/S-Lösungen am Beispiel von Projekten wie VERADOK aufzeigen.
Client/Server-Architekturen, woran erkennt man sie?
Client/Server, übersetzt als Leistungsempfänger/ Leistungserbringer oder Auftraggeber/Auftragnehmer: Dies gibt es schon seit langem in der DV-Welt. Hardware- oder Software-Subsysteme liefern als Server spezielle Dienstleistungen, die von anderen Hard- oder Softwaresystemen als Leistungsempfänger genutzt werden. Zwei Beispiele aus älterer und jüngerer DV-Geschichte: Host/Speichersubsystem und Anwendungsprogramm/Datenbankserver.
Der heute übliche Begriff definiert dieses Auftraggeber/Auftragnehmer-Verhältnis sehr viel umfassender. Jede abgrenzbare Leistung in einem System kann als Service beschrieben werden, der von Leistungsempfängern über definierte, ggf. auch genormte Serviceschnittstellen genutzt werden kann. Der Leistungserbringer ist der Server, die Leistung selbst der Service, der Leistungsempfänger der Client. Wie im wahren Leben kann ein Server oder Client selbst wieder Server oder Client sein. Außerdem ist mit dem Begriff nicht die Realisierung vorgegeben. Ob der Service durch Software, Hardware, menschliche Tätigkeit oder eine Kombination aus allem erbracht wird, bleibt der Systemimplementierung überlassen.
Wendet man diese Definition auf die eingangs zitierten Host-basierten Systeme an, dann können auch diese Architekturen den Begriff C/S für sich reklamieren, wenn auch das Gesamtsystem vielleicht nur in einem geringen Umfang in Services strukturiert ist.
Es hilft nach Ansicht der Autoren nicht weiter, mit fast religiösem Eifer den Begriff C/S für die eine oder andere Seite zu okkupieren. In allen von Softwareingenieuren konstruierten Systemen lassen sich Teile identifizieren, die der Definition C/S genügen. C/S an sich ist also unbestritten, die Frage muß vielmehr lauten:
Wieviel C/S-Technologie und zu welchem Preis benötigt eine die Anforderungen der Anwender erfüllende konkrete Lösung?
Dokumentenmanagementsysteme, was versteht man darunter?
Im Zuge der schnellen Entwicklung der letzten Jahre und um sich vom jeweiligen Mitbewerber abzuheben, wurden eine Vielzahl von verschiedenen Begriffen eingeführt. Um nur einige zu nennen: Optical Filing, Document Management, Image Processing, Workflow-Management, elektronisches Archiv.
Im Verständnis der Autoren ist ein Dokumentenmanagementsystem ein komplexes System, das der Verwaltung und Bearbeitung von kodierten und nichtkodierten Informationen dient. Es ist in den organisatorischen Fluß eines Unternehmens eingebunden und besteht aus verschiedenen Teilkomponenten, wie z. B. Archivkomponenten und Vorgangsbearbeitungssystemen. Der Einsatz optischer Speicher wird nicht zwingend impliziert. Besondere Anforderungen sind dabei an die Vorgangsbearbeitung zu stellen, da im Gegensatz zu rein datenorientierten Systemen hier große Mengen an nichtkodierten Faksimileinformationen transportiert, gespeichert und am Arbeitsplatz zur Verfügung gestellt werden müssen. Diese Daten benötigen im Durchschnitt das 10-fache an Speicherplatz, der Engpaß ist dabei die Verteilung und Bereitstellung der Information im Netz. Zusätzliche Probleme entstehen durch die Behandlung gemischter Dokumente aus Daten- und Imagekomponenten, Rahmenbedingungen wie Zugriffszeiten und Blätterzeiten, die Einbettung in eine ganzheitliche Sachbearbeitung und eine prozeßorientierte Vorgangssteuerung mit Anbindung an benachbarte Anwendungssysteme.
Die Komplexität von Dokumentenmanagementsystemen steigt mit dem Integrationsgrad. Außerdem findet man selten die "grüne Wiese" vor. Die bestehende Systemlandschaft muß in den meisten Fällen integriert werden (Bild 1: "Der Weg in die Vollintegration").
Die eingangs gestellte Frage "Ist C/S für Dokumentenmanagementsysteme mit großen Dokumentenmengen geignet" ist nach unserem Verständnis nicht mit einem Ja oder Nein zu beantworten. Die Frage muß vielmehr lauten:
Wieviel C/S-Technologie benötigt oder verträgt ein Dokumentenmanagementsystem, um bei vorgegebenem Integrationsgrad und Mengenvolumen die Anwenderwünsche zu erfüllen?
Top
Das Projekt VERADOK
Das Projekt VERADOK kann als ein Beispiel für die Mächtigkeit von Client/Server-Lösungen bei großen Dokumentenmanagementsystemen dienen. Das Projekt soll für das Landesamt für offene Vermögensfragen (LAROV) mit fünf Abteilungen und für sechs weitere angeschlossene Ortsämter Probleme der Aktenerschließung, der Aktenverteilung und der Aktenbearbeitung lösen. Das System unterstützt 700 Benutzer im geplanten Endausbau, davon derzeit 450 Imaging-Nutzer, ca. 40 Scan-Arbeitsplätze und ca. 80 Arbeitsplätze für andere Funktionen. Die Menge der zu bewegenden Dokumente und der Bearbeitungsvorgänge ist erheblich, ebenso die Querbezüge zwischen den Daten.
Informationsvolumen:
ca. 300.000 Karteikarten
ca. 130.000 Registraturakten
mit insgesamt ca. 6.300.000 Seiten
ca. 250.000 Magistratsakten mit insgesamt ca. 11.000.000 Seiten
ca. 2 GigaByte Datenbankvolumen.
Transaktionsvolumen:
ca. 2000 Datenbankrecherchen täglich
ca. 1200 Vorgangsbereitstellungsaktionen täglich
ca. 20.000 gescannte Seiten täglich aus Altbestand und Neuzugang.
Im Projekt VERADOK betreffen Vorgänge jeweils ca. 30 bis 200 Faksimileseiten, ca. 30 Dateien / Tabellen und etwa weitere 100 Steuerinformationen. Ein Sachbearbeiter hat zu einem Zeitpunkt bis zu 30 Vorgänge gleichzeitig in Bearbeitung, die Bearbeitungszeit liegt zwischen 14 Tagen und 6 Monaten, in bestimmten Abteilungen auch im
30-Minutenbereich. Der Sachbearbeiter muß aufgrund großer Abhängigkeiten zwischen einzelnen Vorgängen ständigen und wechselnden Zugriff auf seinen aktuellen Arbeitsbestand haben.
Top
Designkriterien für VERADOK
In der Designphase von VERADOK wurden die Anforderungen beschrieben und klassifiziert. Die zwei wesentlichen Kernelemente waren die Gestaltung der Vorgänge und Abläufe und die Abbildung auf eine geeignete Technik bei hohen Erwartungen an Ergonomie, Verfügbarkeit und Performance.
Die virtuelle elektronische Mappe
Grundlage des Designs ist die objektorientierte virtuelle Vorgangsmappe. Sie trägt in sich (self-contained) alle für eine Vorgangsverarbeitung erforderlichen Informationen - Daten, Dateien, Bildinformationen. In der Regel beinhaltet die Vorgangsmappe hierarchische Strukturen und Verweise zu anderen Objekten.
Der ganzheitliche multifunktionale Arbeitsplatz
Um dieses komplexe Objekt im Wechsel mit anderen in Arbeit befindlichen Objekten ergonomisch dem Sachbearbeiter anbieten zu können, stehen ihm hochauflösende großformatige graphische Arbeitsplätze zur Verfügung. Der Bildaufbau ist so organisiert, daß eine schnelle Vorgangsbearbeitung und ermüdungsfreier Dokumentenzugriff und -bearbeitung möglich ist. (Bild-3, Bildschirmarbeitsplatz). Die Funktionalität wird ganzheitlich angeboten, Werkzeuge wie z.B. Standardtextverarbeitung oder individuelle Fachfunktionen sind in die Vorgangsbearbeitung integriert. Die Ergebnisse werden automatisch der virtuellen Akte zugeordnet.
Die Bereitstellung der Informationen über Servicefunktionen
Die Anwendung erfordert eine hohe Verfügbarkeit und Datensicherheit. Um diese Probleme zu isolieren, setzt das Design auf abgrenzbare Servicefunktionen, die bezüglich dieser Forderungen weitgehend unabhängig voneinander sowohl softwaretechnisch als auch hardwaretechnisch optimiert werden können. Die wichtigsten sind (im VERADOK-Projekt in Vorbereitung)
Objektservice
Stellt der Anwendung bedarfsorientiert komplexe Objekte(virtuelle elektronische Mappe) zur Verfügung.
Replikationsservice
Sorgt bei Veränderungen in den Objekten für Konsistenz mit dem zentralen Bestand. Der Konsistenzerhalt wird asynchron im Hintergrund durchgeführt.
Scanservice
Stellt alle für das Scannen der Altdokumente und der Neuzugänge notwendigen Funktionen zur Verfügung.

Diese Dienste benutzen selbst weitere, dem Anwendungsprogramm direkt nicht zugängliche Dienste, wie z. B.

Archivservice
Stellt den physikalischen Zugriff auf nichtkodierte Informationen im optischen Archiv zur Verfügung.
Datenbankservice
Stellt den Zugriff auf kodierte Informationen in der relationalen Datenbank zur Verfügung

Die Modularisierung der Anwendung in Fachfunktionen und die Integration über ein Vorgangsmanagementsystem
Die Anwendung ist unter Nutzung der Servicefunktionen in Fachfunktionen strukturiert. Die Fachfunktionen (sowohl individuelle Entwicklungen als auch angepaßte Standardanwendungen, wie z. B. Textprozessoren) werden mit Hilfe eines Vorgangsmanagementsystems zu einem prozeßorientierten ganzheitlichen Sachbearbeiterplatz integriert. Alle in der Anwendung verwendeten Fachfunktionen, unabhängig von dem unterliegenden Betriebssystem und der Hardware, sind in den Prozess integrierbar. Dies wird demnächst durch eine standardisierte Anbindung an einen Workflowserver erreicht.
Top
Abbildung des VERADOK-Designs auf eine C/S-Architektur
Die für VERADOK aufgestellten Designkriterien könnten auf den ersten Blick auch in einer eingeschränkten Client/Server-Umgebung, in der die grafischen Arbeitsplätze direkt an den Host gebunden sind, erfüllt werden. Betrachtungen zur Ausfallsicherheit und zum Durchsatz zeigen aber, daß eine konsequente Abbildung auf eine Mehrschichtenarchitektur in vieler Hinsicht Vorteile bringt.
Ausfallsicherheit
Die Ausfallsicherheit ist kein Wert an sich, sondern nur aussagekräftig in Zusammenhang mit der Angabe, wie lange und in welchen Funktionen ein Arbeitsplatz gestört sein darf, bis er als "ausgefallen" gilt. In Dokumentenmanagementsystemen gibt es in der Regel keine Realzeitbedingungen, die Aktualität der Daten muß aber statistisch garantiert sein, und die Konsistenz im Gesamtsystem darf nicht gefährdet sein.
Damit gilt ein Arbeitsplatz im Dokumentenmanagementsystem erst dann als ausgefallen, wenn
er hard- oder softwaretechnisch bedingt unbedienbar geworden ist,
der Arbeitsvorrat für die Vorgangsbearbeitung nicht mehr ergänzt werden kann und auch im Rahmen der Vorgangsbearbeitung keine anderen Aufgaben zur Bearbeitung anstehen,
aktuelle Daten abgerufen werden müssen, diese aber nicht abrufbar sind.
Bildet man die geschilderten Designkriterien, insbesondere die asynchrone Objektbeschaffung und Objektreplizierung durch Objektservice und Replikatorservice auf eine Client/Server-Struktur in einem Mehrebenenmodell (Arbeitsplatzrechner, Abteilungsserver, ggf. Host) ab, dann ist die Gesamtstruktur ausfallsicherer gemäß obiger Definition als in einer reinen PC-Host-Umgebung. Folgende Ausfälle werden durch die Struktur aufgefangen:
Auch bei Ausfall der zentralen Ressourcen halten die Abteilungsserver einen Arbeitsvorrat, der auch ohne Verfügbarkeit der optischen Speicher für mehrere Tage ausreichend ist.
Bei Ausfall des Archivservers oder des Datenbankservers kann innerhalb von wenigen Minuten der gespiegelte Server die Arbeit übernehmen.
Bei Ausfall eines Archivsystems kann das Archiv vom zweiten System 1:1 rekonstruiert werden.
Bei Ausfall eines Abteilungsservers kann nach kurzer Anlaufzeit ein anderer Abteilungsserver die Aufgaben und die Daten des ausgefallenen Servers zeitweilig übernehmen.
Durch die Verteilung der Informationen innerhalb der Speicherhierarchie kann der Benutzer bei Ausfall des lokalen Netzes kurze Zeit auch mit der Textverarbeitung und seinem lokalen Arbeitsvorrat an Dokumenten ohne Verbindung zu den Servern weiterarbeiten.
Räumlich getrennte Aufstellung der Archivsysteme reduziert die Wahrscheinlichkeit für gemeinsame Totalausfälle. Die vorgestellte Client/ Server-Struktur in einem Mehrebenenkonzept ist damit auch aus Sicherheitsaspekten bei kritischen Daten gegenüber Host-basierten Systemen von Vorteil.
Durchsatz
Der Engpaß bei Dokumentenmanagementsystemen ist die Schnittstelle zu den Dokumentservern und das Netz. In VERADOK optimiert ein asynchroner Transport der kodierten und unkodierten Daten innerhalb der Speicherhierarchie den Datenfluß zwischen den Arbeitsplätzen (Ebene-1), den Abteilungsservern (Ebene-2), den Archiv- und Datenbankservern sowie den Spezialservern zur Ansteuerung und Verwaltung der Jukebox (Ebene-3). Wesentlich in diesem Konzept sind ein ausgefeiltes Caching, entsprechend der Netzauslastung bedarfsorientiert gesteuerte Zugriffsprotokolle und asynchrone Zugriffe auf die Datenbanken, getrennt von der Vorgangsbereitstellung am Arbeitsplatz. Für die konfigurierbaren Überlaufspeicher, die vom Cacheverfahren benötigt werden, stehen 200 MB am Arbeitsplatz, 8 GB auf den Abteilungsservern und bis zu 20 GB gespiegelt in Archiv- und Datenbankservern zur Verfügung. Mit diesem Konzept sind Zugriffs- und Blätterzeiten unter 1 bis 2 Sekunden am Arbeitsplatz erreichbar.
Die Netz- und Serverbelastung verringert sich durch die asynchrone Kopplung der hierarchischen Speicher. Durch den bedarfsorientierten Abruf der Daten in Form von virtuellen Objekten entzerrt sich der Datenverkehr, und kritische Engpässe im Informationsverbund haben nur noch kurzzeitige und lokale Auswirkungen. Selbst zu Stichzeiten, z. B. zu Arbeitsbeginn, ist keine Überlast zu erwarten, da der Arbeitsvorrat für den Sachbearbeiter nicht mit der Tagesarbeitszeit korrelliert.
Die für LAROV gewählte Struktur ist ohne Designänderungen kaskadierbar und damit an steigende Durchsatzanforderungen anpaßbar. Die entstehenden Kosten steigen mit dem Ausbau, Basisinvestitionen sind mit dem Grundausbau bereits abgedeckt.
Top
Ausblick
VERADOK wurde konsequent objektorientiert und verteilt entworfen, setzt in der Umsetzung aber noch an vielen Stellen auf individuellen Code. Die Autoren gehen davon aus, daß in sehr kurzer Zeit durch Betriebssystemkomponenten, Netzwerksoftware und Datenbanken die in VERADOK implementierten objektorientierten Verteil- und Replikationsmechanismen noch besser als heute durch Standardsoftware oder zumindest bewährte Industrieprodukte unterstützt werden. VERADOK wird sich dann dem technischen Fortschritt durch Austausch der individuellen systemtechnischen Teile relativ leicht anpassen können.
Die Grundidee der Verteilung von Information und der Entlastung zentraler Ressourcen auf Basis von Services und Client/Server-Architektur hat das Projekt nicht verteuert, aber neben den strukturellen Vorteilen einen Gewinn an Ausfallsicherheit und Durchsatz gebracht. Die Autoren sind von der Tragfähigkeit und Zukunftssicherheit des Designs überzeugt.
Rechtshinweis
© CopyRight PROJECT CONSULT 2001
Autorenrechte Dr. Ulrich Kampffmeyer

Home/Rechtshinweis
Presse/Autorenrechte
Zum Download sind auschließlich die Beiträge in der Rubrik Download vorgesehen. Als PDF bereitgestellte Beiträge enthalten auch die zugehörigen Grafiken.
Wissen/Download

Top
Seitentitel: Artikel_Veradok, Zitierung: http://www.PROJECT-CONSULT.com/home.asp?SR=245
Zuletzt aktualisiert am: 11.12.2001
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis
Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on)
Diese Seite wird nicht mehr gepflegt. Bitte besuchen Sie www.PROJECT-CONSULT.de
This website is no longer updated. Please visit www.PROJECT-CONSULT.de