DE10162251A1

DE10162251A1 - Verfahren, Gerätesystem und Computerprogramm zum geräteübergreifenden Verwalten und Bearbeiten von Dateien

Info

Publication number: DE10162251A1
Application number: DE2001162251
Authority: DE
Inventors: Steffen Petz
Original assignee: Oce Printing Systems GmbH and Co KG
Current assignee: Canon Production Printing Germany GmbH and Co KG
Priority date: 2001-12-18
Filing date: 2001-12-18
Publication date: 2003-07-10

Abstract

In einem Verfahren oder System zum Verwalten und Bearbeiten von Computer-Dateien mittels eines in einer objektorientierten Programmiersprache erzeugten Computerprogramms werden DOLLAR A - mit einem betriebssystemunabhängigen Schnittstellen-Programmodul Funktionen und Methoden zur Verwaltung und Bearbeitung von Dateien beschrieben und DOLLAR A - eine abstrakte Dateisystem-Klasse gebildet, die zumindest einen Teil der Funktionen und Methoden des systemunabhängigen Schnittstellen-Programmoduls implementiert, welche wiederum von davon abgeleiteten Implementierungen verwendet werden können.

Description

Die Erfindung betrifft ein Verfahren, ein Gerätesystem und ein Computerprogramm zum geräteübergreifenden Verwalten und Bearbeiten von Dateien.
Die Erfindung betrifft insbesondere ein Gerätesystem, das mit einem JAVA-basierten Schnittstellen-Programmodul gesteuert wird. Weiterhin betrifft die Erfindung ein JAVA-System, das zum Verwalten und Bearbeiten von Dateien geeignet ist, die in einem Netzwerk auf einem beliebigen Speichermedium wie z. B. auf einem Computer, einem Plattenlaufwerk, einem Bandspeicher, einer CD-ROM oder einem anderen Speichermedium gespeichert sind.
JAVA ist eine plattformunabhängige, objektorientierte Programmiersprache, mit der sichergestellt werden kann, dass Programme, die in JAVA geschrieben sind, auf beliebigen Computern bzw. Betriebssystemen ausgeführt werden können, sofern jeweils ein entsprechendes JAVA-System eingerichtet ist. Die grundlegenden Strukturen von JAVA, mit welchen die Plattformunabhängigkeit geschaffen wird, sind in dem amerikanischen Patent US-A-5,668,999 beschrieben.
Das Lesen, Schreiben, Löschen, Umbenennen und Kopieren sowie das Besorgen von bestimmten Informationen aus Dateien ist in JAVA nur für lokale Dateien implementiert, d. h. für Dateien, die auf demselben Computer physikalisch gespeichert sind, auf dem das JAVA-System installiert ist.
Dateien, deren Speicherort in einem Netzwerk beliebig sein kann, also lokale und nicht lokale Dateien, deren Verwaltung in einer computerübergreifenden Ebene erfolgt, werden nachfolgend logische Dateien genannt. Logische Dateien sind also Dateien in einem Computernetzwerk, auf die über bekannte JAVA-Strukturen insbesondere zur Ausführung von Verwaltungsoperationen systembedingt nicht zugegriffen werden kann. Dazu zählen zum Beispiel Remote-Dateien, d. h. Dateien, die auf einem anderen Computer oder in einem Geräte-Archiv gespeichert sind. Solche Dateien können aber beispielsweise an Ihrem Namen und Ihrem Speicherort, d. h. dem Pfadnamen in einem Netzwerk, identifiziert werden. Dabei ist es zu wünschen, dass auf solche Dateien nicht nur lesend zugegriffen werden kann, sondern sie auch verwaltet werden können, indem z. B. Datelattribute verändert oder der Speicherort (Pfad) geändert werden.
Eine Grundlage der JAVA-Programmierung ist das sogenannte Ableiten von Klassen. Verkürzt ausgedrückt, versteht man darunter das Erzeugen einer neuen Klasse aus einer alten Klasse, wobei die Funktionen und Methoden der alten Klasse in die neue Klasse übernommen werden und in dieser neuen Klasse mindestens eine Funktion, die in der alten Klasse nicht implementiert war, zusätzlich implementiert wird.
In anderen objektorientierten Programmiersprachen wie z. B. C⁺⁺ sowie in der objektorientierten beschreibungssprache UML (Unified Modeling Language) wird statt des Begriffs "Ableiten" auch der Begriff der "Vererbung" verwendet. Die UML ist in "UML-Unified Modeling Language, Objektorientierte Programmierung in der Praxis", R. Burkhardt, Addison-Wesley, Massachusetts (1999), ISBN 3-8273-1407-0 beschrieben.
Aus dem allgemein bekannten Betriebssystem Microsoft Windows® NT ist ein Programm-Modul zum Verwalten von Programmen bekannt. Des weiteren ist in diesem Betriebssystem das Dienstprogramm "Active Directory" enthalten, mit dem Objekte aller Art in einem Computernetzwerk verwaltet werden können. Details über dieses Active Directory Programm-Modul sind z. B. in den Veröffentlichungen "Inside Windows NT®", David A. Solomon, Microsoft Press, Redmond, Washington, USA (1998), ISBN 1-57231-677-2 auf Seiten 452 bis 455 und in "Microsoft Windows®2000 Server Deployment Planning Guide", Microsoft Press, Reämond, Washington, USA (2000), ISBN 1-57231-805-8 auf Seiten 255-271, 289-294 und 354-359 beschrieben. Weiterhin wurde im Microsoft Developer Network (MSDN) Library unter der Internet-Addresse: msdn.microsoft.com verschiedene Informationen zum Active Directory veröffentlicht, z. B. "Microsoft Windows 2000 Active Directory Technical Summary", "Active Directory Services Interface in the Microsoft Exchange 5.5. Environment", Microsoft Corporation (1997) und "NT Directory Services". Über dieselbe Adresse sind auch Informationen über das sogenannte Microsoft.NET Framework zu beziehen, durch das die Programmierbarkeit und Verfügbarkeit von Computerprogrammen in einem heterogenen Netzwerk verbessert werden kann.
Die Erfindung betrifft insbesondere auch ein Verfahren und ein System zur Verarbeitung eines Druckdatenstroms, der zur Ausgabe auf einem Druckgerät aufbereitet wird. Eine derartige Aufbereitung findet typischerweise in Computern statt, die Druckdateien oder Druckdaten aus Anwenderprogrammen heraus druckerangepaßt verarbeiten. Die Druckdaten werden dabei z. B. in einem Ausgabestrom einer bestimmten Druckdatensprache wie AFP® (Advanced Function Presentation), PCL oder PostScript umgewandelt. Die Druckdatensprache AFP ist beispielsweise in der Publikation Nr. F-544-3884-01 der Firma International Business Machines Corp. (IBM) mit dem Titel "AFP Programming Guide and Line Data Reference" beschrieben. Bei der Erstellung von Druckaufträgen mit dem Druckdatenformat AFP ist es häufig vorgesehen, vorgegebene Daten, sogenannte Resource- Daten erst kurz vor dem Drucken mit variablen Daten zu verbinden um ein Dokument zu erzeugen. Die Resource-Daten können dabei an verschiedenen Standorten bzw. Computern abgespeichert sein, die u. U. unter verschiedenen Betriebssystemen bzw. Platformen angesteuert werden.
In Großrechenzentren werden die Druckdaten typischerweise in einem Host Computer (Main Frame) zusammengetragen (Spooling- Vorgang) und daraus Druckaufträge (Jobs) generiert, die derart zur Ausgabe auf Hochleistungsdrucksystemen angepaßt sind, daß die Hochleistungsdrucksysteme im Produktionsbetrieb zeitlich optimal ausgelastet werden können. Sie können dabei weitgehend im kontinuierlichen Betrieb eingesetzt werden. Immer häufiger werden die Druckdaten dabei dezentral bearbeitet, die Daten an verschieden Sytandorten bzw. in verschiedenen Systemen gespeichert und erst zum Ausdrucken wieder zusammengeführt.
Derartige Hochleistungsdruckgeräte mit Druckgeschwindigkeiten von etwa 40 DIN A 4 Seiten pro Minute bis zu über 1000 DIN A 4 Seiten pro Minute und die dazugehörigen Arbeitsverfahren sind beispielsweise in der Veröffentlichung "Das Druckerbuch", herausgegeben von Dr. Gerd Goldmann (Oce Printing Systems GmbH), Ausgabe 4C, Oktober 1999, ISBN 3-000-00 1019-X beschrieben. Im Kapitel 12 (Seiten 12-1 bis 12-18) dieser Publikation ist das unter dem Namen PRISMA PRO® bekannte Server-System beschrieben, welches in Produktions-Druck- Umgebungen der Aufbereitung von Druckdatenströmen dient.
Die zuvor genannten Veröffentlichen werden hiermit durch Bezugnahme in die vorliegende Beschreibung aufgenommen.
Der Erfindung liegt die Aufgabe zugrunde, ein plattformunabhängiges, system-einheitliches Verfahren bzw. Steuerungssystem anzugeben, mit denen die Verwaltung und Handhabung sowohl von lokalen als auch von logischen Dateien auf einfache Art und Weise möglich ist.
Diese Aufgabe wird durch die in den unabhängigen Ansprüchen angegebene Erfindung gelöst. Vorteilhafte Ausführungsformen der Erfindung sind Gegenstand der Unteransprüche.
Erfindungsgemäß ist ein systemunabhängiges Schnittstellen- Programmodul vorgesehen, das Funktionen und Methoden zur Handhabung und Verwaltung von Dateien abstrakt beschreibt. Weiterhin ist eine abstrakte Dateisystem-Klasse vorgesehen, die zumindest einen Teil der Funktionen und Methoden des systemunabhängigen Schnittstellen-Programmoduls implementiert, welche wiederum von den von der abstrakten Dateisystem-Klasse abgeleiteten Implementierungen verwendet werden können.
Die Erfindung beruht auf der Überlegung, dass es durch eine objektorientiert programmierte, systemunabhängige Datei- System-Schnittstelle, die eine Fülle von abstrakten Methoden und Funktionen zur Verwaltung und Bearbeitung von Dateien definiert, möglich ist, diese Schnittstelle sehr universell einzusetzten und sich daher universelle Anwendungsmöglichkeiten im Bereich der Dateiverwaltung und -bearbeitung ergeben. Die vordefinierte Schnittstelle und ihre entsprechenden Klassen sind aufgrund ihrer maßgeschneiderten Methoden und Funktionen direkt zur Verwaltung und Bearbeitung von Dateisystem- Objekten verwendbar, ohne dass zusätzliche Treiber-Programme erstellt werden müssen.
Weiterhin beruht die Erfindung auf der Überlegung, dass es in einem abgeleiteten System von Klassen eines objektorientiert programmierten Computerprogramms vorteilhaft ist, in einer übergeordneten Klasse nur diejenigen Funktionen zu implementieren, die von mehreren oder sogar allen von ihr abgeleiteten Klassen benötigt werden. Beispielsweise enthält die abstrakte Dateisystem-Klasse Grundfunktionen, die von allen davon abgeleiteten Klassen gebraucht werden, wie z. B. das blockweise Kopieren von Daten oder das rekursive Kopieren und Löschen von Verzeichnissen, d. h. das Durchführen dieser Operationen im Verzeichnis und allen dazu gehörenden Unterverzeichnissen.
Die universelle Datei-System-Schnittstelle ermöglicht es ebenfalls, ein verkettetes bzw. hierarchisches Zusammenspiel von Klassen von Datei-Systemen zu ermöglichen, weil die universelle Schnittstelle alle von den Klassen implementierten Methoden als abstrakte Methoden beschreibt. Somit ist die Verwaltung des gesamten Dateisystems in einem Computernetzwerk sehr einfach möglich, auch wenn die Computer mit unterschiedlichen Betriebssystemen, d. h. in einem heterogenen Netzwerk, betrieben werden.
Durch die hierarchische bzw. verkettete Gliederung des Systems an Klassen ist Netzwerk sehr leicht erweiterbar, beispielsweise, wenn neue Geräte mit zu verwaltenden Dateien hinzukommen.
Das Dateisystem ist insbesondere in der Programmiersprache JAVA und somit betriebssystemunabhängig definiert und das systemunabhängige Schnittstellen-Programmodul ist insbesondere eine JAVA-Schnittstelle (JAVA file system interface). Die Erfindung ist daher insbesondere für JAVA File Systeme zur Datei/Verzeichnisverwaltung und -bearbeitung in einer offenen Netzwerkstruktur geeignet, die Computer mit verschiedenen Betriebssystemen enthält.
Die abstrakte Dateisystem-Klasse ist insbesondere eine Teilimplementierung der abstrakten Dateisystem-Schnittstelle und kann im Sinne einer objektorientierten Programmiersprache insbesondere Basis für weitere Ableitungen der Klasse sein. Die Erfindung ermöglicht es somit, an logischen Dateisystemen Verwaltungsoperationen einschließlich des Lesens und des Schreibens von Dateien durchzuführen, indem im Computernetzwerk mittels einer einheitlichen Schnittstelle eine hierarchische und/oder verkettete Zuweisung von abstrakten Dateisystemen erfolgt. Dabei werden zumindest in der bezüglich einem Bediener obersten bzw. ersten Schnittstelle eine grafische Bedienoberfläche zur Datei-Anzeige und/oder zur Eingabe gewünschter Dateioperationen vorgesehen. In der untersten bzw. letzten Schnittstelle erfolgt demgegenüber ein Zugriff auf das dem abstrakten Dateisystem zugeordnete physikalische Dateisystem.
Ein Benutzer eines erfindungsgemäßen Datei-Systems (file systems) wird insbesondere nur mit den Funktionen und Methoden der Dateisystem-Schnittstelle konfrontiert, aber nicht mit der Struktur der miteinander verketteten Schnittstellen. Mittels der verketteten Schnittstellen und der abstrakten Datei- System-Klasse (abstract file system class) werden die an einem physikalischen Datei-System durchgeführten Operationen im obersten bzw. ersten Interface dem Bediener zugänglich gemacht. Dabei können die physikalischen Datei-Systeme auf unterschiedlichste Art ausgebildet sein, z. B. als Remote- Dateien, als Plattenlaufwerke, als CACHE-Speicher, als Archivspeicher wie z. B. CD-ROMS oder Magnetbänder usw..
Vorzugsweise werden von der abstrakten Dateisystem-Klasse (Abstract File System Class) weitere Klassen von Dateisystemen (File Systems) abgeleitet, die die Funktionalität des abstrakten Dateisystems ergänzen und die ebenfalls mit der Dateisystem-Schnittstelle (File System Interface) kommunizieren können. Derartige, von der abstrakten Klasse abgeleiteten Klassen von Dateisystemen sind insbesondere

- ein Remote-File-System, das einen Zugriff auf Dateien auf einen anderen Computer erlaubt,
- ein Mirror-File-System, das mehrere Verzeichnisse und darin vorgesehene Dateien auf unterschiedlichen physikalischen und/oder logischen Einheiten synchron hält (spiegelt) und/oder
- ein Delegate-File-System, das mehrere Dateisysteme und Dateifunktionsaufrufe in Abhängigkeit vom jeweiligen Pfad der entsprechenden Datei an diese File-Systeme verwaltet.

Durch das Vorsehen mehrerer Klassen von logischen Dateisystemen, auf die die Datei-System-Schnittstelle zum Zwecke der Kommunikation mit anderen logischen Dateisystemen jeweils aufsetzbar ist, kann das erfindungsgemäße Dateisystem einfach realisiert werden. Bei einer Realisierung in JAVA wird insbesondere die recht unabhängige Plattform für einzelne JAVA- Anwendungen beibehalten, obwohl ein erfindungsgemäßes JAVA Dateisystem auf unterschiedlichen Computersystemen und Netzwerksystemen installierbar ist.
Die Methoden und Funktionen der einzelnen Dateisystem-Klassen werden in die entsprechenden Funktions-Aufrufe der physikalischen Dateisysteme umgesetzt, zum Beispiel in einem bestimmten Computer bzw. Betriebssystem, in einem Bandlaufwerk oder in einem anderen bekannten logischen oder physikalischen Dateisystem wie zum Beispiel in einem FTP (File Transfer Protocol)-System, in einem Tar (Tape Archive)-System in einer Unix- oder Linux-Systemumgebung oder in einem System mit Zip- Dateien (Dateien, die nach dem Algorithmus von Phil Katz komprimiert sind) umgesetzt.
Die Dateisystem-Schnittstelle (File System Interface) definiert nur den Namen der jeweiligen Methoden, mit welchen auf die einzelnen Dateisysteme zugegriffen wird, mit deren Eingangs-Parameter und den entsprechenden Rückgabewerten. Hierdurch wird das erfindungsgemäße Dateisystem plattform- und implementierungsunabhängig.
Ein erfindungsgemäßes Programm-System kann besonders vorteilhaft in Drucksystemen angewandt werden, bei denen diverse Geräte wie Anwendungscomputer, Host-Computer, Druckauftrags- Bearbeitungs-Computer (Druckserver), Träger variabler und statischer Druckdaten insbesondere innerhalb eines AFP- Druckdatennetzwerkes (AFP steht für Advanced Function Presentation Data Stream) und/oder Archivierungscomputer über ein Computernetzwerk verteilt ausgebildet sind.
Durch die Erfindung ist es möglich, in einem beliebig erweiterbaren Computernetzwerk mit einer einzigen Anzeige- und Bedienungsoberfläche, verschiedene FileSystem-Implementierungen anzuzeigen und zu bedienen. Ein Dateisystem ist dabei insbesondere auch um die Fähigkeit des Remotezugriffs oder der Spiegelung erweiterbar. Verschiedene Dateisysteme sind beliebig kombinierbar und eine Auswahl kann nach Pfadnamen erfolgen. Über eine Socketschnittstelle können auch Nicht-Java- Programme auf alle Dateisysteme des Systems zugreifen.
Insbesondere kann zum Beispiel mit einem erfindungsgemäßen Dateisystem, in dem ein oder mehrere Delegate-File-Systeme implementiert sind, auf eine prinzipiell beliebige Zahl weiterer Dateisysteme zugegriffen werden.
Ist in einem erfindungsgemäßen Dateisystem ein Mirror-File- System implementiert, so sind diesem Dateisystem zumindest zwei weitere logische und/oder physikalische Dateisysteme unterzuordnen, auf welchen die einzelnen Verzeichnisse und/oder Dateien synchron gehalten werden.
Nachfolgend werden weitere Aspekte und Ausführungsformen der Erfindung beschrieben, aus denen zusätzliche Vorteile der Erfindung deutlich werden.
Es zeigen:
Fig. 1 Ein Druckproduktionssystem,
Fig. 2 Eine Systemstruktur mit einem JAVA File System Interface,
Fig. 3 Eine Systemstruktur für ein Remote File System Interface und
Fig. 4 Eine grafische Benutzeroberfläche für ein JAVA File System Interface.
In Fig. 1 ist ein Hochleistungsdrucksystem 1 gezeigt, bei welchem verschiedene System-Komponenten über ein Datennetzwerk 2, welches ein lokales Netz (Local Area Network, LAN) oder auch ein größeres Netzwerk (Wide Area Network, WAN, Internet) sein kann. An dem Netzwerk 2 hängt mindestens ein Client-Terminal 3, auf welchem Druckaufträge erzeugt werden können. Das Terminal 3 ist ein an sich bekannter Computer, z. B. ein Personal Computer PC mit einem Betriebssystem wie z. B. Microsoft Windows, Windows NT, Linux oder dergleichen, mit angeschlossenem Bildschirm 3a.
Die Druckaufträge können wahlweise auch auf einem Hauptcomputer (Main Frame) 4 erzeugt oder zumindest Daten von dem Main Frame 4 in den Druckauftrag eingefügt werden. Der Main Frame 4 des Rechenzentrums wird über eine geeignete Betriebssystem- Steuerung wie MVS, BS2000 oder VSE gesteuert. Am Main Frame 4 können Steuerungsfunktionen und Anzeigen über den daran angeschlossenen Bildschirm 4a erfolgen. An den Hauptcomputer 4 (Main Frame) ist außerdem ein Bandlesegerät 5 sowie ein erster Hochleistungsdrucker 6 direkt angeschlossen.
Am Datennetzwerk 2 sind außerdem ein zweiter Drucker 7, ein Druckserver 8 sowie ein Archivserver 9 angeschlossen. Der Druckserver 8 wiederum ist mit einem zweiten Bandlesegerät 10 sowie einem Bildschirm 11 verbunden. Zusätzlich zur Verbindung 11 zwischen dem Druckserver 8 und dem Haupt-Datennetzwerk 2 ist der Druckserver 8 über die Verbindung 12 mit einem zweiten, lokalen Netzwerk 15 verbunden, an dem weitere Drucker 13, 14 angeschlossen sind. Der Druckserver 8 sowie der Drucker 14 können optional mit einer Anlage zur Produktion von Archivspeichern (CD-ROM) 16 verbunden werden. Die Archivanlage 16 hängt jedoch hauptsächlich am Archivserver 9. Zusätzliche Bildschirme 9a, 16a und 14a sind mit den jeweiligen Geräten 9, 16 und 14 verbunden.
Zum Erstellen eines Druckauftrages im Datenformat AFP, beispielsweise am Client-Computer 3 oder am Druckserver 8, ist es erforderlich, auf entsprechende Resource-Daten zuzugreifen. Diese Resource-Daten können dabei unter Umständen an einem anderen Computer gespeicher sein, beispielsweise im Host- Computer 4, auf dem ein anderes Betriebssystem installiert ist als auf dem Client-Computer 3 bzw. dem Druckserver 8. Es ist deshalb erfoderlich, ein geeignetes Hilfsmittel zur Verfügung zu haben, mit dem Betriebssystem-unabhängig auf dateien zugegriffen werden kann. Dazu dient das JAVA File System Interface 20, welches in Fig. 2 gezeigt ist.
Bei der in Fig. 2 gezeigten Systemstruktur ist ein Client 20 mit einem Master 21 verbunden, an dem wiederum verschiedene Subsysteme (Slaves) 22, 23 und 24 angekoppelt sind. Innerhalb des Client-Computers 20 ist ein Anzeigemodul für Dateiverzeichnisse (Directory View User Interface) 25 vorgesehen, an dem der Benutzer auf alte Dateien des gezeigten Systems, d. h., auf lokale Client-Dateien, auch Dateien im Master- System 21 und auf die Dateien der Slave 22, 23 und 24 zumindest in Form einer Verzeichnisanzeige zugreifen kann. Die grafische Benutzerschnittstelle 25 ist dazu an die in JAVA programmierte, universelle Schnittstelle 26 angeschlossen. Die JAVA-Schnittstelle 26 definiert ein abstraktes Dateisystem und ist keine Implementierung eines echten Dateisystems. Es ist daher auf einer solchen Implementierung nur "aufgesetzt", so dass die Impementierung auf die Schnittstelle zugreifen kann bzw. diese zur Steuerung der Kommunikation mit anderen Implementierungen lesen kann. Das Interface 26 ist beispielsweise auf dem Delegate File System 27 aufgesetzt, mit dem mehrere daran wiederum angeschlossene File Systeme 28, 29 und 30 verwaltet werden können.
Im JAVA-Interface 26 sind typische Dateiverwaltungs- und Bearbeitungsfunktionen definiert, beispielsweise das Kopieren, Umbenennen und Löschen von Dateien und Dateiverzeichnissen, die Abfrage des Inhaltes eines Dateiverzeichnisses, die Abfrage und Änderung von Datei- bzw. Verzeichniseigenschaften wie Größe, Erstellungs- und Änderungsdatum usw. sowie das Lesen und Schreiben von Dateien, die Erzeugung neuer Dateien und Verzeichnisse oder auch ein Ereignismechanismus zum Reagieren auf Änderungen. Weitere, typische Datei- bzw. Verzeichnisverwaltungseigenschaften können vorgesehen sein. Das abstrakte Dateisystem implementiert das JAVA-Interface 26 nur teilweise, ist aber Basis zur Ableitung der weiteren Implementierungen wie das Remote File System 28 und das Local File System 30.
Das JAVA File System 26 ist in identischer Form auch auf das Remote File System 28, auf das Remote File System 29 und auf das Local File System 30 aufgesetzt. Es bildet somit die plattform- und betriebssystemunabhängige Verbindungsstelle zwischen den verschiedenen Implementierungen 27, 28, 29 und 30. Mit der Implementierung Local File System 30 kann auf die im Client-Computer 20 lokal gespeicherten Dateien zugegriffen werden. Es implementiert alle im JAVA File System definierten Funktionen und Methoden zur Anwendung auf die physikalischen Dateien, die auf einem lokalen Speicher, z. B. auf einer Festplatte, gespeichert sind. Über das erste Remote File System 28 kann auf Dateien des Master-Computers 21 zugegriffen werden, die in einer sog. Print File Library enthalten sind. Das Remote File System 28 ist dazu mit dem Computerprogrammmodul "Remote File System Server Impl" 31 nach Art einer Sende- und Empfangsschnittstelle verbunden, so dass die im Interface 26a definierten Funktionen auch auf den Verzeichnissen bzw. Dateien der Server-Bibliothek (Print File Library) ausgeführt werden können. Eine entsprechende Verbindung besteht auch zwischen dem zweiten Remote File System 29 und der Resource Server Implementierung 32. Diese Implementierung ist über das JAVA File System 26d wiederum mit einem Delegate File System 33 verbunden, an dem wiederum mehrere Implementierungen, nämlich die beiden Mirror File System Implementierungen 34 und 35 über die entsprechenden JAVA File System Interfaces 26e und 26f verbunden sind. Zusätzlich kann das Delegate File System 33 über die JAVA File Systemstelle 26g auch Methoden und Funktionen an das Local File System 36 des Master-Computers 21 deligieren.
Das Mirror File System 34 ist wiederum über die beiden JAVA File System-Schnittstellen 26k und 26j mit Remote File Systemen 38, 39 verbunden. Das Remote File System 39 greift wiederum über die Remote File System Server Implementierung 40, die JAVA File Systemschnittstelle 261, auf das Local File System 41 zu, mit dem Handhabungs- und Verwaltungsoperationen der oben genannten Art im Slave-Computer 22 durchgeführt werden können. Dieselben Operationen können im Slave-Computer 23 über das Remote File System 38, die Remote File System Server Implementierung 42, das JAVA File System Interface 26 m und das Local File System 43 erfolgen, wobei das Mirror File System 34 jeweils dafür sorgt, dass die in den Slaves 22 und 23 abgespeicherten Daten identisch gespiegelt sind.
Die vom Mirror File System 35 identisch gespiegelt gehaltenen Dateien werden im Local File System 36 des Servers, über das Remote File System 37, die Remote File System Server Implementierung 44, das JAVA File System Interface 26n und das Local File System 45 im Slave Computer 24 und/oder über das Remote File System 38 und die daran angeschlossenen System- Programmmodule im Slave Computer 23 gespiegelt gehalten.
Die gesamte Systemstrukur zeigt, dass über das JAVA File System Interface 26 eine Verkettung der verschiedenen File Systeme dergestalt möglich ist, dass eine hierarchische Verkettung der Systemaufrufe erfolgt. An oberster Stelle der Hierarchie steht dabei das Delegate File System 27 mit dem angeschlossenen JAVA File System Interface 26 von welchem aus baumstrukturartig die Dateioperationen an praktisch beliebig viele andere Computer (Server und/oder Slaves) verteilt werden können. Die jeweils angeschlossenen Interfaces 26a, 26b usw. bis 26n sind dabei jeweils identisch zum JAVA File System Interface 26 ausgebildet. Dies hat neben der Plattformunabhängigkeit auch den Vorteil, das an jedem dieser Systeme ein Abgriff für eine grafische Benutzerfläche (GUI) möglich ist, wie im Client 20 anhand des Directory Viewer GUI 25 gezeigt.
Im Folgenden werden einige Klassen, die das JAVA File System Interface implementieren, auszugsweise mit einigen Java- Quellcodezeilen dargestellt.

Klasse AbstractFileSystem

Diese Klasse dient als Basis für weitere Ableitungen und enthält Grundfunktionalitäten wie das blockweise Kopieren von Daten vom InputStream zum OutputStream, Eventverteilung an registrierte Listener, rekursives Kopieren und Löschen von Verzeichnissen, rekursives Suchen in Verzeichnissen, Bearbeiten von Pfadnamen, usw. Eine Ableitung dieser Klasse muß alle abstrakten Methoden dieser Klasse (z. B. moveTree()) und alle hier nicht implementierten Methoden des Interfaces (z. B. is- Directory()) überschreiben.
Die Methode move() ruft die Methode moveTree() (die von einer Ableitung noch implementiert werden muß) und benachrichtigt danach alle Listener, daß die Quelldatei gelöscht und Zieldatei erzeugt wurde.

Klasse LocalFileSystem

Diese Klasse ist eine Implementierung für den Zugriff auf lokale Dateien. Es bildet die FileSystem-Methoden auf Methoden der in Java standardmäßig verfügbaren Dateizugriffsklassen java.io.File, java.io.FileInputStream und java.io.FileOutput- Stream ab. Da es von AbstractFileSystem abgeleitet ist, verfügt es über dessen Fähigkeiten und ist damit wesentlich leistungsfähiger als die Standard-Dateizugriffsmethoden von Java. Weiterhin bietet es die Möglichkeit logische Pfadnamen zu echten Pfaden zu mappen.
Die Methode getLocalFileObject () ist nicht Bestandteil des Interfaces, wird aber von anderen Methoden verwendet, um ein java.io.File Objekt zu erhalten. Sie löst zunächst ein evtl vorhandenes Mapping auf und erzeugt dann das gewünschte Objekt. Die list-Methode dient dazu, den Inhalt eines Verzeichnisses auszulesen. Die Methode isDirectory stellt fest, ob der angegebene Pfad ein Verzeichnis ist.
Mit der nachfolgenden Methode setAttributes kann man Attribute einer Datei oder eines Verzeichnisses ändern. Bei lokalen Dateien läßt sich nur das Datum setzen.

RemoteFileSystem

Diese Klasse ermöglicht den Zugriff auf ein FileSystem-Objekt 52, das in einem anderen Computer gespeichert ist. Wie in Fig. 3 dargestellt, erfolgt die Kommunikation über die Rechnergrenze 50 hinweg über das Java-eigene Netzwerkprotokoll RMI. Auf der Gegenseite muß dazu ein Server existieren, der das Interface RemoteFileSystemServer 51 implementiert.
Die Stub-Komponente 53 kapselt das RMI-Protokoll und tritt normalerweise nicht in Erscheinung. Das RemoteFileSystem 54 verhält sich gegenüber einem File System, das das RemoteFile- System 54 aufruft, so wie das FileSystem-Objekt 52 auf der Serverseite, indem es alle Aktionen dorthin delegiert. Für das RemoteFileSystem 54 wirkt wiederum die Stub-Komponente 53 so wie das serverseitige File-Objekt 52, d. h. es greift über das Interface RemoteFileSystemServer 51 auf das FileSystem- Objekt 52 zu.
Die list-Methode delegiert führt die list-Methode des Servers aus, der wiederum die list-Methode seines FileSystem-Objektes aufruft. Da beim Remoteaufruf ein Fehler auftreten kann, muß die RemoteException abgefangen und in eine FileSystemException umgewandelt werden.
Die nun folgende Klasse RemoteFileSystemServerImpl oder eine deren Ableitungen dient als Bindeglied zwischen dem Remote- FileSystem und dem FileSystem-Objekt, das angesprochen werden soll. Es implementiert ein eigenes Remote-Interface Remote- FileSystemServer (Datei RemoteFileSystemServer.java), das die Methode definiert, die das RemoteFileSystem auf dem Server aufrufen kann.
Der Server hat eine Variable vom Typ FileSystem, an die alle Aktionen des RemoteFileSystems delegiert werden.

private FileSystem filesystem;
Die list-Methode des Servers ruft die list-Methode des File- System-Objektes auf und gibt das Ergebnis an das RemoteFile- System auf der Clientseite zurück. Zuvor wird gepüft, ob der Benutzer des RemoteFileSystems Leserechte auf dem Server hat.
Zur Fehlerprotokollierung werden mögliche Exceptions (Fehler) abgefangen, protokolliert und wieder geworfen.
Weiterhin stellt RemoteFileSystemServerImpl eine Socketschnittstelle zur Verfügung, über die Nicht-Java-Programme auf dessen FileSystem zugreifen können.

DelegateFileSystem

Diese Klasse dient dazu, abhängig vom Pfadnamen, Aktionen and verschiedene FileSystem-Objekte zu delegieren. Damit lassen sich logische Pfade definieren, für die ganz bestimmte File- System-Objekte zuständig sind. Z. B gilt in der beschriebenen Systemumgebung der Pfad /$PFL/. ./. . als Pfad für eine Print File Library. Diese Print File Library wird über ein eigens dafür entwickeltes FileSystem-Objekt, das deren Eigenschaften, wie z. B. Versionierung von Dateien, implementiert, angesprochen.
Über das Interface PathSelector wird entschieden, ob ein FileSystem für einen gegebenen Pfad zuständig ist.
Mit addFileSystem() wird dem DelegateFile-System ein FileSystem-Objekt mit zugehörigem PathSelector zugefügt:
Die Methode findFileSystem findet zu einem angegebenen Pfad das zuständige FileSystem. Diese Methode wird über getFileSystem() von allen anderen Methoden aufgerufen, um eine Aktion weiter zu delegieren. Die Methode getFileSystem() ruft find- FileSystem() auf und wirft eine Exception, wenn diese kein zuständiges FileSystem gefunden hat.
Die Methode isDirectory ruft getFileSystem (und damit indirekt findFileSystem()) auf um das für den angegebenen Pfad zuständige FileSystem zu ermitteln und ruft dessen isDirectory() Methode auf.

MirrorFileSystem

Diese Klasse dient dazu, mehrere FileSystem-Objekte (z. B. Verzeichnisse auf verschiedenen Rechnern) synchron zu halten.

public class MirrorFileSystem implements FileSystem
{
private Map mirrors = new HashMap();
private FileSystem masterMirror;
Mit den Methoden addMirror und removeMirror werden gespiegelte FileSystem-Objekte zugefügt bzw. entfernt. Das erste zugefügte FileSystem wird der Master, der als Referenz dient.
Die Methode move() ruft für alle gespiegelten FileSystem- Objekte deren move-Methode auf, um eine Datei zu verschieben. Tritt bei einer dieser Aktionen ein Fehler auf, werden alle vorhergehenden Aktionen rückgänig gemacht, d. h. die Datei wieder in ihren ursprünglichen Namen umbenannt.
In Fig. 4 ist ein mit einem Applet generierter Bildschirmausdruck gezeigt, auf dem eine Maske 55 gezeigt ist, mit der das Bearbeiten und Verwalten von Dateien anhand einer grafischen Benutzer-Schnittstelle ermöglicht wird. Die Maske 55 zeigt im Feld 56 ein Verzeichnis an und erlaubt damit und mit den im Verzeichnis enthaltenen Dateien, die im Bereich 57 angezeigt werden, Bearbeitungs- und Verwaltungsoperationen. Im Feld 58 sind alle verfügbaren Rechner bzw. Verzeichnisse baumstrukturartig dargestellt.
Die Erfindung ist in einem wie in Fig. 1 beschriebenen Drucksystem vorteilhaft nutzbar, bei dem Druckdaten bzw. Drucksaufträge von einem Client-Computer abgesetzt und zu einem Master, der die Daten bzw. den Auftrag entgegennimmt, übertragen werden. Dabei können Resource-Daten, insbesondere von Druckaufträgen im Datenformat AFP, die auf einem vernetzten Computer gespeichert sind oder auf mehreren Vernetzten Computern synchron gehalten werden sollen, von Client- Rechnern aus verwaltet werden. Dazu ist es insbesondere vorteilhaft, wenn folgende Konfigurationen eingehalten werden:

- Für den Dateizugriff vom Master auf die Slaves wird auf jedem Slave ein Server vom Typ SlaveFileSystemServerImpl installiert. Dieser ist eine Ableitung der RemoteFileSystemServerImpl-Klasse und stellt sicher, daß er nicht illegalerweise von einem Client aus direkt benutzt wird
- Für den Zugriff von den Clients zum Master werden auf diesem mehrere Server vom Typ RemoteFileSystemServerImpl (z. B. ResourceServerImpl zur Resourcenverwaltung) installiert. Diese greifen über eine Kombination von DelegateFileSystem-, MirrorFileSystem- und RemoteFileSystem-Objekten auf das lokale und die Dateisysteme der Slaves zu.

Auf dem Client gibt es Viewer zum Anzeigen und Bearbeiten eines FileSystem-Objektes. Dem in Fig. 3 dargestellten Applet wird diesem Viewer ein DelegateFileSystem übergeben, der ein LocalFileSystem für lokalen Dateizugriff und mehrere Remote- FileSystem-Objekte für den Zugriff auf Serverdateien enthält.
Obwohl die Erfindung anhand der Programmiersprache JAVA erläutert wurde, kann sie auch mit anderen objektorientierten Programmiersprachen wie z. B. C⁺⁺ ausgeführt werden. Mit der Erfindung werden nicht nur Verfahren, Geräte und Computerprogramme angegeben, sondern auch Computerprogramm-Produkte wie Speichermedien (Disketten, CD-ROMs usw.), die beim Laden und Ablaufen des Computerprogramms in einem Computer einen erfindungsgemäßen Verfahrensablauf bewirken. Bezugszeichenliste 1 Drucksystem
2 Haupt-Datennetzwerk
3 Client-Terminal
3a zweiter Bildschirm
4 Hauptcomputer
4a erster Bildschirm
5 erstes Bandlesegerät
6 erster Drucker
7 zweiter Drucker
8 Druck-Server
8a dritter Bildschirm
9 Archiv-Server
10 zweites Bandlesegerät
11 erste Netzwerkverbindung
12 zweite Netzwerkverbindung
13 dritter Drucker
14 vierter Drucker
14a fünfter Bildschirm
15 zweites Netzwerk
16 CD-ROM Archiv
16a sechster Bildschirm
20 Client
21 Master
22 erster Slave
23 zweiter Slave
24 dritter Slave
25 Grafische Benutzerschnittstelle
26 JAVA File System-Interface
27 Delegate File System
28 erstes Remote File System
29 zweites Remote File System
30 Local File System im Client 20
31 Pint File Library Implementierung
32 Resource Server Implementierung
33 Delegate File System
34 erstes Mirror File System
35 zweites Mirror File System
36 Local Filesystem im Master 21
37 drittes Remote File System
38 viertes Remote File System
39 fünftes Remote File System
40 erste Slave File System Server Implementierung
42 zweite Slave File System Server Implementierung
44 dritte Slave File System Server Implementierung
41 Local File System des Slaves 22
43 Local File System des Slaves 23
45 Local File System des Slaves 24
50 Rechnergrenze
51 RemoteFileSystem Server
52 FileSystem-Objekt
53 Stub-Komponente
54 RemoteFileSystem-Modul
55 Maske
56 Pfad-Feld
57 Dateifeld
58 Rechnerfeld

Claims

1. Verfahren zum Verwalten und Bearbeiten von Computer- Dateien mittels eines in einer objektorientierten Programmiersprache erzeugten Computerprogramms, wobei
mit einem betriebssystemunabhängigen Schnittstellen- Programmodul (26, 26a. . .26n) Funktionen und Methoden zur Verwaltung und Bearbeitung von Dateien beschrieben werden und
eine abstrakte Dateisystem-Klasse (abstract file system class) gebildet wird, die zumindest einen Teil der Funktionen und Methoden des systemunabhängigen Schnittstellen- Programmoduls (26) implementiert, welche wiederum von davon abgeleiteten Implementierungen verwendet werden können.

2. Verfahren nach Anspruch 1, wobei das Schnittstellen- Programmodul (26, 26a. . .26n) in einem Computernetzwerk (1, 11, 12) an mehreren Stellen installiert wird, so dass ein hierarchischer und/oder verketteter Zugriff auf logische und/oder physikalische Dateien ermöglicht wird.

3. Verfahren nach Anspruch 2, wobei das Schnittstellen- Programmodul (26a. . .26n) jeweils auf Implementierungen (27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40) aufgesetzt wird, durch die die Funktionalität des abstrakten Dateisystems erweitert wird.

4. Verfahren nach einem der vorhergehenden Ansprüche, wobei zur Ergänzung der Funktionalität der abstrakten Dateisystem-Klasse von der abstrakten Dateisystem-Klasse mindestens eine weitere Dateisystem-Klasse abgeleitet wird.

5. Verfahren nach Anspruch 3, wobei auf der weiteren Dateisystem-Klasse zusätzlich das Schnittstellen-Programmodul aufgesetzt wird.

6. Verfahren nach Anspruch 4 oder 5, wobei als weitere Dateisystem-Klasse
ein Remote-File-System, das einen Zugriff auf Dateien auf einen anderen Computer erlaubt,
ein Mirror-File-System, das mehrere Verzeichnisse und darin vorgesehene Dateien synchron auf verschiedenen phylogischen oder physikalischen Einheiten verwaltet und/oder
ein Delegate-File-System, das mehrere Dateisysteme verwaltet und Dateifunktionsaufrufe in Abhängigkeit vom jeweiligen Pfad der entsprechenden Datei an diese Dateisysteme verwaltet
vorgesehen wird.

7. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Schnittstellen-Programmodul nur den Namen von Methoden definiert, mit welchen auf abstrakte und/oder physikalische Dateisysteme zugegriffen wird, mit deren Eingabe- und Rückgabewerten.

8. Verfahren zum Verwalten und Bearbeiten von Dateistrukturen (Verzeichnisse und Dateien) in einem Computernetzwerk mittels Programm-Modulen, die aus einer objektorientierten Programmiersprache erzeugt sind, wobei
eine Vielzahl von Dateiverwaltungs-Programm-Modulen jeweils einen Dateibereich verwalten,
die Dateiverwaltungs-Programm-Module jeweils mit einem einheitlichen Schnittstellen-Programm-Modul (JAVA FileSystem Interface) zusammenwirken, das abstrakte Funktionen und/oder Methoden zur Verwaltung und/oder Bearbeitung von Dateistrukturen definiert und
die Dateiverwaltungs-Programm-Module jeweils eine oder mehrere Implementierungen der abstrakten Methoden und/oder Funktionen enthalten.

9. Verfahren nach Anspruch 8, wobei die Dateiverwaltungs- Programm-Module derart hierarchisch verbunden werden, dass jeweils ein übergeordnetes Dateiverwaltungs-Programm-Modul an mindestens ein untergeordnetes Dateiverwaltungs- Programm-Modul Abfragebefehle und/oder Zugriffsbefehle zum zugeordneten Dateibereich erteilt.

10. Verfahren nach Anspruch 8 oder 9, wobei das einheitliche Schnittstellen-Programm-Modul jeweils derart auf ein untergeordnetes Dateiverwaltungs-Programm-Modul aufgesetzt ist, dass dessen Kommunikation mit einem übergeordneten Dateiverwaltungs-Programm-Modul über das Schnittstellen- Programm-Modul erfolgt.

11. Verfahren nach einem der Ansprüche 8 bis 10, wobei am hierarchisch obersten Dateiverwaltungs-Programm-Modul ebenfalls das Schnittstellen-Programm-Modul aufgesetzt ist und wobei darüber mit einem grafischen Benutzerschnittstellen-Programm-Modul kommuniziert wird.

12. Verfahren nach einem der Ansprüche 8 bis 11, wobei das einheitliche Schnittstellen-Programm-Modul eine Klasse im Sinne der objektorientierten Programmiersprache ist und wobei die Implementierungen jeweils als Ableitung [vererbte Klassen] aus dem einheitlichen Schnittstellen-Programm- Modul erzeugt werden.

13. Computerprogramm-Modul erzeugt aus einer objektorientierten Programmiersprache zur betriebssystemunabhängigen Verwaltung und/oder Bearbeitung mindestens eines Dateisystems (file system), umfassend
ein systemunabhängiges Schnittstellen-Programmodul, das Funktionen und Methoden zur Handhabung und Verwaltung von Dateien beschreibt und
eine abstrakte Dateisystem-Klasse (abstract file system class), die zumindest einen Teil der Funktionen und Methoden des systemunabhängigen Schnittstellen-Programmoduls implementiert, welche wiederum von abgeleiteten Implementierungen verwendet werden können.

14. Computerprogramm-Modul nach Anspruch 13, dadurch gekennzeichnet, dass es aus der Programmiersprache JAVA erzeugt ist.

15. Computerprogramm-Modul nach Anspruch 13 oder 14, wobei zur Ergänzung der Funktionalität der abstrakten Dateisystem- Klasse mindestens eine weitere Dateisystem-Klasse vorgesehen ist.

16. Computerprogramm-Modul nach Anspruch 15, wobei die weitere Dateisystem-Klasse eine Ableitung der abstrakten Dateisystem-Klasse ist.

17. Computerprogramm-Modul nach einem der Ansprüche 13 bis 16, wobei auf der weiteren Dateisystem-Klasse zusätzlich das Schnittstellen-Programmodul aufgesetzt wird.

18. Computerprogramm-Modul nach einem der Ansprüche 13 bis 17, wobei als weitere Dateisystem-Klasse
ein Remote-File-System, das einen Zugriff auf Dateien auf einen anderen Computer erlaubt,
ein Mirror-File-System, das mehrere Verzeichnisse und darin vorgesehene Dateien synchron auf verschiedenen phylogischen oder physikalischen Einheiten verwaltet und/oder
ein Delegate-File-System, das mehrere Dateisysteme verwaltet und Dateifunktionsaufrufe in Abhängigkeit vom jeweiligen Pfad der entsprechenden Datei an diese Dateisysteme verwaltet
vorgesehen wird.

19. Computer-Programmodul zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 12.

20. Vorrichtung zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 12.

21. Computer, dadurch gekennzeichnet, dass ein Computer- Programmodul nach einem der Ansprüche 13 bis 18 installiert ist.

22. Computer-Netzwerk in dem Computer und/oder Computerprogramm-Module vorgesehen sind, mit denen ein Verfahren nach einem der Ansprüche 1 bis 12 durchführbar sind.