DE69637436T2

DE69637436T2 - Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen

Info

Publication number: DE69637436T2
Application number: DE69637436T
Authority: DE
Inventors: Stephen R. Menlo Park Savitzky; Rithy K. Menlo Park Roth; Tina L. Menlo Park Jeng; Peter E. Menlo Park Hart; Richard Menlo Park Golding
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 1995-07-19
Filing date: 1996-07-17
Publication date: 2009-03-05
Anticipated expiration: 2016-07-18
Also published as: DE69637436D1; JPH0950416A; EP0755006B1; JP2006294046A; US6438617B1; EP0755006A3; US5918051A; EP0755006A2

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich im Allgemeinen auf den Bereich der Service-Tools für entfernte Geräte (Maschinen). Im Besonderen betrifft die vorliegende Erfindung die Kommunikation zwischen Serviceanwendungsprogrammen in Computersystemen und entfernten Vorrichtungen, z. B. entfernten Geräten, sowie externen Daten in Dateien, Datenbanken und Programmen.
Objektorientiertes Programmieren
Ein Verständnis für objektorientiertes Programmieren und objektorientierte Anwendungs-Frameworks hilft dabei, die vorliegende Erfindung in vollem Umfang zu begreifen. Wie für Fachleute auf diesem Gebiet selbstverständlich, stellt ein „Objekt" eine Abstraktion einer Realwelt-Entität dar und ist als Kombination aus einer Datenstruktur (deren Felder als „Attribute" oder „Daten-Members" bezeichnet werden) und einer Gruppe von Operationen („Methoden” oder „Member-Funktionen") implementiert, die an ihm durchführbar sind. Bei einer „Klasse" handelt es sich um einen Datentyp für eine Gruppe von Objekten, die jeweils die gleiche Datenstruktur und die gleichen Operationen aufweisen. Eine „Instanz" einer Klasse ist ein Objekt, dessen Datentyp die Klasse ist, wie tatsächlich im Speicher eines laufenden Anwendungsprogramm verkörpert.
Klassen werden in eine oder mehrere (Kompilierzeit-)Hierarchien gruppiert, und zwar auf Grundlage von „Vererbung", die es ermöglicht, dass die Schnittstelle (d. h. die Namen und Typen der Attribute und Methoden) einer „Subklasse" in Bezug auf ihre Unterschiede gegenüber der Schnittstelle einer oder mehrerer „Superklassen" spezifiziert wird. Instanzen können durch „Containment" in eine oder mehrere (Laufzeit-)Hierarchien gruppiert werden; ein Objekt, das eine Mehrzahl anderer Objekte enthält, wird „Container" oder „Sammlung" genannt. Weitere Informationen über Konzepte des objektorientierten Programmierens sind zu finden in: „The Annotated C++ Reference Manual" von Margaret A. Ellis und Bjarne Stroustrup, Addison Wesley c, 1990.
Ein „objektorientiertes Anwendungs-Framework" besteht aus einer Bibliothek von Klassen, die so entworfen sind, dass sie vom Anmeldungsprogrammierer erweitert und in Subklassen eingeteilt werden können, und zwar in einem Paket mit mehreren veranschaulichenden Sample-Anwendungen, welche diese Klassen nutzen und so gestaltet sind, dass sie sich vom Anwendungsprogrammierer modifizieren lassen. Die Sample-Anwendungen bilden gewöhnlich ein System, das in sich selbst nützlich ist. Gemeinhin ist Fachleuten auf diesem Gebiet das Konzept, das einem Framework zugrunde liegt. Einige Beispiele für Frameworks sind X Toolkit, Motif Toolkit, Smalltalk Model-View-Controller GUT und MacApp.
Fernserviceanwendung
Bei einer „Anwendung" handelt es sich um ein Programm oder eine Gruppe zusammenarbeitender Programme, die einen Benutzer eines Computersystems in die Lage versetzen, eine beliebige Aufgabe oder Gruppe von Aufgaben auszuführen.
Fernserviceanwendungen sind Anwendungen, die einem Computerbenutzer die Kommunikation mit und die Durchführung von Services (Operationen) auf Geräten (entfernten Geräten) gestatten, die vom Computersystem des Benutzers getrennt sind und sich möglicherweise an einem entfernten Ort, d. h. außer Haus, befinden. Zu den Beispielen für entfernte Geräte bzw. Einrichtungen zählen Bürogeräte, etwa Kopiergeräte, Faxgeräte und Telefonsysteme, sowie Software-Entitäten im Speicher irgendeines entfernten Computersystems, etwa eines Datei- oder Datenbankservers, etc.. Die typischen Aktionen, die mithilfe von Fernserviceanwendungen durchgeführt werden, umfassen das Ferndiagnostizieren von Problemen eines entfernten Geräts, das Überwachen der Benutzung des entfernten Geräts, das Aktivieren/Deaktivieren von Merkmalen des entfernten Geräts, das Abrufen von Daten, das Verändern von Parametern, etc..
Des Weiteren unterstützt die vorliegende Erfindung Anwendungen, die in Kommunikation stehen mit und Operationen durchführen auf Software-Entitäten, wie z. B. Dateien und Prozesse, die im selben Computersystem enthalten sind wie das Anwendungsprogramm; wir werden den Begriff „entferntes Gerät" mit dem Verständnis gebrauchen, dass es auch Prozesse und Dateien umfassen kann, die sich zwar im Gerät des Benutzers, aber außerhalb des Speichers und Prozesses befinden, die vom Fernserviceanwendungsprogramm gesteuert werden.
Um auf ein entferntes Gerät zuzugreifen, nutzt die Fernserviceanwendung einen „Einrichtungstreiber", der zu irgendeiner Schnittstelleneinrichtung, etwa einem Modem, gehört, und einen „Protokolltreiber", der die Daten formatiert, die zum entfernten Gerät gesendet und aus diesem empfangen werden. Diese Treiber können Teil des Betriebssystems sein oder Module innerhalb des Anwendungsprogramms darstellen.
In der Vergangenheit waren Fernserviceanwendungen an jeden Typ eines entfernten Geräts individuell angepasst. Beispielsweise kommunizierte eine erste Fernserviceanwendung nur mit Geräten, die ein bestimmtes Protokoll aufwiesen, wohingegen eine zweite Fernserviceanwendung nur mit Geräten kommunizierte, die ein anderes Protokoll aufwiesen. Ein Vorteil dieser angepassten Methode besteht darin, dass die Fernserviceanwendungen effizient sind, weil sie eng an die Architektur und Parameter des jeweiligen entfernten Geräts gekoppelt sind.
Ein Nachteil der individuell angepassten Fernserviceanwendungen liegt darin, dass jedes Softwaresystem häufig Funktionen und Daten beinhaltet, die üblicherweise benutzt und für jedes System dupliziert werden, wie z. B. Kundendatenbanken. Ein weiterer Nachteil ist, dass jedes Mal, wenn ein neuer Typ eines entfernten Geräts hergestellt wird, ein neues Softwaresystem geschaffen werden muss, um die einzigartigen Fähigkeiten des neuen Typs eines entfernten Geräts anzusprechen. Das Problem dabei ist, dass das Softwaresystem oft von der Pike auf gebaut wird; so ist die Entwicklungszykluszeit lang. Noch ein weiterer Nachteil besteht darin, dass individuell angepasste Methoden oftmals unflexibel sind. Ist ein Softwaresystem erst einmal on-line, erweist sich die Durchführung von Modifikationen aufgrund der zahlreichen Verzweigungen mit anderen Teilen des Softwaresystems als sehr schwer.
Demzufolge besteht die Notwendigkeit für eine Gruppe von Softwaremechanismen, durch die eine Fernserviceanwendung mit irgendeinem aus einer Mehrzahl entfernter Geräte kommunizieren und darauf Operationen durchführen kann, und für ein Verfahren zur Entwicklung dieser Fernserviceanwendungen, in denen die oben dargelegten Nachteile vermieden werden.
WO 95/17720 A bezieht sich auf ein Verfahren und ein System, welches Services in einem objektorientierten System in Reaktion auf Abfragen zur Verfügung stellt. Ein Service wird als Beschreibung in Form eines Stapels von Servicebeschreibungen geleistet. Anhand der Stapelbeschreibungen werden die tatsächlichen Services durch Erzeuger-Objekte erzeugt.
Es ist eine Aufgabe der vorliegenden Erfindung, die Darstellung jedweden entfernten Geräts in einem Anwendungsprogramm zu verbessern, welches Dienste auf entfernten Geräten ausführt.
Diese Aufgabe wird erfüllt durch die Vorrichtung des Anspruchs 1 und das Verfahren des Anspruchs 17. Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen definiert.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung bezieht sich im Allgemeinen auf den Bereich der Service-Tools für entfernte Geräte. Im Besonderen betrifft die vorliegende Erfindung die Kommunikation zwischen Serviceanwendungsprogrammen in Computersystemen und ent fernten Vorrichtungen, z. B. entfernten Geräten, sowie externen Daten in Dateien, Datenbanken und Programmen.
Gemäß einer bevorzugten Ausführungsform der Erfindung umfasst eine Vorrichtung zum Kommunizieren mit einer Mehrzahl entfernter Geräte, aus einer Mehrzahl von Gerätetypen, ein Computersystem, einschließlich eines Prozessors und eines Speichers, eine Datenkommunikationseinrichtung, die an das Computersystem und die Mehrzahl entfernter Geräte gekoppelt ist, um mit jedem aus der Mehrzahl entfernter Geräte zu kommunizieren, und eine erste Mehrzahl von Softwareobjekten innerhalb des Speichers zur Beschreibung von Services für die Mehrzahl entfernter Geräte. Eine bevorzugte Ausführungsform umfasst ferner eine Mehrzahl von Operationen innerhalb des Speichers, die mit der ersten Mehrzahl von Softwareobjekten in Zusammenhang steht, wobei die Mehrzahl von Operationen zur Erfüllung von Requests dient, die von den Services der ersten Mehrzahl von Softwareobjekten beschrieben sind.
Gemäß einer weiteren Ausführungsform der Erfindung umfasst ein System zum Kommunizieren mit einer Mehrzahl entfernter Geräte aus einer Mehrzahl von Gerätetypen ein Computersystem, einschließlich eines Speichers und einer Massenspeichereinrichtung, eine Mehrzahl von Gerätebeschreibungsdateien innerhalb der Massenspeichereinrichtung, wobei die Mehrzahl von Gerätebeschreibungsdateien die Mehrzahl entfernter Geräte beschreibt, und eine Mehrzahl von Anwendungsprogrammen innerhalb des Speichers, wobei jedes aus der Mehrzahl von Anwendungsprogrammen zum Lesen von Darstellungen einer Mehrzahl von Softwareobjekten und zum Stellen und Erfüllen von Requests dient, die durch Services der Mehrzahl von Softwareobjekten beschrieben sind.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm eines Systems 110 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
2 veranschaulicht ein Blockdiagramm eines objektorientierten Anwendungs-Frameworks zur Verwendung in einer bevorzugten Ausführungsform der vorliegenden Erfindung;
3 veranschaulicht ein Blockdiagramm der Sample-Fernserviceanwendungsprogramme und Datendateien, die mit dem Framework zur Verwendung in einer bevorzugten Ausführungsform der vorliegenden Erfindung ausgestattet sind;
4 veranschaulicht in Bezug auf eine bevorzugte Ausführungsform der vorliegenden Erfindung die Darstellung der Komponente, der graphischen Benutzerschnittstelle, des Anwendungszustands, des Gerätemodells und der Warteschlangen-Objekte, die ein entferntes Gerät beschreiben;
5 veranschaulicht in Bezug auf eine bevorzugte Ausführungsform der vorliegenden Erfindung die Darstellung eines entfernten Faxgeräts und der entsprechenden Komponente, des entsprechenden Gerätemodells und der entsprechenden Anwendungszustandsobjekte sowie deren Verhältnis zu den im entfernten Gerät enthaltenen Daten;
6 veranschaulicht in Bezug auf eine bevorzugte Ausführungsform der vorliegenden Erfindung die Darstellung der Objekte, die erforderlich sind, um mit einem entfernten Gerät zu kommunizieren und auf diesem Operationen durchzuführen.
BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM
Übersicht
Eine bevorzugte Ausführungsform der vorliegenden Erfindung stellt einen Teil des objektorientierten Anwendungs-Frameworks REST („Ricoh Electronic Service Tool") dar, das gegenwärtig von der Ricoh Corporation, dem Abtretungsempfänger, entwickelt wird. Ein objektorientiertes Anwendungs-Framework („Framework") umfasst eine Klassenbibliothek, welche die Deklarationen und Implementierungen von Klassen von Objekten beinhaltet, und eine Mehrzahl von Sample-Anwendungsprogrammen, die unter Verwendung dieser Klassen geschrieben sind.
Ein Framework ist ein System, das einen Anwendungsprogrammierer in die Lage versetzt, neue Anwendungsprogramme in irgendeiner Anwendungs-Domain, z. B. jener der Fernserviceanwendungen (im Fall der vorliegenden Erfindung), schnell und problemlos zu schreiben. Insbesondere bearbeitet der Anwendungsprogrammierer zwecks Erstellung eines neuen Anwendungsprogramms typischerweise Sample-Anwendungsprogramme, die für ein bestimmtes entferntes Gerät geschrieben sind.
Die Objektklassen im Framework, welche Teil einer bevorzugten Ausführungsform der vorliegenden Erfindung sind, bilden, wenn sie als Softwareobjekte innerhalb des Speichers eines Computersystems instanziiert sind, einen Mechanismus und eine dazu gehörige Methode, die es ermöglicht, dass jedwedes Anwendungsprogramm, das unter ihrer Verwendung implementiert worden ist, mit einer Mehrzahl entfernter Geräte aus einer Mehrzahl verschiedener Typen kommuniziert.
Ferner stellen die Sample-Anwendungen ein System in sich dar, und zwar zur Durchführung einer beliebigen Gruppe von Aufgaben, z. B. Fernserviceaufgaben (im Fall der vorliegenden Erfindung).
Definitionen
Eine „Komponente" ist ein Softwareobjekt, das die Services und den Zustand irgendeines entfernten Geräts repräsentiert. Eine Komponente kann Subkomponenten auf weisen, z. B. kann ein Kopiergerät über eine Sortiereinrichtung und eine Zufuhreinrichtung verfügen, die an es angeschlossen sind.
Eine „Einrichtung" ist ein Computersystem eines Peripheriegeräts, das es ermöglicht, dass das Computersystem, in dem die Fernserviceanwendung läuft, mit einem oder mehreren entfernten Geräten kommuniziert.
Ein „Einrichtungstreiber" ist ein Softwareobjekt, das eine Schnittstelle zur Verfügung stellt, durch welche die Fernserviceanwendung mit einer Einrichtung kommuniziert.
Ein „Gerät" ist irgendeine Hardware- oder Software-Entität, die sich außerhalb des Computersystems befindet, in dem die Fernserviceanwendung läuft; d. h. ein entferntes Bürogerät, ein Dateiserver oder ein Datenbankserver.
Ein „Gerätemodell" ist ein Sammlungsobjekt, dessen Inhalt „Modell-Item"-Objekte sind, welche die von einer beliebigen Komponente bereitgestellten Services beschreiben.
Ein „Modell-Item" ist ein Objekt, das ein individuelles Service-Item beschreibt, das von irgendeinem entfernten Gerät zur Verfügung gestellt wird.
Ein „Service" ist eine beliebige Operation, die an oder von einer Komponente durchgeführt werden kann, einschließlich des Abrufens oder Aktualisierens von Daten, die in dieser Komponente enthalten sind.
Ein „Service-Item" ist eine abstrakte Klasse, die einen Service oder eine Gruppe von Services oder die gerade in einem Service enthaltenen Daten beschreibt.
Ein „Gerätezustand" ist ein Sammlungsobjekt, dessen Inhalt „Anwendungs-Item"-Objekte sind.
Ein „Anwendungs-Item" ist ein Objekt, das die Informationen enthält, welche die Fernserviceanwendung über irgendeinen Service hat, der vom entfernten Gerät zur Verfügung gestellt wird, einschließlich des gegenwärtigen Zustands (Daten) des Services im Gerät und jeglicher Veränderungen oder Operationen, die der Endbenutzer des Programms aufgerufen hat und die nicht durchgeführt worden sind.
Namenskonventionen
Beim Folgenden handelt es sich um eine Zusammenfassung der Namenskonventionen, die hierin und im beigefügten Software-Appendix verwendet werden. Die Namen von Klassen werden auch im Innern von Wortverbindungen groß geschrieben, um auf den Anfang ihres Namens hinzuweisen. Namen globaler Funktionen, Variablen und Klassen besitzen ein Präfix aus einem bis drei Buchstaben, das die allgemeine Familie angibt, zu der sie gehören. Beispielsweise haben die ein Service-Item beschreibende Datenstruktur und alle ihre Subklassen das Präfix „SI_". Bei Klassen, die von „R_Base" abstammen, ist das Präfix vom Rest des Namens durch Unterstrich getrennt; „R_Base" stellt die Basisklasse für Objekte dar, die in Sammlungen eingeordnet, in externe Dateien geschrieben und wieder aus diesen Dateien ausgelesen werden können.
Klassen- und Datentypen, deren Namen ein Unterstrich fehlt, sind gewöhnlich als Variablen, Funktionsargumente oder Klassendaten-Members instanziiert und werden durch Wert weitergegeben; Klassen, deren Namen einen Unterstrich enthalten, sind nahezu immer auf dem Heap instanziiert und werden als Referenzen oder Zeiger (Pointer) weitergegeben. Diese Konvention erlaubt es Fachleuten für objektorientiertes Programmieren, in der folgenden Erörterung mühelos Klassen von Instanzen und Instanzen von Referenzen oder Zeigern zu unterscheiden.
Die Namen globaler Funktionen, Konstanten und Variablen weisen ein Präfix aus Kleinbuchstaben auf.
Member-Funktionen und Daten-Members, welche Teil der öffentlichen Schnittstelle einer Klasse sind, beginnen mit einem Kleinbuchstaben. Geschützte Daten-Members besitzen einen Namen, der mit einem Unterstrich endet; üblicherweise ist eine öffentliche Member-Funktion vorhanden, um auf die Daten zuzugreifen; ihr Name ist der gleiche, der Unterstrich jedoch fehlt. Derartige Daten-Members werden „Attribute" genannt und mittels Makros deklariert, deren Namen mit „R_ATTR" beginnen.
Falls eine Member-Funktion vorhanden ist, die einen Wert aktualisiert, endet deren Name auf „Set"; die Aktualisierungsfunktion wird durch das gleiche Makro deklariert, welches auch das Attribut deklariert.
1. Systemübersicht
Bei 1 handelt es sich um ein Blockdiagramm eines Computersystems 1 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Das Computersystem 1 umfasst einen Anzeigemonitor 10, eine Tastatur 20, eine Maus 30 und einen Computer 2. Seinerseits umfasst der Computer 2 einen Prozessor 40, einen Speicher (z. B. ein Halbleiter-RAM) 50, eine Massenspeichereinrichtung (z. B. ein Plattenlaufwerk) 60, eine Kommunikationseinrichtung (z. B. ein Modem) 70 und ferner einen Systembus 80, der die obigen Komponenten untereinander verbindet. Die Maus 30 stellt nur ein Beispiel für eine graphische Eingabe- oder Zeigeeinrichtung dar. Ans System 1 gekoppelt ist ein entferntes Gerät 90 typischerweise über eine Kommunikationseinrichtung, etwa das Modem 70.
In einer bevorzugten Ausführungsform ist das System 1 ein Gerät, das auf einem 80486 Mikroprozessor basiert, auf dem Linux oder Windows 3.1 als Betriebssystem läuft, wobei Letzteres von der Microsoft Corporation stammt, und auf dem Fernserviceanwendungsprogramme laufen, die mittels des REST-Anwendungs-Frameworks entwickelt sind, das sich gegenwärtig bei der Ricoh Corporation in Entwicklung befindet. Eine bevorzugte Ausführungsform nachstehend beschriebener Klassen von Objekten im REST-Framework ist in C++ geschrieben.
1 stellt lediglich einen einzigen Systemtyp zur Ausführung der vorliegenden Erfindung dar. Jedoch ist für Fachleute auf diesem Gebiet sofort ersichtlich, dass sich viele Systemtypen und -konfigurationen für den Einsatz in Verbindung mit der vorliegenden Erfindung eignen.
Framework-Beschreibung
2 veranschaulicht ein Blockdiagramm eines objektorientierten Anwendungs-Frameworks, wie in einer bevorzugten Ausführungsform der vorliegenden Erfindung eingesetzt. Bei der Anwendungsschicht 140 handelt es sich um jenen Abschnitt des Systems, der besteht aus Anwendungsprogrammen, die ein Endbenutzer ablaufen lässt, einschließlich Remote-Setting 100 und Kundendatenbankzugriff 130, und aus Anwendungsprogrammen, die das Betriebssystem automatisch ablaufen lässt, einschließlich Call-out 110 und Call-in 120.
Die Kernschicht 190 besteht aus einer Bibliothek von Klassendeklarationen und -implementierungen, welche Funktionen bereitstellen, die von allen Fernserviceanwendungen gemeinsam genutzt werden, die sich in der Anwendungsschicht 140 des Frameworks befinden, einschließlich graphischer Benutzerschnittstellenfunktionen 150, allgemeiner Programmsystemfunktionen 160, Modellierung entfernter Geräte 170 und Kommunikation mit entfernten Geräten 180.
Die Schnittstellenschicht 260 enthält sowohl Klassen („Einrichtungstreiber"), die eine Schnittstelle zu spezifischen lokalen Kommunikationseinrichtungen, z. B. Modems, bereitstellen, Klassen („Protokolltreiber"), die eine Schnittstelle zu den Kommunikationsprotokollen bieten, die zum Kommunizieren mit spezifischen Familien entfernter Geräte (z. B. Kopiergeräten 200 und Faxgeräten 240) und zum Durchführen von Operationen auf denselben erforderlich sind, als auch Schnittstellen zu entfernten oder lokalen Datenbankservern 220 und Dateien 230, 240, 250 („Gerätebeschreibungsdateien"), welche Beschreibungen der Services enthalten, die von spezifischen Typen entfernter Geräte zur Verfügung gestellt werden. Die Anwendungsprogrammschnittstelle (API: Application Programming Interface) der Klassen in der Schnittstellenschicht 140 ist durch abstrakte Klassen in der Kernschicht 190 definiert; daher ist ein Anwendungsprogrammierer von den Einzelheiten spezifischer Schnittstelleneinrichtungen und entfernter Geräte isoliert.
Ein Anwendungsprogrammierer nutzt die Framework-Implementierungen von Fernserviceanwendungsprogrammen, und zwar typischerweise durch Gebrauch eines Text editors zum Kopieren und Modifizieren einer oder mehrerer der bestehenden Sample-Programme in der Anwendungsschicht 140. Anwendungen, die auf diese Art konstruiert sind, teilen sich eine gemeinsame erprobte Architektur und ein ebensolches Design sowie den großen Körper eines wiederverwendbaren Codes; die Eliminierung eines Großteils der Design- und Debugging-Phase aus dem Software-Lebenszyklus stellt einen Weg dar, bei dem die Verwendung eines objektorientierten Anwendungs-Frameworks die Implementierung von Fernserviceanwendungen beschleunigt.
Ein Programm, das die vorliegende Erfindung zur Kommunikation mit einem entfernten Gerät nutzt, kann mit nahezu jedem beliebigen entfernten Gerät kommunizieren.
Sample-Anwendungsprogramm und Dateibeschreibung
3 veranschaulicht einige der Sample-Anwendungsprogramme in der Anwendungsschicht 140 des Frameworks (2) und die Dateien, durch die sie Informationen mitteilen. Alle Anwendungsprogramme und Dateien befinden sich vorzugsweise in der Massenspeichereinrichtung 60 des Computersystems 1.
Der Benutzer interagiert direkt mit einer Kundendatenbankzugriffs-Anwendung 300, einer Job-Scheduler-Anwendung 370 und einer Remote-Setting-Anwendung 400. (Fachleuten auf diesem Gebiet ist es klar, dass viele andere interaktive Programme möglich sind; bei den hier angeführten Programmen handelt es sich lediglich um Anschauungsbeispiele).
Die Kundendatenbankzugriffs-Anwendung 300 erlaubt es dem Benutzer, eine Kundendatenbank 310 zwecks Auswahl von Geräten zur Kommunikation abzufragen; überdies gibt sie dem Kunden die Möglichkeit zur Auswahl von (jeweils in einer Gerätegruppendatei 350 beschriebenen) Gerätegruppen und (jeweils in einer Service-Item-Gruppendatei 340 beschriebenen) Gruppen von Service-Items, an denen Operationen vorgenommen werden. Die Kundendatenbankzugriffs-Anwendung 300 gibt eine Job-Item-Datei 320 und eine Falldatei 330 aus, die jeweils die Dateinamen der anderen Dateien enthalten, die in die Interaktion einbezogen sind.
Dann lässt der Benutzer die Job-Scheduler-Anwendung 370 ablaufen, welche die Job-Item-Dateien 320 liest und automatisch die Instanzen der Call-out-Anwendung 380 und der Remote-Setting-Anwendung 400 ablaufen lässt, um mit einem oder mehreren entfernten Geräten 90 zu kommunizieren. Das Ablaufen der Call-in-Anwendung 390 kann in Reaktion auf eine eintreffende Nachricht aus einem entfernten Gerät 90 zu jeder beliebigen Zeit veranlasst werden.
Die Call-in-Anwendung 390 und die Call-out-Anwendung 380 schreiben eine Datenauszugsdatei 410, die eine Kopie der Informationen enthält, die von einem entfernten Gerät 90 zur Call-in-Anwendung gesendet oder von der Call-out-Anwendung 380 aus einem entfernten Gerät 90 abgerufen werden. Zwecks Imports in eine Analysedatenbank 460 oder in anderes Anwendungsprogramm, wie z. B. ein Spreadsheet, wird die Datenauszugsdatei 410 von der Call-Übersetzer-Anwendung 440 entweder in eine Falldatei 420 oder eine Komma-limitierte Datei 450 übersetzt. Die Call-Übersetzer-Anwendung 440 nimmt ihre Umwandlungsoperation unter Verwendung einer Beschreibung des entfernten Geräts 90 vor, die in einer aus einer Mehrzahl von Gerätemodell-Dateien 430 enthalten ist.
Die Remote-Setting-Anwendung 400 wird für direkte Interaktionen zwischen einem Benutzer und irgendeinem entfernten Gerät 90 eingesetzt; die Operationen, die sich auf dem entfernten Gerät 90 durchführen lassen, sind in einer aus einer Mehrzahl von Gerätemodell-Dateien 350 beschrieben; die Zugangsinformationen (z. B. die Telefonnummer) für das entfernte Gerät 90 und einige der Operationen, die darauf durchzuführen sind, können in einer Falldatei 220 spezifiziert sein oder direkt vom Benutzer eingegeben werden.
2. Gerätemodellmodul
2.1. Übersicht
Das Gerätemodellmodul 170 in 2 stellt das Hauptmodul innerhalb der Kernschicht 190 dar. Die Aufgaben des Gerätemodellmoduls bestehen in der Beschreibung der Services, die auf entfernten Geräten für Fernserviceanwendungen in Form von Konfigurationen von Objekten, genannt Gerätemodelle, verfügbar sind, und darin, die Informationen zu enthalten und zu organisieren, die für das Anwendungsprogramm erforderlich sind, um die Übersicht über den gegenwärtigen Zustand des entfernten Geräts und jegliche Operationen und Datentransfers zu behalten, die vom Benutzer angefordert werden.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung bestehen die Geräte- und Serviceklassenhierarchien aus dem Folgenden (beachte: Einrückung kennzeichnet Vererbung):
2.2 Komponente und zugehörige Objekte
4 veranschaulicht eine typische Komponente 700 (Objektinstanz im Speicher 50 des Computersystems 1, die ein entferntes Gerät 90 repräsentiert) und die Objekte, auf die sie sich bezieht. Diese Objekte umfassen ihr „Zustands"-Attribut 600, ein SC_AppServices-Objekt, ihr „Modell"-Attribut 630, ein SC_ServiceModel-Objekt, ihre write-Queue- und readQueue-Attribute 670, die jeweils ein SC_Queue-Objekt sind, und ihr „Sitzungs"-Attribut 710, eine Referenz zu einer Instanz einer Subklasse der Klasse SI_CommunicationSession.
Ein SC_ServiceModel 630 ist eine Sammlung von „Modell-Items" 640, 650, wobei jedes Modell-Item eine Instanz einer Subklasse von SI_ModelItem darstellt. Kollektiv ist das SC_ServiceModel 630 eine Beschreibung der Services, die vom entfernten Gerät 90 zur Verfügung gestellt werden, das durch die Komponente 700 repräsentiert ist.
SC_AppServices 600 ist eine Sammlung von „Anwendungs-Items" 610, 620, wobei jedes Anwendungs-Item eine Instanz der Klasse SI_AppItem ist und eine Referenz zu einem entsprechenden SI_ModelItem 640, 650 und einer SI_CallbackList 520, 530 hat. Jedes Anwendungs-Item 610, 620 enthält Informationen über den gegenwärtigen Wert (falls bekannt) des entsprechenden Services im entfernten Gerät und über jedwede angeforderten Operationen oder Datentransfers, die diesen Service einschließen. Das SC_AppServices-Objekt 600 wird mittels der Operation „initServices" auf Klasse Sammlung 700 initialisiert; einer seiner Parameter ist ein optionaler Zeiger zu einer Funktion ausgehend von Pointer-to-SI_ModelItem zu Boolescher, die es ermöglicht, dass aus dem Gerätemodell 630 nur jene Services ausgewählt werden, die tatsächlich von der Anwendung benutzt werden.
Eine SI_CallbackList 520, 530 ist eine Sammlung von SI_GuiItem-Objekten 540, 550, 570, 580, 590, von denen sich jedes auf ein einziges Objekt bezieht, und vice versa nimmt ein einziges Objekt auf jedes von ihnen Bezug, welches „Control" in der graphischen Benutzerschnittstelle repräsentiert, welche Informationen anzeigt und mit welcher der Benutzer interagieren kann. Der Zweck von SI_GuiItem besteht darin zu gewährleisten, dass Veränderungen, die vom Benutzer mithilfe der graphischen Benutzerschnittstelle vorgenommen werden, äquivalente Veränderungen im entsprechenden SI_AppItem 610, 620 im Anwendungszustand 600 bewirken, und dass Veränderungen in einem SI_AppItem 610, 620 im Anwendungszustand 600, die aus der Operation des Programms resultieren und insbeson dere aus der Kommunikation mit dem entfernten Gerät, äquivalente Veränderungen bei den Informationen hervorrufen, die dem Benutzer mittels der graphischen Benutzerschnittstelle präsentiert werden.
Die Operation „newValueSet" der Klasse SI_AppItem wird eingesetzt, um eine Zustandsveränderung (Schreiboperation) im Service aufzurufen. Die Operation „readRequest" der Klasse SI_AppItem wird verwendet, um eine Leseoperation aufzurufen. Wird eine Lese- oder Schreiboperation aufgerufen, wird ein Objekt 680, 690 der Klasse SI_QueueItem konstruiert, das sich auf SI_AppItem 610, 620 bezieht und außerdem die angeforderten Operationen enthält, nämlich die Lese- oder Schreiboperation und, im Fall der Schreiboperation, die zu schreibenden Daten. Das SI_QueueItem wird entweder in eine Lesewarteschlange 670 oder eine Schreibwarteschlange eingeordnet, die an Komponente 700 angebunden sind. Diese Warteschlangen-Items häufen sich an, bis der Benutzer oder die Anwendung eine Batch-Kommunikationssitzung beim entfernten Gerät aufruft, wie in Verbindung mit dem Kommunikationsmodul weiter erläutert.
Bei Durchführung der Batch-Kommunikationssitzung wird das Attribut currentValue von jedem SI_AppItem aktualisiert, damit es den Wert widerspiegelt, der im entfernten Gerät gespeichert oder aus diesem abgerufen wird. Jedes SI_GuiItem 500, das zu den SI_AppItems 610, 620 gehört, wird als Nebeneffekt der „currentValueSet"-Operation automatisch von der Aktualisierung benachrichtigt.
Ein Komponenten-Objekt ist selbst ein Behälter für (nicht dargestellte) „Sub-Komponenten", die separat steuerbaren Geräten entsprechen, die an das entfernte Gerät angeschlossen sind. Beispielsweise kann es sich beim Top-Level Komponenten-Objekt 700 um einen Leitungsadapter-Multiplexer handeln, an den eine Mehrzahl von Kopiergeräten angeschlossen ist, die durch den Inhalt der Top-Level Komponente 700 repräsentiert sind.
5 veranschaulicht das Verhältnis zwischen dem Gerätemodell 860 (630 in 4), dem Anwendungszustand 810 (600 in 4) und dem entfernten Gerät 90. Für diese Veranschaulichung werden wir ein Faxgerät benutzen, das dem Ricoh-Modell FAX-60 ähnelt, bei dem die fernzugänglichen Services durch Daten repräsentiert sind, die in einem elektronisch löschbaren ROM 910 enthalten sind, aus dem Daten abgerufen oder in dem Daten modifiziert werden können, und zwar dadurch, dass dem Faxgerät 90 ein passend formatierter Aufruf vorgelegt wird, welcher Startadresse und Größe enthält. Für Fachleute auf diesem Gebiet ist problemlos ersichtlich, dass die Möglichkeit zur Verwendung anderer Protokolle besteht, die andere Wege zum Identifizieren der zu übermittelnden Daten und andere Codierungen für die Daten beinhalten.
Da das entfernte Faxgerät Service-Items in einem Speicher speichert, enthält das Gerätemodell 860 Objekte 870, 880, welche Instanzen der Klasse SI_MemoryItem sind, einer Subklasse von SI_RemoteItem, die ihrerseits eine Subklasse von SI_ServiceItem ist. Beispielsweise weist SI_MemoryItem 870 die Größe 3 in seinem "itemSize" Attribut auf, das einen String der Länge 3 spezifiziert. Der Datentyp „Chars" im SI_MemoryItem 870 ist im „valueDscr"-Attribut durch einen Zeiger zur Instanz einer Subklasse von Klasse R_ValueDscr repräsentiert.
Einige der fernzugänglichen Daten bestehen aus Bitfeldern, die innerhalb von Bytes im Speicher gespeichert sind; 5 zeigt zwei solcher Bitfelder 921, 922, die innerhalb eines Bytes 920 im Speicher 910 eines entfernten Faxgeräts 90 enthalten sind, wobei jedes von einer Instanz 890, 900 der Klasse SI_BitfieldItem repräsentiert wird, die beide innerhalb des SI_MemoryItem-Objekts 880 enthalten sind, welches das Byte 920 repräsentiert.
Jedes Service-Item, das sich durch das Fernserviceanwendungsprogramm beeinflussen lässt, weist einen gegenwärtigen Zustand innerhalb des Anwendungszustands 810 auf, der durch eine Instanz 820, 830, 840, 850 der Klasse SI_AppItem repräsentiert wird.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung besteht das Gerätemodel aus Instanzen von Subklassen von SI_ModelItem, welche die folgende Hierarchie besitzen (beachte: Einrückung kennzeichnet Vererbung):
Die abstrakte Klasse SI_ModelItem stellt eine abstrakte Programmierschnittstelle zur Durchführung von Zugriffs- und Aktualisierungsoperationen an einem Service-Item bereit, das sich auf einem entfernten Gerät befindet; die verschiedenen Subklassen von SI_ModelItem bieten Implementierungen dieser Operationen zum Umgang mit bestimmten Arten von Ferndaten unter Verwendung von Kommunikationsprotokollen, die für bestimmte entfernte Geräte spezifisch sind.
Das Einteilen in Subklassen schafft die Möglichkeit, dass das Verhalten von SI_MemoryItem-Objekten 870, 880 spezifisch für Fernservice-Items ist, die im Speicher eines entfernten Geräts gespeichert sind, und dass das Verhalten von SI_BitfieldItem-Objekten 890, 900 spezifisch für Bitfelder ist, die in einem Wort enthalten sind, das im Speicher eines entfernten Geräts gespeichert ist. Beispielsweise wird das „packedSize"-Attribut durch eine Funktion berechnet, die in einem SI_BitfieldItem einfach den Wert des „itemSize"-Attributs returnt, aber in einem SI_MemoryItem den Wert des „itemSize"-Atttributs multipliziert mit acht, also mit der Anzahl an Bits in einem Byte, returnt.
SI_InternalItem und SI_ExternalItem sind die beiden Haupt-Subklassen von SI_ModelItem. SI_InternalItem-Objekte beschreiben Daten, die mit dem entfernten Gerät in Zusammenhang stehen, aber sich innerhalb der Fernserviceanwendung befinden (beispielsweise die Seriennummer des Geräts, die möglicherweise nicht fernzugänglich, aber aus einer Kundendatenbank erhältlich ist). Wenn sich Daten außerhalb der Fernserviceanwendung befinden, wird eine Subklasse der SI_ExternalItem-Subklasse verwendet. Beispielsweise beschreibt SI_TableItem eine Tabelle in einem entfernten Datenbankserver, und SI_MemoryItem beschreibt ein Daten-Item im Speicher eines entfernten Faxgeräts.
Die Daten selbst, d. h. ihr Datentyp (Ganzzahl, Kardinalzahl, Float, String, etc.), ihre Größe, ihr Wertebereich und weitere Attribute, sind in einer Datenstruktur beschrieben, die als „Wertdeskriptor" (Klasse R_ValueDscr) bezeichnet wird. Diese Wertdeskriptoren sind ähnlich jenen, die in Sprachen wie Smalltalk gebraucht werden, Laufzeit-Klasse-Deskriptoren. Ein Zeiger zum Wertdeskriptor und der Defaultwert der Daten sind in einem Objekt der Klasse Rvalue kombiniert, welches das „defaultValue"-Attribut des SI_ModelItem-Objekts ist. Einige Attribute des Wertdeskriptors können nachrangig gegenüber entsprechenden Attributen von SI_ModelItem sein. Falls ein Wert eine Referenz zu einer Instanz irgendeines Objekts darstellt, werden sein Klassenname und seine öffentlich zugänglichen Attribute durch eine Instanz der Klasse R_ClassDscr beschrieben, die von der virtuellen Funktion „dscr" der Objektinstanz returnt wird.
Jedes SI_AppItem-Objekt 820, 830, 840, 850 im Anwendungszustand 810 speichert die Informationen, welche die Fernserviceanwendung über den gegenwärtigen Zustand des entfernten Geräts, den Zustand der Benutzerschnittstelle und das Verhältnis zwischen diesen besitzt. Jede Instanz von Klasse SI_AppItem 820, 830, 840, 850 weist ein Attribut „Model" auf, das eine Referenz zu einer einzigen Instanz von Klasse SI_ModelItem 870, 880, 890, 900 enthält, welche die zulässigen Zustände für dieses Item und seinen Ort oder seine Zugangsinformationen bezüglich des entfernten Geräts beschreibt. Ferner hat jedes SI_AppItem sowohl ein Attribut „currentValue", welches Informationen über den ge genwärtigen Zustand des Service-Items im entfernten Gerät enthält, auch als ein Attribut, „newValue", das einen angeforderten Aktualisierungszustand für das entfernte Item darstellt.
Compound-Daten
Wenn ein Service-Item im entfernten Gerät aus einer Compound-Datenstruktur, z. B. einem Array oder einer Struktur, besteht, wird es durch ein SI_ModelItem-Objekt beschrieben, das eine Sammlung aus einem oder mehreren untergeordneten SI_ModelItem-Objekten besitzt, die auch als seine „Kinder" bekannt sind. Ein SI_ModelItem, das einen Array repräsentiert, hat ein einziges Kind, das die Array-Item-Objekte beschreibt, und ein SI_ModelItem, das eine Struktur repräsentiert, hat ein separates Kind, das jedes Feld beschreibt. Das entsprechende SI_AppItem kann entweder ein SI_AppItem-Kind für jedes Sub-Item (Array-Element des Strukturfelds) oder andernfalls einen einzigen Compound-Wert haben, der sich auf einen Array von Sub-Item-Werten bezieht. Jedes SI_AppItem, das ein Array-Element repräsentiert, weist einen Wert in seinem „Location"-Attribut auf, der ein Index vom Anfang des Arrays ist. Der Anwendungsprogrammierer entscheidet, welche dieser beiden Darstellungen die zweckmäßigste für eine gegebene Anwendung ist. Beispielsweise enthält Ferndatenbyte 920 in 5, das durch SI_AppItem-Objekt 830 und SI_MemoryItem 880 beschrieben ist, Bitfelder, die durch SI_AppItem-Objekte 840 und 850 und SI_Bitfield-Objekte 890 und 900 beschrieben sind.
Ferngeräthistorie
Gegebenenfalls kann die Historie eines entfernten Geräts in einer (nicht dargestellten) Historiendatenbank gespeichert werden. Typen von Historiendaten beinhalten beispielsweise die Anzahl an Kopien, die jeden Monat auf einem Kopiergerät angefertigt werden, die vom Kunden gekauften Optionen, etc.. Um die Historie zu verfolgen, verfügt SI_AppItem über ein Attribut, nämlich „Historie", das auf ein weiteres SI_AppItem einer anderen Komponente hinweist. Bei der anderen Komponente handelt es sich typischerweise um eine Komponente, die eine Datenbank oder Datei beschreibt.
Der „currentValue" des Historie-Items spiegelt das wider, was bei Start der Anwendung über das Item bekannt ist (z. B. die Kopienzahl des Vormonats in einer Abrechnungsanwendung). Wenn eine Veränderung bei dem auftritt, was das System über das Item weiß, wird „currentValueSet" aufgerufen, um die Veränderung wiederzugeben, und mit dem gleichen Wert wird die „newValueSet"-Operation des Historie-Items aufgerufen. Bei einigen Anwendungen (z. B. Remote Setup) kann es von großem Nutzen sein, wenn sich der Wert eines Service-Items zu jenem Wert, den es beim Start des Programms hatte, zurückwandeln lässt, um auf wirkungsvolle Weise jegliche Veränderungen rückgängig zu machen, die von der Anwendung des Benutzers vorgenommen worden sind.
Definieren neuer Modell-Items
Wie zu entnehmen, ist der Anwendungsprogrammierer in der Lage, neue Subklassen für die Klasse SI_ModelItem rasch zu definieren, um neue Arten von Service-Items zu beschreiben, die von einem beliebigen neuen entfernten Gerät, einer Datenbank oder anderen externen Ressourcen zur Verfügung gestellt werden. Jedwede Anwendung, die mit einer Bibliothek verlinkt ist, die den Code für eine derartige Subklasse enthält, ist dazu fähig, die neuen Service-Items während der Laufzeit zu nutzen; derartige Anwendungen müssen nicht wieder kompiliert, sondern lediglich verlinkt werden. Durch Einordnen der neuen Klassen in eine dynamische Bibliothek (DLL: Dynamic Link Library) können zweckgemäß konstruierte Anwendungen neue Service-Items selbst nach Verlinkung und Verteilung an den Benutzer nutzen.
Initialisierung
Für Fachleute auf diesem Gebiet ist es ersichtlich, dass das Anwendungsprogramm in seinem Speicher sowohl eine Komponente als auch das Gerätemodell und den Anwendungszustand, die zu ihr gehören, konstruieren muss, um mit irgendeinem entfernten Gerät zu kommunizieren.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung kann dies durch Parsen einer oder mehrerer Dateien erfolgen, die eine Darstellung der zu konstruierenden Objektinstanzen in Text- oder Binärform enthalten, einschließlich der Namen ihrer Klassen, der Namen und Werte ihrer Attribute und der Darstellung der in jedem Sammlungsobjekt enthaltenen Objekte in Text- oder Binärform. Der daraus entstehende Parsebaum wird unter Verwendung der Konstruktoren für die verschiedenen Klassen erzeugt, die in der Datei dargestellt sind; seine Wurzel ist die erforderliche Komponenten-Objektinstanz 700, 800; sein „Model"-Attribut enthält das Gerätemodell 630, 860 und sein „Zustands"-Attribut enthält den Anwendungszustand 600, 810. Der Anwendungszustand kann entweder durch Parsen einer separaten Falldatei 330, 420 konstruiert oder mit Defaultwerten aus der Gerätemodelldatei 350, 430 konstruiert und initialisiert werden.
Einem Beispiel zufolge ruft das Anwendungsprogramm, wenn es mit einem Faxgerät kommunizieren muss, zunächst eine das Faxgerät beschreibende Gerätemodelldatei ab. Eine derartige Datei kann (bei partieller Darstellung) folgendermaßen aussehen:
Wie veranschaulicht, ist die Beschreibungsdatei eine Darstellung in Textform von einem SC_ServiceModel (Modell) für ein „K50"-Faxgerät. Instanzen von SI_MemoryItem sind einschließlich R17D4, R17D5 und R17D6 beschrieben. Virtuelle Funktionen innerhalb der entsprechenden Instanzen werden ausgeführt, um das spezifische Kommunikationsprotokoll abzuwickeln.
Einem weiteren Beispiel zufolge ruft das Anwendungsprogramm, falls es mit einem Kopiergerät kommunizieren muss, zunächst eine Datei ab, die das Kopiergerät beschreibt. Eine derartige Datei kann (bei partieller Darstellung) folgendermaßen aussehen:
Wie veranschaulicht, enthält die Beschreibungsdatei eine Darstellung in Textform von einem SC_ServiceModel (Modell) für ein „FT8780"-Kopiergerät. Instanzen von SI_CopierItem sind einschließlich LampThermistor, SC_ChargerLeak und FusingTempADJ beschrieben.
Eine Anwendung kann mit einer Mehrzahl entfernter Geräte dadurch kommunizieren, dass sowohl eine Mehrzahl von Komponenten-Objekten 700, 800 als auch dazu gehörende Gerätemodelle 630, 870 und Anwendungszustände 600, 810 in ihrem Speicher entweder der Reihe nach oder gleichzeitig geschaffen werden.
2.3. Beispielhafte Klassendeskriptoren
Der folgende C++-Code besteht aus Klassendeklarationen für eine erläuternde Subgruppe einer bevorzugten Ausführungsform der Gerätemodellklassen.
2.3.1. Service-Klasse
Die Service-Klasse stellt die allgemeine abstrakte Basisklasse für Service-Items und Service-Sammlungen dar.
2.3.2. SI_ServiceItem-Klasse
Die SI_ServiceItem-Klasse stellt eine einheitliche Schnittstelle für alle Service-Items zur Verfügung.
Wertbeschreibungsinformationen:
Die folgenden Funktionen werden normalerweise an einen Deskriptor delegiert, spezifischerweise an den Wertdeskriptor von defaultValue. Eine paar Funktionen, wie z. B. die Größen und valueList, können gegenüber Attributen in SI_ModelItem nachrangig behandelt werden.
2.3.3. SI_ModelItem-Klasse
Ein ModelItem ist Teil der Beschreibung eines Geräts, d. h. es ist das Programmmodell des Geräts. Es enthält keinerlei Informationen über den gegenwärtigen Zustand des Geräts, sondern nur darüber, wie jener Zustand zu erreichen ist und welche Werte zulässig sind. Grundsätzlich enthält ein ModelItem all das, was im Voraus über ein Item bekannt sein kann, ohne dass tatsächlich ein entferntes Gerät aufgerufen oder in einer Datenbank nachgeschlagen wird.
Lesen und Schreiben:
SI_RemoteItem enthält Operationen zum Lesen und Schreiben des Items auf ein(em) entfernten Gerät; allerdings werden diese in den protokollspezifischen Subklassen nachrangig behandelt. Diese Operationen sind in SI_ModelItem eingegliedert, da dies jene Klasse ist, auf die sich ein SI_AppItem bezieht. Es gibt keinen Grund dafür, warum SI_AppItem entfernte Items und Datenbank-Items unterschiedlich zu behandeln haben sollte --- beispielsweise können einige Geräte zur Angabe ihrer eigenen Seriennummer fähig sein, wohingegen bei anderen die Seriennummern nur auf dem Typenschild und in der Kundendatenbank vorhanden sind.
Es ist zu beachten, dass die Fernzugriffsoperationen ein SI_AppItem-Argument benötigen; dies ist jenes Anwendungs-Item, aufgrund dessen die Arbeit verrichtet wird. Alle Operationen werden sofort returnt, falls SI_AppItem mit „belegt" markiert ist; wird die Arbeit tatsächlich verrichtet, wird ein Callback-Verfahren aufgerufen.
2.3.4. SI_RemoteItem-Klasse
Bei SI_RemoteItem handelt es sich um die Elternklasse für jene Service-Items, die tatsächlich von einem entfernten Gerät durchgeführt, in diesem gespeichert oder aus diesem abgerufen werden. Diese Klasse repräsentiert den tatsächlichen Speicherort für ein Speicher-basiertes Service-Item; außerdem enthält diese Klasse Informationen über individuelle Bits, falls notwendig. Wenn ein entferntes Gerät Inhalt aufweist, vergibt diese Klasse individuelle Namen und Beschreibungen an die Komponenten in Form einer Datenstruktur. Arrays identischer Items haben nur eine Komponente.
2.3.5 SI_MemoryItem-Klasse
Die SI_MemoryItem-Klasse repräsentiert Orte in einem Speicher auf einem entfernten Gerät. Wie im Abschnitt über den Hintergrund erläutert, können einige entfernte Geräte direkten Zugriff auf den Speicher des entfernten Geräts bieten.
2.3.6. SI_BitfieldItem-Klasse
Die SI_BitfieldItem-Klasse repräsentiert ein Bitfeld in einem SI_MemoryItem, das es enthält. Die Bitzahl ist relativ zum niederwertigen Bit des enthaltenden Speicher-Items, das seinerseits bis zu 32 Bits lang sein kann. Die Spezifizierung der Größe (packed-Size) des Bitfelds obliegt dem Deskriptor des Defaultwerts.
3. Kommunikationsmodul
3.1. Übersicht
Das Kommunikationsmodul 180 arbeitet mit dem Gerätemodul 170, um Operationen durchzuführen und auf Daten auf einem entfernten Gerät 90 zuzugreifen, und zwar in Übereinstimmung mit Aufrufen, die durch Ausführen der „readRequest"- und „newValue-Set"-Operationen auf Instanzen der Klasse SI_AppItem zustande kommen. Die Aufgabe des Kommunikationsmoduls 170 , das sich in 2 in der Kernschicht 190 befindet, besteht darin, eine Programmierschnittstelle zur Verfügung zu stellen zwecks Ausführung einer als „Kommunikationssitzung" bezeichneten Interaktion zwischen dem Computersystem 1, auf dem das Fernserviceanwendungsprogramm läuft (z. B. 100, 110, 120, 130 in der Anwen dungsschicht 140 aus 2) und einem beliebigen entfernten Gerät 10. Die Implementierung dieser Programmierschnittstelle ist in Subklassen der Basiskommunikationsklassen enthalten, wobei die Subklassen in der Schnittstellenschicht 260 aus 2 angeordnet sind.
Eine bevorzugte Ausführungsform der vorliegenden Erfindung nutzt eine einzige, im Kommunikationsmodul 170 definierte Programmierschnittstelle für alle Arten entfernter Geräte. Die Subklassen in der Schnittstellenschicht 260 bieten Implementierungen für diese Programmierschnittstelle, die sich zum Interagieren mit bestimmten Arten entfernter Geräte eignet.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung bestehen die Sitzungsklassenhierarchien aus Folgendem (beachte: Einrückung kennzeichnet Vererbung):
3.2. Detaillierte Beschreibung
Die SI_DeviceCallBack-Klasse enthält eine Gruppe abstrakter Programmierschnittstellen für asynchrone Kommunikation zwischen der Fernserviceanwendung und einem externen Prozess, einer Kommunikationsvorrichtung oder einem entfernten Gerät. Da der Abschluss einer derartigen asynchronen Eingabe- oder Ausgabeoperation einige Zeit in Anspruch nehmen kann, gibt die Anwendung lediglich den Aufruf aus und setzt die Bearbeitung der Benutzerschnittstellenereignisse fort. Sobald die Operation abgeschlossen ist, ruft der Gerätetreiber die Anwendung zurück, wobei er die „connectDone"-Operation benutzt.
Bei der „SI_CommunicationSession" handelt es sich um die abstrakte Basisklasse für alle Sitzungen, d. h. Interaktionen mit entfernten Geräten. Es gibt zwei Subklassen von SI_CommunicationSession, nämlich die gepufferte und die nicht gepufferte.
Gepufferte Sitzungen (SI_BufferedSession und ihre Subklassen) wickeln Kommunikationen mittels eines Protokolls ab, welches erfordert, dass Daten in Blöcken übertragen und empfangen werden, wobei sie möglicherweise einen Protokollinformationen enthaltenden Header umfassen. Die Daten und der Header werden in einem Puffer gespeichert, bevor sie versendet werden bzw. nachdem sie empfangen worden sind. Die SI_BufferedSession enthält den Code, der benötigt wird, um Daten zwischen dem Puffer und den (im Anwendungszustand 600, 810 enthaltenen) internen Datenstrukturen der Fernserviceanwendung zu bewegen, wobei Informationen im Gerätemodell 630, 860 benutzt werden, um das Format der Daten und ihren Ort innerhalb des Puffers zu spezifizieren. SI_MemorySession, SI_256BytesSession und SI_CopierSession sind konkretisierende Subklassen von SI_CommunicationSession, welche kommunikationsspezifische Informationen für verschiedene entfernte Geräte bereitstellen.
Nicht gepufferte Sitzungen (SI_UnbufferedSession und ihre Subklassen) werden als Schnittstelle zu Entitäten, z. B. Datenbank- oder Dateiservern, verwendet, für die eine Anwendungsprogrammierschnittstelle durch irgendein Betriebssystem oder irgendeine Bibliothek geboten wird, welche(s) direkte Datentransfers zwischen dem entfernten Gerät und den Daten im Anwendungszustand 600, 810, z. B. durch einen Aufruf zum Fernvorgang, unterstützt. SI_DBSession, SI_CustAccessSession und SI_HistorySession bilden konkretisierende Subklassen von SI_UnbufferedSession, welche kommunikationsspezifische Informationen für verschiedene Ferndatenbanken, etc. liefern.
TI_TaskItems werden verwendet, um eine Kommunikationssitzung in eine Sequenz von Schritten aufzuteilen. 6 zeigt eine typische Sitzung zwischen einem Computersystem 1 und einem entfernten Gerät 90, 1110. Eine Sitzung 1000 beinhaltet eine lokale Lesewarteschlange 1040 und eine lokale Schreibwarteschlange 1070, eine virtuelle Batch-Operation, um angeforderte Operationen auf Service-Items auszuführen, und eine virtuelle Mapping-Operation, um Daten zwischen dem vom entfernten Gerät 90, 1110 gebrauchten externen Format und jenem des Computersystems 1 zu übersetzen. Die Warteschlangen 1040 und 1070 sind Instanzen von SC_Queue und enthalten Instanzen 1050, 1060, 1080, 1090 von SI_QueueItem.
Jedes SI_QueueItem, z. B. 1050 oder 1080, enthält ein Boolesches Attribut „read", das für Leseaufforderungen 1050 wahr und für Schreibaufforderungen 1080 falsch ist, ein Rvalue-Attribut „value", das für Leseaufforderungen 1050 nicht definiert ist und den zu schreibenden Wert für die Schreibaufforderungen 1080 enthält, und ferner ein Attribut „appItem", das eine Referenz zum SI_AppItem 1051, 1081 enthält, das den entfernten Service repräsentiert, an dem Operationen vorzunehmen sind. Das SI_AppItem 1051, 1081 wiederum bezieht sich auf eine Instanz 1052, 1082 einer Subklasse von SI_ModelItem, die den Datentyp, die Größe und den Ort des Services beschreibt.
Des Weiteren weist die Sitzung 1000 das Attribut „callSchedule" auf, das sich auf eine Liste 1010 von Instanzen 1020, 1030 irgendeiner Subklasse von Klasse TI_TaskItem bezieht. Die verwendete Subklasse ist spezifisch für den Typ des entfernten Geräts 1110, mit dem kommuniziert wird. Die Call-Schedule-Liste bestimmt die Reihenfolge von Operationen, die bei einem einzigen Call zu erledigen sind, und kann zur Optimierung bei einem Faxgerät eingesetzt werden, das ein Maximum von 256 konsekutiven Bytes pro Call übermittelt, etwa durch Umordnen von Referenzen zu Items 920, 930 im Speicher 910 eines entfernten Faxgeräts zwecks Minimierung der Anzahl separater Calls, die für den Zugriff auf diese erforderlich sind.
Sobald die Sitzung 1000 initialisiert ist, ruft sie ein Einrichtungsmanagerobjekt für eine Instanz 1100 einer Subklasse von CM_CommunicationDevice auf, die eine Schnittstelle zur Kommunikationseinrichtung 70 bereitstellt, durch die das Anwendungsprogramm mit einem entfernten Gerät 90, 1110 kommunizieren kann. Der von der Sitzung 1000 vorgenommene Aufruf beinhaltet eine Spezifikation des Protokolls, das beim Kommunizieren mit dem entfernten Gerät 90, 1110 zu verwenden ist; der Einrichtungsmanager sendet eine Instanz 1100 einer Einrichtung 70 zurück, die das angeforderte Protokoll verwenden kann und sich noch nicht im Einsatz befindet.
Wenn die Fernserviceanwendung zur Ausführung der in der Warteschlange befindlichen Kommunikationsaufrufe auffordert, typischerweise in Antwort auf den Benutzer, geht die Sitzung 1000 ihre Lesewarteschlange 1040 und ihre Schreibwarteschlange 1070 der Reihe nach durch, um ein callSchedule 1010 aufzubauen. Falls notwendig, häuft sie Daten an, die in einen Puffer geschrieben werden sollen, und zwar mithilfe der virtuellen Funktion „putValueIntoBuffer" von jedem entsprechenden SI_ModelItem 1082, um die Daten aus ihrem internen Format im SI_QueueItem 1080 zu ihrer externen Darstellung zu übersetzen und sie im Puffer zu speichern.
Dann geht die Sitzung 1000 das Call-Schedule 1010 der Reihe nach durch und weist jedes Task-Item 1020, 1030 zur Ausführung seiner Operation an. Seinerseits teilt jedes Task-Item 1020, 1030 der Sitzung 1000 mit, welche Operation auf dem entfernten Gerät 1110 vorzunehmen ist. Die Sitzung 1000 nutzt daraufhin den Einrichtungs-Controller 1100 (auf den oben Bezug genommen wird), um die Low-Level-Lese- oder Schreiboperation mit dem entfernten Gerät 1110 durchzuführen. Falls notwendig, benutzt sie dabei die virtuelle Funktion „getValueFromBuffer" vom jeweils entsprechenden SI_ModelItem 1052, um die Daten aus dem Puffer zu extrahieren, sie aus der externen zur internen Darstellungsform zu übersetzen und in SI_AppItem 1051 mittels der „currentValueSet"-Operation von SI_AppItem 1051 zu speichern.
3.3 Definieren neuer Sitzungstypen
Wie ersichtlich, kann der Anwendungsprogrammierer Subklassen der Klasse SI_CommunicationSession rasch definieren, um neue Wege des Kommunizierens mit einem beliebigen neuen entfernten Gerät, einer Datenbank oder einer anderen externen Ressource zu beschreiben. Jedwede Anwendung, die mit einer Bibliothek, die den Code für eine derartige Subklasse enthält, verlinkt ist, wird in der Lage sein, den neuen Sitzungstyp während der Laufzeit zu nutzen; solche Anwendungen müssen nicht wieder kompiliert, sondern nur verlinkt werden. Durch Einordnen der neuen Klassen in eine dynamische Bibliothek (DLL) können zweckgemäß konstruierte Anwendungen neue Sitzungstypen selbst nach Verlinkung und Verteilung an den Benutzer nutzen.
4. Kommunikationseinrichtungsschnittstelle
4.1. Übersicht
Eine Kommunikationseinrichtung 70 (Einrichtung) ist ein Peripheriegerät eines Computersystems, z. B. ein Modem, durch welches Fernserviceanwendungen mit einem entfernten Gerät kommunizieren. In einer bevorzugten Ausführungsform der vorliegenden Erfindung ist eine Kommunikationseinrichtung 70 innerhalb eines Anwendungsprogramms als eine Instanz 1100 einer Subklasse von Klasse CM_CommunicationDevice dargestellt.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung bestehen die Einrichtungsklassenhierarchien aus dem Folgenden (beachte: Einrückung kennzeichnet Vererbung):
4.2. Detaillierte Beschreibung
Die Klasse CM_CommunicationDevice kapselt alle Attribute und Operationen ein, die nicht nur relevant sind für physische Kommunikationseinrichtungen, etwa für Modems, sondern auch für Anwendungsprogrammierschnittstellen, bis hin zu solchen Dingen wie Datenbanken und Datenbankservern. Eine Instanz von CM_CommunicationDevice besitzt Attribute, welche die Kommunikationsadresse eines entfernten Geräts, eine Liste von Protokolleinschränkungen, die für das entfernte Gerät spezifisch sind, und virtuelle Funktionen „initDevice", „connect", „read", „write" und „disconnect" enthalten, die eine allgemeine Programmierschnittstelle für alle Einrichtungen zur Verfügung stellen.
Die Klasse CM_CCA stellt eine bevorzugte Ausführungsform einer Klasse dar, die alle Attribute und Operationen definiert, die auf Kommunikations-Controlleradapter (CCA) anwendbar sind, die zur Kommunikation mit einem entfernten Faxgerät eingesetzt werden. Bei einem Kommunikations-Controlleradapter handelt es sich um eine Ausführungsform eines spezialisierten Faxmodems, das auf den internen Speicher des entfernten Geräts zugreifen kann. Die CM_USACCA-Klasse definiert eine bevorzugte Ausführungsform hinsichtlich dessen, wie auf ein Faxgerät, das ein 256-Byte-Protokoll nutzt, zuzugreifen ist bzw. wie dieses zu modifizieren ist.
Die Klasse CM_LADP bildet eine bevorzugte Ausführungsform einer Klasse, die zur Kommunikation mit Kopiergeräten verwendet wird. Diese Klasse nutzt eine Instanz von CM_Modem als Kommunikationskanal. Der LADP (Leitungsadapter) ist eine Ausführungsform einer Kombination aus Modem und Multiplexer, die eine Schnittstelle zwischen einer Telefonleitung und bis zu fünf Kopiergeräten darstellt.
Die Klasse CM_DBACESS stellt eine bevorzugte Ausführungsform einer Klasse dar, die es ermöglicht, dass die Fernserviceanwendung eine Datenbank einsieht, als ob diese eine entfernte Vorrichtung wäre. Diese Klasse verfügt über ein Handle für eine Datenbank und nutzt Operationen, die durch eine Datenbankschnittstellenbibliothek definiert sind, um auf Daten-Items in der Datenbank zuzugreifen und diese zu aktualisieren.
Die Klasse CM_DeviceManager ist eine bevorzugte Ausführungsform der Klasse für ein globales Objekt, dessen Funktion darin besteht, alle an ein Computersystem 1 angeschlossenen Kommunikationseinrichtungen 70, deren Status (Leerlauf oder belegt) und die Protokolle, die sie unterstützen, im Blick zu behalten. Ein Kommunikationssitzungs-Objekt 1000 fordert ein Einrichtungsobjekt 1100 aus dem Einrichtungsmanager an, welcher eine Referenz zu einer Einrichtung 1100 zurücksendet, die sich gerade im Leerlauf befindet und in der Lage ist, mit dem Kommunikationsprotokoll umzugehen, das vom entfernten Gerät 90, 1110 verlangt wird.
4.3. Hinzufügen neuer Einrichtungen
Wie zu entnehmen, kann der Anwendungsprogrammierer rasch Subklassen für die Klasse CM_CommunicationDevice definieren, um ein Protokoll für jede beliebige neue entfernte Vorrichtung, Datenbank oder andere externe Ressource festzulegen. Jedwede Anwendung, die mit einer Bibliothek verbunden ist, die den Code für eine derartige Subklasse enthält, wird in der Lage sein, das neue Protokoll während der Laufzeit zu nutzen; solche Anwendungen müssen nicht wieder kompiliert, sondern nur verlinkt werden. Durch Einordnen der neuen Klassen in eine dynamische Bibliothek können zweckgemäß konstruierte Anwendungen neue Protokolle selbst nach Verlinkung und Verteilung an Benutzer nutzen.
SCHLUSSFOLGERUNG
In der vorangehenden Spezifikation wurde die Erfindung in Bezug auf eine spezifische beispielhafte Ausführungsform derselben beschrieben. Viele Veränderungen, Modifikationen und zusätzliche Erweiterungen zum Framework, welche die Modellierung entfernter Vorrichtungen erleichtern, sind rasch vergegenwärtigt und in andere Ausführungsformen der vorliegenden Erfindung einbezogen.
Dementsprechend sind die Spezifikation und die Zeichnungen eher im Sinne einer Veranschaulichung als im Sinne einer Einschränkung zu sehen.

Claims

Vorrichtung (1) zum Kommunizieren mit einer Vielzahl von entfernten Maschinen (90) aus einer Vielzahl von Maschinentypen, die Vorrichtung (1) umfassend: – einen Prozessor (40) und einen Speicher (50); – Datenkommunikationsmittel (70), – eine erste Vielzahl (630, 860) von Software-Objekten innerhalb des Speichers (50) zum Beschreiben von Diensten für die Vielzahl der entfernten Maschinen (90); und – eine Vielzahl von Operationen innerhalb des Speichers, welche assoziiert sind mit der ersten Vielzahl (630, 860) von Software-Objekten, wobei die Vielzahl von Operationen bereitgestellt werden, um Anforderungen zu erfüllen, welche von den Diensten der Vielzahl von Software-Objekten beschrieben werden; dadurch gekennzeichnet, dass das Datenkommunikationsmittel (70) gekoppelt ist mit der Vielzahl von entfernten Maschinen (90), zum Kommunizieren mit jeder Maschine aus der Vielzahl von entfernten Maschinen (90); und die Vorrichtung weiter umfasst: – eine zweite Vielzahl von Software-Objekten innerhalb des Speichers (50), wobei jedes der zweiten Vielzahl (600, 810) von Software-Objekten mindestens ein Anwendungselement (820, 830, 840, 850) für die Vielzahl von entfernten Maschinen beschreibt, wobei ein Anwendungselement ein Objekt darstellt, welches Information enthält über den gegenwärtigen Zustand von mindestens einer der Vielzahl von entfernten Maschinen.
Vorrichtung gemäß Anspruch 1, wobei die Dienste für die Vielzahl von entfernten Maschinen (90) Operationen auf der Vielzahl der entfernten Maschinen (90) umfassen.
Vorrichtung gemäß Anspruch 1, wobei die Vielzahl der Operationen Datenelemente umfasst, welche zu der Vielzahl von entfernten Maschinen (90, 910), transferiert werden sollen, wobei die Datenelemente Datentypen, Datengrößen und Datenlokationen umfassen.
Vorrichtung gemäß Anspruch 1, wobei mindestens ein Applikationselement (820, 830, 840, 850) für die Vielzahl von entfernten Maschinen (90, 910) einen Zeiger umfasst zu einem Objekt der ersten Vielzahl (860) von Software-Objekten und einen gegenwärtigen Wert, welcher einem Wert entspricht von einem Datenelement innerhalb einer entfernten Maschine aus der Vielzahl von entfernten Maschinen (9, 910).
Vorrichtung gemäß Anspruch 4, wobei mindestens ein Anwendungselement (820, 830, 840, 850) der entfernten Maschine (90, 910) auch ein Lese-Anforderungs-Flag umfasst und einen neuen Wert zum Beschreiben einer anhängigen Anforderung für einen Wert, der zu mindestens einer der Vielzahl von entfernten Maschinen (90, 910) transferiert werden soll.
Vorrichtung gemäß Anspruch 1, wobei die zweite Vielzahl von Software-Objekten (600, 810) ein Objekt umfasst, welches ein Element in einer Datenbasis beschreibt.
Vorrichtung gemäß Anspruch 6, wobei Anforderungen für Aktualisierungen der Datenbasis erzeugt werden, wenn ein Datenelement transferiert wird zu der mindestens einen Maschine der Vielzahl von entfernten Maschinen (90, 910).
Vorrichtung gemäß Anspruch 1, wobei die zweite Vielzahl (600, 810) von Software-Objekten sich in einer Schlange (queue) im Speicher befindet, wobei die zweite Vielzahl von Software-Objekten (600, 810) Anforderungen umfassen für Operationen, welche auf der Vielzahl der entfernten Maschinen ausgeführt werden sollen.
Vorrichtung gemäß Anspruch 1, wobei die zweite Vielzahl (600, 810) von Software-Objekten sich in einer Schlange im Speicher befindet, wobei die zweite Vielzahl von Software-Objekten Anforderungen umfasst für Datenelemente, die zu der Vielzahl von entfernten Maschinen (90, 910) transferiert werden sollen.
Vorrichtung gemäß Anspruch 1, weiter umfassend: eine Massenspeichereinrichtung (60), welche geeignet ist, eine Vielzahl von Datendateien aufzunehmen, wobei die Vielzahl der Datendateien Darstellungen der Vielzahlen von Software-Objekten umfasst; und Prozessierungsmittel (40), welche mit der Massenspeichereinrichtung (60) gekoppelt sind, um eine der Vielzahl von Datendateien in die erste Vielzahl (630, 860) von Software-Objekten zu transformieren.
Vorrichtung gemäß Anspruch 10, wobei die Vielzahl von Datendateien Textdaten umfasst.
Vorrichtung gemäß Anspruch 1, weiter umfassend: Prozessierungsmittel (40) zum Transformieren der ersten Vielzahl von Software-Objekten (630, 860) in eine Datendatei; und eine Massenspeichereinrichtung (60), welche mit dem Prozessierungsmittel (40) gekoppelt ist, zum Aufnehmen der Datendatei.
Vorrichtung gemäß Anspruch 12, wobei die Datendatei Textdaten umfasst.
Vorrichtung gemäß Anspruch 1, weiter umfassend: eine Anzeige (10); eine Tastatur (20); eine Zeigeeinrichtung (30); eine graphische Benutzerschnittstelle (150); Anforderungsmittel, gekoppelt mit der graphischen Benutzerschnittstelle, um Anforderungen zu stellen für Dienste auf der Vielzahl von entfernten Maschinen, in Antwort auf eine Benutzereingabe mit der graphischen Benutzerschnittstelle; und Aktualisierungsmittel, gekoppelt mit der graphischen Benutzerschnittstelle, zum Aktualisieren der graphischen Benutzerschnittstelle, wenn ein Dienst ausgeführt worden ist auf einer der Vielzahl von entfernten Maschinen.
Vorrichtung gemäß Anspruch 14, wobei die Dienste für die Vielzahl von entfernten Maschinen (90) Operationen auf der Vielzahl von entfernten Maschinen (90) umfassen.
Vorrichtung gemäß Anspruch 14, wobei die Dienste für die Vielzahl von entfernten Maschinen (90) Datenelemente umfassen, welche transferiert werden sollen zu der Vielzahl von entfernten Maschinen (90), wobei die Datenelemente Datentypen, Datengrößen und Datenlokationen umfassen.
Verfahren zum Kommunizieren einer Vielzahl von entfernten Maschinen (90) aus einer Vielzahl von Maschinentypen, in einem Computersystem (2), einen Speicher (50) und eine Massenspeichereinrichtung (60) umfassend; wobei das Verfahren folgende Schritte umfasst: – Bereitstellen einer Vielzahl von Maschinenbeschreibungsdateien innerhalb der Massenspeichereinrichtung (60), wobei die Vielzahl von Maschinenbeschreibungsdateien geeignet ist zum Beschreiben der Vielzahl von entfernten Maschinen (90); und – Bereitstellen einer Vielzahl von Anwendungsprogrammen innerhalb des Speichers (50), wobei jedes der Vielzahl von Anwendungsprogrammen geeignet ist, Repräsentationen der Vielzahl von Software-Objekten zu lesen, – und um eine Anforderung zu stellen, welche von mindestens einem der Dienste der Vielzahl von Software-Objekten beschrieben wird; dadurch gekennzeichnet, dass das Verfahren folgende Schritte umfasst: – Bereitstellen eines Programms für die Vielzahl von Anwendungsprogrammen zum Empfangen von Mitteilungen (communications) von der Vielzahl von entfernten Maschinen (90), und zum Ausgeben von Dateien, welche die Daten enthalten, welche von mindestens einer der Vielzahl von entfernten Maschinen mitgeteilt wurden, und – Bereitstellen einer Vielzahl von Software-Objekten innerhalb des Speichers (50), wobei die Vielzahl von Software-Objekten geeignet ist, Information bereit zu behalten über den gegenwärtigen Zustand von mindestens einer der Vielzahl von entfernten Maschinen.
Verfahren gemäß Anspruch 17, wobei die Dienste der Vielzahl von Software-Objekten Operationen auf der Vielzahl von entfernten Maschinen (90) umfassen.
Verfahren gemäß Anspruch 17, wobei die Dienste der Vielzahl von Software-Objekten Datenelement umfassen, die zu der Vielzahl von entfernten Maschinen (90) transferiert werden sollen.
Verfahren gemäß Anspruch 17, weiter umfassend folgende Schritte: Bereitstellen einer lokalen Datenbasis (310) zum Zugriff auf eine entfernte Datenbasis, wobei die entfernte Datenbasis eine Vielzahl von Maschinentypen und Zugriffsinformation für die Vielzahl von entfernten Maschinen (90) umfasst; und Bereitstellen eines Programms zur Abfrage der entfernten Datenbasis und zum Aufbau einer Datendatei, welche eine Darstellung einer Vielzahl von Software-Objekten umfasst, welche einen Maschinentyp und Zugriffsinformation spezifiziert für eine Maschine aus der Vielzahl von entfernten Maschinen (90).
Vorrichtung gemäß Anspruch 17, weiter umfassend folgende Schritte: Bereitstellen eines Programms für die Vielzahl von Anwendungsprogrammen, welches geeignet ist auf der Vielzahl von entfernten Maschinen (90) betrieben zu werden unter Verwendung einer Schlange (queue) im Speicher (50), wobei die Schlange eine Vielzahl von Software-Objekten umfasst, welche Anforderungen umfassen für Operationen, die auf der Vielzahl von entfernten Maschinen ausgeführt werden sollen.
Verfahren gemäß Anspruch 17, weiter umfassend folgende Schritte: Bereitstellen eines Programms für die Vielzahl von Anwendungsprogrammen, welches geeignet ist auf der Vielzahl von entfernten Maschinen (90) betrieben zu werden unter Verwendung einer Schlange im Speicher (50), wobei die Schlange eine Vielzahl von Software-Objekten umfasst, welche Anforderungen umfassen für Datenelemente, die zu der Vielzahl von entfernten Maschinen transferiert werden sollen.
Verfahren gemäß Anspruch 17, weiter umfassend folgenden Schritt: Bereitstellen eines Programms für die Vielzahl von Anwendungsprogrammen, welches einem Benutzer erlaubt, interaktiv eine Maschine aus der Vielzahl von entfernten Maschinen (90) und Dienste für die eine entfernte Maschine (90) zu spezifizieren.
Verfahren gemäß Anspruch 23, wobei die Dienste für die eine entfernte Maschine (90) Operationen für die eine entfernte Maschine (90) umfasst.
Verfahren gemäß Anspruch 23, wobei die Dienst für die eine entfernte Maschine (90) Datenelemente umfasst, die mit der einen entfernten Maschine (90) transferiert werden sollen.